ScrumMaster ≠ Manager
The ScrumMaster role on the team is never static and takes on many forms. Their role is one of servant leadership; as the team needs, the ScrumMaster provides. When the team first adopts Scrum, the ScrumMaster plays the teacher: training the team on the mechanics of Scrum, guiding the Product Owner on how to build a backlog, educating stakeholders on the new ways they will be given transparency into the progress of the product.
As the team progresses the ScrumMaster transitions into more of a coach: creating space for the team to self-improve, mentoring Product Owners on increasing outcomes while reducing output, and helping stakeholders embrace team empowerment. In just the span of a day, the ScrumMaster will oscillate from teacher to coach to mentor to mom to confidante to guru to barista and back again 30 times.
There is one role, though, the ScrumMaster should never slide into for the team, and that is the manager.
Who is accountable for the team’s success? The team. A team can’t achieve “self-organizing” if they are looking to the ScrumMaster to drive their day-to-day or become their taskmaster. If they are treating the Daily Scrum as a status meeting for the ScrumMaster, they aren’t using that opportunity to collaborate and create a gameplan for the day.
ScrumMaster Role Definition can lead to Management tendencies
The way the ScrumMaster’s role is sometimes worded can lead to some of the “doing it for” rather than “coaching them to” that happens. For example, on his website, Mike Cohn outlines some of the key tasks as “removing any impediments to progress, facilitating meetings, and doing things like working with the Product Owner to make sure the product backlog is in good shape and ready for the next sprint.” This is in no way a comprehensive list of the duties of the ScrumMaster but highlights a few areas that they can easily fall into the trap of managing the team.
Impediments are barriers to progress. As they are identified, the ScrumMaster should be working with the team to come up with a plan to solve them. This doesn’t mean that if, for example, the team is waiting on a design, the ScrumMaster runs over and pushes the designer to deliver. It means instead of a team member saying, “Oh well, looks like we are blocked by design on this one, I’ll move on to the next thing,” they quickly have a discussion with the designer to check the status and see what they can do to help move it forward. It’s easy for the ScrumMaster to scurry around removing impediments as soon as they pop up. It’s harder to help the team become disciplined in resolving them before they are truly impeded.
When a team is starting out, the ScrumMaster should play a very hands on role in facilitation to make sure Scrum meetings accomplish their purpose and stay within timeboxes. We can’t just tell the team to “self-organize” on something they have never done before, the ScrumMaster should lead by example. They should make sure everyone is prepared and that conversations are not dominated by only a few strong voices. There should be space for everyone’s thoughts and opinions.
As the team matures, it’s all too common for the ScrumMaster to continue leading rather than encouraging the team to take over ownership. It’s easy for the ScrumMaster to call on each team member to give their daily update. It’s harder to create a mechanism for the team to instigate the conversation and embrace collaboration.
The ScrumMaster should be a teacher/guide for the Product Owner to encourage them to bring product ideas to the team in a way that the Who, What and Why are part of the conversation and the How is up for negotiation. It would be efficient for the backlog to be built in a one-on-one with the PO and SM or even more so the Product Owner sitting in front of their computer jamming out to some classic rock and hammering away. The more valuable way to create a backlog and increase motivation is the ScrumMaster making sure time is allotted every sprint for the Product Owner to sit down with the team to discuss backlog items, add acceptance criteria and break them down into sprintable chunks.
Situations that force ScrumMasters into the Management role
Organizational culture and alignment can put the ScrumMaster into a position where they end up taking on the role of manager. This could be because they have a direct report on the team or because the organization has made them accountable for the success of the team. Either of these could create a conflict of interest that renders the ScrumMaster incapable of truly coaching the team if they don’t do some serious realignment.
It’s extremely common for a more senior ScrumMaster to manage other ScrumMasters. This is not a conflict of interest. However, there is a potential for major misalignment if a ScrumMaster is a Dev manager and members of their Scrum team report to them in the HR structure. This is bad news, but it happens. Sometimes the Dev Manager has the best personality to play the ScrumMaster on a team. Unfortunately, this means when they suggest something, in the context of their ScrumMaster role on the team, their direct reports see things as mandated. If there is no way to reshuffle, then it is best to identify the potential conflicts and monitor them to maintain a healthy balance.
Performance evaluations and compensation can also add fuel to the fire. If a ScrumMaster’s bonus is tied to team metrics they lose their impartiality. If the team wants to try something big which could cause a temporary downturn in velocity, they should feel empowered to encourage them to do so. As a company grows from one that is “doing Scrum” to an “Agile Organization” the management dynamic will need to shift. Traditional command and control management styles will need to be replaced with more of the ScrumMaster’s servant leadership and coaching traits.
It’s easier for the ScrumMaster to do things for the team, it’s harder to create space for them to own it themselves. This is the difference between managing and coaching. Trust your teams. Empower them. You will end up with a much better product, happier customers, and much more motivated teams.
- This is referring to “little c” coach rather than “big C” Coach as in Agile Coach. Different organizations handle these roles in differing ways. In some, the Agile Coach is a role separate from ScrumMaster, or the ScrumMaster’s actual title is Agile Coach while the role they play on the Scrum team is ScrumMaster. Other organizations reach out to companies that specialize in Coaching and contract Agile Coaches to come in and help drive Agility.
3 Responses to “ScrumMaster ≠ Manager”
Great article! Nicely written. There are many instances of this problem out there. Thank you for taking the time to blog. I’ll be sharing.
And the line between being helpful servant leader and manager is so thin 🙂 But you’ll make it with patience, focus and practice. Good art, thanks
With the right person in the right situation, I have seen how a Manager might also be a good Scrum Master. https://www.agility11.com/blog/2018/10/18/should-your-manager-be-your-scrum-master