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)