ScrumMaster is a leadership position that requires creativity, vision, and intuition to succeed. Good ScrumMasters are empathetic, good listeners, and ready to heal relationships. This blog explains 20+ ScrumMasters Roles.
If ScrumMasters combine multiple roles, they have to be good at distinguishing one from the other. They can wear only one hat at a time, so they have to choose which role they are in when speaking or acting.
The following examples provide more detail on the advantages and disadvantages of the roles most often combined with the ScrumMaster role.
The ScrumMaster Works with Multiple Teams
Disadvantages: A ScrumMaster for multiple teams lacks time because even independent problems quite often arise at the same time. The inability to facilitate discussions early enough and prevent conflicts from growing often makes the job quite difficult.
Advantages: The ScrumMaster learns fast and is much more experienced in solving difficult problems. A general recommendation is to have one ScrumMaster for two teams, or a maximum of three teams, at one time.
In most environments, three would be way too many because such a ScrumMaster would lack the necessary information to prevent conflicts and move the teams to the next level.
Result: Such a ScrumMaster has more experience and is usually much better at system thinking because he understands that every team is different.
Based on his experience in different environments, he is more likely to be successful in implementing Scrum in different cultures. He is also more likely to apply Scrum over the entire organization and will not be too attached to the development team.
A ScrumMaster for two to three teams is the only recommended combination. The Product Owner should never act in the ScrumMaster role. The two roles have conflicting goals.
The combination of ScrumMaster and manager often creates a lack of trust and makes the team too reliant on the manager's decisions, instead of taking responsibility themselves.
ScrumMaster is a leadership position. It requires creativity, vision, and intuition to succeed.
Good ScrumMasters are empathetic, good listeners, and ready to heal relationships.
Great ScrumMasters are not solely focused on their teams but are able to build communities across the organization.
Listening to others
Awareness and self-awareness
Commitment to the growth of others
Building a community
Stay One Step Ahead
Any change is difficult, and every individual copes with it differently. Just as you can observe resistance in individuals, you can see it at the team or organization level. One of the ScrumMaster’s roles is to be a guide during change such as an Agile transformation, a new way of collaborating, or a new practice.
To be a good guide, the ScrumMaster must stay only one step ahead of the team and organization, pulling them out of their habits, norms, and customs.
If he goes too far too fast, the team will most likely not understand what he is talking about. If, on the other hand, the ScrumMaster is at the same stage as they are, he is not challenging their status quo enough and they will not improve.
In the very first stage of the change, the ScrumMaster must overcome quite a bit of resistance—people will simply say, “We’re happy with what we have.” They don’t want to change and don’t see any need to change. So, asking them to take over some ownership and activity at this stage is bound to fail.
After some time people start saying, “It’s all great, but it’s not for us.” They have already tried new things, but because it’s not easy for them to change, they prefer to return to the previous state, before the change.
Some time afterward, when together you have overcome the biggest issues, people will say, “Let’s talk about how to improve things because we don’t want to go back anymore.” This is already a good state to be in.
Finally, they make it. And they celebrate. “It’s much better than what we did before.” And here is the biggest trap. They are all so happy with their achievement that they stop improving and get stuck.
The ScrumMaster’s role is to let them enjoy this moment but then to push them in the direction of more experimenting, process adaptation, and improvement.
The ScrumMaster is a guide in Agile transformation.
The ScrumMaster should stay only one step ahead of the team and organization, pulling them out of their habits and customs.
A great ScrumMaster should start each day with a question: “What can I do to make it easier for my team to perform their work?” One way of helping them is to remove impediments so they can work efficiently.
However, ScrumMaster is not just an administrative position, and so the way to remove impediments is to delegate responsibility, activities, and ownership to the team so they can solve problems by themselves.
Unless the ScrumMaster gives the team the opportunity to take over these tasks, she ends up as their “mother” who is so loving and caring that her “kids” are low-confidence grown-ups, dependent on her even in their thirties.
So, should the ScrumMaster remove impediments? Yes, but in a way that supports the team in finding a solution. The ScrumMaster can start by explaining what self-organization is and why it is such an important part of Scrum and continue with coaching and facilitation.
Facilitation means making sure that team meetings run smoothly and that communication flows in an efficient way. Therefore, every meeting or conversation should have a clearly defined goal, deliverables, and an idea of what the expected result looks like.
The facilitation rule says you should never interfere with the content of the discussion or the solution itself. You only drive the discussion flow.
Facilitation makes communication more efficient.
Define a goal, deliverables, and expected results.
Coaching is probably one of the most important skills the great ScrumMaster must have. It requires a lot of practice and experience, but once you master it, it’s incredibly powerful. In Scrum, coaching focuses not only on an individual’s personal growth, but also on team self-organization, responsibility, and ownership.
Coaching is more powerful than explaining, sharing experiences, or giving advice. The goal is not to be fast in the short term but to improve in the long term.
The team is at the beginning of the transformation. They’ve just passed Scrum training, but they still don’t understand what it is really about. They complain that Scrum is not the right method for them.
The right approach here is to explain all over again why you do Scrum, what you expect from such change, and how individual Scrum meetings and artifacts work together.
In order to be successful, team members have to understand the dynamics and principles behind Scrum. If the ScrumMaster only facilitates, most likely this will not happen fast enough. If the ScrumMaster coaches, the team will be lost, as they haven’t a clue how to improve their Standup, for example.
The team is taking over responsibility, but they face loads of problems. The easiest way is to take over and remove those impediments for them. But wait. How does that approach lead to the goal of the ScrumMaster building a self-organized team?
It doesn’t. So the ScrumMaster has to take the slower and more painful approach for the sake of the team and coach them to realize they can handle most of the impediments by themselves.
If the ScrumMaster doesn’t do this, she ends up as team secretary very quickly, and the team becomes a low-confidence group that always waits for someone else to fix things. Proper facilitation of meetings and discussion helps as well.
The team has been working in a Scrum environment for a long time. They may not be a good “Scrum team,” but they are fine with how they are.
The optimal approach here would be coaching. Coaching techniques reveal opportunities for improvement to the team and also let the team members see their problems first.
If the ScrumMaster starts with teaching and explaining, the team will most likely not accept it and reply that, as a self-organized team, they will decide how they work. The ScrumMaster is not there to tell them what to do. In some cases, they refuse to accept such a ScrumMaster, and she has to leave eventually.
The team is quite good; they mostly self-organize. The ScrumMaster remembers that her facilitation skills were a necessary aspect of their success. That’s how the ScrumMaster improved their cooperation. That’s how she made them efficient.
Nonetheless, it’s the right time to move on and change the approach. All ScrumMasters should do is step back and let the team run the meeting. Don’t stay in the middle, don’t start it, and don’t indicate who’s next. Just be there, ready for facilitation with a lighter touch. Give them space and trust them.
They will make it. If the discussion goes in the wrong direction, coach them so they identify the problem and adjust accordingly. Note that you are not disappearing at this time; you are still present, carefully listening, aware of what’s going on, and ready to help if needed.
Although all the approaches of the ScrumMaster State of Mind model are important during your journey to becoming a great ScrumMaster, one very important item is still missing—observation.
If you take the opportunity to be quiet and let the team take over an activity, you can continue to observe them for another minute before you teach them or explain how they should do something, facilitate their conversation, coach them to decide themselves, or try to fix the problem yourself by removing impediments.
If you resist the urge to solve every issue as quickly as possible so the team can get back to work again, you will be much closer to the goal of having a self-organized team.
Therefore, the ScrumMaster State of Mind model is very important, because it forces you to step back to the role of observer and decide which approach you are going to take and why. There is truth to the adage that listening is one of the most important aspects of communication and decision making.
When you imagine how listening could have improved the outcome while you were teaching, facilitating, coaching, and removing impediments, you will find some situations where you would have decided things differently if you had practiced this model.
Observing, listening, and not interfering are the most important aspects of a great ScrumMaster’s job.
Any action, such as coaching, facilitation, teaching, or removing impediments, can wait until it’s clear which approach is the best choice.
Scrum defines three roles only—ScrumMaster, Product Owner, and the development team. The usefulness of the latter two is usually easy to understand because companies can link them to existing roles, but the ScrumMaster role puzzles them.
To make the ScrumMaster role more understandable, I have designed a new concept describing three levels of a great ScrumMaster: #ScrumMasterWay.
It helps ScrumMasters to focus on the right level of the organization at any given time and pull them out of the development team perspective into that of the product and the overall organization.
Every level is individually described in the following sections, but before you go on, try this simple exercise.
ScrumMaster’s point of view
The Product Owner should be
not part of any team; he should not attend Retrospectives.
my partner; I’m here to help.
a member of the self-organized team of Product Owners taking care of the product portfolio.
Other teams that need our input or support
a. are spoken of as “them” and we don’t care about their needs.
b. have to ask the Product Owner to plan items into the Backlog.
c. are part of our company and we help each other.
I expect the manager
not to attend any team meetings.
to help me create a suitable environment and remove some roadblocks.
to support my learning and encourage me to come up with innovations and changes at the organizational level.
I expect to get
clear and measurable expectations of what I am supposed to achieve.
an opportunity to aim for long-term team success.
the freedom to come up with innovative and creative ideas, even outside our group.
A group of ScrumMasters is
useless because I don’t need other ScrumMasters to do my job.
useful, because we can help each other and share experiences.
the most important group because I can’t “change the world”/my organization alone.
If you chose “a,” you’re at Level 1; “b,” Level 2; “c,” Level 3 (the levels will be explained in the following sections).
LEVEL 1 — Team
At this level, the ScrumMaster feels responsible for the development team only. It’s not uncommon; it happens to most new ScrumMasters who have passed some training course and started to apply Scrum theory. During the class, they are already struggling with questions such as “How can I make myself useful every day?”
The answer goes back to the goal of the ScrumMaster: to build a self-organized development team, and let them embrace Scrum values and the Agile mindset, which is a long-term activity, not a short-term task.
Bearing this in mind, your first step would be to make yourself comfortable in the Observation segment from the ScrumMaster State of Mind model and suppress the urge to do something like removing impediments yourself or giving advice.
In this first transformation stage, you would find yourself busy with the development team’s resistance, lack of understanding, and absence of ownership, responsibility, and experience. When you have passed this phase, another question arises: “What shall I do when my team is finally self-organized?”
This makes perfect sense because at the beginning Scrum-Masters must spend more time teaching and explaining and maybe also removing impediments, but at a certain point in time, such activities may not be necessary anymore. Facilitation of team discussions and meetings may not be as necessary either.
For example, a Standup meeting is simple enough that the team can run it independently without any ScrumMaster activity. At this time the ScrumMaster is ready for the next levels of the #ScrumMasterWay model, where there is plenty of work to be done.
The first level of the #ScrumMasterWay model is good for the initial transformation phase, but it’s just the start of your great ScrumMaster journey.
LEVEL 2 Relationships
You feel good about your team, but it’s time to move to the second level and focus on relationships. The first step is to create a coherent, self-confident Scrum team that integrates the Product Owner into the team, and to create balanced relationships among the three Scrum roles.
When you are finished with that, your next step is to empha-size all the relationships and connections the Scrum team has— with customers, users, product people, marketing, support groups, and other teams and line managers.
In this effort, you are applying self-organization to everyone who is involved and building self-organized teams with the people who work with you. This can include the implementation of a scaling Scrum model or just focus on the overall communication and information flow.
Consequently, the ScrumMaster’s ability to explain Scrum at the development team level is a good background skill for this level. The crucial factor is your understanding and definition of Scrum as not only a set of meetings, roles, and artifacts but also a culture, philosophy, and mindset.
In this stage, you must see Scrum as an empirical process that you can imagine as a playground with certain boundaries around it and a few general rules for how to play, but the details of how to play are up to the team and will differ from one team to another.
In this stage, more flexible virtual teams are built to take over ownership and responsibility for certain areas. Some of these teams solve problems or address issues and then fade; some will remain active for a longer time.
In this stage, you are making continuous improvement and perpetual adaptation of your cooperation an integral part of your environment.
The development team and the Scrum team are not the only teams in an Agile organization.
Scrum is a mindset, culture, and philosophy, not just a fixed set of practices.
Level 3 ScrumMaster’s Entire system
Finally, the last level of the #ScrumMasterWay model focuses on the organization or one of its parts as a whole system.
At this level you want to transform the world of work by guiding the organization to become prosperous and sustainable, to inspire people, and to create value for society. That’s actually the mission of the Scrum Alliance.
Level 3 moves the ScrumMaster’s focus to the entire system, bringing the Agile mindset and Scrum values to the company level. It helps an organization to change its approach to its employees, management and leadership style, product ownership, and strategy, so it can be more flexible and welcoming of change.
The new understanding and definition of Scrum is “a way of living.” It becomes a culture or philosophy according to which you can live. You realize that it’s not only a way of working but that you can apply these principles to your personal life.
That doesn’t mean doing family Standups, having a family Backlog, or anything like that. It’s more about attitude, principles, and approaches.
The ScrumMaster at this level becomes an Agile or enterprise coach who is helping the organization to become more efficient, contented, and successful.
Regardless of the situation, the ScrumMaster should be aware of the current status at all three levels, but his activity may vary depending on the circumstances. Note that unless the previous level is working well, you can’t really jump to the next level.
The ScrumMaster works as an Agile and enterprise coach, improving the whole organization.
Scrum and Agile are a way of life.
First, fix the development team level, and then improve relationships before you focus on the system level.
Make sure you still keep an eye on the lower levels so they improve as time goes by, aligned with the top levels.
Hints for Great ScrumMasters
Observe before you decide which ScrumMaster State of Mind approach you are going to take.
Remove impediments by helping the team to remove them.
Facilitation is more than running a meeting, reading a blog, or going to a facilitation class.
Coaching is not about your experience but rather the ability to ask good questions.
Work at all three levels of the #ScrumMasterWay model; don’t stay only at your development team’s level.
Agile and Scrum are the ways the great ScrumMasters work and live.
The ScrumMaster’s Role
So what should the ScrumMaster do? First, identify how deep in the dysfunctions pyramid his team is.
Once he recognizes this, he has to teach the team to increase their understanding, coach them to make them realize they have a problem, and help them to create some team alliance or working agreement on how they are going to work together.
The key is the realization of what the team wants to achieve and why, plus some plan for how they are going to get there.
One small piece of advice that helps when you’ve risen beyond the initial layers is to create a team identity intentionally. Call them “the team,” and let them decide on a name.
Never ask individuals what they think—always make the team accountable. “What does the team think about it?” or “You are the team, you should decide.” You’ll be surprised at how well such a tiny change works.
Even a good team can sometimes fall short when it comes to supportiveness, collaboration, and friendly behavior. Let me introduce you to four toxins that often poison teams and organizations. It’s good to be aware of all four of them and, if they emerge, to identify them and help the team to overcome such situations.
Everyone does this sometimes: “It’s your fault!” It’s easy and natural to try not to be responsible for any faults. In a Scrum team, it can be a complaint like “It is the Product Owner’s fault. He is responsible for the Backlog and User Stories.
This one was just not well described,” instead of saying, “This User Story was not defined well; what shall we do with it next time so it will never happen again?”
The ScrumMaster’s Role
The ScrumMaster’s role is to educate the team about the four toxins and then coach them so they are able to identify the toxins in real time and make each other accountable for not using the toxins.
You’ll be surprised how often these toxins are present in your discussions and how just raising awareness of them can be helpful. Communication becomes nicer, and you will be able to reach an agreement much more quickly.
The overall environment will be less like a thunderstorm, and overall motivation and ownership will increase. Teams working in a less toxic environment have more fun, and that’s what you are looking for, right?
One of the most critical parts of the Agile mindset and of Scrum culture is responsible. Everybody talks about responsibility, but not many of us take full responsibility in every situation.
Christopher Avery has created a very nice responsibility model that explains how responsibility works. During the long years of evolution, people's brains were trained to be quick in decision making.
Whenever even a small issue emerged, the brain would offer an option for how to approach it. As an example, imagine you are parking your car in an underground garage and you accidentally scratch the car next to you.
The first solution your brain will offer is denial. “This never even happened. I don’t see any scratches, the car is just dirty. And the sound? It was only sand crunching.”
Back at your Scrum team, it could turn up as pretending that a piece of code works, even if it just crashed. “It’s coded, so it works.”
While you are not fine with denial, your brain will offer the next possible solution of laying blame in no time. “It’s his fault! If he had parked straight, this would never have happened.”
In the Scrum environment, this could be pointing at the Product Owner because he described something wrong, or it could be the fault of another team member. “I coded it right; it’s his fault that it’s not working.”
Still not happy? Don’t worry, your brain is proposing another solution. You can justify it. “It happens. Everyone scratches a car from time to time, right? And those underground parking spots are so narrow.”
The Scrum team, at the beginning of their journey, uses this excuse quite often when trying to explain why they can’t plan a Sprint or didn’t finish with the Sprint results they expected.
“Anything can happen during the Sprint, so we can’t guarantee anything. In software development we often encounter technical difficulties, right? That’s just the way it is.”
If you still don’t feel good about it, you can see it as your own fault. “It’s all my fault. I will never learn how to park in those narrow spaces.”
The Scrum team may express their frustration over the lack of cross-functionality and say, “We don’t have enough experience in that product part. It’s too difficult. It would take us years to learn it.”
They usually don’t mind that they are in fact saying, “We are not good enough,” and they are trying to hide it by claiming that it’s normal to ask for experts.
So what’s next? Solve it as if it is your obligation. “I’ve left my business card behind the wiper blade. It’s my duty to do this. The insurance will cover it.”
This stage reminds me of a Scrum team that follows Scrum just because they have to. Someone told them to have meetings, so they have them without understanding. “We do Standup because of Scrum—we have to. It’s one of the Scrum meetings, isn’t it?”
At any time you can decide to quit. “I’m not going to solve it; it’s not important for me.” No one is forcing you to be responsible. However, don’t trick yourself. None of the previous levels is real responsibility. And nothing previously mentioned helping you prevent those things from happening in the future.
Tuckman’s model of the stages of group development
One of the classical theories of team development is Tuckman’s model of the stages of group development. Let’s look at how this theory applies to the Scrum environment.
Imagine you’ve just started Agile transformation and are moving to Scrum. You’ve got a bunch of individuals that you call a team, specifically a self-organized Scrum team that is supposed to become cross-functional. So what’s happening?
Being in the forming stage is kind of OK. People don’t talk or cooperate much; they still keep their old habits as individual specialists. They actually don’t need each other. Scrum is hard to apply to their way of working, so they complain that it’s not at all useful in their environment.
The ScrumMaster’s role at this stage is to explain the backbone Scrum principles and start the transformation, not only on paper but in the team’s heads—to lift them out of their habits.
ScrumMasters have to be present in all segments of the ScrumMaster State of Mind model; however, they spend significantly more time teaching, explaining, and sharing experiences.
Storming usually comes very soon after forming, because Scrum pushes cooperation, commitment, and communication far beyond the team’s limits.
The tension grows as they try to follow the Scrum process; they start to argue with each other and often get upset. It’s not a happy place to be, so they are glad to grasp any hand being offered to them to get out of this stage.
The ScrumMaster’s role is to encourage them to talk and make working agreements on how they are going to act together.
In this stage, the most important aspect of the ScrumMaster State of Mind model would be facilitation, because smooth communication may take the team out of storming to the next stage of norming, whereas poor communication can break them apart and turn them into a dysfunctional team.
The norming stage brings liberation from stress and the team can finally breathe. “Wow, it finally works,” they say. “And it’s better than before! We like it.”
But be aware that this is exactly the reason why norming is so dangerous: it tempts teams to stay where they are: “We are good; we don’t have to improve anymore.” But that’s not the goal. You didn’t put in all that effort to end up here. A good team is not yet the high-performing one that you aimed for.
The role of the ScrumMaster is to show the team ways to get even better. Encourage them to take ownership and responsibility and continue improving.
In the ScrumMaster State of Mind model, the most important tool to be used at this stage is coaching. Without it they are likely to get stuck in this stage forever—which is not too bad because this stage is already quite comfortable and productive.
Nevertheless, the real goal you want to achieve with Scrum is the performing stage. This is the right Scrum team. So how do you recognize you are there? First of all, the team is self-confident and always looks for better ways to do things.
They don’t feel they are finished yet. They are playful, they run experiments, and they are not afraid of failing. They are open and transparent. They are not self-centered but looking across their team boundaries. It’s a very creative and innovative place to work, and the people have lots of fun.
What is the ScrumMaster’s role here? Well, to prevent things from going wrong and avoid the team returning to any previous stage.
It is mostly observing, while focusing on other levels of the #ScrumMasterWay, always being ready to step in as coach, facilitator, or impediments remover or to share experiences and teach the team new things.
To complete the model, there is always some change. And even a small change (such as when one person leaves or joins a team) can break a team apart and make them return to the first forming stage.
They will most likely not stay there for a long time, but they may have to go through all the team development model stages again.
It may take a day, or forever because they might get stuck at the norming stage this time. If you think about it, it makes perfect sense: during the first round the ScrumMaster was diligently taking care of communication, working agreements, and team health, but this time it may be that no one thinks about these things.
Thus the ScrumMaster’s role must be to observe any change and to identify it early and adjust his behavior regarding the actual team stage, even if it’s just for a couple of days.
For the same reason, even a great self-organized team needs the ScrumMaster. Otherwise, they may not handle such changes by themselves and eventually end up in the norming or storming phase.