Adoption Strategies

As always, coaching by an experienced method expert on the first project is recommended.

Similar to Scrum, but in contrast to the recommended gentle, pilot-project adoption strategy of UP (for example), XP recommends adoption like this:

1. Pick the worst project or problem.

2. Apply XP until solved.

3. Repeat.

If all the XP practices can't be swallowed at once, Beck recommends starting with:

• whole team together in a common project room

• test-first development

• acceptance tests written/owned by customers

• Planning Game

• pair programming

That said, there are dangers in only adopting a few of the practices, especially if one does not understand how they support each other. Avoidance of up-front design (even on a per-iteration basis) is compensated by frequent refactoring. Frequent refactoring is supported by continuous integration, and test-first development. And so forth.

Introducing customers to this new engaged approach is a challenge. The key is to help them see the early, tangible business value that they want, and emphasize that they will be steering the team to meet their needs in short cycles. An XP goal is to so delight the customer with this new-found control and responsiveness, that after a few iterations they will love the process.

On the common problem of customers wanting more and more in an iteration, one technique is to exploit the physical nature of story cards: Once the cards have been estimated and chosen for an iteration and therefore consuming all available development resources they are laid out on a table. Clearly, with the "no overtime" rule of XP, adding a new card means an existing one must be physically removed. This visual and tangible impact teaches a clear lesson.

If you can't get a customer into the room, what to do? First, look for another related representative, such as a product manager. If no luck, establish the closest possible communications. Visit them frequently, use a mobile phone, spend time at their job, have them use an instant messenger service to simulate the feel of close communication, have them attend the Planning Games, and show lots of demos.

Programmers will adopt most of the practices without concern, except pair programming. XP recommends not inviting programmers opposed to the idea to an XP project. Do not put only young programmers together; the maturity and patience of some older developers is necessary to make pairing work. Ensure the pairs mix regularly, the typing developer rotates frequently, and that people are learning from each other; i.e., sharing with their partners what they know, and what they are thinking. If pairs aren't frequently talking together, something isn't working.

For XP, the physical environment must change: open common room with development stations near the center, and the walls exposed for visible graphs, sketching, and so forth. And, the stations need to support pair programming. Ensure the non-typing partner can easily see the monitor.

Since pair programming implies lots of talk, a culture of quiet talking needs to be encouraged.