Agile Manifesto

Software work in the 1990s started with documents and ended with documents. Requirements were locked down across hundreds of pages, signed off, built exactly as written, and shown to the customer only after everything was finished — the waterfall approach, where each stage closes before the next one opens.

The cost sat in the gap between those two ends. A year could pass between the day requirements were frozen and the day anyone saw a working screen, and in that year competitors moved and the customer's situation changed. Folding a change in meant reopening an approved document and going back through sign-off, so most teams spent those weeks building what they already knew was wrong.

The same exchange played out in every meeting room. A customer would describe what they needed now, engineering would answer that it wasn't in the requirements document, and the customer would answer that the document had been right at the time and wasn't any more. Teams that honored the document delivered something useless on schedule. Teams that broke it became the teams that broke their word.

Through the late 1990s, groups working outside that model appeared independently of each other. In February 2001, seventeen of those people met at a ski resort in Utah and came out three days later with this document.

The document has two parts — four sentences of values, and twelve principles underneath them. Every value sentence uses the same shape, "B over A."

1. Individuals and interactions over processes and tools — whether people actually talked to each other counts for more than which procedure was followed.
2. Working software over comprehensive documentation — one screen you can click beats ninety pages of specification as evidence of progress.
3. Customer collaboration over contract negotiation — instead of arguing over who owns a scope change, both sides decide together what is needed now.
4. Responding to change over following a plan — a situation that departs from the plan counts as information rather than as an accident.

One clause sits under those four sentences: while there is value in the items on the right, the items on the left are valued more. That line sets how the rest of the document reads. Nothing on the right gets thrown out, and the ranking applies only when the two sides collide.

The twelve principles push those sentences down to the level of behavior. They group into three sets.

1. What ships and when — deliver working software on a short cycle, and measure progress by working software rather than by percent complete. Iterative development, passing over the same thing repeatedly to sharpen it, and incremental development, adding one usable piece at a time, both come from here.
2. How change is handled — welcome changing requirements even late in development, keep the design simple, and keep technical quality high enough that the next change stays cheap. Code rushed out under schedule pressure destroys the capacity to absorb the next change, which is why these three travel together.
3. How the team is built — give motivated people an environment and trust them with the work, put the roles a release needs in one room so they can talk face to face, and hold a pace the team can sustain. Self-organizing teams and cross-functional teams are named here, and the closing principle, that a team reflects at regular intervals and adjusts accordingly, is where the retrospective gets its basis.

The authors were seventeen individuals, not a company and not a standards body. Each one arrived holding a method of their own, so the ground they could agree on was narrow, which is why the result fits on a single page. That origin sets the document's character: no certifying body, no audit, no revised edition. The 2001 wording is still the wording.

Having no enforcement behind it isn't a weakness, because it works as a reference point when judgment splits rather than as a rule to comply with. Two situations bring people back to it.

1. Someone new asks why the team works this way. A framework like Scrum specifies which meeting happens on which day and who decides what, but never writes down why that order.
2. The team disagrees about method. How much specification to write before starting is not a question taste can settle. A written statement of what the team values more gives the argument something to point at.

"Nobody said stop writing documents. The manifesto itself says there's value in the items on the right."

Bringing the clause back for someone who read only the first half of a value sentence.

"The manifesto never says run two-week cycles. That came from the framework we picked."

Separating a rule that comes from principle from one that comes from a tool. The second kind a team is free to change.

"For this quarter's retrospective, let's pick the one principle out of the twelve we're worst at."

Turning an open-ended improvement discussion into a checklist that already exists.

At Pagedeck the document came up during an argument between Theo and Mia over how long a spec should be. Theo wanted screen mockups and field definitions and nothing more. Mia wanted edge cases written down so nobody would come back asking about them later.

What settled it was the second value sentence. The question moved from "how many pages" to "how much of the spec do we need in order to put a clickable screen out this cycle," and the team agreed to settle edge cases once the screen existed. The document didn't supply the answer. It named what the argument was about.

The most common reading is that the manifesto told everyone to stop writing documentation. The second value sentence circulates with its first half detached, which makes that reading easy to arrive at. What the sentence actually sets is an order of preference for when the two collide, and the line directly below it says the right side has value too. Teams that take the misreading at face value end up with no handover notes and no feature specs, and six months later, once the owner has changed, more time goes into guessing from the code than into building anything new.

The second misreading is that one page is enough to start from. It's short and plainly written, so it feels complete. But nothing in it says how often to meet or how to slice work — Scrum and Kanban own that ground. Taking the framework and skipping the document produces the opposite failure: meeting names and boards all in place, and nobody holding the authority to change the plan. That state has a name of its own, agile in name only.