When explaining Agile, it’s common to describe it in terms of the basic development-and-delivery process from which Agile (and especially Scrum) began:
- A single development team.
- Focused on a single iteration (with occasional references to a multi-iteration release).
- Limited to software development (with an implied but not described software deployment process).
- Defining success as ‘working software’ delivered.
But looking at the later evolution of Agile as a whole, it’s clear that this is quite a narrow view of the overall change management context within which Agile teams often operate:
- Multiple teams.
- Organised across a multiple multi-iteration releases.
- Including various non-software elements, such as business process changes, training and so on.
Regarding the last point mentioned above – defining success in terms of working software – the issue has always been simple but profound. Working software is good, but from the organisation’s point of view it can never be much more than an indirect measure of value. And however highly they may think of new working software, what the Agile team’s stakeholders actual want is value. Software may be an enabler of value, but it is not obvious why one piece of software is more valuable thn another, beyond (in the original model) the fact that the Product Owner says it is.
So in the absence of a much clearer view of what is actually valuable, working software can only be an indirect measure. And that ‘clearer view’ comes from understanding the place of any given piece of software in the product’s overall strategy. As Rich Mironov puts it:
There is no natural prioritization of development work without an underlying strategy. Individual feature-level ‘value’ calculations don’t form into great products. (Twitter 15/6/2018)
As a result of not knowing a given story or a given piece of software’s place to the overall product strategy, there is no way to reliably estimate its value. After all, knowing the value of something (an epic, a story, a theme, etc.) depends on:
- knowing how to optimise the overall flow of costs and benefits,
- and therefore how to maximise the value delivered,
- and therefore understanding what the real value of this or that story is at a given point of the overall product lifecycle.
Hence the centrality of Product Management as a whole to a mature Agile. Taken together with a product vision, backlog and plan, the product strategy shows why story x is important – including why it’s more important than stories y and z. In a different strategy it might be the other way around – story x might be completely worthless, while stories y and z are invaluable.
In short, in the absence of a well-defined Product Management cycle – as defined by Agile201, of course – teams cannot know how to maximise value. So they are reduced to feature factories: they can control how well the deliver working software, but whether they deliver value is out of their hands.