Incremental Extremism

It almost seems a contradiction in terms, doesn't it?

I know there are several pages out here that dance around this question, but I wanted to hit it head on for a bit.

Can a team adopt XP incrementally, a practice at a time, or does it have to be swallowed whole?

Statement of the Question

On the one hand, we have the section of KentsBook that very clearly points out how the practices supplement and counterbalance each other. Adopting PairProgramming means you do not need CodeReview. Becoming TestInfected means you can RefactorMercilessly.

On the other hand, I seem to remember that he explicitly recommends adopting XP a practice at a time -- figure out what your worst problem is, fix it with the appropriate XP practice. Repeat. He also exhorts us to be selective and creative in our application of the practices in our environments.

I clearly understand the mechanics of the first approach. But the reality is that the second approach has much more chance of succeeding in an existing, non-XP team. In fact, it almost allows XP to sneak up on the team -- you don't argue about adopting XP as a whole. You sell it a practice at a time, based on it solving real world problems that a given team is experiencing.

If this can be successful, it means that the team buys in on a visceral level. If you force adoption as a whole, it is a bit like mass forced baptisms -- which I can't imagine actually did much to drive the expansion of Christendom. Once the soldiers are gone, the old ways come back out.

Are the linkages between practices few enough and well enough understood that you can sort of group them together and adopt them incrementally? Are there specific things you want to make sure you are tracking, to make sure that you don't get out of balance?

A Proposed Implementation Sequence

Start with daily StandUpMeetings if you don't have them already. And get other kinds of (frequent) meetings out of the way so that the team has time to actually code. --LaloMartins

It seems to me that the first place to start is to organize DevelopmentInterval's by UserStories or ImpliedRequirements?. Begin by building systems in HorizontalStripes, end-to-end, integrating continuously as you go. Use something simple like a WorkQueue to plan the project and track status. Get the developers to provide estimates in uninterrupted days. Throw those evil gantt charts and bogus percent complete estimates out the window.

And you can call this ScrumDevelopmentProcess if it makes management happy ;-)

Working off a WorkQueue seems to give you lots of opportunities to argue about DoSimpleThings and JustSufficientImplementation. You are no longer performing some abstract task called Analysis or Design. You are implementing a specific business function.

Then introduce aggressive UnitTesting, to get the developers TestInfected.

Run your DevelopmentInterval, 8 weeks maximum.

At the PostPartum, listen carefully to what worked and what didn't.

In the next interval, focus on the collaborative practices. Introduce PairProgramming and CrcCards. Either immediately quit doing code reviews, or leave them in place for an interval or two and notice how different they are now that design and development is collaborative.

Do you think this approach will work? How close does it get us to XP? Are there important practices left out? What do you think? -- BillBarnett

All or Incremental

Back a while when the Wiki as XP tutorial threads were in full flow there were a few statements along the lines of you must do all the practices ALL AT ONCE just like C3 does them or you AREN'T EXTREME!!!!! Not even a little bit!!! about the place. Or that's how they read, anyway.

Well: 1) so what? 2) surely not?

In the heat of the "are XPers dangerous perverts?" discussion, as with the re-run of that discussion thrashing around on news:comp.object at the moment maybe that sort of zealotry has a place. But XP would seem to now be firmly into the early adopter phase, so perhaps this sort of rhetoric needs to start to be replaced with a more normal discussion of which practices can be used when, and under what circumstances.

It's a very nice (maybe even profound) feature of the practices that they complement and reinforce each other. A corollary of that is that a sub-set of them will jointly and severally underperform, but not being able to get the full benefit is surely no reason to deny yourself any of the benefit.

As Beck has pointed out, few of the practices are new. It's the arrangement of them to address this new microeconomics of development that is original. Last year I was placed in the TeamLeader role on a project with very tight timescales and scrambled requirements. We adopted some of the practices: UnitTesting, requirements in the form of something like a UserStory, short iterations. We got a lot of benefit from this. Were we extreme? I'd say not since we did far too little refactoring and had nothing like the planning game going on, and they seem like the shibboleth practices. But we tended to extremism.

Attitude and Its Relationship To 'All or Incremental'

Isn't what makes you extreme or not your recognition that the exponential increase in the cost-of-change may not apply to your project? And if it does not, do you use the rational (no pun intended) set of practices in that case? If it indeed does not, and you do, and then don't you tend to extremity?

While pondering my current project (which couldn't be less extreme if we tried) it became clear to me that the PlanningGame, along with a commitment of real user's time to the development, needs to go into a project at the time the bid is written.

While writing this it also occurred to me that beyond the practices is the XP attitude, call it anti-Taylorism for short, which may or may not be necessary for successful implementation of any or all of the practices.

Maybe it's some sense for the presence or absence of that attitude that leads to the all-or-nothing stance -- KeithBraithwaite

Related Pages

I have developed an ExtremeProgrammingEnablingChart which shows my opinion of which methodologies in ExtremeProgramming enable which other methodologies. It may be helpful in charting a route to implementing extreme programming. -- JonGrover

I found this page after I'd written MigrationToXp - which deals with the same issue. -- RichardDevelyn

See AdoptingXpPatternLanguage

CategoryExtremeProgramming | CategoryAdoptingXp