On a cold February weekend in 2001, seventeen software developers convened at The Lodge at Snowbird ski resort in the Wasatch Mountains of Utah. They represented different methods, different companies, and different philosophies about how software should be built. What they shared was a conviction that the dominant approach — long planning cycles, thick specification documents, and slow sequential processes — was producing bad software, burned-out teams, and frustrated customers.
What they produced over two days was 68 words of values, 12 principles, and a document that would reshape an entire industry.
The Problem They Were Solving
To understand the Agile Manifesto, you have to understand what it was reacting against.
Through the 1980s and 1990s, most software development followed a model borrowed from manufacturing and civil engineering. Waterfall development — the term came from a 1970 paper by Winston Royce, who actually used it as a negative example — organized work into rigid sequential phases: requirements gathering, design, implementation, testing, deployment. Each phase was supposed to be complete before the next began.
In theory, this approach was orderly and predictable. In practice, it produced disasters. Requirements changed during multi-year projects. Customers received what they had specified, not what they needed, because needs evolved while development ground forward. Testing caught problems too late to fix cheaply. Large IT projects routinely came in over budget, behind schedule, or simply failed.
The Standish Group's 1994 CHAOS Report found that 31.1 percent of software projects were cancelled before completion, and 52.7 percent cost 189 percent of their original estimates. Only 16.2 percent were completed on time and on budget.
Several practitioners had developed alternative approaches — Extreme Programming (XP), Scrum, Crystal, Feature-Driven Development — and the Snowbird meeting brought their creators together to find common ground.
The Snowbird Meeting and the 17 Signatories
The meeting was organized by Kent Beck, who had developed Extreme Programming, and facilitated by Bob Hartman. The other attendees included figures who would become influential voices in software development:
- Ward Cunningham — inventor of the wiki
- Martin Fowler — author of influential works on refactoring and patterns
- Ron Jeffries — co-creator of Extreme Programming
- Ken Schwaber and Jeff Sutherland — co-creators of Scrum
- Jim Highsmith — creator of Adaptive Software Development
- Alistair Cockburn — creator of Crystal
- Dave Thomas and Andy Hunt — co-authors of The Pragmatic Programmer
The group debated what to call themselves ("adaptive" nearly won), eventually settling on "agile." They drafted the manifesto collaboratively and posted it at agilemanifesto.org, where it remains today, largely unchanged.
The Four Values
The manifesto's four values are deliberately concise. Each takes the form "we value X over Y" — not "Y has no value," but "X matters more when they conflict."
Value 1: Individuals and Interactions Over Processes and Tools
Processes and tools are useful — they help teams coordinate and maintain consistency. But they become harmful when they substitute for human judgment or become more important than the people using them. A team that enforces a rigid ticket workflow even when direct conversation would solve a problem faster has inverted the proper priority.
The manifesto's authors observed that the best software was built by motivated, skilled people who communicated well — and that no process could substitute for that foundation. Processes should serve the team, not the other way around.
Value 2: Working Software Over Comprehensive Documentation
This value is the most frequently misunderstood. It does not say documentation has no value. It says that hundreds of pages of specification and design documents are not the primary measure of progress. Working software — software that does something useful for a customer — is.
The critique was directed at projects that generated mountains of documentation while producing little working code, and at contracts structured around deliverables that were documents rather than software. If a choice must be made between writing a feature and writing a specification for a feature, write the feature.
Value 3: Customer Collaboration Over Contract Negotiation
Traditional project contracts specified requirements in detail upfront, then bound both parties to that specification. When requirements changed — as they invariably did — negotiating changes became adversarial, expensive, and slow.
Agile methods assume that requirements will change and structure the relationship around managing that change together. This requires a different kind of customer engagement: regular involvement, ongoing feedback, and willingness to adjust direction rather than litigate deviations from an original specification.
Value 4: Responding to Change Over Following a Plan
Plans are not useless. But a plan that cannot be changed when the world changes is an anchor. The manifesto's authors had watched too many projects follow a plan into disaster — continuing to build toward a defined endpoint even when evidence mounted that the endpoint was wrong.
Agile methods embrace change as a feature of software development, not a failure of planning. Short cycles, frequent delivery, and regular retrospectives are designed to make incorporating change cheap and fast.
The 12 Principles
The manifesto's twelve principles elaborate on the values with more specific guidance. Each deserves careful reading, because each reflects a lesson learned from failure.
Principle 1: Continuous Delivery of Valuable Software
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
This principle makes customer value — not technical elegance, not process compliance, not schedule adherence — the north star. "Early" matters: getting working software in front of customers quickly surfaces assumptions that would otherwise go untested for months.
Principle 2: Welcome Changing Requirements
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
This is the most counterintuitive principle for people trained in traditional project management. Change late in development is expensive in Waterfall precisely because the architecture is set, code is written, and the system is nearly locked. Agile methods aim to reduce the cost of late changes through loose coupling, automated testing, and short cycles — transforming change from a threat into an advantage.
Principle 3: Frequent Delivery of Working Software
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
Short delivery cycles do several things simultaneously: they surface integration problems early, they give customers regular opportunities to redirect effort, they create a cadence of accountability, and they reduce the risk of investing heavily in the wrong thing. The shift from six-month releases to two-week sprints is one of the most concrete changes Agile brought to software development.
Principle 4: Business and Developers Must Work Together Daily
"Business people and developers must work together daily throughout the project."
The wall between "the business" and "the technical team" is one of the most reliable sources of failed projects. When developers work for months on a specification written by a business analyst who is no longer available, the result is a technically correct implementation of the wrong thing. Daily collaboration is the antidote.
Principle 5: Build Projects Around Motivated Individuals
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
This principle pushes back against command-and-control management of software teams. Developers who understand why they are building something, who have agency over how they build it, and who are trusted to make decisions produce better software than those who work to detailed specifications under close supervision.
Principle 6: Face-to-Face Communication
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
Written in 2001, this principle has aged into controversy in an era of distributed and remote teams. The underlying insight — that rich, synchronous communication reduces misunderstanding and speeds resolution — remains valid. The question of whether video calls or instant messaging adequately substitute for physical co-location is genuinely open.
Principle 7: Working Software as the Primary Measure of Progress
"Working software is the primary measure of progress."
Not lines of code. Not stories completed. Not tickets closed. Working software — software that functions correctly and delivers value. This principle insists that teams measure what actually matters.
Principle 8: Sustainable Development Pace
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
Crunch culture — extended periods of intense overwork before a deadline — is both harmful to developers and counterproductive to quality. The manifesto explicitly rejects the idea that development teams should be driven to exhaustion at intervals. A sustainable pace, maintained consistently, produces better outcomes than boom-and-bust cycles of heroic effort and burnout.
Principle 9: Technical Excellence and Good Design
"Continuous attention to technical excellence and good design enhances agility."
This principle is often overlooked in discussions of Agile, but it is critical. Agility — the ability to change direction quickly — requires clean, maintainable code. Technical debt, accumulated shortcuts, and poor design choices make change expensive. The manifesto's authors were clear: you cannot be truly agile with a codebase that resists modification.
Principle 10: Simplicity
"Simplicity — the art of maximizing the amount of work not done — is essential."
Build only what is needed. Do not over-engineer for hypothetical future requirements. The simplest solution that works is almost always preferable to a clever, complex one. This principle directly addresses the tendency of developers and product managers to add features, abstractions, and complexity beyond what the current need requires.
Principle 11: Self-Organizing Teams
"The best architectures, requirements, and designs emerge from self-organizing teams."
The manifesto's authors believed that good technical decisions emerge from empowered teams, not from top-down architects or project managers specifying solutions. This does not mean teams have no structure — it means that the people doing the work are best positioned to make decisions about how to do it, and that management's role is to set direction and remove obstacles, not to prescribe methods.
Principle 12: Regular Reflection and Adaptation
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
This is the retrospective principle. Teams should examine not just what they are building but how they are building it, and they should adjust. The process itself is subject to continuous improvement.
The Agile Methods That Emerged
The manifesto was not a methodology — it was a set of values and principles. Several specific methodologies emerged either before or after it, all claiming alignment with agile values:
| Method | Key Concepts | Typical Cycle Length |
|---|---|---|
| Scrum | Sprints, Daily Standups, Sprint Review, Retrospective | 1-4 weeks |
| Extreme Programming (XP) | Pair programming, test-driven development, continuous integration | 1-2 weeks |
| Kanban | Visual workflow, work-in-progress limits, continuous flow | Continuous |
| Crystal | Team size and criticality determine process weight | Varies |
| Feature-Driven Development | Short feature iterations, feature lists | 2 weeks |
| SAFe (Scaled Agile Framework) | Scaling Agile to large enterprises | Program Increment (8-12 weeks) |
Scrum became the dominant implementation, largely because it is specific enough to be teachable and certifiable while remaining flexible enough to adapt to different contexts. A 2023 survey by the Scrum Alliance found that Scrum is used by approximately 66 percent of organizations practicing Agile.
What Went Wrong: The Agile Industrial Complex
Several of the manifesto's original signatories have become its most prominent critics — not of the values themselves, but of what has been done to them.
Ron Jeffries, one of the co-creators of Extreme Programming, published a widely read essay in 2018 titled "Developers Should Abandon Agile," arguing that "Agile as it is practiced in most organizations" has become harmful to developers. He observed that many implementations of Scrum involve heavy management oversight, mandatory reporting, and pressure to estimate and commit to work in ways that strip developers of autonomy — the opposite of what the manifesto intended.
Dave Thomas, one of the original signatories, wrote that "the Agile industrial complex turned Agile into a noun" — a thing to be purchased, certified, and installed — rather than a set of values to be lived. He proposed replacing "Agile" with lowercase "agile" as an adjective describing a way of working, not a branded framework.
Martin Fowler has written extensively about the difference between "agile" as an approach and the "process bureaucracy" that many Agile implementations have become. He argues that the sign of genuine agility is whether a team can respond to change — not whether they conduct standups or use story points.
The critiques converge on a common theme: the ceremonies and artifacts of Agile — sprints, velocity, burndown charts, story points, retrospectives — have become ends in themselves rather than means to the goal of delivering valuable software through motivated, empowered teams.
"The goal of Agile was to produce software that satisfied customers. Many organizations have instead produced processes that satisfy auditors." — paraphrase of a common critique among original manifesto signatories
The Post-Agile Movement
In response to the perceived corruption of Agile, several practitioners have articulated alternative frameworks or updated principles:
Modern Agile, proposed by Joshua Kerievsky, strips back to four guiding principles: make people awesome, make safety a prerequisite, experiment and learn rapidly, and deliver value continuously. It deliberately avoids prescriptive frameworks.
#NoEstimates challenges the practice of sprint commitments and velocity tracking, arguing that the pressure to estimate and commit to scope creates the very rigidity Agile was designed to eliminate.
Continuous Delivery and DevOps movements have, arguably, done more to realize the manifesto's intent than many Agile frameworks — by making the deployment pipeline fast enough that change is genuinely cheap, they create conditions where responding to change is not just valued but structurally enabled.
Why the Manifesto Still Matters
The Agile Manifesto's core insight — that software development is a human, knowledge-intensive activity that responds poorly to industrial management techniques — remains as true as it was in 2001. The specific practices appropriate to any team depend on context, size, domain, and culture. But the values provide a durable framework for evaluating those practices.
A team that asks whether their process serves the people doing the work, whether they are delivering value regularly and frequently, whether they can incorporate change without crisis, and whether they are reflecting and improving — that team is practicing the spirit of the manifesto regardless of what methodology they call their own.
The 2001 meeting at Snowbird did not solve the problem of software development. But it gave the industry a vocabulary and a framework for asking the right questions — and those questions are more relevant, not less, as software becomes ever more central to how the world works.
Frequently Asked Questions
What is the Agile Manifesto?
The Agile Manifesto is a brief document written in February 2001 by 17 software developers at the Snowbird ski resort in Utah. It articulates four core values and twelve principles for developing software in a more adaptive, collaborative, and customer-focused way, as an alternative to heavyweight plan-driven methods like Waterfall.
What are the 4 values of the Agile Manifesto?
The four values are: 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. The manifesto explicitly states that while there is value in the items on the right, the items on the left are valued more.
What are the 12 principles of the Agile Manifesto?
The twelve principles cover continuous delivery of valuable software, welcoming changing requirements, frequent delivery in short cycles, daily collaboration between business and developers, building projects around motivated individuals, face-to-face communication, working software as the primary measure of progress, sustainable development pace, technical excellence, simplicity, self-organizing teams, and regular reflection and adaptation.
What do the Agile Manifesto authors say went wrong with Agile adoption?
Several original signatories, including Ron Jeffries and Dave Thomas, have publicly criticized what they call 'Industrial Agile' or 'Faux-Agile' — the adoption of Agile ceremonies and terminology without the underlying values. They argue that large-scale frameworks like SAFe (Scaled Agile Framework) have turned Agile into a compliance-driven, process-heavy system that contradicts the manifesto's original intent.
Is Agile still relevant today?
Agile values and principles remain highly relevant, but the debate is over implementation. Many organizations have recognized that mechanical adoption of Scrum or other frameworks without genuine cultural change produces bureaucratic overhead without the benefits. The post-agile and modern Agile movements advocate returning to the manifesto's core intent — delivering value through collaboration, trust, and responsiveness — rather than adherence to prescribed rituals.