This article is part one of Toptal’s scaling Agile series, designed to guide project managers in their team expansion efforts. The next 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?
Scaling 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 to your team 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 Teams||Number of Products||Scenario|
|1||1||One team manages the development of a single product.
No scaling is necessary.
|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
There are numerous Agile scaling frameworks to choose from, but we 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 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.
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 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.
This configuration combines all the layers—Essential, Large Solution, and Portfolio—to coordinate enterprisewide team management.
|Use SAFe If Your Organization:|
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:|
3. Large-Scale Scrum (LeSS)
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:|
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:|
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:|
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.
I’m confident that you’ll find the scaling 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.”
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.
Select an Agile framework based on your unique work context. When choosing, consider factors such as the experience level of your team, organizational maturity, and the complexity of the solutions being built.
The four levels of the Scaled Agile Framework (SAFe) are Essential, Large Solution, Portfolio, and Full.