Rotating Scrum Masters To Diversify Leadership

Many engineering managers or team leads play the role of scrum master in daily team standups — it becomes routine to check a burndown chart, review a scrum board, shuffle a few tickets, and discuss the status of the latest release/deploy.

And yet, if this practice has become routine then it probably is no longer something that facilitates personal growth. Given that managers are always seeking to both maximize their time as well as help mentor their team, the management of standup is an opportunity to hand off some leadership to others in order for them to grow and practice.

Junior engineers can fall prey to having more focus on their personal efforts rather than that of their broader team as a whole. Over time, they need to learn how to alternate focus between multiple levels of resolution, and develop a more detailed sense of how their work is interconnected to their team and company goals.

Having a junior engineer lead standup meetings can lead them to consider these things in a way that they previously hadn’t, given that you provide them with some guard rails so that they don’t become overwhelmed.

Senior engineers often have a good feel for what an efficient team looks like, even if they can’t yet precisely articulate how that efficiency in a team is created. Allowing them to manage standups gives them a chance to examine how specific mechanics of sprints and standups contribute to that efficiency.

Being the one to course-correct team efforts by monitoring these mechanics gives them a taste of the organization and communication required in management, which can help them further their own understanding of their desired career paths.

Whether measured explicitly or not, there is an important aspect of team efficiency to agile sprints. A team runs more smoothly and ships more work if various mechanics are in place:

Many engineers have a vague “spidey sense” for these things, but having practice at explicitly owning them as the scrum master can make engineers into more efficient team members.

Everyone who has run a meeting has experienced the minor frustration of having to keep the conversation focused. It is easy for an individual meeting participant to get side-tracked without much concern. However, if everyone has to experience the challenge of leading a focused standup meeting it can have the side-effect of making them more conscientious participants.

While providing everyone the chance to lead in this way can have value, doing it successfully should have a prerequisite that the manager or team lead is already proficient enough at this activity that they can coach others through doing so.

It took myself a year before I felt adept at running standups effectively and efficiently. During that time I experimented with focus on different mechanics/measurements, different types of communication, different ways to organize tickets/boards, and solicited feedback on these things during retrospectives.

If a leader is still growing through the exercise of leading standups themselves then it might be premature for them to share the responsibility with others.

Sharing standup management with less-experienced team members comes at the cost of some efficiency in the short-term. While this is often okay, there might be unique projects or contexts in which this needs to be avoided.

If current project have irregular constraints, deadlines, or consequences, it might be best to have the most experienced leader in charge of standup in order to best mitigate the increased risks that are present.

Designers, product managers, QA engineers, and others are also stakeholders in standup meetings, and they can play a factor in whether or not the cost/benefit ratio of this rotation is worthwhile.

If your team is working with a more junior designer or product manager, or perhaps one who has an irregularly large workload, it may benefit them to have the most experienced leader running standup.

First, ensure that your team is in a position to benefit from this practice. Make sure that the When NOT to rotate scrum master section, from above, doesn’t apply to your team. To help assess readiness, consider doing the following:

For this rotation to succeed, the engineers need to have a strong understanding of how it should work, what they need to do, and why.

I found it useful to create a one-pager that explains this rotation, and to review it with your team to kickoff the rotation. It can also be useful to review this with each engineer both before and after their first time through the rotation.

Related posts:

Five years ago my husband and I embarked on a journey. A journey to find the perfect place to found “Humblebee Farms”. The journey took nearly five years to complete and tested us in every imaginable…

Most of you are already familiar with SQL database, and have a good knowledge on either MySQL, Oracle, or other SQL databases. In the last several years, NoSQL database is getting widely adopted to…

Binance will add support for Harmony staking to its recently launched staking platform, as announced on October 15th. Starting Oct. 16th, Binance users with $ONE on the exchange will begin receiving…