In 2001, seventeen developers frustrated by documentation-first processes wrote four values and twelve principles that reshaped how software gets built. The founding document of Agile.
▸ Try the interactive toolThe Agile Manifesto is the founding document of modern software development. In 2001, seventeen developers met at a ski lodge in Utah, frustrated by the heavyweight, documentation-first processes dominating the industry. In two days they produced a short statement of four values and twelve supporting principles that reshaped how software gets built.
The Manifesto's genius is its structure: each value is a comparison, not an absolute. “Working software over comprehensive documentation” doesn't say documentation is worthless — it says that when the two compete, working software wins. This is constantly misread as “Agile means no documentation” or “no planning,” which inverts the point. The values express priorities under tension, not prohibitions.
Individuals & interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The right-hand items still have value — the left wins when they conflict.
Most Agile failures trace back to misreading the Manifesto — treating its priorities as absolutes, so “responding to change” becomes “no plan” and “working software” becomes “no documentation.”
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Reading values as absolutes | “No documentation, no planning” — the opposite of the intent. | The ‘over’ structure means the right side still matters, just less when they clash. |
| Process over people | Rigid ceremony adherence while the team disengages. | Valuing individuals and interactions keeps the focus on the humans. |
| Plan-worship | Following an outdated plan off a cliff because it's the plan. | ‘Responding to change’ makes the plan a servant, not a master. |
| Contract mindset | Treating the customer as an adversary to be held to a spec. | Collaboration over negotiation makes them a partner in figuring it out. |
For each of the four, note both sides. The skill is recognising that you're choosing what wins when they conflict — not abolishing the loser.
The four values are headlines; the twelve principles are the practical guidance (deliver frequently, welcome change, sustainable pace, etc.). Use the principles to operationalise the values.
Most teams claim Agile while breaking it — valuing process over people, or worshipping a plan. Find where the practice contradicts the values.
When working software and documentation genuinely compete, or a plan meets new evidence, use the value to decide — deliberately, not dogmatically.
Doing the ceremonies (standups, sprints) without the values is theatre. Anchor the practices back to the four values and twelve principles, or they're hollow.
A team proudly declared themselves Agile and stopped writing documentation entirely — “working software over comprehensive documentation,” after all. Months later, onboarding new engineers was agony, decisions had no record, and the same questions were re-litigated endlessly.
They'd read a priority as a prohibition. The value never said “no documentation”; it said that when documentation and shipping working software compete for time, shipping wins — while still keeping the documentation that actually earns its keep. Restoring lightweight, high-value docs (decision records, API contracts) fixed the pain without making them “less Agile.” The Manifesto had been right; their reading of it hadn't.
The deliverable is shared clarity on the four values as priorities-under-tension — the foundation every Agile practice should trace back to.
| The value | Misreading | Correct reading |
|---|---|---|
| Working software > docs | “No documentation” | Ship first, document what's worth it |
| Responding to change > plan | “No planning” | Plan, but adapt to evidence |
| Individuals > process | “No process” | Process serves people, not vice versa |
| Collaboration > contracts | “No agreements” | Partner with the customer, don't litigate |
The Agile Manifesto isn't a rulebook — it's a set of priorities for when good things compete. Almost every “Agile gone wrong” story is really a story of reading those priorities as absolutes.
The deeper lesson is that the Manifesto describes a mindset, and the ceremonies (sprints, standups, retros) are just one possible expression of it. Teams that adopt the ceremonies without the values get cargo-cult Agile — the ritual without the result. Teams that internalise the values can adapt the practices to their context and still be genuinely Agile. The four values and twelve principles are the thing to anchor to; everything downstream in this module — Scrum, Kanban, Shape Up — is a different attempt to live them out.
‘X over Y’ doesn't abolish Y. The lower-priority side still has real value.
Doing standups and sprints without the underlying values is theatre, not Agile.
“We're Agile” isn't an excuse for no planning, docs, or accountability.
The values are headlines; the principles are how you actually apply them.
The next tool (Tool 02) shows Agile and Waterfall as complementary models, not enemies.
The frameworks in this module (Tools 04–11) are all attempts to operationalise these values.
Every execution practice here should trace back to the four values.
‘Responding to change’ and ‘customer collaboration’ are the delivery-side echo of continuous discovery (Module 3).
Pick one of the four values. Honestly assess: does your team (or one you know) follow its spirit, or has it slipped into the misreading — no docs, no plan, process over people?
Name one concrete change that would realign the practice with the value as a priority, not an absolute.
If your team is ‘Agile’ but breaks a value's spirit, you've likely found cargo-cult Agile — the ceremonies without the mindset that makes them work.