Scrum Master Allocation: The Case for a Dedicated Scrum Master
Your business has limited resources. You want to get more done, faster, for less money. Where should you cut back, and where should you invest? One popular answer is, cut back on scrum masters.
Why cut back on scrum masters? Managers have limited headcount, and are looking for ways to stretch their budgets. Scrum masters are often not actually writing code. The functions of the scrum master are seen as supplementary, non-essential, and therefore fungible. Many organizations spread scrum masters across two, three, or even more teams.
Teams are able to function without a full time scrum master, once they understand the basic agile process. The question is, what are those teams missing out on, that they could have had with a full time scrum master available to them? In other words, could you be incurring costs of productivity and delivery benefits if your team doesn’t have focused scrum master support?
Time for a sports analogy
I could easily make a case that your favorite sports team would also function without a full time coach, once they understand the game. But I bet you would never want to see your team without a full time coach. Why is this true? These athletes have been playing the game since they were children, honing their skills, strategies and understanding. What value does the coach add? Why not let the team be self-organizing? Or let the team captain take the role of the coach, as needed?
An experienced scrum master, like an experienced sports coach, has the wisdom and knowledge that comes from working with teams over a period of time. They’ve “seen it all before”, or at least a lot of it – and if they are in a network of agile coaches, they have access to insights about things they have not seen as well. They concentrate on knowing how to practice agile well, and how best to deal with impediments (whereas your team is focused on how to write software well, how to test it well, how to make it run fast, etc.). The team relies on the coach’s understanding of agile when they encounter new territory. The scrum master is with the team, observing them, proactively scanning for and resolving impediments, and inserting coaching and mentoring where they see a need, even when it may not have been requested.
Another thing a good scrum master has is coaching skills. Coaching is actually a skill, an expertise, of its own. In its pure form, it is the act of enabling individuals and teams to first see themselves clearly – what is happening, what impact it is having, and how they themselves are complicit in it.
The next step in coaching is to find the best solution by facilitating a discussion where the team themselves determines a solution – something they buy into, can deliver on, and will support ongoing. It’s all too easy – and most people’s instinct – to dictate a solution to the team, and then sigh and shrug when “they just don’t listen”. A skilled coach will get results by deriving the solution through the people who must implement it, thereby getting stronger buy-in and follow through. The coach also preserves the team memory for what was agreed to, and ensures they hold themselves accountable. The result of all of this is a much better likelihood that problems will be solved, and that they will be solved faster.
Like players in a fast-paced game, a development team does and should get caught up in the moment. They are focused on the goal; they are in the middle of the action. Like a sports coach, the scrum master stands on the sidelines. Not jumping in and playing the game, but engaged and attentive to everything that’s going on, both within and around the team. The Scrum Master has the ability to get the 360 degree view, a perspective that
- is (ideally) unbiased and non-judgmental,
- can help the team get a better understanding of their situation and the alternatives available to them
- can be working proactively to prevent bad things from happening
Even just constantly asking the team, “what’s blocking you?” to reveal opportunities to speed things up makes a difference, since developers often are too overwhelmed or aren’t conditioned to reach out for help. As a trusted, engaged, but non-participatory ally, the coach can support the team in a unique way. (But, if the coach misses half the action, their effectiveness in this respect is hugely diminished!)
Software development teams generally catch on to the mechanics of the scrum process after 3 - 6 sprints, if they are properly trained and guided. They all know what Stand Up is, the three questions they’re supposed to answer, what to do at the demo, the outcome needed at sprint planning. But maintaining this over time takes dedication, and fortitude. When impediments arise, it’s easy for these practices to go off course, or backslide into “scrum-but”, without an agile leader to course correct. Even if the basic process is adopted properly and gels, there are lots of additional practices above and beyond basic scrum that teams would benefit from adopting: continuous integration, test driven development, pair programming, dev ops, etc. The coach’s role is to bring these challenges to the team when they’re ready and help them through the changes they need to make. Change is always hard. It helps to have a coach.
Of course, a team will always improve on its own, if it’s using agile methods to inspect and adapt. That’s one of the great powers of agile methodology – the continuous improvement is built into the process. Similarly, a sports athlete will also improve on their own if they continue to train, inspect and adapt their skills. But how much faster can that athlete, or that development team, improve and progress with the skills and attention of a qualified coach at their disposal each day?
And when the Scrum Master’s away…
Sure, a team can function when the scrum master absent, and most of them do. They do the best they can in their circumstances. Often, one of the team members steps up and takes on the functions that the scrum master would have done, to the best of their ability. And what’s wrong with that?
Well, nothing’s wrong with it; but having the scrum master there would have two benefits.
- The team would probably function better
- They will probably overcome obstacles faster, and
- The time and effort that team members spend compensating for the absent scrum master, can be applied fully towards completing the work in the backlog.
To compound the problem, when the scrum master’s engagement with each team is part-time, they become less effective in performing their role for any of their teams.
- They can’t respond in a timely manner to teams’ needs.
- Context switching between teams decreases their efficiency – context-switching costs an average of 20% productivity.
- They don’t have bandwidth to orchestrate process improvements.
- They are often the last to know about what’s going on.
- It becomes impossible for them to track the details of the stories and tasks the team works on – so they lose fluency with the work in progress.
- They don’t get to observe the nuances of the team’s interactions. So they are unable to offer specific guidance or the most effective coaching.
As a result, the organization around them then begins to question the scrum master role, perceiving it as ineffective or of little added value, because they observe nothing but scrum masters whose impact is impaired by being spread across multiple teams.
My team is already hyper productive!
Maybe you have a team that is already performing at peak efficiency, and using full on XP practices. Is there still value to having a dedicated scrum master when you’ve gotten to that stage? Again, my position is, yes. Let me ask you this – for how long will that team be kept intact as-is? Rarely do real world development teams go unchanged for more than a few months at a time. Resources get added, moved around; people move on to other companies or retire.
The team dynamic is a delicate machine that gets tuned to the specific individuals who have come together to form the team. Changes in composition of the team, therefore, have a significant impact on team dynamics, and thus the ability to be productive. And even if the team itself stays intact, the environment around the team will inevitably be in a constant state of flux, presenting new challenges for the team to cope with.
Organizations are made up of human beings, and human interrelationships are inherently dysfunctional, at least to some degree. The extent to which that inherent dysfunctionality impacts delivery of value to your customers depends on how effectively your team can manage it. Providing a coach for the team gives them a definite advantage in managing dysfunction.
Another concern that may be raised about dedicated scrum masters is one of utilization. Consider a dedicated scrum master working with a team that understands the process and is pretty productive. You would probably determine that the scrum master is only busy doing scrum master work 50% of the time. Perhaps even less! It seems quite reasonable, then, to give that scrum master a second team to work with. They can clearly handle the additional load.
In his wonderful book Slack, Tom DeMarco explains beautifully why the question of utilization is not as simple as it seems. In the case of the dedicated scrum master, the scrum master’s *availability* is a significant asset to the team. If the team needs something, the scrum master can respond immediately. When the team has an impediment that they need help resolving, the scrum master can get right to work on it. She doesn’t have to say, “ok I’ll get to that in a couple of hours when I finish doing sprint planning with my other team”. Having that availability means that the team’s needs are dealt with swiftly so progress can move forward. Problems that can be dealt with in the moment will prevent the team from suffering the inefficiency of context switching or sitting idle when they hit dead ends.
As an added benefit, this availability also sends a message to the team that the organization supports them and believes that it is vital to keep their progress unimpeded. This message of urgency and commitment resonates and the team redoubles their own efforts to make progress. If the message is, “yeah, we know you have a problem, but you’ll have to wait”, the implication is that it’s ok if time is wasted. This attitude will inevitably get reflected in the team’s level of dedication.
The rest of the scrum master’s time should not be considered unproductive. As mentioned above, the scrum master is actually busy observing the team. They may also be quietly working on potential improvements to their processes, tools or environment. If desired, the scrum master can assist with some of the team’s tasks, time permitting. Pairing with or working alongside members of the team gives the scrum master even greater insight into the challenges the team faces. They may uncover practices that the team has been taking for granted, but which can be simplified or eliminated. However, the team should never rely on scrum master commitment to working the stories in order to deliver on their sprint. The scrum master’s priority is to play the scrum master role, and that role pre-empts any other work they may take on.
Where are the numbers?
It would be great to see some numbers behind this dedicated scrum master benefit, wouldn’t it? How can we determine what is the best approach for the organization?
When scrum masters are split across multiple teams, it’s easy to understand how money would be saved:
Cost savings = (scrum master hourly salary * #hours) * (number of teams served -1)/ number of teams served
So, for a scrum master who makes $50/hour serving 2 teams over a 2 week sprint,
Cost savings = (50*80)*1/2 = $2000
The cost, however, is harder to understand.
- It is the impedance to progress and improvement that the team suffers.
- It is the effort and time not applied to the completion of backlog items when team members are being scrum master surrogates.
- It’s the loss of the additional productivity that a scrum master might have obtained from the team by coaching them to implement improvements.
- It is the lost ROI from having features in customers’ hands sooner as a result of higher productivity.
To calculate lost productivity, we can use the following formulas:
H = # hours spent to produce a deliverable
Productivity = unit of output/hours spent
Cost of the deliverable = (H * hourly salary for the team) + (#hours of scrum master time * scrum master hourly salary)
If productivity increases by 5% with a dedicated scrum master, then the amount of hours spent to achieve the same deliverable H’ = H /1.05
So the cost then = (H’ * hourly salary for the team) + (H’ * scrum master hourly salary)
To determine the impact of lost productivity in our previous example, assume
- The hourly salary of the team is $50/hour for 7 team members, or $350
- The scrum master is split between two teams, and
- The deliverable takes the team one 2-week sprint.
H = 80
Cost with shared scrum master = (350*80) + (25*80) = $30000
Cost with dedicated scrum master for the same deliverable = (350*76) + (50*76) = $30,400
Which is comparable to the cost when sharing the scrum master!
In the above example, we have almost completely offset the cost of having a dedicated scrum master. But we are not finished yet. The revenue stream from the deliverable can now be realized H-H’ hours sooner. There will be a corresponding increase in ROI, which can be calculated using a spreadsheet (if you’re like me and your eyes cross whenever you look at discounted ROI calculation!). In addition, the faster time to market realized by this improvement may be essential in highly competitive or seasonal businesses. Thus, there are certainly many projects where the combination of decreased development cost, increased ROI and faster time to market achieved through the attention of a dedicated scrum master will more than offset the scrum master’s cost.
How much productivity improvement can be gained from dedicating a scrum master to one team? Unfortunately, I don’t know of any studies that have been yet conducted to determine this. 5% seems like a pretty fair and conservative expectation, though much greater improvements should be achievable, particularly with inexperienced teams. It would be great if an organization with a large agile implementation or the maker of an agile management tool could gather data comparing the productivity of teams with dedicated vs. shared scrum masters, so that we could make more than a wild guess about that number.
One of the most powerful and frustrating aspects of being a scrum master is that if you do it well, no one notices you doing it. Good scrum masters can have a significant impact on the productivity of a team when they are
- experienced agilists with coaching expertise
- fully available to respond immediately to issues
- able to observe and tune into the nuances of the team’s interactions
- able to take the time to understand the work that the team is doing in detail
- not too busy to focus proactively on continuous improvement on behalf of the team
What we also can see is that the additional cost of dedicating a scrum master may well be entirely offset by the increase in productivity that they can derive. The cost offset comes from three sources:
- reduced development cost,
- faster time to market, and
- increased ROI.
More study should be devoted to the productivity impact of scrum master allocation based on empirical data. This would allow organizations to make better decisions regarding how many scrum masters they should allocate to their teams to drive the best chance for project success.
About the Author
Melinda Stelzer Jacobson is an Agile Coach who believes that productivity and success are achieved by happy people in teams where trust, respect and communication are valued. Her belief is grounded in 15 years of software development experience spanning across telecommunications, banking, scientific devices, web sites and internet applications. Based in San Francisco, Melinda is a Certified Scrum Master, Certified Scrum practitioner, ICAgile Certified Professional in Agile Coaching, and Innovation Games Certified Collaboration Architect. In her spare time she saves cute orphan bunnies from being euthanized.
Great article! The coaching role of the scrum master role is often overlooked
Great article! The coaching role of the scrum master role is often overlooked
Best argument I've read for a dedicated, FT ScrumMaster, but...
I largely agree with your opinion but differ slightly. I will take your argument as "A Scrum team with a full-time ScrumMaster will always be better than one without a full-time ScrumMaster." That is absolutely true and you've made the argument very, very well.
However, this does not necessarily mean every Scrum team should have a full-time ScrumMaster. Consider a team with 6 hardcore programmers, a designer and a full-time ScrumMaster. They're kind of missing a tester. Sure they could turn one of the programmers into a tester. That may be a good or bad decision--it would depend entirely on the exact context of this made-up example. But they could also turn the ScrumMaster into a tester (or trade the SM for one). And again, whether that is good or bad would depend entirely on the context of a specific situation.
The point there is that of course having a full-time ScrumMaster is better than a part-time one. However, one must always consider whether that is the optimal decision. I might even concede that it is most of the time the optimal decision. But I'd never concede that it is right in all contexts.
In fact, in the example you gave there is no way it would be the right decision. You said to assume that a full-time ScrumMaster makes the team 5% more productive. (I know it's just a number out of thin air and you probably wanted to pick a low number to show how dramatic an improvement a fulltime ScrumMaster could provide.) I assume that is 5% better than the same team with, say, a half-time ScrumMaster. But let's suppose the ScrumMaster stays half time and uses his other half time as a programmer (or tester or whatever). If there were five programmers and there are now 5-1/2 programmers, the team has just received 10% more programming capacity. (I'm ignoring the 20% task switching loss for a moment.) It is quite possible that 10% more programming capacity is the better option here.
The point is we can't decide without knowing the situation. Every system has one and only one of what is called the capacity constrained resource. If that is programmers and the team could have half a programmer instead of the additional ScrumMaster time, then opting for the half a programmer is likely the right answer.
We can't know without knowing the exact context--and that means there will be some cases (perhaps not many!) when a part-time ScrumMaster is a better economic decision.
You used the comparison to a part-time sports coach. Perhaps that is a model for investigating how often a team can reach the pinnacle of their sport with a part-timer. My favorite sport is basketball and the last time it happened was 1969 with Bill Russell (perhaps the best player ever, certainly so based on championships won: 11). In basketball, a player-coach has won 3 times in 67 seasons or about 4.5% so call it 5% of the time. Perhaps then in 1 in 20 Scrum teams gets to a level where they can have a team member / ScrumMaster combo and still be the best they can be. Seems a little low to me but I'd accept it as a starting point.
Again, thank you for the great article. The best on this subject I've seen. I'd just want to use it as argument to get people to think harder about reducing the role rather than to say every team absolutely must have a full-time ScrumMaster.