[Copied from the XpMailingList because someone enthusiastically liked it. It's essentially a survey of the bullet points during migration.]

If your species lacks the ability to split into multiple engineers at whim, you are going to have to chose your battles '''very''' carefully when migrating a crufty blob of code, and a dissolute team, to XP.

Generally, either get a team and an XpCoach and go full-bore ExtremeProgramming, or stick with what you know and migrate opportunistically. '''Don't''' check off practices one by one, or do the ones that are easy or the ones you get permission to do. PairProgramming without a GreenField project can be damaging.

SoftwareDevelopment has two nested cycles. Writing code is the inner cycle, and releasing features is the outer cycle. You will stabilize your process very early if you introduce some of the aspects of TestDriveDevelopment to your inner cycle, and if you release a new version, with fanfare, every Friday.

Legacy code shows a great investment in debugging, so don't throw that investment away. See ExtractAlgorithmRefactor.

Unless bosses are enthusiastic, shut up about XP. Talk about "IterativeDevelopment", "robustness", "bug resistance", and "testing".

If you had a greenfield XP project, it would produce a literate AcceptanceTest output as a secondary user interface. Your mission is to simulate one. If you can comprehend FitNesse get it, otherwise just write a dumb program that reads your data and outputs HTML to a Web page.

Make your managers respond to '''this''' interface. Point to the bugs. Point to the low metrics. Ask which to improve.

-- PhlIp