"Agile Is Dead - Long Live Agile"

August 2025 8 min read Opinion

The word “Agile” has been stretched so far from its original meaning that it has become almost useless. It now means everything – which means it means nothing. And that is a problem worth talking about honestly.

The Hook: A Word That Lost Its Meaning

In February 2001, seventeen software practitioners gathered at a ski resort in Snowbird, Utah. They were frustrated. Not with technology. Not with their clients. With the way software was being built – the rigid processes, the bloated documentation, the disconnect between what customers actually needed and what development teams were being asked to deliver.

They wrote four value statements and twelve principles. They called it the Agile Manifesto. It took them two days.

Twenty-four years later, the word they chose – Agile – is printed on the business cards of consultants who have never written a line of code. It appears in the job titles of middle managers whose primary contribution to software development is attending meetings about attending meetings. It is the subject of a global certification industry worth billions of dollars annually. It is, in short, everywhere.

“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.” The Agile Manifesto, 2001

Read that again. Individuals and interactions over processes and tools. Now look at your organisation. Count the processes. Count the tools. Count the people whose job it is to manage the processes and the tools. Ask yourself, with genuine honesty, whether the balance has shifted.

---

The Reality: What Agile Has Become

Here is what “Agile” means in most organisations today. It means two-week sprints. It means a daily standup that nobody listens to. It means a backlog with 300 items that gets refined every other Tuesday by a Product Owner who does not have the authority to actually prioritise anything. It means a Scrum Master who is primarily responsible for booking the retrospective room and updating the Jira board.

It means, in the language of anthropology, Cargo Cult Agile – the faithful reproduction of rituals whose original purpose has been forgotten, in the hope that the outcomes will somehow follow.

The Numbers Are Damning

The State of Agile Report – the most comprehensive annual survey of Agile adoption – consistently shows that the vast majority of organisations report practising Agile. It also consistently shows that the top challenges in Agile adoption include:

• Organisational culture at odds with Agile values – cited by over 40% of respondents year after year
• Lack of management support – the leadership commitment that the Manifesto’s authors considered non-negotiable
• Inadequate training and education – teams doing Scrum without understanding why
• Resistance to change – the one challenge that no framework, no certification, and no consultant can solve from the outside

Read those challenges carefully. They are not technical problems. They are not process problems. They are cultural and organisational problems. And no amount of sprint planning will fix them.

The uncomfortable truth: Most organisations that claim to be Agile are not. They have adopted the vocabulary, the ceremonies, and the tools. They have not adopted the values. And without the values, the ceremonies are just overhead.

---

The Checksum: What the Manifesto Actually Said

Let us go back to the source. The Agile Manifesto has four value statements. Not frameworks. Not role definitions. Not sprint ceremonies. Four statements about where to place emphasis when the two sides come into conflict:

We value…	Over…
Individuals and interactions	Processes and tools
Working software	Comprehensive documentation
Customer collaboration	Contract negotiation
Responding to change	Following a plan

The Manifesto is explicit: “That is, while there is value in the items on the right, we value the items on the left more.”

This is not a rejection of processes, documentation, contracts, or plans. It is a statement about priorities when they conflict. The question is not whether you have a process. The question is whether, when your process conflicts with what individuals and teams actually need, you change the process or you override the people.

The Twelve Principles Nobody Reads

Behind the four values sit twelve principles. They are less famous than the values – and considerably more demanding. A few that tend to be inconvenient:

• Principle 1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Not valuable documentation. Not valuable roadmaps. Valuable software.
• Principle 4: “Business people and developers must work together daily throughout the project.” Daily. Not in sprint reviews. Not in quarterly business reviews. Daily.
• Principle 5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Trust them. Not monitor them. Not report on their velocity. Trust them.
• Principle 11: “The best architectures, requirements, and designs emerge from self-organising teams.” Self-organising. Not teams that receive tasks from a manager who attended a SAFe training.

Run the checksum: Take Principle 5 – “trust them to get the job done” – and hold it against your current reporting structure. How many layers of approval does a team need to make a technical decision? How many dashboards are their velocity and throughput displayed on? How many people outside the team have access to their sprint burndown? The gap between that principle and your answer is the gap between Agile as intended and Agile as practised.

---

Real-World Examples: The Gap in Practice

I have spent twenty years working in enterprise environments – financial services, pharmaceutical, energy, automotive. I have seen Agile adopted, adapted, misapplied, and abused in more ways than I can count. Here are three patterns I have encountered in almost every large organisation I have worked with.

The Renamed Waterfall

A large financial services organisation decides to “go Agile.” They hire a transformation consultancy. The consultancy delivers a six-month programme that renames their existing project phases as sprints, their existing project managers as Scrum Masters, and their existing steering committees as Product Owners. The Gantt charts are now called roadmaps. The monthly status reports are now sprint reviews. Nothing about how decisions are made, how budgets are allocated, or how teams are staffed has changed. The transformation is declared a success. The problems it was supposed to solve remain.

The Agile Wrapper

A pharmaceutical organisation adopts SAFe to “scale Agile across the enterprise.” Two years and several million euros later, they have a Programme Increment planning event every quarter that takes three days and involves 200 people. Every team has a velocity. Every velocity is reported to management. Every manager is optimising their team’s velocity rather than the value delivered to patients. The ceremonies are running perfectly. The outcomes are unchanged.

The Reluctant Scrum Master

A mid-size software company promotes their most organised developer into a Scrum Master role. They give him two days of training and a Jira admin licence. His actual job – as practiced, not as described – is to schedule meetings, chase people for status updates, and make sure the burndown chart is updated before the Friday report goes to management. He is competent, diligent, and deeply unhappy. He is also not doing anything the Scrum Master role was designed to do.

---

So Is Agile Dead?

No. But the word is.

The values the Manifesto describes – empiricism, collaboration, trust, continuous improvement, delivering value over following process – are not dead. They are harder to achieve than a two-day certification course suggests. They require genuine organisational change, not vocabulary change. They require leaders who are willing to give up control in exchange for better outcomes. They require teams who are willing to take responsibility rather than just follow instructions.

Those things are difficult. They are uncomfortable. They cannot be purchased from a vendor or installed with a framework. And that is precisely why most organisations have opted for the easier version – the ceremonies without the values, the tools without the trust, the vocabulary without the substance.

“Agile is not dead. But most of what is sold, taught, and practised under that name has very little to do with what the seventeen people in Snowbird actually intended.” Markus – agile-checksum.com

What Genuine Agile Looks Like

In twenty years, I have seen it work. Not often. Not easily. But I have seen teams that genuinely self-organise, leaders who genuinely trust, organisations that genuinely respond to change rather than managing it. When it works, it is not impressive in a dashboard sense. There is no metric that captures it cleanly. What you notice is that problems get solved faster, that people are more honest about what is not working, and that the software that ships actually matches what users need.

That is the original promise. It is still worth pursuing. Just do not expect a certification to get you there.

---

The Takeaway

This blog exists because the gap between Agile as intended and Agile as practised is worth documenting, analysing, and arguing about. Not to be contrarian. Not to sell a better framework. But because the problems the Manifesto was written to address – the misalignment between what organisations build and what customers need, the waste generated by processes that serve the process rather than the outcome, the human cost of working in systems that do not trust the people in them – those problems are real, and they are not going away.

The checksum is simple. Take any Agile practice in your organisation. Ask whether it serves the values in the Manifesto or contradicts them. Be honest about the answer. Then decide what to do about it.

That is what this blog is for.

1. Find one ceremony in your organisation that exists primarily to generate a report for management rather than to help the team.
2. Ask why it exists. Ask who it serves. Ask what would happen if you stopped doing it.
3. The answers to those three questions will tell you more about your organisation’s actual relationship with Agile than any maturity assessment ever will.

---

Glossary Terms Used in This Article

• Agile Manifesto – The 2001 document that defined the values and principles of Agile software development.
• Cargo Cult Agile – The adoption of Agile rituals without understanding the underlying principles.
• SAFe – Scaled Agile Framework, the most widely used enterprise scaling framework.
• Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team.
• Agile Transformation – The process by which an organisation attempts to adopt Agile values and practices at scale.