Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we - your ‘mythbusters’ Christiaan Verwijs & Barry Overeem - will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here (1, 2, 3, 4 , 5 and 6).
Myth 7: The Scrum Master Must Resolve Every Problem
Today’s myth is all about how problems are resolved that are hindering a Development Team in their work. 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 quite a few 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 through great lengths to set up their own ‘Impediment Board’ and invite the Development Team to put new impediments on it for them to resolve. Today we bust the myth that it is the responsibility of the Scrum Master to resolve all problems that are hindering the Development 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 Development 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 the way how this responsibility should be understood.
What makes something an ‘impediment’?
Impediments are those problems that hinder a Development Team’s progress 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 - with software development being 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 Development Teams to use their professional expertise, creativity and collective intelligence to solve problems as they emerge. Within Scrum, the self-organizing nature of a Development 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 Development Team can solve similar problems on their own the next time they occur.
Many categories of problems are resolvable by Development Teams, like clarifying unclear specifications, fixing problems in a deployment or even the resolution of a conflict within the team.
The difference may seem trivial, but the consequences are not. Is a Development 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 members of the team? What happens when only the Scrum Master can help the Development Team clarify unclear specifications with the Product Owner, or break down large chunks of work? What happens when only the Scrum Master can get infrastructural problems resolved? A Scrum Master that solves most of the problems that arise is not doing a Development Team any favors. He or she is actively impeding the (growing) ability of the Development Team to solve their own 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 Development Team runs into problems with their infrastructure. Not being able to deploy applications on their own, they depend on an external team. On the day before the Sprint Review, the Development Team is having problems with a deployment. An impediment is raised during the Daily Scrum, and the Scrum Master takes it upon himself to get this sorted out.
The problem that is raised is just a symptom of a deeper impediment; the inability of the Development Team to do their own deployments or at least solve problems related to deployment. By solving only the problem at hand, the Scrum Master does not help the Development Team to improve their ability to solve similar problems on their own. Instead, the Scrum Master can address the actual impediment by helping the team find ways to resolve deployment problems on their own.
One solution might be to add the skills or the people to the Development Team that are needed to do this. Another solution might be for the team to set up and manage their own infrastructure (DevOps). A more low-tech solution might be to create communication channels between the Development Team and the people capable of resolving problems in deployments (e.g. liaisons). Whatever the solution, it should emerge from the Development Team with help from the Scrum Master.
Example #2: Team conflict
Another example. Suppose a Development Team is dealing with two members that 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 own conflicts. Perhaps there is no psychological safety within the Development Team to talk about it. Or people don’t know how to bring up conflicts or lack the courage to do so. By solving only the problem, the Scrum Master does not help the Development Team to improve their ability to solve similar problems on their own.
Instead, the Scrum Master could facilitate a session where frustrations are aired and where the team mediates solutions (instead of being handed one). The Scrum Master can model the kind of behavior needed for conflict resolution, like asking open-ended questions, showing empathy and finding common ground, and invite members of the team to do the same.
Example #3: Not enough work
A final example. Suppose a Development Team finds itself in the 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 Development Team is apparently not collaborating in a manner so that everyone can contribute to achieving the Sprint Goal.
Instead of finding work, the Scrum Master would do well to investigate why this is happening. He or she might address this during a themed Sprint Retrospective. Or perhaps the Development 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 that are acting as ‘Towers of Knowledge’, and take up the bulk of the work while the rest works on the crumbs.
Either way, the Scrum Master can help the Development Team become more self-organizing by finding solutions for these impediments, not for the (symptomatic) problem that is raised during the Daily Scrum.
Being a successful Scrum Master means ...
Successful Scrum Masters help Development Teams increase their ability to resolve problems on their own. 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 an problem that the team can easily resolve by itself during Sprint 5. If you want to know if you are doing a good job as a Scrum Master, monitor the ability of a Development 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 Development Team is totally focussed on solving a major technical problem. Or a Scrum Master can facilitate a session where the team breaks down some large chunks of work. Solving problems for the Development Team is totally acceptable if it is done for the right reasons. Don’t do it out of routine. Before solving an problem, consider if you’re really helping to the Development Team to grow in their ability to resolve similar problems on their own. 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 impediments. Real blockers to the team’s progress should be discussed immediately.
- Whenever a potential impediment is raised by the team, consider what would happen if you don’t do anything. Will someone else in the Development Team take care of it?
- There is nothing wrong with an ‘Impediment Board’ to make transparent what impediments have been removed over time. But make sure to use it for real impediments, not just for whatever problem the Development Team feels like delegating to the Scrum Master. And make sure that the board is owned by the entire Scrum Team, and is just not for the Scrum Master;
- Not every problem is important. Use a Sprint Goal as a compass and guidance. As a Scrum Master you should especially act on impediments that hinder the Development 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. Quite often impediments will be related to product management and collaboration with stakeholders and suppliers. The Product Owner is a key player on this area. Therefore, ensure a solid relationship with the Product Owner.
- Focus on the real problem, not the first problem. Ask questions to understand the situation. Check if it’s really an impediment or a learning opportunity for the Development 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 problems that hinder the Development Team in achieving the Sprint Goal. Instead, the Scrum Master should help the Development Team to become increasingly capable of resolving similar problems on their own (self-organization). The Scrum Master does so by addressing those problems that ‘act as a parachute’ to the team slowing down overall progress, not just whatever pops up. In this post we offered a couple of concrete examples and clarified what kind of problems a Development 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?
Want to separate Scrum from the myths? Join our Professional Scrum Master orScrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses. Check out the previous episodes here (1, 2, 3, 4 , 5 and 6).
