Impediments are problems that hinder a team’s progress toward the Product and Sprint Goals and are outside their capability to resolve independently.
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.
Examples of such unexpected problems are:
❌ Team members becoming sick
❌ A broken laptop
❌ Unavailability of the Product Owner
❌ Conflict between team members
❌ Bugs in the production environment
Teams should use their professional expertise, creativity, and collective intelligence to solve problems as they emerge. Within Scrum, a team's self-organizing nature can be understood by its ability to solve problems without delegating ownership 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.
Does this mean that a Scrum Master never resolves problems? Of course not.
Scrum Masters are still part of the 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 complete the task 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.
Good guidelines to remember are:
✅ A Scrum Master should reveal, not resolve.
✅ Focus on the real problem, not the first problem.
✅ Not every impediment is important. Use a shared goal as a compass and guidance.
What's your take on this?
PS: this topic is part of the Scrum.org PSM II (advanced) class. If you want to run this class in your organization, message me to discuss the possibilities.