Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here.
Lets 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. Spending his time on “very important things”, Tim prefers to spend the Daily Scrum writing code. But except the huge commits he does at the end of the Sprint — that often undo work by others — no-one really knows what he is actually working on. The issue has been raised by the Development Team on several occasions during the Sprint Retrospectives, without resolution. The Scrum Master of the team — Tess — has spoken about it with Tim on multiple occasions, 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. Morale has slumped. And due to the unpredictability of what Tim is working on, and how it will impact the Sprint, the team is increasingly hesitant to commit to the Sprint Goal. Having tried many different things to successfully resolve the situation, Tess decides to remove Tim from the Scrum Team.
This case illustrates the balancing act between the self-organizing nature of a Scrum Team and making Scrum work for both the team and the broader organization. The case we just described represents one of the difficult decisions that Scrum Masters are sometimes faced with.
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, it can harm the trusting environment, it should be delegated to HR/management instead and it goes against the self-organizing nature of the Development Team.
Yet in this post we are going to make the case that this principle is a actually myth, based in part on an incomplete understanding of what it means for the Scrum Master to be a ‘Servant-Leader’. 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 Scrum 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 the organization;
- Acting as a Servant-Leader, the Scrum Master helps to create an environment where the Scrum Team can work effectively with Scrum;
- The Scrum Master is responsible for the removal of impediments that hinder the progress of a Development Team. Many things can become impediments, from broken laptops to team conflicts and from disruptions to missing skills. But a Scrum Master should concern him- or herself primarily with those impediments that endanger the Sprint Goal and transcend the ability of the Development Team to solve on their own. More broadly speaking, the Scrum Master tries to remove or resolve things that get in the way of the team’s ability to work effectively with Scrum (and by extension, the entire organisation).
Another way to look at this is that the Scrum Master is a Servant-Leader by setting and maintaining the rules of the game while providing the players with 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 top of their ability, his or her primary responsibility is to make sure that the game is played right. Translated to Product Development this means that it is about delivering a valuable product in incremental steps to learn on-the-go and allow better insights to emerge.
The removal of impediments — things that obstruct the game from being played well — is one of the responsibilities of Scrum Masters. So the question now becomes; can members of the team become ‘impediments’ to the game?
“Can members of the Scrum Team become impediments?”
People as impediments?
Although we don’t feel comfortable labeling people as ‘impediments’, the reality is that people can get in the way of working with Scrum effectively. These are some examples:
- Like the case; a developer that plays everything close 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 really knows. For obvious reasons, this developer does not see the value in Daily Scrums, and never attends;
- A developer that 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 Development Team;
- A developer that 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 that 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;
These examples 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;
- The Development Team is well-aware of the situation and doesn’t like it one bit. 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 have the courage to take a dramatic decision such as removing someone from the team;
- The Scrum Master has had a number of conversations with the member in question to help them become aware of the effect they’re having on the team;
In other words, there is an prolonged unresolved conflict that is harming the functioning of the Scrum Team. As a result, you may start seeing things as people skipping Scrum Events to avoid conflicts, useful discussions may be cut short (or avoided altogether) and people will be generally less willing to be open and transparent about their work. Considering such a conflict, is it really ethical for a Scrum Master to do nothing and wait for the team to make the decision themselves? If it is obvious to everyone that this isn’t working, and that it’s affecting how well the team operates, the Scrum Master is exactly the right person to — acting as a Servant-Leader — step in and 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 when they know that a Scrum Master can take actions like this?
This argument assumes that there is a ‘trusting environment’ that can be damaged to begin with. But if a team is dealing with an unresolved conflict — like the aforementioned examples — there are already a lot of things going on that are actively harming trust. 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 retaliation 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 repercussions;
- Relying on that what people say is what they really 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, the removal of a member from the team will help restore trust. In terms of group dynamics, it creates space for the team to find a more productive way of collaboration. And the Scrum Master has also demonstrated that he or she is willing to make such a difficult decision 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 the conundrum in this article is to delegate the decision to some party 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.
In order to work effectively with Scrum, the Scrum Guide stipulates only three roles: a Product Owner, a Scrum Master, and a Development Team. Together, the three roles have full authority to make decisions about product development and their internal process as a team. Although management can certainly still be involved, they are not the ones making the decisions. If they would, it would undermine the self-organizing nature of the Scrum Team and signal that the power to make decisions about development and their internal process does not truly lie with the Scrum Team after all. Having, or wanting to, delegate these kinds of decisions signals that the team is not truly self-organizing. It helps to keep in mind 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 no 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 incredibly difficult decision, and should indeed be the very last resort. The Scrum Master should do whatever is possible to help the Development Team resolve the conflict on their own. 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 sure that the person in question has already had sufficient opportunities to improve. As such, the decision should not come as a total surprise;
- 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, 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, management), while staying in control of the decision that you are making as a Scrum Master;
- Don’t make it personal and don’t use personal reasons to make the case. Stick to what is observably true or (at least) shared by the majority in 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, share it with the Development Team. Give them the opportunity 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?
We feel that the same reasoning as outlined in this post applies to the Product Owner as well. 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 kind of decision about the product, making it very difficult to rapidly inspect and adapt;
- The Product Owner is creating an atmosphere that unconducive of 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 that is better suited for the role. If that person can’t be found, the value of Scrum lowers to the point where one can wonder if it is even useful to continue. This — again — underscores how the Scrum Master needs a mandate from management.
Closing
The Scrum Master is primarily responsible for the Scrum Framework and for the empirical process that underlies it. Sometimes, this may require that the Scrum Master removes 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 Development Team should be supported in whatever way possible to resolve these conflict on their own. But if the conflict cannot be resolved by the Development Team even after repeated attempts, it becomes an impediment for the Scrum Master to resolve. In that case, the Scrum Master — being a Servant-Leader — has the responsibility and the authority to act; for the good of the team and the empirical process of Scrum. Obviously, 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 a member was removed from the Scrum Team by the Scrum Master? What happened next?
May 8, 2018: In light of the excellent discussions that this post triggered, we made three changes to article to clarify some aspects. We rewrote the conclusion to give a more complete overview of the nuanced position of the post itself. Its a bit lengthier, but we noticed that many people only read the conclusion (and responded to that). We also removed two paragraphs about mental health and cultural differences to reduce the length a bit. Finally, we further emphasized the self-organizing nature of the Development Team to remove any excuse for people to read this post as “the Scrum Master can fire all the people!”
Want to separate Scrum from the myths? Join our Professional Scrum Master orScrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses or contact us for in-house courses. Check out the previous episodes here.
