5 Things the Scrum Master Shouldn’t Be Doing
I love being a Scrum Master. What I love about it is helping a team accomplish something and honestly just making Developers' work lives as hassle-free as possible. I love working with smart people and seeing them accomplish amazing things.
As a Scrum Master, most of us want to help. But sometimes we think we are helping when we’re actually hurting the team.
As a case in point, when I was a new Scrum Master, I was looking for ways (let’s be honest) to justify my existence. And I wanted to help. So, I observed that submitting security and access requests was an annoying administrative job for the Developers. I suggested that I could help take those over for Developers. What began as a way to help quickly became a bottleneck. Pretty soon one of the Developers asked me, in an annoyed tone, if they had to submit these through me because it would be faster just to do it themselves. It was a lesson I haven’t forgotten. Sometimes helpfulness can be annoying.
Sometimes knowing what NOT to do can be as helpful as knowing what TO do. Here are five things that the Scrum Master shouldn’t be doing.
1) Gatekeeper
No, I’m not talking about security access again. I once worked at an organization where instead of being the Scrum Master I was a stakeholder. I needed to request work from the Scrum team, and I knew it was a quick five-minute job, so I emailed my request to the Product Owner. Instead of adding the request to the Product Backlog (or telling me “no”), I got a snippy email from the Scrum Master a week later telling me that all requests for the Scrum team had to go through her. I decided to play by her rules and sent her a reply with my request, explaining that it was urgently needed. Ten back-and-forth emails and a couple of unanswered calls later, I finally actually gave up.
Some months later I received an email from a Developer asking for details about my request. I was surprised because I didn't know my work request had even been added to the Product Backlog, so by that time the business had developed a work-around. What I remember about this request was not so much the request itself but the frustration and lack of visibility around working with that Scrum team.
2) Organizing the Scrum Team into teams
I observed a Scrum Master once who was working to roll out Scrum to a new area of the business. One of the managers (who didn’t work directly with that team) met with other executives (who also didn’t work directly with those team members) and they put a lot of thought into how the teams should be structured and who should be on each team. It was well intended and well thought-out, but totally unnecessary.
A better approach would have been to let the team self-organize. On the many occasions where I have let teams self-organize, they mostly don’t come up with anything different or better or worse than what executives would have come up with. (Well, to be honest, usually it’s a bit better than what the executives would have come up with.) But the important thing is that they make it work because it was their own idea. And that makes all the difference.
I did this once with a team of sixty people remotely. They came up with their team structure, and they were empowered to decide who would be on each team. It improved morale. It made them feel in control of their own work. And it made them more collaborative than they otherwise would have been. Six months later, when priorities changed, they decided one day at a Retrospective that they needed to re-organize to meet the new business needs. And so they did. No management intervention needed.
3) Making decisions for the Scrum Team
If your team is facing a larger decision, it isn’t up to the Scrum Master to navigate this for them. What the Scrum Master can do is bring together the team members for a discussion and let them decide how to accomplish it.
For example, if the team is doing some greenfield development and they need to make a major architectural decision, I have often had Developers ask me to schedule a meeting to bring the right people together to discuss it. I facilitate the meeting in such a way as to make it productive. That’s my part as the Scrum Master. But I don’t make the decision for them. If they need to request approvals from higher-ups due to it being a significant decision, I ask how they want to go about that. Usually, it’s a follow-up meeting with leadership.
4) Owning the Sprint Review
Now this one is a bit nuanced. As the Scrum Master, it is my job to ensure that the Scrum events are positive, productive, and kept within the timebox. But the Sprint Review is the Product Owner’s most valuable event. They really need to take a starring role here, so it's important that I as the Scrum Master don't take over this event.
I’m not saying that the Product Owner has to lead the whole thing personally. In fact, it is really better if, during the part where we are inspecting the Increment, Developers can lead the discussion and get feedback on their own work, where appropriate. But the Product Owner does need to take an active role. They should be the one, for example, requesting feedback on the roadmap or forecast, talking through the plans for what the Scrum team will focus on next, reviewing outcome metrics or customer satisfaction figures, and talking about progress towards the Product Goal.
The Scrum Master might start the meeting if the Product Owner prefers that, but the Product Owner is responsible for maximizing product value and the Sprint Review is where we inspect progress towards the Product Goal and discuss what to do next. So, they need to have a strong role here.
5) Solving every problem for the team
It’s easy for a Scrum Master to slip into the mindset of being the chief problem-solver. A Developer mentions an impediment, and we jump in to fix it. A conflict arises and we figure it out ourselves. A process feels sticky and we redesign it on the team’s behalf.
Sometimes that is appropriate. More often it is not. When the Scrum Master consistently solves the team’s problems for them, the team never builds the muscle of solving those problems themselves. Over time, the Scrum Master becomes a dependency rather than an enabler.
A better approach is usually to coach the team to surface the issue, discuss it, and decide how they want to address it. Bring the right people together. Facilitate the conversation. Ask good questions. Then step back and let the team own the solution.
There are always exceptions
There’s always an exception to every rule. If a Developer asks me to submit a security or access request for them because they’re urgently busy, sure, I’ll absolutely do that to help out. If a Product Owner asks me to put together a forecast for them because they aren’t sure how to go about it, I absolutely have done that, but they are always the one with the final say on whether it looks right or not.
The difference is between temporarily helping and becoming the permanent owner of work that really belongs to someone else.
Great Scrum Masters remove real impediments, create the conditions for the team to succeed, and then get out of the way. Knowing what not to do is often the most helpful thing of all.
Learn what great Scrum Masters do focus on.
Like great Product Owners, great Scrum Masters know where to focus their time and where to empower the Scrum Team. In the Advanced Scrum Master class, you’ll learn how to focus on the work that matters most.
