This is a discussion I hear a lot. The Scrum Guide has a list of duties that a Scrum Master performs, and while it is not clearly stated that it is a full time role, it is quite clear to me on reading it that it is intended to be. This is my least favourite motivation for why to do something ”Because Scrum says so”, so let’s look at this question a bit more in-depth and decide if you need a full time role?
What does a Scrum Master do?
The duties and activities of a Scrum Master are many and varied, they will take on different forms depending on what the organisation needs at that point in time. So, listing everything a Scrum Master does would be a very long list indeed. So, for the sake of simplification I am going to break it down to one central responsibility:
”A Scrum Master helps to facilitate change and improvement.”
People have a natural tendency to focus on the here and now, and things that need to be solved today, they focus on things that are urgent (time sensitive tasks) but not things that are important (not time sensitive but often more valuable). This is why we have the role of the Scrum Master in Scrum, their job is always to focus on the important, while the team is often occupied focusing on the urgent. While your team might be focusing on implementing new features, a Scrum Master focuses on how we improve our requirements handling to make sure they are easier to implement the next time. While each team member focuses on their own coding, a Scrum Master focuses on how we can help the work together as more of a team, so they can swarm problems rather than fix their own tasks.
We cannot afford a full time Scrum Master!
I think it is looking at the question completely backwards, the question we should be asking ourselves is ”What is the return on investment of having a full time Scrum Master?”
To demonstrate this, I will use some very simple back of the envelop math, nothing scientific just a quick calculation.
The maximum size of a Scrum team is 9 people. Add to this the Scrum Master and Product Owner makes 11.
For the purpose of this calculation we will assume everyone is paid the same.
In this calculation we will use the term ”Improvement” to indicate both efficiency and effectiveness gains.
So, the question is ”How much of a recurring improvement does a Scrum Master need to facilitate to have a justifiable ROI?”
Team time / team size = required improvement
100% / 11 = 9.09%
So, a Scrum Master needs to find and facilitate an improvement of 9.09% in order to break even week after week. Everything over and above that is money in the bank!
Now the question becomes, “Can this person truly find that much of an improvement?”
Some example improvements
As I do not always precisely track my work, these numbers will be fairly rough, but I think enough to show my point.
One of the most normal situations I encounter are teams who are having long and unproductive sprint planning meetings. I find the simplest way to counter this is to have regular refinement meetings where we look at the product backlog and mould it in to usable shape. My previous team was having sprint planning meetings that went on for at least a whole day. After instituting a regular refinement meeting (1 hour every 2 weeks) we were able to shorten that to at the very most 2 hours (often much shorter).
So, we had saved the team 44 hours a month. Or a 2.5% improvement.
This doesn’t even count the less measurable benefits of higher quality output, better requirements, and a happier, more engaged customer.
Poor quality is a huge source of waste in companies. Bugs are occurring in production, which require immediate attention. The team need to interrupt its ongoing work to focus on fixing the issue. The problem with this is, when an immediate fix is needed the natural human behaviour is to address the symptom instead of the underlying cause. So, we do nothing to prevent the bug from reoccurring the next time and eating more of our time. An experienced Scrum Master will catch this, and work to visualise these issues so that patterns can be found and the most costly issues can be addressed by the team.
Let’s say you get 10 bugs a week, and each disrupts your day for 1 hour (both pretty low estimates in most teams I encounter).
If we identify, and fix the root causes instead of the symptoms, we saved 40 hours a month. Or 2.27%.
Once again, this does not count the less measurable benefits like more satisfied customers, code bases which are easier to work with, preventing technical debt which comes with a maintenance cost, and less cost of task switching.
Helping the entire team pays back fast
These are some fairly simple examples but I think you are starting to get the idea: when you help the entire team, it starts to pay back very fast. And in my experience, the biggest improvements happen in those less tangible areas I mentioned. For an experienced and dedicated Scrum Master, 9.09% is easy!
Can’t this be done in a part time capacity?
So, we are able to demonstrate that a Scrum Master is able to pay for their role, but does this mean they NEED to be full time in order to achieve these results – could they not do the same work in a part time capacity?
Well, yes and no… Or, as they say in Sweden, Nja…
I am not saying you won’t get some value out of a part time Scrum Master, but, facilitating improvement is not work that can always be planned and actively executed. It often involves being around at the right time, or even if you are around, in the correct mental state to identify the opportunity and act on it. As mentioned earlier, someone needs to focus on the important, not just the urgent, because urgent is always treading water, important is where we move forward.
So, ”Can we do this in a part time capacity?” I think is the wrong way at looking at the question. Instead you should ask yourself:
”How much do we lose every time an improvement opportunity is missed?”
With this in mind, I think the central question is not ”Can we afford a full time Scrum Master?” but ”How can we afford NOT to have a full time Scrum Master?”