Skip to main content

Solving Impediments as a Scrum Team

August 20, 2019

TL; DR: Solving Impediments as a Scrum Team

The main message of the retrospective was clear: there are too many interruptions by stakeholders and senior management. The interruptions impeded the flow of work through the team. Consequently, achieving the Sprint Goal had been at risk several times in the past. Moreover, the team missed the Sprint Goal twice recently. Solving impediments as a team has become a necessity.

Learn more on how to tackle impediments as a team by running experiments, iterating and visualizing on the solution.

Types of Impediments

According to the Scrum Guide, the Scrum Master should be the right team member to deal with this kind of impediment:

“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
Download the Scrum Guide Reordered for free

However, there are various reasons why stakeholders — and particularly the senior management — are ignorant of basic agile concepts that are essential for the productivity of a Scrum Team:

  • They have never had an introduction to agile and lean practices in the first place. (This is undoubtedly is a rookie mistake; becoming agile requires that everyone in the organization at least receives a basic introduction into how ‘agile’ works.)
  • Even if they received such a basic introduction to agile practices, they have never been introduced in flow theory and productivity. The effect of their interruptions is unknown to them. Probably, none of the Scrum Masters or agile coaches of the organization felt competent enough to teach the concept of flow. (This might also be partly attributed to the reputation of the standard textbook on this issue, Reinertsen‘s “Principles of Product Development Flow,” which is considered ‘difficult’ to read.)
  • There also is an attitude among some senior managers that the ‘agile rules’ do not apply to them, no matter how often the Scrum Master points at their misguided behavior. Weak leadership will always find plausible reasons — by their standards — why their information requirements need to be handled in a privileged way. (Question: who do you escalate the issue to if the culprit is the Chief Product Manager, the CTO, or the CEO?)

The mere fact that stakeholders and managers interrupt the team is hence no reason to point at the Scrum Master but an excellent opportunity to tackle the issue as a team.

Solving Impediments like the Interruption Problem as a Team

In this case, the Scrum Team decided to approach the impediment at two levels:

  1. The Scrum Master reached out to the stakeholders and the management to offer a short training class at a convenient time slot late in the evening to educate them on the productivity issues of agile teams.
  2. The Product Owner created on the half of the Scrum Team an interruption bucket poster on a wall in the team space. (Learn more about interruption buckets from Jimmy Janlén’s book “Toolbox for the Agile Coach - Visualization Examples, How great teams visualize their work.”)
Version 1 of the interruption bucket — Solving Impediments as a Scrum Team

At the next retrospective, two weeks into the experiment, the Scrum Team analyzed the situation:

  • The response of the stakeholders and the senior management to the workshop on team productivity was lower than expected. The offer did not reach the most ignorant culprits in particular.
  • However, the interruption bucket managed to trigger discussions in the team area. It proved useful to add a sticky at the beginning of the interruption and pointing at the same time at the issues of interrupting the flow. Some stakeholders and managers were surprised to learn about the problems. At the end of the Sprint, there even were reactions like “I will send you an email, I do not want another sticky in my column.” On the other side, the most notorious wrongdoer could not care less about the visualization.

Hence the team decided to iterate on the problem-solving approach:

  • The Scrum Master was now seeking 1-on-1s with those who did not attend the workshop and piled up several stickies on the interruption bucket board.
  • The interruption bucket received a make-over, now distinguishing between helpful and non-helpful interruptions. (Among all disruptions there were also useful interruptions that were just misdirected communication-wise.) 
Interruption bucket version 2 — Version 1 of the interruption bucket — Solving Impediments as a Scrum Team
  • The team decided to introduce do-not-disturb-hours and visualize this schedule.
Do not disturb hours — Version 1 of the interruption bucket — Solving Impediments as a Scrum Team

A Sprint later, the impediment could be practically contained to a single person while the others appreciated coaching them on how to better interact with the Scrum Team.

Join 24,000 Agile Peers and Subscribe to the Weekly Food for Agile Newsletter

Conclusion — Solving Impediments as a Team

As so often, collaboration proves to be ground from which to grow a successful Scrum Team. Tackling the impediment as a team by running experiments and iterating on the solution improved in this case the team’s productivity as well as its standing with stakeholders and the senior management. (Except for one, but that is another story.)

What lessons have you learned when collaborating as a Scrum Team to solve an impediment? Please share with us in the comments.


What did you think about this post?