Methodologies And Scale

Problem:

Heavyweight methodologies (e.g. RUP) don't seem to work very well for a lot of projects. But they have a lot of nice theory in them, and have been polished by a lot of abstract analysis and discussion, so there's a sense that there's something to them.

Lightweight or agile methodologies seem to have a lot of success in certain areas. But there's a persistent concern about extending them to other areas: areas with more developers, more geographical separation between developers, and more distance to the nearest customer.

Obscure Physics Analogy:

In the late 1960s, a physicist noticed some similarities between the resonances in atomic nuclei and ordinary, large-scale resonances. He proceeded to treat the nucleus as if it were bound together by a "string", and looked at all the energy states the string could have. His approach was very clever, had a lot of interesting theory to it, and looked like it had something to it. It's just that it wasn't that good a description of atomic nuclei when compared to existing theories.

Several years later, another physicist was trying to explain some things about subatomic particles, which are usually thought of as being points. He resurrected the string approach - at a very, very different scale. This time, the description was an improvement over existing theories, and got rid of a lot of singularities, and gradually grew into StringTheory and SuperStringTheory?.

So the beautiful theoretical stuff was actually valuable - just not at the scale at which it had originally been applied.

By-Now Painfully Obvious Point:

Heavyweight methodologies might actually be extremely valuable - but at scales much larger than most current software development occurs at.

Refinement:

"Scale" actually covers a multitude of things:

how many people are on the project (the usual meaning)
distance between developers (minimum, maximum, average)
distance to nearest customer

(where "distance" means, "How expensive is it for these two to communicate?". So same room is the minimum, corners of the same floor further, then working from home - unless you have good a telepresence system, in which case same floor and home are equal.)

I think it could be extended to cover other dimensions along which we think XP doesn't extend:

(inverse of) maximum allowable difference between system's behavior and correct behavior (so a need for high reliability would increase the scale)
average life of requirements (so systems where the requirements change slowly would have a larger scale)

There's a widespread idea that SmallTeamsAreGood?, and if you have a problem you can't solve with a small team, you should apply DivideAndConquer: split the problem into smaller problems, and sic a small team on each one of them. At small team scale, you'd want to use an agile methodology, such as XP.

Now you have some problems with inter-team communication: there are suddenly interfaces that need to be stable, and code that team A needs changed, but is owned by team B, etc. But we have these beautiful, abstract, theoretically impressive heavyweight methodologies lying around, which were constructed just to solve problems like these. So use them.

But keep the heavyweight methodologies confined to the large-scale stuff:

Don't make little use cases for how to format phone numbers.
Do make big use cases for high-level interactions between users and the system.
Don't make little design decisions about whether to use UDP or TCP.
Do make big design decisions about what subsystems or layers you need (because that's how you know what each team will be doing).
Don't produce lots of detailed documents for how all the parts of each subsystem communicate internally.
Do produce a few documents describing what each subsystem is responsible for, and how it communicates with other subsystems. Start with just the simple, obvious communication needs, and add other interfaces when you need them - using the heavyweight methodology's process for changing the document.
Don't make the detailed requirements document the customer produces cover everything down to the last detail.
Do make sure each team gets an OnSiteCustomer.

As with any hybrid, there's some duplication, and resultant extra effort and confusion. But it should be pretty clear from scale alone where to apply XP and where to apply RUP. For example, if I'm changing an object that my team alone uses, I follow XP. If, however, I want to change an interface another team uses, I use RUP.

Maybe RUP knowledge is only needed by a few people: the manager or team leader or designated inter-team person on each team. Then I'd go to our RUP guy and ask him to get the change done. I suppose it would turn into a UserStory for the other team, and we'd negotiate to get it put into their next iteration (or their current one, if it's urgent).

In the meantime, there's probably some way I can adapt to the new interface inside our software; maybe all the other team will end up having to do is to move my adaptor over to their subsystem.

Irresponsible Speculation:

There may be some surprising new ways (made possible by the lightweight methodology) to deal with inter-group communication. PairProgramming, in particular, seems promising.

Returning to the interface-change example above: when the other team wants to accept the changes to the interface that my team has made, the person doing the work would naturally pair with me. This beats the hell out of working from a revised interface spec, or even a how-to document: the actual guy who actually made the change (me) will be right there alongside him as he modifies his code to deal with it. That could definitely take the sting out of an interface change.

And, of course, we'll know we haven't broken anything because he'll have a big suite of UnitTests for his team's subsystem.

Teams might also get switched around for certain kinds of tasks. For instance: declare the last iteration before a big release the Optimization Iteration (this is not so different from the widespread industry practice of doing all the optimization in the first release after a big release). Form new optimization teams by dealing out members of the subsystem teams - now each team should have at least one person familiar with each subsystem. Each optimization team is assigned some optimization tasks; wherever the optimization takes them, they can go. If they need to move some things around between subsystems, they might still have to get the other teams' buy-in, but at least some member of each subsystem team is there to (a) justify it to his subsystem team and (b) guide his optimization team in doing it correctly.

Practical Predictions:

No way in hell is a RUP organization going to hybridize it with XP for a project. So the above judicious use of each methodology at its appropriate scale will first happen:

at an XP shop that runs into a scale problem (in the broad definition of "scale" above)
on a geographically-separated OpenSource development project, where nobody is a purist about either lightweight or heavyweight methodologies anyway
in a small company whose Napoleanic founder decides he wants his own software process to brag about in his marketing literature, but isn't quite enough of an egotist to do all the work from scratch (plus, "The best of both worlds!" looks good on a brochure).

That's my thought for the day. What do you think about (a) the Scale Matters thesis; (b) the details of crossbreeding XP with a heavyweight methodology; and (c) whether this will ever happen? -- GeorgePaci

I like it (mostly because I mumble similar thoughts, so obviously we're both correct :-). Scale Matters, yes, and nice list. Hmmm on the crossbreeding... and I think it's already happening in a few places (emphasis on few). -- AlistairCockburn

I would suggest that larger scale projects do not require different methodologies. Instead, in larger projects, the weaknesses in a methodology cannot be fixed via brute force as in smaller projects. Thus, methodologies should scale downward, but not necessarily upward. I would also state that the "heavyweight" methodologies don't do very well in large scale projects and alternatives are needed in large scale projects as well. Finally, a pragmatic note. We need a consistent methodology across projects of all scales if developers are to carry experience from project to project. -- WayneMack

What about a gradual way into this? I imagine a small team of rebels starting XP in a large RUP organization. Will they survive without the benefits of other teams doing XP as well, or will they tire from fighting heavyweight architects and managers, and surrender their agile island to them?

My guess is that it won't hurt the product to have just a few of a large number of teams do XP, while the rest hangs on to their own heavyweight process. It may not be easy, and at least some team members should be fluent in both processes and know their way around the organization to get things done. But it could work. -- EelcoRommes

In managing a team doing "not quite XP, but light" as a subcontractor to a CMM Level 4/ISO 9002 house, I can say the development team loves it, but I as a manager hate it. We are running essentially two parallel projects, a development project and a documentation project. I spend most of my time churning out documentation and rarely pull any of the development team away from development. In general, I can keep the document stream occurring fast enough that the developers do not have to sit around and wait to do work. And guess what? Management loves it (though they are careful not to look too closely). Our team is considered a model because we get our documentation out on time, it has sufficient bulk, and is grammatically correct. The software we are releasing to independent test is coming back without errors found. The users are happy; they are receiving updates every 4 months and they get to choose what to include in the update.

CategoryExtremeProgramming