Rotating the Scrum Master Role
Rotating the Scrum Master role within your team may be a disaster, or it may yield specific and desirable benefits if done carefully.
Discussions on the web periodically raise the question, “Can the Scrum Master role be rotated across the team?” This is an interesting question and one’s answer to this can have a dramatic effect on a Scrum team.
Implicit in this question is the consideration of whether the Scrum team members possess the skills that are required for the Scrum Master role.
Before I dive into the nuances that I see, here are a few comments one might consider if this rotation model is up for discussion in your organization.
Pros
- Individual team members learn the value of achieving ‘crispness’ in the Scrum events.
- Each team member can learn new skills in how to achieve the goals of the Sprint Review & Demo, how to analyze the input to the Sprint Retrospective, and so forth for the remaining Scrum events.
- The organization can dispense with persons dedicated solely to the Scrum Master role.
Cons
- The Scrum Master should operate both “on the factory floor” (tactically) and “in the balcony” (strategically) over that floor. Not every team member has this dual skill.
- Sprint Planning constraints (capacity, velocity, load, readiness of stories… ) may be difficult for team members to address when they are facilitating events only once every, say, five sprints.
Let’s go a bit deeper with an additional question: Is the Scrum Master role mechanical, such that facilitating a few Scrum events is all that is required?
In my experience I have seen many in our community answer this question affirmatively, and this deeply disturbs me. If agility just required managing a checklist for the mechanics of Scrum events, our lives in software development would be a lot easier.
It is a given that not everyone trying to fill the Scrum Master role will understand, or even be interested in, the multiple facets of what the Scrum Master role fully requires beyond facilitating the Scrum events. A focus on mere mechanics is too narrow. In Coaching Agile Teams Lyssa Adkins enumerates and explores a list of expected Scrum Master skills that include: facilitator, mentor, teacher, problem solver, conflict manager, and collaboration coordinator.
To expect everyone on a Scrum team to be equally adept at these soft skills is naïve. However, to presume a dedicated Scrum master should be strong in these skills is totally inline with what the role should deliver.
So, is there a way to engage a rotation model to benefit the team?
Yes. In my client engagements I have used limited rotation even as I was their dedicated Coach or Scrum Master. I found the “biggest bang for the buck” can be obtained by rotating the developers into facilitating the Daily Standup (aka, Daily Scrum). A developer as developer in a Standup can easily tune out and not listen to what other team members are reporting. But when that same developer as Scrum Master is facilitating a Standup, showing a backlog, and has to remember what Fred said yesterday versus what Fred is saying this morning, this creates a huge cognitive shift. Managing the Standup structure of accomplishments, commitments, and 16th minute generates discipline and forces this acting Scrum Master to embrace a perspective of being “on the balcony” to identify dependencies and emerging risks for the team, and so forth.
In my experience this “acting” role produces better Standup reporting by that person when he or she returns to being a developer again. They understand the process and goals of the Standup much better, and become more successful as participants.
It is theoretically possible that each team member might also be able to (eventually) lead Sprint Planning, Product Backlog Refinement, the Sprint Review and the Sprint Retrospective effectively. But if they do this only every fifth or sixth sprint – they will always be doing it for the first time.
I will also add an additional viewpoint to be considered in this discussion. This viewpoint is the backbone of my book, The Effective Scrum Master, and consists of these four Scrum Master personas:
Sherpa – the Scrum Master as Expert
The Scrum Master should always demonstrate 'good agile' for the team. This means the Scrum Master must strive for and attain expertise in Agile—not just Scrum, which is only one of many flavors of an agile approach. Not all developers have such a broad exposure to different forms of Agile, or have the depth to fulfill this attribute.
Shepherd – the Scrum Master as Guide
The Scrum Master must nurture and grow the Scrum team as a Team, and the individuals in the team, to be the best they can be. The Shepherd guides the team to achieve increasing levels of self-organization and accountability to each other. Not all developers can provide such 360 degree guidance, nor may they have team-building skills.
Sheepdog – the Scrum Master as Protector
An effective Scrum Master must protect the Scrum team—even at some personal or professional cost. Most people, including developers, are not comfortable with confronting threats to the team when doing so may affect their next Performance Appraisal or their career path.
Diagnostician – the Scrum Master as Healer
An effective Scrum Master must be a skilled diagnostician and always aware of the team’s vital signs. One does not develop this skill by running a Scrum event. Diagnosis is a rare skill in both Scrum Masters and physicians, and sensitivity with a keen intuition is a maturity that must be developed over time.
Conclusion
I have always been puzzled by the rotation model as a substitution model. It is always applied in a way to render the Scrum Master role as “anybody can do this”. Why have I not heard, “let’s rotate the Scrum Master and Product Owner into developer roles”? We don’t proclaim this because we know development is a highly selective skill set. Yet, isn’t the Scrum Master skill set just as selective? We feel the Scrum Master role is not technical and therefore plug-compatible across our team. I would offer that the Scrum Master role is indeed highly technical: technical in the domain of human interaction. And if we do not maximize the effectiveness of that human interaction, then perhaps we deserve superficial and mechanical checklists.
I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.
