Agile vs. XP: The Differences and Similarities
by Robert C. Martin
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.
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.
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.
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.
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.
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.
Code, and other work artifacts, are not owned by individuals. Any member of the team may work on any artifact at any time.
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.
Names within code and other work artifacts are chosen to be evocative of the system being created.
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.
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.
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.
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.
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:
This set of values was accompanied by a set of principles, agreed to by all:
Principles behind the Agile Manifesto
We follow these principles:
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.