The Five Reasons

In particular, these are the five reasons XP can't scale.

• Pair programming expands quadratically.

• Planning game is too introspective.

• Collective ownership leads to chaos.

• Metaphor is too weak.

• No means to effectively coordinate multiple teams exists in the other practices.

When I use the term "scale" here, I mean for teams and problems of a size larger than XP was intended. I don't know what this number is, but let's say it's somewhere between 10 and 20 team members and some number of function points (or other metric) in a period of time that is beyond the capacity of a given team. There is likely a bias in this discussion toward a model of scaling XP that implies multiple (roughly) coequal teams. I recommend against scaling XP into one large team, because it seems to magnify the issues without providing a means of mitigating them. Indeed, Brooks [Brooks1995] notes the issues associated with building teams that are too large.

Pair Programming Expands Quadratically

Pair programming (PP) is too broad a term for anyone to claim that it doesn't scale. In fact, there's likely nothing about PP alone that doesn't scale, as long as it focuses only on the programming task itself the arrangement of two programmers collaborating in real time to solve a problem. The part of PP that doesn't scale is its use in XP beyond the programming task itself. PP in XP is used to provide a medium to communicate design [Williams+2000] and familiarize developers with the code base. The communication paths of pairs in a team grow as the square of the number of members in the team; double the team size, quadruple the communication paths.

As the team grows in size, it may become distributed to other buildings, other cities, or even other countries. Complexity is added to the pairing process we have to coordinate across sites, time zones, and languages. Local cliques creep in; teams focus on parts of the system and avoid others. A partitioning of system knowledge has occurred, but not a rational one. The system has now become N interacting systems and N interacting teams, yet there is no reasoned approach to this interaction, and there is no mechanism for coordination.

Planning Game Is Too Introspective

The planning game is a means to ensure that the team works on the most important tasks at any time. As the team grows, the number of tasks grows as well. As the project grows in scope, the amount of important work grows correspondingly. As both grow, their effects multiply. Combine this with distributed teams and we have a problem: There is no means to ensure that each team is working on the right things relative to the other teams. You can use the cop-out answer that "The customer coordinates this by picking what's important for each iteration," but would you want the customer to be exposed to this degree of your development process? Is it really the customer's responsibility to help you resolve your development difficulties? I don't think so go back to one of the tenets of the approach: Customers make business decisions; engineers make technical decisions.

It is likely (and has occurred several times in my experience) that a team needs to work on a less important (from the business perspective) task to ensure that an important systemwide behavior is available. Alas, there is no XP means to do this, because there is no overall coordination role defined in XP.

Collective Ownership Leads to Chaos

Collective ownership is a good thing in XP. It enables work to proceed without depending on a particular individual to do the work. That individual may know the area better than others, but the risk of that individual becoming a bottleneck is reduced through collective ownership. Unfortunately, as the scale grows, collective ownership changes from a benefit to a potential source of churn and complexity. The churn comes from two developers (or two pairs) adding conflicting features to the code base. The complexity comes from resolving the interactions of these new features, even when they're not directly conflicting but only cohabiting. Add to this the requirements on tools to support this type of problem resolution, and a huge potential risk has been added to the technical side of the project. Bring on the bonus of no overall coordination and it's game over.

Metaphor Is Too Weak

Metaphor is the least well defined of the XP practices. My reading of metaphor indicates its use as a general compass for understanding the solution space. This use of metaphor is sufficient because PP continually reinforces the metaphor.

Metaphor is insufficient as design, though, because its relationship to the solution is often rather loose. Indeed, as the team size grows, the ability for the metaphor to be sufficient decreases. Combining this with the decreasing ability of PP to meet the communication needs of the team leads to a team that can quickly diverge instead of converge.

No Means to Effectively Coordinate Multiple Teams Exists in the Other Practices

As noted earlier, there is no notion of coordination across teams in XP, because XP is oriented at a single team. This is one of those items left out of XP because it was not an issue in the target environment of XP. However, this leaves a dilemma for scaling XP: Either scale XP by making a single large team, risking collapse under the communication burden; or scale XP by growing several collaborating teams and risk collapse because of lack of coordination.