“That’s why we need to use a scaling approach”
Some time ago, I was in a debate with someone who claimed the following:
“Scrum is a framework suited for a single team. The entire Scrum Guide talks about the Scrum Team. But often you need more than one team to build a product. For this, Scrum is unsuited.”
The person with this observation suggests a scaling framework instead of Scrum. His point of view is incorrect.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F483a8b14-c4c9-4f80-8c35-ab219110aa04_800x533.jpeg)
I will take a deep-dive into the topic, starting with the definition of Scrum:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017
The word team is not here. Instead, the definition mentions people delivering products. Then, the Scrum Guide elaborates on Scrum:
“The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.” — Scrum Guide 2017
Teams are plural, meaning more than one. Does this settle the discussion then? It is not this simple, because this is what the Scrum Guide sees as the essence of Scrum:
“The essence of Scrum is a small team of people.” — Scrum Guide 2017
Some say this confirms that Scrum only works with one small team. I don’t agree. It only states that teams should be small. It doesn’t exclude that more small teams work on one product.
From here, the Scrum Guide continues to focus on the Scrum Team. It already established that the framework consists of one or more teams. Each Scrum Team has the same characteristics. As a result, it makes sense to discuss the characteristics of a team.
But there’s more…
There’s more in the Scrum Guide when we focus on creating products. Here’s an interesting snippet from the Product Backlog section:
“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.” — Scrum Guide 2017
This important statement doesn’t have a prominent spot in the Scrum Guide. But the consequences of what it says are huge. One Product Owner — solely responsible for the Product Backlog — works with one or more teams.
But there’s more:
“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” — Scrum Guide 2017
This line is from the Increment section. It says that multiple teams all work on Product Backlog Items from one Product Backlog. Together they create one Increment. And it doesn’t stop here:
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. — Scrum Guide 2017
The Scrum Teams and their stakeholders inspect the Increment and adjust course at one Sprint Review.
To sum it up:
One or more teams work together with one Product Owner, from one Product Backlog, creating one Increment, having one Sprint Review.
With that, it is clear that Scrum is a framework to build a product with one or more Scrum Teams.
What about the scaling frameworks?
But what about Nexus and LeSS? What about Scrum@Scale? Scrum is already suited for multiple teams. Why do these scaling approaches exist?
The people from Large-Scale Scrum (LeSS) simply state that LeSS = Scrum. I see their point, although there are nuances where LeSS deviates from pure Scrum.
Scrum@Scale uses Scrum everywhere. Scrum Teams are all over the organisation and there is alignment between all of them. Scrum@Scale respects Scrum as is and, as such isn’t an alternative to having multiple teams work on the same product.
Nexus also leaves the core of Scrum intact. It is an exoskeleton around Scrum. Yet, it does add events, roles and artifacts to manage multi-team product environments. Created by Scrum.org, it suggests that multi-team product development requires more than Scrum alone. This is add odds, in my humble opinion, with what the Scrum Guide states and what Scrum offers.
Scrum with multiple teams
How to picture Scrum with multiple teams? Well, here’s an example.
It all starts with a Product Backlog, holding all things known to be needed for the product. One Product Owner is responsible for this Product Backlog. Multiple teams use this one Product Backlog to help build the Increment.
At the start of the Sprint, the Product Owner has multiple ways to plan the work with the Scrum Teams. She or he could do this per individual team, but the most logical approach is to at least start the Sprint Planning with all the teams involved. They will be able to align the respective Sprint Goals with the Product Owner and the other teams. After this, they can continue planning their Sprint.
Scrum Teams all have their own Sprint Goal, Sprint Backlog and Daily Scrums. They should be able to work on their Sprint Goal without help from outside the team:
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” — Scrum Guide 2017
During the Sprint, teams work towards their Sprint Goals, finishing their selected Product Backlog Items from their Sprint Backlog. The sum of all work of the Development Teams is the Increment. Development Teams might need to integrate their work as part of the Definition of “Done” but this doesn’t have to be the case.
At the Sprint Review, the Product Owner and her/his Scrum Teams discuss the Increment with the stakeholder and talk about what would be a good next step.
Does this look like LeSS to you? Well, I don’t think that is a coincidence. Still, I only brought forward what you can find in the Scrum Guide, except for the way to plan the Sprint.
Endnote
Scrum is a framework to create products of value in a complex environment with one or more teams. The Scrum Guide is clear about this. LeSS and Scrum@Scale, two Scrum scaling frameworks, acknowledge that Scrum is sufficient to work with multiple teams. Nexus, however — created by Scrum.org of the Scrum co-founder Ken Schwaber — brings forward Scrum isn’t sufficient. This is strange. As far as I can see it, the Scrum Guide and the Nexus Guide are at odds with each other on this point.