April 29, 2018
The Temporary Scrum Master
—Not sure I like rotating the Scrum Master role through a team.
I'm curious how rotating the Scrum Master role through the Development Team works out for the Development Team and the Organization as a whole. I'm not sure that rotating the Scrum Master role is healthy. Selecting one member of the Development Team to permanently become the Scrum Master seems the better choice.
The Scrum Guide permits the the Product Owner and Scrum Master to execute work in the Sprint Backlog. I take this to mean both roles can be carried out by someone in the Development Team.
A review of the servant-leadership philosophy applied to the Scrum Master role provides insight on the challenges:
- service to the Product Owner: the support the Scrum Master provides the Product Owner is not focused solely upon the domain. It includes Product Backlog management.
- service to the Development Team: this focuses on the organization and the Scrum Team. It includes building bridges to other parts of the organization. It includes coaching the Development Team on self-organization and cross-functionality.
- service to the Organization: this includes helping the organization leverage Scrum better.
When I hear about the Scrum Master role being fulfilled by the Development Team it usually includes a concessions to ensure the Scrum Master isn't taking on that role permanently. The motivation behind this concession is interesting.
Rotation implies that the organization isn't fully vested in Scrum. Further:
- it implies the Scrum Master role is less valuable than the "other" role the Scrum Master has.
- it implies that Scrum Master isn't a good career choice for domain experts.
- it subjects the team to different Scrum Master's each with their own set of values and approaches.
Different values and approaches aren't bad. They are opportunities for learning. But they may cause confusion if you are just rolling out your Scrum implementation.
In all, rotating the Scrum Master doesn't sit well with me. The Scrum Master seems better suited as a permanent role. Even if I assume the Developer turned Scrum Master is a domain expert there are significant trade-offs involved in this approach, especially if you view Scrum as an important initiative that can benefit the entire organization.
comments powered by Disqus
