In common usage the terms XP and Agile are sometimes used to mean the same thing, and sometimes to mean very different things. What are their origins, and what are their true definitions. Is Agile the same as XP? Is XP Agile? We’ll answer those questions here.

XP

The term XP predates the term Agile by several years. XP stands for Extreme Programming, and is a suite of practices, principles, and values invented by Kent Beck in the late ‘90s. Nowadays the principles and values are not as well known, but the practices survive. Those practices are:

The Planning Game

Development proceeds in very short iterations, typically 1-2 weeks in duration. Prior to each iteration features are broken down into very small stories. Stories are estimated by developers and then chosen by stakeholders based on their estimated cost and business value. The sum of story estimates planned for the current iteration cannot exceed the sum of estimates completed in the previous iteration.

Whole Team

The team consists of developers, business analysts, QA, project managers, etc. The team works together in a lab space or open area where collaboration and communication are maximized.

Acceptance Tests

Stories and features are defined by automated tests written by the business analysts, and QA. No story or feature can be said to be done until the suite of acceptance tests that define it are passing.

Small Releases

Systems are released to production, or pre-production very frequently. An interval of 2-3 months is the maximum. The minimum can be once per iteration.

Continuous Integration

The whole system is built and tested end-to-end several times each day. While new tests are made to pass, no previously passing tests are allowed to break. Developers must continuously keep the system in a deployable state.

Collective Ownership

Code, and other work artifacts, are not owned by individuals. Any member of the team may work on any artifact at any time.

Coding Standard

Code, and other work artifacts, look as if they were written by the team. Each team member follows the team standard for format and appearance of the artifacts.

Metaphor

Names within code and other work artifacts are chosen to be evocative of the system being created.

Sustainable Pace

Building software is a marathon, not a sprint. Team members must run at a rate they can sustain for the long haul. Overtime must be carefully controlled and limited. Tired people do not win.

Pair Programming

Code and other work artifacts are produced by pairs of individuals working together. One member of the pair is responsible for the task at hand, and the other helps out. Pairs change frequently (every two hours or so) but responsibility stays with the owner.

Test Driven Development

Developers are not allowed to write production code until they have written a failing unit test. They may not write more of a unit test than is sufficient to fail. They may not write more production code than is sufficient to pass the failing test. The unit tests are maintained and executed as part of the build process. No previously passing unit test is allowed to fail.

Refactoring

Code, and other work artifacts, are continuously reviewed and kept as clean as possible. It is not sufficient that code works; it must also be clean.

Simple Design

The simplest design that suffices for the task at hand, is the right design. More complex and general designs may become useful later, but not now. We do not wish to carry the weight of that complexity while it is not needed. Sufficient for the day are the complexities therein.

Agile

XP was one of several so-called “lightweight” methods. Others in that category were SCRUM, DSDM, Crystal, FDD, etc. Each of these methods was created as a reaction to the consistent and increasing failure of the heavier, waterfall derived methods. Each of these lightweight methods had it’s own set of principles, values, and practices. Each was championed by its own group of adherents. In February of 2000, Object Mentor called a meeting of these adherents in Snowbird, Utah. The purpose of that meeting was to see whether or not we could merge the values and principles of the various methods into a consistent whole.

Remarkably, the attendees of that meeting managed to set aside their differences and worth together to form a manifesto, and then a set of principles that encompassed all of the lightweight methods. They also came up with a name. They called it: Agile. The Agile Manifesto describes the values we chose:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

This set of values was accompanied by a set of principles, agreed to by all:

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Conclusion

XP is a set of practices that conform to the values and principles of Agile. XP is a discrete method, whereas Agile is a classification. There are many Agile methods, XP is just one of them.

Having said that, none of the other Agile methods are as well defined, or as broad in scope as XP. Scrum, for example, is roughly equivalent to XP’s Planning game practice, with elements of Whole Team. While there are differences in the details, it is fair to say that Scrum is a subset of XP. Indeed, many Scrum teams augment their process by adding in many of the XP practices such as Acceptance Testing, Pair Programming, Continuous Integration, and especially Test Driven Development.

Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way developers do their daily work. Of those disciplines, Test Driven Development is the most revolutionary and impactful.