I Killed The ScrumMaster (And Why He Had It Coming)

Death of ScrumMaster

Them there is fighting words!

Yesterday I was asked by a client about how to optimize a team that was already doing very well.

Without having to think twice, I immediately knew the answer.

“Get rid of the ScrumMaster”

Why? Was the SM doing a bad job? Nope, they had an awesome SM. Was the SM confused with a PM? Maybe a bit, but no more than normal.

Here’s the thing: after watching dozens or hundreds of teams try to be Agile and be all nice and Scrummy, I keep coming back to one thing: having a special person who only does SM duties is like having a person who only does database work, or a person that only works on the UI. It just doesn’t fit into a cross-functional team experience. Worse yet, it starts creating a wall between the developers and the rest of the organization.

It wasn’t meant to do any of that, but it does.

I’ve long thought the SM role should be rotated among the team members, and the more Scrum teams I work with, the stronger that feeling. I see an entire industry sprouting up around “being a leader in your team” and the implication is clear: the SM is a leader, they’re a sheep dog, they’re a facilitator, they’re expected to have special people skills.

In other words, the ScrumMaster is just the 21st century version of the Project Manager.

Only it gets better! Back in the old PM days, if the team didn’t perform, you took the PM out and shot him (figuratively, of course). Maybe then you moved on to decimating the team itself. The PM was always responsible when things went wrong. Nowadays, the modern SM has completely dodged that part of the job. Team not doing well? Hey, we’re Agile! That means the team is in charge. If the team isn’t doing well, dang it, it’s the team’s fault! I’m just this leader facilitator guy. Can’t help it if you give me a bunch of schmucks to work with.

Don’t get me wrong: I firmly believe in team accountability, and the team has to own and deliver in a sprint. It’s just that the ScrumMaster role is also part of the team, yet it occupies some kind of weird place where it’s also supposed to be a champion for the process.

Bah.

I will now share with you the dirty little secret of technology development that everybody knows but nobody wants to admit: it’s much easier to take a developer and add on some social, management, negoation, or other skills than it is to bring in an expert in those skills and have them amount to anything useful. We’re treating ScrumMasters as if they’re some kind of end to themselves. They are not. They simply have some special things to do on a sprint. Any developer should be able to do these things. After all, your team is working in a co-located manner, right? And you all get along with each other — heck, you sit right beside each other! Developers are pretty good at counting, are they not? And who can’t make a couple of line graphs?

Nope, the ScrumMaster job needs to be rotated among the team. Everybody should have a turn. Kill the idea that there’s some special guy, special skill, and special technique that’s involved. It might help sell a lot of training classes, it might give something to do to all those folks in your organization with those PMP certifications, but it’s not helpful to the team or to the value stream.

And don’t get me started on the problems with the Product Owner role :)

Enjoyed this? Check out the video follow-up done later that day.


Follow the author on Twitter

October 24, 2013

8 responses to I Killed The ScrumMaster (And Why He Had It Coming)

  1. Oh, go on. Get started on the problems with the Product Owner role. :-)

  2. Michael Kutz said:

    Nice article. I agree with most of what you write but in my projects the SM was responsible to moderate meetings and was generally a quite helpful as a neutral person at hand when two team members had a problem with each other. However at some point he/she git less important since we were running into less problems — so I think you got a point.

    I think you are right as we may get rid of the SM once the team got into a performing state, as long as it is not having an SM might be a good idea.

    • admin said:

      I hear you. I think people need to do that. Nothing wrong with asking one person to do it. Just like there’s nothing wrong with asking one person to handle all the JSON, or be the CSS guy.

      Back when we did Agile but had folks on the team we called Project Managers, we’d just vote on some poor guy to be the “official” PM.

      There’s also always going to be a role for helping teams get started. Is that a SM? I don’t know. Perhaps that was the original intent: somebody to help out with reinforcing the process enough until the team took complete ownership.

      But heck, that’s sure not the way the actual role is playing out.

  3. Tobias Mayer said:

    Seems you’ve had poor experiences with scrummasters. If I had those same experiences I’d probably fire them all too. Happily I’ve worked with some amazing people: daring, blunt, confrontational, ideaful… people who see what others do not, and call it out. People who know how to bring dysfunction to the surface. People who speak truth to authority.

    Sadly, too many misunderstand the role. Killing it though, you’ll likely lose more than you even know could occur.

  4. Kyle said:

    Yeah this is absolutely right – ScrumMaster should not be a full time job. If there’s enough work to make it a full time job – you’re Doing It Wrong(tm).

    And I love the comparison to other horizontally oriented tasks – does CSS by itself deliver customer value? No. Does creating a burndown chart by itself deliver customer value? No.

  5. Sounds like you’re describing the ScrumSecretary role :) . Certainly, that doesn’t take a special person to do and that stuff should certainly be spread among the whole team. But there is much to being a Scrum_Master_.

    When a team becomes competent, most SM’s today don’t have the skills and understanding to keep being a useful ScrumMaster. The team no longer needs training and support to operate as a self-organizing unit (i.e. they are solidly in the Norming stage). What is the SM supposed to do? If that person doesn’t stay one or two steps ahead of the team, they can no longer contribute to the growth of the team and will become a drag. At this point, it’s either step up or step out.

    Real ScrumMastery isn’t about doing things for the team. Yes, a SM may (and usually does, especially in the beginning) do secretary stuff for the team, but the point is to train the team to take care of such stuff themselves (i.e. they don’t need a manager, they manage their own work). What a real SM is responsible for is the formation of an environment and team behavior that allows the team to deliver exceptional value. As the team picks up their skills, the SM will extend outside the team and start influencing there so that the blockers that prevent the team from delivering get removed (organizational change agent). The SM will also “hold a mirror” to the team, so that they can take notice of their less constructive behavior and seek improvements together (observing the patterns and visualizing information). They also need to protect the team since often members of high-performing teams are highly desired people by other managers.

    I’d say, less than 10% of current SM’s have the level of skills and understanding to be great SM’s. That’s why it is so common to see SM’s who are not all that useful to the teams and the organizations they work with.

  6. Just to emphasize my previous point and link it with the post, sounds like the SM in question wasn’t an awesome SM (probably was a good one, and an awesome person), and had run out of being useful to the team. So probably moving that person to a new team and letting this team work without him/her was definitely the best approach. Then again, maybe that SM could’ve been helped to become a great one (and get rid of e.g. those PM’ish habits).

  7. John Steele said:

    I can see your argument and accept that a high functioning team might be able to function without a dedicated ScrumMaster in the short term. In some respects, having this as a goal could even be held out as an ideal, much like Self Actualization is in Maslow’s Hierarchy of Needs; a goal we might strive for but few achieve.

    However, the reality of team dynamics suggest is it much more efficient to make one person responsible for clear and regular communication to the larger organization, consistent in format, presentation and purpose with every other team.

    High functioning teams, by definition, should be able to not only deliver on their commitments sprint in, sprint out, but also use Story Points to predict their “carrying capacity” through the period between releases. (Assuming the team don’t release after every sprint, but only after a series of sprints.)

    Again, this is a function that could be handed to another team member, but in my experience is rarely considered as important by rank and file developers who simply want to be left alone to code. In other words, your suggestion might work in small shops with frequent deliverables where the ScrumMaster is simply the team’s Administrative Assistant. But it will not scale to the Enterprise, with dozens (or hundreds) of teams where consistency, communication and predictability are prized.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>