In Scrum, there is a Scrum Team that works from a single Product Backlog. The Scrum team sprints against chosen Product Backlog items and then creates a growth of possibly usable, shippable, functionality at the end of the Sprint. At the surface level, Scaling Scrum is just the same. One single Product Backlog provides the required input to Sprint. At the Sprint end, there would an increase of potentially shippable functionality that has been developed and ready for usage. Whichever the case might be, on one or multiple Sprints, a Product Owner can choose to employ one Scrum team or more than one. The composition or number of these Scrum teams may or may not remain the same throughout.

Why is it required to scale Scrum?

The main reasons for scaling Scrum are:

1. The need to complete the functionality at a rapid pace by putting additional Scrum Teams to work on the Product Backlog.
2. Scaling is required when there is a necessity to align more than 1 scrum team under a program or portfolio.
3. The need to bring together teams under a common mission, synchronize their events, normalize their estimation, so tracking & measuring becomes easy.

Once a certain number of Scrum Teams start working together on Product Backlog, there is an increase in the number of complications, non-linear events, and interactions. There is linear co-relation between creativity and productivity and the Scrum Teams. The Product Owners who employ more than one Scrum Teams need to analyse and carefully evaluate both costs and benefits.

All the basic principles, values, artefacts, meetings and roles in Scrum apply, irrespective of whether the composition is scaled or singular. These are to remain unchanged for risk control, developing creativity, productivity, besides being able to be absolutely transparent.

Scrum.org has developed this Scaling Scrum which is a program for managing and operating the initiatives of multiple Scrum Teams.  Techniques for the organization and selection of Product Backlog points, solving dependencies, integrating work, and creating “done” increments are assessed. Techniques are unique and pliable enough to change with the requirements since all development situations are different in terms of people, domain, technology etc.

What does scaling of Scrum involve?

Scaling Scrum is a project that requires an active hands-on approach where participants get an in depth understanding of nuances and instances of scaling Scrum that can work for their own projects, initiatives, releases, and/or organizations. It is essentially an amalgamation of setting up, running, coaching, and optimizing multiple Scrum team initiatives.

The program for Scaling Scrum provides metrics for measuring the value that is generated by the way of functioning chosen for a multi-team Scrum project. It is the management that monitors the metrics and therefore the techniques too can be adjusted for increasing the value of results.

If you have a big product with complicated programs and even bigger problems, you need to scale up Agile Scrum implementation to other locations and many more teams. It is here that the Scaled Agile Framework® (SAFe) would come to your rescue in terms of school of thought and knowledge domain. SAFE provides a large structural base for scaling the Agile principles and Scrum processes to a much larger environment and the largest enterprise. Lately, companies not only belonging to Silicon Valley have not only completely embraced Scrum but have also adopted SAFe for scaling Agile implementation for their enterprises.

For ready reference, one can visit the ScaledAgileFramework website for a proper breakdown of SAFE framework which includes program, team, and at the portfolio levels. The framework has been described in the form of a diagram known as the “BIG Picture”. Elements of this “BIG Picture” diagram on the SAFe website includes roles, activities, teams, and artefacts, that can be clicked for reading detailed descriptions of each. This is indeed a good way to start learning about SAFe.