By Kent McDonald
Henrik Kniberg in his excellent YouTube Video Agile Product Ownership points out that teams face three competing forces:
– Build the Right thing
– Build the thing Right
– Build the thing Fast (i.e. shorten the feedback cycle)
All three are equally important, and they all reinforce each other, yet it seems as though since the agile manifesto was written, building the thing right and building the thing fast have gotten a lot of the attention as these are mostly impacted by improving development practices and collaboration, which is primarily the focus of the various agile approaches (Scrum, Extreme Programming, etc.)
When it comes to building the right thing, it seems as though an unstated assumption has always been “the Product Owner/Onsite Customer knows what that is.” Trouble is, the people who may be the most desirable to act as a product owner or onsite customer in terms of their authority to make decisions on what the right thing to build is either do not have the time, or the inclination, to spend the amount of time with a time required to effectively provide the necessary guidance.
To make things potentially even more interesting is that there are (at last count) at least three different skill sets that all tend to center around figuring out the right thing to build. Each skill set is well suited for a given context, and less applicable in others and as a result tend to overlap quite a bit. On top of that most people who consider themselves a practitioner in one of those three skills sets rarely identify the other skill sets as useful, even though they practice many of the same skills. Those skill sets are product management, user experience, and business analysis.
There is quite a bit of overlap between business analysis and product management, primarily because they apply a similar set of skills in different contexts – Product Management for software products and business analysis for efforts that are not directly related to an organization’s end products, such as processes or systems that support those processes. There is a substantial set of Product Management that does not overlap with business analysis such as focus on profit and loss and delving into the market aspects of a product.
Business Analysis and User Experience provide an interesting comparison, they solve the same problem, but take fairly different approaches to solve it. Business Analysis describes the right thing to build using an analysis mindset and focuses more on the needs of end customers (the people paying for a change) whereas user experience tends to solve the problem with a design perspective and places more emphasis on the end user of the solution.
Again, neither perspective is right or wrong, and in many cases both perspectives are needed to a greater or lesser extent depending on the context.
So you have multiple ways to identify the right thing to build, with disagreement from practitioners around whether they actually do the same thing and yet a lot of overlap between the approaches. It would be helpful if there was a hand tag that you could use to refer to the activity of figuring out the right thing to build that incorporates the useful aspects of product management, business analysis and user experience but is not exclusive.
The International Consortium of Agile, (ICAgile) in an attempt to organize all the knowledge related to agile into tracks, applied the term “Value Management” to software development as a way of pulling together the disparate ways of figuring out the right thing to build into some sort of coherent whole.
ICAgile did not define specifically what Value Management specifically means, but introduced the Value Management Track as follows:
“The Agile Value Management track emphasizes customer-focused approaches and practices to maximize value delivery at various levels within organizations. The learning objectives highlight concepts around organizational alignment, adaptive planning, establishment of value teams to set priorities, and techniques for spreading value-based approaches such as product roadmapping, progressive elaboration, and frequent cross-program communication.”
Here’s how I like to think of Value Management as applied to an agile setting (although hopefully you are doing these things regardless of what approach you are using.
- Understand stakeholder needs
- Determine if the need is worth satisfying
- Determine the best solution to satisfy it
- Build a shared understanding of the solution
- Validate the need was satisfied
This concept of value management is understanding the next most important set of needs in the marketplace or in your business and finding that in a way that you can work through this collaborative process of getting the best solution to the problem delivered in the nearest term possible. So it’s not just about taking orders, it’s about balancing capability and capacity against the next most important things to the business. It’s much bigger than order taking and producing documents.
The Agile Value Management class that B2T Training and Lithespeed are partnering to deliver shows how to apply business analysis techniques as well as a few techniques from Product Management and User Experience to make sure your team is building the right thing for your organization.
