Scrum Masters Working Together

FriendsOnce a company’s scrum implementation reaches a certain size it becomes necessary for there to be multiple Scrum Masters.  Even more necessary is that these Scrum Masters work together as a cohesive team.  As is often the case, the sum is greater than the individual parts and a functioning Scrum Master team can have a major impact on the business.

When Scrum Masters work separately without syncing up you put yourself at risk of contradicting each other and making plans that are completely at odds with each other.  You might assume that because all Scrum Masters are working to the Scrum Guide that  there would be no risk of contradiction.  But if you’ve read much Scrum literature (especially on the internet) then you know that interpretations can vary greatly, in addition to the fact that the Scrum Guide doesn’t delve greatly into details and every company has different issues to be dealt with in different social contexts.  This is one reason why it’s crucial that Scrum Masters work together, so they don’t cancel each other out and dampen each other’s effectiveness.

Regardless of the issues that can be caused by Scrum Masters not working in line with each other, it is still beneficial for Scrum Masters to work together.  Two minds are greater than one and conferring with each other on the issues you face can often help to develop even better approaches than one Scrum Master could have come up with alone.  I especially like to share the approaches I’ve decided won’t work with my fellow Scrum Master.  She can often help me to find a way to adapt my idea and make it work after all.

Sometimes you require a 2 pronged attack on a particular issue.  For good cop, bad cop scenarios for example.  Every Scrum Master has different social relationships with each member of your organization.  Sometimes you can be too close to your team to be objective, or too close for them to listen to you.  In both cases the outside opinion of another Scrum Master can do wonders.

I have found the best way for Scrum Masters to keep in sync with each other is to have regular catch-ups or stand ups.  These could be daily or every few days depending on how much overlap there is between your teams and how close they are within the bigger scheme of the organization.  Some people may think that the Scrum of Scrums is the time for this but I don’t agree.  Firstly, I prefer the Scrum of Scrums to be primarily driven by team members as opposed to Scrum Masters – team members know best about the issues they’re facing.  Secondly, Scrum Masters usually have a broader view that just the team’s current work, which is the focus of the Scrum of Scrums – remember, there’s a whole section in the Scrum Guide dedicated to how the Scrum Master should serve the organization (and not just the team).

Just like the team stand ups it can be good to have something to keep things focused and for the Scrum Master stand up I recommend an Impediments board.  This is a basic kanban/scrum board but with a prioritized list of impediments instead of user stories.  The Scrum Masters can then work to break out tasks to deal with these impediments and then allocate the tasks amongst themselves.  Doing things this way can  help to avoid duplication of effort when there are common issues across teams, as well as making it more obvious which issues are these wide-spread ones.  Impediments should also be dated so that it’s obvious which ones are not progressing towards resolution – these are the impediments that either need the most focus, or need to be reassessed as to their importance.

An Impediments board can also be good for team members to view.  They may feel relieved to see that the Scrum Masters are across the issues they are worrying about or they may be able to suggest things that the Scrum Masters have missed.  Finally, as things move across it can help everyone to feel a sense of progress.  Often we become so focused on the issues at hand that it can be easy to forget how much we have improved already and how much we have achieved.


Related Books:

Scrum Mastery

Geoff Watts
2013
Coaching Agile Teams

Lyssa Adkins
2010
Scaling Lean and
Agile Development

Craig Larman
Bas Vodde
2008
Scaling Software Agiling

Dean Leffingwell
2007


Categories: Communication, Roles

Tags: , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: