Agile is the most successful failed methodology in the history of software development.
Failed not because it doesn't work — it does, when implemented honestly — but because it's been adopted so comprehensively that the word no longer means anything. Every team is agile now. Every programme has sprints. Every organisation has a transformation story that starts with "we moved to agile."
And yet most of those organisations are still shipping software slowly, with high defect rates, in ways that bear no resemblance to what the Agile Manifesto described in 2001.
What went wrong
The problem is that Agile became a noun when it should have stayed a verb.
Agile-the-noun is a set of ceremonies: standups, sprint planning, retrospectives, demos. You can implement all of them faithfully and still build the wrong thing slowly, with unhappy developers, and no meaningful involvement from the people who actually need the software.
Agile-the-verb is a set of outcomes: fast feedback, working software, continuous improvement, genuine collaboration between the people building and the people using. You can achieve these outcomes with almost any process. You can fail to achieve them while running a textbook scrum.
What we found at a financial services firm
One of our coaching engagements was with a 200-person technology function at a UK financial services firm. They had been "doing agile" for four years. They had a full-time agile transformation team, certified scrum masters across every squad, and a programme management office that tracked velocity across 14 teams.
They were also running 12 sprint ceremonies per fortnight and producing approximately zero working software per sprint. The ceremonies had become the work.
The retrospectives were used to discuss the standups. The standups were used to discuss the sprint planning. The sprint planning was used to negotiate story points in a way that had no connection to actual complexity. The demos showed stakeholders things that had not yet been tested.
The velocity number — the one the PMO tracked — went up every quarter. No senior stakeholder had seen a working feature in eleven months.
What we changed
We didn't introduce a new methodology. We asked three questions in every team, every sprint, without exception:
- What is the one thing that absolutely must work by the end of this sprint?
- Who will test it, and when?
- What will we do differently next sprint based on what we've learned?
That's it. No new ceremonies. No new roles. No certification programme. Just an insistence that each sprint ended with something that worked, tested by a human being, and a documented decision about what to change.
Within six weeks, two of the fourteen teams were consistently shipping working features. Within four months, eight were. The ceremony count dropped by 40%. Developer satisfaction scores — which we measured at the start and end of the engagement — improved by 28 points.
What "agile coaching" actually means
The coaching work isn't teaching people what a sprint is. They know. It's helping teams and leadership rediscover why the sprint exists: to create a regular rhythm of working software, real feedback, and genuine learning.
When you do that, agile stops being a set of boxes to tick and starts being a way of working that makes delivery faster and more honest. That's what the Manifesto was about. It's still right.
If your agile transformation has produced more ceremonies than outcomes, let's talk.