What is agile? The Manifesto's 4 values and 12 principles
In February 2001, seventeen people met at the Lodge at Snowbird, a ski resort in the mountains outside Salt Lake City. According to Jim Highsmith’s history of the weekend, they came to talk, ski, relax, and look for common ground.
They represented Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and a few others. On paper, that’s a room full of competing methodologies. What they shared was a dislike of heavyweight, documentation-driven process.
They left with 68 words.
That’s the whole Manifesto for Agile Software Development. Four lines of values, a sentence before them, a sentence after. You can read it faster than you can find a parking spot at Snowbird.
It took me a while to see what they saw. My first time playing product owner was at Emplify, and it clicked for me when I saw Jeff Patton’s workshop. Frameworks and ideas that had felt disjointed suddenly fit together in a logical way. The 68 words are the short version of that feeling.
Since then, people have written a great many more words about those 68. This is some of them.
The 4 values of the Agile Manifesto
The Manifesto opens with “We are uncovering better ways of developing software.” Uncovering, present tense. Nobody at the lodge claimed to have finished. Then the four values:
- Individuals and interactions over processes and tools. The people doing the work, and how they talk to each other, matter more than the workflow diagram. A good team with a bad tool beats a bad team with a good one.
- Working software over comprehensive documentation. A thing you can run tells you more than a document describing the thing. Documentation is still allowed. It just isn’t the measure.
- Customer collaboration over contract negotiation. Work with the customer throughout, instead of trying to pin every requirement down in a contract before anything is built.
- Responding to change over following a plan. Plans are useful. Being able to change them when you learn something is more useful.
Then comes the sentence almost everyone skips:
That is, while there is value in the items on the right, we value the items on the left more.
This is the part that makes it a statement of priorities instead of a list of banned activities. The Manifesto doesn’t say “no documentation” or “no plan.” It says that when the two collide, you know which one wins. Teams that quote the four lines without the last sentence tend to end up with no plan, and then call that agile.
The 12 principles behind the Manifesto
The values came with twelve principles. These are the working rules. The wording below is the Manifesto’s own, lightly trimmed.
- Satisfy the customer. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver frequently. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Work together daily. Business people and developers must work together daily throughout the project.
- Trust motivated people. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Talk face to face. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Measure working software. Working software is the primary measure of progress.
- Keep a sustainable pace. Sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Pay attention to technical excellence. Continuous attention to technical excellence and good design enhances agility.
- Keep it simple. Simplicity, the art of maximizing the amount of work not done, is essential.
- Let teams self-organize. The best architectures, requirements, and designs emerge from self-organizing teams.
- Reflect and adjust. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Principle 8 says “indefinitely.” It’s worth remembering the next time someone calls a two-week cycle a sprint. We come back to that in our guide to sprints. Principle 12 is the reason retrospectives exist. The 4Ls retrospective is one way to run one.
Who signed the Agile Manifesto
The seventeen original signatories:
- 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
- Dave Thomas
Ken Schwaber and Jeff Sutherland had presented Scrum together six years earlier. If you want the story of how Scrum and Agile relate, it’s in Why Scrum? A product owner’s guide.
What Agile was reacting to
The usual villain is Waterfall: gather every requirement, then design, then build, then test, then ship, each phase finished before the next begins. When requirements really are stable, that works fine. It’s predictable, and it fits nicely on a Gantt chart.
The trouble is that software requirements are rarely stable. Markets move. Customers change their minds once they see the thing. A project planned in full up front can arrive on time, on budget, and wrong.
The paper usually credited with describing Waterfall, Winston Royce’s 1970 “Managing the Development of Large Software Systems,” draws the strict sequence and then calls it “risky and invites failure.” The rest of the paper is about adding feedback loops. The industry kept the diagram and skipped the text.
By the late 1990s, several groups were building those feedback loops on purpose. Kent Beck’s Extreme Programming Explained came out in 1999 and argued for embracing change even late in development. Scrum was already in use. The Snowbird meeting didn’t invent these ideas. It found the sentences they had in common.
Common misreadings of Agile
The most common one is that Agile means the ceremonies. Stand-ups, sprints, and retrospectives are practices from particular frameworks, and none of them appear in the Manifesto by name. A team can hold every meeting on the calendar and still ship nothing a customer asked for. The meetings are there to help deliver value, and they’re easy to mistake for it.
Close behind is the idea that Agile is a methodology. It’s the umbrella. Scrum, Kanban, and XP are ways of working under it, and they disagree with each other on plenty. If you’re weighing two of them, start with how Kanban fits with Agile and Scrum.
The last one is that Agile means working without a plan. See the sentence everyone skips. Responding to change assumes there was something to change.
What Discover Weekly says about trust
Principle 5 is “build projects around motivated individuals… and trust them to get the job done.” Spotify’s Discover Weekly is a decent example of what that costs.
In an interview with Fast Company, Spotify CEO Daniel Ek said of the feature, “I never really saw the beauty of it.” He questioned the team repeatedly, and for a while Spotify didn’t give them any more headcount. They kept working on it anyway and shipped it. He read about the launch in the press and expected a disaster.
It became, in his words, one of the most loved features Spotify has.
The team turned out to be right, which is nice for them. The more useful detail is that the organization left enough room for a team the CEO doubted to keep going. Trust doesn’t always look like enthusiasm. Sometimes it looks like not stopping people.
From doing Agile to learning
Early Agile was mostly about how a team builds: shorter cycles, working software, less paperwork. That part largely won. Two-week iterations are now so normal that they’re sometimes used by teams who have never read the Manifesto.
The harder question moved outside the team. Shipping working software every two weeks doesn’t help if it’s the wrong software. Most of what has grown up since, like customer discovery and outcome-based roadmaps, is aimed at learning what to build before building it. Think of it as principle 12 turned around to face the market, with the team reflecting on the customer as often as it reflects on itself.
What “responding to change” looks like on a board
We plan our own work in CardBoard, on user story maps. The activities run across the top. The work sits underneath, cut into horizontal slices, one per release.
When we built dark mode, the map had three releases: change everything underneath and nothing on screen, then turn it on for our own team, then fix the edge cases and give it to everyone. The first thing dark mode broke was our board backgrounds. A row of pastel backgrounds glowed inside dark menus, so we cut them and replaced them with four.
The plan absorbed it, because it was built in slices. Move a card or re-cut a release, and the rest of the map still tells you where you are.
That’s the fourth value in practice. The plan had value. When the board backgrounds broke, it lost anyway.