The Agile Manifesto at 20+: What It Got Right, Wrong, and Left Unsaid
Seventeen people in a Utah ski resort in February 2001 wrote twelve principles that would reshape how software is built. Some of those principles aged brilliantly. Others became the seeds of every agile dysfunction we see today.
The Agile Manifesto was written in a specific context: small teams of skilled developers frustrated by heavyweight, document-driven processes that prioritized planning over working software. Its four value statements and twelve principles were a direct reaction to that context. The problem is that agile is now deployed in contexts the manifesto authors never envisioned — large enterprises, regulated industries, distributed teams, hardware-software combinations — and the framework has not always traveled well.
What it got brilliantly right
The manifesto's emphasis on working software over comprehensive documentation remains one of the most important ideas in the history of software engineering. The insistence on customer collaboration over contract negotiation fundamentally changed how product and engineering teams should relate to each other and to users. And the principle of responding to change over following a plan — executed well — gives teams the permission to be honest about uncertainty rather than hiding it behind Gantt charts.
What it got wrong, or at least incomplete
The manifesto is silent on architecture. It is silent on technical practices. It says almost nothing about the organizational conditions — psychological safety, management behavior, incentive structures — that determine whether agile values can actually take root. It assumes a level of team autonomy and trust that many organizations have not developed and may not be willing to develop. And it created, by accident, an industry of certification and methodology that is in many ways antithetical to the adaptive, empirical spirit the manifesto was advocating.
What it left unsaid
The manifesto does not say how to handle the boundary between agile teams and non-agile organizations. It does not address how to scale. It does not talk about what happens when "the business" and "the team" have irreconcilably different incentives. These are not criticisms — a two-page manifesto cannot solve every organizational problem. But they explain why agile transformation so frequently stalls at the team level and fails to change anything above it. The manifesto gave us a philosophy for the team. We are still waiting for a philosophy for the enterprise.
Ready to put this into practice?
Join a SAFe certification course and master agile at scale.
Browse Courses →
