This is the fourth part of a multi-part series on how to perform evaluations of Agile Development Processes.
- The first article in this series evaluated the first 4 principles of the Agile Manifesto as an approach to perform Agile evaluations.
- The second article focused on principles five through 8.
- The third article addressed principles 9 through 12.
This article addresses a common question we receive: Do we need Scrum masters?
Answer: Scrum Masters need not be a position within your team. That said whether you practice Scrum, some other Agile methodology or waterfall, the activities and tasks typically assigned to a scrum master need to happen whether you have a Scrum master employed as a person on your team or not. While you do not need someone with a Scrum master title, and you need not dedicate someone to the Scrum master tasks, you must address most of the activities a Scrum master performs.
We most commonly tee this question up as whether Scrum Master is a role with tasks that can be distributed amongst team members, or a position that a person must fill within an organization.
Scrum Master Responsibilities and Tasks
Scrum Masters are generally responsible for the following activities:
- Implementation and governance of best practices in managing the product development lifecycle.
- Communication within and outside of the team regarding progress, activities, blockers, etc.
- Coaching team members on process.
- Facilitating implementation related meetings such as standups.
- Assist with the product team backlog.
- Resolution of blockers; remediation or elimination of obstacles that block team progress.
The reasoning behind dedicated Scrum Masters
AKF Partners generally views “Scrum Master as a position” as a best practice in most (but not all) organizations. When used properly, Scrum Masters help offload important and valuable work to lower cost resources, providing an efficient way to lower the cost of development.
The purpose of a Scrum Master, when implemented as a position within the team, is to cost effectively remove time consuming activities from higher cost development and project management resources. As organization size increases, with multiple development teams participating in product delivery, the time allocated to coordination and communication activities increases exponentially – specifically as a square of the number of engineers and product managers. If the average product manager and engineer come at a cost of between 10% and 50% more than a Scrum Master, as engineering team sizes grow the cost savings benefit of dedicated Scrum Masters similarly grows.
The savings a Scrum Master provides goes beyond just the easily calculated cost per activity. Because a Scrum Master exists to help protect the productivity of a team, the “paper cuts” of inefficiency caused by constant distractions are reduced significantly. Every time a developer is interrupted, they lose more time than just the time of the interruption; developers must context- switch and get themselves back up to speed on their activities. A five-minute interruption can easily cause 10 or 20 minutes of productivity loss. Therefore, along with our absolute dollar savings in cost, we also achieve productivity gains.
When Scrum Masters may not be needed
Very small organizations are less likely to recognize productivity gains with Scrum Masters. Because the amount of work increases with total organization size (not just the development team to which the Scrum Master is allocated), organizations with 2 or 3 development teams of less than 12 people each are unlikely to see significant improvements in efficiency or cost. Both efficiencies will be present, but their benefits may not “fund” a full-time equivalent hire.
Common Scrum Master concerns – the Tyranny of the How
Our argument for the Scrum Master position assumes the position is an administrative and support role. Scrum Masters are part process engineer and part project manager. In our opinion, and in properly built and run organizations, neither of those activities warrant executive positions as they are meant to help facilitate outcomes.
The most common failure we see with Scrum Masters in organizations is when companies allow the position to be elevated to an executive level. Doing so invites an opportunity to allow how something is built to take precedent over what is being built. We often call such situations “The Tyranny of the How”. Put simply, how you accomplish something is more of a subordinate decision within properly run organizations. Executives need to focus on what should be done and why it should be done.
When we see scrum masters, Agile enthusiasts, process engineers or program management teams elevated to executive positions, “How” starts to become more of the discussion. In so doing, the autonomy of teams is removed, and execution instructions start to flow from the top down. “How” takes on a life of its own and process rather than outcomes become the focus of discussions. In extreme cases, as in the case of GE and Motorola with Six Sigma processes, the how starts to influence culture and take priority over the what. Outcomes suffer.
Summary
- Scrum Masters add significant value in organizations by significantly reducing the cost of development and time to market.
- Elevating Scrum Masters (or for that matter any execution or process organization) starts to elevate how something is done over what should be done; doing so is bad for both outcomes and company culture.
Our series continues in part 5 with other common Agile implementation concerns.