In the last two posts I’ve taken two different views on what might happen to the Software Demand curve when we introduce Agile:
When we discussed how Agile effects the software supply curve things were pretty clear cut. Agile, in the long term boosts supply, and may even flatten the curve - making it more responsive to price changes, i.e. more elastic. Unfortunately things are not so clear cut with the demand curve.
Good news: There is a story Agile people - OK me! - sometimes tell - about what “should” happen with demand in an Agile environment.
Bad news: The is another story about demand in an Agile environment, one that Classicist (i.e. believer in “Waterfall” style up front requirements and planning) fear. And I’ve seen that too. It ain’t pretty.
But, the key point is: Few of the Agile tools work directly on the demand curve. After all, Agile is about software and the demand for software is derived from something else so why would they?
Let me say that again in other words because it is important: Nobody wants software for the sake of software, the demand for software is derived from some other demand, e.g. a retailer wants to sell online, that means they need software.
The current Agile tool set (e.g. User Stories, Acceptance Criteria, Specification by Example, etc.) which touches on demand - call it need, want, requirements, specification, whatever you want - does not address the underlying demand. These tools operate with the demand as presented.
Sure there can be feedback from the tools and Agile deliveries but feedback is often absent. Even when feedback is present those responsible for the underlying demand may not want to hear - or act - on the feedback. And in an environment where success is measured by criteria like “On Budget, On Schedule, On Features” acting on feedback may be impossible.
Which brings us back to the 3 Styles of Agile: Iterative, Incremental and Evolutionary (part 1) and 3 Styles of Agile part 2. (At some point in the future I will reprise those three styles in the light of this analysis.)
One of the key factors in determining whether the feedback can affect underlying demand is whether those responsible (e.g. senior managers) who largely originate the underlying demand are open to feedback. Which brings us to another story I need to tell, another time...
Where does this leave us then?
If the current Agile toolset cannot address the underlying demand we need new tools. We might choose to add those tools to the thing we call Agile or we might choose to put them in another category.
Personally I believe many of those tools do exist but they exist outside the Agile space. They are fellow travellers if you will. For example: Beyond Budgeting is clearly one of those tools. However, many of those tools have their own names, they are not Agile, they are what they are (e.g. Beyond Budgetting). They fit very nicely with Agile but they are not.
However that is my personal view. I also think that Agile is a marketing bang-wagon and those tools will be conscripted to the Agile course and in many cases put under the Agile umbrella.
Either way the problem we need to recognise is: addressing the software demand curve Agile is necessary but not sufficient by itself.
Allan,
ReplyDeleteYes, you're very right. Agile's effects on the demand curve in short time frames should be minimal (arguably by design), although due to feedback loops and interaction effects could influence the demand curve.
Agile & Lean are both sets of techniques which optimize the production of widgets (features), while attempting to match what people want to buy at various price points (i.e. the demand curve). These frameworks serve to optimize for efficiency during the production process. If a factory/development team is not operating at a globally optimal point, a potentially positive ROI on moving the team towards this global optimum.
Optimizing development is largely where agile came from, since there were such glaring sub-optimalities in how software was created in the late 90s, for example with waterfall 1.0.
Yet taking agile and lean to the extreme, assuming a whole industry tries to make themselves more efficient, competition becomes similar to long distance race like a marathon, where everyone wants to optimize their times. This isn't necessarily a healthy obsession, certainly not for software providers of all types.
Assuming you do have a lean operation running which responds rapidly to change, arguably the bottleneck moves towards business strategy. At that point, the problem space becomes a lot more messy, as each competitor is looking at sets of strategic tradeoffs.
Companies can differentiate by attempting to find niches within a specific market, which will have specific sets of preferences. Each larger group like this will form the basis of a variation of a product, which eventually may become its own product category. These strategic tradeoffs, while arising from the demand side, will have implications for the supply/production side. By choosing a smart set of tradeoffs, and then supplying the features implied faster than anyone else, software companies create completely new markets (blue ocean strategy). First mover advantage is pretty important, particularly in software.
Personally, I think adding more techniques to the agile umbrella isn't necessarily useful, as it's not what agile is meant to do. Agile has enough "meat" on its own and also a clear problems it attempts to solve. It's enough to provide pointers to the relevant sources.
That said this cross-pollination among Type Y management tools is increasingly necessary, as there are arguably all an attempt to address problems caused by something else. The corporation, as it was articulated during the 20th century, has become increasingly inadequate to the 21st century. Agile is just one of a number of tools which are evolving to help us cope empirically with this lack of theoretical understanding.
Luke, thanks for three lengthy analysis
DeleteOn strategy I think you are right. Something I have seen in my own work is that as the development side gets cleaned up then failing in strategy become apparent - sometimes it is a complete absence of strategy.
I hope we can find m more 'fellow traveler' type-y tools to supplement our work, I'd prefer to avoid inverting new ones - that is the pattern thinker in me!