Adopting XP

Extreme programming (XP) is a software development process defined by specific, simple practices. XP takes individual practices known to be good and turns all the dials up to maximum, creating a process quite unlike the traditional development process. XP doesn't have a design phase followed by an implementation phase followed by a test phase. As part of the extreme idea of doing certain good things all the time, design and testing are done throughout the project's life.

XP is always focused on the end product: every couple of weeks, an XP project delivers working code. It relies on fast and frequent feedback to help management steer the project to meet shifting requirements, help junior programmers learn good practices, and teach experienced programmers new tricks. Since it is new to many people, implementing an XP project requires careful planning and thought. You must be aware of both the things that you should do, and the things that you should not.

Prepare Your Team
The best way to learn XP is in an experiential-learning training course. Your entire development team (including the testers, the customer, and the manager) should attend a one-week immersion course on XP. While many programming teams are learning XP based solely on books and information on the Web, it is important to actually do the practices with guidance.

Even if you do attend training, the minimum required reading (for at least your team leader) is

• Extreme Programming Explaine by Kent Beck, which covers all the practices at a high level and why they support each other
• Extreme Programming Applied by Ken Auer and Roy Miller, which describes ways to adopt XP and how to persuade managers, customers, and programmers to try it
• Extreme Programming Installed by Ron Jeffries, Chet Hendrickson, and Ann Anderson, which gives more detail on all the practices, including examples of testfirst and pair programming

Your customer should read Planning Extreme Programming by Kent Beck and Martin Fowler. All programmers on your team should keep a copy of Refactoring by Martin Fowler handy and study it carefully. Encourage your team to read and discuss these books and others on design, design patterns, programming, and testing. (See the StickyNotes at the end of this article for full details on these books.)

Don't rely on just one book . In efforts to explain XP more clearly, the description of the process is still evolving. The process described in the first book, Extreme Programming Explained , is described differently in the later books; for example, test-first programming (a very important practice) is not described at all in the first book.

Start an XP Project with a Coach
Based on my team’s experience, and that of the other teams in my department, I strongly recommend hiring a full-time coach for at least the first several iterations of your project. Teams need someone who can correct "bad form"—failing to follow a recommended practice, failing to apply a practice correctly, not communicating, or being blind to some other inefficiency. Coaches must also be able to program, so they can work with every member of your team, teaching them patterns for incremental designing and testing.

Don't just make your team leader the coach . As a cost-saving measure, you may be considering adopting XP without a formal coach. We made that mistake. Before our first XP project, my team attended a one-day training course and read Extreme Programming Explained . We thought that would be enough to get started. Later we realized that we were not applying all of the practices because we didn't have a coach to help us take full