Myth: The Scrum Master Must Resolve Every Problem
In this series of posts, we—your MythBusters Christiaan Verwijs and Barry Overeem—address common myths and misunderstandings. Thea Schukken created the great visuals.
If you prefer, you can also listen to us reading this post.
Today’s myth concerns how problems that hinder a team's work are resolved, from a broken Wi-Fi router to a steady stream of meeting requests from outside the team and from clarifying unclear work to resolving a conflict between members.
We’ve met several teams where the Scrum Master has a full-time job taking care of these kinds of problems, or ‘impediments’ as they are called. Some Scrum Masters go to great lengths to set up their own ‘Impediment Board’ and invite the team to put new impediments on it for them to resolve. Today, we bust the myth that it is the Scrum Master's responsibility to resolve all problems hindering the team.
Busting the Myth
The Scrum Guide clearly describes the various services that a Scrum Master provides. One of those is to remove impediments to the team’s progress. At first glance, this seems to support today’s myth. But ‘impediment’ is an important keyword here. All too often, impediments are assumed to be whatever problems arise during the Sprint. But this is not how this responsibility should be understood.
What makes something an ‘impediment’?
Impediments are those problems that hinder a team’s progress toward the Sprint Goal and lie outside of their capability to resolve on their own. This ties impediments strongly to another concept that is central to Scrum: self-organization. The background here is that software development is a very complex, unpredictable endeavor — it is likely for all sorts of unexpected problems to emerge during a Sprint. Examples of such unexpected problems are:
- Team members becoming sick
- problems with the development environment
- A broken laptop
- Unavailability of the Product Owner
- Conflict between team members
- Bugs in the production environment
A great demand is placed on teams to use their professional expertise, creativity, and collective intelligence to solve problems as they emerge. Within Scrum, the self-organizing nature of a team can be understood by their ability to solve the problems they run into without having to delegate ownership of the problem to people outside the team. In that regard, we prefer to explain impediments as those problems that, when resolved, improve the chances that the team can solve similar problems on their own the next time they occur.
Teams can resolve many problems, such as clarifying unclear specifications, fixing deployment issues, or even resolving a conflict within the team.
The difference may seem trivial, but the consequences are not. Is a team truly self-organizing when all problems that arise need a Scrum Master to resolve them? What happens when only the Scrum Master can resolve a conflict between team members? What happens when only the Scrum Master can help the team clarify unclear specifications with the Product Owner or break down large chunks of work? What happens when only the Scrum Master can resolve infrastructural problems? A Scrum Master who solves most of the issues that arise does not do a team any favors. He or she is actively impeding the (growing) ability of the team to solve their problems.
Some real-life examples of problems and impediments
All this talk about ‘self-organization’ and ‘impediments’ is still quite abstract. So, let’s break it down into some concrete examples to work with.
Example #1: Infrastructure problems
Suppose a team runs into problems with its infrastructure. It cannot deploy applications independently and depends on an external team. On the day before the Sprint Review, the team is having problems with a deployment. An impediment is raised during the Daily Scrum, and the Scrum Master takes it upon himself to resolve this.
The problem raised is just a symptom of a more profound impediment: the inability of the team to do their deployments or at least solve issues related to deployment. By solving only the problem at hand, the Scrum Master does not help the team improve their ability to solve similar problems independently. Instead, the Scrum Master can address the actual impediment by allowing the team to find ways to resolve deployment problems independently. One solution might be to add the skills or the people needed to the team. Another solution might be for the team to set up and manage their infrastructure (DevOps). A more low-tech solution might be to create communication channels between the team and the people capable of resolving deployment problems (e.g., liaisons). Whatever the solution, it should emerge from the team with help from the Scrum Master.
Example #2: Team conflict
Another example. Suppose a team deals with two members who can’t stand each other. Instead of talking about the problem themselves, it is delegated to the Scrum Master to resolve. The actual impediment here is the inability of the team to deal with their conflicts. Perhaps there is no psychological safety within the team to talk about it. People may not know how to resolve disputes or lack the courage to do so. By solving only the problem, the Scrum Master does not help the team improve their ability to solve similar problems independently. Instead, the Scrum Master could facilitate a session where frustrations are aired, and the team mediates solutions (instead of being handed one). The Scrum Master can model the behavior needed for conflict resolution, like asking open-ended questions, showing empathy, finding common ground, and inviting team members to do the same.
Example #3: Not enough work
A final example. Suppose a team finds itself in a position where half the team has nothing to do. This is raised as an impediment during the Daily Scrum, and the Scrum Master is tasked with finding them some work. The actual impediment here is that the team must collaborate so that everyone can contribute to achieving the Sprint Goal. Instead of finding work, the Scrum Master would investigate why this is happening. He or she might address this during a themed Sprint Retrospective. Or perhaps the team is unaware of practices that promote collaboration, like pair- or crowd-programming, breaking up large chunks of work, or testing work by others (‘two pair of eyes’). Or maybe there are people in the team acting as ‘Towers of Knowledge’ and taking up most of the work while the rest work on the crumbs. Either way, the Scrum Master can help the team become more self-organizing by finding solutions for these impediments, not for the (symptomatic) problem raised during the Daily Scrum.
Being a successful Scrum Master means …
Successful Scrum Masters help teams increase their ability to resolve problems independently. This is something that teams have to learn, and the Scrum Master helps them do so. What may be considered an impediment during Sprint 1 may have become a problem that the team can quickly resolve by itself during Sprint 5. If you want to know if you are doing an excellent job as a Scrum Master, monitor the ability of a team to resolve problems on their own over time. If this is increasing, you are probably doing a good job.
So, Scrum Masters never resolve problems?
Does this mean that a Scrum Master never resolves problems? Of course not. Scrum Masters are still part of the Scrum Team. Perhaps a Scrum Master will fix that wi-fi router if the team is focused on solving a major technical problem. Or a Scrum Master can facilitate a session to break down large chunks with the team so they can more easily get it done within the Sprint. Solving problems for the team is acceptable for the right reasons. Don’t do it out of routine. Before solving a problem, consider if you’re helping the team grow in their ability to resolve similar problems independently. A good guideline to remember is:
“A Scrum Master should reveal, not resolve.”
Tips
- Don’t wait until the Daily Scrum to raise an impediment. Consider the Daily Scrum as the most minimal opportunity to discuss obstacles. Real blockers to the team’s progress should be addressed immediately.
- Whenever the team raises a potential impediment, consider what would happen if you didn’t resolve it. Will someone else on the team take care of it?
- There is nothing wrong with an ‘Impediment Board’ to clarify what impediments have been removed over time. But make sure to use it for real impediments, not just for whatever problem the team feels like delegating to the Scrum Master. And make sure that the entire Scrum Team owns the board and is not just for the Scrum Master;
- Not every impediment is important. Use a Sprint Goal as a compass and guidance. As a Scrum Master, you should primarily act on impediments that hinder the team from achieving the Sprint Goal. Focus on these impediments before resolving anything else;
- Be brave and creative in removing impediments. Remember, “A good Scrum Master will push for permission to remove impediments to team productivity. A great Scrum Master will be prepared to ask for forgiveness.” (Geoff Watts — Scrum Mastery)
- One of the most powerful tools of a coach is the use of silence. Remain silent and see what happens next. The same goes for how a Scrum Master should act. As an experiment, don’t act on an impediment and see what happens;
- Collaborate with the Product Owner. Often, impediments will be related to product management and collaboration with stakeholders and suppliers. The Product Owner is a key player in this area. Therefore, ensure a solid relationship with the Product Owner.
- Understand the difference between ‘blocks’ and ‘impediments.’ A block affects only a single task, whereas an impediment acts like a parachute, slowing overall progress. Quite often, the team can fix blocks themselves, whereas impediments need to be fixed by the Scrum Master (Ilan Goldstein — Scrum Shortcuts with cutting corners)
- Focus on the real problem, not the first problem. Ask questions to understand the situation. Check if it’s an impediment or a learning opportunity for the team.
“Focus on the real problem, not the first problem.”
Closing
Today, we busted the myth that the Scrum Master is responsible for solving all the problems that hinder the team from achieving the Sprint Goal. Instead, the Scrum Master should help the team become increasingly capable of resolving similar problems independently (self-organization). The Scrum Master addresses problems that ‘act as a parachute’ to the team, not just whatever pops up. In this post, we offered some concrete examples and clarified what kind of problems a team should solve and what problems are ‘impediments’ to be picked up by the Scrum Master. We also offered some tips on how to do this.
What do you think about this myth? Do you agree? What are your ‘lessons learned’?
