You are already developing software. You have already started. XP is a way to improve both your development process and your experience of it. To do XP, you start where you are and adapt by adding practices that meet your goals and express your values. As you add practices, the synergies between them make things possible that you previously couldn't imagine. And then, you want more. By the time you have applied XP completely you are energized, confident, part of an active community, and working at a seemingly incredible pace with less stress than ever before.
XP may represent a new direction or an acceleration in your efforts to improve. If so, how and where do you start?
First, there is no one right place for everyone to start. Any of the primary practices are safe, offering immediate improvement if you have the problem they are designed to address. Feeling overwhelmed by everything you have to do? Start the weekly cycle for yourself. Take time at the beginning of the week to write down everything you think you can accomplish in the week. If there is too much to do, align your priorities with the team's needs.
It's easy to start by changing one thing at a time. I think it's hard to jump in and do all the practices, embrace all the values, and apply all the principles in novel circumstances by reading this book and deciding to do it. The technical skills in XP and the attitudes behind them take a while to learn. XP works best when it is done all together, but you need a starting place.
Change is not necessarily slow. A team eager or desperate for improvement can progress quickly. It doesn't need to wait long to assimilate one change before moving on to the next practice. If you change too fast, though, you risk slipping back into old practices and values. When this happens, take time to regroup. Remind yourself of the values you want to hold. Review your practices and remind yourself why you chose them. New habits take time to solidify.
How do you decide what to change first? Look at what you are doing and what you want to achieve. Choose the first practice on that path. One option is to use XP-style planning. Write stories about improving your software development process. "Automate the build." "Test first all day." "Pair program with Joe for two hours." Estimate how long each will take. Figure out your budget for process improvement. Pick a story to work on first. Adapt as you discover what is easy or valuable and what is difficult.
I've used this same process myself with organizations planning to apply XP. One team's stories were about teaching classes, trying pilot projects, and educating executives. Our sponsors asked for instant change even though everyone knew that wasn't possible. Applying XP-style planning to the process of change let us communicate and align our priorities and gave our sponsors a chance to see what we were doing and influence what was happening.
Change begins with awareness. Awareness of the need for change comes from feelings, instincts, facts, or feedback from outsiders. Feelings, while valuable, need to be cross-checked with facts or trusted opinions.
Metrics can lead to awareness. Trends in metrics can point to the need for change before the consequence of the trend becomes painful. I coached a team that went through all of its post-development defects and discovered that they had all been created by individuals programming alone. Without the ability to reflect accurately on its experience, the team wouldn't have been able to make an informed decision about how much to pair program.
Once you are aware of the need for change, you can begin to change. The primary practices are possible places to begin improving your development practices. Each describes a continuum of behavior. Find your current position with respect to each of the practices. Pick a practice whose purpose matches your own priorities for change. Move one step closer to the endpoint illustrating the practice. See if the humanity and effectiveness of your development improves.
For example, I might decide that I need closer technical collaboration. I have a big integration coming up and I am feeling increasingly nervous in spite of design and code reviews. How can I collaborate more?
Pair programming is the practice that addresses technical collaboration. At full intensity, it suggests that all long-lived code be written by two people having a conversation as they program. Perhaps my team is not willing to "give up" that much time, since we are all going to be held personally responsible for our areas of the code. However, I can collaborate one step more intensely by picking a piece of code about which I am nervous and asking someone else to pair with me for an hour or two as I work out its interface to another part of the system. I would be wise to choose the person responsible for the other part of the system as my partner, if he is willing.
Once we've paired, we can evaluate whether closer technical collaboration helped or hindered our team's accomplishment of its goals. We're in an informed position to decide whether to further intensify our collaboration and what means to use: pairing, reviews, or some other method.
Once I change, sometimes I want the familiarity of an old way of working more than the improvement of a new way. Even if I change, the people I relate to may resist my changes enough that I would rather change back than hold myself to my new standards. Complicating the situation is my own insecurity about my new practices. Do I program faster or slower if I write automated tests along with my programs? I want to avoid changing back inappropriately.
Change always starts at home. The only person you can actually change is yourself. No matter how functional or dysfunctional your organization, you can begin applying XP for yourself. Anyone on the team can begin changing his own behavior. Programmers can start writing tests first. Testers can automate their tests. Customers can write stories and set clear priorities. Executives can expect transparency.
Dictating practices to a team destroys trust and creates resentment. Executives can encourage team responsibility and accountability. Whether the team produces these with XP, a better waterfall, or utter chaos is up to them. Using XP, teams can produce dramatic improvements in the areas of defects, estimation, and productivity. The price of the improvement is closer collaboration and engagement with the whole team. Raise your expectations for accountability and teamwork, then help the team through the inevitable anxiety that comes with change.