Extreme Programming (XP) is a software development methodology created by Kent Beck and first described in his 1999 book Extreme Programming Explained: Embrace Change. XP emerged from Beck’s work on the Chrysler Comprehensive Compensation System (C3) project in the mid-1990s, where he began applying and refining practices that prioritized rapid feedback, simplicity, and direct collaboration between developers and customers.

XP predates the Agile Manifesto by two years. When seventeen software practitioners gathered in Snowbird, Utah in February 2001 to produce that document, XP was already a functioning methodology with a published body of practice. Beck was among the signatories. XP did not emerge from Agile - Agile emerged from the same intellectual tradition that XP represented.

The Five Values

XP is grounded in five explicit values that shape its practices and distinguish it from process frameworks that operate primarily through rules and procedures.

Communication - problems in software projects almost always involve a failure to share information. XP structures work to maximize communication: developers work in pairs, the customer sits with the team, and code is collectively owned so anyone can speak to it.

Simplicity - do the simplest thing that could possibly work. XP teams resist building for anticipated future requirements and instead deliver the minimum that satisfies the current need. This is not laziness but discipline: simple systems are easier to change when requirements inevitably shift.

Feedback - feedback must come from multiple sources and at multiple timescales. Tests provide feedback in seconds. Pair programming provides feedback in minutes. Releases provide feedback in weeks. XP structures practices to compress feedback loops at every level.

Courage - XP asks developers to do things that feel risky: delete code that is no longer needed, tell a customer that a feature will take longer than they want, refactor working code. Courage is only sustainable when supported by the other values - you can delete code confidently when tests verify the system still works.

Respect - Beck added this value in the second edition of his book (2004). Team members respect each other’s contributions, the customer respects that the team is working in good faith, and the team respects the customer’s domain knowledge.

Core Practices

XP is defined by a set of interlocking practices. They are designed to reinforce each other - removing one often weakens others.

Test-Driven Development

TDD is the practice of writing a failing test before writing the code that makes it pass. The cycle is: write a test, watch it fail, write the minimum code to pass it, refactor. This order matters. Writing the test first forces the developer to specify what the code should do before thinking about how to do it. It also produces a comprehensive test suite as a natural byproduct of development, rather than as a separate phase.

TDD has become arguably the most widely adopted practice to emerge from XP. It is taught in most computer science curricula and is standard practice across many engineering organizations, long after XP itself has faded as a named methodology.

Pair Programming

Two developers work at one computer. One writes code (the driver) while the other reviews each line as it is written (the navigator). They switch roles frequently. Research on pair programming is mixed on raw productivity, but evidence consistently shows lower defect rates and better knowledge distribution across the team. In XP, pair programming also prevents knowledge silos - no single developer is the only person who understands a component.

Continuous Integration

XP teams integrate and test code multiple times per day. Every developer commits to the main branch frequently, and the integrated build is verified by automated tests after each commit. This practice eliminates the integration phase that waterfall projects dreaded, where code written by separate teams had to be assembled - often with significant rework. Continuous integration is now standard infrastructure across the industry, largely independent of any methodology.

Collective Code Ownership

Any developer can modify any part of the codebase at any time. No one owns a module or file. This requires discipline - changing code you did not write risks breaking things you do not understand - but TDD provides the safety net. Collective ownership means the team can refactor freely and eliminates single points of failure when people leave or are unavailable.

Refactoring

XP teams continuously improve the internal structure of code without changing its external behavior. Refactoring is not a separate phase; it is a constant activity. The test suite makes refactoring safe by immediately revealing regressions. The combination of TDD and refactoring is what makes XP’s commitment to simple design viable: you build the simplest thing now, knowing you can safely improve it later.

Simple Design

At any point, the design should be as simple as possible while passing all tests and expressing the developer’s intent clearly. XP teams do not design for anticipated future requirements. Beck described good design as passing tests, revealing intent, having no duplication, and containing the fewest possible elements - roughly in that priority order. This principle maps closely to what later writers codified as YAGNI (You Aren’t Gonna Need It).

The Planning Game

XP divides planning into two activities. Release planning establishes scope, priority, and estimated dates for a version. Iteration planning selects stories from the release plan for the next iteration, typically one to two weeks. Customers write user stories - short descriptions of features from the user’s perspective - and assign them business priority. Developers estimate each story in terms of effort. The planning game is a negotiation: customers can change scope but not estimates; developers can change estimates but customers set priority.

On-Site Customer

An actual customer representative works with the team full time, available to answer questions, clarify requirements, and make scope decisions immediately. This eliminates the feedback delay of requirements documents and specification reviews. It also means that the product being built is continuously shaped by someone who understands the business need.

Small Releases

XP teams release working software frequently - ideally to production, or at minimum to a staging environment where the customer can verify it. Small releases reduce risk by limiting the amount of unverified work in progress and providing real feedback earlier.

Sustainable Pace

Beck argued that teams should work at a pace they can sustain indefinitely. Overtime is a signal that something is wrong with planning or scope, not a solution. Consistent overtime reduces quality, increases defect rates, and eventually leads to burnout. This position was contrarian in the late 1990s software industry and remains relevant today.

XP and the Agile Manifesto

When the Agile Manifesto was written, XP was the most complete and detailed of the lightweight methodologies. The four Agile values map closely onto XP values and practices. “Individuals and interactions over processes and tools” reflects XP’s pair programming and on-site customer. “Working software over comprehensive documentation” reflects XP’s small releases and TDD. “Responding to change over following a plan” reflects the planning game’s flexible scope.

Scrum emerged around the same time as XP and addressed project management more directly. XP addressed engineering practices more directly. Many teams that adopted Agile in the 2000s combined elements of both: Scrum’s sprint and ceremony structure with XP’s TDD, continuous integration, and refactoring practices.

Lasting Influence

Several XP practices are now mainstream industry practice regardless of whether a team identifies as XP or Agile. TDD is taught as a fundamental skill. Continuous integration and continuous deployment are standard infrastructure. User stories are the default unit of work in most product development organizations. Refactoring is a recognized discipline with its own catalog of named techniques, largely due to Martin Fowler’s work which ran parallel to Beck’s.

XP’s influence is most visible in practices that spread beyond any specific methodology. The practices that required the most organizational change - the on-site customer, full-time pair programming, and sustainable pace as a firm constraint - were adopted less widely, which is consistent with how organizational change typically works.