Conventional wisdom
has it that rotating the scrum master position should not be a permanent
practice. Mike Cohn has an interesting blog entry
from a few years ago, which supports this wisdom, while presenting both sides of
the argument. I heartily recommend looking at that blog, including the
insightful comments from readers. Based on my experience with
our scrum team, and observations from others, I would suggest that creating a “permanent”
scrum master is not necessarily the best choice, and doing so closes off some possibilities
for getting the most out of agile methods.
Our team is not an
immature one. In its current form, it has existed for over 4 years, which
periodical personnel changes over the time. Our first scrum master was in the
role for about 2 years, and she helped us to improve. Since then we have put the position on a 3-6
month rotation.
Here are two assumptions that
need to be re-examined.
- This may be sacrilege, but I’ll say it: Very few people want to be scrum master. You could hire someone off the street whose ambition is to be a scrum master (see job postings, there are many), but in most cases, the scrum master is chosen from the ranks of existing employees. If you have a team full of professionals who are moving to scrum, people want to continue practicing their profession, not doing the things that the scrum master role asks you to do. So what happens? The manager assigns scrum master duties to the most junior person, or the person who otherwise draws the short straw. Only in edge cases will a team already have a person who desires to develop into an agile coach, which they perceive (justly) to take them out of their current career path.
- The coaching aspect of scrum mastery is, IMO, overrated. Our team is full of coaches. We coach formally and informally all the time, in structured and opportunistic settings. By having everyone be the scrum master over time, the scrum master merely continues to support a coaching culture within and around our team
- The scrum master got better. Every person who has entered the role, went in kicking and screaming, and came out the other end a better team member. Some develop an appreciation for what everyone on the team contributes, some stepped forward as a leader instead of remaining as a wallflower. Some learned to see the benefits of scrum more clearly, or out as a more mature agilist. The change has been different or every person.
- The team got better. The top focus of our scrum masters has been to improve our internal processes. He or she leads the team retro, and facilitates the commitments to improve, which often turn into stories. By getting fresh blood into the role of facilitating continuous improvement, we see innovation all the time. One scrum master will come up with a new structure for our retros, another will come up with better charts or metrics to present team performance improvement. A third will explore and incubate deeper understanding of our planning tool. Another might beat the team over the head with the rules of scrum, making sure that we don’t follow (or break) any of the rules without a sound, consensus-driven reason. Everyone has their own view on how the job should be done, and if they have that good intent, if their heart is in the right place, we give them time and space to do so.
Listen,
I admire Mike Cohn and many of the other agile/scrum experts. Without them, it
would have taken me much longer to get up to speed on how my team and I could,
as Mike would say, “succeed with agile.” However, I am wary of agile gurus
telling us what we should or shouldn’t do, which rules can be broken and which
ones must be followed. In the case of Scrum, I am in favor of teams starting
out going by the book (that is, the rules of the game as described in The ScrumGuide), but over time, teams should feel free to discard the rules that don’t
serve them and introduce new processes that support their ongoing efforts to
collaborate better.
