Thursday, January 26, 2017

Why Rotating the Scrum Master Role Works for Us

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.
  1. 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.
  2. 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

 By rotating the role every so often, our team found these benefits.
  1. 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.
  2. 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.


  1. Well said. I know my mantra is Agile is a mindset not a process. Scrum helps but especially in the case of non development teams, you should indeed start pure, then not be afraid to do what works for the team. Agree rotating Scrum Master is a great way to keep things fresh and to challenge the norms.

  2. With all due respect, I do disagree with some of this. I think the rotating scrum master is a good experiment in the short term. Like any position however - if you have a Scrum Master that is passionate and dedicated to their role, you will get better results. Learning how to facilitate meetings to get the most out of teams in a collaborative manner takes time and practice. Understanding the dynamics of the team, mentoring them with minimal guardrails(but some guardrails all the same), coaching beyond just the team, and having effective retrospectives (that do more than pay lip service to improvement, and really dig into dynamics and causes) takes time and practice. Please, correct me if my perceptions are off on this - I also think your team is out of the norm. Many of you have and understand agility better than most teams due to your roles and your focus. If I had a dedicated group of agilists working with me, I'd see a lot of value in changing up the position frequently (and may even ask if the position is necessary at all)! Having a dedicated scrum master on teams where the focus is developing software, marketing, dev ops, etc. provides more value due to focus.

    1. I agree with you. Ideally, we would have someone who's dedicated and passionate about being the scrum master, and who wants to pursue a career in agile coaching, etc. My point is that, in my experience, there are so many times when the person selected really just wants to be an engineer (or whatever profession). So, the question becomes, how to you make lemonade out of that situation? In our (admittedly special) case, rotating works for us, as it says in the title of the blog. Ultimately, teams (and mgmt) need to discuss the types of points you raise and make the best decision for the team at that time.

      I appreciate your comment. You show up as 'unknown' so I don't know who wrote this. In any case, I hope to discuss issues like this more with you at some point.