Sometimes it’s thought that all problems that are hindering a Development Team in its work should be resolved by the Scrum master. This can vary from solving email problems to fixing a keyboard or laptop.
A lot of developers think all issues a development team runs into are ‘impediments’ and should be solved by the Scrum master. And, although the Scrum master indeed has a responsibility to solve real impediments, it for sure isn’t the responsibility of the Scrum master to resolve all problems that are hindering the Development Team. In most cases the Development team is more than capable to solve issues on its own. So what exactly is the difference between a regular issue and an impediment?
Issues are problems, open questions or conflicts which often appear out of nowhere and need to be solved, dealt with or clarified on short term. Issues can be dealt with by the development team itself.
Impediments are obstacles that hinder the Scrum team, especially the development team members, in the efficient execution of their work and in obtaining the sprint goal. They can be either technical or organizational in nature and can’t be resolved by the Development team on its own. In most cases, impediments are flagged during the Daily Scrum meeting or the Sprint retrospective.
Here are some examples:
• The test environment isn’t available.
• Not enough workspaces available.
• Specific knowledge and/or skills are missing in the team.
One of the many tasks of a Scrum Master is to support the development team by removing these impediments.
It’s however of the utmost importance that, while solving the impediment, a Scrum master should always keep in mind that his (or her) main goal is to support the Development team’s self-organizing abilities. This can only be done if the Scrum Master puts focus on finding a solution for the real impediment and not only for the symptomatic problem as raised during the Daily Scrum or Sprint retrospective.
Therefore the Scrum master should always look for the ‘real problem (or impediment) behind the problem’ and not just start solving all problems as they’re brought up by the Development team. This way, next time a similar impediment rears its ugly head, the Development team will be able to solve it on its own (transforming the impediment into an issue). This will strengthen the team’s ability to resolve problems on their own and will boost their self-organization. And that’s something all Scrum masters should strive for, isn’t it?
For a further deep-dive, I highly recommend this excellent post of Barry Overeem on Scrum.org, ‘The Scrum master as an Impediment Remover’.
What are your thoughts on the statement ‘A Scrum Master should reveal, and not resolve’? Please leave your comments below!