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.
More than two decades later, the Agile Manifesto remains one of the most consequential documents in the history of software development. A 2023 survey by the Project Management Institute found that 71 percent of organizations report using Agile approaches sometimes or always. The Association for Project Management's 2022 survey found Agile as the dominant delivery methodology in technology-intensive industries. What began as a philosophical statement by a group of practitioners has become the organizing framework for how most software teams think about their work.
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. The report's findings were widely circulated and contributed significantly to the sense of crisis in the industry.
Subsequent CHAOS Reports tracked modest improvement through the 2000s but continued to show the fundamental instability of large, sequential software projects. The 2015 report found that projects using Agile approaches were three times more likely to succeed than projects using Waterfall methods -- one of the most-cited data points in the case for Agile adoption.
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 manifesto's creation story is notable not just for who was in the room but for how it was produced: collaboratively, in two days, without lengthy specification or planning. The process itself demonstrated the values it was articulating. Alistair Cockburn later described the meeting as "17 people who by all rights should not have agreed on anything agreeing on something" -- a reflection of how strong the shared frustration with the status quo was.
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.
Research published by DeMarco and Lister in Peopleware: Productive Projects and Teams (1987, updated 2013) supported this observation empirically: in a study of 600 programmers across 92 companies, the best individual performers outperformed the worst by 10:1 on productivity measures, and the differences were primarily explained by environmental and organizational factors -- not tools or process. The highest-performing teams were characterized by low interruption, high autonomy, and strong interpersonal trust.
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.
The distinction matters because documentation that precedes code is inherently speculative -- it describes a system that doesn't yet exist, and will inevitably diverge from reality as the code is written. Documentation written after working code is verified against actual behavior and is proportionally more accurate and useful.
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.
This value has significant implications for procurement and contracting. Government agencies and large enterprises accustomed to fixed-price, fixed-scope contracts have had to develop new contracting models -- time and materials contracts, outcome-based contracts, or value-based pricing -- to enable Agile ways of working within institutional frameworks designed for Waterfall.
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.
Eric Ries's later work in The Lean Startup (2011) provided a complementary framework for this value: the concept of the pivot -- a structured change in strategy based on learning -- formalized the idea that changing course based on evidence is not failure but intelligence.
The 12 Principles
The manifesto's twelve principles elaborate on the values with more specific guidance. 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.
The principle underpins the entire modern continuous delivery movement. Teams that can deploy to production multiple times per day can validate assumptions with real users almost immediately. According to the 2022 State of DevOps Report (DORA), elite-performing teams deploy on demand (multiple times per day), compared to low-performing teams that deploy between once per month and once per six 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.
Jeff Sutherland, one of Scrum's co-creators, documented in his 2014 book Scrum: The Art of Doing Twice the Work in Half the Time that teams using two-week sprints with continuous feedback loops regularly achieved productivity improvements of 300-400 percent over teams using traditional methods, as measured by features delivered per unit of time.
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.
This principle gave rise to the role of the Product Owner in Scrum -- a designated individual responsible for representing customer and business needs to the development team, available for questions, and empowered to make prioritization decisions without lengthy escalation chains.
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.
Daniel Pink's research, synthesized in Drive: The Surprising Truth About What Motivates Us (2009), provides empirical support for this principle: for complex cognitive work, intrinsic motivation (autonomy, mastery, purpose) is more effective than extrinsic motivation (bonuses, supervision, deadlines). Software development is unambiguously complex cognitive work.
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.
Research by GitLab (2021) and Buffer (2023) consistently finds that distributed teams experience higher cognitive load from communication overhead than co-located teams, but also higher satisfaction with work autonomy -- suggesting tradeoffs rather than a clear winner. The COVID-19 pandemic forced a global experiment in remote software development and demonstrated that distributed Agile teams could function effectively, if with adaptations.
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.
This principle directly challenges vanity metrics -- activity measures that correlate poorly with outcomes. A team that closed 150 tickets in a sprint but shipped nothing that works has made no progress by this measure.
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.
The research on software developer burnout has grown substantially since 2001. A 2022 survey by Haystack Analytics found that 83 percent of software developers report experiencing burnout, with 81 percent citing overwork as the primary cause. Burnout correlates strongly with elevated defect rates, higher turnover, and reduced innovation -- precisely the outcomes that crunch culture claims to prevent.
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.
Technical debt -- the implicit cost of rework created by choosing a quick solution now instead of a better approach that would take longer -- is the primary mechanism by which teams lose agility over time. Research by McKinsey Digital (2022) found that technical debt consumes an average of 20-40 percent of a typical technology company's engineering budget, and that teams with high technical debt deliver new features 50 percent slower than teams with low technical debt.
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.
YAGNI ("You Aren't Gonna Need It") is the XP practice that operationalizes this principle: do not implement functionality until it is actually needed, not when you predict it might be needed. Research on software features consistently finds that a significant fraction of features in shipping software are rarely or never used -- estimates range from 45 percent (Standish Group) to 64 percent (Pragmatic Marketing) of features receiving little or no usage.
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.
This principle has been substantially validated by research in organizational psychology. Google's Project Aristotle (2016), a multi-year study of team effectiveness, found that the single strongest predictor of team performance was psychological safety -- the belief that team members can speak up, ask questions, and take risks without fear of punishment. Psychological safety requires genuine team autonomy; teams that are micromanaged develop risk aversion rather than safety.
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 retrospective -- a dedicated meeting at the end of each sprint where the team discusses what went well, what didn't, and what to change -- is one of the most consistently valuable Agile practices. Teams that conduct genuine retrospectives (not pro-forma exercises) improve their processes measurably over time. The challenge is ensuring retrospectives lead to action: a retrospective that identifies problems but produces no changes is a form of organizational performance theater.
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 | Best Suited For |
|---|---|---|---|
| Scrum | Sprints, Daily Standups, Sprint Review, Retrospective | 1-4 weeks | Most product teams |
| Extreme Programming (XP) | Pair programming, test-driven development, continuous integration | 1-2 weeks | Teams needing high code quality |
| Kanban | Visual workflow, work-in-progress limits, continuous flow | Continuous | Maintenance, support, operations |
| Crystal | Team size and criticality determine process weight | Varies | Teams wanting lightweight methods |
| Feature-Driven Development | Short feature iterations, feature lists | 2 weeks | Large teams, feature-centric products |
| SAFe (Scaled Agile Framework) | Scaling Agile to large enterprises | Program Increment (8-12 weeks) | Large organizations |
| LeSS (Large-Scale Scrum) | Scaling Scrum with minimal added process | 2 weeks | Organizations favoring simplicity at scale |
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.
The Scrum Alliance and the Project Management Institute both offer Agile certifications (Certified ScrumMaster and PMI-ACP respectively) that have become common professional credentials. The certification economy has grown substantially: the Scrum Alliance had certified over 1.5 million practitioners by 2023. Critics note that certifications teach the mechanics of Agile frameworks without necessarily transmitting the values that make them work.
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 phenomenon the critics are describing has a name in organizational behavior literature: cargo culting -- adopting the observable rituals of a successful practice without the underlying behaviors and values that make it work. A team that holds daily standups but makes no daily decisions, conducts sprint reviews but acts on no customer feedback, and runs retrospectives that change nothing is performing the ceremonies of Agile without practicing it.
Measuring Agile's Impact
The evidence on Agile's effectiveness is broadly positive but requires careful interpretation.
The DORA (DevOps Research and Assessment) research program, founded by Nicole Forsgren, Jez Humble, and Gene Kim, has produced the most rigorous ongoing measurement of software development performance. Their four key metrics -- deployment frequency, lead time for changes, change failure rate, and time to restore service -- have become industry standards for measuring development effectiveness.
Elite performers on these metrics (a cluster that has grown from 7 percent to 18 percent of teams surveyed between 2019 and 2022) deploy multiple times per day, have lead times under one hour, change failure rates below 5 percent, and restore service in under one hour. These teams are not uniformly using Scrum or any specific Agile framework; they share a commitment to continuous improvement, automation, and the values in the manifesto.
A 2021 meta-analysis by Diebold, Ostberg, Wagner, and Zendler reviewed 44 empirical studies of Agile methods and found consistent positive effects on team satisfaction, customer satisfaction, and product quality, with more mixed evidence on productivity and cost. The authors noted that studies of Agile effectiveness are difficult to conduct rigorously because teams rarely randomly adopt methodologies, creating selection effects.
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.
Shape Up, developed by Basecamp and described in Ryan Singer's 2019 book of the same name, proposes a different rhythm: six-week work cycles (not two-week sprints) with explicit "appetite" budgets rather than estimates, followed by two-week cooldown periods for bug fixing and exploratory work. Shape Up has been adopted by teams that found sprint cadences too rigid and estimation too inaccurate to be useful.
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. Two decades later, with software development more central to human activity than ever -- in medicine, infrastructure, finance, communication, and governance -- those questions are more relevant, not less.
The enduring contribution of the manifesto is not any specific practice but the insistence that process should serve people and outcomes, not the other way around. Organizations that forget this -- that let the framework become the goal -- are not practicing Agile. They are enacting its opposite.
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.
