ScrumMasters Get No Respect

While this is the image many of us associate with being a ScrumMaster, most of the time this is just a fantasy

It’s bitterly ironic that the two jobs in a small team that end in “master”, ScrumMaster and BuildMaster, are the ones that get no respect. If you’re working as the BuildMaster, you’re always chasing down developers who broke the build and then skated out. Or you’re writing a lot of back-end scripts that, while useful, nobody ever really thinks about much. They just want it to work™. In a lot of ways you’re like the guy in the circus who follows around behind the elephants all day: not exactly a fun gig, but necessary.

Being a ScrumMaster is just as bad, if not worse. The title itself is hilarious: you are truly master of nothing. Instead of chasing down builds, you’re usually chasing down developers for things like missing estimated hours, or status of their stories How is it possible to stand in a room, work in a room, with a huge board with stories on it, talk about them everyday, yet somehow fail to actually update the board? Yet this happens all of the time. In a way, this makes the ScrumMaster role a lot like testing — you’re always reminding people of how stupid they are. Not exactly a recipe for a fun time.

Worse, if you’re not chasing down developers, you’re teaching newcomers about the “rules” to the Agile/Scrum thing. You know, the pigs and the chickens. What idiot came up with the idea of having to explain how the roles work to middle or senior management in terms of farmyard animals? Could we get any sillier than that? Maybe we could have them actually dress up as chickens and pigs. Nope. Scratch that. If I’m not careful I could start something and not mean to.

But it’s tough to educate everybody, and many times that’s what you’re having to do as you also try to do the ScrumMaster duties. While in really small teams being a ScrumMaster is just a part-time deal, if you have a team that’s just slight too large, say 10 or 11 people, and running really short Sprint lengths, you’re going to be humping it. Good Agile teams are like controlled chaos as it is. ScrumMasters are the ones that always get the worst of it.

Is your ScrumMaster just another suit? Or is he actually part of the team?

Then we have the whole confusion over exactly what the ScrumMaster is supposed to be doing. I hear all you folks out there: “ScrumMaster is just another word for project manager — just with lots of feel-good fluffiness around the job.” But you know what? You’re wrong. To me a ScrumMaster is always focused internally on facilitating the team in their Agile stuff. Traditionally the Product Owner is focused externally on commitments and resources, like testing gear or lab time. I see a lot of teams that keep a PM in addition to the ScrumMaster role. The PM doesn’t run anything: project management is just another skill like database administration or UX savvy that team members bring to the table. And isn’t the idea that everybody on a team should be able to fill in for each other anyway?

Can your ScrumMaster actually develop? If they can’t, you got problems. How is a ScrumMaster supposed to know the impact of various things being brought up in a stand-up if they don’t know what the terms mean or how big of a problem something actually is? Yes, you can ask, but many times obstacles appear “under-the-radar” for a while before they blow up. ScrumMasters who have technical chops can spot these. It’s lot harder to do it the other way.

Do this this with your ScrumMaster role

That’s one of the reasons why, just like with BuildMasters, you should rotate your ScrumMaster role. Let’s face it: it’s not rocket science and if the team is truly working cross-functionally it shouldn’t be that big of a deal. The job requires great people skill and being able to write and add and subtract. Maybe make a graph or two. If you are working side-by-side with your team and can’t talk to them? You have bigger problems than ScrumMaster ones.’

Because of all this, it’s common for ScrumMasters not to be happy with their work — it can truly feel thankless. In addition, because ScrumMasters can tend to be dictatorial, it’s also common for teams not to be that happy with their ScrumMasters, either.

No matter how you slice it, ScrumMasters get no respect. Rotate the role around and let everybody see this and watch your cohesion and performance increase.

If you’re interested in becoming a better ScrumMaster, or would like to get your agile team off to the best start possible, get the ScrumMaster book.

No ScrumMasters were harmed in the making of this post

8 responses to ScrumMasters Get No Respect

Really rotate the ScrumMaster role? I’ve been doing/coaching/training Scrum for a number of years now. I’ve rarely seen this idea work well. Becoming a good ScrumMaster takes months – rotating the role just means that you have that much longer to wait before you have a good ScrumMaster.

If you’re having that much trouble with the role of ScrumMaster and your team look at the person playing the role, look at the team and ask what the issue is.

We disagree. That’s fine. If we all agreed there really wouldn’t be much to blog about.

I’m not going to get into a “I’ve coached way more teams than you have” discussion. It’s not relevant, and it drags down the discussion. This is what I’ve seen, this is why I recommend what I do.

I would caution against “Magic ScrumMaster” syndrome — where all the ills of the team are foisted on whoever the guy is that has the SM role. ScrumMasters exist as part of a team. That means the same ScrumMaster doing the same things in a different team can have different results. It is a simple job, but it is not an easy job. We make a mistake when we take out the role from the surroundings and lose track of the bigger picture.

That statement itself looks a bit problematic to me. If the team is dependant on the ScrumMaster to make a technical call on whether an impact is big or small, there’s something inherently wrong with the team’s approach.

The team should be trusted to make that call not the ScrumMaster. If the team thinks a problem is big, then the problem most likely IS big… similarly if the team thinks it is small it most likely is small. The ScrumMaster doesn’t need to dictate or understand the extent of impact.

I think you’re moving the goalposts a little bit here. My point was that the ScrumMaster had to understand the technical conversation in order to know when to bring things up to the team, not that he would be making some kind of decisions for the team.

Imagine sitting in a nuclear control room. The place is full of engineers. There’s a problem with the reactor. You are the facilitator. Should you have knowledge of nuclear power?

My point is that you have to know enough of the problem domain — including the most-important social aspects (which we all emphasize) — in order to help the team make decisions.

At one end there’s the old “A Project Manager can manage any kind of project” that PMI said for a while. (Not that the SM is the PM, but you get the idea). On the other end is the old idea that the SM has no special skills — it’s not a job.

I think the answer is in the middle. A ScrumMaster doesn’t have to know the exact details of what’s going on, but he/she should be technically-inclined. If I had to make a mistake, I’d take a developer who was rotating into the SM role for a few sprints over a “trained” SM with little or no domain/technical experience. We really need to stop putting the SM role on such a pedestal.

I do agree that the ScrumMaster role can an should be rotated. I used to do that in some of the smaller project teams I’ve coached where I assigned a new SM every iteration and the received the concept really well.

But by your logic if a ScrumMaster needs to know how to code, a Tester, a UX designer, a DBA can never assume that role and hence only the devs would rotate that role among themselves.

The whole idea of a ScrumMaster is to make sure the Agile teams adhere to Scrum theory, practices, and rules (as per the Scrum Guide).

On top of that SMs make sure there are no blockers during the course of a day, and that’s what makes this roles so generic for anyone in the team can wear the SM hat.

If a technical background was a pre-req I’m afraid you won’t be able to rotate the role.

My two cents worth.

P.S: If it were a nuclear power plant and I was a facilitator, the team would point me to who, or what they need to fix the prblem and it’ll be my job to get it for them. I don’t/wouldn’t need to know what the technicality of the fault is… if you know what I mean.

Here is the meat of what I am saying: “The team is more important than the process or the ScrumMaster”

Now, it’s perfectly fine to say, as you did, that the ScrumMaster tole is critical to make sure that “Agile teams adhere to Scrum theory, practices, and rules (as per the Scrum Guide).”

But I don’t believe that. As somebody outside the team, I only care if they are getting their work done. If I were inside the team, I would only care about whether we all made decisions as a group and iteratively got better over time. In neither case would I care about whether we were being appropriately agile. Agile exists as a goal, an idea, not a rigid set of rules to be adhered to. Perhaps the team doesn’t like stand-ups. Good for them. The rest of us may think this is an idiotic idea, but it’s up to them to figure it out on their own.

Looked at it like this, The ScrumMaster is a _facilitator_, not a manager. He is the Master of Agile Ceremonies — helping with the structured part of the show. But he is not the leader or the controller. In some ways, having a management background is a severe disadvantage to being on an agile team. Many times the things we teach managers are very difficult to un-learn later on. I spend a lot of time telling managers to loosen up.

I want to point out something you said — I’m honestly not trying to pick apart your comment, but I found it instructive.

“But by your logic if a ScrumMaster needs to know how to code, a Tester, a UX designer, a DBA can never assume that role and hence only the devs would rotate that role among themselves.”

First off, I said that some technical and domain knowledge was necessary to understand the team, to integrate more effectively. Secondly, all those roles you mention do not exist on an Agile team. We’ve got developers, that’s it.

Now that I’ve been probably too anal with my reply (sorry about that) let me agree with you a bit.

What I’m talking about is applicable in reality mostly to smaller teams. In larger teams, yes, people tend to clump into little groups: testers, DBAs, UI folks, etc. Even if everybody is perfectly cross-trained, it’s still natural for people to want to do the stuff they like. In larger teams, say 7-9 people (or more), perhaps you have one person who has such great people skills that he would make the perfect ScrumMaster. Great! Let him have it. I’m not saying you have to rotate. I’m saying you should be able to rotate and that rotating the role gives you a lot more benefits that most people realize. Give it a shot.

On several (too many to count, really) occasions I’ve seen ScrumMasters develop a “The team is not doing what I want, therefore it isn’t Agile” attitude. I’ve seen retrospectives where the team tries to correct the ScrumMaster but he just ignores them. In short, I’ve seen a lot of “I’m special because I’m the ScrumMaster” going on — it’s not a healthy thing. Everybody is in this together. The team is more important than the processor the ScrumMaster.