The Four Agile Values
Understanding what we value more, and what we still value (just less).
1Reading the Manifesto Correctly
The Agile Manifesto states four preferences, not absolutes:
"We have come to value X over Y. That is, while there is value in the items on the right, we value the items on the left more."
This is crucial. It's not "X good, Y bad." It's "when forced to choose, prefer X."
Common Misread
"We don't need documentation because we're agile" is NOT what the manifesto says. Documentation has value; it's just not the primary focus.
2Individuals and Interactions over Processes and Tools
Great tools and processes can't save a dysfunctional team. But a great team can succeed with mediocre tools.
What this means in practice:
- Hire for collaboration, not just technical skills
- Choose processes that serve the team, not the other way around
- When the process creates friction, fix the process
- Face-to-face conversation beats email threads
What this doesn't mean:
- Chaos with no process
- Ignoring useful tools
- Undocumented tribal knowledge
The team notices their daily standup has become a status report to the manager. They discuss and change the format to focus on collaboration.
A team uses Jira exactly as corporate mandates, even though the workflow doesn't match how they actually work. They maintain two systems.
3Working Software over Comprehensive Documentation
The best documentation of what a system does is the system itself. Code that runs beats specifications that describe what code might do someday.
What this means in practice:
- Ship early and often
- Measure progress by working features, not completed documents
- Write just enough documentation, at the right time
- Keep docs close to the code so they stay current
What this doesn't mean:
- No documentation ever
- Unreadable code with no comments
- No design discussions before coding
4Customer Collaboration over Contract Negotiation
Contracts assume you can specify everything upfront. Collaboration assumes you'll learn together. In a world of uncertainty, collaboration wins.
What this means in practice:
- Include stakeholders in regular reviews
- Seek feedback early, not just at the end
- Adjust scope based on learning
- Build trust through transparency
What this doesn't mean:
- No contracts or agreements
- Unlimited scope creep
- The customer is always right (they often don't know what they need)
5Responding to Change over Following a Plan
Plans are useful. Clinging to outdated plans is harmful. The goal isn't to avoid planning— it's to plan in a way that allows adaptation.
What this means in practice:
- Short iterations with replanning opportunities
- Welcome changing requirements, even late in development
- Track velocity to improve future estimates
- Kill projects early when they're not working
What this doesn't mean:
- No planning
- Changing direction every day
- Developers ignoring the roadmap
The Planning Paradox
In agile, we actually plan MORE frequently than in waterfall—just in smaller batches. "Responding to change" requires constant replanning.
- The manifesto states preferences, not absolutes—context matters
- The items on the right still have value
- Each value addresses a specific failure mode of traditional development
- Being agile means internalizing these values, not just following rules