If there are any words that describe Agile’s ultimate goal, they are surely ‘working software’.
As the Agile Principles themselves put it:
“Working software is the primary measure of progress.”
Not that all software development methodologies aren’t aiming at the same thing. But Agile is unique on keeping the focus on the end result, and not allowing itself to be distracted by formalities such as contracts, plans, specifications, procedures and status reports. The timescales on which Agile operates – software finalised, if not actually deployed, every 2-4 weeks – also makes it easy to focus on actual delivery. After all, delivery is any day now – quite the opposite of the long-term delivery schedules of so many traditional delivery projects, where the first delivery might not be until the year after next!
But is working software really the right focus? For a single iteration involving a single software development team it looks fine, but how many deliveries are limited to small upgrades, localised changes and generally things that demand no more authority or expertise that already lies within the average software development team and its established Extended Team?
What is a working solution?
For example, only if a change to existing software is pretty limited will there need to be no change to training or operational controls or database tables the Core Team don’t own or…
As for a complete new product, the list of items that need to be delivered over and above the actual software can be huge, with individual items that have positively strategic significance:
- Changes to business policy, vision and strategy.
- Business plans, sales and marketing components, new recruitment, etc.
- New or revised business processes, data, standards, procedures, tools, templates, reporting, metrics, etc.
- User recruitment, training, organisation, evaluation, etc.
- Changed or complete new IT systems and architecture, management systems, data, etc.
- Revised operational design; scheduling, tools and controls; skills, knowledge, training and documentation; organisation and resourcing, etc.
Plainly this goes far beyond ‘working software’! Of course, a new product like this stands at the extreme opposite from updating a single web page, and a lot of a new product is typically developed in the form of tranches of software. But still, aren’t most ‘software’ developments typically embedded in something larger and more diverse? So taking working software are your end-point suggests a far-from-optimal, if not somewhat timid process.
Impact on the Agile delivery process
So what does moving ‘working software’ to ‘working solution’ imply for Agile? Well, it places a range of new demands on the delivery process as a whole.
|Product management structure|
This is by no means the full extent of the impact of working in terms of working solutions rather than working software. Depending on your organisation, it could be better or worse, but it will certainly be different, and almost certainly harder.
And crucially, it’s not just a matter of scale: complexity is an independent variable here, so ‘Agile-only-more-so’ is not the answer.
[Warning! Pretentious analogy alert!]
So, what does all this mean? It’s like the difference between Newtonian and Einsteinian models of gravity: Newton’s equations are valid for certain limited (but still extremely wide-ranging conditions, but once you start to come close to the speed of light, Newton turns out to be not so much wrong as simply a special case of broader set of equations – Einstein’s. Likewise, working software is a locally useful but more generally limited version of what the delivery ‘equation’ should been about, namely working solutions.
The original principle wouldn’t have been harmed by replacing ‘working software’ with ‘working solution’, and it would have been more sustainable, though it would also have required some more thought about exactly how Agile fits into the corporate world. Given the historical conditions in which Scrum and then Agile first emerged – a world of massive, failing programmes – it isn’t surprising that their authors strove so hard not only to humanise the delivery process but also to strip delivery back to its basics. Nevertheless, if we continue to insist on defining working software as ‘the primary measure of progress’, then we effective resign Agile to small ballparks and minor league status.
But even this isn’t the final word on Agile’s goals. A working solution as such is no doubt a better goal than simply working software. But it still isn’t as good – and as directly tied to your organisation’s truly ultimate aims – as delivering value. But that’s another issue – which you can read about here.