You may find the following useful if you have challenges running effective daily scrum meetings with a larger geographically distributed team. You might be finding that it takes more than 10 minutes, is awkward, shares no new understanding and results in no one doing anything different. Some people may be complaining that you’re not Agile enough and you need a smaller co-located team, and others may have decided that Agile is ineffective.
We got interested in this problem because we’ve been working in a business intelligence scrum team distributed between four cities in two time zones with a wide range of levels of technical expertise, agile experience and common sense. With about 12 people in the team it was too many for group discussions to flow naturally, but not quite enough people due to skill and role distribution to split into two teams.
The solution concepts were
the team to accept that everyone would need to prepare individually for the meeting and share their preparation with the rest of the team
the scrum master to set aside time every day to check the above shared preparation and follow up if it was missing, inadequate or indicated other actions were needed
the scrum master to enforce a short meeting with a rigid structure
The solution in practice
At the end of each working day, each person not only checks that the scrum board is up to date, but he or she also fills in a daily scrum focus table in a “scrum notes” document/page for the next morning’s meeting. There is a new table for each day. Where people know what they are doing this typically takes a couple of minutes. Where they don’t know what they are doing it is a useful prompt for them to ask for help.
First thing the next morning the scrum master has a look at the table and takes action accordingly. This normally takes 15 to 30 minutes immediately before the daily scrum meeting and most reminders or questions are sorted out with a brief face to face chat or an instant message. Sometimes people can’t be found like Colin in the example above and the scrum master can add a reminder to the notes.
Because of the distribution of the team the meetings are done on conference call, looking at the scrum master’s screen share. The meeting typically only takes 10 minutes, the scrum master knows what’s going on already and running through the meeting allows everyone in the team to see what everyone else is up to. It serves as governance on the daily development process and a trigger for other team members to contribute to solving problems.
Note in particular
The names are in alphabetical order - having a strict order helps on conference calls to speed up the meeting.
In colocated teams we’ve had lots of fun throwing rugby balls/cuddly toys/rubber chickens at each other at random to decide who does their update next, which is a great way to keep everyone on their toes. It means Aaron doesn’t get to take a nap between Beth and Zach’s updates. The downside is that the more timid people are chanting “is it me next” under their breath rather than listening before their turn.
The original approach was to have a table with a single column which said “planned work for today”. It didn’t work.
We took that approach on a much earlier project at a different client with smaller teams where we just needed an efficient daily summary for some people who couldn’t attend, rather than an effective meetings tool. It was well received and quick to write, so was successful in that context.
When we tried that with our 12 person team, for each person in turn we’d look at yesterday’s list and ask there were any problems doing it all, then scroll to today’s list to find what was planned for today. Then for the next person we’d scroll back to yesterday’s list. We spent more time scrolling than talking. It was distracting when the approach should have been making us focus.
It proved more effective to have separate columns for “problems end of yesterday” and “planned work for today”, and for people to write in “problems end of yesterday” any planned work they hadn’t completed.
Counting the effort days remaining was done manually by the scrum master looking at the board.
Having a report to create the summary might have been useful but actually we got value out of the scrum master reviewing the board.
If there are too many tasks for the scrum master to add up mentally then there’s too much detail on the board.
Counting effort days works given we normally create Jira subtasks that are assigned to only one person, and any time spent working on other people’s tasks comes out of the unallocated time. This is a flawed way to account for time because it doesn’t directly highlight the value added by people helping each other, but it has been useful showing when individuals have become overloaded and need that help.
We kept the daily scrum focus tables in the Confluence page for the sprint.
The scrum master having to manually collate the updates from all the individuals sounds like an old fashioned waste of time, so some kind of collaborative edit document is essential. This process is supposed to increase team effectiveness by enabling individuals to prepare independently, not waste scrum master time.
Other Considerations and References
Creating the daily scrum focus table seemed redundant given that there’s a scrum board in Jira. We had thought that we should just be able to look at the scrum board and have the relevant conversations. That’s how it generally worked with some teams we’ve worked in.
The key insight here is that each member of those skilled teams goes to the daily scrum meeting with their part of a mental daily scrum focus table already mostly prepared, and they can finish the preparation on the fly.
When people are less experienced then they go to the meeting with less of a mental model, and also have less ability to finish that preparation on the fly. This is compounded by the time pressure of a large team meeting needing each update to be very short. Even the experienced people benefit from preparation in those circumstances.
The daily scrum meeting itself becomes a checkpoint on the more important activity of doing the preparation. As mentioned above, in small teams of experienced people, the preparation can be completed in the meeting itself, but with larger teams this can fail and people can finish the meeting not knowing what other people are doing and perhaps not even being sure of their own work. The real goal is not to have a daily scrum meeting but to get everyone to assess progress daily and ask for help when needed.
We could look at eliminating the daily meeting altogether, but we expect we’d lose some focus and make more work for the scrum master chasing people because not everyone is very disciplined. The pressure of the cadence of preparing to present in front of others seems helpful. There are fun ways to scale out the pressure to prepare without making the meeting longer, though that kind of thing changes the content substantially.
We have one day a week where we fill in the daily scrum focus table but don’t have a meeting. We don’t really look at other people’s notes on those days. It’s good to save some time on those days. But we’d see the purpose of having an actual daily scrum meeting as being to listen to our colleagues and work out how we can help while still getting our own work completed. By using preparation techniques like the above this can work in a larger geographically distributed team.
By Pete Grant, thanks to Steve Frowen for review and suggestions.