4 reasons no one want to play scrum master

I’ve played the scrum master role on several teams of various sizes. From a team of 3 (2 engineers and 1 QA) to a team of 10 (4 engineers, 1 DBA, 3 QA, and a product owner). I’ve never been formally asked to be a scrum master, but I often volunteer to fill the gap because I see it as an important function for a high performing team and I enjoy some aspects of it like breaking apart complex work into manageable tasks, setting engineers up for success with their effort, helping to deliver a project in a predictable timeframe, and giving insight into work by transparently documenting the effort.

All of that being said being a scrum master can be a truly terrible role on a team. Here are a few of the reasons I think that is

Breaking up work is hard

Gathering concrete requirements for a project is hard enough. Translating those requirements into technical solutions is hard. Breaking the technical solution up into pieces so that engineers can take it and successfully build out a solution without lots of rework, false starts, and mistakes is a truly daunting task.

How hard it is depends on several key things

  1. The size of the project. If you’re building something small it’s easier to reason about it, if you have lots of dependencies and thousands of lines of code it gets harder and harder to break work up safely
  2. The number of engineers. The more engineers the more work it is to coordinate between them. More engineers means more time describing tasks and handing them off
  3. The timelines. If your timelines are tight you have less room to shuffle work and mistakes are more costly. Slotting a talk for a sprint before it’s prerequisites are done can mean a lot of effort

All of those things impact the engineering work too, but the scrum master work is usually done ahead of time so I’d argue the impact is felt more there.

Scrum master == scapegoat

If a project goes off the rails and is way behind schedule or over budget it’s easiest to blame the guy who was organizing the project. Some of that is reasonable because if you’re working to organize a project and it goes sideways you should be willing to own your mistakes.

That being said it’s difficult to estimate tasks, difficult to plan in advance, and difficult to lay out goals ahead of time. Too often management perceives a scrum master as a scheduler and expect to get long term dates from rough estimates. When they’re wrong it’s a lot easier to blame them for the mistakes.

You wind up writing a lot of agendas

If you’re an engineer you probably prefer doing technical work to writing a meeting agenda. But when you’re walking a team through a complex sprint plan, or there’s a lot of shuffling going on for a project it’s usually better to do some meeting prep before you start the meeting.

Who hasn’t kicked off a meeting to realize that you don’t have a plan, no one else is jumping in to drive it, and slowly realize you’re making a plan live in front of a studio audience?

It doesn’t take many of those experiences to make you want to avoid them. So you wind up writing agenda ahead of time, blocking a half hour before the meeting, and reviewing how they went afterwards to see if you can tune the meeting plan to make it more efficient.

Scrum master can be the bottom of a land slide

If you’re a scrum master you’ve probably heard the phrase, “Do you think you could get this organized? I think you have the best handle on what the team is working on right now.”

Once you’ve volunteered for the scrum master role and shown that you have the ability to execute you can find yourself at the bottom of a land slide with lot of work coming your way. If you’re not careful you can find yourself doing less and less engineering and more and more paperwork. It’s not necessarily a bad thing, but no one warns you about that the first time you volunteer to run sprint planning.

All of that to say, cut your scrum masters some slack. Give them a hand and appreciate what they do. Here are some concrete suggestions

  1. Participate in sprint planning and come ready to vote on points
  2. Don’t hold your opinion in, if you have experience on breaking up a certain type of work jump in, don’t make your scrum master pull teeth to get answers
  3. If a scrum master (who is also an engineer) asks if someone else wants to play scrum master for a few sprints it probably means they’re ready for a break. Take them up on it and they’ll probably trade back with you in the future

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Brian Olson

Engineer, formerly at Amazon, currently at Google. All opinions are my own. Consider supporting here: https://devblabs.medium.com/membership