Master of the Scrum Dungeon

I was talking to a team mate the other day about why I don’t like Scrum Master as a job title rather than a role, and specifically why I think Scrum Master is not a full time role but something a member of the team does alongside their ‘day job’.

I’ve often been Scrum Master on a team but I’ve always been contributing in one of my other skills at the same time. This is a bit like the concept of ‘multi-class’ characters in Dungeons and Dragons (whoops my ‘geek’ is showing again!) i.e. you can be a Fighter-Wizard and take on the characteristics of both.

Most frequently, I’ve been Developer-Scrum Master in a Scrum team. My primary tasks, the ones I spent most time doing, were development activities. However, my Scrum Master duties trump those and I drop everything to remove impediments, escalate issues, facilitate ceremonies, etc. as these impact the whole team not just my tasks.

I feel this works well because, in a healthy self-managing, self-organising, multi-disciplined team a Scrum Master role is NOT a full time job.

The issue with making Scrum Master a ‘job’ (the only thing you do) is when there are lots of problems, impediments, etc. it takes up your time BUT when the team is functioning smoothly you’ve very little to do most of the time (15 minute stand up per day, 15 minutes updating/reviewing burn down…eh, what now?). SO, this leads to one of two behaviours:

  1. Scrum Master disengages and wanders around talking to team members about irrelevancies as they’re bored, thus interrupting team work,
  2. Scrum Master introduces more ceremony, detailed reports, more meetings, more detailed estimates of future stories that may not even happen, allocating tasks to team members rather than allowing self direction, more detailed plans that need rewriting regularly to cope with change. All this ceremony adds overhead and, although the Scrum Master is busy, it sucks in other team members and prevents them doing ‘their day job’. This is waste and inefficiency of the highest order.

The second reaction is the more common, especially when traditional Project Managers become Scrum Masters as they often feel the need to fill the void with all those comforting spreadsheets and documents they used to use.

The full-time Scrum Master subconsciously wants the team to be disfunctional! If everything is going smoothly they can’t justify their existence. They have nothing to escalate, no blockers to remove, everyone is allocating their own tasks, solving problems together, calling their own meetings spontaneously when required and not holding meetings for the sake of them.

Contrast this to the Developer-Scrum Master or Tester-Scrum Master behaviour. They understand the need to drop their tasks for the good of the team to put on the Scrum Master hat (I’ve actually had one of these in a team before!). However, they are focussed on delivery. They want to get the Scrum Master bit out of the way and get on with the task at hand. Yes, they need to escalate an issue to management, then they need to go back to work. Yes, they need to follow that escalation up but the team won’t let them forget as they are presumably blocked waiting on this to be fixed (peer pressure is a great motivator, unless you’ve a sociopath for a SM!). So they tend to do ‘just enough’ Scrum Mastering, as dictated by the team.

So the moral of this story, for me, is (as I’ve actually shouted across a crowded office at recruiter friends of mine!) “SCRUM MASTER IS NOT A JOB!”