
Change Management
16 June 2024
·
3
minute read
What Went Wrong with Agile? An Honest Reckoning
Agile is not dead. But it has been badly misused, cynically marketed, and routinely applied in ways that contradict its own principles. This post opens a series examining what actually went wrong — and why it matters.
BM
Bent Myllerup
Better Change Coach
A recurring claim on LinkedIn holds that Agile is dead. This is nonsense — but the kind of nonsense that contains a signal worth examining. The people making the claim are usually promoting some successor framework, which tells you something about their motives. It does not tell you they are entirely wrong about the symptoms.
Here is the honest version: Agile has become one of the most commoditised, misappropriated, and content-free terms in professional life. When the Danish government agency for agriculture used the word "Agile" twenty-five times in a single job posting, something had clearly gone wrong. That is not an isolated incident — it is a symptom of what happens when a genuinely powerful idea becomes a branding exercise.
Promises kept and promises broken
For several years I have facilitated leadership cohorts at the start of which my co-facilitators and I ask participants a consistent question: of the promises Agile made when your organisation adopted it, which were kept and which were not?
The answers have been remarkably consistent across organisations of different sizes, sectors, and geographies.
What organisations generally report getting: higher transparency, faster decision-making at team level, clearer priorities, and better collaboration within teams.
What they generally report not getting: meaningful customer orientation, self-leading teams, faster time to market, genuine innovation, real empowerment, simplicity, and fewer meetings.
This is a damning scorecard for a philosophy that promised to address all of those things. The good news — such as it is — is that this pattern is not evidence that Agile doesn't work. It is evidence that most organisations have not implemented what Agile actually requires.
Where Agile came from
Understanding why the gap between promise and reality exists requires understanding where Agile actually comes from. The Agile Manifesto — signed at Snowbird, Utah, in February 2001 — is often treated as the origin. It is not. The roots run back further.
The intellectual foundation lies in the 1986 Harvard Business Review article "The New New Product Development Game" by Takeuchi and Nonaka, who studied six leading product development organisations and identified what distinguished their approaches. They described self-organising teams, overlapping development phases, built-in instability as a driver of creativity, and a rugby metaphor — teams moving as a unit, passing back and forth — that would directly inspire the name "Scrum."
What is less commonly noted is that all six of the products Takeuchi and Nonaka studied were mechanical-electrical: photocopiers, cars, cameras, and personal computers. Agile's intellectual roots are in physical product development, not software. The seventeen signatories of the 2001 manifesto were all from the software industry, which is why Agile became so closely associated with software — but that association was contextual, not inherent.
Agile is a paradigm for developing complex products under uncertainty. It does not care what technologies are involved. The implications of this are significant: many of the "Agile for hardware" frameworks that have proliferated in recent years are solving a problem that did not need solving. Agile was never only for software to begin with.
What this series is about
In the posts that follow, I will address specific mishaps: doing it by the book, framework idolatry, the commoditisation of Scrum, the incompetence problem in coaching and training, and the certification circus. My agenda is not to promote a successor framework. I do not have one to sell.
My agenda is to hold up a mirror. The Agile market contains a great deal of snake oil, a significant quantity of religion, and some genuinely excellent thinking and practice mixed in. Separating them is worth doing. The next post is Agile Mishap #1: Do It By the Book.
⬤ INTERESTED IN TRAINING?
View our
Change Management
courses
FLIN (free), FL2D, and FL3D — certified by the Flight Levels Academy.