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.Discuss
I’ve recently been asked by one team to provide them with case studies/success stories about Scrum to prove scrum works. It is striking that the people ask for case studies about agile – but didn’t before adopting their existing process.
Ken Schwaber co-creator of Scrum has: Primavera Success Story (pdf) a paper that describes Primavera’s struggles with waterfall and then their transition to Scrum (with XP engineering practices). Key message: Scrum works for Primavera, but changing the process isn’t easy.
Stuart Read, Professor of Marketing at IMD in Lausanne Switzerland has written a case study about Guidewire (pdf) – a insurance billing company that is built entirely around Scrum.
On InfoQ (caveat emptor I’m an InfoQ editor) there are a number of case studies:
- Scrum Boosts Effectiveness at the BBC (presentation), “In this conference talk Andrew Scotland tells how BBC’s New Media division, characterized by a lot of uncertainty and emergent software process, decided to use Scrum to more effectively deliver software amidst all that change and uncertainty. Three years later – the difference is significant, and the journey was worthwhile.”
- Case study: Distributed Scrum Project for Dutch Railways – focused on how one group has made a necessary evil (distributed teams) work, this case study is also a good example of how Scrum works
- Improvement, Success and Failure: Scrum Adoption in China – an interesting Q&A. The questions around failures are very interesting: Training is critical and doing Scrum-but will eventually kill.
- Henrik Kniberg’s famous “Scrum an XP from the Trenches” a 168 page ebook (free) that describes how one team does scrum.
UIE a usability website has: The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site – while not strictly a Scrum case study Netflix does use Agile methods.
Obviously Ken’s book Agile Project Management with Scrum is a series of case studies.
DDJ has Embedded Agile: A Case Study In Numbers an article that demonstrates Agile working in the embedded environment. Timo Punkka documents Schneider-Electric’s
adoption of Scrum for embedded software development.
Mishkin Berteig has one called: A Cautionary Tale. It looks an Agile Adoption delayed and what the delay cost the organisation.
Agile From The Trenches – A real world example – Keith Sterling’s (BTW Keith can you stop moving this article :-)) story of Agile adoption in a UK telco to help it build and rollout a broadband provisioning platform.
Rally has a number of Customer Case Studies – Caveat Emptor while interesting they were written to prove that Rally can help you transition to Agile – so they tend to be slick and focused on Rally benefits. Net result – they’re a wee bit light on specifics. They also have Agile Impact Paper written by IDC – good paper about the impact – but what a pain to download – I’m surprised I wasn’t asked how many children I have.
Danube also have Customer Case Studies – same caveat as Rally applies.
Finally Frank Maurer, a professor at U Calgary has: Agile Software Development: An Industrial Case Study with data showing increased productivity.
Google reveals many more case studies – but if the above weren’t sufficient then no case study will help convince. Finally I suggest stop reading case studies, take action. Get some training, find a mentor and start. Your first few iterations will not be your best but you will improve with time.
As a counter point some of you may recall my Journal of Agile/Scrum Failure – which is still looking for contributions.
Update: Added Case Studies from Mishkin and Rally. Latest additions Keith’s efforts and Timo’s embedded paper. Added samples from Danube.
Image attribution: http://photodune.net/