Extreme Practices Vs Extreme Values

I've been working to introduce XP to a project I'm on with some success (in the kind of environment where XP 'traditionally' works: small team, rapid development, ...). When we started out we focussed mainly on the practices such as PairProgramming, UnitTests, the PlanningGame, etc. and many of these worked for us, some only worked with modification and some didn't work or weren't applicable. So are we doing XP, or not, given that we can't take a checklist of XP practices and tick everything on it?

I believe that we are, simply because we hold the XP values dear:

ISTM that, if you hold these values dear, and you are doing ContinuousOptimization of the practices and principles that you employ, then you're doing XP. Whether you're actually doing PairProgramming or UnitTests is 'just' detail. Of course, all of the practices associated with XP have come out of a long process of ContinuousOptimization by people who really know how to build software. So, if you ditch PairProgramming, you have to ask yourself whether you really hold Communication, Simplicity, Feedback and A/F/C/C dear. But maybe, just maybe, PairProgramming and co aren't the best way to achieve Communication, Simplicity, Feedback and A/F/C/C in your organization or project.

-- PaulDyson

BTW, I also believe that ExtremeProgrammingMayScaleUp but perhaps ExtremeValuesWillScale better than some of the practices.


Aggressiveness/Fearlessness/Courage/Confidence (whatever you want to call it)

Maybe we can call this value TheOnlyThingWeHaveToFearIsFearItself?? ;-) -- MikeSmith


It's great that you're into the values, Paul, and very much agree that they seem to scale. I sincerely hope you'll keep trying the practices as well. I couldn't help thinking, however, of folks who say things like "I'm Catholic. Oh, I don't go to church much any more, and confession definitely isn't for me. I practice safe sex with all my girl- and boyfriends, and think God is probably really a large fuzzy white dog ..."

As a reporter of what works, I've become a proponent of some XP behaviors that I personally do not find natural. The use of cards is one. I hate the cards: it's just that they work better than what I actually like. Another is diagrams: I like diagrams: we just don't need them. Pair programming I do like, though I fall off the wagon a lot. It just flat works better.

I kind of live in fear of someday reading a report about XP that reads like my Catholic example above: "We used XP on our project and it failed miserably. We were in a hurry, and didn't write many tests, but we subscribed to all the values. When the customer found out we were six months behind, they came to town and shut down the project. They didn't even keep the 500 UML diagrams, which were almost finished. The 20 guys in Brazil were also terminated. XP just does not work!"

So please embrace the wonder of the XP ideas, where you find them useful. Try to stick to the values. Try the practices, let us all know what works and what you have difficulty with. For now, however, in my opinion, Extreme Programming is the extreme practices. -- RonJeffries


Something I can see happening where I am is someone saying: "look, we have 1000 test cases that all pass but the system still keeps going wrong. Of course we were in a hurry when we wrote them and I know that most of them don't really test the essential behaviour of the system classes, but XP says unit tests and we've got lots of unit tests". This isn't doing XP, this is just using the TestingFramework without embracing the value of Feedback.

I fully agree that the practices are the best we currently have and work wonderfully well in the 'traditional' XP environment. Also agree that they take working at and shouldn't be discarded or modified lightly. In fact they should be modified and discarded if and only if they prove not to be the best things you can possibly do to truly support the values in your environment. And if that (modifying the practices) means you're no longer doing XP then maybe that's okay.

-- paul

Your person failed to follow XP practice when they didn't create new test cases for each error that they encountered.

The trouble with just using the values is that it gives you too much latitude. Communication, simplicity, feedback, courage? Do you suppose that other methods explicitly disparage these? You could run all kinds of completely different projects and still claim to support these.

Now, they might be good projects, but I would rather not call them XP projects. I'd prefer the XP stamp to indicate a fairly narrow band of practices so that the term conveys some meaning. -- DaveCleal

I think that not writing many tests because you're in a hurry is not following the value of Feedback just as not writing tests for each error isn't following the practice of UnitTesting. However, I fully accept that it is easier to pay lip-service to values than it is to pay lip-service to practices so perhaps it is easier to use the XP stamp for a 'narrow' band of practices.

-- paul


EditText of this page (last edited April 6, 2004) or FindPage with title or text search