Feb 11th 2001 – exactly 25 years ago – was the first day of a 3-day meeting at the Snowbird ski resort in Utah that gave birth to the Manifesto for Agile Software Development.
Like all important documents, most folks who think they know what it says don’t appear to have actually read it.
There’s no mention of “sprints”, or “story points”, or “user stories”, or “build pipelines” or “Kanban boards” or any of the other details of specific Agile methodologies. The Manifesto isn’t a “how-to” guide. It’s a “why-to” guide.
It lays out a set of values and principles for teams who wish to be more responsive to changing user and business needs, through continuous learning and adaptation in a highly people-centric – and especially customer-centric – process.
On the front page of the manifesto’s website, it states:
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
The values and principles of Agile Software Development describe what it is like to be agile (with a small ‘a’). We do not “do” agile. We do not “adopt” agile. We do not “implement” agile.
We become agile.
The manifesto itself is, of course, a laudable but compromised attempt to bring multiple iterative and “lightweight” development methodologies – different “brands” – under one banner.
One of those brands came to dominate in the minds of software developers.
Another came to dominate in the minds of managers and executives, and ultimately came to dominate economically. This was a mistake.
“Agile Software Development” is doing software development in an agile way. It’s not a management thing.
Agile teams are self-organising, because putting decision-making power where (and more importantly, when) decisions need to be made – and therefore understood – is one of the keys to unlocking greater agility. A chain of command almost always becomes a serious bottleneck.
The other key message that got lost in translation is the need for strong technical chops. Teams who can’t deliver rapidly, reliably and sustainably get micromanaged, and that ends their experiment in agility.
Without development teams with strong technical discipline who are empowered to make decisions, Agile Software Development becomes little more than Agility Theatre. And that’s the reality for the majority of teams today – command-and-control waterfall development wearing an Agile Halloween costume, while the technical capability withers from lack of investment.
In this respect, Agile Software Development’s reputation – like the reputations of so many ideas in software development – is built on the experiences of teams that weren’t applying the values and principles. Most developers and managers have never even seen software agility in practice.
I recommend reading the manifesto again (or for the first time). Perhaps do it as a team. Maybe talk about how the values and principles could or are helping, and identify where your organisation might just be play-acting
