Modern XP (Extreme Programming): Your Team Isn't Actually Doing It

XP is a system, not a menu. You can’t take the parts you like and expect the same results.

In the late 1990s, Kent Beck formalized a set of software development practices while working on the Chrysler C3 payroll project. He called it Extreme Programming. The name came from a simple idea: take the practices that good teams already do and turn the dials to 10. If code review is good, review constantly (pair programming). If testing is good, test everything, all the time (test-driven development). If integration is good, integrate continuously (continuous integration).

These weren’t theoretical. They were practices drawn from real projects, refined through use, and designed to work together. XP predates Scrum’s rise to dominance, and its authors were among the signatories of the Agile Manifesto in 2001. Many of the ideas that the broader industry now treats as standard originated here.

So what happened?

The industry took a menu approach

When Agile went mainstream, organizations picked through XP like a buffet. Continuous integration? Sure, that sounds useful. Short iterations? Already doing something like that. Pair programming? Too expensive. TDD? Too slow. Collective code ownership? Too risky. The planning game? We have Jira.

The result is that most teams today claim to practice several XP techniques while actually doing watered-down versions of a few. They run a CI server but merge week-old branches. They write some tests but not before the code. They do code reviews instead of pairing and call it close enough.

This isn’t a minor distinction. XP’s practices were designed as a system where each practice reinforces the others. Pull one out and the system degrades. Pull several out and you’re left with something that shares a name with XP but delivers a fraction of the value.

Why cherry-picking fails

Consider a few examples of how the practices depend on each other.

TDD without refactoring produces a growing test suite that becomes a burden. Tests lock in implementation details. The code gets rigid. Developers start resenting the tests instead of relying on them.

Refactoring without tests is dangerous. You’re restructuring code with no safety net. So teams don’t refactor, and the design calcifies.

CI without small releases means you’re integrating frequently into a branch that doesn’t ship for weeks. Integration problems surface, but delivery problems don’t. You’ve solved half the equation.

Code review without collective ownership creates bottlenecks. Only the “owner” can approve changes to their module. Knowledge stays siloed. The review becomes a gate instead of a collaboration.

Small releases without customer feedback means you’re shipping frequently but not learning. You deliver faster without knowing if you’re delivering the right thing.

Each practice exists because of what the other practices make possible. TDD works because refactoring keeps the design clean. Refactoring works because tests make it safe. CI works because small changes integrate cleanly. Small releases work because CI keeps the build shippable. The system holds together. The individual parts, isolated, do not.

What this series covers

This series walks through XP’s practices as they were meant to work: together, in reinforcing loops. Not as a history lesson, but as a practical guide for teams building software today. The tooling has changed. The languages have changed. The principles haven’t.

Each post focuses on a loop of practices that reinforce each other:

1. The Code Quality Loop: TDD, Refactoring, and Simple Design. These three form a triangle. Remove any side and the structure collapses. Most teams claim to do at least one of them. Few do all three, and fewer still understand why all three are required.

2. The Knowledge Sharing Loop: Pair Programming and Collective Ownership. Code review is not pair programming. “That’s Steve’s service” is not collective ownership. These practices eliminate knowledge silos and make every other practice more effective.

3. The Delivery Loop: Continuous Integration and Small Releases. Your CI pipeline that runs against a branch created two weeks ago is not continuous integration. These practices are about reducing the distance between writing code and getting feedback on it in production.

4. The Feedback Loop: The Planning Game and Customer Collaboration. Modern product development rediscovered what XP already knew: tight feedback loops with real users beat detailed upfront planning. The planning game is not estimation theater.

The final post in the series makes the business case for XP as a complete system. Not for individual practices adopted in isolation, but for the full set of reinforcing loops that make software delivery predictable, sustainable, and responsive to change.

The practices aren’t outdated. The adoption was incomplete.

When people dismiss XP, they’re usually dismissing the watered-down version their organization tried a decade ago. They paired for a week and found it exhausting. They tried TDD and found it slow. They attempted CI and found it broke too often.

These are symptoms of partial adoption. Pairing is exhausting when you don’t have collective ownership and the pair is trying to learn one person’s private codebase. TDD is slow when you don’t refactor and the tests become brittle. CI breaks when you don’t work in small increments and merge large batches.

The answer isn’t to dismiss the practices. It’s to understand the system.

XP was designed for teams that build software in complex, changing environments. That describes more teams today than it did in 1999. The tooling is better. The deployment infrastructure is better. The case for these practices is stronger now than when they were introduced.

The next post in this series starts with the foundation: TDD, refactoring, and simple design. Three practices that most teams think they understand and almost none practice together.