The Scrum Master’s Paradox

Nobody will deny that Scrum Masters are very busy around Sprint Boundaries. After all, they have retrospectives and reviews for the outbound Sprint, and they have planning meetings for the inbound Sprint. If the team is collocated or at least in the same time zone, the sprint boundary occupies one or two very busy days. However, if the team has offshore members, sprint boundaries become two or three busy mornings. During non-boundary days, there may be the occasional refinement meeting, Daily Scrums, and all the soft skills which are not well-understood or appreciated, so ultimately the question is raised, “what do Scrum Masters do all day?”

There are many things that Scrum Masters should do to add value beyond facilitating meetings. They are a coach for the development team and the product owner, and in many cases they also coach the organization around the team: SMEs and Stakeholders in particular. They do this work by observing, asking questions and making recommendations. They should also use their soft skills: build bridges, foster team-spirit, improve team happiness, and guard the team.

In organizations which are advanced in their understanding of agility, the soft skills are better understood and appreciated. However, in organizations which consider agility to be done by developers alone, this value is unclear outside of the team.

"I know that the team is productive and their velocity continues to go up, but what does the Scrum Master do all day?"

The Typical Remedies

In some companies, the Scrum Master is given multiple teams to handle. This works fine when the teams are each collocated because there are AM and PM options for meetings. Also, if the teams happen to agree to have alternating sprint boundaries (e.g., two-week Sprints offset by a week), this works out nicely and helps the Scrum Master “stay busy.” However, handling two teams which are geographically dispersed and work on synchronized Sprints becomes very difficult to facilitate.

In other companies, the Scrum Master is given huge spreadsheets of metrics to maintain in their "free time" to “track team efficiency” for the benefit of those outside of the team. In some cases, this leads to additional responsibilities which make the typical Scrum Master look more like a project manager. These sorts of Project Management activities often distract Scrum Masters from their regular duties including coaching and soft skills. Furthermore, collecting metrics for the sake of collecting metrics can lead to many team-level agile anti-patterns of behavior. Therefore, in the interest of making sure that a Scrum Master is kept busy, teams can be made less agile.

In other cases, companies conclude that if Scrum Masters are “only busy a few hours a week,” they may not be needed at all. This leads to a shedding of Scrum Master and teams reverting to waterfall or a more Kanban style of team work.

The Scrum Master's Paradox

The Scrum Master's Paradox comes from Scrum Masters being compelled to appear more busy at the expense of doing their job properly: do the bare minimum from a Scrum perspective as full-time pursuit. What is a Scrum Master or company to do to resolve the Scrum Master’s Paradox?

There are a few strategies which might be considered. First, should the team consider Kanban? Second, can a contributing member of the development team take on the role of the Scrum Master? Third, should the Spotify model of headless teams be considered? Finally, should Scrum Masters be encouraged to actively coach teams to a higher level of efficiency? By looking at these three areas, perhaps the paradox can be resolved.

Kanban

In some cases, Kanban is a perfectly acceptable methodology. If the work is extremely simple, highly repetitive, and/or is demand driven, Kanban is well suited. For example, a service desk would find it difficult to work in Scrum because their work flows in via a queue rather than being planned a Sprint at a time. If the work repeats on a regular basis (e.g., building the same widgets) Kanban may be a more reasonable choice. In the absence of these sort of factors, Scrum is superior because it shines a spotlight on process issues so that teams can work on resolving them. Working in fixed iterations with regular retrospectives is critical for finding and resolving mysterious process impediments which might otherwise go unnoticed.

Contributing Scrum Master

Although, there isn’t a rule that says Scrum Masters cannot actively contribute to the work of the team, this does appear to be a trend in some companies especially on major IT initiatives. In these cases, a project is staffed with developers, testers, architects, BAs, Product Owners, and Scrum Masters: each with their own SOW or understanding that they do not contribute beyond what they were hired to do. Especially with teams that are largely made up of contractors, the roots of these limits are often found in contractual relationships between companies.

A better approach is to have a new team coached by an agile coach (acting initially as a Scrum Master) until a development team member expresses interest in extending their skill set to include Scrum Mastery. This is very much in line with agile notion of cross-training. And with proper training and coaching, it is most definitely a viable alternative to a dedicated Scrum Master. It is interesting how people think that Project Managers can become Scrum Masters yet developers (for example) cannot take on that skill or that it is somehow a waste of their time.

The Spotify Model

In the Spotify model, an agile coach works with multiple headless (without a Scrum Master) teams. The coach makes regular rounds and actively coaches the teams to a higher-degree of agility. The coach in these cases will likely coach a team in running their own daily scrum and planning events while continuing to facilitate and contribute to retrospectives. In this case, it is possible for the coach to handle many more teams. Furthermore, the role of the Scrum Master is effectively shared across development team members and the coach. Therefore, there is an affinity between this option and the contributing Scrum Master option.

Scrum Masters as Actual Scrum Master

Another option is just to accept that a full-time dedicated Scrum Master can provide extreme value to a team during their perceived “down time” by observing the team as they work, asking questions within the team and in the surrounding organization and making recommendations for improvement to the Product Owners, the development team and the organization. For this option to work, the Scrum Master needs to have a great deal of experience and the fundamental understand that their job is more than that of an administrative assistant to the team; rather it is as the Scrum Guide suggests: an active coach which is there to help the team discover higher-levels of agility. This option results in higher-performing teams as well as helps develop the next generation of agile coaching.