Process

The Dedicated Scrum Master Role

After reading a discussion about whether having a dedicated Scrum Master is an effective way of running a team, I got to thinking about what I have experienced in the real world. This is an empirical point I’m about to make; I’ve worked with a good number of organisations, but not enough to get to the point of thinking my sample is representative of all organisations. I’ve worked entirely in the UK and there has been a big bias during the hook-ups (i.e. I’m very clear that I’m looking for the right culture, I want the organisation to be aligned to Theory-Y rather than Theory-X, and they are usually interested in Agile or Lean).

So, with this in mind, here’s how the picture looks. I’ve worked in roughly equal numbers of organisations with and without a dedicated Scrum Master role. The short version is that where I have found Scrum Masters, I have found they cause more problems than they solve. That split of three roles causes problems (Technical, Business, Scrum Master), and the Scrum Master role often appeals to the wrong individuals. In particular, the role is highly desirable to people who subscribe to the theory that either the technical people, or the business people, need to be corralled into delivering.

Empirical Scrum Masters vs Not
See my side note!

The result, within the confines of my own limited experience, is that teams seeking agility without a formal or dedicated Scrum Master are more consistent with the actual Agile Manifesto and principles.

In theory, though, having an experienced Scrum Master (or Coach) with the right skills should result in the whole organisation becoming more effective. So, what’s going wrong? Quite simply, it’s the mismatch between this expectation of the role, and the individuals selected to undertake it. I’m not commenting on whether these people are out there; I’m saying that they either aren’t applying, or they’re not being accepted. This is especially problematic for organisations that are (late) adopters of Agile or Lean process. In every late-adopter case I have been personally involved in the Scrum Master role becomes the device used by the dominant culture to protect itself from change. Or, more simply, the Scrum Master role in these organisations is specifically used to subject the other roles to command and control methods.

This is, I suppose, exactly what you’d expect. One of the early epiphanies came out of Extreme Programming (XP), which sought to make software development safe for programmers. This is transformative for programmers in dated cultures – but the shift in the balance of power is not easily undertaken or achieved. Another of the principles uncovered within XP was that business people make the business decisions and technical people make technical decisions. This works. I’ve seen it applied successfully several times. Having another role outside of this two-role system dilutes this clear separation of responsibility. Where a great coach will help teams uncover this principle, a bad one will want to carve off sections from both sides to add tangible weight to their role.

In summary, while the Scrum Master role works in theory and often has some benefits even in dysfunctional cases, the role is most often a net-negative.

Side Note

A quick note on my diagram!

You may have spotted that the third circle “Organisations Consistent with Agile Manifesto and principles” should have zero area outside of the other two circles, as those two circles represent 100% of organisations in the sample. I couldn’t satisfy this without making the labelling troublesome.