February 2001. Seventeen software developers gather at a ski lodge in Snowbird, Utah. Some are rivals. Some have never met. They all agree on one thing: the industry's dominant approach to building software is fundamentally broken.
What came out of that weekend wasn't a methodology or a process. It was a statement of values — 68 words — that rewired how the world thinks about software development.
Learning Objectives
By the end of this lesson you will be able to:
- Explain the historical context that led to the Agile Manifesto
- State and interpret the 4 Agile values in your own words
- Distinguish between Agile as a mindset and Agile as a specific framework
- Name at least 3 of the 12 Agile principles
The Context: Why the Manifesto Was Necessary
The 1990s were the decade of "heavyweight" software processes — CMMI, RUP, Prince2. Teams spent months writing requirements documents before a single line of code. Projects routinely ran late, over budget, and delivered software that didn't match what users actually needed.
The 17 practitioners at Snowbird came from different backgrounds (XP, Scrum, DSDM, Crystal, and others) but shared a diagnosis: the problem wasn't the people — it was the process. Specifically, the assumption that software could be managed like a predictable, mechanical engineering project.
The 4 Core Values
The Manifesto is built around four value statements. Each one says: "we value the left side, but we value the right side more."
Value 1: Individuals and Interactions over Processes and Tools
Software is a human activity. No tool, no matter how sophisticated, substitutes for a developer and a QA engineer talking directly and clarifying a requirement in 5 minutes instead of creating a ticket that sits in a backlog for two weeks.
QA implication: Raise a concern directly with the developer. Don't wait for it to go through a formal defect workflow if a quick conversation can resolve it faster.
Value 2: Working Software over Comprehensive Documentation
Documentation that describes software no one will build, or software that's already been replaced, is waste. The proof that the software works is... the software working.
QA implication: A passing test suite is more valuable than a 100-page test plan that was written once and never updated. Executable documentation (automated tests) beats static documentation.
Value 3: Customer Collaboration over Contract Negotiation
Treating the customer as an adversary — someone to be managed, contractually bound, and kept at arm's length — guarantees you'll build the wrong thing. The customer knows the problem. The team knows the solutions. Collaboration is how you find the right answer.
QA implication: QA is a bridge between the team and the customer's real needs. A QA engineer who questions acceptance criteria or asks "but what does the user actually expect here?" is practicing this value.
Value 4: Responding to Change over Following a Plan
Plans are useful. Plans that become sacred objects — that the team follows even after the environment has changed — are dangerous. Agile teams treat a plan as a current best guess, not a commitment carved in stone.
QA implication: When requirements change mid-sprint, a QA engineer who adapts quickly (updates test cases, re-checks regression areas) is more valuable than one who refuses to test because "that's not in the original spec."
The 12 Principles: A Quick Tour
The Manifesto comes with 12 principles that expand on the 4 values. Key ones for a QA engineer:
- "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale." → Frequent releases mean frequent feedback loops.
- "Continuous attention to technical excellence and good design enhances agility." → Quality isn't a phase; it's a practice woven through every sprint.
- "The best architectures, requirements, and designs emerge from self-organizing teams." → QA is not a separate department that receives finished work; it's part of the team that shapes the work.
- "At regular intervals, the team reflects on how to become more effective." → That's the Retrospective. It exists because the Manifesto demands continuous improvement.
Agile Is a Mindset, Not a Methodology
Here is the most important thing to understand — and the most commonly misunderstood:
Agile is not a process. Scrum is a process. Kanban is a process. XP is a process.
Agile is the philosophy that underpins all of them. You can follow Scrum ceremonies perfectly and still be completely un-Agile if you're not actually embracing the values. You can also be deeply Agile without using any named framework at all.
The litmus test: "Is this decision driven by the values in the Manifesto — collaboration, working software, responding to change — or is it driven by the comfort of following a rigid process?"
Pro Tips
When someone says "we're Agile" but the QA team is a separate, downstream department that receives finished features to test, they're not Agile. That's Waterfall with daily standups.
The Manifesto says "we VALUE the right side" — it does not say "the left side is worthless." Processes, tools, documentation, and plans all matter. The point is that they serve the left-side values, not override them.
Summary
- The Agile Manifesto was written in February 2001 by 17 practitioners who agreed that heavyweight software processes were failing the industry.
- The 4 Agile values are: Individuals over Processes, Working Software over Documentation, Customer Collaboration over Contract Negotiation, Responding to Change over Following a Plan.
- "Over" does not mean "instead of" — both sides have value; the right side is prioritized when they conflict.
- Agile is a mindset and a set of values. Scrum, Kanban, and XP are frameworks that attempt to implement those values.
- The 12 principles give the values operational meaning — particularly around frequent delivery, technical excellence, and continuous improvement.