Introduction

I have this belief about why XP (and perhaps other "agile" development processes) can't scale up. It's similar to why I had problems with heavyweight development processes (think CMM) scaling down. In both cases, the approaches focus on a set of problems that exist in the target environment (small-scale development for XP) that don't exist in the other environment, and they miss important problems that don't exist in the intended environment but do exist in the other environment. In either case, you can't take the process and simply add more people (or in CMM, take people away) and expect it to work.

Hypothesis: The current set of 12 practices commonly referred to as Extreme Programming, as defined in [Beck2000] and [Jeffries+2000], does not scale.

To prove a negative is difficult, often approaching impossible. We are left, therefore, with a proof by contradiction we assume the hypothesis and show that it can't be achieved. Such is the case with this hypothesis. In this chapter, I argue that XP as the four values is inherently scalable, but these 12 particular practices prevent the values from scaling. I then propose some new practices that alleviate the failings of the existing practices in the particular case of large projects. No comments are made relative to these approaches for small projects.