In February 2001, seventeen software practitioners gathered in a ski resort in Utah and wrote a document that would eventually reshape how a significant portion of the knowledge economy organises its work. They were experienced developers, consultants, and thinkers who had each, independently, concluded that the dominant software development approaches of the time were producing poor results at significant cost.

The Agile Manifesto — two pages of text, four values, and twelve principles — was the result. It is worth reading in full. It is worth reading regularly.

The four values

The four values are organised as preferences rather than absolutes. The manifesto is explicit: "while there is value in the items on the right, we value the items on the left more." This framing is important and often misunderstood. The manifesto does not say that processes and tools are worthless, or that documentation should be eliminated. It says that in a trade-off, individuals and interactions should take precedence.

Individuals and interactions over processes and tools. Processes and tools matter, but they exist in service of the people using them. When processes start serving themselves rather than the people who need to deliver, they become obstacles rather than support.

Working software over comprehensive documentation. Documentation has genuine value — for maintenance, for onboarding, for compliance. But it is not the product. Working software that solves real user problems is the product. When documentation becomes more important than the thing it describes, something has gone wrong.

Customer collaboration over contract negotiation. Contracts are necessary. Contracts that substitute for ongoing customer engagement tend to produce products that were specified at a fixed point in time and delivered when that specification is no longer accurate. Continuous collaboration keeps the work connected to current reality.

Responding to change over following a plan. Plans are valuable; they create shared understanding and coordination. But plans made at the start of a project are based on the least information the team will have at any point. Rigid adherence to those plans in the face of new information is not discipline — it is stubbornness.

The twelve principles

The twelve principles elaborate on the values and give more specific guidance on how to work. A few are worth highlighting because they are most commonly misapplied.

The principle of delivering working software frequently — with a preference for shorter timescales — is not just about speed. It is about feedback. Short cycles mean that mistakes are caught early when they are small and cheap to correct. Long cycles mean that mistakes compound in the dark.

The principle that the best architectures, requirements, and designs emerge from self-organising teams runs directly counter to the instinct of many organisations to maintain centralised control over technical decisions. It is based on the observation that the people closest to the work are usually best placed to make decisions about the work.

The principle of sustainable pace — that sponsors, developers, and users should be able to maintain a constant pace indefinitely — is probably the most ignored principle in common Agile practice. Sprint after sprint of heroic effort is not Agile. It is waterfall with shorter deadlines.

Why it matters now

The manifesto was written specifically about software development, and some of its language reflects that. But the underlying insights generalise: that people matter more than process, that feedback loops should be short, that plans should serve the work rather than constrain it. These are not time-bound observations. They describe conditions under which complex work reliably goes well.

Revisiting the manifesto is useful for any team that has started to find Agile mechanical or bureaucratic. The ceremonies exist in service of the values. When the ceremonies crowd out the values, the manifesto is a reminder of which way round it is supposed to go.