Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
By the time a Dev-Team knows about the agile process and is able to defend it against outside influences, one might say the Scrum Master's work is done at this point and he/she is not needed anymore.
It seems this might be a very individual state (depending from team to team). I wonder if there are objective signs, when the Scrum Master becomes superfluous? Or mabye this state is never really reached and the Scrum Master always has some work to do?
There are no Scrum police and there is no, one right way to do Scrum. Scrum is a loose framework defined in less than 20 pages. Frameworks are a guideline, not a straight jacket. There are organizations, people, and thoughts that would have you think different. At the end of the day, remember, 20 pages is not a process, it's a guide, use your judgment.
That disclaimer aside, there are good starting practices most follow:
Role vs. Job is a huge distinction in Scrum. Someone should be filling the role, that isn't always their only job.
When coaching teams I generally go with this logic:
With a new team, a dedicated person, as Scrum master, can handle really only one team.
If you have one performing team and a newer team, a dedicated person, as Scrum Master, can handle two teams.
Once you get to three teams, then even a dedicated person can't fulfill the role of Scrum Master on all three teams easily. They have become a Scrum Coach.
Beyond four teams and you're moving into Agile Coach space as you are dealing with more and more concepts outside the outside the "strict" confines of Scrum.
If a team no longer has a dedicated Scrum Master role (because they are a higher performing team), the role of Scrum Master typically ends up being owned by the team. It's up to the team how to own it. They may rotate the role, divvy the role or any number of solutions. Because they are self-organized, they do this themselves and decide themselves.
And remember, always reach back to the Scrum Values and the Agile Manifesto to get a temperature check on how your decisions reflect the underlying principles and values.
When is a Scrum Master superfluous?
The goal is to enable the team to be self-organizing ... so once that happens then yes you could call the SM superfluous.
But projects and teams are always in a state of flux, hence if you are not needed today you very well may be needed tomorrow. So there is always a need to keep an eye on the team to ensure it's working and progressing. Some days the role of the scrum master may be very quiet as the team self organizes their way through the sprint, that's OK, it means that you (and the team) are doing an excellent job.
The Scrum Master role is always required for Scrum, but teams that have outgrown Scrum as a framework, or teams that have chosen a different methodology, can certainly evaluate the pros and cons of reducing or eliminating the role as part of their agile inspect-and-adapt cycle.
The Scrum Guide defines three roles:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
The Scrum Guide further states, rather explicitly, that:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
So, implementing Scrum without a Scrum Master is not technically Scrum. It's a "Scrum-but," where you're sort of following Scrum as a loose guideline, but not actually implementing the complete framework.
There are Scrum roles and events that require a Scrum Master. However, a high performing team may not need a full-time Scrum Master.
A dedicated Scrum Master is certainly best, because task-switching and project/role overhead affect a Scrum Master just as much as it does the other framework-defined roles. Nevertheless, high-performing teams may require fewer man-hours from the Scrum Master, allowing that Scrum Master to participate in multiple teams.
There is a practical limit to how many teams a Scrum Master can effectively (or even ineffectively) participate in, though. I can't find the related answer right now, but I believe the functional limit calculated in another answer on PMSE was "three." With that said, a matrixed Scrum Master is suboptimal, but may fit certain circumstances provided that the role is available to the team and the matrix effect doesn't create delays, blockers, or drag on the Scrum Team's processes.
https://pm.stackexchange.com/a/22265/4271
The Scrum Master's job is never "done." If you think the role has become unnecessary, you're likely overlooking something you should be doing or falling prey to the 100% utilization fallacy. Don't do that!
Your job is not to be busy all the time. Your job is to facilitate the process, and to be readily available and actively engaged with the team so that you maintain full situational awareness and remain fully plugged-in to the people and processes that affect the project. Even when it seems extraneous, the Scrum Master's job is to be immediately available for those times when the role is needed.
The scrum methodology defines certain roles. Each role has certain tasks. A person may perform one or more roles. In the extreme case a person may perform all roles, although this is not efficient.
If the scrum master tasks are assigned and performed adequately by other members of the team then the scrum master person (not the role), can be re-assigned in other projects. There are not any clear signs when this can be done, you have to gradually re-assign tasks from the scrum master to other members of the team, and closely monitor the successful completion of these tasks.
Although what I describe above can be done, I see two big disadvantages:
I have asked this question in my Scrum Master Certification. The answer was if you has a team that you can't see how to improve, why this team needs a Scrum Master? As you can notice, it can only happen in the long term, with a team that has been working together for an extended period without any changes or conflicts. In this case, the Scrum Master should look for another team inside the organization that needs his skills.
As you wrote: a Scrum Master is a role. A role has one or more tasks to do and one or more responsibilities to fulfill.
So if the tasks and responsibilities are not needed anymore, you should cancel it.
How can you assess if a role is still needed?
An easy way is to play through a few use cases. For clear tasks, you can quite quickly come to an assessment.
What about the not so obvious tasks?
A Scrum Master often helps you as somebody that is more disconnected from the group dynamics can view the situation from a different point. This is not only useful for outside requirements but also for team internals.
So if you want to do scrum you need the role but if you modify the setting you should definitively have somebody outside the Dev Team that can "morally" support the team.
I always find it quite helpful to refer to the Scrum guide for guidance for these types of questions. It always amazes me that such a short document pretty much always has the answer. The same with the Agile manifesto.
According to the Scrum guide:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
If you take away the Scrum Master you no longer have a Scrum team.
This is not to say that you cannot deliver or that you are somehow now waterfall. It just means that you have decided, based on your own experience, that you don't need one and you have therefore created an offshoot of Scrum for your own circumstances.
Scrum works for thousands of teams around the world because they have adopted the framework and then the team grows and delivers within this framework.
If you remove a part of the framework you may not reap all of its rewards.
I have worked with many teams that have adopted their own 'method' which takes what they perceive as useful from different frameworks but there are pros and cons to this approach and the happiest highest performing teams I have worked with stick to the framework.
