The Five XP Values

XP isn't just a collection of practices—it's a value system. The practices only make sense in the context of the values. Without the values, you get cargo-cult XP: teams going through the motions without the spirit.

The five XP values are: Communication, Simplicity, Feedback, Courage, and Respect.

These aren't aspirational posters. They're decision-making tools. When you're unsure what to do, ask which choice best embodies these values.

Communication is the first value because software development is fundamentally a communication problem. We're not just writing code—we're translating human needs into machine instructions.

Misunderstandings are the root cause of most bugs. The customer says "fast," the developer implements caching, but the customer meant "fewer clicks." Traditional approaches try to solve this with documentation. XP solves it with continuous communication.

In XP, communication means:

• Pair programming (constant technical communication)
• Customer on-site (constant requirements communication)
• Daily standups (constant team communication)
• Simple code (code that communicates its intent)

The opposite of communication: assuming you know what's needed, working in isolation, writing clever code, and throwing specifications over the wall.

Simplicity means doing the simplest thing that could possibly work. Not the most elegant, not the most extensible, not the most general—the simplest.

This is captured in the XP mantra YAGNI: You Aren't Gonna Need It. Don't build frameworks. Don't add extension points. Don't generalize. Build exactly what's needed today.

Why? Because:

• Simple code has fewer bugs
• Simple code is easier to change
• Simple code is easier to understand
• Half of what you think you'll need, you won't

This doesn't mean sloppy or hacky. Simple code is often harder to write than complex code. It requires thinking deeply about what's actually essential.

The opposite of simplicity: building for hypothetical future requirements, adding "just in case" flexibility, creating abstractions before you need them.

Feedback is how you learn whether you're doing the right thing. XP creates feedback loops at every scale:

• Seconds: Unit tests tell you if your code works
• Minutes: Pair partner catches mistakes as you type
• Hours: Daily integration reveals integration issues
• Days: Weekly iterations show progress to customers
• Weeks: Release cycles confirm you're building the right thing

The faster the feedback, the cheaper the fix. A bug caught in seconds costs nothing. A bug caught in production costs time, money, and reputation.

XP's practices are designed to create fast, honest feedback. Tests don't lie. Working software doesn't lie. Production metrics don't lie.

The opposite of feedback: working in isolation for weeks, waiting until the end to test, avoiding customer contact, ignoring production metrics.

Courage means doing what needs to be done, even when it's uncomfortable. In XP, courage shows up as:

• Refactoring ruthlessly: Changing working code to make it simpler
• Throwing away code: Deleting code that's not pulling its weight
• Asking for help: Admitting you don't know something
• Speaking up: Telling the customer when estimates are wrong
• Trying new things: Experimenting even when you might fail

Courage isn't recklessness. It's supported by the other values. You can refactor with courage because you have tests (feedback). You can speak up because you have customer relationships (communication).

The opposite of courage: leaving broken windows, padding estimates to be "safe," hiding bad news, doing what's always been done.

Respect was added in the second edition of Kent Beck's book, recognizing what was always implicit: XP only works when team members respect each other.

Respect means:

• Trusting colleagues' competence (not micromanaging)
• Valuing everyone's contribution (developers, testers, customers)
• Giving honest feedback kindly (not crushing spirits)
• Taking care of your own work (not creating burdens for others)

In pair programming, respect means listening to your partner's ideas. In planning, respect means giving honest estimates. In code review, respect means critiquing code, not people.

The opposite of respect: dismissing ideas without consideration, assigning blame, treating some roles as less important, caring more about being right than being effective.