A client, “Deidre,” reached out to me for advice.  One of her Scrum Teams expressed concerns with an approach Applied Frameworks recommends for conducting a Daily Scrum known as “walking the board” instead of “walking the team.”  Deidre wanted to know if there were any concerns with the team reverting to “walking the team” in their Daily Scrums.  

We have previously covered “walking the board” and other Daily Scrum techniques in-depth, but to briefly summarize, it is an item-by-item review, not a person-by-person review.  Here is an example to illustrate these two approaches for a Daily Scrum.  

Suppose a team has the following items in their Sprint Backlog:

Sprint Backlog Item #1

    • Task 1 = DONE
    • Task 2 = In progress (Bob)
    • Task 3 = In progress (Graciella)

Sprint Backlog Item #2

    • Task 1 = In progress (Sermet)
    • Task 2 = In progress (Vikas)

When opting to “walk the team” in a Daily Scrum, the focus of the conversation could go from Bob to Vikas, then to Graciella, and finally to Sermet. Unfortunately, jumping back and forth between the two Sprint Backlog items makes the conversation disjointed and focuses on the individuals, not the value being delivered.  

Conversely, when “walking the board,” the team focuses the conversation on the first backlog item before moving to the second backlog item.  In the above example, Bob and Graciella would discuss the progress made on Sprint Backlog item #1, their plans to get to Done, any assistance they may need, and any impediments they may have.  Once that discussion is complete, the team shifts to discussing the same for Sprint Backlog item #2.

We encourage teams to avoid context switching, as described in this video, and to swarm on the work.  “Walking the board” focuses on the delivered outcomes, encouraging the team to refrain from working on new Sprint Backlog items until the ones in flight are brought to Done.

When asked why the team did not like “walking the board,” Deidre explained that the team had a situation where a contractor, “Terry,” did not pick up any new work for two sprints (i.e., 4 weeks).  Many thoughts swirled in my mind (along with images of Harrison Ford) as I contemplated what lies beneath?  How could an individual not contribute to the team for an entire month? Admittedly, I didn’t have all the details, but my cursory assessment was that “walking the board” was not the culprit. Instead, there were several missed opportunities built into the Scrum framework itself that could have prevented or highlighted this scenario.

  • Scrum promotes self-managing teams and full Scrum Team accountability. 

The Scrum Guide explicitly states that the Developers on a Scrum Team must hold each other accountable as professionals. However, I suspect the other team members noticed Terry’s lack of engagement and contribution during the Daily Scrum but opted not to speak up.  Why?  Perhaps the team did not fully understand or embrace what it means to be self-managing.

  • Scrum emphasizes the importance of a Scrum Master who is accountable for the Scrum Team’s effectiveness.  

Ideally, the Scrum Master would have identified Terry’s lack of engagement and contribution and noticed the failure of the other Scrum Team members to hold them accountable.  The Scrum Master could have used this lack of transparency as a coachable moment for the Scrum Team.  Alternatively, the Scrum Master could have used this opportunity to direct the Scrum Team’s attention to their working agreements and coach the team on how to tailor their agreements to improve their effectiveness.  Or the Scrum Master could have pointed the Scrum Team’s attention to various information radiators in use (e.g., taskboard, burndown chart, etc.) and how these tools could have increased transparency within the team.

  • The Sprint Planning event within Scrum is an opportunity to collaborate in creating a plan for delivering the work in the Sprint.  

To dig deeper into potential root causes, I would evaluate the Sprint Planning event. For example, if Terry was present, did they contribute to the discussion of how the work should be completed and help decompose the Sprint Backlog items into tasks? The Sprint Planning event could have been an early indicator of Terry’s potential lack of engagement.

  • The Sprint Retrospective event within Scrum is an opportunity to reflect on the past Sprint and identify improvements.

Continuing to dig deeper, I would evaluate the effectiveness of the Sprint Retrospective.  If team members or the Scrum Master did notice a lack of engagement throughout the Sprint but didn’t speak up, then the Retrospective should have been another forum the Scrum Team could have leveraged to raise concerns.  I would like to know if Terry’s lack of contribution was raised in the Sprint Retrospective, and if not, why?

In my years of coaching Agile teams to “walk the board,” most teams prefer this approach.  I was less concerned that the team wanted to revert to “walking the team” vs. “walking the board.”  After all, Scrum is a framework that allows the team to decide how they work. 

What concerned me was the lack of understanding of WHY the team wanted to revert to this method.  I suspect the team might have perceived “walking the team” as a more passive way to hold one another accountable. Scrum could have offered multiple ways to address the root cause of this issue, but no one, not even the Scrum Master, thought to consider deeper root causes.  Instead, the team members wanted to revert to what was familiar, “walking the team.”

The next time you observe a similar scenario, pause and ask yourself, “WHY is this occurring?” Is the team attempting to treat a symptom rather than address a root cause? Hopefully, you won’t encounter a web of terror and deception like Harrison Ford and Michelle Pfeiffer’s characters. Instead, I’m confident you will uncover more profound issues and anti-patterns beneath the surface.