Extreme Programming

Also known as: XP

framework · computer science · organizing-schema

Beck's rigorous agile practices including TDD, pair programming, and continuous integration.

Extreme Programming was developed by Kent Beck at the Chrysler Comprehensive Compensation (C3) project in 1996 and presented in Extreme Programming Explained: Embrace Change (1999, 2nd ed. 2004 substantially revised). XP synthesizes a set of mutually-reinforcing engineering and team practices — taking each to an 'extreme' (the rationale for the name): if code review is good, do it continuously through pair programming; if testing is good, write tests before code (Test-Driven Development); if integration is good, integrate continuously; if short cycles are good, deliver every week. The original twelve practices include Planning Game, Small Releases, Metaphor, Simple Design, Testing, Refactoring, Pair Programming, Collective Ownership, Continuous Integration, 40-hour Week, On-site Customer, and Coding Standards; the 2004 second edition reorganized these around values (Communication, Simplicity, Feedback, Courage, Respect) and primary/corollary practices. XP's engineering rigor — particularly TDD, pair programming, refactoring, and continuous integration — substantially influenced subsequent agile and DevOps practice, even where the full XP package is not adopted.

Originators

Kent Beck; Ward Cunningham; Ron Jeffries (foundational practitioners) high

Year / Decade

1996 (Chrysler C3 project); 1999 (XP Explained 1st edition); 2004 (substantially revised 2nd edition) high

Primary sources

Beck, K. (1999, 2nd ed. 2004). Extreme Programming Explained: Embrace Change, Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change (2nd edition with Cynthia Andres) high

Core components

Five values: Communication, Simplicity, Feedback, Courage, Respect
Twelve original practices: Planning Game, Small Releases, Metaphor, Simple Design, Testing, Refactoring, Pair Programming, Collective Ownership, Continuous Integration, 40-hour Week, On-site Customer, Coding Standards
Test-Driven Development as central practice
Mutually-reinforcing practice set
Two-day or one-week iterations
Customer collaboration through On-site Customer or User Stories
YAGNI principle within XP

Primary use case

Software development with high engineering rigor; foundation for Test-Driven Development practice; substantial influence on subsequent agile methodologies and DevOps; teaching framework in software craftsmanship; basis for many continuous-integration and continuous-delivery practices; reference for engineering-discipline-heavy agile.

Common criticisms

Full XP adoption is rare — most agile teams adopt selected practices (TDD, CI, pair programming) without the full mutually-reinforcing set, which Beck argued reduces effectiveness
pair programming faces persistent organizational resistance and varies in effectiveness based on pair compatibility
on-site customer requirement is rarely met in practice
original 'metaphor' practice was dropped in 2nd edition as it had not worked well in practice
XP's emphasis on white-room pair programming fits poorly with remote work norms (though distributed pairing has matured)
community largely absorbed into broader agile / Scrum / DevOps space
the 'extreme' branding sometimes obscures the moderate, sensible nature of most XP practices.

Lineage

Parent of: Test-Driven Development, YAGNI
Siblings: Scrum, The Agile Manifesto, Test-Driven Development