Agile values

Agile values are the four foundational statements from the Agile Manifesto that guide how agile teams approach their work. They express preferences-valuing certain approaches over others-while acknowledging that both sides have merit. These values provide the philosophical foundation upon which all agile frameworks and practices are built.

Why it matters

Practices without values become rituals without meaning. Teams can do standups, sprints, and retrospectives while completely missing the point. The values explain why the practices exist and guide decisions when practices don't provide explicit answers.

When teams truly internalize agile values, they make better decisions throughout their work. They prioritize effectively, collaborate genuinely, and adapt appropriately. When teams only adopt practices, they follow procedures without getting the benefits.

The four values

Individuals and interactions over processes and tools. Software is built by people, for people. How they communicate and work together matters more than the processes they follow or the tools they use. Good tools and processes support good people; they don't substitute for them.

This doesn't mean processes and tools don't matter-it means they serve people, not the other way around. When a process impedes collaboration, change the process. When a tool doesn't help, find a better one. Never sacrifice human effectiveness for process compliance.

Working software over comprehensive documentation. The primary measure of progress is software that works, not documents about software. Users can't use documentation; they use working features. Documents describe intent; working software proves delivery.

This doesn't mean skip all documentation-it means don't confuse documentation with progress. Document what genuinely helps: architecture decisions, API contracts, user guides. But recognize that documents can become outdated while code remains the truth.

Customer collaboration over contract negotiation. Building the right product requires ongoing partnership with customers. You can't specify everything upfront; requirements emerge as customers see working software. Collaboration throughout development beats detailed contracts that assume complete knowledge.

This doesn't mean contracts are worthless-it means relationships matter more than paperwork. Work with customers as partners toward shared goals, not adversaries managing compliance with detailed specs.

Responding to change over following a plan. Change is inevitable and often valuable. New information, market shifts, and emerging opportunities make yesterday's plan obsolete. The ability to adapt beats the ability to predict.

This doesn't mean don't plan-it means hold plans loosely. Plan at the appropriate level of detail. Expect plans to change. Measure success by outcomes, not by plan compliance.

The right side still matters

The Manifesto explicitly states: "While there is value in the items on the right, we value the items on the left more."

This isn't a rejection of processes, documentation, contracts, or plans. It's a prioritization when they conflict with the items on the left. Some documentation is essential. Some processes help. Contracts have their place. Plans provide direction.

The values guide trade-offs. When you must choose between comprehensive documentation and shipping working software, ship the software. When process impedes people, adapt the process. When a plan no longer makes sense, change it.

Applying the values

In product management, the values argue for continuous customer collaboration, frequent delivery of working software, and adaptive planning based on what you learn. They support iterative discovery over comprehensive upfront specifications.

In development, the values argue for technical collaboration, working code over documentation, and flexibility in approach. They support practices like pair programming, continuous integration, and refactoring.

In leadership, the values argue for enabling teams rather than directing them, trusting people to do good work, and creating environments where adaptation is possible.

Living the values

Teams that live the values ask different questions:

Not "did we follow the process?" but "did we deliver value?"

Not "is the document complete?" but "do we understand what to build?"

Not "did we meet the spec?" but "did we solve the customer's problem?"

Not "did we stick to the plan?" but "did we achieve the goal?"

These questions reveal whether values are internalized or just stated.

Values under pressure

When deadlines loom or problems emerge, values get tested. Teams revert to familiar patterns: demanding documents, enforcing processes, clinging to plans, avoiding customers.

Strong teams maintain their values under pressure. They know that shortcuts against values usually backfire. Skipping customer collaboration means building the wrong thing. Forcing plans despite new information means wasted effort. Prioritizing documentation over delivery means nothing ships.

Values matter most when they're hardest to maintain.

Values as foundation

The values aren't the only guidance agile teams have. The twelve principles elaborate on the values. Frameworks like Scrum and XP provide specific practices. But the values remain foundational.

Teams that understand the values can adapt practices to their context. Teams that only know practices struggle when situations don't match their procedures.

Klero embodies agile values by facilitating customer collaboration and providing working feedback systems rather than just documentation. When teams can see what customers actually say and need, the collaboration the values call for becomes practical.