The concept of using Scrum-of-Scrums meetings for large projects following the Scrum approach presents major problems. Mike Cohn has written on the subject. So has Tim Bowler. I think it is more complicated than they suggest.
Let’s say you have a project with 100 people assigned. I know 100 people seems like a lot but it’s not unusual in a big company. Imagine we have an average of 5 people on a Scrum team giving us 20 teams. The teams will have to be grouped in some fashion. Imagine there are 4 groups of 5 teams.
We now have 20 daily Scrum meetings, 4 daily Scrum-group meetings and 1 daily Scrum-project meeting. Here are the problems:
- A lot of daily meetings. Granted, worst case is that someone at the top of the hierarchy must attend all three types of meetings. To lesson the burden, it may be better to reduce the frequency of the Scrum-of-Scrum meetings. Two or three times per week may be sufficient.
- The big picture may be lost. Each Scrum team has a ScrumMaster and a Product Owner who are experts in their areas. Who is the expert on the entire system? Who will ensure that the components developed by the teams will fit together and operate cohesively?
- Coordination is missing. The Scrum teams cannot go merrily along developing their pieces of the solution in isolation. There must be significant coordination among the teams. How does that happen? How does everyone stay busy without wild swings in workload?
- Vertical slicing becomes very difficult. Scrum teams are encouraged to implement features not components thus biting off vertical slices of the system. Doing so across multiple Scrum teams creates major configuration management problems. It can be done and it will be difficult.
- Testing becomes an even bigger problem. Features and components may work properly but the complete system may not. Who tests the entire system? How are the testing efforts coordinated?
Get the idea? You may need a Scrum-of-Scrums meeting focused on software construction issues. You might need another one for testing issues. You will certainly need some kind of meeting for high-level project planning and coordination. I know — more meetings. You’ll also need to involve more people who can focus on the big picture without getting mired in the implementation details.
Running a large project (yes, it’s one project not a collection of projects) consisting of many Scrum teams is much harder than it looks. I haven’t come across anyone offering a complete and realistic way of using the Scrum of Scrums while preserving the essence of the Scrum approach. Have you?