XP Explained

This week we begin getting into the proverbial weeds of Extreme Programming by tackling chapters seven and eight in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapter 8 changes gears and provides advice on how to get started with XP.  Beck suggests that there is no single place to start for everyone. Where you start depends on where you are beginning.  Chapter 9 provides a list of corollary practices that build on the primary practices discussed in Chapter 7.

Chapter 8: Getting Started

We implement XP to improve the development process and how the development process is experienced by those using the process. Given the motivation to improve, it might be tempting to try to implement all of the primary practices at once (or perhaps even to implement the practices alphabetically).  The right way to to implement XP will be different for every organization. Beck states that an organization can use any of the primary practices in any order.  The place to start is a function of problems an organization is experiencing and capabilities of the organization.  The best place to start is by picking a practice (one that solves a real problem), write stories, make the change, get feedback, and then continue to make changes. Use a series of small steps to make progress quickly. Demonstrating results will provide the organization with the motivation to pursue the next step and the next.   

Chapter 9: Corollary Practices

The corollary practices build on primary practices introduced Chapter 7.  From the perspective of the degree of difficulty, the corollary practices are more difficult and require a solid understanding of the values, principles, and primary practices to safely implement.  The corollary practices are:

  • Real customer involvement – Beck suggests making the business people affected by the system part of the team. While we today we would recognize this practice in the product owner role and in the Agile Manifesto, at the time this was a fairly radical concept.  As a further note, involving real customers is difficult in many organizations.  Beck states (and I wholeheartedly agree), that not involving a real customer at all or a proxy for the real customer will lead to waste.
  • Incremental deployment – Big bang deployment have a high risk of failure or lesser problems.  Big failure translates into the potential for high economic costs. Develop and deploy in smaller pieces in order to limit risk and get early feedback.  (Does this remind you of a principle in the Agile Manifesto?)
  • Team continuity – Simply put, keep effective teams together. Keeping effective teams together increase the reliance of teams when they encounter problems and increases both productivity and quality.
  • Shrinking teams – As a team becomes more capable keep the workload steady and reduce the size of the team.  This is one of the most radical of the corollary practices.  The reduction in team size acts as a constraint that puts steady pressure on the team to increase its capability.
  • Root cause analysis – When a team finds a defect after development they should fix the problem and then eliminate the cause. The goal of this practices is to make sure the same kind of mistake does not happen again. In XP terms, when a defect is encountered: write an automated test, fix the system so the automated unit test works, then figure out why the defect was created and wasn’t caught.
  • Shared code – The team owns the code. In scenarios where there is common ownership of the code, anyone on the team can improve any part of the system at any time. In order for this practice to work the team must develop a strong sense of collective responsibility.  Without a feeling of responsibility, quality will deteriorate.
  • Code and tests – Maintain the code and tests as the only permanent artifacts. Eliminating obsolete artifacts provides space for improvement.
  • Single Code Base – Allow only one code base.  If you need to create a separate branch make sure it is only temporary (temporary means that it lasts only a few hours).  Multiple code streams are a potent source of potential problems and time sinks.  Once upon a time, a team I managed maintained seven unique branches of a file maintenance system.  Every time we found a defect in one branch we had to update six other (or at least do the analysis). Three weekends, 12 pizzas and a lot of caffeine later we had one code base.
  • Daily Deployment – Deploy completed / tested code every night so that you get feedback on how the code operates in production. Shifting to Daily deployment is hard and requires planning so that functionality can be implemented if the customers are not ready.
  • Negotiated Scope Contract – Agree on work based on fixed times, cost and quality BUT renegotiate scope on a periodic basis.  This practice is reflected in the basic Agile thinking that fixes time (time boxes) and cost (stable team size) but assumes that scope will vary based on the businesses needs and problems encountered by the team.
  • Pay-Per-Use – Implement a pay-per-use or subscription approach to the software you developing or supporting as a mechanism to facilitate tangible feedback.  The marketplace (internal or external) provides more feedback than you can get from a customer satisfaction survey

I would suggest that when considering implementing XP begin with the primary practice that solves the highest priority problem.  Implement the practices of XP by using XP.  Write stories, make the change, measure and observe the results and then tweak the process.  Rinse and repeat until you can not longer improve (there is always room for improvement!)  


Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3

Week 3, Chapters 4 – 5

Week 4, Chapters 6 – 7