Great idea: save on the Scrum Master!
You can’t count how many times we hear this idea: one of our developers will be 50% Scrum Master and it’s done. We’ve even heard 10%. Problem solved. We don’t have to deal with the hiring and training of a separate Scrum Master, our Scrum Master will develop as well, we can have our cake and eat it too. Genius!
Really? Why did the creators of Scrum consider the Scrum Master as a separate role, didn’t they think of the above brilliant idea?
Let’s do some maths. Let’s take an average team of 7 people. Add a 50% developer / 50% Scrum Master. The maths says that this increases the team’s performance by 0.5 people, 7.5/7 = 1.07 times, or 7%.
But does the maths really add up? There are two problems with this:
1. If someone is 50% assigned to a task, they will not achieve a 50% result
…but much less because of the loss of focus and the constant multitasking. Moreover, the half-finished job is most often not worth 50%, but nothing. It is not finished. In other words, it is almost guaranteed that if this person really gets 50% of critical workload, he will be the slowest, he will not help but hinder the team. Who should intervene in such a situation? Well, the Scrum Master! The person who is really busy, because he is the one who should be helping. Even if his job is to improve performance, he will not have time to do this and his own performance as a developer will be far below expectations.
2. The primary task of the Scrum Master is to continuously improve the performance of the team.
The 7% in the above example is a very poor result for a Scrum Master, who at 50% capacity is good if he can handle the basic administrative tasks and facilitation, leaving no time for the team or his own development. When Jeff Sutherland, one of the inventors of Scrum, gave the title “The Art of Doing Twice the Work in Half the Time” to his book about Scrum, it was not just a marketing ploy. He meant it. In theory, up to four times, or 300%, more performance can be achieved with Scrum (in practice, unfortunately, it is rare because of “let’s do it smart” solutions like the one above), but there are examples of even bigger leaps.
Let’s do the maths again. In the example above, if the 7 people each produce 100 units of value, or 700 units in total, adding a catalyst person who does not produce value directly but increases the team’s performance by 15%, that’s 7*115, or 805 units of value, a bigger increase than adding a new developer, and well worth it. And a moderately good Scrum Master can do much more than that, even partially successful agile transformations can be expected to typically increase performance by 20%-50% (Source: Scaled Agile Inc., SAFe, Why do Businesses Need SAFe?, 2018).
So should we save on Scrum Master?
So before you make the decision to save money on Scrum Master, it is worth considering the above. For small teams, a full-time Scrum Master may indeed be unnecessary, but even for a medium-sized team, we are already killing the golden goose if we don’t let the Scrum Master focus on increasing the team’s performance. In addition, we often see the best developer on the team being appointed Scrum Master, pulling the rug out from under him in terms of development, while he has no time and energy to act as a catalyst for the team.
Think about it, is the Scrum Master doing development work for you too? If so, does he have time to develop the team itself, or does he only perform secretarial duties? If not, is he really acting as a catalyst for the team, does he understand that this is their main role?