Iconix Opinion Of Extreme Programming

From the XpMailingList:

Nicholas Robinson wrote:

the ICONIX priesthood even stipulate XP doesn't consider analysis or design at all, which as far as I am aware is wrong.

Yes, it is wrong. Rather a serious error for people who chose to write a book about XP, in my opinion.

Design in XP is done all the time. Design aspects include simple initial design; group design sessions as part of the Planning Game; deep understanding of the design by all developers, using pair programming and team code ownership; and continuous design improvement using refactoring. Most teams use CRC, UML, or ad-hoc diagrams to express design topics, as well as code.

Analysis in XP is also done continuously, as part of the PlanningGame. Requirements must be broken down into small enough pieces to be able to be estimated and tested. And they must be grouped into a sensible product in order to do the Release Plan. It is true that XP books do not speak much to the subject of where the stories come from. Our experience is that the Whole Team / On-site Customer practice covers this topic well. If you can't get an XP Customer, then of course you have to do something else. Teams using Alistair Cockburn's style of use cases report good results.

I don't write much about [the IconixProcess] because I don't know much about it. It seems like the fair thing to do. If you have some specific questions about how to fit ExtremeProgramming into an existing project, I'll be glad to help, as will everyone here.

I guess as long as at the code writing part, the tests are written suitably to support refactoring, regardless of process, then it shouldn't be too bad. Something I have learned reading the agile material is that getting bogged down in diagrams slows down the inertia, and I have experienced it myself. The in-house document that has been produced gives an example of a robustness diagram through to code, and the final code doesn't even look object-oriented to me!

Yes, certainly the XP practices of testing, simple design, and refactoring will serve you well. Especially if, as you suspect, the up-front design is lacking.

You're right about the slowdown that comes from excess documentation. I find that a very limited amount of documenting, and a lot of discussion with the team works quite well, especially in the presence of code.

-- RonJeffries