The Agile Manifesto is a short, plain-language document published in February 2001. Seventeen software developers met at a Utah ski lodge and agreed on four values and twelve principles that put working software, collaboration, and adaptability ahead of paperwork and rigid plans. The full text fits on a single page, yet it has shaped how millions of teams ship products today.
What makes the manifesto useful is its honesty. It does not say documentation, contracts, or plans are useless. It says when you have to choose, lean toward people, working code, customers, and change. That tiny shift in emphasis launched agile software development and a whole family of frameworks like Scrum, Kanban, XP, and SAFe.
If you are studying for a certification, leading a transformation, or just trying to make sense of why your team runs sprints, the manifesto is the right starting point. Read it once, then read it again with your team. The conversation matters more than the memorization.
The manifesto opens with four value statements. Each follows the same shape: we value X over Y. Both items have worth, but the left side wins when you cannot have both. That structure is what most readers miss on first pass.
Individuals and interactions over processes and tools. A great tool will not save a team that does not talk to each other. Conversation finds problems faster than any ticket queue.
Working software over comprehensive documentation. A 200-page spec proves nothing. A running build that a real user can click proves everything. Write the docs you need, not the docs that look impressive.
Customer collaboration over contract negotiation. Fixed-scope contracts assume you know what the customer wants on day one. You almost never do. Sit beside the customer and adjust as you learn.
Responding to change over following a plan. Plans go stale. Markets shift. Tech changes. The team that can pivot in a two-week sprint beats the team locked into a 12-month roadmap.
By the late 1990s, software teams were drowning in heavyweight methods. Waterfall, RUP, and document-driven processes promised predictability but delivered late, over-budget, and often wrong. Several practitioners had already invented lighter alternatives: Scrum, Extreme Programming, Crystal, DSDM, Feature-Driven Development, and Adaptive Software Development. They all worked, but each had its own vocabulary.
Kent Beck, Martin Fowler, Ward Cunningham, Robert Martin, and others decided to compare notes. Seventeen of them met February 11–13, 2001 at The Lodge at Snowbird in Utah. They expected to argue. Instead, they found broad agreement on what mattered. Two days later they had a manifesto, a website, and a name: Agile. The word was chosen because it captured adaptability without being tied to any single method.
Kent Beck, Ward Cunningham, Ron Jeffries, Robert C. Martin, James Grenning. Brought test-first development, pair programming, and continuous integration to the table.
Jeff Sutherland, Ken Schwaber, Mike Beedle. Contributed the sprint cadence, the product backlog, and the daily stand-up that most teams now use.
Alistair Cockburn and Arie van Bennekum. Emphasized human factors, communication, and fitting the method to team size and project criticality.
Martin Fowler, Andrew Hunt, Dave Thomas, Brian Marick, Steve Mellor, Jim Highsmith, Jon Kern. Helped articulate the principles in language any developer could use.
The four values get the headlines, but the twelve principles do the heavy lifting. They translate values into daily behavior. If a team says it is agile but ignores the principles, the badge is fake. Below is a working summary of each principle, grouped by the practical question it answers.
Principle 1. Satisfy the customer through early and continuous delivery of valuable software. Ship something useful in weeks, not quarters.
Principle 2. Welcome changing requirements, even late in development. Late changes are a competitive advantage when you can absorb them.
Principle 3. Deliver working software frequently, every two weeks to two months, with a preference for the shorter timescale.
Principle 4. Business people and developers must work together daily. Hallway conversations beat email threads.
Principle 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Principle 6. Face-to-face conversation is the most efficient way to convey information. Video counts in distributed teams.
Principle 7. Working software is the primary measure of progress. Burndown charts and status reports come second.
Principle 8. Sustainable pace. Sponsors, developers, and users should be able to maintain a constant pace indefinitely. Crunch is a warning sign, not a strategy.
Principle 9. Continuous attention to technical excellence and good design enhances agility. Sloppy code slows the next sprint.
Principle 10. Simplicity, the art of maximizing the amount of work not done, is essential. Ship the smallest thing that solves the problem.
Principle 11. The best architectures, requirements, and designs emerge from self-organizing teams. Hand a team a goal, not a blueprint.
Principle 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior. The retrospective is non-negotiable.
Twenty-five years after Snowbird, the manifesto has not been updated. That is intentional. The signatories have repeatedly said the values are durable, even as practices evolve. New frameworks arrive every few years, but each one traces its lineage back to those four sentences.
For modern teams, the manifesto matters in three ways. It gives a common language across roles. A product manager, a developer, and an executive can all point to the same words and check whether a decision aligns. It provides a tie-breaker. When schedules slip and someone wants to skip the retrospective, the principles remind the team what they signed up for. And it is short enough to actually read. Most corporate playbooks are not.
If you are preparing for a certification exam, expect questions on the four values, the twelve principles, and the signatories. PMI-ACP, PSM I, and CSM exams all reference the manifesto. Memorize the four values verbatim. Paraphrase the principles in your own words, but be ready to map each one to a real team behavior.
Reading the manifesto is easy. Living it is hard. Start with one value per quarter. If your team struggles with status meetings that produce no decisions, lean into individuals and interactions. Replace one weekly status meeting with a working session where everyone has a laptop open and a real problem to solve. Measure the difference in cycle time.
If your customer feels far away, ship something to them every two weeks, even if it is rough. Customer collaboration cannot happen without contact. Build a feedback loop, not a contract. Use light prototypes, screen recordings, or staging links. The point is the conversation, not the polish.
If your roadmap is rigid, run a quarterly replanning session and explicitly ask what changed in the market, the tech, and the team since last time. Responding to change requires planned moments of change, not chaos. The transformation work is mostly cultural, not procedural.
Once the manifesto clicks, pick one framework and try it for a full quarter. Scrum gives you a tight calendar of sprints, planning, review, and retrospective, which is helpful when a team needs structure. Kanban is lighter, focused on flow and limiting work in progress, which suits teams with unpredictable demand. Scrum tends to be the most common entry point because the rules are explicit and the certifications are widely recognized.
For organizations with many teams, look at scaled frameworks. SAFe is the most popular at the enterprise level, with structured roles for portfolio, program, and team layers. LeSS keeps Scrum almost intact but adds coordination patterns. Spotify-style squads and tribes are popular but less of a framework and more of an operating model. Choose based on how much structure your culture can absorb.
Whatever framework you pick, keep returning to the manifesto. When a ceremony feels pointless, ask which principle it serves. If the answer is none, change the ceremony. If the team is grinding, check the sustainable pace principle. The manifesto is not a relic. It is a working compass.
The first value, individuals and interactions over processes and tools, is the one most leaders quote and most teams miss. Tools are easy to buy. Interactions are harder to engineer. You can install Jira, Slack, GitHub, and a dozen plug-ins and still have a team that does not understand the product they are building. The fix is not another channel. It is dedicated time where humans actually talk, ideally with a real problem on the table. Pair programming, mob design sessions, and customer demos all serve this value far better than buying the next tool in the trend cycle.
The second value, working software over comprehensive documentation, has been the most misunderstood. The signatories did not throw away docs. They threw away docs that nobody reads. A short architecture decision record, a one-page onboarding doc, and a clear API reference are all forms of documentation that support working software. A 300-page requirements binder written before a single line of code is the kind of document the manifesto rejects. Test it like this: if you deleted the document tomorrow, would the team notice within a week? If no, the document was theater.
The third value, customer collaboration over contract negotiation, applies even to internal teams. Treat the requester as the customer. Sit with them. Walk through screens. Ask what they would skip if the deadline shrank by half. Contracts and statements of work still exist in agile shops, but they are framed as starting points, not finishing lines. Outcome-based contracts and incremental delivery contracts have grown specifically because the old fixed-scope model collapses the moment requirements move.
The fourth value, responding to change over following a plan, is the one most agile teams misuse. Responding to change does not mean abandoning all planning. It means planning at multiple horizons. Roadmaps look six to twelve months out and are deliberately fuzzy. Quarterly objectives are sharper. Sprint plans are sharp and committed. The sprint-level plan can absorb day-to-day discovery. The roadmap can absorb quarterly pivots. The difference between agile and chaotic is exactly that: planned cadence for re-planning.
Watch for these anti-patterns. The fake stand-up where each person reads a status report to a manager is a violation of principle four and principle five. The retrospective that always ends with the same complaints and no action items violates principle twelve. The two-month sprint that everyone calls a sprint is not agile, it is a mini-waterfall with the wrong label. The roadmap that locks scope, time, and cost simultaneously violates principle two. Naming these patterns honestly is the first step to fixing them.
Another pattern is the heavyweight tool stack used to enforce process compliance instead of conversation. When your weekly cadence is dominated by updating ticket fields rather than talking about the work, the tool is winning and the team is losing. Strip the tool back to the minimum that still gives transparency, then put the saved time into actual collaboration. Many teams find that one well-run board, a shared backlog, and a single channel for async updates beats a dense matrix of dashboards.
If you are introducing the manifesto to people who have never read it, do not lecture. Hand them the one-page document and give them ten minutes. Then ask each person to underline the phrase that most surprised them and the phrase they most agree with. The first conversation always reveals where the team really stands. Some people will love the simplicity. Others will worry that it gives cover for sloppy work. Both reactions are useful and both can be addressed by walking through the twelve principles together.
For new hires, pair the manifesto with one concrete artifact from your current sprint. Show them the actual backlog, the last retrospective notes, and a recording of the most recent demo. Connect each item back to a principle. This grounds the abstract values in real team behavior and helps the new joiner spot where your team is strong and where the rituals have drifted from the spirit of the document.
The manifesto predates DevOps, cloud-native development, microservices, and modern AI tooling, yet it slots cleanly into each of them. Continuous delivery is principle one in action. Trunk-based development supports principle ten by minimizing the work of integration. Site reliability practices serve principle eight by protecting the team from unsustainable on-call rotations. Even the rise of AI-assisted coding tools fits the manifesto, because they remove rote work and free engineers to spend more time on the design conversations the manifesto values most.
When teams adopt new engineering practices, the test is the same as it was in 2001. Does the practice produce working software faster, give customers earlier feedback, support sustainable pace, or improve collaboration? If yes, the practice is agile. If it just adds ceremony without those outcomes, the team should retire it. The manifesto is a permanent filter for new ideas, not a museum piece.
The manifesto values working software over comprehensive docs, but explicitly says the right side has value too. Useful docs survive.
Responding to change beats following a fixed plan, but agile teams plan at multiple horizons. The change is the cadence, not the absence of planning.
The manifesto is silent on org charts. It calls for collaboration across roles, not the elimination of management.
Many teams print the manifesto and pin it near their workspace, physical or virtual. That small act creates a reference point. Whenever a decision feels off, someone can stand up and read the relevant sentence. Over time, the language of the manifesto becomes the language of the team. People start asking is this the smallest version of the change, are we collaborating with the customer this sprint, what did the last retrospective surface, and is our pace sustainable. Those questions, asked weekly, are what separate teams that practice the manifesto from teams that merely quote it.
To understand why the manifesto landed when it did, it helps to look at the decade before. Through the 1990s, the dominant software lifecycle was waterfall, where requirements were frozen, design was specified, code was written, and testing came at the end. Large projects routinely ran years late and millions over budget. The Standish Group's Chaos Report, first published in 1994, found that more than 80 percent of software projects were challenged or outright failed. Something had to give.
By the late 1990s, several practitioners had quietly invented lighter approaches. Kent Beck published Extreme Programming Explained in 1999. Ken Schwaber and Jeff Sutherland had been refining Scrum since the mid-1990s. Alistair Cockburn was developing the Crystal family. Each method was different, but each shared a bias toward short cycles, customer involvement, and adaptive planning. The Snowbird meeting was the first time these inventors compared notes in the same room and discovered just how much they agreed on at the level of values.
One of the strengths of the manifesto is its restraint. It says nothing about company structure, team size, hiring practices, performance reviews, or vendor management. It says nothing about specific tools or programming languages. It does not endorse any single framework. That deliberate silence is what has let the manifesto outlive the specific methods that gave it birth. A team using Scrum, a team using Kanban, and a team using their own homegrown process can all claim the manifesto if their behavior matches the values.
The silence also forces hard conversations. The manifesto will not tell you whether you should split your team in two, hire a project manager, or buy a new tool. You have to work it out by mapping your situation back to the values and principles. That can feel frustrating to people who want a recipe. It is a feature, not a bug. The manifesto trusts the team to think.