The votes are in! The next three books for Re-read Saturday are:
Coaching Agile Teams by Lyssa Arkins https://amzn.to/38G0ZD3
Extraordinarily Badass Agile Coaching by Bob Galen https://amzn.to/3wJsbtS
Team Topologies by Matthew Skelton, Manuel Pais, and Ruth Malan https://amzn.to/3yXINzo
While Bob Galen’s book topped the poll, we will re-read it after Coaching Agile Teams so that I have a chance to read it first (so I can actually call it a re-read). Thanks to everyone who participated in the selection process.
This week, we are revisiting (and re-editing) the conclusion first re-read to tide you over to the completion of Why Limit WIP. I have been backpacking, glamping, and visiting my father for the past eight days. That in its own right would not have precluded completing our re-read, but I also forgot the power cord for my laptop.
—
Today we conclude our re-read of Extreme Programming Explained, Second Edition (2005) with a few final thoughts and five of my major conclusions from reading this book a second time. Next week we begin our read of The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one, please use the link to support the blog and podcast).
XP was my first real exposure to the guts of Agile. XP Explained (the first edition) was a formative part of my Agile education. I didn’t expect the re-read to have as much of an impact; however, reflecting on what I have gleaned from reading the second edition, I was wrong. Five of the more significant reflections of our re-read are listed below.
- XP is an expression of a strong set of values and principles. Values and principles provide a rationale for the practices that are the nuts and bolts of a methodology. Organizations first adopt the values and principles of XP and then tailor practices based on their needs and context. As long as they meet the values and principles of XP, organizations are extreme.
- The primary and secondary practices of XP fit together like a jigsaw puzzle. Each piece reinforces and supports the other. While they may be adopted incrementally until all practices are in place, other non-extreme practices will be needed.
- The one person you are really in charge of is yourself. When adopting XP, begin by changing how you work and then use the evidence of value to persuade others to change. This idea is useful when changing any organization. You need to be able to walk the walk before you ask others to follow you. I do not remember this theme from the first time I read the book; however, over the last fourteen weeks, this idea has become more important to how I think about how I approach any change – organizational or more personal.
- There is no one way to approach XP. Beck shows his experience with being out in front of change (based on his history of thought leadership in Smalltalk and Object Oriented Programming) by recognizing that concept purity is rarely a winning strategy when trying to have a broad impact. The goal of any change is what is of primary importance, rather than following the exact perfect path described in the “book”.
- One final note is that the second edition of XP Explained is fundamentally a different book than XP Explained, first edition. This was not so much a re-read as a new read for me. The second edition added a level of depth that can only come through feedback based on the continued evolution of XP use. My reaction to how different the two editions were might not be the same as not judging a book by its cover, but I now realize that it is not always a good idea to judge a book by its edition number.
Next week on the Software Process and Measurement Cast, Steven Adams and I will discuss his impressions from the re-read of XP Explained, second edition. I believe you will enjoy the conversation.
Bottom Line: XP Explained, Second Edition still provides readers with an extremely important message to those interested in improving both the value of the software they deliver and the work they perform.
I still recommend buying a copy of Extreme Programming Explained
