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.