Scrum of Scrums: Can Agile really scale?

 

While I’ve been a big advocate of using Scrum for time critical projects involving new product and software development, I’ve not been convinced this project method works for very large scale, multi-located or globally dispersed project teams.  Scrum has had the most success in software development and when coupled with Extreme Programming (XP).  The reason for this is that XP advocates pair-programming and co-located teams which is conducive to Scrum’s facilitation of self-organizing and cross functional teams.  There are other aspects to XP such as unit testing and continuous and integrated builds which is also conducive to Scrum’s iterations of sprints.  But it is the close proximity of teams and communication which allow Scrum and XP to work so well.

But can this scale to large, globally dispersed and multi-located teams?

Some in the Agile community say it can and some have called it managing a “Scrum of Scrums”.  Mike Cohn was one of the first to advocate this.  But his focus is mainly on how to run stand up meetings with multiple Scrum teams.  While I think this is important, it doesn’t quite cover the huge gamut of processes that would have to take place to effectively run a Scrum of Scrums.  This post by Vin D’Amico of BrainsLink.com is a good summary of the gaps you must address for doing a Scrum of Scrums:

• 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?

I don’t think Agile/Scrum adequately address this.  Glen Alleman of the popular Herding Cats blog agrees and states that what the Scrum proponents are advocating with a Scrum of Scrums is a notion from the System Engineering field established before Scrum which is the idea of managing a System of Systems.  As he states, “all this tells us is that simply having multiple Scrums working on multiple threads in the project may be necessary but is far from sufficient for success. Much more is needed to control, coordinate, and define the processes between and among these parallel work elements.”

I found the picture below which gives a good graphical diagram of what a Scrum of Scrums could look like:

As can be evidenced even in this simple diagram, there’s a complex flow of communication, coordination, processes and work that would have to be managed using a rigorous system oriented approach to ensure the self-organizing, “emergent” deliverables from the Scrum of Scrums get completed on time, within budget and to scope/requirements.

If any readers out there have managed, attempted to manage or thought about managing a Scrum of Scrums, please let me know!