I can tell the current team is happy with XP, but they aren't whole-hearted devotees.

This is probably a good thing. After all, you wouldn't want all your projects looking like nails. See When should Extreme Programming be Used?

is XP self-sustaining or does it need a strong advocate inside the team to nurture and encourage it?

"Strong advocates" do more harm than good. Ensuring that the people who make the decisions know what extreme programming is and what its strengths and weaknesses are would be more beneficial.

chromatic wrote a good intro piece on the subject a little while back as well.

The place I work for has some of the Extreme Programming tenets in place, but not all, and in my opinion it works quite well.

The main parts we've adopted are the unit testing philosophy (Everything has unit tests, unit tests are written before the code they test, and tests must remain to check the code doesn't get broken later), the pair programming one (Two people sharing a keyboard, passing it between them and discussing what they're doing continually.. we only use this at times, and since I'm the only pure-Perl person here I've yet to do it much at all), and the idea that you code the minimum amount to get this part working and refactor it when it becomes necessary.

This seems to work well for us, giving us the safety net of the unit tests, the distribution of skills and avoidance of 'obvious' mistakes the pair programming does, and the over-engineering which refinement methodologies can sometimes produce. It does seem to be a nicely modular approach though, and in my own coding I've adopted a few bits such as the unit tests, the minimal coding, and a great deal of reading on design patterns and refactoring. I don't do the pair programming since I really don't want to slice my brain in half.

There is a nice series of books on Extreme Programming about, and I'd recommend reading Kent Beck's 'eXtreme Programming eXplained' as a nice book to read before launching yourself into the XP heartland.

As for it being self-sustaining, I suppose it's as self-sustaining as any other methodology. People will keep doing it as long as they see an advantage, or they're made to. Here we've reached both, I think, and even if our main XP proponent left we'd still do it. We do have a larger team though and so may have more momentum there.

$"=q;grep;;$,=q"grep";for(`find . -name ".saves*~"`){s;$/;;;/(.*-(\d+)
+-.*)$/; 
$_=["ps -e -o pid | "," $2 | "," -v "," "]`@$_`?{print"+ $1"}:{print"-
+ $1"}&&`rm $1`;}
[download]

A Consultant comes in to a company that practices XP. He talks to one of the team leads:

Consultant: Hey, I hear you guys do XP! Great! So you pre-write your unit tests?

Team Lead: Well, no.

C: Well, do you do pair-programming?

TL: Well, um, no.

C: Well, do you have stand-up meetings at the end of every day?

TL: Well, not exactly, no.

C: So what's XP about it?

TL: Well, for starters, we don't write documentation...

Using XP you don't write comprehensive specs to begin with, so there's not as much up-front documentation. However, I've found that the amount of documentation doesn't really change in XP, just when it's written. This has proved both good and bad at the company I'm with now.

I haven't seen XP work correctly yet. I keep hoping that it will on the next project, but starts to erode during the first 1/3 of the cycle, and is gone by the end. Despite this, I still believe it's possible and desirable, it just seems to be more difficult in practice than it sounds in the books.

On a related note, does anybody know of open-source projects that are done using an organized XP effort? I understand that the business conditions of an open-source project are completely different from those in the private sector, but still there are some elements of XP that are applicable to anything (unit-tests and pair-programming in particular)

I've also seem to get involved in seemingly endless battles to improve the development methodology. It is something that interests me as much as the development itself.

What I've found is that every environment is different, and the things that work best are often informed as much by the business environment (e.g., how much does a bug really cost?) as it is by the technical environment and culture.

So while I can say that team programming, peer review and regular shotgun meetings are what I've found to be the most useful, I offer the following advice:

• Be prepared for the changes to take a long time to implement and gel amongst the team. Six months to a year would not be atypical. Let the business people in the company know what your ideas are, but also let them know that your ideas will take some time to implement properly and for the results to show. You will need the buy-in of the suits over a long time horizon, so manage their expectations: You are not going to cut development time in half overnight, but you should see a gradual but consistent improvement over time in coordination, estimation, output, and quality.
• Any methodologies do need a strong advocate. Every formal process takes time, and there needs to be a strong and informed individual to push back when business decision makers want to take shortcuts which may appear innocuous in isolation but which breed a culture of sloppy work habits.
• Don't be too inflexible. Every environment is different, and one development technique may work well in one shop and not another. Keep trying things, promote an environment that encourages constant and positive feedback, and keep the things that work and discard those that don't. Don't rely on a single development methodology, though you may favor one over others: No single development methodology is a silver bullet. Inform yourself and pick and choose.