Why Scrum masters shouldn’t be the one solving all impediments

Impediments who solves themWho should be handling and solving impediments? Should it be the Scrum master? The team as a whole! Their agile coach?

I prefer that team members recognize and solve impediments themselves. For most of them they don’t need a Scrum master or coach. So if they see a problem, I expect team members to take action and solve it.

With the above (slightly provocative) question I started a discussion in the Scrum Master Community on Facebook. And boy, did it take off. Within minutes many people reacted and we had a great discussion! A big thanks to Alexey Krivitsky, Luis Gonçalves, Douwe Attema, Michael Leber, Gitte Klitgaard, Sjoperd de Vries, Angel Medinilla and many others who reacted. I’m impressed by the thoughts and insights that you shared.

Why the Scrum master shouldn’t be the one solving all impediments

Back to how I feel about Scrum masters solving impediments. Agile teams need to be able to handle impediments. I often see teams where the Scrum masters are overloaded with the many things that they have to do. Before they can solve an impediment another one pops up requesting their immediate attention.

At the same time I see too much apathy in teams. When the Scrum master is there, impediments are solved. They do stand ups and retrospectives where problems become clear, and then the Scrum master thinks of a solution and solves it.

But when the Scrum master is away, things stall. Teams skip rituals and don’t recognize or sometimes ignore problems and get stuck.

At one time I had a chat with an IT manager from a large company. He mentioned how proud he was about his Scrum masters. “Whenever there’s an impediment, they will pick it up and solve it relentlessly” he said. “They are always helping teams by solving problems and driving them forward.”

But he also mentioned that it surprised him that when the Scrum master was away for one or two days, teams didn’t do a daily stand-up. And when there was a problem, teams often got stuck.

I asked him if their might be a connection. If teams are so used to having a Scrum master which solves all of their problems, why should team members bother to learn ways to solve problems themselves?

This is where Agile coaching comes in. When I work with organizations I help teams and managers to see patterns of apathy, and help them to find ways to deal with them.

Leading the team and solving impediments is a full day job for their Scrum masters. Although they are good at it, it is driving them mad (I talked with several Scrum masters from that company who confirmed this to me). Switching between all the different things that are asking for attention doesn’t feel very effective. In fact, it’s hard for them to get anything done at all.

Have team members solving impediments

The Scrum guide suggests that “The Scrum Master serves the Development Team in several ways, including […] removing impediments to the Development Team’s progress”. Although the Scrum master can certainly play an role when it comes to dealing with impediments, my opinion is that handling problems is a responsibility for the whole team and not only for the Scrum master.

I like team members to be the ones who solve problems, in stead of having a Scrum master doing it. There’s value in the Scrum master helping the team to find ways, and be an example, but it should be about teaching people how to fish in stead of feeding them.

Some of the main reasons to involve team members when dealing with impediments are:

  • Team members other than the Scrum master might be better qualified to solve an impediment
  • Problems are often too complex to be solved by one person
  • Viewing an impediment from different angles helps to find effective solutions
  • Many problems have to do with the way how people work together, solving such a problem cannot be done by one person alone
  • You can expect from a professional that they are able to organize their work, which includes dealing with problems

So before setting out an expectation that the Scrum master should be the one who solves all impediments, think about the implications. You do not want the Scrum master to be a bottle neck for the team. Self organizing means that the team as a whole is capable to deal with impediments. Find a solution that helps them to proceed, and do what is needed to get the job done.

My advice: Prevent that the Scrum master becomes overloaded with solving impediments, by involving team members when looking for solutions. Scrum masters should coach teams in finding ways to work together, and using the individual strengths of the team members, also when solving impediments. In this way the team can really be effective and do magic.

In my opinion very mature team probably don’t need a Scrum master role anymore. This is also why I don’t believe in full time Scrum masters. We have to prevent Scrum masters from becoming overhead, keep the role valuable, up to the point that a team has developed enough capabilities to self organize.

Share this Experience
  • 34
    Shares

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 11 Comments

  1. Ben – I agree with most of this post. However you don’t make clear when a team won’t need a ScrumMaster anymore. If you said after 6 months, I would say very very unlikely. If you said after 2+ yrs, then I would say that’s possible.

    The better approach might be to state how a team would know whether or not it needs an SM anymore.

  2. Mark, I’m not saying anywhere in this post that teams don’t need a Scrum master. What I’m stating is that the Scrum should not be the one who solves all impediments. This is a team responsibility.

    The Scrum master role as described in the Scrum guide mentions useful activities, things where teams will benefit from. But for me it doesn’t have to be one dedicated person doing all these things, it can be done by any team member. Does that mean that there’s no Scrum master anymore? Or that every team member plays the Scrum master role occasionally. A matter of interpretation I guess.

  3. You say “Leading the team and solving impediments is a full day job for their Scrum masters”. Scrum masters shouldn’t lead the team.

    https://youtu.be/hG4LH6P8Syk

  4. Exactly Flavius, Scrum Masters shouldn’t lead, but that is what was happening at the company in the example above.

    That is why I propose to have part time Scrum masters who work with team members. They focus on collaboration, on coaching people to do their work and helping them to solve things that impede them.

    I think we are aligned on this?

  5. I can understand a team not needing a Scrum Master anymore, once it is established that the team is mature and can self – manage/organize itself. However, what happens when the dynamics of the team changes due to staff turnover?

    1. Good question Mary!

      Although we prefer to have stable teams, there will be situations when the team composition changes.

      If it’s a small change, say a new team member, one member leaving, or a replacement, then I expect the team to be capable to deal with this.

      If the impact is larger then basically the team has to go re-establish itself. This will need coaching. It could be that one or more of the team members have the capabilities to do this, then they can help the team to regroup and agree upon their values and practices. Otherwise external coaching can be applied, which can e an agile coach, or a Scrum master. Or maybe a senior member from another team.

      Your thoughts on this?

  6. Good post Ben.
    Agree with you in almost all the cases.

    I think a part time scrum master role is worth, even when the team becomes stable, which could be a hat a team member wears. Since even the stable team at times cannot hold strong for the scrum/agile processes against the business need of organization. At that time if there is someone assigned the role of scrum master the chances are more that she can take the stand due assigned role.

  7. Thanks Bhanu, happy to read that you like my suggestions.

    I’m not sure if I understand you correctly. You mentioned to “hold strong for the scrum/agile processes against the business need of organization”. I would expect that these two should be in balance, a good agile process should be an enabler to serve the business. So normally there shouldn’t be any conflicts between working agile and delivering business results.

    Maybe I’m getting you wrong, so please let me know what you are meaning to say.

  8. Just another case of the “Not-my-Job” syndrome I see in so many Scrum Masters nowadays and that strengthens the view of so many people that Scrum Masters are unproductive, because impediment removal is one key issue that makes Scrum Masters visible to the “outside world”.

    There is a major fallacy in this article: The idea that if the Scrum Master is an impediment remover, the team automatically becomes fully dependent on the Scrum Master. I have never experienced that. I teach my teams to be self-organizing so that if one part of the team is missing, other parts of the team will take over the responsibilities. So if I (as Scrum Master) am missing, the team handles that role, including impediment removal.

    My job as Scrum Master is to make sure that the team can be productive. I have to make sure that they can concentrate on what they are best at: Developing great software. If I see someone from my team stand in line to order office supplies, then I will tell them to get back to their PC, and I will take their place in line. That’s not a case of helper syndrome – it’s simply recognizing that the developer is providing more value to the team when developing software than when standing in line somewhere. That doesn’t imply that nobody will be able to get office supplies when I am on vacation. That’s a completely bizarre thing to assume.

  9. Just another case of „Not my job“ syndrome that I see more and more frequently in Scrum Masters. One more reason why so many people keep seeing Scrum Masters as non-productive. There is the weird fallacy in this article to assume that teams become completely dependent on the Scrum Master if the Scrum Master handles impediment removal, when in fact, a strong dependence on the Scrum Master indicates dysfunctions in the team which are not fixed by taking the impediment removal away from the Scrum Master role.

    As Scrum Master, my job is to make sure that the team can be productive. What the development team does best is: creating great software. So I ensure they can concentrate on that. If I see someone stand in line somewhere to order office supplies, then I will tell them to get back to their PC to do what they are best at, while I take their place in line. That is not helper syndrome. That is a simple case of allowing the team to be as productive as possible and to keep frustrating menial tasks away from them. This does not imply that nobody is capable of ordering office supplies when I am on vacation. That is a completely bizarre assumption. And it is even more bizarre to assume that the team will not do daily stand ups when I am not there just because I handle their impediments. Like I said, that is a completely unrelated dysfunction.

    I teach my teams to be self-organizing. I teach them to take responsibility. I teach them to swarm on tasks. If someone from the team is missing, then other parts of the team take over that particular role. The same is true for the Scrum Master and for the task of impediment removal. But while the Scrum Master is there, I see no reason why the team should act like he/she isn’t. And yes, I see it as my main goal to make myself completely obsolete to the extent that my team doesn’t need me anymore. But I don’t do that by pulling myself out of tasks but by teaching the team how to handle these tasks if I am not there.

    I’d also think that it’s quite obvious that the Scrum Master does not remove all impediments alone. When I order office supplies for my team (doesn’t happen often, just following that example further), I don’t go to the forest to chop trees to turn them into paper. There are always other people involved. Sometimes people from my team. But not if it can be meaningfully avoided.

    I wonder which other Scrum roles you would like to redefine and if there is a Ben Linders version of the Scrum Guide as PDF somewhere? Don’t get me wrong, I am not one of those who see the Scrum Guide as holy scripture, but it seems weird to me to remove a major part of a Scrum role simply based on what I perceive as paranoia. „If the Scrum Master handles all impediments, there will be apathy in the teams and they will not do stand ups when the Scrum Master is not there.“ Yes, that is actually the gist of your article. I can just as well claim that facilitating retrospectives for the team makes them incapable of discovering their improvement areas themselves, so let’s stop doing that. Coaching the Product Owner in how to effectively manage the Product Backlog keeps the Product Owner from interacting with the team and the stakeholders to discover ways to handle the Product Backlog better, so let’s stop doing that. Coaching the organization in agile values keeps it from discovering its own way towards Agile. So let’s stop doing that. Bunch of nonsensical „From A follows B, so don’t do A“ statements, right? I am all for tailoring Scrum to match reality, but I am against tailoring Scrum based on an illogical „From A follows B“ statement like the one you have given.

    And just as a sidenote: Impediment removal is driving Scrum Masters mad? Really? Oh boohoooo. Cry me a river. When they signed up for the role, impediment removal was listed as a key task for the Scrum Master role in the Scrum Guide. Oh wait, it still is! Perhaps that’s one of those times where people realize that not every John or Jane is a good match for the Scrum Master role. Being a Scrum Master can be tough. Trying to solve that by giving in to the „Not my job“ syndrome is not going to solve that. It just pushes the difficulties onto other people.

  10. Thanks for your extensive response Frank!

    The behavior that I describe in this post is what I have witnessed working with some teams. They struggle to get problems solved, based on the classical mindset that “it’s the managers job to solve problems in the organization”. They see their Scrum master as a manager, their boss, which is the deeper cause why they are not benefiting from agile.

    I’ve also seen other problems when it comes to the way that impediments are handled in teams. When I was giving an in-house workshop, a manager came to me. He told me how proud he is about his Scrum masters. “They solve everything quickly” is what he said. But when the Scrum master was away, things tended to stall, as team members never got a chance to solve problems. We discussed this, and concluded that their Scrum masters could try out a different approach; more coaching in stead of doing every thing themselves.

    I also see teams with a good healthy working relationship between the Scrum master and other team members, where it works like you describe. And I see teams where the Scrum master role is distributed over the team, where team members pick up tasks and everyone is capable to solve impediments.

    If you browse through my blog posts then you will see that I’m not a “this is the only way” or “one best way” guy. No, there is “Ben Linders version of the Scrum Guide as PDF” and there never will be. I provide solutions how things can be done, usually more than one, and give people room to think for themselves and decide how they want to do it. I share my experience, things that I have seen going wrong and things going right. I don’t tell people how to do stuff, but I’m hoping that the things that I write will inspire them, make them think, and come up with whatever works for them. And make the world a little bit better.

    When it comes to retrospectives there too I suggest to rotate the task of facilitation. I’ve seen many teams who occasionally had an outside facilitator for their retrospective, someone who was really independent from the team, to help them explore a problem that they were struggling with and find a solutions. I’ve coached teams where different team members facilitated the retrospective, and occasionally I facilitated one. I have worked with very mature teams where facilitation was fully ingrained, teams who did retrospectives on the spot. It depends on the team on what they are capable of, what works for them, what works now.

    Finally, I dare to challenge the status quo, the guides, the “this is the way that it should be done”. That is actually the gist of this post. When the majority expects that their Scrum master is there to solve all problems, I give a different view on the topic. Not to tell people that they are doing it wrong, if this works for them, who am I to tell them to change (changing people doesn’t work anyway). But when it doesn’t work, then my post might inspire them to look for different ways.

    Again thanks for your comment Frank! It helped me to add some more context to the ideas laid down in this post, and think about why the heck that I’m blogging in the first place.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

×
×

Cart