The Agile Manifesto: What Happened at Snowbird in 2001 and What the Four Values Really Say

Version note: This post is based on the text of the Manifesto for Agile Software Development written in February 2001, as published on agilemanifesto.org, and on Jim Highsmith's history page on the same site; we use our own wording instead of quoting the manifesto.

Guess First

A new developer on the Bookstore team opens the code to fix a bug in the payment module and finds no explanation at all: the README is empty, there is no documentation for the API (Application Programming Interface), there is no record of why an asynchronous design was chosen. They ask, and the answer is: "We're Agile, we don't write documentation. The Manifesto says so."

Guess: what exactly does the Agile Manifesto say about documentation? "Don't write documentation", "documentation is unnecessary", or something else? And why might the single sentence right below the manifesto's four values be its most important sentence?

Snowbird, February 2001

On February 11-13, 2001, 17 people met at the Snowbird ski resort in Utah's Wasatch mountains. All of them represented methods looking for an alternative to heavy, document-driven software processes: XP (Extreme Programming), Scrum, DSDM (Dynamic Systems Development Method), ASD (Adaptive Software Development), Crystal, FDD (Feature-Driven Development) and Pragmatic Programming. The signatories were Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas.

Around 2000 these methods were described as "light" or "lightweight" in articles. According to Highsmith's history, the participants didn't like that label, and Alistair Cockburn objected to it openly. At the meeting the word "Agile" was chosen, the group called itself the Agile Alliance, and the short text we now know as the Agile Manifesto came out of it.

What it was a reaction to lies in the history we saw in the SDLC (Software Development Life Cycle) series. The sequential processes that took hold from the 1980s through contracts and corporate standards demanded comprehensive documents and approvals at the end of every phase. In these processes progress was measured by completed documents, not by working software. What the authors of the Manifesto had in common was not that they advocated the same method, but that they agreed this way of measuring was wrong.

The Structure of the Four Values

The Manifesto consists of four value pairs. Each pair has one thing on the left and another on the right, and the relationship between them is "over", that is, "we prefer". Right below the four values comes the most often skipped sentence of the manifesto. It says that there is value in the items on the right, but they value the items on the left more.

Without this sentence the manifesto reads like a list of prohibitions: no process, no tools, no documentation, no contracts, no plans. With it, it becomes a list of priorities: it tells you which to choose when the two conflict. A good way to tell whether a team is Agile is to look at what it chooses in those moments of conflict.

Individuals and Interactions over Processes and Tools

The first value puts people and the interactions between them ahead of processes and tools. On the Bookstore team, the most concrete test of this is the following: a pull request has been waiting two days for review, because the process requires two approvals and the second approver is on leave. Should the work wait so the process rule isn't broken, or should the author and a reviewer sit side by side for fifteen minutes and go through the code together?

The value doesn't say remove the process. The two-approval rule has a reason, and that reason is valid. What the value says is that when process replaces people talking to each other, something has gone wrong. If a discussion that takes three days as a comment chain in Jira could end with a five-minute conversation, the tool isn't serving its purpose.

Working Software over Comprehensive Documentation

The second value puts working software ahead of comprehensive documentation. Note: not "documentation" but "comprehensive documentation". Misreading this value is the reason for the empty README at the start of this post.

Which documents are still needed on the Bookstore team? The OpenAPI document of the payment API is needed, because the mobile team and partners use it, and since it is generated from code it stays current with the code. An ADR (Architecture Decision Record) explaining the asynchronous payment decision is needed, because the answer to "why?" can't be read from the code. A README explaining how someone opening the project for the first time can run the application is needed. All of these are short, targeted and read.

What is unnecessary is the 80-page design document nobody reads: written at the start of the project, drifted away from the code after the first sprint, and now giving wrong information. Such a document is worse than no document, because it misleads whoever reads it. The essence of the value is in this question: does this document support working software, or does it stand in for it?

Customer Collaboration over Contract Negotiation

The third value puts collaboration with the customer ahead of contract negotiation. The contract still exists; especially when the team and the customer are different companies, it has to. But when the contract replaces collaboration, every question turns into a negotiation: "Is this change in scope?"

Think of the bulk order screen being built for one of Bookstore's corporate customers. In the sprint review the customer sees the screen and wants to be able to paste order lines from Excel. This isn't in the contract. The contract-focused answer is a change request and a price quote. The collaboration-focused answer is to take this new request into the backlog and discuss with the customer which less valuable item to drop in exchange. The second answer is only possible if the contract was written to allow it; how to do this in a fixed-price contract is the subject of the fifth post of the series.

Responding to Change over Following a Plan

The fourth value puts responding to change ahead of following a plan. This value is most often misread as "there is no plan in Agile". Most of the people who wrote the Manifesto came from methods that put great emphasis on planning; XP's planning game and Scrum's Sprint Planning are examples.

The difference is in the role of the plan. The plan is not a contract against which you measure how far you are from change, but your best estimate today. The Bookstore team's quarterly plan contains a reporting feature for libraries. In the second week of the sprint the shipping company announces that it will change the format of its delivery events, and in two weeks the old format will stop working. Following the plan means finishing the reporting feature; responding to change means updating the plan and prioritizing the format change. The second isn't throwing the plan away, it's re-planning.

Production Notes

Turn the values into a decision tool. When a discussion gets stuck, the Bookstore team asks: "Are we choosing the left side or the right side here, and why?" Sometimes the answer is the right side: in a regulated payment integration, comprehensive documentation is a requirement. What matters is that the choice is conscious.

Apply a test to documentation: if a document hasn't been opened by anyone in the last three months or contradicts the code, either update it or delete it. Keep documents close to the code; generate the OpenAPI document from code, keep ADRs in the repo, make the README part of pull request review. The Architecture Decisions series post "Writing ADRs" is a good starting point on this.

You can't measure values, but you can see their symptoms: how long PRs (pull requests) wait for review, the number of days since the last conversation with the customer, the situations in which the team had to say "no" to valuable unplanned work.

Common Pitfalls

Reading the values as "the left exists, the right doesn't" is the most common pitfall. The items on the right weren't banned; the manifesto explicitly says there is value in them too.

The second is thinking the manifesto is a process. The manifesto doesn't tell you what to do, but what to prioritize. A sprint, a stand-up or a board is not a value but a practice; we will unpack this distinction together with common myths in the fourth post of the series.

The third is hanging the values on the wall as slogans and never using them in decisions. The distance between the manifesto on the wall and the reality in the sprint plan is an honest measure of how Agile the team is.

The fourth is reading "customer collaboration" as doing whatever the customer wants. Collaboration goes both ways; the team also tells the customer openly about cost, risk and alternatives.

A Small Experiment

★☆☆ Open agilemanifesto.org and read the whole manifesto; it only takes a few minutes. Write the sentence below the four values in your own words.

★★☆ List the documents in your team's repo. For each, answer this question: does it support working software, or stand in for it? If you find a document that isn't current, update it or delete it.

★★★ Pick three decisions your team made in the last sprint and match each to one of the four value pairs. In which did you choose the item on the right, and was that a conscious choice?

The four values say what to prioritize but not how to apply it. In the next post we move to the second page of the manifesto, the 12 principles, and connect each one to a developer's daily practice: small PRs, feature flags and CI (Continuous Integration).