Scaling Scrum – Intro to Scrum@Scale

As one of the most popular and widely accepted agile frameworks, Scrum was envisioned and designed to enable a single team to perform its work at optimal capacity and at a sustainable pace. Given the rising volume and complexity of work performed during the development of a modern product (or service), most organizations eventually had multiple Scrum teams working together. The traditional management structure had proven insufficient for efficiently managing the interaction and coordination of these teams in an agile way. There was a clear need for a framework to fill the void and effectively coordinate multiple Scrum teams.

This new framework needed to provide:

• a minimum viable bureaucracy (MVB) – the least amount of governing bodies and processes needed for customer value delivery
• linear scalability – a network of teams which can grow without changing its essential characteristics
• business agility – reduce decision latency (time to make a decision)

To address the issue, Dr. Jeff Sutherland, a co-creator of Scrum, wrote a guide in 2018 describing his approach to best practices for effectively scaling Scrum – and thus the Scrum@Scale framework was born.

As in Scrum itself, the accountability of the “what” (product) is clearly separated from the “how” (process).

Basically, there are two separate cycles:

• Scrum Master Cycle (the “how”) – focused on efficiently running multiple development teams to produce product increments
• Product Owner Cycle (the “what”) – focused on the product itself, primarily maintaining strategic vision and product backlog, as well as release planning

In order to successfully scale Scrum, one needs to build a reference model that consists of a small set of teams successfully implementing Scrum and coordinating with each other to deliver every Sprint. This will serve as a template for further scaling. While building your reference model it’s best to group the teams into a Scrum of Scrums (SoS; effectively created by IDX Systems – now GE Healthcare).

It entails an MVB consisting of two leadership groups:

• Executive Action Team (EAT) – the hub of the Scrum Master Cycle, focused on getting it done faster. Regardless of the level of scaling, it fulfills the Scrum Master role for an entire agile organization by being the final stop for removing impediments to productivity as quickly as possible
• Executive MetaScrum forum (EMS) – the hub of the Product Owner Cycle, focused on the result produced by the SoS. Regardless of the level of scaling, it fulfills the Product Owner role for an entire agile organization by aligning all teams to maximize value delivery. This also includes the involvement of executives and key stakeholders

Essentially, a Scrum of Scrums can be imagined as a “team of teams” – a larger group whose members are Scrum teams themselves.

This implies introducing the scaled versions of Scrum roles (Scrum of Scrums Master – SoSM, Chief Product Owner – CPO), events (e.g. Scaled Daily Scrum – SDS etc.) and artifacts. If further scaling is needed you can use several Scrum of Scrums. The result is a Scrum of Scrum of Scrums (SoSoS) with additional scaled versions of Scrum of Scrum’s roles, events and artifacts.

Since Scrum@Scale is component-based, it’s easily customized to fit a particular organization and their transformation strategy. For the latest version of the definitive guide to the Scrum@Scale - checkout https://www.scrumatscale.com/scrum-at-scale-guide/

When applying agile practices for multiple teams and especially in the context of distributed software development, it’s always a benefit to use a more knowledgeable and experienced external partner. This will enable you to further improve any existing internal practices.

Software development nearshoring and consulting companies working in distributed teams on international projects have a lot of accumulated knowledge and experience in scaling agile practices. This puts them in a unique position to offer valuable guidance.

When searching for the right external partner to consult with regarding your software R&D challenges, there are some key issues to consider. We have provided a checklist to help with your search: