Let me ask you this: If you had a team of five would you rather have 20% annual gain without adding another developer, or go hire and integrate a new developer every year to get a 20% productivity gain YoY?
If it was up to me, I’d go with option one and make sure that I invest in ScrumMasters. Too often I see the ScrumMaster role diminished and undervalued in organizations. Many leaders believe that the ScrumMaster role is part-time (can be combined with another role such as manager) or that one ScrumMaster can cover five teams. Perhaps it’s because of the wrong ways the role is implemented that’s causing confusion and bad decision-making around staffing the team.
Increasing Productivity With Developers
Hiring developers right now are easy right? And getting them onboarded and productive is quick, right? When it comes to finding, hiring, and keeping talented developers, it’s definitely an employee’s market.
You can get that 20% productivity gain by hiring more developers, but the return will come about slower and will be a lot riskier. I would argue that a ScrumMaster is easier to hire than a developer and they might be able to make an immediate impact and bring new skills to the table for a smaller salary.
Let’s go back to that promised 20% gain, this time through the lens of process improvement. When developers are left to decide between process improvement or coding, their obvious choice is to code. Who is going to do the process improvement? The ScrumMaster will help guide the team to focus sufficient time on process improvement.
There are some similarities between ScrumMaster and management responsibilities. We want both to be servant leaders, both to coach their team, and both to help improve the organization.
However, the advantage of a ScrumMaster is that they are not coaching from a place of authority. Meeting 1-1 with a boss is different from a private meeting with a ScrumMaster. The ScrumMaster is truly here to serve, while the manager is still responsible for managing performance. Agile is big on self-organizing teams because it leads to higher engagement. The ScrumMaster can be an integral part of this self-organizing team, while the boss is not a part of this team.
Gains Via ScrumMasters
A ScrumMaster has many responsibilities, the main one and easiest to understand is that they facilitate the process and events of Scrum. While this helps everything run smoothly, this won’t lead to continuous improvement. Another part of their role is to not let the team get too comfortable and to create safety and courage for the team to keep trying new things. This leads to continuous improvement and the 20% gain we’ve discussed throughout this article.
In the beginning (early Sprints), the ScrumMaster will be mostly focused on helping the team improve their own practices, but eventually, the team will get good on their own. Some would say the job of a coach is to work themselves out of a job. That is true.
After 3-6 months the coach shouldn’t have too big of a role in all the standard practices of Scrum. The team should be good at Daily Scrums, Sprint Planning, Backlog Refinement, Retros, and Sprint Reviews. Everyone will know the rules and should be able to self-organize to get them done. The ScrumMaster will just be there to keep them honest, keep them from falling back into bad habits, and to remind them of the new rules they set or the new practice they wanted to try.
So then what do they do when the team isn’t as dependent on them? As teams start to address all of their internal issues, they start raising organizational impediments. Now the ScrumMaster’s focus turns from inward to outward facing. They look outside the team for ways to help them become even more productive. They now become the advocate for the team, championing change throughout the organization and working with leadership, business stakeholders, peer teams, other ScrumMasters, etc. to improve the overall system in which the team is operating. These changes are bigger, harder, and take more time, which is why this job isn’t easy. It is through organizational change that big productivity gains are accomplished.
One last note: How far can a ScrumMaster scale? I typically like to see a ScrumMaster working with one or two teams at a time. Past this point, they might only be able to do the facilitating without all the other areas. Which just means they are able to maintain status quo with a team, but not continually drive improvement.
So why wouldn’t you make the investment into a full-time ScrumMaster that is going to help two teams get 20%+ annual improvement in productivity? Sounds like a solid ROI to me— and easier than hiring two new developers every year.