5 Whys is a blog about technical leadership in the software world.

Scrum Master 2.0: A Scrum Master is Not

I'm a big fan of the idea that you should grow your team to be self organizing. I also used to hold the idea e that a Scrum master is just another word for "team coach", that should grow their team. I felt that people who say that Scrum masters should guard their teams from outside interference would be doing a disservice to their team, because they hold them back from learning and growing new skills needed. I felt that scrum masters who protect their teams become bottlenecks, and they do. 

But in the past couple of years I've had some interesting discussions with some of the original Scrum Folks (Especially Martin Devos) and what most of them seem to agree on is this: Scrum today, and the Scrum master role as it is taught, is very different, and less effective, than the original intent of the role.

This has been gestating in my head for a few months, but I think that now I see this weird role like this:

A Scrum Master is not:

  • A Team Leader
  • A Tech Leader
  • Permanent
  • A Coach

 

A Scrum Master should be:

  • A constant role that is temporarily held by a person (weekly or even daily basis) 
  • Fulfilled by all members of the team, in turn, in cycles, so that they learn to deal with outside interference and grow their skills of working within an organization
  • The person that does all the "dirty day to day minutia" that keeps the team from doing their stuff (paperwork, meetings etc)

Notice that the key factors for an effective scrum master are that they are not one fixed person, but a role shared and cycled through by all members of the team. This way you get the following benefits:

 

  • They are not a bottleneck, since each member of the team should be able to perform this function (or learn in the process of doing)
  • They save the team from unneeded red tape and delays by having one person take all the "heat" for a week, then moving to the next person.

 

So why is this so different than what many today say?

I'm not sure. I think somehwere the idea of "rotating" got lost and we were left with "fixed role". 

Then, many people, me included, tried to reconcile the notion of a self organizing team with a fixed scrum master (a bottleneck! a bus factor!), and the only way that made sense was if the scrum master was indeed taking the role of a coach or a team leader, growing and pushing the team out of its comfort zones. 

On top of that were all the extra "bonuses" of being in charge of the process and other weird business. I'm really not sure where that stuff came from, but it's really really weird. 

Funnily enough, if you go down the rabbit hole of a leader\coaching SM making themselves unnecessary, you might come in the end to the point of this post: That a Scrum Master will ask their team to do his/her job , weekly in cycles, so that they learn that set of skills.

So, my current way of thinking:

  1. If you are about to decide who will be the team SM, don't choose anyone. make them a all a SM, on a week by week basis. 
  2. If you are a fixed role Scum Master (that is, there is only one person assigned), you do need to become the coach, and get everyone to cycle through your role in dealing with red tape and outside interference.

A Scrum Master 2.0 is really the Scrum Master 0.1 in its most basic form. 

A Value System for Code Reviews, and How to Scale Them for a Large Project

3 Reasons to stop solving other people's problems for them