Agile Manifesto: 4 Values & 12 Principles [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on September 05, 2026
10 min read
Agile isn't a methodology, a tool, or a set of meetings — it started as four values and twelve principles written on a whiteboard by seventeen people at a ski resort. The Agile Manifesto is that founding document, and everything called "agile" since traces back to it. Understanding the manifesto is the difference between doing agile ceremonies and actually being agile. This guide explains the Agile Manifesto in full — its history, the four values, all twelve principles, how it relates to frameworks like Scrum, and how it appears on the PMP and CAPM exams.
What is the Agile Manifesto?
The Agile Manifesto — formally the Manifesto for Agile Software Development — is a short statement of four values and twelve principles that define a better way of developing software and, by extension, delivering work. It is the foundational document of the entire agile movement: a concise declaration of what agile teams should prioritize, written to replace the slow, rigid, documentation-heavy processes that dominated software development at the time.
What makes it powerful is its brevity and its emphasis. The manifesto doesn't prescribe practices, roles, or ceremonies; it states priorities. It says, in effect, that when trade-offs arise, teams should favor people over process, working results over paperwork, collaboration over contracts, and adaptability over rigid plans. Everything more specific — Scrum's sprints, Kanban's boards, and the rest — came afterward as ways to live out those priorities. The manifesto is the philosophy beneath all of it, which is why understanding it matters more than memorizing any single framework's rules.
The history: why and who wrote it
The Agile Manifesto was written in February 2001, when seventeen software developers met at the Snowbird ski resort in Utah to find common ground among the various "lightweight" development approaches they'd each been championing. They were reacting against the heavyweight, plan-driven processes of the era — long projects that produced mountains of documentation and detailed upfront plans, only to deliver software that was late, over budget, or no longer what the customer needed.
The group included figures who would become giants of the field, among them Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber, and Jeff Sutherland, people who had independently developed methods like Extreme Programming and Scrum. What united them was a conviction that software development had become too rigid and too disconnected from the people it served. Out of that meeting came the manifesto: not a detailed methodology, but a shared set of values and principles they could all stand behind. The word "agile" was chosen as the umbrella term for the mindset, and the document has remained unchanged — and remarkably influential — ever since.
Ready to take the next step in project management?
200,000+ Professionals Taught by Our Instructors
The 4 values of the Agile Manifesto
At the heart of the manifesto are four values, each expressed as a preference of one thing over another. The phrasing matters: the manifesto doesn't reject the items on the right, it simply values the items on the left more when the two are in tension.
| We value this… | …over this |
|---|---|
| Individuals and interactions | processes and tools |
| Working software | comprehensive documentation |
| Customer collaboration | contract negotiation |
| Responding to change | following a plan |
Each value has a point. Individuals and interactions over processes and tools recognizes that capable people communicating well matter more than any rigid process. Working software over comprehensive documentation says that a functioning product is worth more than exhaustive paperwork about it. Customer collaboration over contract negotiation favors an ongoing partnership with the customer over haggling about a fixed scope. And responding to change over following a plan accepts that requirements will evolve, and that adapting beats stubbornly following an outdated plan. Crucially, the manifesto closes this section with a caveat: "while there is value in the items on the right, we value the items on the left more." Documentation, plans, processes, and contracts all still matter — they're just not the priority when a trade-off has to be made.
The 12 principles behind the Agile Manifesto
Beneath the four values sit twelve principles that translate the values into more concrete guidance. They flesh out what agile looks like in practice:
- Satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development, harnessing change for the customer's advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, preferring the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals: give them the environment and support they need, and trust them to get the job done.
- Face-to-face conversation is the most efficient and effective way to convey information within a team.
- Working software is the primary measure of progress.
- Agile promotes sustainable development — the team should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity, the art of maximizing the amount of work not done, is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Read together, the principles paint a coherent picture: deliver value early and often, embrace change, keep people and communication at the center, sustain a healthy pace, and continuously improve. That last principle — regular reflection and adjustment — is the direct ancestor of the sprint retrospective, and the first two are why agile teams treat changing requirements as normal rather than as failures of planning.
Why the Agile Manifesto matters
The Agile Manifesto matters because it is the definition of agile itself — the reference point against which any practice, framework, or team can be judged "agile" or not. Without it, "agile" would be a vague buzzword; with it, there's a concrete set of values and principles that give the word meaning. Every agile framework, method, and technique is ultimately an attempt to realize what the manifesto describes.
Its influence has been enormous and durable. It reshaped software development away from rigid, plan-everything-first approaches and toward iterative, feedback-driven delivery, and its ideas have since spread well beyond software into marketing, operations, and general project management. It also provides a useful test for teams that have adopted agile mechanics without the mindset: a team can run every ceremony and still miss the point if it isn't actually valuing people, working outcomes, collaboration, and change. That distinction — between doing agile and being agile — is exactly what the manifesto exists to clarify. More than two decades on, it remains the single best answer to the question "what does agile actually mean?"
The manifesto vs. agile frameworks
A common confusion is treating the Agile Manifesto as a framework you can "implement." It isn't. The manifesto is a philosophy — a set of values and principles — while frameworks like Scrum, Kanban, and Extreme Programming are the practices that put that philosophy to work. The manifesto tells you what to value; a framework gives you specific ways to act on it.
The relationship is straightforward once you see it. Scrum implements the manifesto through sprints, roles, and events that deliver working software frequently and reflect regularly. Kanban and flow-based methods like scrumban realize it through visualized work, limited work-in-progress, and continuous delivery. Lean thinking, which shares deep roots with agile, shows up in approaches like lean project management. None of these is agile in itself — each is a way of being agile as the manifesto defines it. This is why a team can follow Scrum to the letter and still not be agile: the framework is only as agile as the values behind how it's used. The manifesto is the destination; frameworks are different roads to it.
The Agile Manifesto on the PMP® and CAPM® Exams
Because the current PMP exam is heavily weighted toward agile and hybrid delivery, the mindset captured by the Agile Manifesto runs through much of the exam — even when the manifesto isn't named directly. The values and principles inform how the exam expects a project manager to think: favoring working outcomes, close collaboration, and adapting to change over rigid adherence to a plan or process.
Situational questions reward the agile mindset over command-and-control instincts. When a scenario presents changing requirements, the manifesto's "responding to change over following a plan" points toward embracing the change rather than resisting it; when it presents a customer relationship, "customer collaboration over contract negotiation" favors partnership over rigid scope enforcement. You may also see questions that directly ask which statement is one of the four values, or that test the principle of delivering value early and continuously. Our PMP Complete Study Guide, the most complete on the market, covers the agile mindset and how the manifesto's values are tested. If you're learning agile from the ground up rather than sitting an exam, our Complete Project Management Course teaches the agile mindset alongside predictive and hybrid practice.
PMP Practice Question: Agile Manifesto
A software team building a companion app for a medical device invokes the Agile Manifesto to justify eliminating written requirements, dropping the regulatory traceability records, and treating the delivery contract as merely indicative — citing "working software over comprehensive documentation" and "customer collaboration over contract negotiation." The compliance office objects that certification will fail without the records, and both sides ask the project manager to settle it.
How should the project manager apply the manifesto's values?
a) Side with the team, since the manifesto explicitly ranks working software above documentation, and in a direct conflict the left-hand value takes precedence.
b) Side with compliance by setting the manifesto aside, since agile values were never meant to operate in regulated environments like medical devices.
c) Read the values as weighted preferences rather than absolutes: keep the documentation, records, and contract terms the product genuinely needs, while keeping working software the primary measure of progress.
d) Split the work: let the team run the features with agile values while a separate compliance-owned workstream produces the documentation and records predictively.
Correct answer: C.
Rationale: The manifesto's own closing line settles this: "while there is value in the items on the right, we value the items on the left more." The right-hand items — documentation, contracts, plans — are explicitly declared valuable; the manifesto weights them, it never abolishes them, so regulatory traceability the product needs for certification is not waste to eliminate but right-hand value this context demands. Choice a) is the literal-reading trap, converting a preference into a veto the authors explicitly disclaimed; choice b) over-corrects in the mirror direction, since agile runs successfully in regulated industries precisely by honoring both sides of each value pair; choice d) sounds pragmatic but divorces the records from the people building the software, which is how documentation drifts out of sync with the product and fails the certification anyway. To drill this kind of values judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Professionals Taught by Our Instructors
Frequently asked questions
What is the Agile Manifesto?
The Agile Manifesto, formally the Manifesto for Agile Software Development, is a short statement of four values and twelve principles that define a better way of developing software and delivering work. Written in 2001, it is the foundational document of the agile movement, stating the priorities agile teams should favor — such as people over process and responding to change over following a plan.
When and who wrote the Agile Manifesto?
The Agile Manifesto was written in February 2001 by seventeen software developers who met at the Snowbird ski resort in Utah. They included influential figures such as Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber, and Jeff Sutherland. They were seeking common ground among their various lightweight development methods and reacting against the heavy, plan-driven processes of the time.
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 adds that while there is value in the items on the right, agile teams value the items on the left more when the two are in tension.
What are the 12 principles of the Agile Manifesto?
The twelve principles translate the values into practice. They cover early and continuous delivery of value, welcoming change, delivering frequently, daily business-developer collaboration, building around motivated individuals, favoring face-to-face conversation, using working software as the measure of progress, sustainable pace, technical excellence, simplicity, self-organizing teams, and regular reflection to improve. Together they describe what agile looks like day to day.
Why does the Agile Manifesto matter?
The Agile Manifesto matters because it defines what agile actually means — it is the reference point that gives the word substance rather than leaving it a buzzword. Every agile framework and technique is an attempt to realize its values and principles. It also distinguishes truly being agile from merely running agile ceremonies, since a team can follow the mechanics while missing the mindset the manifesto describes.
What is the difference between the Agile Manifesto and a framework like Scrum?
The Agile Manifesto is a philosophy — a set of values and principles — while frameworks such as Scrum, Kanban, and Extreme Programming are specific ways to put that philosophy into practice. The manifesto tells you what to value; a framework gives you concrete roles, events, or techniques for acting on it. A team can follow a framework precisely and still not be agile if it ignores the underlying values.
Is the Agile Manifesto on the PMP exam?
Yes. The current PMP exam is heavily weighted toward agile and hybrid delivery, and the mindset captured by the Agile Manifesto runs throughout it. You are expected to apply its values — such as responding to change and collaborating with customers — in situational questions, and you may be asked directly to identify one of the four values or a principle like delivering value early and continuously.
Is the Agile Manifesto on the CAPM exam?
Yes. The CAPM covers agile foundations including the Agile Manifesto, usually a little more directly than the PMP — often testing the four values, the twelve principles, or the history of the document. Because the CAPM is scenario-based, you should also be ready to apply the manifesto's values to a described situation, such as one involving changing requirements.
What Is Agile? Methodology, Values & Benefits [2026]
Agile is an iterative, adaptive way of delivering work. What agile is, the values behind it, agile vs. waterfall, frameworks, benefits, and PMP exam tips.
What Is Scrum? Roles, Events & Artifacts [2026]
Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
