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!

Tomas Björkholm, Hans Brattberg, Jan Grape at Crisp In Stockholm, Sweden

Thanks to:

Yassal Sundman, Simon Powers, Shaun Smith, and Vince Ryan for proof reading

About the Authors

 Tomas Björkholm is a mentor, facilitator, coach, certified Scrum Trainer, and the author of two books about Agile. During his nine years at Crisp, he has helped companies implement Agile. His mantra is “if it’s not easy, something is wrong”.

Hans Brattberg is an agile coach and has been at Crisp for 16 years. He is the author of two books about agile and lean startup. His passion is to stop climate change by coaching the right companies, and run a smart grid business start-up.

Jan Grape is an agile coach that has spent his last 12 years with Crisp. His passion is to help product development organizations and their people reach their potential by offering coaching, mentoring, teaching and facilitation. His mantra is "motivation, quality, speed" (in that order).