Are You Doing Xp

• Communication - We have tried to communicate as much as we can articulate about XP, primarily here on Wiki, but in other forums, public and private
• Simplicity - We want to make the definition of XP as simple as possible, so people can understand where they stand WRT XP
• Feedback - We want concrete, simple, straightforward feedback to and from teams who are trying to be extreme
• Courage - We would like to grow the XP community as fast as possible

Here's a short list of what "we" think makes a project extreme:

• Paradigm - Your project is extreme to the degree you see change as the norm, not the exception, and optimize for change
• Values - Your project is extreme to the degree that you honor the four values- communication, simplicity, feedback, and courage- in your actions
• Power sharing - Your project is extreme to the degree that business makes business decisions and development makes technical decisions
• Distributed responsibility and authority - Your project is extreme to the degree that people get to make the commitments for which they will be held accountable
• Optimizing process - Your project is extreme to the degree that you are aware of your software development process, you are aware of when it is working and when it isn't, you are experimenting to fix the parts that aren't working, and you consciously enculturate new team members

My own view is that there are some things that if you aren't doing them, you aren't doing XP. I'm not sure what they are, but I feel sure they are there. In particular, can anyone do XP without testing? without refactoring?

Imagine someone who sets out to do the simplest thing that could possibly work, but doesn't refactor. IMO, he's hosed, end of story. Doing XP? I don't think so.

Imagine someone who refactors without UnitTests. Ditto hosed. Ditto not XP.

Imagine a project with tests, but the techies have a BuildForTheFuture orientation. Quite possibly doomed. Are they doing XP?

I dunno, I'm just an egg, but I think calling the tail a leg doesn't make it one. -- RonJeffries

I think this is one of the things that really needs to improve about the way XP is taught. A definition needs to be exclusive as well as inclusive, but you don't have a simple and sane way of excluding AlmostExtremeProgramming. There have been accusations that people admonishing them when they fail (IfXpIsntWorkingYoureNotDoingXp). Of course, if you succeed, does anyone ask if you're doing AlmostExtremeProgramming?

If you read the comments on http://www.kuro5hin.org/?op=displaystory;sid=2001/4/3/182249/2098 you will see what I mean. The author, maleficient, says he's doing XP at his place of work, but he isn't. Others basically reiterate the same beliefs about XP. People have essentially defined CollectiveCodeOwnership and PairProgramming as XP.

I gave up explaining XP to them because I don't even understand XP well enough myself. I'm not sure why people insist on using IndexCards, there aren't suitable quality assurance for the domains I work in, and there aren't very good replacements for OnsiteCustomer in a product environment (well, in my opinion marketing isn't a good substitute).

I think XP is too rigidly inclusively defined. This leads to people either giving up on it before they start or making up a (broken) definition of their own so they can talk about it. Additionally, it's too loosely exclusively defined as I discuss on RunawayReligion. -- SunirShah?

Is the problem with XP that it's "rigidly defined"... or is it, as Alistair notes below, that it is different - in particular, its having an actual content at odds with how we usually practice software engineering ? In the latter case, it's no surprise that one would have trouble explaining XP; it's a matter of CognitiveDissonance.

We start out in the programming craft with an intuition of what good software is. Then, due to the circumstances of the profession being what they are, we find ourselves practicing that craft in ways that contradict that intuition. And, naturally, we follow the path of least resistance : we adjust our thinking to fit the practices, rather than the reverse.

What XP offers is a way of thinking about the discipline of software engineering which accords more with our intuitions about good software than with currently accepted practice. Its practitioners follow that up with a generosity in explaining that way of thinking and helping others put it into practice, and an apparent disregard for the security of their own pet opinions, which I find nothing short of amazing.

I made a strong effort to have XP adopted where I work. The project where I was involved did badly. Now, I could look to XP for a scapegoat. "It didn't work; surely that can't be my fault, so XP doesn't work". I have a different perspective. The projects where I wasn't involved did even more badly. And, in spite of my efforts, we never got anywhere near a process that I could honestly qualify as extreme in the sense outlined above.

Now the best we can hope for is to have a chance to do well on our next projects, having learned something this time around. The unfortunate reality is that a business doesn't get unlimited opportunities to make mistakes; if a business makes too many mistakes, it is all to likely that the persons involved will go their separate ways, and will not have the opportunity to apply as a team the lessons they learned as a team. That is why it helps to have ExtremeProgramming uncompromisingly defined, but also clearly and flexibly. -- LaurentBossavit

I consider NanoIncrements near to the core of XP, if not in it. NanoIncrements plan for change, as above, but also imply (what is for some of us) surprising economics - that increments can be so short and still be economically effective. -- AlistairCockburn

I consider distributed and continuous design to be near to the core of XP. It is made possible with objects; is the dual of simplicity; and it motivates the other values of communication and testing. But, then, this is just the side of XP that I find most interesting. (Could it be that we are agreeing?) -- WardCunningham

Ward, I was real glad to see you write the word design above. If ExtremeProgramming is about Listening, Testing, Coding, and Refactoring then where is the design? Use CRC cards? Fine. But, I remember an article that I read back in the early 90s that has the answer (for me). TheSourceCodeIsTheDesign. -- MichaelFeathers

There is great truth here. WardAndKent teach us to go quickly to code, because there we learn so much more. And they teach us to code with ExtremeClarity, which makes the design evident within the code. Yes, as discussions in MethodCommenting and elsewhere suggest, there still are things that are harder to see in the code than one would wish. But IMO the bulk of truth lies here: TheSourceCodeIsTheDesign. -- RonJeffries

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006