The last two places I've been asked for the results of XP, but were completely unwilling to put forth the practices to even get "XP Quality".

1. A former employer wanted programming pairs. Not two equals, but a junior programmer to a senior programmer. This is mentoring or training, not XP.

2. Most of my projects the last two jobs have been very deadline driven. Basically, "I want X in Y days." Y has never been longer than 2 weeks. X has always been a release-level enhancement. Maybe XP, but let's at least talk some reasonable estimates.

3. XP says to create test cases, then build the code to pass all the test cases (or fail appropriately). While I tend to code this way, test cases never seem to get the status of code or data. They don't get checked into libraries for re-use, for example.

4. Code reviews weren't ever in the mix in the last two jobs, so occasional pair programming was the best we could do. I mean occasional, as in, "Mike, I'm struggling a little figuring this out, why don't you sit with me a few hours and we'll put our heads together". As soon as the boss found out, he'd break it up. The person "asking" for the pair was seen as a weak team member.

In the end, I think, in small shops, you're just lucky to get anything done at all. You completely rely on the depth of your senior team members, and you hope they have enough breadth and depth to get it done. Sometimes, they do. Sometimes, they don't.

So, when people talk about "XP Failures", I think the failure is more likely "Talk XP, Do Something Else" than "Do XP".

Most senior managers I know of are SO results oriented, they don't care if it came from a monkey grinder as long as it achieves results.

Glen Austin