5 Agile Scaling

Frameworks Compared:
Which One Should You
Use?
Toptal’s Agile scaling series is designed to guide project managers in their team
expansion efforts. In this first installment, project manager Kamil Imański
breaks down popular scaling frameworks to help you make the best choice.

authors are vetted experts in their fields and write on topics in which they have
demonstrated experience. All of our content is peer reviewed and validated by Toptal
experts in the same field.

By Kamil Imański Verified Expert in Project Management

Kamil is an Agile project manager and Scrum master with a background in business analysis and change
management. He has extensive experience leading teams and implementing Agile scaling practices at
international companies, including BAE Systems, which is an FTSE100 company and the largest defense
contractor in Europe. He is a certified Lean Six Sigma Black Belt, PMP, and PMI-ACP.
EXPERTISE

Agile Scrum

PREVIOUSLY AT

This article is part one of Toptal’s scaling Agile series, designed to guide project managers in their team expansion efforts. The next
SHARE THIS ARTICLE

installment, “Agile Scaling: SAFe Best Practices for Scrum Masters,” offers practical advice on facilitating events in SAFe.

Picture this: At the beginning of a project, you assemble a single, effective, cross-functional team of individuals committed to achieving
product goals. To improve performance, you ensure the team is proficient in Agile. The demand for the product grows, increasing
requirements and expanding the backlog. You and other stakeholders realize the team needs to be scaled. Sound familiar?

A scalable Agile framework allows multiple teams working together to maintain their agility. If there is more work to be done than your
team can handle in a reasonable period of time, it’s time to scale. In order to do so, however, you need to select the right framework, and
there are several to pick from. Choose badly and implementation could fail, disrupting productivity and resulting in significant financial
repercussions.

The framework best suited for your team to use Agile at scale will vary, depending on factors such as available funding, organizational
approach, and product complexity.

When Should You Scale?

There are a number of key criteria to meet before you should consider scaling:

Can you manage the development with only one team?

Implementing scaled Agile frameworks can be complex and time-consuming, so don’t scale if you don’t need to. When your team’s
workload outweighs its capabilities, then scaling is necessary.
Is your team Agile?

Perhaps the most important criterion is your team’s proficiency in Agile approaches. If your team is not experienced in Agile, then scaling
will create more problems.

Do your team’s development practices need improvement?

If your team’s engineering practices are not efficient, scaling may not produce the desired results. Practices such as proper implementation
of DevOps and a CI/CD pipeline are vital for consistency across teams. Also, without standardized quality assurance, it may be difficult
to test new features.

Does your team deliver integrated increments?

Scaling involves integrating multiple teams collaborating on the same product, where each team produces features that work together. The
following table details the four possible configurations of teams and products. Note that only one necessitates scaling.

Number of Number of
Teams Products Scenario

1 1 One team manages the development of a single product.

1 More than 1 One team works on multiple products, so a project manager can either create a queue of
products and develop them one by one or set up multiple teams that each work on a
separate product.
No scaling is necessary.

More than 1 More than 1 The number of products equals the number of teams.
No scaling is necessary.

More than 1 1 Multiple teams work together to deliver a large product solution—this is the configuration
in which a project manager should implement a scaled Agile framework.

Choosing a Scaling Framework

This scaled Agile frameworks comparison will focus on five of the most widely used solutions: Scaled Agile Framework (SAFe), Nexus,
Large-Scale Scrum (LeSS), Scrum@Scale, and Disciplined Agile (DA). I have found these to be the most effective frameworks, and they
can be applied to a range of scenarios and organizations. The following sections will equip you with the information you need to make the
best choice for your unique scaling context.

1. Scaled Agile Framework (SAFe)

SAFe is the most popular framework for Agile scaling. A 2021 survey found that 37% of Agile practitioners use it, largely owing to its
multiple configurations, all of which focus on value streams and have well-defined guides and procedures.

Because SAFe is used to deliver complex solutions that require more than 50 people, it organizes teams into agile release trains (ARTs). To
synchronize the teams in an ART, SAFe uses program increment iterations—similar to Scrum sprints—and each iteration typically lasts
eight to 12 weeks. This approach allows product managers to stay focused on the overall goals and oversee a complex product roadmap
efficiently without introducing excessive changes.

SAFe is based on the Scrum framework but with a couple key differences: SAFe adoption happens at the enterprise level rather than the
team level; and while Scrum gives the product owner sole authority over prioritization, SAFe encourages a more democratic approach.

SAFe has four levels of implementation:

Essential SAFe
Essential SAFe is the foundation of SAFe and must be mastered before moving on to any of the subsequent configurations. It utilizes
established Scrum roles such as Scrum master, product manager, and product owner, and also introduces a new role: release train engineer.
This person acts as a servant-leader and ART coach, guiding teams to align their goals. There can be between five and 12 teams in an ART,
with each ART capable of delivering a complete solution.

Large Solution

This configuration sits atop Essential SAFe and introduces a concept called “solution train.” It’s used when building large and complex
solutions that require the coordination of multiple ARTs—potentially hundreds or even thousands of people—working on the same value
stream. For example, if you work at Microsoft and have three separate teams programming Excel, Word, and PowerPoint, they are all
contributing to the same value stream: Microsoft Office.

Portfolio

Portfolio consists of multiple ARTs working on different value streams. Continuing with the Microsoft example: separate teams working
on the company’s Office, Skype, or Xbox products.

Full SAFe

This configuration combines all the layers—Essential, Large Solution, and Portfolio—to coordinate enterprisewide team management.

Use SAFe If Your Organization:

Is a large, well-established enterprise.

Is proficient in Scrum.

Has the financial resources to hire for additional roles.

Builds complex solutions that may require a large number of teams in the future.

Takes a rigid approach to following core framework practices.

Has Agile leadership, which supports cross-boundary decision-making.

2. Nexus

The Nexus framework is also based on Scrum but is more lightweight than SAFe, requiring only small adjustments that facilitate
collaboration among three to nine teams. Implementing Nexus does not require any additional roles. Rather, one representative from each
team joins a central integration team that aligns work toward a single goal. Similar to Scrum, all teams come together for a sprint planning
session, the results of which form the shared product backlog. To check progress, each team holds a daily meeting akin to a stand-up, and
the integration team also meets to report their team’s progress.

During a sprint, teams participate in a refinement session to prioritize and estimate the backlog. Because the complexity of backlog
management rises with the number of teams, Nexus mandates refinement sessions. Teams convene for reviews and retrospectives
following each sprint.

Use Nexus If Your Organization:

Is a startup in need of a lightweight framework.

Is proficient in Scrum.

Has limited financial resources.

Builds simple solutions.

LeSS is almost identical to Nexus, but it has minor differences, such as naming conventions and additional, team-specific sprint planning
sessions. It also differs in its ability to be extended with its second configuration, LeSS Huge, which supports the collaboration of more
than eight teams.

LeSS Huge takes a customer-centric approach to organizing development. To effectively manage work, it requires the product owner to
split the high-level product backlog into smaller “area backlogs” of more granular items and then sorts them further—into requirement
areas.

These requirement areas are managed by area product owners (APOs). APOs specialize in the fields related to each area and work with
several teams on solutions for their area. Each requirement stored in the backlog belongs only to one requirement area, and each area is
managed by just one APO. Together, the product owner and APOs form a team responsible for prioritizing with a productwide view.

Use LeSS and LeSS Huge If Your Organization:

Is a startup in need of a lightweight framework.

Is proficient in Scrum.

Has limited financial resources.

Builds complex solutions that may require a large number of teams in the future.

4. Scrum@Scale

Scrum@Scale is an extension of Scrum and likely the easiest framework to learn and understand. It scales from one team to a team of
teams.

A core component of the framework is the Scrum of Scrums (SoS). Each team chooses an individual to represent them in SoS meetings,
which usually take place daily after the individual team stand-ups. The aim of each day’s SoS meeting is to aid coordination and
communication among teams, and facilitate easy management of any dependencies or overlaps.

The unique roles within this framework include the SoS master, essentially a scaled version of a Scrum master, and the chief product
owner, who works with the team product owners to form a joint backlog for the SoS.

Scrum@Scale is less prescriptive than other frameworks, allowing organizations to scale at their own pace. If the number of teams
continues to grow and SoS meetings become too large, organizations can escalate the framework into a Scrum of Scrum of Scrums
(SoSoS).

Use Scrum@Scale If Your Organization:

Is a large enterprise.

Requires a flexible approach to scaling.

Is proficient in Scrum.

Builds complex solutions that may require a large number of teams in the future.

5. Disciplined Agile (DA)

DA differs from the other frameworks in that it acts more as a toolbox from which you can choose the most appropriate scaling strategies,
rather than a rigid framework with rules you must obey. It is a context-driven hybrid of various frameworks, including Scrum and Kanban,
that can be tailored to the needs of each project, centered on the principle “Choice is good.” DA is built on the idea that every team and
organization is unique in its size, distribution, and domain, and each team member is unique too, with their own skills and experiences.
It can be applied at the software development team level or enterprisewide. For the latter, the DA toolkit identifies what various business
functions—such as finance, IT operations, and vendor management—should address, and presents a range of options for doing so.

DA distinguishes three project phases—Inception, Construction, and Transition—and each comprises delivery-oriented process goals.
Because this framework focuses on the full delivery life cycle, as opposed to just the build, it introduces more roles than the other
frameworks. The primary roles, found on every DA team, are stakeholder, team member, team lead, product owner, and architecture
owner. There are also five supporting roles, often used on a temporary basis to assist scaling: specialist, domain expert, technical expert,
independent tester, and integrator.

DA can be used on top of the other frameworks to scale further.

Use DA If Your Organization:

Is a large, well-established enterprise.

Is Agile but does not adhere to Scrum specifically.

Requires a more flexible approach.

Has the financial resources to hire for additional roles.

Choose Carefully and Scale Slowly

Scaling Agile teams and seamlessly integrating their work is difficult but can be made easier by selecting the best framework. Use the
flowchart below as a first step to guide your decision-making process.

Choosing the right framework depends on a number of variables.

I’m confident that you’ll find the scaling Agile framework that suits your organization’s experience, approach, budget, and products
among those presented here. Whichever framework you choose, it’s vital to not rush—scale incrementally to minimize disruption and plan
changes well in advance.

Have you utilized these frameworks in any of your scaling activities? Tell us about your experiences in the comments section.

Read the next installment of Toptal’s Agile scaling series, “Agile Scaling: SAFe Best Practices for Scrum Masters.”

Further Reading on the Toptal Blog:

Agile Scaling: SAFe Best Practices for Scrum Masters

The Project Management Blueprint, Part 2: A Comprehensive Comparison of Waterfall, DAD, SAFe, LeSS, and Scrum@Scale
CapEx 101: Resolving the Agile vs. Waterfall Conflict With Hybrid Methodology

Mission Driven Development

Critical Chain Project Management: Agile’s Missing Link

The Ultimate Introduction to Agile Project Management

Today’s Project Management Blueprint: A Comparison of Lean, Agile, Scrum, and Kanban

UNDERSTANDING THE BASICS

Scale your Agile team using a framework to expand one large team into a structure
comprising several teams that work on the same value stream. This needs to be
done gradually, while maintaining good cross-team communication, to ensure
minimal disruption to productivity.

How do I choose an Agile framework?

What are the four levels of the scaled Agile framework (SAFe)?