Xp May Not Scale

I see RonJeffries and WardCunningham suggest on HundredPersonProject, ExtremeProgrammingBoundaryConditions, CollectiveCodeOwnership, LargeExtremeProgramming, ExtremeProgrammingMayScaleUp (...) that there's no good reason to think XP won't scale up as-is. Ron and I are also giving this topic a shelacking in private email.

But, given that other methodologies have problems scaling, the burden of proof actually seems to be on the XP adherents. Rather than repeat my list of UsualSuspects? for scaling problems, I'd like to see here a functional explanation of how XP will scale where other methodologies won't. --PeterMerel

If XP scales any better than other methodologies, it will be because

XP aims to do the smallest possible amount of anything that isn't producing the product;
XP uses testing to know exactly where you are;
XP reduces risk early on;
XP values direct, high-quality communication;
XP values simplicity;
XP embraces change.

It should have been called Rational Programming, not ExtremeProgramming - but Rational was taken. --RonJeffries

I tend to think nothing in life scales completely. Logic tends to scale, but only because it is independent of physical constraints. Once those constraints are introduced, complete scaling falls by the wayside. Human systems have physical constraints. Human attention and capability are not infinitely elastic.

If we take it as given that XP as a human system will not scale completely, the question becomes: are there properties of XP which make it scale better than other development processes. -- MichaelFeathers

Are you thinking of scaling in project size or problem size? (you will answer, Both, of course). But the two scale differently. --AlistairCockburn

Agreed. I started thinking "okay, let's hold the problem size constant and throw people at a project. What happens?" Then.. "let's hold the people constant and throw more problem." The former is the FredBrooks scenario and we know what happens. The latter just means that we have a lot of work. The amount of work does not make things go faster or slower. I suspect that the real issue is StoryContention?. How many (and which) stories can be concurrently developed without people tripping over each other if the main means of communication is the CodeBase? Further, I wonder what impact the size of the CodeBase has on development if we see it as a communications medium. What happens in a long lived system? Does the CodeBase inevitably grow and muddle communication, or will refactoring keep it in check?

I just noticed NoSuchThingAsSize. Perhaps I'll shuttle this over there? -- MichaelFeathers

[Hard to believe this page hasn't been touched in three years: since 24-Apr-1998!]

Since the above was written, people have become more aware of the particular practices in XP that make scaling up (number of developers, problem size, code size) difficult. The two that I think pose the biggest problems are:

For some observations about scale, and how to hybridize XP with a heavyweight methodology, see MethodologiesAndScale. --GeorgePaci

''[2010 and we're back to it] How would either of the above practices affect scalability in a negative way? Seems to me that, done right, they would both scale quite well, especially the latter would benefit from economies of scale.

Moved from SizeMatters

KentBeck states in ExtremeProgrammingExplainedEmbraceChange ( page 157 ) that:

Size clearly matters. You probably couldn't run an XP project with a hundred programmers. Nor fifty. Nor twenty, probably. Ten is a definitely doable. With three or four programmers you can safely shed some of the practices that are focused on programmer coordination, like the Iteration PlanningGame. The amount of functionality to be produced and the number of people producing it don't have any sort of simple linear relationship. If you have a big project, you might want to experiment with XP -- try it for a month with a small team -- to see how fast you might be able to develop.

"...small sharp team, which by common consensus shouldn't exceed 10 people." from TheMythicalManMonth

CategoryExtremeProgramming