Do the Scaling frameworks stay true to Scrum?
Scaling Scrum, part 14
This is part 14 of the series:
The many approaches to scale Scrum — an introduction
Scaling Scrum, part 1medium.com
TL;DR — short version
LeSS stays closest to Scrum’s purpose and therefore it is my choice for small to medium sized scaling frameworks.
Scrum@Scale is Scrum scaled for the whole organisation. It is my choice for large scaling frameworks.
Spotify Engineering Culture may be a best fit for component teams.
SAFe puts Scrum’s purpose under heavy pressure. Therefore it scores lowest of all scaling frameworks.
As a general remark: think hard if you really need to scale Scrum.
TL;DR — longer version
If you really think scaling Scrum is needed this article is of help to you. Here are my assessment verdicts:
LeSS stays closest to Scrum’s purpose and framework as only little complexity is added (some events have a part with the team and a part with representatives of the teams). As a result LeSS is the best scaling option for small or medium sized scaling solutions.
Nexus is also true to Scrum, although the additional roles, events and artifacts add complexity. As a result Nexus scores lower than LeSS as a small to medium scaling options.
Scrum@Scale is a very interesting concept. The whole organisation (delivery and product, bottom to top) working in Scrum Teams. In theory this would be working very well and truly in the spirit of the Scrum Guide. Scrum@Scale wins the price of being the best large scale option.
SAFe puts the purpose of Scrum under heavy pressure due to it’s top-down approach, additional layers and as a result additional roles, events and artifacts. SAFe scores lowest of all the scaling frameworks.
Spotify allows for a lot of autonomy for the teams to work according to Scrum. The focus on small decoupled systems however is a different perspective than Scrum’s perspective of optimizing the value of a product. Spotify can be your scaling approach of choice if you don’t have the concerns of systems vs product.
Scrum of Scrums is the simplest solution to scale Scrum. Still one or more events are added that allow companies to ignore possible issues with cross-functionality and transparency. Scrum of Scrums also scores lower than Less on the small to medium scaling options.
Disclaimer
Before you think about scaling Scrum, consider if this will truly resolve your issues.
Don’t scale until you have fixed your issues with Scrum adoption. Many reasons to scale Scrum can be removed by ‘doing Scrum’ properly.
Scoring explained
I intend to asses by comparing Scrum of Scrums to Scrum according to the Scrum Guide. I will address how individual frameworks impact Scrum for every attention area. I will give scores from 1 to 5:
1: doesn’t meet the purpose as Scrum described it
2: barely meets Scrum’s purpose
3: some elements seriously impact Scrum’s purpose
4: has a small negative impact on Scrum’s purpose
5: fully meeting Scrum’s purpose
Why do I score it like this? Well:
Every role, event and artifact has a purpose. “Scrum exists only in its entirety” — Scrum Guide 2017.
Whenever the purpose is impacted by the way a framework is prescribing it this will have an effect on the rating of that part of the framework.
Scrum
For your reference: here’s the link to the Scrum Guide. My understanding of the Scrum Guide forms the basis of my assessment.
Scrum Guide | Scrum Guides
The official Scrum Guide provided in HTML format on the web.www.scrumguides.org
Note that for all frameworks it is assumed that Scrum is used as the framework of choice. This is assumed for SAFe and Spotify Engineering Culture, logical for LeSS, Scrum@Scale, Scrum of Scrums and Nexus.
Scaling frameworks
There are considerable differences between the Scaling frameworks. We at Serious Scrum have introduced the scaling frameworks in separate articles. Here are the links to these articles:
Introducing LeSS:
LeSS (Large Scale Scrum) — an introduction — Willem-Jan Ageling — Medium
This is part two of the series: The LeSS framework is one of the ways to scale Scrum. LeSS aims to start from a solid…medium.com
Introducing SAFe:
SAFe (Scaled Agile Framework) — an introduction
Scaling Scrum, part 3medium.com
Introducing Spotify Engineering culture:
Spotify Engineering Culture (Spotify Model)- an introduction
Scaling Scrum, part 4link.medium.com
Introducing Scrum of Scrums:
Scrum of Scrums, an introduction - Willem-Jan Ageling - Medium
The Scrum of Scrums is a way to scale Scrum to large initiatives. This solution is already around for more than 15…medium.com
Introducing Nexus:
Nexus - an introduction - Willem-Jan Ageling - Medium
This is part six of the series: Nexus is the scaling framework that is created by Ken Schwaber from Scrum.org. Yes…medium.com
Introducing Scrum@Scale:
Scrum@Scale - An Introduction - Paddy Corry - Medium
First question you might ask is: where is the other Scrum guy? The name of Ken Schwaber, the other name on the Scrum…medium.com
Assessment — Maximising Product Value
Scrum is:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — Scrum Guide 2017
This is the whole reason to use Scrum in the first place. For me it’s the number one thing that needs to remain in place. Hence the score weighs far heavier than those on events, artifacts and roles. I rate it three times as heavy than other scores.
LeSS
LeSS keeps Scrum intact. Most pivotal in this is that there is one Product Owner and that all moments of inspection and adaptation continue to have the same effect. LeSS also is the framework with the least amount of changes to roles, events and artifacts.
Score: 5
Nexus
Nexus has a number of extra roles, events and artifacts. This brings the risk of added complexity. But in essence all of the additions also help to serve alignment and transparency between teams and tackling integration. Also Nexus works with one Product Owner per product.
Score: 4
SAFe
SAFe has many additional layers above the team level. All these layers come with additional events, roles and artifacts. The responsibility for the product sits somewhere in a top layer and not with the Product Owner. Also SAFe has Release Trains typically taking five Sprints. These Release Trains can hinder timely inspection and adaptation in case items don’t bring the expected value. Then there’s the notion that all teams should work in a certain cadence. Also this doesn’t help teams to backtrack in case of wrong decisions.
Score: 2
Spotify Engineering Culture
The Spotify Engineering Culture model works with squads that are responsible for small decoupled systems. ‘Spotify’ emphasises the focus on (parts of) a system instead of the whole product. Scrum aims to deliver products with the highest possible value. Working on the most valuable item for a certain system doesn’t necessarily have to bring in high value for a product as a whole. The better choice can be working on another system. Within the Spotify solution it is pivotal to find a way to constantly assess if teams that work on a small decoupled system do work on the most valuable thing. This is not automatically arranged within the Spotify Engineering culture.
Score: 2
Scrum of Scrums
Scrum of Scrums aims to align between teams to maximise the product value. Having said this: this technique of aligning via the Scrum of Scrums runs the risk of ignoring the need for cross-functional teams. It gives an incentive to accept inter-dependencies between teams and as a result accepting that teams build parts of a total solution that only is “Done” when integrated.
Score: 4
Scrum@Scale
As with the Scrum of Scrums also Scrum@Scale aims to align between teams to maximise the product value. Having said this: this technique of aligning via the Scrum of Scrums runs the risk of ignoring cross-functional teams. It gives an incentive to accept inter-dependencies between teams and as a result accepting that teams build parts of a total solution that only is “Done” when integrated.
The Product Owner cycle of Scrum@Scale can be a very effective way to prioritise on value because all teams are effectively Scrum Teams. Having said this I can’t take this part into account in regards to the scoring, because it fills in some blanks that the Scrum Guide intentionally has.
Score: 4
Assessment — Empiricism
Empiricism — the cornerstone of the Scrum framework — for me has twice the weight of the roles, artifacts and events.
LeSS
LeSS leaves all artifact, roles and events intact and the Sprint Review is one event for all teams working on the same Product. This optimises transparency, inspection and adaptation.
Score: 5
Nexus
The additional roles, artifacts and events within Nexus are there because it is deemed important to have the additional alignment. This additional alignment has impact on transparency because information sharing is depending on representatives of teams. This then also means that inspection and adaptation are impacted.
Score: 3
SAFe
The SAFe framework has many roles, events and artifacts throughout the framework. Decision power is scattered allover, unlike how it works in Scrum. Teams are expected to work in a certain cadence in — typically — 10 week cycles. This all has a huge impact on your option to inspect and adapt. Below are some examples, but I could go on and on.
SAFe incentivises emphasis on reporting metrics rather than empiricism. You planned something during the Program Increment planning, are you ‘on track’? Within Scrum it is seen as a given that a team will find out new things that will have an impact on the Sprint Backlog and even the Sprint Goal. Within SAFe — promoting the cadence — you would severely impede other teams and slow those down. Therefore you think twice to deviate from the what was agreed upfront. Very un-Scrum.
The Release Trains also give you the incentive to deliver according to what was agreed during the Program Increment planning instead of inspecting and adapting every Sprint. Scrum basically says that you can’t plan beyond the Sprint. SAFe disregards this.
Score: 1
Spotify Engineering Culture
A ‘Spotify’ team is fully autonomous and as a result can work according to Scrum. Transparency, Inspection and Adaptation can be optimal.
Score: 5
Scrum of Scrums
Scrum of Scrums finds it important to keep Scrum intact. However adding events with representatives of teams only — and allowing to have a need for the events — do impact transparency because not everyone has direct access to the same information. Information can be easily accessible, but that is not the same as attending an event like the Scrum of Scrums. This also impacts the opportunity to inspect and adapt.
Score: 4
Scrum@Scale
Scrum@Scale is effectively scaling Scrum Teams to cover the whole organisation, bottom to top. As a result it — in theory — should be all about empiricism. The ‘Scrum of Scrums’ within Scrum@Scale are Scrum Teams, contrary to the approach ‘Scrum of Scrums’ (where it is an event only). As a result it doesn’t have the same negative impact on empiricism as with the scaling option ‘Scrum of Scrums’. I give the maximum score because all teams need to embrace empiricism. It should lead to radical transparency.
Score: 5
Assessment — Roles, Events and Artifacts
Below are individual assessments on roles, events and artifacts that result in one average score.
Scrum Roles
LeSS
The role of the Product Owner within standard LeSS is exactly the same as described in the Scrum Guide. There is one difference in LeSS huge (more than 8 teams). Here the Product Owner is assisted by Area Product Owners with an Area Product Backlog. The Product Owner however remains accountable for the Product Backlog as a whole.
The role of the Development Team within LeSS also is as in Scrum. Development Teams are self-organised and cross-functional.
Within LeSS the Scrum Master has the same role as within standard Scrum.
Score: 5
Nexus
The Product Owner within Nexus has the same responsibilities as within Scrum. However there is an additional responsibility: the Product Owner is part of the Nexus Integration Team.
Within Nexus the Development Team work as within standard Scrum. Development Teams are self-organised and cross-functional.
Also the Scrum Master has the same role as with standard Scrum. On top of this there’s a Scrum Master within the Nexus Integration Team. This Scrum Master needs to ensure that Nexus is understood and enacted.
An additional role is the Nexus Integration Team, responsible to deliver a “Done” integrated increment. This responsibility is taken away from the individual Scrum Teams. This adds to the complexity.
Score: 4
SAFe
The Product Owner within SAFe is responsible for prioritizing the Team Backlog, not the Product Backlog. This is trickled down from higher levels (Product Manager, maybe even Solution Manager or Epic Owner). This is not in sync with how Scrum views the Product Owner. In Scrum everyone should respect the decisions of the Product Owner. In SAFe the items are presented to the Product Owner.
SAFe proposes all kinds of best practices to be used by the Development Teams. SAFe promotes alignment in ways of working between the teams and emphasizes that all teams should work in more or less the same pace (they should develop in a cadence). So not only the Sprints are aligned (start, end, length), but also the working pace of the teams is aligned. The fact that teams need to move in a certain pace limits their self-organisation as described in the Scrum Guide.
The Scrum Master in SAFe has all the responsibilities that are also mentioned in Scrum. However a SAFe Scrum Master does more. She facilitates all the events (including the daily event), coordinates with other teams, helps facilitating additional SAFe events. Some of these tasks are not in line with the responsibilities of a Scrum Master as discussed by the Scrum Guide. A Scrum Master isn’t the coordinator of the team. The Scrum Master also doesn’t have to be at events like the Daily Scrum.
On top of the team level — at Program, Portfolio, Business level — SAFe knows many additional roles. One could argue that these are outside the “Scrum” space, but roles like Product Manager, Release Train Engineer, System Architect/Engineer, Solution Manager, Solution Architect/Engineer, Solution Train Engineer, Epic Owner, Epic Architect have impact on how the teams function.
Score: 1
Spotify Engineering Culture
Typically this solution has a Product Owner per small, decoupled system for which one team is responsible. It could be debated if these are really separate products. But since this is not defined within Scrum one can argue that the Product Owner can function according to Scrum.
Teams are indeed having all capabilities required to build and sustain the system for which they are responsible. They also have a lot of autonomy on how to build the increment, including the preferred tooling.
Assuming that the team adopts Scrum the Scrum Master role can be executed as described in the Scrum Guide.
Score: 5
Scrum of Scrums (SoS)
The Scrum Master (or another representative of the Scrum Team) has an additional role: being part of the Scrum of Scrums to align between teams. It can be argued that this type of alignment isn’t part of the responsibilities of a Scrum Master (according to the Scrum Guide).
The Product Owner role remains intact. Also the role of the Development Team stays the same.
Score: 4
Scrum@Scale
Within Scrum@Scale both the Scrum Master and the Product Owner are also part of a scaled Scrum Team which is either the Scrum of Scrums (Scrum Master) or the Meta-Scrum (Product Owner). In case of the Scrum Master it could also be another person of a Scrum Team. Similar roles are also for the higher level Scrum Teams (SoSoS, EAT, CCPO Meta Scrum, Executive Meta Scrum). As discussed with the ‘Scrum of Scrums’ solution it can be debated if the responsibility for the Scrum Master in this set-up is the same as what is expected from the Scrum Guide (planning vs coaching). The Product Owner gets a new way of aligning with her Product Owner colleagues and other stakeholders. I can’t rate this impact as Scrum isn’t prescribing how the Product Owner does her job of ordering the Product Backlog.
Score: 4
Scrum Events and Refinement
LeSS
Within LeSS the Sprints of all teams for one product start and end at the same time (thus having the same length). The Scrum Guide doesn’t tell anything about how to align this. So I see this as a practice that is according to standard Scrum.
LeSS splits the planning in two parts, like it happens in Scrum. Contrary to what Scrum says LeSS suggests to have representatives of the team only to discuss with the Product Owner on the Sprint Goal and a selection of items that meet the Sprint Goal. This could negatively impact transparency. The second part of the Sprint Planning sees every team as a complete team creating a plan to meet the Sprint Goal.
The Daily Scrum is the same as in standard Scrum.
LeSS has one Sprint Review per Product. The Scrum Guide isn’t prescribing this but it is generally seen as a best practice.
The Sprint Retrospective is split into two parts: Team Retrospective and Overall Retrospective. At the Overall Retrospective team representatives are taking part instead of the whole team. Optional is a manager.
LeSS recommends the following types of Refinement: Overall Product Backlog Refinement, Team-level Product Backlog Refinement, Multi-team Product Backlog Refinement. It also has recommendation on how to do refinement. Scrum is intentionally vague on this as there are many ways to Rome.
Score: 4
Nexus
The teams start and end the Sprint at the same time and (therefore) have same length. The Scrum Guide doesn’t tell anything about how to align this, so this is in line with Scrum.
Nexus also has the split between the first and second part of the Sprint Planning. The first part is called Nexus Sprint Planning though. It involves all members of the Scrum Teams, contrary to what LeSS advises. Also within Nexus a Nexus Sprint Goal is defined that is at the minimum the sum of the individual Scrum Team Sprint Goals.
In Nexus the individual Daily Scrum is the same as in standard Scrum.
Nexus also has one Sprint Review which is called the Nexus Sprint Review. This replaces the individual Sprint Reviews.
Nexus has the Nexus Retrospective which includes the Sprint Retrospective. It has three parts: a part of Nexus level with team representatives, the team part and then again on Nexus level to define how to follow up on the actions.
Refinement is an additional Event within Nexus, but how refinement is to be done depends per situation, as described within Scrum.
Nexus has one additional event: the Daily Nexus.
Score: 4
SAFe
SAFe dictates a length of the Sprints for all teams, typically 2 weeks. It also determines that the Sprints should be synchronized, as it is with the other frameworks. SAFe also dictates that Release Trains are a number of Sprint — typically 5 — and that the final Sprint is a hardening/planning Sprint. Hence SAFe has many items that differ from a standard Scrum Sprint.
On top of the Iteration Planning which is similar to Scrum there are also planning sessions on higher levels that have direct impact on how the teams can determine the Iteration Goals and backlog items: Program Increment Planning (taking 2 days), Solution Backlog, Portfolio Backlog.
SAFe has a Daily Standup that is quite similar to a Daily Scrum. Main difference is that the Scrum Master has an active role. In Scrum there basically is no role for the Scrum Master at the Daily Scrum. In SAFe she makes sure that the ‘meet after’ discussion is conducted to address issues raised at the Daily Standup.
Within SAFe the Iteration Review closely resembles Scrum’s Sprint Review. However SAFe is far more descriptive on what to do during this review.
SAFe Team Retrospectives are done very much like Scrum’s Retrospectives however more prescriptive.
Refinement within SAFe isn’t described in detail. It is assumed to be standard Scrum.
Apart from the events on team level there are multiple events that require the teams to be attending: Agile Release Train Planning, maybe even the whole Training and Innovation iteration of 2 weeks.
Score: 1
Spotify Engineering Culture
Assuming that a team works with Scrum within this approach the events are simply “Scrum”.
Score: 5
Scrum of Scrums
The Scrum of Scrums and optionally the ‘Scrum of Scrum of Scrums’ are additional events that can have impact on how teams work in a Scrum environment.
The original Scrum Events stay the same.
Score: 4
Scrum@Scale
The Scrum of Scrums and optionally the ‘Scrum of Scrum of Scrums’ are additional events that can have impact on how teams work in a Scrum environment as it adds complexity which can impact transparency.
The Product Owner cycle has all kinds of added events. This can be considered as one of the ways to make sure that the Product Owner has to order the items in the Product Backlog to best achieve goals and missions. The Scrum Guide doesn’t say anything about it and is therefore there’s no impact in the scoring by this cycle.
The original Scrum Events stay the same.
Score: 4
Scrum Artifacts and Definition of Done (DoD)
LeSS
LeSS uses one Product Backlog. LeSS Huge works with Area Product Backlogs which are fed by the overall Product Backlog.
Scrum Teams within LeSS work with their own Sprint Backlog as in standard Scrum.
The potentially release Increment should be integrated before the end of the Sprint. This is making use of the mechanism of standard Scrum.
LeSS doesn’t have any additional artifacts on top of the Scrum Artifacts.
Follows the definition of the DoD as described in Scrum. LeSS does have a number of best practices to define this while Scrum doesn’t.
Score: 5
Nexus
There is one Product Backlog within Nexus.
Scrum Teams within Nexus work with their own Sprint Backlog as in standard Scrum.
The Increment in Nexus is standard Scrum.
The Integrated Increment is a separate Artifact. It is the sum of all integrated work completed by a Nexus. Another separate artifact is the Nexus Sprint Backlog. This is the “composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams.” — Nexus Guide
Nexus also follows the DoD of Scrum and is intentionally non-descriptive about it.
Score: 4
SAFe
Every team has a Team Backlog, not a Product Backlog. This is trickled down from higher levels (Program Backlog, Solution Backlog, Portfolio Backlog).
SAFe works with an Iteration Backlog, similar to a Sprint Backlog.
The Increment in SAFe is a step towards the Program Increment and therefore far less prominent than within standard Scrum.
SAFe has many additional artifacts like increments on different levels and backlogs on different levels.
SAFe works with a DoD much according to Scrum but it stands in the shadow of the concept Built-In Quality.
Score: 2
Spotify Engineering Culture
A team is fully autonomous and as a result can work according to Scrum.
Score: 5
Scrum of Scrums
This approach doesn’t have an impact on the Scrum Artifacts and the DoD.
Score: 5
Scrum@Scale
This approach doesn’t have an impact on the Scrum Artifacts and the DoD.
Score: 5
Average score roles, events, artifacts
LeSS: 4.7
Nexus: 4
SAFe: 1.3
Spotify: 5
Scrum of Scrums: 4.3
Scrum@Scale: 4.3
Verdict
Here are the results from my assessment as I have described it in this article.
Product Value is the purpose of Scrum and this is why I weigh it 3 times the roles, events and artifacts. Empiricism is the cornerstone of Scrum and therefore I decides it has twice the weight of the roles, events and artifacts.
LeSS stays closest to Scrum’s purpose and framework as only little complexity is added (some events have a part with the team and a part with representatives of the teams). As a result LeSS is the best scaling option for small or medium sized scaling solutions.
Nexus is also true to Scrum, although the additional roles, events and artifacts add complexity. As a result Nexus scores lower than LeSS as a small to medium scaling options.
Scrum@Scale is a very interesting concept. The whole organisation (delivery and product, bottom to top) working in Scrum Teams. In theory this would be working very well and truly in the spirit of the Scrum Guide. Scrum@Scale wins the price of being the best large scale option.
SAFe puts the purpose of Scrum under heavy pressure due to it’s top-down approach, additional layers and as a result additional roles, events and artifacts. SAFe scores lowest of all the scaling frameworks.
Spotify allows for a lot of autonomy for the teams to work according to Scrum. The focus on small decoupled systems however is a different perspective than Scrum’s perspective of optimizing the value of a product. Spotify can be your scaling approach of choice if you don’t have the concerns of systems vs product.
Scrum of Scrums is the simplest solution to scale Scrum. Still one or more events are added that allow companies to ignore possible issues with cross-functionality and transparency. Scrum of Scrums also scores lower than Less on the small to medium scaling options.
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling