Today we conclude our re-read of Extreme Programing Explained, Second Edition (2005) with a few final through 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 the 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 Orient 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 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 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 from the work they perform.
Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday: