Scalable Scrum Frameworks

Author

James Pace

Published

February 24, 2024

Scrum is a popular lightweight framework that defines how a single team can work towards a goal and is very popular in software engineering circles. Scrum is the most prescriptive of the frameworks that claim to be “Agile”, and is probably the initial approach most teams reach to when they are trying to be more “Agile”. If you’ve worked on a “Sprint” to work down tasks in a “Backlog”, you’ve probably been doing Scrum.

The official definition of Scrum is found in the Scrum Guide.

The big idea in Scrum is there is a single “Product Owner” who is accountable for managing a “Product Backlog”, which is a list of tasks that need to be done for a project. Teams work to complete those tasks by completing a “Sprint” over a fixed time interval. A “Sprint” involves:

  1. Defining a goal for the end of the sprint.
  2. Picking which tasks from the “Product Backlog” will be worked on for the sprint.
  3. Working on those tasks, and communicating daily to make sure there are no blockers.
  4. At the end of each sprint, delivering some sort of deliverable working towards the final deliverable (called an “increment”1).
  5. Doing a retrospective and adjusting the process and backlog given any information learned since the last sprint.

The Scrum Guide largely defines how a single Scrum team is built and works. There are three popular approaches to extend Scrum to work for multiple teams:

  1. Nexus
  2. LeSS
  3. SaFE

Nexus

Nexus is the most light weight and least prescriptive of the three aforementioned options.

Nexus starts with multiple scrum teams, all working on one product, who practice Scrum as normal working from a single backlog of tasks. To keep the individual Scrum teams from stepping all over each other, Nexus adds a “meta” Scrum team called the “Nexus Integration Team” that is responsible for the coordination between teams, and for combining the output of the inner Scrum teams into a single combined output. The integration team is made up of selected members of the inner Scrum teams.

Of the three options in this article, I would lean towards Nexus if I was running a small start up that had just outgrown every one being in one Scrum team. Nexus would be easiest to apply, with the least amount of extra work and management layers.

LeSS

LeSS (for LargE Scale Scrum) is similar to Nexus, in that if you squint, it is basically inner Scrums wrapped by a bigger Scrum, but the bigger Scrum doesn’t have its own team. Compared to Nexus, LeSS is also a lot more prescriptive. Where Nexus leaves a lot up to the reader to figure out, LeSS provides a lot of guidance, answering a lot questions in their guide that Nexus leaves up to the reader.

LeSS suggests roughly the following process for a sprint:

  1. Sprint Planning 1, where the product owner communicates the things that need to be done to all of the teams, who proportion the work out amongst themselves.
  2. Sprint Planning 2, where the teams work to convert what needs to be done into individual tasks that can be worked on.
  3. Teams then go off and do Scrum to work on those tasks, refining the backlog and communicating with eachother as they go.
  4. At the end of the Sprint one Sprint Review is completed with all teams, and then two Retrospectives are completed, one for each team and one for the Scrum as a whole.

Of the three options in this article, I would lean towards LeSS if I was in a small but already established company. I think the extra prescriptiveness of LeSS can help pre-answer questions people will have in a company that is big enough that the person making the decision to switch can’t individually talk to everyone, but also small enough to not have decades of internal politics to wade through.

SAFe

SAFe is the most prescriptive of the methods in this article, and arguably the least agile. SAFe has multiple complicated layers of management, but all the complicated levels are clearly documented with their explicit roles spelled out clearly.

My impression is SAFe only really makes sense in a large organization where there already is a multilayered management system, and that system is seen as good.

Footnotes

  1. Think “incremental deliverable” but with less letters.↩︎