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