Extreme Programming: The Engineering Practices Agile Doesn't Specify

AskAsk a Scrum team how they write code and you often get a shrug — Scrum defines process: roles, ceremonies, a cadence of sprints. It says almost nothing about how the code itself should be written, tested, or integrated. Extreme Programming (XP) is the answer to that missing half, and it predates Scrum's popularisation as an agile method. It came out of a real, troubled payroll project, not a conference room.

Origin: The Chrysler C3 Project

ExtremeExtreme Programming was developed by Kent Beck while leading the Chrysler Comprehensive Compensation System (C3), a Smalltalk-based payroll project that Chrysler had started in 1993 under Director of Payroll Systems Tom Hadfield¹. By 1996 the project had not produced a working payroll run, and Beck was brought in that March to rescue it. He brought in Ron Jeffries, and together with the team formalised a new way of working through 1997². The rebuilt system went live in 1997, successfully paying around ten thousand employees, before new development on the project was halted in 1999³.

Beck wrote up the practices as Extreme Programming Explained: Embrace Change, published by Addison-Wesley in October 1999⁴ — a year before the Agile Manifesto itself was drafted. XP is not a Scrum spin-off; if anything the historical order runs the other way, and Beck was one of the seventeen signatories of the Manifesto in 2001.

The Core Practices

XP'sXP's contribution is a tight set of concrete engineering disciplines, each addressing a specific failure mode Beck saw on C3:

Practice	What it is	What it prevents
Pair programming	Two developers, one keyboard, continuous review	Defects and knowledge silos slipping through unreviewed
Test-driven development (TDD)	Write the failing test before the code that passes it	Untestable designs and untested code paths
Continuous integration	Integrate and build on every change, not at the end	"Integration hell" — weeks of merge conflicts before release
Collective code ownership	Anyone can improve any part of the codebase	Bottlenecks around single "owners" of a module
Simple design	Build the simplest thing that could possibly work	Speculative complexity for requirements that never arrive
Refactoring	Continuously improve structure without changing behaviour	Design decay under the pressure of ongoing change
The planning game	Business picks scope and priority; developers estimate effort	Either side making commitments outside its own expertise
On-site customer	A real customer representative is available to the team daily	Requirements drifting through layers of proxies and documents
Sustainable pace	A 40-hour week, not sustained overtime	Burnout and the quality collapse that follows it

Two of these practices are influential enough to be taught as standalone topics on this site: see TDD & BDD for how test-first design actually works in practice, and CI/CD for how "integrate constantly" became the industry-standard build pipeline. Both trace directly back to XP.

Complementary to Scrum, Not Competing With It

StudentsStudents often meet XP and Scrum as rival "agile methodologies" and expect to have to choose. That framing is wrong. Scrum deliberately specifies process — sprints, the Scrum Master and Product Owner roles, the daily standup, the sprint review and retrospective — and just as deliberately says nothing about how the work inside a sprint gets built. That silence is not an oversight; it is Scrum's design choice to stay a thin process framework that can sit on top of many engineering approaches.

XP fills exactly that gap. A team can run Scrum's ceremonies and cadence while using XP's practices — TDD, pairing, continuous integration, refactoring — to do the actual engineering inside each sprint. In practice this combination, sometimes called "Scrum with XP practices" or "Scrumban-XP" hybrids in industry writing, is extremely common: Scrum tells you when to plan and review, XP tells you how to keep the code honest between those points. Few teams run "pure" XP with its own planning game and on-site customer; far more borrow its engineering disciplines while using Scrum, Kanban, or another framework for their process layer. See Kanban for the other major process layer XP practices are often paired with, and Choosing a Methodology for how to reason about combining a process framework with an engineering discipline rather than picking one "methodology" wholesale.

References