Listen Now

This week we make a quick side trip. Earlier this week I was asked why I “did” the Re-read Saturday column. Today, I offer a short explanation and highlight the experiments I am running as part of our re-read of Coaching Agile Teams by Lyssa Adkins.

We also have a visit from Jon M. Quigley. In this installment of his Alpha and Omega of Product Development, Jon and I discuss the role of the team lead in agile teams that have coaches, scrum masters, and just might be self-organizing. There is a role but it is not the classic version that is in common use.

Why Do I “Do” Re-read Saturday.

Re-read Saturday is a long-running column featured on my blog ( and at The books selected for the column are nominated and then voted on by readers. Because most books are selected by the acclaim from readers of the blog, the re-read is sometimes actually the first read for me. During the re-read we read, discuss, and highlight concepts chapter by chapter. 

There are three major reasons for the column. One, the column draws eyes. A blog without readers is a diary. Over the years, many of the top 10 annual posts have been from the re-read feature. A second reason, and perhaps the original reason was that I had not read some of these books before and really needed to read them. For some of the other books we have re-read, the re-read drove home the point that memory erodes over time. For example, I am embarrassed to say I had forgotten the story of Herby (check out the re-read of The Goal). Reason two is that the re-read is a forcing function to guide behavior. The books we read and re-read help shape how we behave. The third reason is that the column generates a lot of interaction. I have heard from readers and authors with ideas and opinions. The interactions have certainly improved my understanding of how work is done and how to improve. The level of interaction suggests that the readers get similar benefits.

Recently, I decided to run weekly experiments based on the chapter I am reading. The weekly experiment is another forcing function. Doing the activity drives home a point so it is harder to forget. For example from the re-read of Chapter 2 of Coaching Agile Teams by Lyssa Adkins titled Expect High Performance I am focusing on using metaphors to guide behaviors. As an experiment, I am establishing a metaphor for myself. The goal is to see whether having a metaphor changes my behavior. The concept of the weekly experiment might end up being the best reason for me to “do” Re-read Saturday and perhaps the best reason for you, the reader, to participate.

PS — I am not convinced that the person that asked was really looking for this much information. I actually think they we asking why read books at all when you watch videos which lead us to a different discussion which I will share another day. 

Finally, have you downloaded the book referenced in last week’s interview? Check out Seeing Money Clearly at 

Re-read Saturday News

This week, Chapter 2 of Coaching Agile Teams by Lyssa Adkins (SPaMCAST Amazon affiliate line – buy a copy). The chapter’s title is Expect High Performance. As a coach, you need to have high expectations of yourself and those you are coaching. 

Remember to buy a copy of Coaching Agile Teams by Lyssa Adkins and read along.

Previous Installments

Week 1: Logistics and Introduction 

Week 2: Will I Be A Good Coach 

Week 3: Expect High Performance 


Jim Benson has a new book titled, The Collaboration Equation. The first sentence in the description of the book is:

 “It is the base of the human condition, we need other people in order to live, but always seem to be at odds with each other.”

We went from there,

If we agree that transactive memory is a common feature of teams’ institutional memory and accept the benefits, then we must address the risks. That should not be a major assumption. In many situations it makes sense. Knowledge can be stored in a single place and then accessed by the team as needed. The idea of having one version of data was one of the reasons I was taught normalization when I was working in the database realm. Transactive memory acts as a form of normalization so teams can reduce redundancy and conflicting truths. When the process works, a team will be more than the sum of its parts. While this seems very mechanistic, I would not suggest ignoring the idea in a fit of humanistic pique. I have not found a team or relationship that has been together for more than a few days that is not leveraging transactive memory. However, as described in our overview, there are two macro scenarios where transactive memory causes problems for a team adopting new approaches. They are:


I spend a lot of time studying individuals and teams in a quest to help them learn how to deliver more value. One of the most common failure scenarios I observe is that once organizations have reached a decent level of effectiveness, someone will leave and the whole thing will come tumbling down. I am not trying to suggest that turnover and change should be stamped out (I actually think it is healthy), but rather something else is amiss. Several years ago I was able to study the implementation of an agile scaling methodology in a Fortune 100 company. The study looked at quality, productivity, and cycle time across 15 product lines. In every case, the metrics fell during implementation (this was expected) then improved spectacularly, over 80% improvement in every metric, the year after implementation. Unfortunately, things got murkier when the consultants supporting the change were withdrawn and sent elsewhere. The metrics fell by 30 to 50% from the high watermark. I am not arguing that consultants should be permanently ensconced in any organization – it is unhealthy but rather something else is amiss. Recently I forgot to call my father on his birthday. My wife remembers things like special events and then clues me in…if she is around. This time she was not. The whats amiss in all three of these scenarios is a reflection of the risks of transactive memory. 


The Software Process and Measurement Cast 665 features our essay on the organizational aspects that impact teams. Teams don’t live in a vacuum, so when the word organization gets used it reflects the influence of all sorts of organizations. Organizations facilitate teams to a greater or lesser extent. In the workplace, the employer’s organization will have the most significant impact on how teams form and perform but it is not the totality. Other influences can affect the structure and performance of teams. 

We will also have a visit from Jon M Quigley who will bring his Alpha and Omega of Product Development column to the podcast. In this installment, Jon and I discussed the idea of making decisions at the last responsible moment. We decided on the topic just before we began recording (just kidding). 


Teams don’t live in a vacuum. Every team is an intersection of boundaries of all sorts of organizations. Organizations facilitate teams to a greater or lesser extent. In the workplace, the employer’s organization will have the most significant impact on how teams form and perform but it is not the totality. Other influences can affect the structure and performance of teams. In the short run, many organizational factors are difficult and slow to change (not impossible).  Many of the behavior factors noted earlier in this thread might be an affectation of the organization. A few of the most critical attributes to consider are:


The second category of attributes that are important for teams to be effective is behavioral attributes. These attributes describe how individuals and teams as a whole act. While the first category, skills is about the individual, behavior is about the team as a group. All team members’ behavior should contribute to how the team works together to meet it’s goal. The most important behavior attributes are:


Most outcomes in software development and information technology are reflections of team activities. Whether coding a new function or provisioning a server people work together to achieve a goal. The great majority of these collaborations yield positive results; sometimes the results are even extraordinary.  The team or teams doing the work have a HUGE impact on the results.  A coach or a guide needs to be able to read the tea leaves so they can help teams improve. In Teams: The Heart And Soul Of Work, I identified three categories of attributes of good teams. They are:

  1. Skils,
  2. Behaviors, and 
  3. Organization.

In the SPaMCAST 644, we talk teams. At the core of agile is the belief that the team is the fundamental building block of work. Because they are so important, organizations put tons of effort into helping and guiding teams. The problem is not that teams aren’t important or that we aren’t working hard to make them better, teams are still chronically messed up. We discuss a framework for guiding support for teams. 


Teams are the most common grouping of people in agile. I do not think I have been to conferences, in-person or virtual, without being told how important teams are to the delivery of value. Because they are so important, organizations put tons of effort into helping and guiding teams. The problem is not that teams aren’t important or that we are working hard to make them better, but rather that regardless teams are chronically messed up.


Collaboration is not easy. If we start with the premise that collaboration is important, even critical, why does it often fail to emerge or wither on the vine? This is not a rhetorical question. Knowing what can break collaboration is just as important as understanding the prerequisite. Four of the most common ways collaboration gets messed up include:


Next Page »