Remove "Remove Impediments" as a responsibility of the Scrum Master
The "Remove Impediments" responsibility of the Scrum Master is much too generic. It is easy to formulate everything as an impediment. It also leads to the Development Team not taking responsibility for solving their own problems but instead assign it to the Scrum Master because his role is to remove impediments.
- Remove "remove impediments" completely, or
- Add "remove impediments" also to the PO and Dev Team responsibility, or
- Clarify the kinds of impediments are suggested, perhaps by adding an additional clarification such as "impediments that the team cannot yet resolve themselves or that do not directly relate to the Sprint Goal"
28 commentsComments are closed
Raju Joshi commented
I think SM can help to team to solve the issues which need lot of coordination, Inter-dependencies talking,followup with external stakeholder,teams etc and those should be categorizes as Impediments for the SM, Rest all technical glitches etc should be handle by the team.
Charles Bradley commented
In principle I'm in favor. I don't like the specific suggestions here. My specific suggestion would be to simply add directly under the existing SG language "Removing impediments to the Development Team’s progress"
Add this bullet point directly below the above quote:
"Over time, encouraging and teaching the Development Team to self organize to remove as many of their own impediments as possible"
Anbu Joseph C commented
Initially Helps, then faciliates and then coaches the team to remove impediments and then works with the organisation to remove any organisation impediments for the team. Need to set the correct expecation for all the stakeholders for them to self-organise and self-manage.
Brian Clink commented
Yes, facilitate. And the scrum master can coach the dev team on how to be resourceful and the dev team can challenge each other during the daily scrum to self-solve problems or solve together. Look at impediments as a good thing, and a learning opportunity.
Alasdair Macleod commented
Why not become better at representing the role of SM as a coach facilitator not a team manager impediment remover. Of all the comments adding that they facilitate the DT learning how to remove impediments for themselves would be the best direction of travel however I think this is really just based on vested interests of trying to make Scrum look like it favours one group of peoples scaling product for sale.
Pierluigi Pugliese commented
While I’m assuming it is not the intent of the Scrum Guide, I’ve seen way too many situations in companies where the Scrum Master becomes the “cleaning crew” for the team, where every silly “problem” or perceived that is considered an impediment:
- Replacing the toner inthe printer
- Updating the progress indicators
- Talking to the Product Owner (auch!)
So IMO this part of the Guide would definitely benefit for a clarification.
MIke Dwyer commented
While I can appreciate your posit, I can't go along with the action. The ScrumGuide is just that a guide to act and grow. It is not prescriptive, follow the rules model. Yes, the ScrumMaster owns leading impediment resolution. No, the CSM is not there to carry the burden on their own. That type of thinking has the fetid odor of a RACI about it and should be expunged.
If anything, the the ScrumMaster relationship to impediments is to coach, train, and assist the team and the organization in recognizing impediments and addressing them. Those impediments that are unable to be addressed should fall into a known constraint that is acceptable by the organization. All said and done, The CSM leads this. Best Regards Mike D.
Wim Heemskerk commented
Please don't let the Scrum Master of the hook; this is just too core to his role. True that he can't do it by himself generally, but let's not water it down too much because of that. How about "get impediments removed"?
Indeed it could use clarification. I like this definition: Impediment: a problem that goes beyond the self-organizing capability of the Development Team.
(I associate this definition with Gunther Verheyen but don't know if he's the original source, nor am I quoting literally.)
Wolfgang Richter commented
Agree with "facilitation", "helping". Some impediments may also be removed by the SM him/herself. Like Petri's and Bas' ideas. Do not like the word "relentless".
My preference would actually be to define impediment for concretely. I always phrase it that impediments aren't obstacles for delivery of the Sprint Goal, but impediments are obstacles for better Scrum in the organisation.
Brett Maytom commented
The Scrum Master should reveal and then facilitate removal. The Scrum Master should take responsibility to ensure the impediment is removed but does not remove it him/herself. The SM should own, be responsible and accountable to ensure that the impediment is addressed and not forgotten.
Rowan Bunning commented
I'd like to suggest that in conjunction with bringing the case of resolving impediments to those with the ability to resolve them, a Scrum Master "provides problem solving services to assist those taking responsiblity for resolving the impediment with ways to resolve it. It may not be necessary to mention in The Scrum Guide but this could be in the form of experiments to probe constraints and evaluate which options is most effective and still feasible given current constraints. In this way the Scrum Master avoid simply throwing the Impediment monkey onto someone else's shoulders.
I suggest extending the above suggestion (and the below comments) with a few classic anti-patterns that are frequently seen around the role of Scrum Master. I agree that "Remove Impediments" is too generic and may lead to perceiving Scrum Master as a "jack of all trades". But also see this as a deeper problem that could be exposed in the Scrum Guide with a very short list of 'do not' examples.
Bas Vodde commented
Most suggested added to the comments would also work. E.g.
- "Facilitate the removal of impediments by those responsible for resolving them"
- "Create awareness and understanding of impediments with the people who have the means to resolve them"
- "Facilitate relentless transparency on impediments and who owns these impediments outside the whole Scrum Team"
- "Help facilitate removing impediments"
Though some of these seem to suggest that the SM doesn't remove any impediments, which wouldn't be true either. The Scrum Guide ought to have an appropriate balance.
Michael Küsters commented
Petri's suggestion is great.
Here's my suggestion:
- Create awareness and understanding of impediments with the people who have the means to resolve them.
Anton Skornyakov commented
Agree that a change is needed. Like Petri's proposal very much.
Jerry Lopez commented
Shifting responsibility to the agile product delivery team requires that a SM role is not depended upon to remove impediments. A product focused team means the product owner also owns this along with the team. When I see a mature team they don't even need a SM to facilitate the process. Yes, when the impediment is outside the control the of the Dev team, then the SM and sometimes the PO, can take it on. If for some reason scrum does not want to explicitly imply it's product focused, then it would still be appropriate on the bases that matures teams are able to take this on and mature POs are in there, right with the team making things happen. A revision to the language seems appropriate to reflect the maturity scum has experienced over the years.
How about the SM ensures impediments are addressed and removed (by the Development Team or by Management) as appropriate?
Tim Born commented
A Scrum Master teaches the team to be self-sufficient. Early on they may need more direct help removing impediments, but an SM doing their job uses these as learning opportunities for the team to learn to help themselves.
Yes, the phrasing in the scrum guide is often misunderstood as written. Perhaps it can be rephrased to capture the deeper intent?
Jacek Bochenek commented
I fell into the trap of misinterpreting that one for quite a while, letting go of that mentality helped the team grow very quickly.
Both the first and third suggestions look good to me, I'm afraid the second one would be either confusing or very complex. I think Petri's suggestion works as well.