Agile manifesto
The Agile Manifesto is the foundational document of agile software development, created in February 2001 by seventeen practitioners who gathered in Snowbird, Utah. Frustrated with heavyweight, documentation-driven development processes, they articulated a new philosophy centered on individuals, working software, customer collaboration, and responding to change. The Manifesto remains the philosophical foundation for agile approaches worldwide.
Why it matters
Before the Manifesto, software development was dominated by plan-driven approaches. Projects began with extensive requirements gathering, proceeded through design and implementation phases, and ended with testing and deployment. Changes were resisted because they disrupted the plan.
The Manifesto offered an alternative philosophy that acknowledged the reality of software development: requirements change, customers don't know exactly what they want until they see it, and the best solutions emerge through iteration and collaboration.
The document's influence extends far beyond software. Its principles have been adapted for marketing, operations, education, and organizational change. The core insight-that adaptive approaches outperform predictive ones in uncertain environments-applies broadly.
The four values
The Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools. People and how they communicate matter more than rigid processes or sophisticated tools. The best processes in the world fail if people can't collaborate effectively; the simplest processes succeed when people work well together.
Working software over comprehensive documentation. The primary measure of progress is software that works, not documents describing software that might work someday. Documentation has value, but it's not the goal-delivering value to users is.
Customer collaboration over contract negotiation. Building the right product requires ongoing partnership with customers, not just upfront requirements and sign-offs. Customers learn what they need through seeing working software; collaboration enables that learning.
Responding to change over following a plan. Plans become obsolete as conditions change. The ability to adapt is more valuable than the ability to predict. This doesn't mean don't plan-it means hold plans loosely.
The Manifesto notes: "While there is value in the items on the right, we value the items on the left more." This isn't rejecting processes, documentation, contracts, or plans. It's establishing priorities when they conflict with the values on the left.
Common misunderstandings
"Agile means no documentation." Wrong. Agile values working software more than comprehensive documentation. Essential documentation is still necessary-just not documentation for its own sake.
"Agile means no planning." Wrong. Agile values responding to change more than following a plan. Teams still plan; they just hold plans loosely and adapt based on learning.
"Agile means the customer is always right." Not quite. Customer collaboration means working together toward shared goals, not doing whatever the customer demands. Sometimes collaboration means pushing back.
"Agile is just for developers." The Manifesto was written about software development, but its principles apply broadly. Any work involving uncertainty and complexity benefits from iteration, collaboration, and adaptation.
The signatories
The seventeen signatories brought diverse perspectives:
Kent Beck and Ron Jeffries represented Extreme Programming. Ken Schwaber and Jeff Sutherland represented Scrum. Alistair Cockburn brought the Crystal methodologies. Jim Highsmith contributed Adaptive Software Development. Others brought perspectives from Feature-Driven Development, DSDM, and pragmatic programming.
Their diverse backgrounds contributed to a Manifesto that transcends any single methodology. What they agreed on became the Manifesto; what they disagreed on remained with their individual approaches.
The twelve principles
The Manifesto is accompanied by twelve principles that elaborate on the values. These provide more concrete guidance while remaining general enough to apply across contexts.
They emphasize continuous delivery, welcoming change, frequent delivery, business-developer collaboration, motivated individuals, face-to-face conversation, working software as progress measure, sustainable pace, technical excellence, simplicity, self-organizing teams, and regular reflection.
These principles inform agile frameworks but don't prescribe specific practices. Different teams implement them differently based on their context.
Living the manifesto
The Manifesto is most valuable when internalized rather than mechanically followed. Teams that understand the values make good decisions in situations the Manifesto doesn't explicitly address.
When facing a decision, ask:
If a process or practice works against these values, question it-even if it's an established part of your framework.
The manifesto today
Over two decades later, the Manifesto remains relevant. Its values address fundamental challenges that haven't changed: uncertainty about requirements, the need for collaboration, the importance of adaptation.
Some criticize the Manifesto for being too software-focused or too narrow. Subsequent work on agile principles has expanded and adapted the ideas. But the original document retains its power as a clear statement of what matters.
Klero embodies Manifesto values by facilitating customer collaboration and enabling teams to respond to change. When you can see what customers need and how they respond to delivered features, the collaboration and adaptation the Manifesto calls for become practical realities.
