Myth: The Scrum Master can’t remove people from the team

In this series of posts, we—your Mythbusters Christiaan Verwijs and Barry Overeem—address common myths and misunderstandings. Thea Schukken created the great visuals.

If you prefer, you can also listen to us reading this post.

Let's start with a case …

“So Tim decided not to join again?” asks a visibly frustrated developer attending the Daily Scrum. Those present let out a defeated sigh and drop their shoulders. “Even after the talk we had about needing to share our progress openly?” adds another developer.

The tension is palpable. Tim hasn’t joined the Daily Scrum for almost two months now. Tim spends his time on “very important things” and prefers to spend the Daily Scrum writing code. But except for the huge commits he makes at the end of the Sprint—that often undo work by others—no one knows what he is working on.

The team has raised the issue several times during the Sprint Retrospectives, and it has yet to be resolved. The team's Scrum Master, Tess, has spoken about it with Tim multiple times, trying to figure out what drives Tim to play his cards so close to his chest. But despite good talks, nothing has changed since. The team has grown tired of the fight, and morale has slumped.

Due to the unpredictability of what Tim is working on and how it will impact Sprint, the team is increasingly hesitant to commit to the Sprint Goal. Having tried many different things to resolve the situation successfully, Tess decides to remove Tim from the team.

This case illustrates the balancing act between a Scrum team's self-organizing nature and making Scrum work for both the team and the broader organization. It represents one of the difficult decisions that Scrum Masters sometimes face.

When asked if Scrum Masters can remove someone from the team, most people respond out of principle with a resounding ‘No!’. It can create hierarchy in the team, harm the trusting environment, and go against the team's self-organizing nature. It should be delegated to HR/management instead.

Yet in this post, we are going to make the case that this actually a myth, based in part on an incomplete understanding of what it means for the Scrum Master to be a ‘Servant-Leader’. However rare, there are situations where the Scrum Master has the responsibility and authority to remove someone from the team.

What does the Scrum Guide say?

The Scrum Guide does not explicitly state that the Scrum Master can remove someone from the team. But the Scrum Guide does emphasize several relevant responsibilities:

• The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide within the team and the broader organization;
• Acting as a Servant-Leader, the Scrum Master helps to create an environment where the team can work effectively with Scrum;
• The Scrum Master is responsible for removing impediments that hinder the team's progress. Many things can become impediments, from broken laptops to team conflicts and disruptions to missing skills. However, a Scrum Master should concern himself or herself primarily with those impediments that endanger the Sprint Goal and transcend the team's ability to solve problems independently. More broadly speaking, the Scrum Master tries to remove or resolve things that hinder the team’s ability to work effectively with Scrum (and, by extension, the entire organization).

Another way to look at this is that the Scrum Master is a Servant Leader who sets and maintains the game's rules while providing the players the freedom and support to play the game as effectively as possible. Although the Scrum Master does everything to help people play the game to the best of their ability, his or her primary responsibility is to ensure the game is right. Translated to Product Development, it is about delivering a valuable product in incremental steps to learn on the go and allow better insights to emerge.

Removing impediments — things that obstruct the game from being played well — is one of the responsibilities of Scrum Masters. So, can team members become ‘impediments’ to the game?

“Can members of the Scrum team become impediments?”

Can people be impediments?

Let’s make this as simple as possible: people should never be called ‘impediments.’ Instead, the dynamic between individuals can get in the way of working with Scrum. Not the person, but this dynamic is the impediment. Take the following examples:

• A developer who plays everything close to the chest, not revealing what he is working on, how things are going, or how other people can help. Whatever this developer is working on, no one knows. For obvious reasons, this developer does not see the value in Daily Scrums and never attends;
• A developer who frequently spends her evenings unilaterally throwing away entire chunks of code written by the team, replacing it with code that she feels is superior to what the team has produced — despite increasing frustration in the team;
• A developer who uses every opportunity he has to air his grievances with Scrum, starting heated debates during the various Scrum events and distracting people from the matters at hand against their will (‘here we go again….’);
• A developer who uses her seniority to aggressively criticize the work of others on an ongoing basis, making people generally feel unsafe and insecure when she is in the room;

However annoying these situations may be, they do not make for a sufficient reason to remove someone from the team. But what if the following conditions are true as well?:

• The situation has been going on for a while without the prospect of improvement;
• The atmosphere in the team is increasingly tense. People are stressed and increasingly hostile. Some may even be reporting in sick, unwilling to endure the stressful work environment;
• The team is aware of the situation and doesn’t like it. There have been many conversations about the situation during Sprint Retrospectives. But the will to take action fails to materialize. The team is afraid to act, feels that it isn’t their responsibility, or doesn’t dare to take a dramatic decision such as removing someone from the team;
• The Scrum Master has had several conversations with the member in question to help them become aware of the effect they’re having on the team;

In other words, a prolonged unresolved conflict harms the team's functioning. As a result, you may start seeing people skipping Scrum events, helpful discussions may be cut short (or avoided altogether), and people will be less willing to be open and transparent about their work. The foundations of Scrum—transparency, inspection, and adaptation—are crumbling.

Considering such a conflict, is it ethical for a Scrum Master to do nothing and wait for the team to decide themselves? Suppose it is obvious to everyone that the team is suffering, affecting its operation. In that case, the Scrum Master is precisely the right person to step in and—acting as a Servant-Leader—do what needs to be done—no matter how difficult.

“Is it ethical for a Scrum Master to do nothing and wait for the team to make the decision themselves?”

An impact on trust?

A common objection is that removing people from the team can damage trust. How will people feel safe again knowing that a Scrum Master can act like this?

This argument assumes that there is a ‘trusting environment.’ However, many things already harm trust if a team deals with an unresolved conflict, as in the examples above. It is more likely that the team is surviving in a state of artificial harmony — a status quo that isn’t very healthy. Take the following behaviors that exemplify a trusting environment; would they occur in teams with the conflicts mentioned earlier?:

• Having difficult conversations without fear of retaliation;
• Being critical or skeptical of something without fear of reprisals or being made fun of;
• Making mistakes without getting blamed or punished;
• Relying on others in the team to help you when you get stuck;
• Being able to ‘lovingly fight’ (have a heated debate without repercussions on the relationships between the people involved);
• Admitting that you don’t know something or are afraid of it without having to worry about implications;
• Relying on that what people say is what they think (e.g., no facades);

If you read between the lines, it takes little effort to relate the lack of these behaviors to a lack of transparency, inspection, and adaptation — the core principles of the empirical process that Scrum is all about and the core of what the Scrum Master is there to protect.

Isn’t the reverse more likely to be true? Rather than decreasing trust, taking action will help restore trust. Group dynamics create space for the team to find a more productive collaboration. The Scrum Master has also demonstrated that he or she is willing to make a difficult decision, such as removing someone for the good of the team. Rather than decreasing trust, removal can be a powerful signal to help restore trust.

“Rather than decreasing trust, removal can be a powerful signal to help restore trust.”

Why not delegate the decision to HR or management?

A common response to this article's challenge is to delegate the decision to someone outside the team, like Human Resources or management. Let them make the decision based on the evidence presented. Yet, this approach reveals the continued existence of traditional beliefs about the role of management in Scrum.

To work effectively with Scrum, the Scrum Guide stipulates only three roles: a Product Owner, a Scrum Master, and the Developers. Together, the three roles have full authority to make decisions about product development and their internal process as a team. Although management can still be involved, they are not making the decisions. If they would, it would undermine the self-organizing nature of the team and signal that the power to make decisions about development and their internal process does not truly lie with the team after all. Having or wanting to delegate these decisions signals that the team needs to be truly self-organizing. It helps to remember that the decision to remove someone from the team does not mean that this person is being fired. They can very well be of great value in another team or another position in the company — just not in this team.

“It’s also good to keep in mind that a person is not being fired from the company, but removed from a team.”

So, how do you remove someone from the team?

Removing someone from a team is a tough decision and should be the last resort. The Scrum Master should do whatever is possible to help the team resolve the conflict independently. But if all else fails, removal is a viable option. Although there is certainly no “best way” to remove someone from a team, here are some things to consider:

• Make very sure that there have been plenty of opportunities for the team and the individual to improve the dynamics, but without results;
• Be honest about the reasons for removing someone from the team;
• Don’t remove people from the team with everyone present. Take the person in question aside and announce the decision. Be friendly and empathic but firm and resolute. Take sufficient time to give the person the opportunity to respond and ask whatever is on their mind;
• Make sure that you involve the necessary people and departments in the decision (like HR and management) while staying in control of the decision that you are making as a Scrum Master;
• Don’t make it personal or use personal reasons to make the case. Stick to what is observably true or (at least) shared by the majority of the team;
• Decide together how to proceed from here. Depending on the situation, a member may wish to leave right away. But they may also prefer to finish the current Sprint. In any case, make sure to follow up with the person a couple of days after the decision;
• When the decision has been made, please share it with the Development Team. Allow them to respond and reflect on what happened. This may be a moment for relief but also for a difficult conversation about how this can be prevented in the future;
• Removing someone from a team is difficult — especially for the person being removed. Be exceptionally respectful and empathic;
• Don’t brag to others about how you removed someone from the team or how you stepped up and did something difficult. Treat the person you removed and the situation in which this was needed with the utmost respect. Removing someone from a team is not something to be proud of.

What about the Product Owner?

The same reasoning outlined in this post also applies to the Product Owner. There are many ways in which Product Owners can get in the way of the game:

• The Product Owner is unwilling or unable to be sufficiently available for the Development Team to clarify requirements and determine what needs to be built;
• The Product Owner has no mandate or entirely lacks product vision to make any decision about the product, making it very difficult to inspect and adapt rapidly;
• The Product Owner is creating an atmosphere unconducive to Scrum, e.g., with a strong focus on commitments and control.

If all other solutions have failed, the last resort of a Scrum Master is to replace the Product Owner with someone from inside or outside the organization who is better suited for the role. If that person can’t be found, Scrum's value lowers to the point where one can wonder if continuing is useful. Again, this underscores how the Scrum Master needs a mandate from management.

Some other thoughts

• Besides removing an individual from the team, a Scrum Master can also decide to disband the entire team and start over. This can be helpful when there is a persistent and unhealthy dynamic between a group of people — a reality that sometimes happens;
• When starting a new team, you can make specific work agreements about dealing with such scenarios. What happens when an unhealthy dynamic threatens a team?
• There is great value in building skills to prevent conflicts from escalating to the point where a Scrum Master has to step in;

Closing

The Scrum Master is primarily responsible for the Scrum framework and the empirical process underlying it. Sometimes, this may require that the Scrum Master remove people from the team. Prolonged conflicts in teams between individuals can dissolve the trusting environment that is needed for the empirical process to work (see the examples in the post). Because of its self-organizing nature, the team should be supported in whatever way possible to resolve these conflicts independently.

However, suppose the team cannot resolve the conflict after repeated attempts. In that case, the Scrum Master—a servant leader—has the responsibility and authority to act for the good of the team and the empirical process of Scrum. This is a last resort and something to avoid.

So, what do you think about this post? Have you ever been in a situation where the Scrum Master removed a member from the team? What happened next?

Find out more on patreon.com/liberators