The XP Practices: An Overview
A map of all XP practices and how they reinforce each other.
1Practices Work Together
XP isn't a menu where you pick your favorites. The practices are designed to reinforce each other. Remove one, and the others become harder or less effective.
For example:
- Refactoring is safe because you have comprehensive tests
- Simple design is possible because you can refactor when requirements change
- Collective ownership works because you have coding standards
- Continuous integration is feasible because you have small releases and tests
This interlocking nature is why "doing TDD but not refactoring" or "pair programming without tests" often fails. You're removing a load-bearing wall.
That said, you have to start somewhere. We'll discuss incremental adoption in Module 5.
Think of XP practices like safety features in a car. Seatbelts, airbags, and crumple zones all work together. Removing any one makes the others less effective.
2Primary Practices
These are the core practices that most XP teams adopt:
Planning Practices:
- User Stories: Requirements as conversation starters
- Planning Game: Business chooses what, developers choose how
- Small Releases: Deliver value frequently
- Iteration Planning: Break stories into tasks for each iteration
Development Practices:
- Test-Driven Development (TDD): Write the test first
- Pair Programming: Two developers, one keyboard
- Refactoring: Improve code without changing behavior
- Simple Design: The simplest thing that works
- Continuous Integration: Integrate and test many times a day
Team Practices:
- Whole Team: Everyone needed to deliver, in one room
- Collective Code Ownership: Anyone can change any code
- Coding Standards: Agreed-upon code conventions
- Sustainable Pace: No overtime as a rule
We'll cover each of these in depth in the following modules.
3Corollary Practices
These practices are powerful but require more maturity or specific conditions:
- Real Customer Involvement: The actual customer, not just a proxy
- Root Cause Analysis: Fix the system, not just the symptom
- Shared Code: All code is visible to all developers
- Code and Tests: Code and tests are the only permanent artifacts
- Single Code Base: One branch, not many
- Daily Deployment: Deploy to production every day
- Negotiated Scope Contract: Contracts that embrace change
- Pay-Per-Use: Direct feedback from real customers
These aren't "advanced XP." They're practices that work well in the right context but might be inappropriate or impossible in others.
4The Feedback Diagram
One way to understand XP practices is through their feedback loops:
Seconds: Unit tests Minutes: Pair programming Hours: Continuous integration Day: Stand-up meeting Week: Iteration planning, customer demo Month/Quarter: Release, retrospective
At every scale, XP creates opportunities to learn and adjust. This is intentional. The faster you learn, the faster you can correct course.
If you're not getting feedback at each of these scales, something is missing.
5Start Somewhere
This might seem overwhelming. Don't try to adopt everything at once.
Most teams start with:
- TDD or at least writing tests
- Continuous Integration
- Iterations (or sprints if using Scrum)
- Retrospectives
These form the foundation. Once they're working, add:
- Pair programming (start with just hard problems)
- Refactoring (start with the messiest code)
- Small releases (start by releasing more frequently)
We'll cover adoption strategies in Module 5. For now, just understand the landscape.
One Practice at a Time
Pick one practice, do it well, then add another. Trying to adopt everything at once usually means adopting nothing well.
- XP practices are designed to reinforce each other
- Removing one practice often weakens the others
- Primary practices are the core; corollary practices require more context
- Feedback loops exist at every scale from seconds to months
- Start with a few practices and expand gradually