XP Explained Cover

We conclude the main portion of the re-read of Extreme Programing Explained, Second Edition (2005) with Chapters 24 and 25. Next week will present a few final thoughts before 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).  This week in XP Explained; Chapter 24 discusses the value of community as an asset to support the adoption and use of XP. Chapter 25 is Beck and Andres’s concluding notes on XP Explained. (more…)

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.

XP Explained Cover

This week we tackle Chapter 14 and 15 in Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005).  Chapter 14 deals with design.  Software design is a transition point in the life cycle that begins with business requirements and ends in functional software. The design translates the need into a cohesive solution. Chapter 15 covers topics related to scaling.  Scaling concepts focus on using XP to solve larger, more complex problems in more complex organizations.   

Next week we have more what will follow Extreme Programing Explained, Second Edition (2005) ; a re-read or a new read?  Thoughts?  In this week’s we tackle two concepts central to XP; planning and testing, both done the XP way. (more…)

XP Explained Cover

 

With this installment of our re-read of Extreme Programing Explained, Second Edition (2005) we are exactly halfway through the book.  We will have seven more installments including one week for an entry for overall reflections on the book. It is time to start thinking about what is next; a re-read or a new read?  Thoughts?  In this week’s we tackle two concepts central to XP; planning and testing, both done the XP way.

Chapter 12 Planning: Managing Scope (more…)

XP Explained

This week we tackle teams in XP and why XP works based on the Theory of Constraints in Extreme Programing Explained, Second Edition (2005). The two chapters are linked by the idea that work is delivered most effectively when  teams or organizations achieve a consistent flow. (more…)

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. (more…)

XP Explained

This week we begin Section 1of Kent Beck’s Extreme Programing Explained, Second Edition (2005), titled Exploring XP, by tackling Chapters two and three.  The first two chapters in section One provide us with an overview of the conceptual framework that underpins XP. 

Chapter 2: Learning to Drive.  In this chapter, Beck challenges us to consider that developing a product or writing code is like driving.  The metaphor of driving is used because driving is not a one-time event where you start the car and point it in the right direction then take a nap.  Rather, driving is a process of constantly paying attention, gathering feedback and making a series of small changes so that you arrive at your goal healthy and whole.  As noted in the preface, the core XP paradigm is “stay aware, adapt, change.” Tying the driving metaphor and XP together is the common problem of mushy requirements. In XP customers drive the content of the system and steer by getting feedback and adapting based on short iterations.  (more…)