Scaling Frameworks are used in organisations where a great number of teams are building a product. The number of teams is too big to be supported by the normal Scrum framework and therefor another type of framework is needed.
Recently Jeff Sutherland released his Scrum@Scale. This is one of many scaling frameworks introduced over the past years. Nexus, Less and SAFe are the most commonly known and perhaps the most used frameworks out there. If you use another framework, let me know, maybe I can add it to the post.
In this article I’ll give you a small introduction to the four frameworks and compare them on topics as events and artefacts, teams and sizing, roles, how is it integrated in the organisation and what the pros and cons are.
If you need in-depth information, I recommend clicking on the links underneath the chapters and you will be navigated to the framework websites.
Nexus
Nexus was developed and sustained by Ken Schwaber and Scrum.org
Nexus is a framework for developing and sustaining scaled product and software delivery initiatives. It uses Scrum as its building block.
It is basically a set of rules, and if you comply to it, Ken Schwaber thinks you can successfully implement this scaling framework and apply Scrum on multiple teams.
Nexus framework
Teams and sizing
Nexus is designed for 3 to 9 teams, it has only one Product Owner, one single product backlog, and one review. To integrate these teams, Nexus describes the need of an Integration team, which consist of representatives of all teams.
Events and artefacts
Backlogs and refinements
Nexus had one Product Backlog and is maintained by the Product Owner.
For the sprint there is a single Nexus Sprint Backlog and each team has its own Sprint Backlog.
The Product Backlog needs to be decomposed so that dependencies are identified and removed or minimized. Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified.
Integrated Increment
The Integrated Increment represents the current sum of all integrated work completed by a Nexus. The Integrated Increment must be usable and potentially releasable which means it must meet the definition of “Done”. The Integrated Increment is inspected at the Nexus Sprint Review.
Sprint Planning
Representatives from each Scrum Team meet to discuss and review the refined Product Backlog. They select Product Backlog items for each team. Each Scrum Team then plans its own Sprint, interacting with other teams as appropriate.
Daily Scrum
Appropriate representatives from each Development Team meet daily to identify if any integration issues exist. If identified, this information is transferred back to each Scrum Team’s Daily Scrum. Scrum Teams then use their Daily Scrum to create a plan for the day, being sure to address the integration issues raised during the Nexus Daily Scrum.
Sprint Review
The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the Integrated Increment that a Nexus has built over the Sprint. All individual Scrum Teams meet with stakeholders to review the Integrated Increment.
Retrospectives
Appropriate representatives from each Scrum Team meet to identify shared challenges. Then, each Scrum Team holds individual Sprint Retrospectives. Appropriate representatives from each team meet again to discuss any actions needed based on shared challenges to provide bottom-up intelligence.
Roles
Roles in Nexus are the normal Scrum roles. The only extra roles known in Nexus are the ones in the Integration Team. People participating in this Integration team aren’t new. They already have a place in one of the teams. The Product Owner is also part of this team.
The Nexus Integration Team is accountable for ensuring that a “Done” Integrated Increment (the combined work completed by a Nexus) is produced at least once every Sprint. The Scrum Teams are responsible for delivering “Done” Increments of potentially releasable products, as prescribed in Scrum. All roles for members of the Scrum Teams are prescribed in the Scrum Guide.
Product Owner in the Nexus Integration Team
A Nexus works off a single Product Backlog, and as described in the Scrum framework, a Product Backlog has a single Product Owner who has the final say on its contents. The Product Owner is responsible for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus. Like I mentioned, the Product Owner is a member of the Nexus Integration Team.
The Product Owner is accountable for managing the Product Backlog so that maximum value is derived from the Integrated Increment created by a Nexus. How this is done may vary widely across organizations, Nexuses, Scrum Teams, and individuals.
Scrum Master in the Nexus Integration Team
The Scrum Master in the Nexus Integration Team has overall responsibility for ensuring the Nexus framework is understood and enacted. This Scrum Master may also be a Scrum Master in one or more of the Scrum Teams in that Nexus.
Nexus Integration Team Members
The Nexus Integration Team consists of professionals who are skilled in the use of tools, various practices, and the general field of systems engineering. Nexus Integration Team Members ensure the Scrum Teams within the Nexus understand and implement the practices and tools needed to detect dependencies, and frequently integrate all artifacts to the definition of “Done.” Nexus Integration Team Members are responsible for coaching and guiding the Scrum Teams in a Nexus to acquire, implement, and learn these practices and tools.
Additionally, the Nexus Integration Team coaches the individual Scrum Teams on the necessary development, infrastructural, or architectural standards required by the organization to ensure the development of quality Integrated Increments.
If their primary responsibility is satisfied, Nexus Integration Team Members may also work as Development Team members in one or more Scrum Teams.
Integration organisation
Next to the presence of stakeholders in the Nexus Review, it doesn’t say anything about the integration within the organisation.
Cons
Nexus is limited to 9 teams and doesn’t involve the organisation. I believe this is big lack of information, because many organisation struggle with truly integrated agile.
I think Nexus is too limited, as it only goes for maximum 9 teams and doesn’t involve the rest of the organisation. The framework itself sounds very logical and isn’t very different from normal unscaled Scrum. If the number of teams will stay underneath 9, it could work for you.
Pros
Nexus isn’t much different than Scrum and has minor additions to let it function in a scaled environment. The framework is easy to understand and can be adopted rather quickly when you’re scaling teams.
Nexus is a very thin and light framework. So it’s easy to understand and to be experimented with.
https://www.scrum.org/resources/scaling-scrum
LeSS
LeSS (Large-Scale Scrum) isn’t new and improved Scrum. And it’s not Scrum at the bottom for each team, and something different layered on top. Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons.
Craig Larman and Bas Vodde created Less after years of experimenting at large organisation in a wide variety of domains.
Less framework
Teams and sizing
Less basic
The basic Less is for 2-8 teams (10 to 50 people) and is Scrum.
Not Scrum underneath layers of management.
Less teams are cross-functional. Not only coding and testing, but also include software design and architectural skills, business domain knowledge and UI/UX skills. Teams are responsible for requirement clarifications with the end-users and customers. Less teams do not build components but features and are the so called feature teams. Features that are customer-centric.
Less Huge
When there are more than 8 teams, Less does exactly the same, with only one difference. Namely one extra layer of Product Owners, called Area Product Owners with their individual requirement area.
Less Huge framework
Events and artefacts
Less is multi-team Scrum with one Product Owner and one product backlog. Less is a framework with a set of rules about the structure, product and sprint.
Planning
A sprint starts with Sprint Planning 1, where teams pick features from the top of the backlog that they will implement during the sprint. Sprint Planning 1 is followed by Sprint Planning 2 where teams discuss their strategies for developing their features.
Review and Refinements
During the sprint communication is done through inter-team coordination. There are no assigned coordinators. Like normal Scrum, there are backlog refinements and a shared Sprint Review where to explore what was done and to determine the best increment to develop next.
Retrospectives
Next to the team’s retrospective, there is an Overall Retrospective where organisational obstacles, that prevent high value delivery, are being explored.
Roles
Roles in Less are also the normal Scrum roles.
In Less Huge there is the addition of the Area Product Owners with their own specific area and teams. They function between the Product Owner and their teams.
Integration organisation
Less says that your organisation needs to change in order to allow Less to work.
Less adoption goes deep. It challenges conventional wisdom about projects, products, roles and management practices.
For instance, the role of a manager. The manager should help the team learn and improve the capability of the development system.
Pros
Less aims for more responsible teams with fewer role distinctions. By giving fixed responsibilities to named roles takes them way from the teams. So Less does this differently and creates self-organising teams. Same goes for the number of artefacts and tools. Less keeps the number of artefacts down to a bare minimum and focuses on a working product.
The integration within the organisation is for me a very big advantage. At the same a time it is a very big challenge and fortunately the people from Less are determined in teaching the willing organisations out there.
And there is the focus shifting of the manager. To me, this is essential for the chances of success.
This makes Less, in my opinion, a very complete scaling framework.
Less looks to me like the most applicable of all frameworks because of their intension to change the entire organisation and because of their firm believe in the different responsibilities of management. The framework consists of logical rules and an adoption is an actual organizational design change.
Cons
To adopt Less in your organisation, you need to change it. For me this is an advantage, but it could very well be a disadvantage for you and your organisation.
Scrum@Scale
Scrum@Scale (S@S) is designed for very large companies and claims it’s a scaling framework for the organisation as a whole: all departments, products and services.
| Dr. Jeff Sutherland developed Scrum@Scale based on the fundamental principles behind Scrum, Complex Adaptive Systems theory, game theory, and object-oriented technology. Scrum@Scale was created to efficiently coordinate this new ecosystem of teams in a way that optimizes the overall strategy of the organization. It achieves this goal through setting up a “minimum viable bureaucracy” via a scale-free architecture, which naturally extends the way a single Scrum team functions across the organization. |
Teams and sizing
S@S doesn’t say anything about the number of teams. But it is a scaling framework, so obviously it should be applicable from about approximately 5 teams.
In a video Jeff Sutherland says that S@S is feasible for thousands of teams. The first challenge is to create a small set of teams that implements Scrum well. This set of teams works through organisational issues that block agility and creates a Reference Model for Scrum that is known to work in the organisation and can be used as a pattern for scaling Scrum across the organisation. As the Reference Model of teams accelerates, impediments and bottlenecks that delay delivery, produce waste, or impede business agility become apparent. The most effective way to eliminate these problems is to spread Scrum across the organisation so that the entire value stream is optimised.
| Scrum@Scale achieves linear scaling in productivity by saturating the organisation with Scrum and distributing velocity and quality organically, consistent with the organisations’ specific strategy, product, and services. |
Roles
This framework has normal Scrum roles at the bottom teams. The teams above the bottom ones have its own roles, named after Scrum roles. In my opinion, these extra roles have different responsibilities. I’ll mention the roles in the next few subparagraphs.
Events and artefacts
SoS
A set of teams that have a need to coordinate comprise a “Scrum of Scrums” (SoS). The SoS has a Scaled Daily Scrum (SDS) for coordinating the teams and removing impediments. Every SoS has its own Scrum Master.
SoSoS
In a very large environment, S@S says that a Scrum of Scrum of Scrums (SoSoS) is needed to coordinate multiple Scrum of Scrums and this construction is an organic pattern and infinitely scalable. Each SoSoS should have SoSoSM’s (Scrum of Scrum of Scrums Scrum Master) and scaled version of each artefact and event.
EAT
And then there is the EAT (Executive Action Team), the Scrum of Scrums for the entire organisation. The EAT is an organ that is the final stop for impediments that cannot be removed by the SoS’s that feed it. Again, the EAT has its own PO, SM and backlog.
Executive Action Team
MetaScrums
A team of PO’s and stakeholders are known as MetaScrums. In this group of people the What is discussed. And again, another backlog, SM and Product Owner called the Chief Product Owner.
The MetaScrums can also be scaled. The Chief PO will add another Chief to his or her title and becomes a Chief Chief Product Owner.
The MetaScrum for the entire organisation is the Executive MetaScrum.
Integration organisation
S@S integrates with the organisation through the Executive Action Team (EAT).
| Scrum is an agile operating system that is different from traditional project management. The entire SM organisation reports into the EAT, which is responsible for implementing this agile operating system by establishing, maintaining, and enhancing the implementation in the organisation. The EAT’s role is to create an Organisational Transformation Backlog (a prioritised list of the agile initiatives that need to be accomplished) and see that it is carried out. For example, if there is a traditional Product Development Life Cycle in the old organisation, a new agile Product Development Life Cycle needs to be created, implemented, and supported. It will typically support quality and compliance issues better than the old method but be implemented in a different way with different rules and guidelines. There are many other aspects of organisational development and governance that may need retuning. |
Cons
As you can see, S@S is full of roles, artefacts, events, extra layers, titles, etc. At a glance it looks very complex and it didn’t strike me when I read about Service Level Agreements between PO’s with their backlogs and teams of specialists.
A lot is dictated in S@S, like the use of velocity, release plans, deployment, Scrum of Scrum Masters being responsible for deployments, etc.
Pros
The S@S guide is very elaborate.
SAFe
SAFe, created by Dean Leffingwell, stands for Scaled Agile Framework and is meant to cover the entire organisation.
It has four configurations in which you can operate.
Every configuration has a set of levels underneath.
- Essential SAFe (Portfolio, Large Solution, Program and Team)
- Portfolio SAFe (Large Solution, Program and Team)
- Large Solution SAFe (Portfolio, Program and Team)
- Full SAFe (Program and Team)
Essential SAFe with its four levels
Teams and sizing
Within the program level, there are teams comprised and it can consist of 50 to 125 people. At the team level you may work like Scrum or Kanban with a Product Owner, Backlog and iterations.
Events, roles and artefacts
The teams in the program level are called an Agile Release Train (ART). The output of ART is a Program Increment (PI) and is based on a Program Backlog maintained by the Product Manager. The governance falls in the hands of a Release Train Engineer (RTE), also called the Train Scrum Master or Program Manager. To smoothen the train track, SAFe came up with an architectural runway, facilitated by the Train System Architect.
PI planning
In the PI planning meeting, the vision, roadmap of the train and features of the upcoming PI are presented. Each team then identifies what objectives it can achieve and which risks and dependencies can occur.
System Demo
After an iteration, there is an event called System Demo. In which the PI is demonstrated.
Please take a look at my post about the why it is a bad idea to call this a demo.
Large Solution
When a single ART can’t deliver a solution, because of its size, SAFe introduces Large Solution. The content is managed by Solution Management and the Value Stream Engineer or Solution Train Engineer (STE) is the coach and guide.
Integration organisation
To integrate with the organisation, strategic themes are created at the portfolio level.
At this level the direction for all underlying value streams is managed by deriving the themes and allocating budgets.
Cons
The framework is very prescriptive in the responsibilities of their newly introduced individual roles, processes and artefacts.
I see this as a disadvantage. The framework is too big and complex that I wonder if there is any agility left. I have spoken to a lot of SAFe adopters (developers and RTE’s) and most of them aren’t very happy with it. Maybe there are people and organisations out there, who can bring some positive news about SAFe [Symbol].
Pros
I see SAFe implemented at the more classical organisations and I think this is what SAFe does best. They leave the organisation intact, as far as possible, and tries to scale the rest with extra roles, events and artefacts.
They are good in creating nice interactive posters online, offer a lot of certification opportunities and launch a new version of SAFe every now and then.
https://www.scaledagileframework.com/
Conclusion
These four frameworks claim to have exactly the same goal: creating the best possible customer-centred product.
But in all fairness, the frameworks are very different.
My advice is to experiment and try to create your own framework that is tailored for your organisation, products, teams and clients. Use some elements from these frameworks, think of a logical structure and start with a small set of teams, learn from doing and grow from there.
