Extreme Programming

Extreme Programming, created by Kent Beck, is an agile software development methodology defined by a specific set of engineering practices — unlike Scrum, which mostly defines roles, artifacts, and events without prescribing how the code itself gets written, XP prescribes the technical discipline directly: pair programming, test-driven development, continuous integration, and frequent, small releases, aimed at improving software quality and responsiveness to changing requirements.

The five values

• Communication — most project problems trace back to something not communicated; XP's practices (pairing, on-site customer, collective ownership) are largely designed to force communication that a document-based process would let slide.
• Simplicity — build the simplest thing that could possibly work for today's known requirements, rather than speculatively designing for requirements that may never arrive.
• Feedback — get real feedback as fast as possible, at every level: a unit test gives feedback in seconds, pair programming gives feedback continuously, a short release cycle gives feedback from real users within weeks rather than months.
• Courage — the willingness to make a needed change (refactor working code, throw away a bad design, tell the customer an estimate is wrong) even when it's uncomfortable, because the other four values give enough safety net to act on it.
• Respect — every team member's contribution is valued; practices like collective code ownership and sustainable pace only work in a team that genuinely respects each other's work and limits.

Core practices

• Pair programming — two developers work at one workstation, one writing while the other reviews in real time and thinks ahead; catches defects immediately rather than at a later review stage, and spreads knowledge across the team as pairs rotate.
• Test-driven development (TDD) — write a failing test, write the minimum code to pass it, then refactor; keeps the codebase continuously covered by tests that were written before the implementation they verify, rather than added afterward (or not at all).
• Continuous integration — integrate and test code changes multiple times a day rather than in large, infrequent merges, so integration conflicts surface small and early instead of large and late.
• Refactoring — continuously improve the code's internal structure without changing its external behavior, keeping the design suited to today's actual requirements rather than accumulating the debt of "simplest thing that worked at the time" left unrevisited.
• Collective code ownership — any pair can improve any part of the codebase at any time, rather than code being siloed to whoever originally wrote it — this requires the shared coding standards and test coverage the other practices provide to be safe.
• Small releases — release working, valuable software in small increments, keeping the feedback loop with real users short.
• Sustainable pace — work at a pace the team can sustain indefinitely (historically stated as "no more than 40-hour weeks"); chronic overtime degrades the judgment and code quality the other practices depend on.
• On-site customer — a real customer or customer representative is available to the team continuously, answering questions and clarifying priority in real time rather than through a specification document.

XP vs. Scrum

XP and Scrum address different layers and are commonly used together: Scrum defines the team's roles, planning cadence, and ceremonies (what to build, in what order, on what rhythm); XP defines the engineering practices for how the code itself gets built well within that cadence. A team can run Scrum's sprints without any of XP's technical practices (and often ships lower-quality code as a result), or run XP's practices without Scrum's specific role/ceremony structure.

Common pitfalls

• Adopting pair programming or TDD as a checkbox without the supporting values — the practices depend on genuine communication and courage to work; performing them mechanically (pairing in silence, writing tests after the code purely to hit a coverage number) loses most of their actual value.
• Skipping refactoring because "it isn't a feature" — without ongoing refactoring, "simplest thing that could work" accumulates into a design that no longer fits the system's actual requirements, eventually slowing delivery of genuine features.
• Chronic overtime treated as normal — undermines sustainable pace and, empirically, the judgment quality the other practices depend on.
• No real on-site/available customer — without fast access to real priority and requirements answers, the team either stalls on decisions or guesses, undermining the fast-feedback premise the other practices are built around.

Learn more

• Scrum for the complementary process/role framework XP's engineering practices are commonly run inside.
• Agile Principles for the underlying values XP's specific practices operationalize.
• Kanban for a contrasting, flow-based process model XP's practices can also pair with.