In the early days of Agile/Scrum, my engineering teams would regularly rotate Scrum Master responsibilities, primarily because everyone wanted to try out this ‘new Agile thing’. It was a chance for each engineer to take a leadership role on a team, get a little more perspective on a project, and to try out their ideas. Agile was new, interesting, and full of promise. Serving as Scrum Master forced us to learn the processes and gave us a chance to practice them.
The Era of Aging Agile
Fast forward to today, the Era of Aging Agile, where the newness and excitement are long gone. Agile, particularly the Scrum version, is nowadays pervasive so most engineers know something about it. And yet, I find that many engineers are not well versed or experienced in Agile processes. Some engineers have been on Agile teams, but become jaded by their experiences. Often Agile best practices are given lip-service, as opposed to honest efforts. Or they are poorly executed.
If your team lacks knowledge of useful Agile processes or their implementation is terrible, you need to get help from someone who has expertise and who can coach your team. The suggestion I am making here, to consider a Scrum Master rotation, is only useful when your Agile techniques are basically working, but perhaps not as consistently and universally as you would like for your team.
Two Approaches
A common approach to managing an engineering team’s Agile processes at this point in time is to have a dedicated Scrum Master—either an experienced team member with good Agile skills or an Agile professional, possibly even split between several teams. With this approach, your Scrum Master is likely to be able to guide the team past challenges, pointing out options as you go.
But there is a subtle disadvantage to the use of a dedicated Scrum Master that you need to be aware of. Software development is a team sport, where everyone needs to know how to play. If you have an expert Scrum Master, team members may lean on him or her to handle the processes, challenges, and techniques, rather than learning these for themselves.
The strongest engineering teams are those where all of the members fully participate, not just in the coding, but also in the processes they follow. To successfully participate, the engineers should have both good knowledge of the processes and experience with them.
This is why I suggest forming a Scrum Master rotation in which each member of the team will regularly serve as Scrum Master for a Sprint.
Making it Work
The key to a successful Scrum Master rotation is to ensure that you provide coaching for the folks who are new to the role. This is where your previously dedicated Scrum Masters (or whoever your Agile experts are) can shine. Rather than having them performing all the work for the team, they can mentor the new Scrum Masters as needed, ensuring that the new Scrum Masters know their responsibilities and can handle any tricky situations that might arise. Also, they should still take their slot in the rotation, especially so that the other team members can see how they work. In fact, the whole team will likely be paying much closer attention as they know that they will be filling this role at some point soon! In addition, having a Scrum Master rotation will free up some of your (former) Scrum Master’s time, so eventually they should have more time to take on bigger engineering or planning tasks, depending on their skill sets and desires.
Although every Agile team is a little bit different, there are some tasks that are common for Scrum Masters, and are good for everyone on the team to gain experience with, including:
- Effectively running concise daily standups
- Reporting on and dealing with technical issues affecting the team
- Working with PM and Engineering leadership on backlog and issue grooming
- The Planning and pointing of stories
- Looking at the backlog to see what work is likely to come up in the near future
- Running retrospectives and tracking previous proposed changes.
On the strongest engineering teams I have seen, every member of the team thought about and acted on these items. But if an engineer never fills the Scrum Master role, he or she may not learn good ways to handle them. Fortunately, once every member has gained experience regularly addressing these types of issues, the Scrum Master role becomes more comfortable and less work for whoever happens to be in it!
Intelligent Choices
I like my teams to suggest process changes, but expect them to have a good understanding of the problem them are facing, and good reasons as to why they think their change will address this problem. Otherwise they are just randomly guessing.
Teams where all the folks really understand their current processes are much more likely to make intelligent changes to improve how they work. They are more likely to be able to adjust and overcome issues. And they are more adaptable when outside changes come upon them.
One good technique I have used to help my teams gain useful Agile knowledge and experience is to set up a rotating Scrum Master schedule so that that each one regularly rotates through the role.