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?
One place to look for a framework is the System-of-Systems model, http://bit.ly/iUMHfD. This is a mature structure used in many domains. Managing the interfaces is the critical success factor. This is done through an Interface Control Document (ICD), that can be at any resolution needed to assure stability for the period of performance (development iteration).
Most agile based processes are focused in individual projects, the integration of multiple projects or work streams (in our enterprise domain where Scrum is used) have a systems engineering paradigm.This, along with the architecture of the enterprise system provide clear boundaries between the Scrum’s while maintaining all the benefits of individual Scrum.
The SoS model assumes smaller systems or components are interfaced to produce a fully functional “super-system”. That approach works (I speak from experience) though it violates a Scrum premise that stories should vertically slice through a system. Perhaps we need the concepts of component stories and system stories. The component stories can slice through components and the system stories can slice through the entire solution space.
The Scrum of Scrums approach requires more than just additional Scrum meetings. There are more serious integration and testing issues that the agile community needs to define. The SoS model may be a great place to start.
On my last engagement, we had 250 developers.
To my way of thinking, the premise of your post is incorrect: as small project methodologies are scaled for application to larger efforts, the various practices are modified to accommodate to the scaling. The dynamics in a 5 person team are simply not the dynamics of 20 teams working together. Thus, a daily meeting may be necessary for the Scummers, but the problems confronting the aggregation, hopefully the coherent aggregation, of 20 teams moves at a slower pace. Thus, the need for fewer meeting at the larger level of aggregation.
In a statistical sense, it’s hard for one element to move the mean when there are hundreds of contributers. Moreover, with aggregation, the distribution of outcomes scales also. That is to say: the confidence interval for the same level of confidence expands as the variance of multiple teams is combined into a distribution that describes the aggregated sum. So, if we think emergent progeny of one team, at a 95% level of confidence, will be within certain limits [they will produce umbrellas and not buggy whips at 95% confidence], the aggregated emergent interval is will be wider at the same level of confidence, allowing for a possible emergence of buggy whips in the aggregated total. What problem does the emergence of a buggy whip present? So long as umbrellas and whips do not violate agreed architecture of the system and are within the bounds of object APIs, hooray for emergence!
And what is a system? A system is an agreed structure, or set of structures, with agreed behaviors [leaving out a chaotic system which is still a system but the behaviors are unpredictable at an economic level of effort]. So, if there are no material violations, we still have a system, albeit one with a buggy whip
From a system engineering perspective, which Glen and I share, the architecture that arches over an endeavor of 100 developers is going to the slowest moving element of all. So also the changes in the interfaces between team objects. Each team is somewhat black-boxed by virtue of the backlog assigned to it. It [the Scrum team] can, and should, be emergent and agile within its box[es], but the architecture and the agreed manner in which the objects of each team will cooperate in a network to achieve a system response is a slow invariant.
Indeed, the magic of object development is that each object is in effect a node in a network of objects. [‘Good’ systems are networks and not hierarchies, in my opinion]. The performance of each node [to include failure at a node which includes failure of a Scrum to perform in a particular sprint] can be elastic not effect unduly other objects connected via node-node relationships. Nodes that are emergent in capability may shed an unnecessary relationship, or form a new and unexpected one, so long as the object API’s [interfaces] are not violated.