Home    Services    People    Process        More About Us

The Rules of XP

Ken Auer, President, RoleModel Software, Inc.
Erik Meade, Object Mentor, Inc.
Gareth Reeves, CSS LLC

We will boldly assert the following truths:

• XP's values make it Agile.
• XP's practices do not define XP.

So, if it's not the practices, what defines Extreme Programming (XP)?

We will briefly support these two assertions and then present a further assertion: XP is defined by its rules. Finally, we present and discuss those rules.

XP and Values
Defining XP
What About Rules?
The Rules of XP
Bending the Rules
Conclusions
Acknowledgements

XP and Values

We can say XP is an agile process because it shares the values defined in the Agile Manifesto (http://www.agilealliance.org):

• Communication - Individuals and interactions over processes and tools
• Simplicity - Working software over comprehensive documentation
• Feedback - Customer collaboration over contract negotiation
• Courage - Responding to change over following a plan

XP's values are the Agile Alliance values. SCRUM's values are Agile Alliance values. XP and SCRUM share the same values, but what makes them different?

Defining XP

Defining XP by the practices has at least two problems.

Some practices are fuzzy in definition. For example, one team's definition of having a 'Customer on site' can be vastly different from another's. To complicate matters even further, we have seen that it is possible for a team to be doing all of the XP practices and yet still not be extreme.

Another problem with this approach is it's commonly understood you can be doing XP without doing all of the practices. This was reinforced at XP Universe 2001 when Kent Beck drew the analogy that practices are etudes. For those who are not familiar with etude:

é·tude
a short musical composition for a solo instrument intended to develop a point of technique or to display the performer's skill, but often played for its artistic merit

In this paradigm, the etudes (or practices) become the path to XP, they are not what defines XP.

Many have suggested some practices are more important than others. Others have proposed additional practices. If XP were defined by it's practices it is not clear when something is or is not XP. If the list of official practices change, does something go from being XP to not XP?

What About Rules?

What makes Baseball, Baseball (and not Basketball)?

It's not the values that make it baseball. You can have different values that motivate you to play baseball. Ken values the intricacies of the game that can be leveraged by an otherwise inferior athlete to beat his opponent. Ken's 5-year old son, Caleb, values the fun of running around the bases. Their values are different. It's still baseball.

You can execute the practices almost perfectly like major-leaguers or poorly like Caleb, who is still working on hitting the ball and knowing where/when to run. The execution of practices can be vastly different. It's still baseball.

What is it that defines baseball? The rules.

Sometimes, rules clearly suggest a practice. A rule such as "You must arrive safely at first base before being put out" would imply the practice of running to first base after hitting the ball. Some rules offer wider constraints and suggest a variety of strategies and/or practices for "playing better".

We tend to think of Software Development as comparable to a game, as per Alistair Cockburn's premise[Co02]. So, the argument being put forth is that we should not define XP merely by its values or it's practices. We should define XP by its rules. Once the rules are defined many of the practices used on XP projects would be suggested, while still leaving room for a variety of strategies or practices that help us "play better".

The Rules of XP

So what are the Rules of XP? One of the main reasons the three authors have come together from different organization is to validate that the rules apply across a variety of organizations. Each of our organizations have different ways in which we apply these rules. Each of us have been involved in multiple XP projects whose implementations of XP have varied. Lastly, each of us have seen projects which attempted to do XP but fell short in one way or another.

We've chosen to categorize the rules of XP in two parts: The Rules of Engagement and the Rules of Play.

In baseball, the Rules of Engagement could be thought of as those that define the size of the field, the size of each team, an inning, the number of innings, etc. The game can't begin without the Rules of Engagement. These rules are prominent when a contest is arranged and begun, but they are also present throughout the contest. However, due to the intensity of the Rules of Play during the playing of the game the Rules of Engagement become less prominent. Without them, you don't have an identifiable game. But they don't really define the minute-by-minute activities, only a framework under which those activities take place.

The Rules of Play happen within the Rules of Engagement. Together, they define the minute-by-minute activities. During a game, the Rules of Engagement can often seem a distant thought. The Rules of Play in baseball include "pitcher pitches a ball toward home plate while batter is in the batter's box...", and all the other rules determine what legally happens once the pitch is set in motion, a runner is on base, etc. When a batter is having a ball coming at him at 90+ miles per hour, he is not giving much thought to the number of innings in a game or what inning he is currently in. If the pitch goes by him, he takes a step back and ponders those things the Rules of Engagement define. He steps back into the batter's box and a subset of the Rules of Play take over his mind.

So, in XP, we have the following Rules of Engagement:

As we've developed these rules and have become familiar with other Agile processes, it seems that these rules may be very similar to those of other Agile processes. We certainly do not believe we can assert this with authority, but we suspect they are at least similar. However, whatever similarities they might possess in their Rules of Engagement, XP seems to differentiate itself from other Agile processes in its Rules of Play. The Rules of Play are simple, they happen within the Rules of Engagement:

It is these Rules of Play which make XP fundamentally different than other Agile processes. In fact, if we could name the whole process over, we would call it "Extreme Software Development" and following the Rules of Play would be called "Extreme Programming". (Then the development team could be Extreme Programming even if the Rules of Engagement were not followed...which evidently appears to happen often in the industry. Extreme Software Development would not occur until both sets of Rules were followed).

Bending the Rules

The rules listed above are the summarized version of the complete rules of XP. The details of each of the rules are left out because this paper is meant to make a point about the necessity of rules in general, and these rules in particular, not to be an exhaustive rulebook.

That said, some rules have more flexibility than others.

In baseball, you can bend the rules a little, and still arguably be playing baseball. When Ken plays with his kids there are less than the regulation number of players and he only gets one out per half-inning and they get three. It's not "official" baseball. It may or may not be a better game given the context. Get rid of the baseball, the bat, or the bases, and it's NOT baseball at all... not even "unofficial" baseball. The points at which it goes from "official" baseball to "unofficial" baseball to "not" baseball is somewhat fuzzy and could certainly be argued. However, it should be clear that when the context of the game permits all the rules to be used, they should be. And when they can't be, it is certainly not "official" and something is lost.

Given some context, some form of "unofficial XP" might be the right thing to do. Often, however, adjustments can be made within the rules that may be "unorthodox" while still "official XP". In baseball, you can legally play with five infielders and two outfielders or, you might temporarily have a pitcher switch to the outfield.

We've tried to define the rules in a manner that identifies which rules are the most flexible. For example:

Timeboxing (E6)
Timeboxing is important for providing feedback and also for forcing key decisions. One, two, and three weeks have been vehemently argued by experienced XPers as the ideal size of an iteration. Often these arguments are strongest given the constraints of the environment in which one is working. There have been known cases where developers used short (e.g. one or two week) "internal iterations" and longer (e.g. four weeks or three months) "external iterations" to publish results to an audience wider than the team. However, we find it hard to imagine a situation where it was not vital to have internal iterations of a month or less. Go over that, and you may still be doing "unofficial" XP. Get rid of the idea of iterations altogether, and you're doing something else.

Continuous Validation Through Testing (P1)
The best way to do this is certainly to have automated tests and keep them in a state such that they can be run very quickly. This is a practice that eXPerts do very well most of the time. However, there might be environments and teams where, for at least a period of time, it is difficult to achieve this level of excellence. "Automated Tests" is a practice that is a "fundamental strategy" to XP. Without it, you probably won't execute XP as well. This is somewhat analogous to the strategies and practices that experienced baseball players treat as second nature such as where they are positioned in the field to maximize their potential to limit progress by their opponents. An inexperienced ballplayer might miss these things or at least execute them poorly in spite of having a good coach, but would still be playing the game of baseball. Even the most experienced ballplayer might occasionally come up against a situation he's never seen before and won't know "the best thing to do".

Measuring Progress Toward Objectives (E4)
Again, the best way to do this is to have the customer write acceptance tests that can be run automatically regularly (e.g. nightly) and whenever desired. Early in a project, it is often difficult to do, and there may be certain types of requirements or contexts in which it makes sense to do some of this measurement manually or less often. But, if the customer can't identify what's done and what's not, you're not even doing "unofficial" XP.

Other rules, worded in order to keep them succinct, might need their points of flexibility made more explicit. For example:

Customer Sets and Adjust Priority (E2)
In reality its not always possible and sometimes not even logical to have a single customer set the priorities and define the objective of the system in detail. Often this takes a team of people. At times, there may be people who have to wear both a "customer" hat due to their subject matter expertise as well as a "developer" hat. As long as the "hats" are made explicit, this would be an acceptable bending of the rule. If a manager who "knows the business" sets and adjusts priorities, you may be doing "unofficial XP". If the developers do it, you are doing something else.

Test-first Programming in Pairs (P2)
We've yet to hear of a great answer as to how to do test-first for certain types of user interface development. If no one on the team can figure out a useful test for some subset of the code, you can probably identify it as an exception. If you program in pairs but have a bunch of exceptions that encourage code to be written by individuals at times, you have stepped over the line to "unofficial XP". If not writing the test first becomes the rule rather than exception, you are playing a different game!

Other rules, though a bit vague, just don't have much room to bend. For example, the team MUST act as an Effective Social Network (E5). RoleModel recently had a client that was doing virtually all of the practices of XP (they weren't doing all of them well, but they were doing them). We would assert that they were not doing XP, but not because of their sometimes poor execution of the practices. The fundamental issue was that they were not acting as an Effective Social Network:

1. They did not have open, honest communication between management, the customer(s), and the development team or even within the development team.
2. There were often dictates made by management that got in the way of progress (e.g. you must use Lotus Notes for project tracking even though "off the shelf" Notes didn't provide the capabilities needed. Of course, you cannot use Notes until you've attended an official training class on it. There was a long waiting list for the class and it might take months until one could actually attend. And contractors were not going to be given such a class. No Notes Programmer was made available to the team at first and, when they eventually were, they had limited availability and had to clear everything they were asked to do through some third party).
3. Some people, namely "contractors", were second-class citizens. If "employees" didn't like something the contractors suggested, they would make decisions without them and then dictate the way things were going to be done. The fact that the coach was a contractor made it very difficult for him to actually coach.
4. Meetings with people from the customer team had to be scheduled. A lot of time was spent by the developers talking about how to spin the discussion with the customer to make the developers look like they've thought it all through. Often this discussion included debate whether they should even expose any uncertainty to the customer.

Conclusions

There have been many discussions over what exactly defines XP over the past several years. There have been presentations and articles written about experiences with XP that have gotten XPers in a huff because the authors/presenters "clearly didn't understand what XP was". Most published attempts at defining XP have discussed its values and practices and often include a disclaimer that you can do XP without doing all of the practices. Since it's listed values read somewhat like "motherhood and apple pie", they have fallen far short of defining XP. It's changing list of practices as well as the statements about moving beyond the practices and discussion of "less essential" practices has made it difficult to identify what XP really is. This has left a real void because shared definitions are important in order to have effective communication be it critical or instructional.

Once a game is defined by its rules, the rules seldom change significantly. However, players learn effective strategies and constantly refine their execution of those strategies. New strategies are often being explored. The most effective ones eventually become commonplace... until a better strategy is discovered.

Ken possesses a copy of a small book entitled "Official Baseball Rules"[Sport86]. It exhaustively defines the game of Baseball. Until this paper was written, there has been no real source for the equivalent definition of XP. When we look at the Rules of XP, it is much easier to identify what XP is than trying to define it by the 12, 13, or 19 practices (+/- 2 that are "less essential").

However, the Rules only tell you enough to play the game - not enough to play it effectively.

Ken also possesses a copy of "The Complete Book of Baseball Strategy"[Wolf74]. It provides a list of 169 "Stratagems" (practices?) many of which are generally applicable as well as some that are specific to people in different roles (First Baseman, Pitcher, Coach, etc.). It also provides a series of drills (the equivalent of etudes?) that "drill" the stratagems into players. Of course, even though the title includes the word "Complete", there are certainly useful stratagems that can be found (either explicitly or by reading between the lines of the experiences of others) in other books and resources. We would suggest that the majority of the XP literature to date has provided the moral equivalent of basic (the practices) and situational stratagems to help their readers execute better. There are more stratagems to be explored.

Now that we've got that cleared up, let's play ball!

Acknowledgements

This paper was inspired by a rash of e-mail discussions among several others including Kent Beck, Alistair Cockburn, Ward Cunningham, Jim Highsmith, Ron Jeffries, "Pragmatic" Dave Thomas, and Don Wells to whom credit is due for both their contributions of ideas and getting Ken's thoughts out of his head and into writing. Thanks are also due to the other participants at the OOPSLA 2001 Workshop "Refining the Practices of eXtreme Programming" who provided much input based on discussions of Ken's original position paper to this workshop.

[Co02] "Agile Software Development", Alistair Cockburn, Addison-Wesley Pub Co, 2001
NOTE: Alistair compares software development to a cooperative game like rock climbing. Although we concur with many of the points of the comparison, it is more realistically a "cooperative game" internal to an organization and a "competitive game" outside of the organization... either way, we need to know the rules.
[Ke01] "Continuous Learning", Joshua Kerievsky, http://www.industriallogic.com/xp/ContinuousLearning.pdf
[Sport86] "Official Baseball Rules" published by "The Sporting News", 1986
[Wolf74] "The Complete Book of Baseball Strategy", Hal Wolf, Exposition Press, 1974