Tipping the Scale

By A. Narasimhan

One reason why Scrum is more popular than other agile flavors may be that it can be applied to all sizes of organizations. Because it can be scaled easily, Scrum is a good fit for both large and small teams. Just because scaling is easy, though, doesn’t mean it isn’t complex. You should be very cautious when deciding to scale to a new level.

You might need to add a second level if:

• You have several interdependent Scrum teams that need to communicate often and feel the need for formal communication among ScrumMasters or among teams.
• You have several teams working together on a single product, with inter-dependencies across modules. The teams need to consider interdependencies and risks due to these dependencies while planning their sprints. They would need a formal structure to enable proper planning.

Implementing the second level is easier said then done. Organizations should understand the true needs of such a structure. Planning a second level of scrum requires, at least, the following actions:

1. Set the number of teams and ScrumMasters at the second level;
2. Implement Scrum at the second level (including planning, daily scrum and reviews) just as you did in the first level;
3. Formalize collaboration meetings and set them at definite intervals, as they are the forum for discussing dependencies and making decisions that will impact several teams at first level;
4. Allow for process overhead incurred by the additional meetings and collaboration.

It is a good practice to fix the frequency and duration of second-level collaboration meetings, partially because the broad agenda of such meetings needs more focus. This agenda includes some specific items:

• Discuss dependencies across modules;
• Facilitate resource sharing across modules/teams;
• Confront issues that have escalated from the first level to the second level;
• Identify risks at the second level; and
• Share lessons learned and best practices from the first level that can be used across teams.

Though it is not advisable to share resources across teams, sometimes large development teams, especially during the first few sprints, cannot avoid sharing resources. In a team of 100, there normally may be about 5-8 database experts, 10-15 designers, and so on. Until the teams learn to take cross-functional tasks and until the expert centers are removed, sharing of resources might be needed. In such situations, the second level of Scrum would be a good platform to make decisions on resource sharing.

One of Scrum’s strengths is its flexibility. Even so, you should consider your organizational needs before deciding to scale Scrum. The complexities a second level introduces must be worth their cost.