Agile Manifesto: The 4 Values and 12 Principles Explained

The agile manifesto is one of the most read documents in software history, and it's only 68 words long. Seventeen practitioners wrote it in February 2001 at a ski resort in Snowbird, Utah, frustrated by years of bloated processes that produced late software nobody wanted.

But the document's influence went far beyond software. Today, marketing teams run sprints. HR departments hold retrospectives. Operations teams use Kanban boards. The Agile Manifesto's four values and twelve principles are the foundation of all of it.

This guide breaks down exactly what those values and principles say, what they mean in practice, and how you can apply them on any team.

What Is the Agile Manifesto?

The Agile Manifesto is a short founding document written in February 2001 by 17 software practitioners at the Snowbird ski resort in Utah. It defines four core values and twelve principles that prioritize people, working results, and adaptability over rigid process and upfront planning.

The 17 signatories included some of the most influential figures in software engineering: Kent Beck (creator of Extreme Programming), Jeff Sutherland and Ken Schwaber (co-creators of Scrum), Martin Fowler, Jim Highsmith, Alistair Cockburn, and eleven others. Their frustration was shared: heavyweight, plan-driven processes consistently produced software that was late, over budget, and no longer relevant by launch day.

The document is published at agilemanifesto.org and has never been revised. It remains exactly as written in 2001.

Key Facts

• The Agile Manifesto was published in February 2001 at agilemanifesto.org, signed by 17 software practitioners. Its four values total 68 words, unchanged since publication.
• The 18th Annual State of Agile Report (Digital.ai, 2024) found that 71% of organizations use agile approaches, up from 37% in 2011.
• A Standish Group CHAOS Report analysis found agile projects succeed at significantly higher rates than waterfall counterparts: 42% success rate vs. 13% for waterfall when controlling for project size (2020 edition).

Understanding the Manifesto is also essential context for agile methodology as a whole, since every major framework (Scrum, Kanban, XP) traces its lineage back to this document.

The 4 Values of the Agile Manifesto

The Manifesto states it plainly: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value..."

Then it lists four value pairs. Each is written as "X over Y." The critical clarification that follows is just as important: "While there is value in the items on the right, we value the items on the left more."

That nuance matters. The Manifesto doesn't say contracts are worthless. It says customer collaboration matters more. It doesn't say documentation is useless. It says working software takes priority.

Value 1: Individuals and Interactions over Processes and Tools

A standup meeting where people genuinely surface blockers is worth more than a beautifully maintained project tracking tool that nobody reads. This value is a reminder that process is a means, not an end.

In practice: if your team spends more time updating the system than talking about the actual work, something is backwards.

Value 2: Working Software over Comprehensive Documentation

This is the most misunderstood value. Teams sometimes read it as "don't write docs." That's not what it says. It says that a working product in a user's hands produces more learning than a specification document does. A prototype that ships in week two tells you more than a 40-page requirements doc written in month one.

Value 3: Customer Collaboration over Contract Negotiation

Contracts define what was agreed at the start. Customers know what they actually need after they've seen the first few iterations. Regular collaboration, demos, and feedback loops let the product evolve toward what the customer really wants, not just what they wrote down in the original brief.

Value 4: Responding to Change over Following a Plan

Markets shift. Competitors ship. User feedback surprises you. A plan written before the work started reflects assumptions, not reality. Agile teams update their plan as they learn. Sprint planning is where this value gets operationalized: teams plan one sprint at a time, not six months at once.

The 12 Principles of Agile

The twelve principles expand each value into actionable guidance. They were written alongside the four values and are published as a companion page at agilemanifesto.org/principles.html.

Three principles matter most for non-software teams: Principle 2 (welcome late change), Principle 10 (maximize work not done), and Principle 12 (regular retrospectives). These apply equally to marketing campaigns, HR processes, and operations workflows.

Why the Agile Manifesto Still Matters

The Manifesto was written in reaction to a specific problem: software projects that failed because they tried to predict and specify everything upfront. That problem hasn't gone away. If anything, it's gotten worse.

Here's why the Manifesto's relevance has grown:

Work is more complex. The problems teams tackle in 2026 (AI integration, distributed work, multi-market launches) are harder to specify upfront than the enterprise software projects of 2001. Iterative delivery and rapid learning loops are even more important.

Feedback loops are faster and cheaper. In 2001, shipping something meant physical releases or overnight deployments. Now, a team can ship a feature to 10% of users in minutes and measure results in hours. The Manifesto's bet on fast feedback is even more rewarded.

Agile has moved beyond software. Marketing, HR, finance, and operations teams run sprints. The 12 principles are domain-agnostic. Principle 8 (sustainable pace) applies to any team. Principle 10 (maximize work not done) applies to any process. Principle 12 (regular retrospectives) applies to any group trying to improve.

The agile vs waterfall decision is still the most common strategic choice teams face when starting a new initiative, and the Manifesto is the clearest articulation of what makes agile different.

Common Misconceptions About Agile

The Manifesto gets misread constantly. Here are the most common mistakes and what the document actually says.

Misconception 1: "Agile means no planning."

It doesn't. The Manifesto says "responding to change over following a plan," not "never plan." Every sprint starts with sprint planning. Every quarter starts with goal-setting. The difference is that agile plans are updated as new information arrives, not followed rigidly regardless of what you learn.

Misconception 2: "Agile means no documentation."

The Manifesto values working software over comprehensive documentation. "Comprehensive" is the key word. Write documentation that's useful. Don't write documentation as a substitute for shipping something.

Misconception 3: "Agile is only for software teams."

The Manifesto was written by software practitioners, but the values are not software-specific. Principle 1 (early delivery of value), Principle 2 (welcome change), and Principle 12 (regular retrospectives) apply to any team doing complex work.

Misconception 4: "Agile means no deadlines."

Agile teams have deadlines. Sprint reviews happen on fixed dates. Product releases have launch windows. The difference is that agile teams negotiate scope to hit the date, rather than negotiating the date to fit the scope.

Misconception 5: "Scrum is agile."

Scrum is one implementation of agile values. So is Kanban. So is Extreme Programming. Agile is the philosophy; Scrum is one recipe that follows it. You can be agile without running Scrum. You can run Scrum ceremonies without actually being agile (this is called "cargo-cult agile" and it's more common than most organizations want to admit).

How to Apply the Agile Manifesto on Your Team

You don't need to adopt a formal framework to start applying agile values. Here's how to move from the Manifesto's principles to actual practice.

Step 1: Identify your current "waste"

Look at where your team spends time on things that don't directly produce value. Long approval chains, status reports that nobody reads, meetings that could be a message. Principle 10 (maximize work not done) starts here.

Step 2: Shorten your delivery cycle

What's the smallest thing your team could ship that a real user could react to? If your current cycle is quarterly, target monthly. If it's monthly, target bi-weekly. Burndown charts can help you visualize whether the work being delivered each cycle is actually completing.

Step 3: Get the customer into the room earlier

Your "customer" might be an external client, an internal stakeholder, or an end user. Whoever it is, find a way to show them work in progress instead of finished work. Early feedback is cheap. Late feedback is expensive.

Step 4: Start a retrospective habit

Block 30-60 minutes at the end of each work cycle to ask three questions: What went well? What didn't? What will we change? Principle 12 is the compounding return of agile. Teams that retrospect consistently improve faster than teams that don't. The formal version is a sprint retrospective, but even a simple shared doc can get you started.

Step 5: Experiment with WIP limits

Choose one stage of your workflow (In Progress, In Review, or similar) and cap how many items can sit there at once. Both Scrum and Kanban agree on one thing: finishing work in progress beats starting new work. WIP limits force that behavior.

Step 6: Give your team more autonomy

Principle 11 says the best results come from self-organizing teams. That means the people doing the work should have input into how the work gets done. Start small: let the team choose how to run their standups, or let them estimate their own capacity each sprint instead of having a manager set targets.

Agile Manifesto Examples by Role and Function

The four values look different depending on who's doing the work.

User stories are one of the most practical tools for bridging the gap between customer needs and team work items. They're the agile artifact that makes Value 3 (customer collaboration) tangible.

Frequently Asked Questions

Who wrote the Agile Manifesto?

The Agile Manifesto was written by 17 software practitioners who met at the Snowbird ski resort in Utah in February 2001. The group included Kent Beck, Jeff Sutherland, Ken Schwaber, Martin Fowler, Jim Highsmith, Alistair Cockburn, Ward Cunningham, and nine others. They signed the document collectively as authors, though the term "agile" was proposed during the meeting itself.

When was the Agile Manifesto published?

The Agile Manifesto was published in February 2001, specifically February 11-13, 2001, during a three-day retreat at the Snowbird resort in Utah. The document was published online at agilemanifesto.org and has not been revised since.

What are the 4 values of the Agile Manifesto?

The four values are: (1) Individuals and interactions over processes and tools, (2) Working software over comprehensive documentation, (3) Customer collaboration over contract negotiation, and (4) Responding to change over following a plan. Each value pair means the left side takes priority, but the right side still has value.

What is the difference between the 4 values and the 12 principles?

The 4 values are the philosophical foundation: they state what agile teams prioritize. The 12 principles are the operational expansion: they explain how to act on those values in practice. For example, Value 4 says "respond to change." Principle 2 says "welcome changing requirements, even late in development." Principle 3 says "deliver working software frequently." Both support the same value but at different levels of specificity.

Is the Agile Manifesto still relevant in 2026?

Yes. The four values were written as a reaction to over-specified, plan-heavy processes. In 2026, those same dynamics appear in AI-assisted development, large-scale digital transformation, and distributed teams. The Manifesto doesn't describe tools or technologies. It describes priorities. And those priorities, favoring people over process, working results over documentation, and learning over prediction, are as applicable today as they were in 2001. The 18th Annual State of Agile Report (Digital.ai, 2024) found that 71% of organizations now report using agile approaches.

The Agile Manifesto isn't a historical artifact. It's a decision-making lens. Every time your team faces a tradeoff between finishing the documentation and shipping the prototype, between following the original plan and adjusting based on new data, between a process and a conversation, the Manifesto tells you which direction to lean. That guidance doesn't expire.