Tipping the Scale

What to Know Before You Add a Second Level of Scrum

20 December 2007

Narasimhan Anantharangachar
Sripadam Management Consultants

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Aniket Mhala, CSM, 12/27/2007 6:50:01 AM
I liked the idea of leveling. However implementing /scaling Scrum across different functional areas (Quality Management Group, Delivery Group, Support group, Education Service Group, Technical Infrastructure group and so on…) of an organization is challenging and complex stuff.

We can use Agile Transition / Scaling model to smoothly implement/scale agile across the organization.

At Organizational level, we can consider the agile transition/scaling as separate project/program which will have transition/scaling backlogs and will have separate transition/scaling team. It will be main responsibility of this team to adopt/scale agile at organization level in agile way (iteration by iteration) by interacting and providing guidance to all cross functional areas of the organization. I think I got this idea from one of the article/presentation of Mike Cohn and it is working very well for our big organization despite of couple of challenges.
Narasimhan Anantharangachar, CSM, 12/28/2007 4:16:43 AM
Aniket, what you say is right. While transition is a bit longer, scaling itself might be a shorter activity and very focussed. Ken Schwaber's Enterprise Scrum talks about transition backlog, reporting relationships etc. at the enterprise level.

You must Login or Signup to comment.