We need to talk about Scrum of Scrums

It’s been a very naughty boy!

Scrum of Scrums started as a mitigation for cross team dependencies. A growing pain of scaling your solution. Sometimes a necessity but I’m not sure we put the same level of effort into understanding if we can descale our products, perhaps another article.

So originally Scrum of Scrums was for technical team members to get together and discuss what they needed from the other team. Reducing blockers and ensure that teams are working for the greater good.

Somewhere along the line this has changed. Somewhere along the line, and probably because it’s got the word Scrum in it twice, this became the responsibility of the Scrum Master. Makes sense right? They’re at the daily scrum after all?

Well no. It unfortunately doesn’t make any sense for the following reasons:

Are we doing Scrum?

Firstly lets go back to basics and think about what the Scrum Master is doing at the daily scrum. According to the Scrum guide.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

Oh dear, looks like they are primarily there to make sure it happens and facilitate the event. In fact it doesn’t really look like they need to attend at all let along get involved in understanding the intricacies of technical problems.

So the first hurdle is that if the Scrum Master is working to the Scrum guide then they may well not have much of an understanding of the dependencies. Of course not many organisations (and perhaps Scrum Masters) want to work to the Scrum guide so maybe this isn’t the only argument.

The estate agent.

So lets assume that the Scrum Master was at the daily scrum and as well as facilitating gained a deep understanding of what the problems around dependencies were. Lets also assume that every other Scrum Master who attended the Scrum of Scrums did the same.

They all get together and talk about dependencies, dutifully they go back to their teams and tell them about what other teams are dependent on them. The first thing the teams do is ask:

• Technically what do we need to do to address this dependency?
• What have the other team done to consider workarounds to this dependency?
• Who says they’re dependent? We don’t see it.

Inevitably the Scrum Master can’t answer these questions so some technical member of the team goes and talks to a technical member of the other team and the power questions are asked and answered. The Scrum Master has become a pointless middle man that just gets in the way of people talking.

Individuals and interactions of processes and tools?

I don’t think so.

So next time you are told that a Scrum of Scrum is for Scrum Masters to get together and talk about their teams problems, stop. Ask is this the most valuable way of sharing technical dependencies? Does this really save the team time? Is this a case of a process being held more valuable than the individuals and the interactions it serves?

How do I know?

Well I’ve experimented with this so you don’t have to.

I’ve worked with a team of Scrum Masters (well two of us) who helped facilitate the Scrum of Scrums for engineers. Much in the same way as a daily Scrum. We ensured the meeting happened and that the interactions were valuable. Technical people talked to each other and things got done.

I’ve also worked in an organisation that felt that the Scrum of Scrums was for Scrum Masters to work out all of the dependencies. As someone who had only been with the organisation a few weeks the meeting was completely pointless as I had no idea of context. However as an observer what I witnessed was that every conversation ended with a commitment to get technical people to go and talk to each other. A complete waste of time of all involved. Cut out the middle man.

So please do try this yourself, perhaps there is something I’ve missed. I’d love to hear about those that have made this work.

If however you are new to the SoS then please stop and question the value that this is generating. That is kind of our job after all.

About the author:

Chris Davey is a freelance Coach, Agile Team Coach and Scrum Master. He splits his time between helping individuals, teams and organisations achieve more and doing the opposite for this family. If you want to know more you can find out here. www.steelcurve.com or https://www.linkedin.com/in/chris-davey-6004421/