Using a Scrum of Scrums for a remote team – the anticipated outcome

I am working on a project where our team are spread between contries and working on multiple streams of work. We are using agile techniques, but we want to improve our cross team communication. So we are going to have a “scrum of scrums” meeting in addition to our daily scrum in each team.

The process is described pretty well in another blog but I wanted to put my own views down before we start so I can see what happens in practice.

The scrum of scrums is a 15 minute meeting to allow cross-team communication. 

• Each team is assumed to manage their own work separately (probably using their own scrum meetings and story walls and other cool things). So the Scrum of Scrums is not for tracking the status of each team.
• The Scrum of scrums (or “the meeting” to save me typing a little) is designed to make teams luckier. It exists so that teams find out what another team is doing just before they do it rather than just after they have done it. So, for example if you are locking down a test environment for 2 days and I am going to start using it for testing then we both get upset with each other and then work out what to do before we blow each other up – hence our luck improves.
• One member of each team comes to the meeting to represent their team and find out what is happening in other teams.  They are expected to know what is happening in their own team and to take information to their own teams if needed.
• The meeting can be every day or a couple of times a week and should only last 15 minutes or less. Often this will not be enough time to explain things properly or to resolve any conflicts, so it is good to have the following approach:
  • If you are worried about something another team is doing, go and talk to them.  Don’t wait to resolve it in the meeting.
  • Often things need more discussion than is allowed in 15 minutes.  Do not have this discussion during the meeting. Instead have a second catchup over skype or coffee just after the meeting.  So I often book the meeting as 1/2 an hour in people’s diaries and then actually have 2 meetings in that time. Meeting one is visciously (er – tightly) facilitated to keep discussions short, but you can ask to speak to anyone “after the meeting” and this happens in the second 15 minutes.
• Each person updates the crew with the following information
  • The most important things we (my own team) did yesterday were …
  • The most important things we are going to do today are …
  • The biggest hassle/annoynance/blockage we face is …
  • If not already covered explicitly – We are going to do the following that might impact the rest of you guys is …  (for example a release, a change to a shared environment, a yummy cake you should come and eat)
  • We want/need/expect this from another team today or tomorrow ….
• Minutes are kept by anyone who has time to do so.  But if they have time to do so then we will probably assign them to regression testing instead of minute tracking.  This is not a status meeting but a meeting to help the teams be lucky.  It is also not a meeting to agree joint actions or issue resolutions.  We will call a separate meeting for those things.
• For distributed teams, do the meeting over skype (or a similar tool) from their own desks.  Don’t have a meeting at one or more sites.   Skype is enough but you can use a virtual storywall or goto meeting if you want to display common information.
  • This allows people to tune out, which sounds bad. But it also allows them to instantly bring someone else into the conversation to confirm something (probably in the follow-up meeting in the second 15 minutes). It also allows them to check and email or send an instant message if they want to confirm something on the spot with their team
  • Don’t have a meeting at one or more locations because it seems to take longer to coordinate meetings at multiple sites and because people at each particular site rather than with those at the other sites … which is where there is more likely to be confusion or incorrect assumptions
  • If you have Yammer or similar then consider using a distribution group instead of having a meetning.  Then confirm everyone will update their information by a given time and check the information provided by others once a day.

With these rules in place I have had mixed results in the past.  I have often been in teams that found the meeting got dropped because it added no value and then we started complaining that we were confused about what other teams were doing. So even if the meeting should work, it is worth killing it and bringing it back again if it is not helping.

I have also found it morphs into a league of superheroes.  In this scenario it becomes a regular meeting for actioning things that don’t fit elsewhere.  But that is then a totally separate undertaking.

When it works though I have found it works really well for uncovering assumptions we are making about dependencies, scope and even existence of other teams. Once I found myself “signing the contract today” when someone else was “deferring the infrastructure rollout because the contract is delayed”.  There was a long discussion after the meeting and we realized we were about to sign a contract and simultaneously render ourselves incapable of meeting the commitments of the contract.  So one meeting saved a lot of distress later.

So – I wonder what will happen this time.