In 30 seconds
- Four values, each a choice between two good things.
- The left side wins a tie; the right side still has value.
- Use them to settle process arguments, not to win them.
1. Individuals and interactions over processes and tools
A five-minute conversation beats a ticket that bounces between three queues. Tools and processes are there to support people talking, not to replace it.
On a real team: if a workflow forces a developer to wait two days for a status change, change the workflow.
2. Working software over comprehensive documentation
Progress is what runs, not what is written about it. Documentation is still needed, but only as much as helps people build, use and maintain the product.
On a real team: a demo of a thin working slice tells stakeholders more than a 40-page spec.
3. Customer collaboration over contract negotiation
Contracts define the relationship; collaboration makes it work. Customers who see the product often can steer it before money is wasted.
On a real team: invite the customer to the Sprint Review, not just the sign-off meeting.
4. Responding to change over following a plan
Plans are useful; treating them as fixed is not. Agile teams plan often and lightly, and expect to replan when they learn something.
On a real team: the roadmap is a forecast, reviewed every few weeks, not a promise carved in stone.
Myth vs reality
FAQ
Where do the agile values come from?
The Agile Manifesto, written in 2001. The values are its first half; the 12 principles are the second.
Are the values ranked?
No. They are four separate trade-offs, not a priority list.
How do I use them day to day?
When a process debate stalls, ask which choice better serves the left side of the relevant value.