Extreme Programming (XP)

Extreme Programming (XP) is an agile software development methodology introduced by Kent Beck in the late 1990s. Where Scrum focuses primarily on how a team organises its work, XP focuses on the engineering practices that keep software cheap to change as it grows.

The name comes from taking practices everyone already agreed were good — testing, code review, design, integration — and pushing them to the “extreme” so they happen continuously rather than at the end.

Core practices

• Pair programming — two engineers, one screen. Fewer defects, faster knowledge spread, real-time review.
• Test-driven development (TDD) — write the failing test first, then write just enough code to pass it, then refactor.
• Continuous integration — code is integrated into the mainline many times a day, not in a big-bang merge at the end of a sprint.
• Refactoring — design is improved continuously rather than locked at the start of a project.
• Small releases — ship often, in small chunks, so feedback comes from real usage rather than internal review.
• Simple design — solve the problem in front of you, not the imagined problem in six months.
• Sustainable pace — burned-out engineers ship more bugs and quit. XP treats overtime as a planning failure, not a virtue.
• Whole team — the customer (or product representative) sits with the team and is available to answer questions in minutes, not days.

XP and Scrum

Many modern agile teams blend the two: Scrum’s planning rhythm (sprints, reviews, retrospectives) combined with XP’s engineering practices (TDD, CI, pairing). Scrum without XP-style discipline tends to ship features quickly that are expensive to change later. XP without Scrum’s planning rhythm can drift from the strategic outcome the work is meant to produce.

Why it matters

XP was the first agile methodology to take engineering quality seriously as a first-class product concern. Even teams that don’t formally adopt XP rely on the practices it popularised — automated testing, continuous integration, frequent refactoring — as the cost of building software that lasts longer than the team that wrote it.