Scaling Extreme Programming

Any thoughts on how this could be accomplished? It seems to be one of the major criticisms fired at ExtremeProgramming.

Here's one idea:

Perhaps ScalingExtremeProgramming can be achieved with a DivideAndConquer technique. A large project can be split into several smaller XP projects where the customers are played by feature leads. The feature leads in turn answer to the real customer. Subdividing until you get to reasonably sized XP projects seems feasible at least in theory. -- RobHarwood

If your decomposition leads to a hierarchical architecture, I think you break the user story scenario. I believe the user requirements from a higher level to a lower level will surface one at a time and be needed immediately for the higher level pair to continue working. A lot of planning and early interface definition is needed to keep a partitioned project on track and this may break the XP work flow. Interface stubs may help, but you still tend to get a big bang integration effort. -- WayneMack

From LargeExtremeProgramming:

One way of combating this might be IntegrationTeams?, which would form the internal nodes of a scaled XP project, with regular XP teams forming the leaf nodes. One integration team could play customer to 3-5 XP teams, say. And integration teams might play customers to other integration teams in a tree hierarchy. The practices might be different than a traditional XP team. For example, testing would play a very large part of the integration team's responsibilities. They would generate AcceptanceTests for their sub-teams and UnitTests (of sorts) for their own integration efforts. I've never worked on a project bigger than 4 programmers, so all of this is naive speculation, but perhaps others could elaborate with their own ideas? -- RobHarwood

Why would you go to all the trouble to flatten out the hierarchical communication structures that distort communication within the team only to reintroduce at the next higher level? How could you create a flat structure of teams?

Umm... I think the answer is obvious: For the purposes of ScalingExtremeProgramming. ;-) Creating a flat structure is a matter of branchiness. Maybe the integration teams could handle up to 10 other XP teams? A branchiness factor of 10 would go a loooong way. Already you've got the possibility for teams on the order of 100 people. Who knows? As I said, it's only naive speculation. -- RobHarwood

But why don't you use a slightly different set of rules at the larger scale and count on emergence to control the product of the uberteam rather than create a hierarchical social/communication structure?

When I finish parsing that question, I'll try to answer. ;-)

I'm terribly sorry. Using less grammar:

XP relies on the interaction of simple rules within a team to produce reliability, reusability, maintainability, flexibility, etc.
If you want the same properties to emerge at a larger scale, one strategy is to find a set of simple rules.
Self-similarity suggests that these rules will look much like the rules within the team, but that the teams will be acting like the individuals.

Isn't this more or less what I'm suggesting? -- RH

Not as I understood it. You want one team that integrates the work of the other teams. On a single team this is like the IntegrationCzar?. But XP spreads the work of integration to all programmers. How could the work of large scale integration be spread to all teams?

I'm seriously not understanding the question. Sorry. How could the work of large scale integration be spread to all teams? By off-loading some of the burden to integration teams, just as I said. Was this a criticism or just a miscommunication? Am I missing something? Can you cite a specific example of what you're pointing at? I'm just assuming that problems can be solved with ridiculous simplicity (i.e. same team structure for nodes as leafs). -- RH

This is wild speculation, but...

If my team uses your team's code/library/interface, then I'm your customer.

How do the teams line up their iterations? If the using team needs a change to the interface, do they have to wait for the next iteration from the library team? Or does the library team merely work on an ad hoc basis and bypass the PlanningGame?

Maybe XP teams should have "fuzzier boundaries" than typically found in development organizations: Do PairProgramming across team boundaries on code that is near any boundary.

I've seen PairProgramming across team boundaries work on a very big project. It started as pair debugging, became something like pair design, and ended in PairProgramming. The team boundaries was actually the boundary between two major components of the system. Unfortunately, it was only two people doing it, and they've never heard of XP. -- OliverKamps

To add to the previous comment, why not split the (large) project up into almost entirely independent projects of a reasonable, smaller size? Where there are dependencies between projects use agreed, but changeable, interfaces and a continuous integration tool (such as Apache Gump - http://gump.apache.org/) to give early feedback on when things break between teams -- PaulBrowne

See LargeExtremeProgramming, ExtremeProgrammingMayScaleUp

[These three pages, plus TomsTalkAtXpImmersionThree and ExtremeManagement, could probably use a good ReFactoring. I personally prefer the WikiName ScalingExtremeProgramming to the other two. -- RobHarwood (Who isn't confident enough yet to try the refactoring himself.)]

CategoryExtremeProgramming