At my job, we're having a Scrum of Scrums meeting where all the Scrum Masters get together. This meeting is turning into a boring meeting where everyone gives their status update. I'm trying to make the Scrum of Scrums meeting more proactive, where Scrum Masters will be more involved with other Scrum Masters, and where it is more of a time for Scrum Masters to call out dependencies on other teams and agree upon a solution to remove those dependencies.
Our team co-ordination meeting was getting really stale too so we did a few things to try and improve it which seem to have worked pretty well.
- We focus our team co-ordination meeting around a board, similar to team standups.
- Each team has a swim lane and puts a card up stating what they're working on now and next. This gives teams an opportunity to question each other when there is a dependency between them which is our primary reason for running the session.
- We track actions that have been taken by teams on the board and review them each week.
- We have a process in place for escalating to the senior team.
- Anyone can come but a senior developer from each team must be present. We introduced this because we were finding other team members lacked the technical understanding of our platform to really identify where teams were going to cause each other problem.
- We keep cards for the previous 4 weeks on the board to provide a quick reference for what people have been working on.
Above is an example of our board.
I suggests to change how the Scrum of Scrum meeting is facilitated. Instead of talking about usual stuff and about the three questions, I would focus only on the following key points and have a discussion about them:
- Which team is going to deliver today: Here other teams shall know that something new (package, code etc.) will arrive at their desk.
- Is there a mentionable change in the burn-down charts: Another indicator that a team will receive something earlier or later than expected.
- Is there any change in the backlog: Again, an important global change.
The idea is to focus only on those things which affect other teams. In order to do it effectively, the teams shall discuss what to bring to the Scrum of Scrum meetings. It shouldn't be something the ScrumMaster finds out. If the team has nothing to say, that the SM shall say that there is nothing to add to the meeting. If it happens on multiple occasions, then something is going on at the team level, which is worth checking out.
Additionally, there is something else which is worth checking out. How come that Agile people turn their own meeting into a status meeting? Don't get me wrong, our ScrumMasters do it all the time, but you may be able to find a good reason and fix it. We still don't know why they do it, and neither do they.
Here I blogged about some daily stand-up variants, you may find something useful there too.
There are a number of books on scaling Scrum, and I'm sure there are other definitions out there, but I'm going to share my personal definition with you.
A scrum-of-scrums standup is a dependency-coordination meeting between scrum teams.
Ideally, a scrum-of-scrums should have a separate Scrum Master who isn't wearing the Scrum Master hat for another team. That person should be the referee who blows the whistle whenever the meeting begins to slide off the agile track.
Think of each Scrum Master attending the scrum-of-scrums standup as a human kanban. That person's job is to:
- Notify the other teams that a value-stream work element is ready to be pulled from that Scrum Master's team.
- Alert the other other teams that some work element is occupying an inter-team work-in-progress slot, and is stuck inside the Scrum Master's team because a defect or process bottleneck has been discovered.
In other words, this should be a short coordination and commitment meeting between Scrum Masters, rather than a status pull, review, or retrospective. However, without a designated Scrum Master to act as a process referee, and without a strong organizational commitment to inspect-and-adapt at the scrum-of-scrums level, meetings like the one described in the question are all too common.
I concur with most of the suggestions above if you are doing a Scrum Master scrum of scrums. I would ask yourself what the purpose of that meeting is. If it is just technical coordination of immediate activities, then focus around that and the scrum masters (or senior developer) should be able to handle them.
If the focus is to keep the teams coordinated beyond just technical dependencies, I might suggest a scrum of product owners (assuming that you have product owner/business analysts or similar on each team) as well or even instead. These folks are responsible for maintaining the overall vision and ensuring that business need is being met instead of just looking at the software. Particularly as you move from being software focused to solution focused, the broader vision will often bring into focus areas that a team needs to be concerned about beyond just doing coding.
Either way, I would use the scrum of scrums as more than just immediate coordination between teams and a regular meeting to look at overall picture of the product (or sprint or release).
Scrum emphasizes not only self-organizing teams but also cross-functional team collaboration for better performance. Known as Scrum of Scrums, this practice is important for large, multidimensional projects which require cross departments and teams to work in close collaboration so that the overall performance is as effective as in small projects involving smaller teams. The key to this scalable element is the Scrum of Scrums, known in traditional parlance as “program management.”
Scrum of Scrums is a very good practice, but its success depends on two key factors – effective coordination and an efficient program manager. If either or both these conditions are not fulfilled, Scrum of Scrums proves to be the Waterloo of the entire project.
In projects involving a single team of few people, Scrum Master is the guide and the mentor who steers the team in the right direction. However, with multiple teams working together on the same project, there has to be a manager who can coordinate effectively across the teams. In such a scenario, each team has its own Scrum Master who in turn coordinates with the Scrum Masters of the other teams under the guidance and supervision of an overall program manager, known as Agile Program Manager. Source: http://scrum-master.info