The Agile Manifesto: Values and Principles

Snowbird, Utah, February 2001

February 2001. Seventeen software practitioners checked into The Lodge at Snowbird ski resort in Utah with no particular expectation of producing anything historic. They came from different methodologies: Extreme Programming, Scrum, Crystal, DSDM, Adaptive Software Development, Feature-Driven Development, and several others. What they shared was a frustration. The dominant approach to software development at the time treated projects like construction contracts. You defined everything up front, documented every requirement, followed the plan, and delivered at the end. The results were consistent, and consistently disappointing. Teams delivered what the specification said, months or years after writing it, and frequently discovered they had built the wrong thing. The customer had moved on, the market had shifted, or the requirements had never been quite right in the first place, and nobody found out until it was too late to do anything about it without enormous cost. Two days of conversation produced the Agile Manifesto: four values and twelve supporting principles. In the two decades since, it has shaped how software teams operate worldwide, and its influence has extended well beyond software into project management disciplines of every kind. You can read the full manifesto in under two minutes. Understanding what it means in practice takes considerably longer, and that gap is precisely where most agile adoptions collapse. The words are not complicated. The implications are.

Four Values — and Why Both Sides Matter

Before introducing the four values, one sentence from the manifesto deserves your full attention: "while there is value in the items on the right, we value the items on the left more." Most agile introductions skip this framing entirely, which sets up a fundamental misreading of every value that follows. The manifesto is not saying that processes, documentation, contracts, and plans are worthless. It is saying that when the two sides come into conflict, the left side wins. That is a statement about priority under tension, not a blanket rejection of anything. A team that reads the manifesto and immediately discards all documentation has not absorbed the values; it has reacted to them impulsively. A team that treats every contract clause as the enemy of good work has misread the third value just as thoroughly as a team that refuses to show a customer anything until formal delivery. The values establish a priority ordering for situations where you cannot have everything simultaneously. Most of the time, you can. You can write a concise specification and still collaborate actively with the customer. You can follow a process and still have the honest conversation that the process cannot have for you. The values tell you what wins when something must give. That context is essential before any of the four values makes sense.

Individuals and Interactions Over Processes and Tools

Imagine a team four months into a nine-month software project. The daily standup has become a ritual of ticket updates. Nobody talks about what is actually happening. The project management tool shows all work as on track. The product, examined honestly, is not on track. Something went wrong in the handoff between two developers six weeks ago, and the conversation that would have surfaced it never happened because both developers filed their status updates in the tracking system and moved on. The process kept running. The project quietly deteriorated. Processes and tools are designed to coordinate work across people and time. They cannot sense when something is wrong. They cannot replace a ten-minute conversation that resolves a misunderstanding before it compounds. People can. The first value places individuals and their conversations above process compliance, and the reason is practical, not philosophical. A team that communicates well will outperform a team that follows process perfectly but never actually talks. This does not mean processes are useless. Well-designed processes protect institutional knowledge, coordinate distributed teams, and create accountability. The point is that process compliance should never become the measure of success, because the moment it does, teams start prioritizing the process over the outcome. They fill out the right fields, close the right tickets, attend the right meetings, and produce the right-looking artifacts. The product suffers while the process looks healthy. Agile teams treat processes as tools in service of a goal, not as the goal itself. When a process is actively preventing the conversation that would solve the problem, the team is authorized to have the conversation.

Working Software Over Comprehensive Documentation

There is a specific kind of project failure that documentation cannot prevent: building the right specification for the wrong product. A two-hundred-page requirements document, perfectly structured and fully signed off, is evidence of thoroughness. It is not evidence that the software will work, that users will find it useful, or that the development team understood what the words on those pages actually meant when they encountered the messy reality of implementation. Requirements documents are translations of what someone wanted into text that another group reads and acts on. Translation loses information. Every layer of abstraction between the person who knows what they need and the person who builds what they need introduces loss, and there is no document long enough or precise enough to eliminate that gap entirely. Working software changes the information flow. A prototype in the user's hands in week three tells you something no specification can: whether the thing being built is actually the right thing. A user interacting with real software, even rough and unpolished software, surfaces requirements that nobody would have thought to write down. Users discover that the workflow they described on paper does not reflect how they actually work. Edge cases emerge. Minds change. All of that is information, and the sooner you have it, the lower the cost of acting on it. The principle here is not that documentation is bad. Brief, targeted documentation helps teams understand the problem, communicate decisions, and meet compliance requirements. The principle is that documentation serves delivery, not the other way around. When a team is producing documentation as a substitute for building something real, it has confused the evidence of work with the work itself.

Customer Collaboration Over Contract Negotiation

The traditional project model treats the customer relationship as a contract problem. You define scope, agree on cost and schedule, get signatures, and then execute. The customer's role ends at signing. They will see the product at delivery. If it does not match what the contract says, there is a dispute resolution mechanism. If it matches what the contract says but is not what they actually needed, that is also a defined situation, usually an expensive and frustrating one for both parties. Contracts protect both sides from each other. They also, in many cases, ensure that both parties spend more energy defending their interpretation of the agreement than solving the customer's actual problem. Customer collaboration replaces that adversarial framing with something more direct: the customer stays inside the process. They see progress regularly, they react to it, they surface new information, and they help the team understand what success looks like as the work unfolds rather than only at the end. This is genuinely uncomfortable for project managers trained to manage scope as a primary control mechanism. If the customer can influence direction throughout the project, how do you protect cost and schedule baselines? The agile answer is that the planning approach itself changes, so that flexibility is built in as a design feature rather than treated as a threat. The customer is not the adversary sitting across the negotiating table looking for specification gaps to exploit. The customer is the person who knows what success looks like, and keeping them outside the process means you are building toward your interpretation of their needs rather than their actual needs. Contracts still exist in agile projects. They are written to accommodate learning rather than freeze it.

Responding to Change Over Following a Plan

Plans are built on assumptions. The longer the planning horizon, the more assumptions are embedded. A twelve-month project plan created in January rests on assumptions about what the market will look like in November, what the team will learn during development, how user needs will evolve, and what the technology landscape will support by delivery. Each of those assumptions can be wrong. Most of them will be at least partially wrong. The plan is a hypothesis about how the future will unfold, and the future rarely cooperates exactly. Traditional project management has change control to handle this reality. You identify a change, assess the impact, route it through an approval process, and update the baseline if approved. That process protects plan integrity, and it is appropriate when the cost of change is genuinely high, when contractual commitments are precise, and when the work is highly predictable. But when a competitor launches a feature your product does not have, or user research reveals that the core assumption driving your design is wrong, the change control process becomes a friction mechanism that slows your response to real information that is sitting right in front of you. The fourth value establishes a priority: when the plan stops serving the goal, change the plan. This is not an argument for undisciplined replanning in response to every new opinion or passing preference. A team that changes direction every week is chaotic, not agile. The value is a statement about authority. The plan serves the outcome. When the plan conflicts with a better understanding of the outcome, the outcome wins. A project manager who cannot revise an approved plan when circumstances have materially changed is not exercising discipline; they are practicing rigidity and calling it professionalism.

Five Principles Worth Living By

The values tell you what agile prioritizes. The twelve principles that accompany them describe what that priority ordering looks like in daily practice. Five of those principles are worth examining in depth, not as items to memorize but as patterns to recognize. These five were selected because they show up most directly in everyday PM decisions; the full set of twelve is available at agilemanifesto.org and worth reading in context. Once you can see these patterns, you will notice both their presence and their absence in any team you work with. You do not need to be running a formal agile methodology for these principles to be relevant. A PM managing a traditional waterfall project who understands these principles will make better decisions about pacing, feedback, and reflection than one who does not. The principles describe conditions for good work. Those conditions are not methodology-specific.

Welcome Change, Even Late

One of the twelve principles states that agile processes are designed to welcome changing requirements even late in development, because a late change based on real learning delivers more value than an early plan built on assumptions. The phrase "even late" is where the principle challenges most project management instincts most directly. Late changes are expensive. Changes in the final stages of a project disrupt completed work, unsettle the team, and threaten delivery dates. The instinctive response to a late change request is to document the impact, protect the baseline, and push back. The principle asks you to ask a different question first: why is this change happening now? A late requirement change is almost always the result of learning. The customer saw a competitor's release. A user test revealed a critical problem with the current design. The business context shifted in a way nobody could have predicted. These events are not failures of planning. No planning process was supposed to predict them, and no planning process can. They represent information that arrived during the project because that is when it became available. Teams designed to absorb change rather than resist it build in short cycles, defer decisions to the last responsible moment, and create feedback loops that surface problems early enough to act on them. A change that arrives late is still less expensive than discovering at delivery that what you built no longer fits the world it was supposed to serve.

Deliver Frequently, Learn Continuously

The manifesto's second principle favors delivering working software in weeks rather than months. The delivery cadence is not a scheduling preference; it is the mechanism through which the project learns. Every delivery is a moment when real information enters the process. The customer sees something working and reacts. The team gets feedback that is grounded in actual product rather than a description of product. Problems that have been growing quietly in the design become visible when something real exists to evaluate. The shorter the time between deliveries, the shorter the time between assumption and correction. A team delivering every two weeks surfaces a wrong assumption in two weeks. A team delivering every six months surfaces the same wrong assumption six months later, by which point the assumption has propagated through everything built on top of it. The cost of correction scales with time, and frequent delivery compresses that time. Short delivery cycles also create something less obvious: a rhythm the whole team can feel. Progress is not abstracted into percentage-complete estimates that may bear no relationship to reality. It is visible in working product that a real user can evaluate. The team knows what they built this week. The customer can see it. That shared visibility changes what problems both parties can identify and discuss together. Frequent delivery is a risk management strategy disguised as a scheduling preference.

Working Product as the Measure of Progress

Working software is the primary measure of progress. This principle directly conflicts with how most organizations track project health. Status reports measure tasks completed, milestones reached, and budget consumed. None of those metrics answer the question that actually matters: is the product working? A team can close every task on schedule, hit every milestone, and spend exactly as budgeted while building something that does not function correctly or satisfy anyone who uses it. Percentage complete, hours logged, and documents approved are proxy measures. They measure effort and process activity, not outcome. The principle redirects the evaluation entirely. Instead of asking "are we on schedule?", you ask "what works today that did not work last week?" Instead of tracking the fraction of tasks marked complete, you track the number of features a real user can actually evaluate. This requires a shared, explicit definition of what "working" means, which agile teams formalize as a "definition of done": a specific, agreed-upon set of conditions a feature must meet before the team considers it complete. When progress is measured in working product, ambiguity disappears. A feature either meets the definition or it does not. A green status report on a project that has not shipped anything a user can touch in three months is not reporting progress; it is reporting activity. The principle insists on the difference.

Sustainable Pace

The manifesto states that agile processes promote sustainable development, with teams maintaining a constant pace that could be sustained indefinitely. This principle seems obvious until you watch what actually happens to project teams under deadline pressure. The schedule slips. The team extends hours. Weekends disappear. The next sprint begins with a team that is already depleted. Quality drops. Defects accumulate. The team that pushed hardest in month three is delivering less in month five than it delivered in month one, and the delivery quality is worse. Sustainable pace is not a concession to comfort. It is a throughput and quality principle grounded in observable team behavior. A team working at a consistent, manageable pace produces more predictable output than a team cycling between heroic effort and recovery. Predictable output is what planning depends on. When velocity swings because the team burns out and rebuilds in cycles, estimates become unreliable. Retrospective data becomes noise. Sustainable pace keeps the signal clean enough to plan against. It also preserves something harder to quantify but equally important: cognitive capacity. Fatigue does not only slow people down; it degrades decision quality. The collaborative, creative thinking that characterizes good project work requires a team with enough reserve to actually think. A team grinding through backlog in survival mode is not solving problems at its best level. It is executing tasks at a diminishing rate while accumulating technical debt and interpersonal friction. Protecting pace protects every other output quality measure alongside it.

Reflect and Adjust at Regular Intervals

The twelfth principle states that at regular intervals, the team reflects on how to become more effective, then adjusts its behavior accordingly. In practice, this is the retrospective: a structured conversation held at the end of each sprint or project phase where the team asks what worked, what did not, and what to change. The answers drive specific adjustments to how the team operates. This is process improvement embedded in the delivery cadence rather than delegated to an external quality function that reviews the project after it is over. The retrospective principle is the most transferable idea in the entire manifesto. You do not need sprints, a product backlog, or any specific agile framework to hold a structured reflection. Any team, running any kind of project with any method, gets better faster when it creates a regular moment to examine its own process honestly. The teams that consistently skip retrospectives cite the same reason: they are too busy delivering to stop. This is almost exactly backward. Teams that skip reflection because they are too busy are often too busy because they have not reflected. The inefficiencies compound unexamined. The tools that slow people down stay in place because nobody paused to question them. The process friction that costs hours every week remains invisible because everyone is too heads-down to look up. Regular, structured reflection is the mechanism by which a team converts experience into improvement rather than simply accumulating experience while repeating the same problems.

Mindset, Not Methodology

Agile is not a set of ceremonies. This is the most important thing to understand before you attempt to apply anything this chapter has described, and it is where the majority of agile adoptions quietly fail. Organizations adopt scrum boards, run two-week sprints, hold daily standups, and fill product backlogs. They call themselves agile. The ceremonies are present. The mindset is absent. The result is something more frustrating than either traditional or agile management: a bureaucratic overlay that adds overhead without delivering the adaptive capacity agile is supposed to provide. Here is what the ceremonies look like without the underlying beliefs. Teams treat the sprint backlog as a fixed commitment that cannot change once the sprint starts, so they implement features they can clearly see are wrong rather than raising the issue mid-sprint. Daily standups become brief status reports delivered upward to management, so nobody names a blocker because naming a blocker feels like admitting failure. Sprint reviews become demos performed for stakeholders who then disappear until the next one, so customer collaboration is theater rather than genuine feedback. Retrospectives run for thirty perfunctory minutes and produce a list of action items nobody follows up on, so the team does not actually improve. Each ceremony is present. None of them are working.

The agile mindset is a set of genuine operating beliefs: we are always learning, the plan is a hypothesis rather than a contract, feedback from real users improves the product, and the team is capable of self-correction when given the authority to act on what it learns. Those beliefs, when they are real, make the ceremonies meaningful. Standups surface blockers because the team genuinely believes blockers should be visible. Retrospectives produce change because the team genuinely believes it can change how it works. The sprint goal can flex when new information arrives because the team genuinely believes that responding to learning is correct behavior, not a failure of discipline. Adopting the ceremonies takes days. Building the settings where the mindset can take root requires sustained leadership commitment, genuine tolerance for the uncertainty that comes with adaptive planning, and a willingness to grant teams the authority the manifesto assumes they already have. The manifesto was written by practitioners who believed software teams were capable of self-organization and professional judgment. Organizations that adopt agile ceremonies while simultaneously micromanaging the decisions those ceremonies are supposed to enable have imported the vocabulary without accepting the premise.

What's Next

The next chapter examines how traditional and agile approaches compare across planning, change management, and team structure, so you can see where the two models diverge, where they align, and where hybrid combinations draw from both.

Reflect

• A team at your organization runs two-week sprints but treats the sprint backlog as a fixed commitment and uses the daily standup for upward status reporting. Which values and principles are being violated, and what would correcting them actually require from leadership?
• The manifesto states that both sides of each value pair carry value. Where in your current work do you treat documentation, contracts, or plans as ends in themselves rather than tools in service of an outcome?
• Think of a project where a significant change request arrived late in the schedule. How did you respond, and how does that response compare to what the fourth value would recommend?
• Which of the five principles covered in this chapter would be hardest to implement in your organization's current culture, and what specifically would need to change first to make it possible?