Key Takeaways

 Scaled Agile works, and using a scaling framework help you get a quick start.

 All scaling frameworks share some common patterns: Scrum at team level, many teams sharing
a backlog, planning is done collaboratively across teams, and the general principles of pull and
self-organization.

 If you know Scrum really well, LeSS is the “no-brainer” framework for scaling, and you might
never need anything else.

 SAFe provides a lot of guidance, and covers a broader scope than the other frameworks,
including financing and enterprise architecture.

 Scrum@Scale prescribes very few practices, but is a good tool for tailoring your own scaled
Agile implementation.

You can organize multiple Scrum teams in many different ways. In this article we
compare LeSS, SAFe, and Scrum@Scale based on our work with these frameworks. There are
other frameworks for scaling Agile such as DAD (Disciplined Agile Delivery) and Nexus, but they are
not covered in this article.
Scaling
According to Craig Larman and Bass Vodde (the creators of LeSS) the primary rule of scaling agile
is: don’t do it!

If you have problems with:

 Cross team dependencies
 Risks that affect several teams
 Scheduling of (coordinated) deliveries

you might need a scaling framework. If you can deal with these problems by re-arranging your teams
and product structure, you are better off without one. If you can’t, please continue reading.

What LeSS, SAFe and Scrum@Scale have in common

All three frameworks start with cross-functional, self-organizing Scrum teams. The teams vertically
slice requirements into the smallest possible increments that can be deployed independently. Teams
are also expected to focus on technical excellence such as doing continuous integration and
automated regression testing. At the end of every sprint the teams should have a potentially
deployable product. The three frameworks also encourage you to use Lean principles to optimize
your flow.
LeSS (Large Scale Scrum)
LeSS is a scaling framework that comes from Craig Larman and Bas Vodde, and is based on their
work in the financial and telecommunication industries.
LeSS is defined by minimalism and minimal process, i.e. use as little process as possible to get
multiple Scrum teams to work well. LeSS consists of a hand full of rules, there are also guides and
examples for how to customize these rules as the organization grows.

At its most basic level, LeSS is a clarification of how Scrum is intended to work. For example, it
clarifies that Scrum teams should be long-lived cross-functional feature teams that are maintained
across multiple projects. The idea is to manage the complexity of large-scale development by
simplifying it as much as possible. Therefore, LeSS recommends that multiple teams has the same
Product Owner and a shared Product Backlog. Their sprints are synchronized to the Product-level
Sprint leading to one integrated Potentially Shippable Product Increment. Sprint Planning, Sprint
Review and Sprint Retrospective runs at the same time for all teams.

One Product Owner with one product backlog, and several teams, each with its own sprint backlog.

It might seem impossible for a single person to be a Product Owner for up to eight teams, but the
philosophy of LeSS precludes the Product Owner from participating at a detail level, which leads to
teams that take on the responsibility to work out their own solutions. This forces the developers to
get closer to their users, giving them a better understanding of their users' context, needs and
problems. The result is a higher level of involvement and custom solutions, developed with better
quality more efficiently. Simply put, you "get more with LeSS".
Overview of LeSS with synchronized sprints.

Process-wise, LeSS is pure Scrum (time-boxed iterations, sprint planning, daily stand-up, sprint
review, and retrospective), with a modification. As per Scrum, Sprint Planning is split into two parts.
However, LeSS recommends that the first part is a joint meeting attended by representatives from all
of the teams to agree "What" Product Backlog Items (PBIs) will be built in the coming Sprint. The
second part of Sprint Planning is then used by each team to produce the Sprint Backlog and agree
"How" the PBI's will be built.

Common sprint end for all teams in LeSS

The end of the sprint also needs to be synchronized. This is accomplished by having one common
Sprint Review for all the teams. The Retrospective is divided into two parts, similarly to the sprint
planning. First, each team holds their own individual team Retrospective, then representatives from
each team hold a joint Retrospective together that enables them to identify and address issues that
cannot be solved at the individual team level.

LeSS Huge
If there are more than eight Scrum teams working off the same product backlog, it’s time to divide
the product backlog into different requirement areas. We then assign 4-8 teams to each of these
new requirement area-specific backlogs.

Each area has its own Product Owner, knows as an Area Product Owner, and backlog just like basic
LeSS. The Product Owner role is still present, and that person is responsible for all the product
areas. The process (Sprint planning, daily stand-up, Sprint review, and Retrospective) is used on
both the overall level and the area levels.
Product owner with his/her Area Product Owners and their teams

SAFe
SAFe is Dean Leffingwell’s framework. Version 1 debuted in 2011. By 2016 the framework was up to
Version 4, and we assume that it will continue to evolve. We have based the text below on the SAFe
Version 4.

Organisation
SAFe’s central premise is to divide the work into value streams. A value stream consists of the steps
that the company continuously repeats to deliver value to customers and users. Between 5 and 15
teams are typically involved with a value stream, and this grouping of teams is called a release train.
A release train can contain up to 150 people. Once that threshold is exceeded it is recommended to
have several Agile release trains within each value stream.

Agile release trains are an organizational structure, and the Release Train Engineer’s roll is that of a

facilitating coach (also known as an Agile Coach in other organizations).

Process
Within the Agile Release Train, teams work according to Scrum with sprints of typically 2 weeks.
SAFe also adds the concept of a “Program Increment” which is a cadence based interval of about 10
weeks, although the length of each interval may vary. The creators of SAFe recommend a Program
Increment duration of between 8 to 12 weeks based on their experience in the field.
 Week-by-week, the relationship between Sprints and Program Increments.

A Program Increment begins with the “PI Planning Event” (a.k.a. “big room planning”) – a one to two
day event where teams gather together to plan for the next Program Increment (usually around 10
weeks). Typically, product managers begin the meeting and set the vision followed by teams do the
actual planning and resolving dependencies between them. The result of the planning, including
dependencies between teams, is visualized on a Program Board. If uncertainties arise, Product
Managers are constantly on hand to make an immediate decision. The Program Increment is
facilitated by a Release Train Engineer.

SAFe suggests two things for achieving a balance between predictability, technical needs, and
flexibility:
1. Not upfront plan any Backlog Items for the “Innovation & Planning Sprint” (IP Sprint), the last sprint
of the Program Increment. Instead use it to finalize things that didn’t get finished, help product
owners plan future increments, and just try new things.
2. Do not fill the Sprints to 100% capacity, but rather only 30-70% to make room for correcting
defects, providing user support, and the unforeseen. It also provides the capacity for accomplishing
those things that product management takes for granted, but often do not receive dedicated time,
for example, upgrading tools and adapting to new platforms.

A typical Scrum team has three kinds of items in their sprint backlog:
1. Defects that are prioritized before anything else.
2. Items from the “big room planning”
3. Things the team knows ought to be done, but no one else has real insight or
opinion of (for example, upgrading operating systems or databases).
Portfolio Management
SAFe’s portfolio level ensures that all the company's initiatives (known as Epics in SAFe) are aimed
at the same goal. Architects, Portfolio Managers, and Initiative Owners work together based on the
strategy and vision developed by the company’s management.

A Kanban board can be used to keep track of all Epics, both enablers (that is, technical initiatives to
facilitate future development) and business initiatives (that is, features that customers direct notice).
The Portfolio Kanban provides transparency over the selection of opportunities. One can track the
entire development progress on Epic level, from the idea funnel to the delivered functionality. It also
helps enforce an organizational WIP limit for both analysis and implementation. The selection and
approval process provides the opportunity for the financing sponsors to approve developments and
forecast delivery.

When an epic’s status becomes "portfolio backlog", it becomes a candidate to be broken down into
one or more Program Backlog Capabilities or Features. SAFe uses the terms (in order of size)
Epics, Capabilities, Features and Stories to describe the work. The Epics that are wholly or partly
developed in a product increment are collected in the column "implementation" (“Implem.” in the
picture below).

Summary of SAFe in a picture that describes the three levels (large-scale SAFe has a "value
stream"
level that lies between portfolio and program level), the roles that are typically found on each level,
the
work involved at each level, and what the requirements are called at each level.
Many roles
At first glance, all the roles, levels, meetings, and artifacts can seem overwhelming. While this
feeling risks making a SAFe implementation that is both stiff and heavy, one should distinguish
between individuals and roles. An individual can advantageously have several roles, and multiple
individuals can man each of the roles pictured above. If you have a good understanding of the basic
principles of Lean and Agile, you can customize SAFe and get a smart and smooth implementation.

Scrum@Scale
Scrum@Scale comes from one of Scrum's founders, Jeff Sutherland, and is a meta-level framework
that takes up the areas that need to be resolved to bring Scrum to scale. One could see it as a list
with discussions you need to have when you decide your process. Depending on the context, the
solution may be similar to SAFe, LeSS or its own custom method.

The areas are divided into a Product Owner cycle (red) and a Scrum Master cycle (gray), as well as
some principles on metrics and transparency. Image courtesy of Jeff Sutherland and Scrum Inc.

Product Owner cycle:

 Strategic Vision – Where are we heading with the company and our products?
 Backlog prioritization – What is most important for us at the company level, the portfolio level,
and within the project?
 Backlog decomposition and refinement – How do we allocate the tasks among the teams, and
how do we conduct sessions in preparation for them?
 Release Planning – How do we plan for our deliveries? What comes when?
 Release Management – How do we synchronize between teams to get painless launches?
 Product and release feedback – How do we get feedback about the latest launched features
from the user, and how do we get that information out to the teams?
Scrum Master cycle:
 Cross-team coordination – How do we coordinate between different Scrum teams so we’re not
both doing the same thing or tripping over each other?
 Continuous improvement and impediment removal – How do we ensure that all teams are aware
of their skills and constantly try to improve them? How do we ensure that whatever a team
comes upon will be resolved even if it falls outside their area of competency?
Outside of these two cycles are also:
 Metrics and transparency – How do we measure that we build the right things and how do we
make sure that everyone has access to these readings?
In some organizations, it can be very difficult to get to some improvements unless people who have
the authority to make certain decisions are involved. Scrum@Scale proposes that companies set up
a group of decision makers (for example, an Executive Action Team) whose mandate is to facilitate
and oversee the improvements that the teams, Product Owners, and Scrum Masters do not
themselves have the ability to implement.

LeSS, SAFe, Scrum@Scale, or roll your own?

Since no two corporate cultures are ever alike, you will almost certainly need to modify whichever
framework you choose, and likely need to come up with a few solutions of your own.

LeSS is a good starting point when you already have Scrum in place, and are just beginning to scale
up with more teams, one at a time. LeSS scales up with minimal additional process compared to
single-team Scrum.

By comparison, one can say that SAFe is more of a everything-anyone-might-need framework, and
one can then remove what is not needed.

Some reasons why you might choose SAFe over LeSS:

 You need to coordinate a very large organization of hundreds or even thousands of people.
SAFe provides a clear way forward here for the entire chain from corporate strategy to product
strategy to tactics to what to do next Sprint.
 You work in component teams and don’t want to change them into feature teams. Component
teams are not recommended but the transition to Feature Teams is hard, regardless of
framework, and our experience is that perhaps SAFe makes it easier because it has
mechanisms and roles that give the perception that the pain of component teams is manageable
(via Program Board and Release Train Engineer).
 You want a framework that can suggest how to handle virtually every aspect of a fully Agile
organization, but doesn’t require a deeper experience of Agile development. SAFe provides an
easy accessible set of tools to help with how to prioritize the Program Backlog, how to run
Planning etc. So it has a set of patterns to get you up and running and adapting from.
 When deciding to go for SAFe you don’t need to take decisions about a lot of things, you just
follow the “book”. Depending on your viewpoint this is either bad (too prescriptive if you don't
adapt), or good (quick enablement - solves common problems).
Scrum@Scale is a useful discussion framework for those who already have several Scrum teams in
place that are functioning together, and you would love to find things and areas to improve.
Alternatively, if you want to describe your process, Scrum@Scale is a good starting point so you
don’t miss any perspectives.

As always, when it comes to Agile, remember these three important things:

 Adapt the method to fit your own situation.
 Constantly reflect on the situation.
 Improve how you work together.
Good Luck Scaling!