Tom Cagley’s re-read Saturday series continues with the book “Extreme Programming Explained (Embrace Change)” by Kent Beck with Cynthia Andres (second addition)

XP is much about software practices, rather than Scrum which is more about project management in an agile setting.  Read this interesting Continuous Delivery blog which complains Scrum leaves off the software practices and mentions that Continuous Delivery was built upon XP and Lean practices.

[Note:  after reading this book and I have changed my mind on the above point I made going into the re-read.  XP is as much about team dynamics and software project management as Scrum is.  XP adds good technical practices into the framework and that difference is noticed more than the other parts.]

Preface & Chapter 1  Tom, I liked your back-then and now comments.

I am still waiting for my copy of the book to show-up. I look forward to the read, as good technical practices make agile work.

Example, scrum is a good framework to follow for several reasons, communications, feedback, and team improvements. However, without the good technical practices, scrum will fall flat.

Martin Fowler makes a much stronger case in his classic blog, FlaccidScrum.

Chapters 2 & 3 [“Learning to Drive” & “Values, Principles, and Practices”]

Chapter’s 3 figure 1 bridge, is an excellent visual { values <- principles -> practices }.

Chapters 4 & 5 [“Values” & “Principles”]

It is hard to argue with any vitreous Values and Principles set, whether they come from Agile, Lean, Kanban, XP, Waterfall …

I like Jurgen Appelo’s approach in Management 3.0 (the book) and the “Do-It-Yourself Team Values” exercise.  Pick what makes sense for the team and the situation and do not pick too many (3 – 7), so the team has a focus.  After mastering certain value – principle – practices combinations, you may  choose other values / principles to focus on.

And we read similar advise in Extreme Programming Explained, where other principles might be included depending the the team’s situation (e.g., traceability for safety-critical systems).

Note:  Waterfall, really?  Gil Broza actually documented the Waterfall values in his “The Agile Mind-Set” book.  The values themselves read well (e.g., “Get it right the first time”). But in most cases, for software development, they are VERY difficult to actually do without increasing project risks.

Chapters 6 & 7 (“Practices” & “Primary Practices”)

Put a “*” on chapter 7, great advice!  I particularly liked the last primary practice – Incremental Design — defer design changes to the last responsible moment (real options thinking).

Beck cautions us “Without daily attention to design, the cost of change does skyrocket.” (page 52)

Beck’s simple heuristic look for and eliminate duplication – excellent!

Chapters 8 & 9 (“Getting Started” & “Corollary Practices”)

Beck provides practical advice on how-to get started implementing XP practices within a team setting or even just by yourself.  At the end of chapter 8, there is a nice map of “Energetic Work” (figure 8) to keep in-mind.

Chapter 9 talks about 11 Corollary Practices in XP, and interesting “Real Customer Involvement” is listed as a corollary practice, rather than a primary practice.  However, Beck explains why listed here, some of the development fundamentals should be addressed first — the two mentioned are (1) accurate estimates and (2) low defect rates.

Chapters 10 & 11 (The Whole XP Team & The Theory of Constraints)

Wow, chapter 11 changes the subject from chapter 10 — really two separate topics here.

Beck’s explanation on how different disciplines (architects, interaction designers, testers) resist working together, at the same time, is classic.  However, for user experience and feature validation , I do think a Lean approach should be considered in most cases.

Validate the feature and/or user-interaction with a prototype and with customers BEFORE it becomes part of the development backlog.

Why?  “the amount of waste and rework is very high because backlog items have not been validated” from Marty Cagan’s Dual-Track Scrum  blog (first paragraph) .

Beck’s explanation of ToC (Theory of Constraints) using laundry is one I can easily understand!  Again, I wonder how this chapter would be re-written today in light of Kanban and WIP (work-in-process) limits in the software context.

Chapters 12 & 13  (Planning:  Manage Scope & Testing:  Early, Often, and Automated)

Two great, short, chapters here.

*  [comment #1]

“Planning:  Manage Scope” is a must read for any project manager of software.  Beck write’s well what an experienced Project Manager has already learned.

See page 92 …

  1. “Time and costs are generally set outside the project.”
  2. “Lowering the quality of your work [to meet schedule] doesn’t eliminate work, it just shifts it later so delays are not clearly your responsibility.”

Therefore, scope almost always is the ONLY negotiable item from the project management “iron triangle” – Schedule, Budget, and Scope.  Which explains why Scrum’s sprint planning sessions were invented and are so popular today.

And I like Beck’s definition of ‘”Complete” means ready for deployment; including all the testing, implementation, refactoring, and discussions with the users.’ (p. 93)

The opening sentence of Chapter 13 is profound – “Defects destroy the trust required for effective software development”.  Having seen defects from both the inside and outside, I agree!

“Here is the dilemma in software development:  defects are expensive, but eliminating defects is also expensive.”

And one argument I had not considered before – “Investments in defect reduction makes sense as an investment in teamwork.”  Normally we consider the impact of defects to the business and end-users, but not the impact of defects to the team itself.

Chapters 14 & 15 (Designing:  The Value of Time & Scaling XP)

I liked much of what Beck and Andres states about Design.

  1. Do design!  And design in small increments whenever possible.
  2. Design at the last responsible moment.
  3. Designing software is not the same as design physical things (e.g., buildings). Although in today’s complexity between numerous systems, this is less true.
  4. Simplicity in design and some specific ideas to achieve it.
  5. Was Beck the first to use the popular phrase “big ball of mud” back in 2004?

One idea I think should be reworded is “Weekly delivery of the requested functionality is the cornerstone of the relationship.” (p. 109)

I think this idea pushes teams to just follow the customer (or Product Owner) lead, even when the team knows technical debt is piling up and there likely will be no plan to address it in the future.  And we do know, there are always new features the customer wants delivered yesterday.

I actually think Beck and Andres was cautioning us against  Big-Design-Up-Front (BDUP), rather than telling us to ignore technical debt in favor of delivering the next new feature.

Scaling XP (Chapter 15)

I think Beck left a marketing opportunity behind by not defining some elaborate scaling framework for XP 🙂

Some really good thoughts here.  Beck is a pragmatist, as am I.

  1. “The project manager makes sure the the organization’s expectations are met.”
    … while the team is using XP practices  (p. 113)
  2. “Don’t push your new-found (XP) knowledge and power on others for your own benefit.”  (p. 114)
  3. “I never became an actuary, but the resulting system (and team) was much stronger than if the actuary worked on his little corner of the system while I worked alone on the user interface.” (p. 115)
  4. “The XP strategy for dealing with excess complexity is always the same: chip away at the complexity while continuing to deliver.” (p. 115)

Chapters 16 & 17 (Interview & Creation Story)

Short and interesting!

About the Interview, I wonder how the XP transformation did the next of couple of years. XP was clearly a mandated change for the organization, train everyone and watch it take hold.  But to start, there were 1/3 were for it, 1/3 were neutral, and 1/3 had serious questions.

One bright call out, quality did improve!

[** comment #2]

The Creation Story (Chapter 17) is how the development teamed formed and became much better than the previous team using the XP framework and practices.  This XP Creation Story project ran like scrum projects that I am familiar with (p. 127)

How the backlog user stories were identified for each iteration:  the customer (product owner) choose.  But how did the customer know?  In this case, the customer was a subject matter expert and the domain space was already very well understood – payroll.

Contrast this to many of today’s projects.  Teams are often working in a domain that is emerging, have market acceptance risks, and there may not be a domain expert.  So we have ideas about quickly validating the selected backlog user stories (e.g., Lean Startup) before the true development starts (i.e., dual track agile).

(p. 128) “End-to-end is further than you think”

Chapters 18 & 19 (Taylorism and Software & Toyota Production System)

Taylorism – Frederick Taylor, early twentieth-century industrial engineer, concerned with efficiency.

Beck & Andres (p. 132)
“Things usually go according to plan,
Micro-optimization leads to macro-optimization,
People are mostly interchangeable and need to be told what to do.”

Does not work well in knowledge work (e.g., software development).
Agile values states the opposite.

Toyota Production System (TPS) – the foundation of lean software development.
A great, short summary of TPS!

Beck & Andres writes about a worker cautiously pulling the chord shortly after a quality issue was spotted. From Lean, this is the Andon Chord (pull it immediately).  And Yea!!! for any organization culture which supports the Andon Chord philosophy.  It definitively would take nerve to “stop the workflow” in an organization mainly focused on throughput – won’t happen very often, as this action would be viewed as a risky move.

Chapters 20 & 21 (Applying XP & Purity)

(p. 139) “You should see big improvements in the first weeks and months, but those improvements only set the stage for the big leaps forward that happen further down the road.”  — this selling statement could apply to any framework.  Could happen that way, but no guarantee.

Two implementation tips I like are …

  1.  Speaking about using a unit test framework  –
    (p. 141) “Expecting others to do what you are not willing to try yourself is disrespectful and ineffective.”   This advice, of course, applies in many other situations.
  2. (p. 141) “Your organization learns to deploy solid software predictably, then invites external customers to be part of planning.”
    Wow, once you arrive here, your team is golden!

Chapter 21 (Purity)

(p. 146) “It’s worse to fail with an XP team than to succeed with a pure waterfall team.  The goal is successful and satisfying relationships and projects, not membership in the XP club.”

XP, as with any process & practices framework, is a means to a goal, not the goal itself.

Chapters 22 & 23 (Offshore Development & The Timeless Way of Programming)

Beck and Andres make a good case to use the wording of “multi-site”, instead of “offshore”.  But the chapter is titled with Offshore — well this chapter, “Offshore Development”, was a few years back  (2005).  The term “distributed teams” is commonly used today (2016).

(p. 150)  “Jobs aren’t going in search of low salaries.  Jobs are going in search of integrity and accountability.”  That is, capability to deliver value first and labor costs second.

Chapter 23 (The Timeless Way of Programming)

Wow!  Note to self, re-read this chapter for culture-change thoughts about creating higher value software deliveries from  teams.

It is vital that we achieve a balance in the organization between business concerns, user experience concerns, and technical concerns.

*** [comment #3]

(p. 154) “With more experience I began to see the opposite imbalance [of technical dominance], where business concerns dominated development.  Deadlines and scope set for only business reasons do not maintain integrity of the team.  The concerns of users and sponsors are important, but the needs of the developers are also valid.  All three need to inform each other.”

(p.154) “My goal is now to help teams routinely bring technical and business concerns into harmony.”
Note:  I bet this sentenced would be re-worded slightly today by adding User Experience as a separate concern to Business and Technical.

A 2005 prophecy about Agile Adoption …
(p. 154) “Without a change of heart, all the practices and principles in the world will produce only small, short-term gains.”

And there is two more good thoughts …
(p. 155) “XP relies on the growth of powerful [capable] programmers; able to quickly estimate, implement, and deploy reliable software.”

(p. 155) “Sharing power is pragmatic, not idealistic.”

Chapters 24 & 25 (Community and XP & Conclusion)

Brief wrap-up statements in both of these chapters.

(p. 158)  “Accountability is particularly important when making changes.”

Do NOT ignore the great Annotated Bibliography at the end of the written text.  Some really interesting categories and titles there.


Great read (or re-read) for software professionals, including software project managers and scrum masters!

My favorite quote from this book is
“End-to-end is further than you think” (Chapter 17 – Creation Story, page 128)

End of the re-read of “Extreme Programming Explained (Embrace Change)”