XP is a set of synergistic practices. Because the practices depend upon each other, people often wonder where they should start. In general, we recommend that you stop and consciously decide to adopt as many of the XP practices as possible.
However, if that induces too much stress, consider adopting the practices in this order.
Establish a solid build process. If you are not able to reliably build the software you are working on, you can&8217;t really go further. Once you have a reliable build process, make sure that you run whatever tests you have prior to each checking.
Pair programming is often a significantly different way of working for most developers. It takes a little bit of time to get used to it, but as a team does, they recognize that they are a much more powerful team because everyone’s knowledge of the system grows rapidly. In addition, quality goes up because there are two sets of eyes on all work as it is being done. When you adopt pair programming, ideally you should have an open workspace.
As your team gets started with pair programming, you should adopt the Planning Game. The Planning Game will help you identify good goals for your next release, iteration, and day of work. At the end of your first iteration, you will have a velocity that you can use to get a sense of how long it takes you do do your work. As you do your planning, talk to your customer about producing acceptance tests and being available to the team.
As you work together on your first iteration, try doing test-driven development. It will feel strange at first. If it doesn’t, you are probably doing it wrong. Over time, it will feel like a more natural way to develop software. Recognize that, at first, your velocity will be rather low. This is a side effect of the learning process. Over the next few iterations your speed will increase.
As you move forward, learn how to refactor and start to practice collective code ownership. Often collective code ownership is a little scary at first, but as you pair, you will notice that everyone is learning what it takes to work with the system. When people volunteer for tasks, they either volunteer only for what they know how to do or for things that they can get help on from a partner.
Once you have a few iterations under your belt, you will be able to understand how the process works and how the different practices interact and support each other. Finally, listen to the feedback coming from your team. That feedback is critical and can be used to improve and adapt the process to your team’s particular needs and problems.