The Agile Manifesto: Four Values and Twelve Principles, Explained

The Agile Manifesto is a one-page statement written by seventeen software developers in February 2001. It says they value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan, and it comes with twelve principles that turn those values into practice. Below, each value and each principle is quoted exactly, followed by what it means in plain words and what it looks like on a task board, which is where most teams can check whether they are living by it.

If you want the short version of agile first, start with what is agile. This page is the detail.

Where the Agile Manifesto came from

According to the Manifesto’s history page↗ (opens in a new tab), seventeen people met on February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah. They included representatives of Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming, all looking for an alternative to heavyweight, documentation-driven processes. They named themselves the Agile Alliance, and the page records that the fiercest debate beforehand was over the location: Chicago, Snowbird or Anguilla.

The methods came before the Manifesto. The Scrum Guide↗ (opens in a new tab) says its authors developed Scrum in the early 1990s. What Snowbird produced was not a new method but the common ground between existing ones, which is why the Manifesto names no roles, meetings or tools. Here is the whole declaration, reproduced in full as its copyright notice asks:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

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

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

The four values of the Agile Manifesto

Read each value on the Manifesto’s front page↗ (opens in a new tab) as a preference, not a ban. The word is “over,” not “instead of,” and the closing sentence says the items on the right still have value.

1. Individuals and interactions over processes and tools

In plain words: two people talking will sort out more than a better tool or a stricter process. On a board: the board records what was agreed; it does not replace agreeing. If a task has bounced between In Progress and To Do three times, the fix is a conversation, not another field on the card.

2. Working software over comprehensive documentation

In plain words: something that runs tells you more than a description of it. On a board: a card reaches the done lane when the thing works and someone checked it, not when the spec is written. The card holds a short note and a plan, not a forty-page document.

3. Customer collaboration over contract negotiation

In plain words: work with the customer as the work happens, rather than arguing over what was promised at the start. On a board: the customer, or whoever speaks for them, can see the work and comment on cards while they are in progress, so surprises come early and small.

4. Responding to change over following a plan

In plain words: when you learn something, change the plan. On a board: the order of the waiting list changes most weeks, and that is the plan working, not failing. A board whose To Do column has not been reordered in a month is following a plan nobody is checking.

The 12 agile principles, one by one

The principles behind the Agile Manifesto↗ (opens in a new tab) open with “We follow these principles” and list twelve. They were written about software; where your team makes something else, read “working software” as “a working result.”

1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Plain words: the job is getting useful things to customers, early and repeatedly. On a board: something moves to done and reaches a customer every week or two. A done lane that fills up while no customer has seen any of it misses the point.
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” Plain words: a change of mind is information, not a failure. On a board: reordering the waiting list is normal, and a card nobody needs any more is closed rather than finished out of stubbornness.
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Plain words: ship often, and prefer sooner. On a board: cards are small enough to finish in days. A card too big to finish in a week gets split before anyone starts it.
4. “Business people and developers must work together daily throughout the project.” Plain words: the person who wants the thing and the people building it talk every day, not through a handoff document. On a board: questions and answers go on the card as comments, from both sides, where everyone can see them.
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Plain words: put motivated people at the center, give them what they need, and trust them without micromanaging. On a board: people pull the next card from the top of the list themselves, and a blocked card is visible and cleared quickly.
6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Plain words: talk before you write. In 2001 that meant the same room; for a remote team it usually means a call. On a board: the card records what the conversation decided, not the whole conversation.
7. “Working software is the primary measure of progress.” Plain words: count what works, not hours logged or cards opened. On a board: progress is what reached done and was checked, with a note of how it was tested. Twenty cards in progress is not progress.
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Plain words: no heroics, no crunch as a habit. On a board: the in-progress column stays short, and if the same person always holds the most cards, the team rebalances.
9. “Continuous attention to technical excellence and good design enhances agility.” Plain words: clean work is what lets you change direction cheaply later. On a board: cards for cleanup, tests and design fixes get room every week or two, not “when we have time.” Technical debt covers how to keep that list honest.
10. “Simplicity--the art of maximizing the amount of work not done--is essential.” Plain words: the fastest way to finish is to build less. On a board: closing a card you no longer need counts as progress. Prune the waiting list once a month and be ruthless.
11. “The best architectures, requirements, and designs emerge from self-organizing teams.” Plain words: the people doing the work decide how to do it. On a board: the plan on each card is written by the person doing the work, and rewritten as they learn, not handed down.
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Plain words: look back, pick one change, make it. On a board: every retrospective ends with one written change the team can check next time. Sprint retrospective questions has prompts for it.

Four common misreadings

• “Agile means no documentation.” The value says working software over comprehensive documentation. Write the documents someone will read and keep current, and skip the rest.
• “Agile means no plan.” The plan exists; it is just expected to change. Principle 2 welcomes change, which only makes sense if there was a plan to change.
• “Working together daily means a daily meeting.” The principle asks for daily collaboration, which can be comments on a card, a chat thread or a five-minute call. Daily standup covers when a meeting helps.
• “The Manifesto is Scrum.” It predates the Scrum Guide and names no Sprints, roles or events. Scrum, Kanban and XP are ways to practice it (what is Scrum covers the first); agile project management shows a light cadence that uses neither in full.

The principles on a fenbs board

fenbs is a simple task board shared by people and AI assistants, and several principles have a direct home in it. Completed is the done lane, and each task’s test status and test notes say how the work was checked, which is principle 7 written down. A task’s plan is rewritten by whoever does the work (principle 11), and a size from XS to XL, where XL means split it, keeps cards small (principle 3). Customers can join a team board with a role that can see and comment, such as the suggested Client role, which is value 3 without a status meeting.

How your team reads the principles belongs on the Decisions and rules page. “A task reaches Completed only with test notes” or “split anything sized XL before starting it” is a rule decided by a person, and every connected AI assistant reads the rules before it touches the board. History shows who moved what, which is useful evidence at a retrospective. What fenbs does not have: sprints, due dates or a WIP limit setting. Your delivery rhythm lives on your calendar, and a limit on work in progress is a rule you write and keep.