Your Training Partner
Articles
When Agile Becomes Its Own Problem

When Agile Becomes the Problem It Was Meant to Solve

in Lean / Agile, Management, Agile

A Movement That Lost Its Way

In 2001, seventeen software developers gathered at a ski lodge in Utah and wrote a document that would reshape how the world builds software. The Agile Manifesto was a rebellion against bloated processes, rigid plans and the belief that documentation could substitute for conversation. Two decades later, the rebellion has become an institution. The institution has become a bureaucracy. And the bureaucracy looks remarkably like what agile was supposed to replace.

Computer scientist Erik Meijer declared that "agile is a cancer that we have to eliminate from the industry." Dave Thomas, one of the original manifesto signatories, wrote that the word has been "subverted to the point where it is effectively meaningless." When the founders of a movement disown it, something has gone fundamentally wrong.

The Certification Factory

The first sign of trouble appeared in the certification market. What began as a way to establish baseline knowledge became a revenue engine. A two-day course and a multiple-choice exam could grant someone the title of Certified ScrumMaster. No project experience required. No demonstrated ability to coach a team through conflict, navigate organisational resistance or facilitate a meaningful retrospective.

The result was predictable. Organisations began treating certifications as proof of competence rather than proof of attendance. Hiring managers demanded CSM and PMP credentials as prerequisites for agile roles, confusing the map for the territory. As practitioner Zach Bonaker observed, "people without the knowledge to understand their problem are defining the requirements to solve it."

What Leaders Actually Say

The gap between agile values and organisational reality becomes painfully clear in the words of those leading transformations. A director at an S&P 400 company stated: "We’ve invested far too much in our SDLC and our processes are fine. Agile is about responding to change, not changing." A vice president at a company of twenty thousand employees put it more bluntly: "I need Agile to work with today’s processes and without changing the organisation."

These statements reveal a fundamental misunderstanding. Agile was never a set of practices you bolt onto an existing structure. It is a shift in how people relate to their work, their colleagues and their customers. Adopting standups without adopting trust is theatre. Running sprints without giving teams authority is waterfall with shorter deadlines.

The Catch-22 of Failed Transformations

Failed agile adoptions create a self-reinforcing cycle. A leader who does not understand agile principles hires based on credentials rather than capability. The hire, selected for certifications rather than insight, implements agile as a process framework rather than a cultural shift. When results disappoint, the organisation concludes that agile does not work and either abandons it or doubles down on control. Both responses make the next attempt harder.

Recruiters compound the problem. Unfamiliar with what genuine agile expertise looks like, they filter candidates based on the flawed specifications they receive. The people best equipped to lead a transformation are often the first to be screened out because their experience does not match the checklist.

What the Founders Proposed Instead

The manifesto signatories did not stop at critique. They proposed alternatives. Dave Thomas suggested abandoning "Agile" as a noun entirely. Instead of asking whether an organisation "does Agile," he proposed asking whether its people work with agility: whether they respond to change, seek feedback and improve continuously. The distinction matters. A noun becomes a product to sell. An adjective describes a quality to develop.

Alistair Cockburn distilled the entire philosophy into four words: collaborate, deliver, reflect, improve. No framework. No roles. No ceremonies. Just a cycle that any team can adopt regardless of methodology. Ron Jeffries, another co-author, went further in 2018 when he told developers to "abandon Agile" altogether, arguing that the movement had been co-opted by management and no longer served the people it was designed to help.

Where the Real Work Happens

Genuine agility exists in organisations that never use the word. It shows up in a product team that ships a small feature to ten users before building the full version. It shows up in a project manager who tells a sponsor that the timeline is unrealistic and proposes a reduced scope instead. It shows up in a retrospective where someone says "this process is not helping us" and the team changes it the next day.

These behaviours do not require a framework. They require an environment where people feel safe to experiment, fail and learn. Building that environment is the actual transformation, and it is far harder than installing Jira or sending managers to a two-day certification course.

Three Shifts That Reconnect Practice with Principle

Teams stuck in performative agile can make three shifts that matter. First, replace output metrics with outcome metrics. Story points and velocity measure activity. Customer satisfaction, time to market and defect rates measure value. Second, make retrospectives consequential. If nothing changes after a retrospective, stop holding them. The exercise has value only when it leads to action. Third, involve the people doing the work in deciding how the work gets done. This is the single most violated principle in most agile implementations and the one that matters most.

The agile manifesto was written on a whiteboard in a single afternoon. It took no certifications, no frameworks and no consultants to produce. Reclaiming that simplicity is the most agile thing an organisation can do.

The Rise and Reinvention of the Testing Quadrants
All Posts
Beyond Scrum: Building a Complete Agile Practice