Extreme Programming Pocket Guide

Part VII. Adopting XP

XP works because its practices complement each other. It’s a whole package. Of course, few projects have the luxury of starting from scratch with a new development process. Few developers are talented and courageous enough to be perfectly productive in new circumstances. Few organizations are flexible enough to listen to all of the weird ideas that just might work, let alone to try the best ones.

Furthermore, XP doesn’t fit every situation completely. You may not be able to convince your manager to try pair programming. You may not be able to find a customer to speak with a single voice. You might need to improve your teamwork before you can think about practicing collective code ownership.

Many projects adopt XP in stages. Introducing XP gradually requires care and discipline. Certain practices are risky without the support of others. Some organizations need to see practical results before committing more fully. It’s important to weigh the strengths and weaknesses of XP and your team before jumping in with both feet.

Though some practices obviously precede others, there are many possible paths toward full XP adoption. This chapter describes one way to adopt XP. It presumes you’re a developer on an existing project. You don’t necessarily need management approval to start, though it may give you the political capital necessary to adopt further practices that do need management support.

Adopting XP means doing what makes the most sense for your team. The best approach ...