Agile 20 years on...
On the 20th anniversary of the Agile Manifesto, we ask whether the adoption of agile thinking and practices has improved business operations?
2021 marked the 20th anniversary of the Agile Manifesto, created when 17 software experts met in Snowbird, Utah, to discuss how to radically improve the delivery of software products.
Since that time, the Agile movement has grown to be a global phenomenon, not only in the software field, but across all aspects of business and government. And understandably so - what business or government agency would not want to be seen as being agile?
So, how have we done? Has the adoption of agile thinking and practices improved the operation of government and businesses? Or has it just been another fad, like Lean, Six Sigma and TQM, that will also fade into obscurity?
Let’s assess the success (or otherwise) of the Agile movement by revisiting the four underlying values of Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Individuals and interactions over processes and tools
The proliferation of squads, tribes, guilds and scrum teams, and the uptake of stand ups and showcases in organisations, would suggest that there has truly been a revolution in the way we now work - and that is a good thing. But there has also been huge growth in heavy, complex processes to govern these interactions (SAFe anyone?), which is the antithesis of the simplicity and transparency that this value aims to promote.
Overall: Improvement needed - aim for simplicity and focus on outcomes, not process
Working software over comprehensive documentation
On the positive side: organisations that have truly embraced a “One Touch Deployment” approach are able to release tested, production-ready software literally at the press of a button. This is an amazing improvement over what happened pre-2000.
On the negative side: unfortunately, the number of organisations that can do “One Touch Deployment” is very few - the majority of organisations still take an inordinate amount of time and money to get new product features developed and shipped.
Overall: Focus on getting small increments out quickly - the big bang approach will always be slow and error-prone
Customer collaboration over contract negotiation
While there have been valiant attempts to improve collaboration in product and service development, this has been more effective inside the organisation than between them. Contracts between organisations have proven to be a stumbling block to agility.
Collaboration requires common goals, a high degree of trust, openness and transparency. Contracts, on the other hand, remain adversarial in the main - dividing up the pie rather than growing it.
Overall: much work needs to be done in the area of collaborative contracting, especially the promotion of such thinking in procurement approaches and policies.
Responding to change over following a plan
This is where I think we have probably seen the most improvement from the adoption of Agile thinking generally.
In the old days, project success was inextricably linked with delivering the plan “on time and on budget”. While plans are not unimportant (indeed, they are essential), the general understanding these days is that a plan is a starting point that is subject to change as we learn new information - this is a major breakthrough in thinking!
Also, while time and budget are both critical elements of any meaningful endeavour, they are increasingly seen as the constraints that they actually are, rather than fixed objectives to be met in their own right.
Overall: Excellent result - keep up the good work!
This is my subjective take on the success of the Agile movement on its 20th anniversary - your mileage may vary. But I do firmly believe that in the rush to adopt Agile, organisations are still leaving a lot on the table.
The takeaway: the KISS principle (Keep It Simple, Stupid) still applies. If it seems too hard, takes too long, or requires too many checks and balances, it ain’t agile.