The History of the Agile Manifesto

By Victor Hoang · Updated Oct 24, 2026

Picture software work in the late 1990s. Many teams still wrote long requirements documents, signed them off, and built to the plan. A group of practitioners had been getting good results with something different. But they worked under different names, in different books, and sometimes as competitors. They had no common word for what they did. And the word they were stuck with, "lightweight," was one most of them disliked.

The Agile Manifesto was written on February 11-13, 2001, when seventeen software practitioners met at the Lodge at Snowbird, a ski resort in Utah's Wasatch mountains. They represented Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and other approaches. The name "agile" arrived at that meeting. The ideas under it were already decades old.

The throughline is a label that gave scattered methods a shared voice. Short build-and-learn cycles had been practiced since at least the 1950s, and a set of rival "lightweight" methods grew up in the 1990s. Then a few of their leaders met, agreed on four values, and gave the whole family a single banner. This article follows that path. For what the manifesto says and how to use it, read our guide to the Agile Manifesto; here we tell where it came from and where it has gone.

Timeline at a Glance

The Iterative Roots (1950s-1980s)

Short cycles work for decades before anyone calls them agile

Start with a fact that surprises many readers. In their 2003 history in IEEE Computer, Craig Larman and Victor Basili write that some people see iterative and incremental development as the modern replacement for waterfall, but that its practiced and published roots go back decades. They date software's use of the practice to the mid-1950s, and our history of Scrum covers the Project Mercury team and the Bell Labs cycles behind that claim, so we won't repeat them here.

Three pieces of writing connect those early practices to the manifesto. The first is Winston Royce's 1970 paper, "Managing the Development of Large Software Systems." Many people remember it as the origin of single-pass waterfall. Larman and Basili say that reading is incorrect: Royce actually recommended arranging matters so that the delivered version is the second version for the critical design areas, which in his example meant a pilot model before the real project. That is a hint of feedback and adaptation, though Larman and Basili add that it is not classic iterative development. For the full story of how the paper was read, see our history of the waterfall model.

The second is Tom Gilb. His 1976 book Software Metrics introduced the terms "evolution" and "evolutionary" to the process vocabulary, and Larman and Basili call it the earliest book they could find with a clear case for evolutionary delivery. They report that Gilb began the practice in the early 1960s and describe his material as probably the first with a clear flavor of agile, light and adaptive iteration with quick results. In 1988 his Principles of Software Engineering Management described the Evo method: frequent evolutionary delivery, and quantified goals checked after each time-boxed iteration.

The third is Barry Boehm's spiral model, which Larman and Basili date to 1985 in print, with 1986 the more frequent citation. They note it was not the first risk-driven cycle, but that it made risk assessment a distinct step in every iteration.

Be careful about what this proves. These are precursors, not the manifesto, and nobody in these decades called any of it agile. The word "agile" would not attach to software methods until 2001. What the record shows is that the argument inside the manifesto, that building in short, adaptive steps beats a single long pass, had been made in print for over thirty years before Snowbird. Where it had not spread was in everyday practice, and that gap is the problem the next era's methods tried to close.

What this means for teams today: Agile is not a rebellion against everything before it. If you treat it as year zero, you'll miss what older traditions learned about feedback, risk and small releases.

The Lightweight Years (1990s)

Rival methods grow up in separate camps, with no common name

In January 1994, according to Larman and Basili, sixteen rapid application development practitioners met in the UK to define a standard iterative process. Their work became the Dynamic Systems Development Method, or DSDM, which they say had more early advocates in Europe. In the same decade, Jeff Sutherland and Ken Schwaber were refining what became Scrum at Easel Corporation.

In 1996, Kent Beck joined the Chrysler C3 payroll project, and Larman and Basili say the full set of XP practices matured there, with some collaboration from Ron Jeffries and inspiration from earlier work with Ward Cunningham at Tektronix. They add that XP drew public attention for its emphasis on communication, simplicity and testing, and its "interesting name." Martin Fowler's account agrees on the setting: he writes that the roots of XP lie in the Smalltalk community and that it was developed largely on the C3 project.

In 1997, a Singapore logistics project that had been running as a waterfall project was heading for failure. Larman and Basili report that with Peter Coad and Jeff De Luca the team resurrected it as a successful iterative project, and De Luca described the overall process as Feature-Driven Development. Fowler adds that Alistair Cockburn developed the Crystal family of methods. So by the end of the decade there were at least five named approaches, each with its own vocabulary, books and followers.

Fowler's essay "The New Methodology," first published in July 2000, tried to explain the family to a general reader. He contrasts plan-driven methods, whose inspiration comes from civil and mechanical engineering, with adaptive ones that welcome change rather than resist it. He also notes that before "agile" was adopted, these approaches were loosely grouped as "lightweight," a term many practitioners disliked.

That dislike is the key to the next era. The methods agreed on much and disagreed on details, they were sometimes competitors, and the umbrella word available to them said the wrong thing about what they valued.

What this means for teams today: Before Snowbird, "agile" meant nothing in particular, because no single method owned it. When a vendor sells you "agile" today, ask which of these underlying practices it actually includes.

The Snowbird Meeting (2000-2001)

Seventeen people agree on four sentences and a name

The meeting began with a smaller one. The Agile Manifesto's history page says Kent Beck organized a gathering at the Rogue River Lodge in Oregon in the spring of 2000. Fowler's own account says that retreat agreed XP should stand as its own process while sharing common ground with others, and that Bob Martin then arranged the broader meeting. In September 2000, the history page records, Bob Martin of Object Mentor in Chicago started the next meeting rolling with an email.

The location was debated. The history page lists Anguilla in the Caribbean, which was warm but slow to reach, and Chicago, which raised concern about its winter. Snowbird, the Lodge at Snowbird ski resort in Utah, won out. On February 11-13, 2001, seventeen people gathered there: 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, as the signatory list records them.

Two things stand out about how they worked. According to Fowler, the group wanted a document that captured their shared ground and served as a rallying cry. They wrote the statement of values mostly during the meeting, and finished the principles over the following months by email and on a wiki. Dave Thomas later recalled that the initial five points were reduced to four plus an introduction by the end of an afternoon, according to the Agile Alliance's anniversary page.

The name came out of the same meeting. Fowler writes that few in the group liked "lightweight methods," because lightness was only a symptom, and that they settled on "agile" because it captured adaptiveness and response to change. The history page records that Fowler raised the one objection, that many Americans don't know how to pronounce the word. The Agile Alliance's account adds that the group rejected "Lightweight" and considered "Adaptive."

The document itself is short. It opens by saying the authors are uncovering better ways of developing software, then lists four values, each stated as a preference:

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

A closing line says that while there is value in the items on the right, the authors value the items on the left more. That last sentence is often skipped, and it matters: the manifesto never says documents, contracts or plans are worthless. The twelve principles added afterward are plainer still. One says working software is the primary measure of progress, and another calls simplicity "the art of maximizing the amount of work not done".

Not everyone present expected agreement. The history page records that Alistair Cockburn had not expected this group to agree on anything substantive, and that he was delighted with the final wording. After the meeting the authors named themselves the Agile Alliance, and Larman and Basili say that the meeting produced the Agile Alliance and the now-popular phrase "agile methods." The Agile Alliance's own account says Bob Martin recalled the organization being formally created as a legal entity after the Snowbird meeting.

What this means for teams today: The manifesto is a statement of preferences from practitioners who disagreed on details. Use it that way: as a tiebreaker when a process choice is close, not as a rulebook.

The Mainstream (2002-2017)

A shared name spreads the methods well beyond their authors

Once the word existed, books and training followed. Larman and Basili note that in 2002 Alistair Cockburn, one of the participants, published the first book under the new appellation. The same period brought Scrum's training courses and certification route, which our history of Scrum follows in detail. In 2005 the manifesto site collected comments from independent signatories, on a page dated March and April 2005, and Fowler overhauled "The New Methodology" on 13 December 2005 into a survey of agile flavors.

Two things happened to the manifesto's meaning in these years. First, the word moved from a set of practices to a general adjective. Fowler wrote that the term had been hijacked for this movement in early 2001, and he described the manifesto itself as hardly a rigorous definition, though one that gives a focusing statement. Second, the practices attached to it widened. Scrum and XP are the best known, but the same manifesto now sits behind kanban boards, scaled frameworks and enterprise programs. Our articles on the Scaled Agile Framework and Disciplined Agile cover two of the frameworks built to apply agile ideas across many teams, and the history of kanban covers a third tradition that merged into the same toolbox.

The manifesto's first line also began to be tested against a problem its authors could not have fully pictured: organizations that had not chosen the values, but adopted the vocabulary. A team can hold the daily meetings and still never show working software. The manifesto does not enforce its own values.

What this means for teams today: If your company adopted agile by buying a framework, the values were probably not part of the purchase. Check whether decisions at your company still favor individuals and interactions or have drifted back to tools and process.

The Backlash (2018-present)

A signatory tells developers to abandon the word

On May 10, 2018, Ron Jeffries, who was at Snowbird and signed the manifesto, published an essay called "Developers Should Abandon Agile." His argument is that Agile has become big business and that poorly applied versions often hurt developers through more interference, pressure and deadlines. He tells developers to stop tying their thinking to a named method, including Scrum and SAFe, and to focus on practices that work inside any framework: delivering tested, integrated software frequently, keeping the design clean through continuous refactoring, and using working software as the basis for conversations with leadership. He suggests Extreme Programming as a starting point and grounds the argument in the manifesto's values.

Read it carefully. Jeffries is not rejecting the values; he is rejecting what the word has come to mean in organizations. That distinction is the central tension of the modern era. The manifesto asked for individuals, working software, collaboration and responsiveness, and a method wrapped around those words can still deliver the opposite.

The manifesto itself has kept its text. The Agile Alliance now displays a 25 Years of Agile badge and describes the manifesto as written in 2001 by seventeen independent-minded practitioners who found consensus around four core values. The manifesto site still carries the 2001 text under a copyright line crediting "the above authors", and it allows the declaration to be copied in any form, but only in its entirety through the notice.

For the wider picture of how agile sits beside other approaches, see our guides to what agile methodology is, agile versus waterfall and the history of hybrid project management, which follows teams that blend the two. Our evolution of project management methodologies places all of this on one map.

What this means for teams today: Don't argue about whether you're "doing Agile." Ask the manifesto's own question: are individuals, working software, customers and change getting the priority the document gives them?

Key People

Key Facts

Key Facts: Agile Manifesto History

• Seventeen people wrote the Manifesto for Agile Software Development on February 11-13, 2001, at the Lodge at Snowbird, Utah.
• The manifesto lists four values, each stated as a preference, and the group finished its twelve principles in the months after the meeting.
• Larman and Basili trace iterative and incremental development to the mid-1950s in software.
• Tom Gilb's 1976 book is the earliest they found with a clear case for evolutionary delivery.
• The word "agile" replaced "lightweight" at the Snowbird meeting, because lightness was only a symptom of what the group valued.

The Pattern Behind the History

We call this the Name After the Practice pattern. It is our reading of the timeline, not a research result.

1. The practice comes first. Iterative delivery was in use in the 1950s, decades before the name.
2. Rival camps grow. In the 1990s, XP, Scrum, DSDM, Crystal and FDD each built their own vocabulary.
3. A meeting supplies the word. At Snowbird, seventeen people agreed on four preferences and one umbrella term.
4. The label travels faster than the values. After 2001 the word spread through books, courses and frameworks.
5. A founder questions the word. In 2018, a signatory asked developers to drop the name and keep the values.

What It Teaches Teams Today

• Use the manifesto's own wording as a test. The values are short enough to check any process change against them.
• Treat agile as a family, not a single method. The people at Snowbird disagreed on details, and your team can too.
• Keep the right-hand side. The manifesto says the items on the right still have value; plans, documents and contracts are not the enemy.
• Judge progress by working software, as principle seven says, not by how many ceremonies you run. Our guide to agile ceremonies covers what each one is for.
• Know the older traditions. Gilb, Boehm and the 1990s methods did much of the thinking before the banner existed.

For the wider story, read the history of project management.

The Agile Manifesto records a moment when scattered practices got a shared name. Its text has stayed the same since 2001, and the work that remains is making sure the practices still match it.