Agile: Origins and the Manifesto

Agile"Agile" is not a methodology. It's a set of four values and twelve principles, agreed in a weekend by people who mostly ran different, competing methodologies, and who found they agreed on more than they expected. Scrum, XP and Kanban are all compatible implementations of that philosophy, not synonyms for it — which is why this page covers the philosophy on its own before the other pages in this section cover specific frameworks.

Snowbird, February 2001

InIn February 11–13, 2001, seventeen software practitioners met at The Lodge at Snowbird ski resort in Utah's Wasatch mountains¹. They came from several already-existing lightweight methods — Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming — brought together by a shared frustration with heavyweight, documentation-driven processes. The seventeen 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². By the end of the weekend they had produced a short, four-line statement of shared values — the Manifesto for Agile Software Development — and, separately, twelve supporting principles.

It's worth being honest about what the meeting was not: it did not design a process. Several attendees have said in retrospect that the group agreed on values much more readily than they would have agreed on a single method, which is exactly why the Manifesto describes a philosophy rather than prescribing steps.

The Four Values

QuotedQuoted exactly, from the Manifesto itself³:

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.

That last line is the part students most often skip past, and it's the part that keeps the Manifesto from being a straw-man rejection of documentation, tools, contracts or plans. It's a statement of priority under tension, not a permission slip to discard the right-hand column. A team with no documentation, no contract and no plan at all has not chosen "individuals and interactions" — it has chosen chaos.

The Twelve Principles

TheThe principles are the operational detail behind the values, and they are far more specific than most teams remember⁴:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Notice how much of this is about people and feedback loops rather than any specific ritual: daily collaboration (principle 4), short delivery cycles (3), sustainable pace (8), and regular reflection (12) are all process-agnostic. Nothing here mandates a two-week sprint, a stand-up meeting, or a burndown chart — those are choices particular frameworks made when they operationalised the philosophy.

Philosophy vs. Framework

ThisThis is the distinction that gets lost once "agile" becomes a corporate adjective: the Manifesto is a set of values and priorities, not an executable process. Scrum, Extreme Programming and Kanban are three different, quite specific answers to "how do we actually run a project that respects these values" — and they disagree with each other on plenty of details (Scrum's fixed sprints versus Kanban's continuous flow, for instance — see Kanban and Scrum). Conflating the philosophy with any one framework is how you end up with "we do Agile" meaning nothing more specific than "we have a Jira board and a stand-up," which is the failure mode Agile-Inspired Reality examines directly, and which Hybrid Waterfall/Agile treats as often the more honest description of what teams actually run.

See Also

ForFor the sequential model Agile was reacting against — and the genuine irony in its own founding citation — see Waterfall. For the specific frameworks built on these values, see Scrum, Extreme Programming, Kanban and Lean Software Development. For deciding which of these actually fits a given project, see Choosing a Methodology.

References