Agile and Its Misuse

What the Manifesto Actually Says

The Agile Manifesto is short enough to quote in full. Four value statements, each contrasting two things, with a closing acknowledgment that both sides have value but the left is preferred:

— 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 the entire document, plus twelve principles that elaborate it. The document is not a methodology. It does not prescribe ceremonies, certifications, sprint lengths, story-point estimation, or any specific practice. It is a statement of values designed to reorient software development away from the heavy-process waterfall practices of the 1980s and 1990s and toward something that respected the inherently uncertain, evolving, conversation-driven nature of software work. The original authors were emphatic that the values were not exhaustive, that the practices implementing them would vary by team and by project, and that the certification of Agile coaches and the industrialization of Agile delivery were exactly what they were trying to escape.

Scrum and the First Wave of Adoption

The most successful single methodology to emerge from the Agile movement was Scrum, formalized in the early 1990s by Jeff Sutherland and Ken Schwaber and refined in the 2000s. Scrum's prescriptions are minimal: a Product Owner who prioritizes work, a Scrum Master who removes obstacles, a development team that pulls work into time-boxed sprints (typically two to four weeks), and four standard ceremonies (sprint planning, daily standup, sprint review, retrospective). The Scrum Guide is twenty pages. Read seriously, the framework is a useful set of constraints that force teams to deliver working software regularly, to inspect and adjust their own process, and to keep the customer engaged.

Scrum's adoption became enormous through the 2000s and 2010s, partly because it was easier to teach and certify than other Agile methodologies. The certifying organizations — Scrum Alliance, Scrum.org, the various national scrum-master credentials — became substantial businesses. By the late 2010s, multiple million people held some flavor of Scrum certification, and the practices of two-week sprints, daily standups, and story-point estimation had become the default in enterprise software organizations across the world.

How It Went Wrong

The failure mode is consistent and worth naming. Large enterprises adopted Scrum's ceremonies without adopting its underlying values. Sprints became deadlines. Standups became status reports. Retrospectives became performance reviews. Story-point estimation became a way of holding teams accountable to forecast accuracy rather than a way of thinking about uncertainty. The Product Owner became a ticket-translator rather than a customer-facing decision-maker. The Scrum Master became a process enforcer rather than an obstacle-remover.

Worse, the Agile movement spawned a second-order industrialization in the form of frameworks like SAFe (Scaled Agile Framework), DAD (Disciplined Agile Delivery), and LeSS (Large-Scale Scrum), which attempted to apply Agile principles at the level of hundreds or thousands of engineers. SAFe, in particular, became a multi-hundred-million-dollar consulting industry in the 2010s. The framework's diagrams — the Program Increment, the Agile Release Train, the Solution Train, the Portfolio Kanban — are sufficiently complex that they require professional certification to implement, and the result, in many adopting organizations, is a process apparatus far heavier than the waterfall it replaced. Several of the original Manifesto signatories — including Dave Thomas, Allen Holub, and Andy Hunt — have publicly disowned what 'Agile' has become, in essays bluntly titled 'Agile is Dead' or variations.

Team Topologies and the Honest Successor

The most credible modern attempt to recover what Agile was trying to do is Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais. The book argues that the central problem of large-scale software organizations is not how to scale Scrum but how to design team boundaries, communication structures, and cognitive loads so that teams can do high-quality independent work. It identifies four team types — stream-aligned, platform, enabling, complicated-subsystem — and three interaction modes between them, and offers a framework for evolving the team structure as the system evolves.

Team Topologies is closer to the original Manifesto's spirit than SAFe is, in part because it focuses on what makes teams effective rather than on what makes teams comply. Conway's Law — the observation that systems mirror the communication structures of the organizations that build them — is the underlying analytical anchor. The book has been adopted heavily in modern engineering organizations and represents, alongside the work of Nicole Forsgren and the DORA research, the current frontier of honest software-organization design.

What to Do Inside a Failing Agile Adoption

If you are inside an organization where 'Agile' has degraded into ceremonial theater — and many readers will be — there are a few practical moves worth considering. First, return to the Manifesto. Read it. Print it out. Compare what your organization actually does to what the four value statements actually say. The gap is usually instructive in itself.

Second, ask whether the ceremonies are producing working software more frequently and with higher customer satisfaction than the previous arrangement. If they are not — and the DORA metrics are a reasonable empirical test — the ceremonies are theater and should be cut, regardless of how much organizational identity has been invested in them. Third, take the discipline of small, incremental, customer-validated software seriously regardless of what label you put on it. The Manifesto authors were trying to liberate the field from heavyweight process; if your local instantiation of Agile has reintroduced heavyweight process, you are entitled, by the Manifesto's own logic, to walk away from it.

The deeper lesson is one Drucker would have recognized. Frameworks become institutions; institutions become incentive structures; incentive structures attract people whose incentives are served by the framework rather than by the original purpose. Agile is not unique in this trajectory; it is the latest in a long line of management movements that started as liberation and ended as bureaucracy. The next movement will follow the same arc unless the people leading it are unusually disciplined about preserving the original purpose. Most of them will not be.