XP Explained Cover
This week the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) tackles Chapters 22 and 23. Two more weeks until we shift gears and start reading The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one – use the link to support the blog and podcast).  Back to XP Explained; Chapter 22 considers the implications of offshore development on the application of XP.  Distributed team members does not preclude using XP.  Chapter 23 waxes philosophically on the programming.  At its core, programming is a discussion of people and behavior more than technique and tools.

Chapter 22: Offshore Development
In the late 20th and early years of the 21st centuries, the software industry was still learning how to grapple with offshore development. Distributed teams became a popular idea.  Whether a team was partially in India, Belarus or Iowa has always been less of an issue than how power and decision making is distributed.  Beck makes the point that even the word ‘offshore’ is a loaded concept that implies an imbalance of power (Beck prefers the term “multisite”). Teams with imbalance of power and decision making will be less effective because parts of the team will be demoted to order takers rather than collaborators.  The values of XP (and therefore XP as an approach to development) are just as relevant in multisite development. When embracing XP in a multisite environment the values and principlesof XP provide a stable underpinning to tailor the core and ancillary practices of XP.

The practices of XP, as we have noted before, are merely tools to implement the values and principles of XP.  There is no perfect set of XP practices, but rather each organization needs to implement XP based on their own context.  Multisite development is just another context. As an example, Beck suggests that in a multisite environment planning might have to occur multiple times a week rather than once every sprint or iteration.

The goal of multisite development is to increase productivity.  There are numerous ways to state this goal, such as to get more with less or to improve the value of software delivery; however as we have explored in previous essays, all of these statements boil down to improved productivity.  One way to measure and provide evidence of improved productivity is to reduce team sizes while increasing throughput. The second goal of multisite development is to reduce waste in software development rather than trying to put up barriers that keep work in places with low productivity or high production costs. Everyone should consider the second goal as a clarion call for continuous improvement (process, people and technology) to protect competitiveness and jobs.
Side Note:  Even though XP Explained, Second Edition was published in 2005, the state of multisite development is still mixed.  I have worked as a consultant for many organizations that leverage multisite development.  Done well multisite site development often offers significant value, but many organizations approach the model poorly and therefore don’t get the value they expect.

Chapter 23: The Timeless Way of Programming
When I read this chapter I was struck by how different the two editions of XP Explained are when compared. The second edition far more philosophically in tune with the world of software development of the early 21st Century (i.e. now). Beck begins the chapter by using the analogy of the power differential between a structural architect and the person for whom he or she is designing the space.  The architect has the upper hand, unless a balance of between the parties can be established.  In the software development environment, the relationship between the business and development, in which the business describes both what they want and the how, when and cost of what will be delivered, is a reflection of a similar power imbalance.  A healthier relationship requires a balance between the business and technical view that maintains the integrity of the overall system.

The values, principles of XP promote the aim of a balanced relationship between the business and development. XP describes an environment in which the team includes technical and business personnel.  XP provides an environment in which developers can develop and excel technically so decisions about the business can be left to the business-oriented part of the team. As Beck puts it,”sharing power is pragmatic, not idealistic.” In the end XP is discussion of empowering people versus primarily being a discussion of tools and techniques.

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  

Week 5, Chapters 8 – 9

Week 6, Chapters 10 – 11

Week 7, Chapters 12 – 13

Week 8, Chapters 14 – 15

Week 9, Chapters 16 – 17

Week 10, Chapters 18 – 19

Week 11, Chapters 20 – 21

Remember  we are going to read The Five Dysfunctions of a Team by Patrick Lencioni next.  This will be a new book for me; therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks, we will begin to read the book together.