One question that comes up repeatedly is, "Is my team extreme?" People have concocted various charts and metrics to measure "extremeness". When used as a tool for reflection, these make sense. As a scoring mechanism where a score of 10 is twice as good as 5, they are absurd. Expecting a binary or numerical answer to the question, "Is my team extreme?" makes no sense.
I like Tex-Mex food. If I see a restaurant that advertises Tex-Mex food, I kind of know what to expect: spicy food, lots of meat, and beans. If I get served (as my daughter once was in Zurich) a limp tortilla with tomato sauce, Swiss cheese, and a pickle; I'll be disappointed. The question, "Is it Tex-Mex? Is it really Tex-Mex?", is important because it sets my expectations for what I'm going to get.
So with the question, "Is my team extreme?" There isn't a binary answer. If someone asks me, "We have a team split between here and Boston, but we're doing everything else on the list of practices. Is that XP?" I can't answer thumbs-up or thumbs-down, nor is my judgement important. Are the team members doing all the things that make sense to them in a sustainable way? That's the question, but only they can answer it.
XP, as a theory, predicts that if you sit together, you'll get better results. Maybe a team is getting good enough results already. Then it is doing fine, really-truly XP or not really-truly XP. If the team wants further improvement, it could increase face-to-face communication by sitting together some or all of the time; intensify the practices already in use; or try practices from areas outside XPusability, teamwork/communication, human resources, marketing, or sales.
This doesn't mean that any old software development style (or lack thereof) is extreme. The values, principles, and practices are there to provide guidance, challenge, and accountability. "If you aren't working well together, consider trying these things for these reasons to see if you can improve your relationships and your performance." If you just stop writing documentation and use XP as an excuse, you will be called on your behavior by the community. Belligerently saying, "We don't have to write documentation because we're extreme," shows contempt for communication, not an embracing of communication as a value.
There isn't a binary test for whether a person or team is extreme. Lots of teams with different values, principles, and practices successfully create value through software development. It's worse to fail with an XP team than to succeed with a pure waterfall team. The goal is successful and satisfying relationships and projects, not membership in the XP Club.
Saying that your team is extreme sets other people's expectations for your style of communication, your development practices, and the speed and quality of your results.