Agile swear words part 6: Agile
He said "I don't know what it means." I said "Neither do I."
I like your manifesto
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.
Who could argue with any of that?
Let’s put it to the test-o!
The Agile Manifesto, reproduced in full above, was written during a meeting in Snowbird, Utah in 2001. The people behind it met to discuss new ways of creating software. They were looking for a better methodology than traditional ‘waterfall.’ They were inspired by the rise of extreme programming (XP) and other approaches that prioritised flexibility and faster delivery over full requirements gathering and change control.
The Manifesto laid the foundations of the Lean Startup movement, and gave rise to a new approach to software development that blended XP with some of the tenets of lean manufacturing pioneered by companies like Toyota. There are few, if any, software development houses today that wouldn't lay claim to being agile.
Victory is ours? Not quite.
What should being agile mean? The manifesto is pretty clear. Looking at it now, I wonder if the authors missed a trick by not emphasising learning over delivery of new features, but overall, the message is clear.
What does being agile mean? In many organisations, it means “we do SCRUM.” We have daily stand ups. We have story points.
A surprising number of people haven’t even read the manifesto. At one organisation, it took me weeks to persuade one senior colleague to read it. I think he thought that it was going to have the length and readability of the Communist Manifesto.
We take foundational knowledge for granted at our peril. Many leaders and organisations are simply adopting practices and imposing them on teams with no understanding of the real issues those teams are wrestling with. Then they get surprised when nothing improves.
There’s nothing in the manifesto about how, and that’s ok. There are a million ways for teams to improve their practices and learn how to improve their ability to deliver software, which in turn should be measured in customer value. That’s the key message from Snowbird in 2001.
It’s alright to say things can only get better
So what went wrong?
A consulting industry spun up, selling practices and certifications. Delivering more things became the promise, an irresistible siren song for organisations looking to “do more with less.” Performative “ceremonies” took the place of doing the right things or removing frictions.
If we were to hold a retrospective on the success of the manifesto now, we’d see that the promised revolution has been suppressed.
Process
Ask many Product Managers to describe how they’re agile, and they’ll talk about Jira. They’ll tell you about their sprint cadence, their story points, their velocity charts. The practices have become the point. The values that may have led to their adoption have evaporated. Organisations wanted to move from waterfall to agile, but the reliance on process prevents learning.
So we get standardisation. Scaled agile. Diagnostic checklists. Cross-functional dependency mapping. There are compelling reasons why these might solve organisational problems, but without a deep understanding of why these things are being adopted and what success looks like, it becomes performative.
Let’s take the daily stand-up as an example. This was described to me by an Engineering Manager as the most important 15 minutes of his team’s day. It’s a brief moment of coordination and establishment of blockers, owned by the team, for the team. In many organisations, it’s a status report. Everyone nods while the other team members give meaningless updates. This opportunity for learning and reflection becomes a form of micro-management.
In many cases, the ringmaster in this circus is called a Scrum Master, an interesting juxtaposition to the idea of servant leadership that is supposed to underpin agile software development. And don’t get me started on the idea that there’s a product “owner.”
Sprints are not sustainable over long distances. Sustainable practices compete with the language. The language wins.
The best teams I’ve worked with evolve their practices. They’ve inspected and adapted so that their way of working fits their context rather than a framework. They’re not precious about their processes. They do what works and discard what doesn’t.
They understand what matters. Individuals and interactions over processes and tools.
Documentation
“Working software over comprehensive documentation” is probably the tenet of the manifesto that has done the most unintentional damage to good practice. I have worked with more than one startup that interpreted the manifesto as permission to stop documenting anything at all. The pain that’s caused by a lack of focus on documentation is incalculable. As many organisations look to step into the brave new world of AI, this lack of documentation is causing real headaches - if there’s nothing for a human to understand, there’s nothing the machine can explain.
Documentation didn’t completely disappear of course. The emphasis shifted away from an explanation of context and how the system delivered value into how to deliver the next shiny feature. Technical documentation devolved into Jira tickets. Confluence documents may get written, but rarely read, and even less often updated in line with the system.
Helpful documentation that could be used as a map generally disappeared. Dependencies became transient, forgotten as soon as the software was delivered. Architecture decision records wasted away. Onboarding guides died of unfashionability. The promise that the code was self-documenting or that change control would be sufficient has proved false. You can see how work was tracked and planned. But that doesn’t tell you why a decision was made or how the system actually works. Working software with working levels of documentation may have been a better aim.
Collaboration
The manifesto envisioned teams working closely with customers, learning from them, and adapting based on what they discovered. What many organisations built instead was an elaborate internal negotiation system.
Story points became a currency for negotiation between product “owners” and delivery teams. The sprint itself, originally conceived as a short cycle for learning and adaptation, became a set of commitments.
The product owner role was conceived to bring the customer’s voice into the team. In practice, it often created a buffer rather than a bridge between the team and the customer. Then stakeholders inserted themselves between the product owner and the customer. Stakeholder wants became more pressing than customer needs and the product role changed from understanding problems to administering a backlog. Collaboration gave way to command and control.
Planning
Planning is probably the area that shows how far we’ve failed to come. Organisations adopted agile’s ceremonies but kept waterfall’s expectations. The roadmap is a gantt chart paved with promised features. The annual planning cycle still dictates what gets built. The teams work in sprints, but all that’s really happened is that the waterfall has become a set of rapids.
The manifesto says “responding to change over following a plan.” Most organisations have built elaborate systems for responding to change by updating the plan. The plan is never questioned. It’s just revised, re-baselined, and all too often, is represented as success, regardless of what is delivered, and how the market receives it.
Where’s me jumper?
How did we get here? The manifesto was written by practitioners. It was written for the people doing the work. The consulting industry repackaged it, created certifications, and sold “transformations” to organisations, marketing faster delivery while disregarding the cultural changes needed to lead to it.
Something the manifesto doesn’t explicitly state but probably should have: the organisation that learns fastest wins. Not the one with the best plan. Not the one with the most rigorous process. The one that treats every cycle as an opportunity to discover something it didn’t know before.
Agile, at its best, is a learning system. Short cycles exist so you can learn what works. Retrospectives exist so you can learn how to improve. Customer collaboration exists so you can learn what’s valuable. Every element of the manifesto points toward an organisation that treats uncertainty not as a problem to be eliminated but as the environment in which it operates.
Every piece of software is, to some degree, an act of invention. It involves creating something that hasn’t existed before, or at least placing it in a new context. This is thrilling and uncertain. Pretending otherwise, pretending that with enough process and enough rigour we can keep the chimerical predictability of waterfall while painting in the colours of agile, makes it so that failure is almost guaranteed.
It’s not agile’s fault. It’s not agile.
Twelve principles
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Who could argue with any of that?
A reminder
This is part of a semi-serious series of words that should be removed from the agile lexicon. Follow the links below for earlier entries.
The only f-word I won’t say: Agile swear words part 1
Commitment-phobia: Agile swear words part 2
My vendetta against the v-word: Agile swear words part 3