The Agile Manifesto, Reread: Four Values, Twelve Principles

A few years ago I sat in a retro where a team spent forty minutes debating whether the standup should move from 9:15 to 9:45, whether estimates should be Fibonacci or t-shirt sizes, and whether the retro itself should go biweekly. Near the end, an engineer who’d been quiet the whole time asked a question that stopped the room: “When did we last ship something a user touched?” Nobody knew. It had been over two months. Every ceremony in the book, argued about with real energy — and the one thing the ceremonies exist to produce had silently stopped happening.

That team would have described itself as very agile. And here’s the uncomfortable thing: by the only document with any claim to define the word, they weren’t agile at all — and most of what they were doing isn’t even in the document. So it’s worth actually rereading the thing. The Agile Manifesto contains zero ceremonies — no sprints, no standups, no story points, no backlogs — and everything teams call “agile” is a derived practice, which means it decays into ritual the moment it’s severed from the principle that derived it.

The document itself is short. Seventeen people at a ski lodge in Snowbird, Utah, in February 2001 wrote four values and twelve principles and put them at agilemanifesto.org, where they’ve sat unchanged for a quarter century. You can read the whole thing in four minutes. Most people who invoke it never have.

The four values are priority calls, not prohibitions

Every value has the same shape: X over Y. And the manifesto closes the values with a sentence people reliably skip: “while there is value in the items on the right, we value the items on the left more.” That sentence changes everything. These aren’t bans — they’re tie-breakers: when you’re under uncertainty and can’t have both, here’s which one you sacrifice. Read them as prohibitions and you get the strawman agile that gives the movement its bad name. Read them as priority calls and they’re sound engineering judgment, written down.

Individuals and interactions over processes and tools. The misreading: process is bad, tooling is bureaucracy, real agile teams just vibe. What it actually asks: when your process and your people disagree, believe the people. A process is a recording of what worked for some team once; the humans in the room have current information the process doesn’t. The trade is real — less standardization, harder audits, more dependence on the specific people you have. Pay it anyway, the authors are saying, because the alternative — a team executing a process everyone in the room can see is producing the wrong thing — is exactly what the heavyweight methods of the nineties kept producing.

Working software over comprehensive documentation. The most famous misreading: agile means no documentation. What it actually asks: when you must choose what to spend the next week on, running code a user can react to teaches you more than a document predicting what the code will do. The word doing the work is comprehensive — the target was the era’s five-hundred-page specs, written before a line of code, wrong by page thirty, maintained by nobody. Documentation that helps people build and operate the system sits on the right-hand side: still valuable, still worth writing. You’re trading exhaustive up-front description for evidence, not for amnesia.

Customer collaboration over contract negotiation. The misreading: contracts and commitments don’t matter, scope is whatever we feel like. What it actually asks: a contract is a snapshot of what both parties believed at the moment of maximum ignorance — the start. Run the relationship entirely on enforcing that snapshot and you’ll deliver what was specified, and it will be wrong, because building the thing is precisely what reveals what should have been specified. The trade: less protection when the relationship sours, more exposure to a customer who changes their mind expensively. The bet is that an ongoing conversation catches the spec-versus-need divergence while it’s cheap — worth more than winning the eventual dispute about clause 4.2.

Responding to change over following a plan. The misreading: don’t plan. What it actually asks: plan, and then treat the plan as a forecast rather than a contract with yourself. The value assumes a plan exists — you can’t respond to change if you never articulated what you expected instead. What it demotes is adherence as a virtue. A team six months into a plan that new evidence has invalidated faces a genuine choice: the credibility and predictability of staying the course, or the awkward conversation and the better product of changing it. The manifesto says take the awkward conversation. Predictability is worth something; it’s just worth less than being right.

Notice what all four have in common: each one names a tension that doesn’t dissolve, and picks a side for when you’re forced to choose. That’s what makes them principles rather than rules — the same reason principles outlast the frameworks built on top of them: a rule tells you what to do, a principle tells you what to weigh.

Twelve principles — and yes, it’s twelve

Behind the values sits a page almost nobody reads: twelve principles. (Twelve — people misremember it as ten, or conflate it with the four values, which is its own small evidence of how little the source document gets consulted.) Listed flat, they read like a catalog. Grouped, they reveal a coherent model of how software development actually works. Four themes.

Short feedback loops and frequent delivery. The first principle sets the frame: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Then cadence — deliver frequently, “with a preference to the shorter timescale.” Then the sharpest sentence in the document: “Working software is the primary measure of progress.” Not velocity, not points closed, not percent of plan — software that works, in front of someone who can react to it. The whole cluster is one idea: keep the loop between building and learning as short as you can, because every unit of work between feedback points is work done on an unverified assumption. The team in my opening scene had shortened every ceremony loop and let this one — the only one that matters — stretch to two months.

People: trust, motivation, sustainable pace. The second cluster is the one process-heavy adaptations quietly delete. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Face-to-face conversation named as the most efficient way to move information. And the principle I’ve watched more organizations violate than any other: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Indefinitely is a strong word, chosen on purpose. A delivery model that requires a heroic push every quarter isn’t agile by the document’s own definition — it’s a debt scheme, borrowing next quarter’s pace to hit this one’s date.

Technical excellence and simplicity. “Continuous attention to technical excellence and good design enhances agility.” This is the cluster that kills the misreading of agile as “move fast, clean up never” — the authors, several of whom championed test-driven development and refactoring, are saying the opposite: sloppy code is slow code, just on a delay. And then the strangest, best sentence in the document: “Simplicity — the art of maximizing the amount of work not done — is essential.” Not minimizing work; maximizing not-done work. It reframes scope-cutting from a deadline concession into a skill you practice deliberately — every feature you don’t build is code you don’t maintain and complexity your next change doesn’t fight through. The best engineers I’ve worked with treat this as the core craft, and it’s sitting right there in principle ten.

Self-organization and reflection. “The best architectures, requirements, and designs emerge from self-organizing teams” — the claim that the people closest to the problem, given real ownership, will out-design the people organizing them. And the twelfth principle, the one that makes the whole system self-correcting: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Read that carefully, because it’s the closest the manifesto ever comes to prescribing a meeting — and even here, it prescribes an outcome (the team adjusts its own behavior) and leaves the mechanism entirely open. A retro that produces no behavior change satisfies the ceremony and fails the principle. Which brings us to the point.

Everything else is derived — and derived practices decay

Go looking in the manifesto for a sprint. It isn’t there. A standup — not there. Story points, planning poker, backlogs, burndown charts, sprint reviews, the role of Scrum Master, the word “Scrum” itself: none of it. Every one of those is a derived practice — some team’s concrete answer, in their context, to a question the principles pose. The standup derives from face-to-face conversation and short feedback loops. The sprint derives from frequent delivery. The retro derives from principle twelve. Estimation derives from the collaboration and planning values. All reasonable derivations. None of them the thing itself.

The distinction matters because principles and practices fail differently. A principle degrades loudly — you can’t stop shipping working software for two months without someone eventually asking the question that engineer asked. A practice degrades silently, because it keeps happening whether or not it’s producing anything: the standup convenes daily, long after it’s become a status broadcast to a manager; points get estimated with real precision, long after anyone could say what decision the estimate feeds; the retro runs on schedule and adjusts nothing. Severed from the principle that produced it, a derived practice doesn’t stop — it hollows. The motions continue; the mechanism is gone. That’s why “we do all the ceremonies” and “we are agile” are different claims, and why my opening team could be maximally ceremonial and minimally agile at the same time.

The recovery move isn’t to run the ceremonies harder, and it isn’t to burn them all down either. It’s to re-derive: for each practice you run, name the principle it serves, and check whether it still does — in your context, with your team, this year. Sometimes the answer is yes, keep it. Sometimes the honest answer is that the principle would be better served by something smaller, or by nothing at all — and what a team looks like when it derives its own practices straight from the principles, without adopting Scrum or Kanban wholesale, is where this series goes next.

Put it to work

1. Read the actual document. agilemanifesto.org, values and the principles page both — four minutes. Then list every agile ceremony your team runs and mark which principle each one serves. Any ceremony you can’t map to a principle is ritual; any principle with no practice serving it — sustainable pace is the usual orphan — is your real gap.
2. Measure the loop that matters. Compute your team’s actual interval between “code written” and “a real user reacted to it,” in days. Not deploy frequency — feedback frequency. If it’s longer than your sprint, your ceremonies are cycling faster than your learning, and you’re iterating on the process instead of the product.
3. Audit one right-hand side. Pick a value where your team has drifted into the prohibition misreading — usually documentation. Ask: what’s the smallest item on the right-hand side we’ve wrongly cut to zero? One page of operational documentation, one plan worth writing down so you can notice when it breaks. The manifesto says the right side has value; act like it.

Further reading

• The Agile Manifesto and its twelve principles (2001) — the primary source; shorter than most blog posts written about it, including this one.
• Kent Beck, Extreme Programming Explained — the clearest pre-manifesto articulation of the values-then-practices structure, from the author who insisted values come first.
• Martin Fowler, “The New Methodology” (martinfowler.com) — the essay-length case for adaptive over predictive processes, from a Snowbird signatory, and the best account of what the manifesto was reacting against.
• Alistair Cockburn, Agile Software Development: The Cooperative Game — the deepest treatment of the people cluster; software as a cooperative game of invention and communication rather than an engineering process to be controlled.