Member since 2 years
Agile & Product enthusiast who is passionate about solving customer problems with efficiency. Nupur love's to convey the agile values and principles using creative ways like making videos over Agile values, conducting games & leading by example. Recently Nupur's "The Scrum Master Song" was appreciated by the legends Jeff Sutherland and Mike Cohn appreciated my efforts(hyperlink) for writing and composing and also coming up with a video which was created by his son's toys :)
Nupur is also fascinated talking about the product, design thinking and business patterns in the merging technology ocean. Leaders like Simon Sinek (Start with Why), Peter Senge(The fifth Discipline) & Eric Ries (The Lean Startup). his world revolves around a product.
I C E - Iterative Customer EngagementNupur WaikarProgram ManagerVeritas SoftwareNilesh NaikProgram ManagerVeritas Software
schedule 1 year agoSold Out!
In Agile world today, organizations are solving problems by building Epics/Features in iterative fashion. The release frequency may vary from every day to every quarter depending on the organization’s size & business demand. There are few business or product management artifacts which are referred pre(to show need of the feature) or post(to know the revenue of the product) epic execution. What if there’s a way to gain more information on feature’s acceptance by the market or target customers in an iterative fashion while the Epic is being developed. Every organization has processes in place to collect very rich data by having customer demos & calls, beta testing or various other avenues. However this valuable information may not be available under one umbrella.
Hence, this experimental model that can help every Epic(scrum teams, leadership & other stakeholders) to understand progress of the Epic/feature from business side while it is being developed. Also, decisions, like if the version v1 of an Epic is released then is it worth investing in v2 . Let’s call it Iterative Customer Engagement & Adoption Metrics.
The metric is updated regularly (quarterly or monthly) while the Epic is being baked & could be reviewed by the stakeholders anytime. This will provide a live Epic health that gives confidence and motivation to the development teams as well as to the leadership to make strategic decisions.
Iterative Customer Engagement & Adoption Metrics consists of following parameters. The parameters may vary based on your release frequency.
- AWARENESS: How many new customers have been informed and are aware about the upcoming Epic.
- INTEREST:How many new customers have shown interest to upgrade/buy the product just to use your feature ?
- PRESENCE:How many customers have attended at least one of your demos?
demos in last quarter.
- CONTRIBUTE: How many new requirements have been added or updated in the Epic based on customer feedback.
- BETA: How many customers contributed in BETA testing specifically for your Epic.
- ADOPTION: How many new/existing licenses acquired | Expected v/s realized growth | How many customer escalations have been raised specifically to your Epic
We will discuss the benefits of this model in more detail during the talk. This will help the entire agile community as well as business community to be more efficient in making decisions.
Building Teams for AgilityNupur WaikarProgram ManagerVeritas SoftwareManish AnandaniSr. Manager, Agile Practice GroupVeritas Software
schedule 2 years agoSold Out!
The 3 key elements of an organization developing products are Leaders, Middle Management & Teams. These elements of organizations need few ingredients in order to build agility in teams. Leaders should successfully be able to convey the vision and the purpose to the middle management & ensure its further conveyed to the teams.
The Middle management should focus on Trust & Values over command and control in order to leverage full potential of teams.
Once leaders & management trust the teams and the vision and purpose is clear, Agile coaches, scrum masters can help teams build accountability, commitment, trust and ownership. These elements functioning with sustainability will help build successful products with value & build self-organizing teams.
Validate your hypothesis with effective Sprint reviewsNupur WaikarProgram ManagerVeritas SoftwareNilesh NaikProgram ManagerVeritas Software
schedule 2 years agoSold Out!
Demos are such a key practice to building the right thing for our customer that alignment on its purpose and value is essential. That’s why our Leaders discussed it at their recent Agile Leadership Planning workshop.
We have alignment with PM-PO/Engineering/Operations Leadership that the purpose of our demos is have a rich dialog with our customers (internal and/or external). The purpose of that dialog would be to:
- Flesh out and vet the problem statement
- Flesh out and vet the proposed solutions
- Test our assumptions and our hypotheses
- Obtain specific feedback on incremental value created towards a solution
We want to ensure the Demos result in value to the customer and any aspect of a Demo not focused on that could be considered waste. In particular this means that Demos are not for status or a platform to showcase efforts and efficiencies. Here are a number of ideas that teams can consider for improving their demos to better align with value to the customer:
- Presence of Key stakeholders in the demo
- Depending on the value the team is delivering in the Sprint, team would decide whose presence is most critical for an early feedback
- SM/PO would engage relevant people in advance and would make sure they attend the demo
- Such Personas could be:
i. Consumers (Dependent teams/Customers etc)
iii. PO and/or PM
iv. Support champions and/or Professional services
v. System testers and/or Hardening representatives
vi. Documentation developer and/or i18n champions
vii. BizTool representative if required
- Having “Right” people in the demo would lead to “Right” feedback
- 1:1 interaction if important stakeholders miss the demo
- Avoid inviting DLs or whole groups that are not all likely to provide feedback as it dilutes concept that if you are invited to a demo you should attend it
- Set expectations about demo / Lean thinking
- Critical piece of a successful demo is to have “Right/Agreed upon” expectations from all stakeholders
- Team and Leadership should be in sync about what is being Demoed and this in a way would avoid demo becoming “Status” meetings
- The decision filters we can use:
i. What validation team is looking out for
ii. Who are the people/team to provide that
iii. What value is delivered by us in the Sprint
- Alignment between PO and team on when is it OK to cancel the demo
- Have a small Demo retro to talk about “Do we all see value in the way we run our demos”?
- Try to be customer centric and focus on key areas
- If we start combining demos, the frequency of cancelling the demo might reduce
- Update on actions taken based on the feedback we received in earlier demos
- This would boost confidence of stakeholders that the feedback given is being considered
- You will have active participation rather than just having muted audience
- Are there possibilities of efficiencies
- One of the ways to improve efficiency is having 2 Demo meetings – One to cater internal stakeholders while other for customers. Each demo would have its own flavor and will trigger specific feedback. This might as well avoid having overlap of unnecessary details.
- If possible, we can combine Demos of multiple teams working on same Epic. This would enable people to have end-to-end visualization of the epic. In short showing the “Big picture”
- Agenda of the demo can be sent out in advance so that relevant audience can join
- Highlight value delivered in the Sprint
- Talk about the value the team has delivered in the Sprint. This can be in form of unblocking any other team or it could be the milestones achieved
- Briefing on milestones might comfort leaders as far as timelines are concerned
- During Sprint planning, team can discuss OR design the sprint deliverable based on the value team wants to deliver
No more submissions exist.
No more submissions exist.