Refactoring Extreme Programming: Practices and Reflections on XP

Author: (British) Stephens (Stephens, M.), (American) Rosenberg (Rosenberg, D.)
Publisher:
Publish Date: 2005-06-01
Features: Breaks the myths of Extreme Programming (XP) and shows its other side; Conducts a thorough and systematic analysis of XP practices, distinguishing between agility and vulnerability; Proposes better methods that are more broadly applicable and achieve XP's agile goals.
Dear readers: We firmly believe that the halo surrounding Extreme Programming (XP) in recent years is shrouded in thick fog, and there are some very obvious weaknesses in this popular development process. The main challenge faced by teams introducing XP into their organizations is that XP requires a significant mindset shift, from team construction methods to how companies interact with clients. One of the key contents of this book is the refactoring process we recommend, which absorbs the essence of XP while discarding its extremism. This approach to achieving agile goals only requires minor changes to the existing organization but still maintains XP's agile objectives. We have also discovered some very interesting aspects of XP, so we try to view some of its quirky and humorous suggestions with a positive attitude.
Before we begin, we want to draw the reader's attention to some very unique elements of this book. It is not an ordinary, general computer science book! We feel that such a topic is suitable for a satirical approach, so we have decided to give it this style. Apart from satire, there are also many calm and humorous elements. At times, we do become serious and conduct a serious, systematic analysis of the inherent flaws and dangers of Extreme Programming (XP). In this regard, this book is not entirely a "critique" of XP. As mentioned later, not all XP is bad. We aim to provide a fair critique and identify parts of XP that can be salvaged or refactored to achieve the same agile goals in a more robust way.
XP has been hyped unfairly, and new books on XP continue to be published at an incredible pace. The excessive hype surrounding XP has influenced the industry from all sides (some positively, as we seek, but mostly negatively). Given this, we believe it is important to write a book that goes against the XP tide and resists it. Here is a small example of how XP has affected the industry. Matt (the courageous co-author of this book) received an email from a consultant who had recently lost an important contract because he refused to start a project without first conducting some detailed requirements analysis and preliminary design. The client, who had read about XP programming, told the consultant, "Since XP thinks it's fine to start a project that way, we will find someone to skip requirements and preliminary design and start the project directly!"
While some business professionals, upon hearing about XP, immediately become (as the consultant's story suggests), there are still some who remain steadfast and refuse to change. In reality, one of the main challenges faced by teams trying to introduce XP into their organizations is that XP requires a significant mindset shift throughout the organization, from how teams are organized to how companies conduct business with clients. This book analyzes the shortcomings of XP and proposes an alternative approach to achieving agility, which requires far fewer changes to the existing organization compared to XP while still retaining its agile goals.
You can use this "alternative approach" as a blueprint to set up your own agile methodology (we provide some pointers near the end of the book to other agile processes that we feel are more rigorous than XP). However, the most important purpose of this book is to shatter some myths that have emerged with the XP wave, such as the myth that no documentation is needed, that a on-site client and some automated tests are enough to replace written requirements specifications, and the myth that individual needs and comfort are secondary elements of a project (i.e., "join us in pair programming or find another job"). And we intend to achieve our goals in an entertaining and humorous way, because it is good, and because the relevant topic requires it.
Target Audience: XP is often introduced into organizations by programmers. This is not surprising, as XP is a "programmer-friendly" method. It elevates the role of programmers (which is essentially not a bad thing) and places them on par with clients. Therefore, if you are a manager or client being persuaded to use XP in the next project, this book provides a valuable counterpoint. If you are a programmer introducing XP into an organization, this book should be helpful to you, as it outlines many of the dangers of XP, which could be potential project killers and are often glossed over in other books about XP. If you are considering trimming XP to extract its strengths while avoiding the "domino effect" of process changes—where a small change in the process causes the entire process to collapse—this book offers some valuable guidance.