agile3
Foundations

Agile Manifesto

Four values and twelve principles, written in 2001, that every agile framework still builds on.

2 min read · Beginner

In 30 seconds

  • A one-page statement of priorities, not a method or a process.
  • Written by 17 practitioners at Snowbird, Utah, in February 2001.
  • "Over" means prefer, not replace: plans and docs still matter.

The 4 values

Read each value as a tiebreaker. Both sides matter, but when they conflict, the left side wins.

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

Each one gets a full walkthrough on Agile Values.

The 12 principles, in one line each

  1. Satisfy the customer with early, continuous delivery.
  2. Welcome changing requirements, even late.
  3. Ship working software often: weeks, not months.
  4. Business people and developers work together daily.
  5. Build around motivated people, then trust them.
  6. Talk face to face whenever you can.
  7. Working software is the main measure of progress.
  8. Keep a pace you could sustain indefinitely.
  9. Pay constant attention to technical excellence.
  10. Simplicity: maximize the work not done.
  11. The best designs come from self-organizing teams.
  12. Reflect regularly, then adjust.

Grouped and explained on Agile Principles.

Where it came from

Through the 1990s several "lightweight" methods grew up as alternatives to heavy, document-driven waterfall projects: Scrum, Extreme Programming, Crystal, DSDM and Feature-Driven Development among them.

In February 2001, 17 people behind these methods met at Snowbird, Utah. They did not agree on one method, but they agreed on what the methods had in common, wrote it down on one page, and chose the word agile for it. Signatories included Kent Beck, Ken Schwaber, Jeff Sutherland, Martin Fowler, Ward Cunningham and Robert C. Martin.

Why it still matters

The manifesto is the shared root of almost every agile framework in use today. When a team argues about process, it is a useful tiebreaker: does this choice help us talk more, ship working software sooner, involve the customer, and adapt? If not, the process is serving itself.

Myth vs reality

Myth · Agile means no documentation.
Reality · Write the docs that help ship and run the software; skip the rest.
Myth · Agile means no planning.
Reality · Plan continuously in small steps instead of once, up front.
Myth · Stand-ups and sprints make you agile.
Reality · Rituals without the values is cargo-cult agile.

FAQ

Is the Agile Manifesto a methodology?

No. It is a set of values and principles. Scrum, Kanban and XP are methods that follow it.

What does "over" mean in the values?

A priority, not an exclusion. Both sides have value; the left side wins when they conflict.

Is it still relevant?

Yes. The tools have changed, but the core problem it addresses, building the right thing in a changing world, has not.