XP is a software development process that is as much about learning how to improve the process as it is about doing software development well. You don’t necessarily have to fully understand every “why” or even every “how” behind XP in order to get started doing it. You could start with the assumption that you will grow the process as the result of acquiring experience-based knowledge. But should you? Just what do you need to know to get started in XP?
There are many approaches to instantiating XP. Some of the mechanisms that can be used to help you and your shop get started include:
read the books
join the XP mailing list(s) and ask for help
take a class
find developers who have already done it
hire experienced coaches
You should have a fundamental understanding of what the XP process is about before tackling it. This understanding can be very quickly obtained from reading one or two of the many books already available. In all cases, start with Kent Beck’s manifesto that started the landslide: Extreme Programming, Embrace Change. Then proceed to one of the more practical books. I prefer Ron Jeffries’ pink book, XP Installed, as a short but information-packed overview of how to practice XP.
While the books are something you can and should start on right away, they will introduce more questions than they answer. Also, it is too easy to come away from books with the techniques of XP but not the spirit–something that can quickly lead to failure when you try to make XP work for you.
A course in XP can help jump-start the process by giving you and your team a hands-on feel of how XP all works together. The better courses available are taught by actual practitioners of XP, and keep pace its rapidly changing application in the real world. By attending such a course, you will see first-hand how it’s meant to be done, and the chance for misinterpretation should diminish.
However, a course is only the beginning. XP promotes the idea that you can and should begin development almost immediately. Its incremental, feedback-driven approach to everything means that you can quickly adapt to issues as they arise and take corrective action. But knowing what the proper corrections should be can be a hit-and-miss proposition. This is where experience and a strong hand come into play.
If I recommend anything with respect to applying XP–or any new software development process, language, or technique–it’s that you find the right people to guide your team. While there is nothing in XP that is inherently complex or difficult to learn, you can save significant time and pain by learning some of the traps and pitfalls in XP. The right people can tell you how to take smaller steps, how to properly do test-driven development, or how to start getting the proper behaviors emerge from the team itself.
A coach is an absolutely essential investment. You wouldn’t field a
professional football team with players who had never even learned the
rules. Your development team similarly represents hundreds of thousands
or millions of dollars worth of talent. Make sure they have support from
someone who is qualified to lead the way.
Coaching should be a short-term job: the core job of a coach is to teach the developers how to work as a self-managing team. A coach should be technically strong, but should also be able to provide leadership for the team.
The coach is responsible for recognizing trouble spots and for negotiating when issues arise. It is imperative that the coach work constantly with the team during its introduction to XP.
The coach can be someone from within the development team who has worked on a successful XP project, or it can be an external consultant. The coach does need to maintain a level of impartiality.
A manager is rarely the right person for the job. A development team can be intimidated by the constant presence of a manager, and most managers would not be able to dedicate 100% of their time to sitting with the development team. Most managers are not technically competent enough for the role.
You can buck the odds and wing it. You will experience some levels of success from applying XP practices, but this progress can be deceptive. It is very easy to produce a significant amount of bad software in a few months’ time when the proper controls of XP have not been applied.