03 · The Agile Manifesto & Principles¶
In February 2001, seventeen software practitioners met at a ski resort in Snowbird, Utah, frustrated with heavyweight, documentation-driven processes (Waterfall taken to a bureaucratic extreme) that were producing late, over-budget software nobody actually wanted by the time it shipped. They produced a short document — the Agile Manifesto — that reads in full as four value statements and twelve supporting principles. It is short enough to read completely in five minutes, and precise enough that misquoting it is one of the most common mistakes in the industry.
The four values, read correctly¶
| We value... | ...over | The common misreading |
|---|---|---|
| Individuals and interactions | processes and tools | "Agile means no process" — wrong; it means process serves people, not the other way around |
| Working software | comprehensive documentation | "Agile means no documentation" — wrong; it means documentation must earn its keep, not become the deliverable itself |
| Customer collaboration | contract negotiation | "Agile means no contracts" — wrong; it means the relationship should stay collaborative even where a contract exists |
| Responding to change | following a plan | "Agile means no planning" — wrong; it means the plan is expected to update as you learn, not treated as fixed truth |
The manifesto's own text makes the caveat explicit and it is the single most important sentence in the whole document:
"That is, while there is value in the items on the right, we value the items on the left more."
Waterfall's plans, documentation, contracts, and tools are not being declared worthless — Agile just refuses to let them outrank the thing they exist to serve.
The twelve principles, grouped by what they actually govern¶
The twelve principles are dense; grouping them by theme makes them memorable and, more usefully, actionable:
| Theme | Principles (paraphrased) |
|---|---|
| Delivery cadence | Deliver working software frequently (weeks, not months); working software is the primary measure of progress |
| Customer relationship | Highest priority is early, continuous delivery of valuable software; welcome changing requirements even late in development |
| Team collaboration | Business people and developers must work together daily; build projects around motivated individuals and trust them |
| Communication | The most efficient method of conveying information is face-to-face conversation |
| Sustainability | Agile processes promote sustainable development — sponsors, developers, and users should be able to maintain a constant pace indefinitely |
| Technical quality | Continuous attention to technical excellence and good design enhances agility |
| Simplicity | Simplicity — maximizing the amount of work not done — is essential |
| Self-organization | The best architectures, requirements, and designs emerge from self-organizing teams |
| Reflection | At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior |
A worked example: applying the values, not just the ceremonies¶
A team adopts Scrum's ceremonies — daily standup, sprint planning, sprint review, retrospective — but keeps behaving like a Waterfall team wearing Scrum's clothes:
| Symptom | Which value is actually being violated |
|---|---|
| The Product Owner writes a 40-page requirements document and refuses to change it once the sprint starts | "Responding to change over following a plan" — the plan has been re-frozen, just inside smaller boxes |
| Daily standup is a status report to a manager, not a sync between teammates | "Individuals and interactions over processes and tools" — the meeting exists but the interaction it's meant to enable doesn't |
| The team stops updating design docs entirely because "Agile means no documentation" | "Working software over comprehensive documentation" — this is the specific over-correction the values explicitly warn is a misreading |
| Retrospectives happen but nothing from them is ever actually changed | "Reflect... then tune and adjust behavior" — the ceremony is present, the principle behind it is not |
This is the most common failure mode you'll see in real organizations: they adopt Scrum's mechanics (the meetings, the board, the sprint length) without internalizing the values those mechanics exist to serve, and end up with all the meeting overhead of Agile and none of its actual benefit. Recognizing this pattern — "process without the values behind it" — is one of the most useful diagnostic skills in this entire course.
How It Actually Works¶
"Cargo cult Agile" — ceremonies with none of the intended effect — isn't a mysterious failure. It happens because each ceremony is a proxy for a mechanism, and copying the proxy without the mechanism produces the same schedule with none of the outcome.
Why "responding to change" requires a cost structure, not just an attitude. Waterfall makes late change expensive because so much sequential work depends on early decisions (see Module 02). Agile makes late change cheap by structurally limiting how much depends on any one decision: a two-week sprint means the most that can be "wrong" and need rework is two weeks of work, not six months. A team that keeps two-week sprints but writes a fully locked backlog for the next six months has kept the timebox and discarded the actual mechanism — they've reintroduced Waterfall's dependency chain inside a Scrum calendar, so "welcoming change" has nothing cheap left to welcome it into.
Why face-to-face conversation is a bandwidth argument, not a lifestyle preference. Written specs can only carry the information someone thought to write down; a live conversation carries tone, follow-up questions, and the listener's real-time confusion signal ("wait, what do you mean by 'category'?") that surfaces a misunderstanding in the room instead of three weeks later in a bug report. A daily standup done as a status report to a manager throws away exactly this mechanism — the two developers who most need to catch each other's wrong assumption about the categorization API are talking at the Scrum Master instead of to each other, so the misunderstanding survives the meeting.
Why "no documentation" is a self-defeating misreading, mechanically. Working software is the measure of progress because documentation can claim anything is done while software either runs correctly or doesn't — it's a harder-to-fake signal. But a team that deletes design docs entirely loses the one artifact that lets someone six months later understand why a decision was made, which forces every future change to be made by guesswork or by re-deriving the reasoning from the code itself — the exact costly rediscovery the manifesto's authors were trying to eliminate, just relocated from "upfront" to "every time someone touches the code later."
Exercise¶
Read all twelve principles in the original manifesto text (search "Agile Manifesto principles" — it's a public, freely available document, and reading the primary source once matters more than any summary). Then pick three principles from the table above that come from different theme rows, and for each one, write one concrete practice a real team could adopt to live it out (not just "communicate more" — something specific, like "the PM and lead developer sit together for the first hour of every day"). Finally, describe one "process without values" failure mode you've personally witnessed or can imagine in a real team, in the style of the worked-example table above.