Wading Into Deep Waters – Can a Scrum Master Remove a Team Member?

A recent post on both LinkedIn and Medium by “Scrum Mythbusters” Christiaan Verwijs and Barry Overeem has been causing a big debate in agile circles: can a Scrum Master remove a team member who’s become an “impediment”? Our previous Agile Evangelist Bob Galen has also chimed in on the topic, but I thought it would be worthwhile to chip in my two cents as well given that I’ve been involved in those decisions in the past.

Can A Scrum Master Remove a Team Member?

Scrum Master
Scrum Master

The original post was made in April and quickly made some people sit up and take notice. It laid out a scenario where a team member was causing issues. He wouldn’t show up for meetings, he checked in code all at once and all at the end of the sprint, etc. In general, this employee – Tim – was damaging the team and had become an impediment. So, the Scrum Master, Tess, took action.

Having tried many different things to successfully resolve the situation, Tess decides to remove Tim from the Scrum team.

Christiaan and Barry take the point of view that sometimes a team member can be an impediment to the team’s performance. Rather than something technical (like a malfunctioning computer or issue with networking) or organizational (like SLAs or other policies that delay a team), they argue that a team member who works against the team’s goals can be an impediment, especially where there is a prolonged, unresolved conflict with that team member.

The examples that they use are familiar:

  • A senior person who uses their authority to bully others into doing it their way,
  • Someone who makes changes and decisions unilaterally, and
  • Someone who uses meetings and ceremonies as an opportunity to vent their frustrations

We’ve all had these people on our teams and in our organizations. But are they impediments?

What’s the Problem?

The problem, as Bob pointed out in his rebuttal, is that this places the Scrum Master in a managerial position on the team. Rather than being a servant leader, the Scrum Master is acting as a manager. And let’s assume that the Scrum Master decided to leave it up to the team to decide who’s “voted off the island”. That’s not a better situation because of the challenges with team dynamics, “mob rule”, etc. We want our teams to be self-organized, but that doesn’t mean that they should determine their own membership. I have argued for that in the past but, in general, teams are assembled because they have the right set of cross-functional skills and knowledge to deliver vertical slices of product.


Five Dysfunctions of a Team (Patrick Lencioni)
Five Dysfunctions of a Team (Patrick Lencioni)

The other issue I see is that what we’re really witnessing is the Five Dysfunctions of a Team in action. Patrick Lencioni describes five different layers, laid out as a pyramid (shown left; similar to Maslow’s Hierarchy of Needs). The levels are built one upon the other, so if our team lacks trust then other dysfunctions are bound to be present in some form. In the example provided in the original articles, the challenges span the pyramid. There is definitely Inattention to Results, Lack of Commitment, Fear of Conflict, and, at the core, an Absence of Trust. As a result, the team is not working.

Using this understanding, the Scrum Master should be finding ways to resolve the dysfunctions. And while I think that Christiaan and Barry are glossing over that, I think the expectation is that Tess, the Scrum Master, did try to resolve the dysfunctions. But is removing someone the right move?

A Fishy Agile Metaphor

Koi Fish, or an Agile Team
Koi Fish, or an Agile Team

When I teach classes about adopting agile, I use a metaphor to describe teams that are being exposed to it for the first time. I tell the class to envision a nice freshwater pond with a bunch of fish swimming around. All the fish are happy and doing awesome fishy things. And then some salt water begins to enter the pond. Some of the fish in the pond love the new salt water. But other fish hate the salt water. As more and more salt water enters, the fish that love it begin to do different fishy things and flourish with the new water. But the ones who hate the salt water start to react very negatively. And some of them begin to expel toxins and poison the water. There’s nothing wrong with these fish. They’re just fish. But sometimes as an environment changes, some fish are going to thrive and others will be unable to adapt. But they aren’t bad fish – they just can’t handle the new environment.

Sometimes, our employees are like those fish. Some thrive in the agile environment. It resonates with them – as it did with me when I was a developer. And for some, it’s something that must be killed, destroyed, burned, and then burned again. But we have to remember that there’s nothing wrong with these people. They aren’t bad people – or bad employees. They’re just not going to work out in that environment. And that’s okay. We just need to encourage them to find an environment that’s going to let them do things the old way. They just need to find a new freshwater pond.

What Do I Think?

So, can a Scrum Master remove a team member? I say no. Not in isolation. And here’s why: the Scrum Master is not necessarily responsible for removing impediments. If you were to put the Scrum Master’s responsibilities on a RACI (or RASCI) chart, you’d see they’re “responsible” for making sure they’re removed, but not necessarily for removing them. What do I mean by that? If there’s a problem with networking or a server, the Scrum Master is not going to fix that problem themselves. They’re going to enlist help. And in this case, they’re going to enlist – and escalate – for help. This is a management decision. It’s an HR decision. The team and the Scrum Master have input, but they don’t have the final say. And I’d push the Scrum Master to find a way to work through the team dysfunctions first before making this kind of serious and potentially damaging action.

Closing Thoughts

Being a Scrum Master is a hard job. I’ve written previously about the challenges, especially how we under-prepare people to be Scrum Masters. But when we ask “can a Scrum Master remove a team member?”, I have to come down on the “no, they can’t” side. While I think – in essence – Christiaan and Barry aren’t wrong about it, I think how they’ve presented it is. Be cautious with your people and treat them like people, not things – or fish.

Feliz entranamiento, mis amigos! (Happy coaching, my friends!)

Bill DeVoe