This year, I’ve had the opportunity to work with agile teams across a couple of different companies. Whilst Alfresco and Marks and Spencer work in different industries, both have adopted agile as their way of working. To help teams deliver, both employ full-time Scrum Masters, and at both companies, most agile delivery teams use Scrum, complete with all the ceremonies, to deliver software.
Seeing the way that both development teams work over the course of the year, I’ve begun to wonder whether the role of Scrum Master is actually harmful. To be clear, I’m not saying that the people in these roles are bad people, rather that by employing a full-time Scrum Master, you are unconsciously locking yourself into a particular development methodology.
The Scrum Guide defines the Scrum Master role as:
“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”
Embedded in this definition is the assumption that by employing a Scrum Master, that you have someone who’s responsibility is to guarantee that your teams are adhering Scrum. This person ensures that teams are following the Scrum practices (estimating, burn-downs) and operating within the confines of the Scrum framework. The Scrum Guide adds this restriction when discussing the use of retrospectives (emphasis my own):
“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.
For some teams, other development practices or frameworks are more appropriate. For example, it may be more appropriate for a team to use Kanban when more flexibility is necessary, or when teams of specialists exist.
Unfortunately, over the past year I’ve seen teams cargo-culting Scrum in their teams, and it’s my hypothesis that having a role of Scrum Master is partly to blame for this. It becomes hard for a team to challenge Scrum as a way of working, when a person they work with every day holds a role that is solely there to employ Scrum. A vote against Scrum can be seen as a vote against this person. This results in the team continuing with practices that don’t help them to deliver software in their context.
The good Scrum Masters recognise that the job title is just that, and that it shouldn’t unduly influence the way the teams work. However, this can’t be said for all. Challenging Scrum as a framework is seen as questioning their validity, and so they act to defend all aspects of the framework. It’s in these cases where I consider the role of Scrum Master to be harmful.
Of course, it could be that the organisation wants to use the Scrum framework, whatever the implications. This doesn’t feel right to me, as it’s at odds with the ideas behind the agile manifesto, in particular “people over process”. In these cases, further inspection is required to understand why an organisation is so hell-bent on implementing Scrum. I’d wager that in many cases it’s down to a lack of understanding of agile development.
So, what is the alternative?
I’ve talked this through with a couple of colleagues, and others in the software industry. GDS steers away from the Scrum Master role title, instead using the role “Delivery Manager” for providing team support, and developing team efficiency. If job listings at NotOnTheHighStreet, Co-Op, ITV and ASOS are anything to go by, then other teams are taking a similar approach.
I’ve not worked with a company that uses this approach, so I can’t comment on what impact this change has, or whether this title change has other unintended consequences. One of my concerns would be the introduction of another “Manager” role (to add to Engineering Managers) into the engineering organisation.
Would M&S and Alfresco operate better after just changing the job title of a few people? I think it’d send a good message (we’re not tied to Scrum), however I think it’s just one aspect of a change in culture that’s needed. After all, the same people will still hold these titles, and if these individuals see Scrum as the one true way, then it’s unlikely to have the necessary effect to improve team performance.
Another alternative is to remove the role entirely, and have the team self-organise around the work. Operating in this mode requires engineers that deeply understand how what they do fit into the wider business, and have the necessary skills to introspect and improve. Many teams can’t do this effectively without support.
Finally, there’s the approach we took whilst at eBay. Some teams had Scrum Masters, yet it was a hat a developer wore rather than a dedicated full-time role. For some teams this worked really well, however for most the Scrum Master role was seen as team secretary and as such wasn’t a hat many people wanted to wear.
The right approach for your organisation will depend on your context and the goals you’re trying to achieve. I don’t think that there’s a single way of solving this issue, however I’m also pretty sure that unless you are unreservedly dedicated to the Scrum framework, that the role of Scrum Master can have unintentional consequences.
The titles that individuals take on in your organisation will influence the way you work. I’ve described the effect the role of “Scrum Master” can have on the way a team works, and the (sometimes) unconscious decisions we’re making by employing people into this role. It’s a widely known idiom within software development that “naming things” is one of the two hard problems in computer science. We’ve seen here, that this not only applies to code, but also to people within your organisation.