Scaling agile: how to scale agile across teams, programs and portfolios

1. What is scaling agile?

Scrum is designed for one team of, typically, ten or fewer people.^[3] It says little about what happens when thirty teams need to ship one product. Scaling agile fills that gap. It answers four questions a single-team method leaves open:

• How do many teams plan together, and how often?
• Who decides priority when teams compete for the same people or systems?
• How are dependencies between teams found and managed?
• How does strategy and funding connect to the work teams are doing?

You will also see the terms agile at scale, scaled agile and enterprise agility. "Scaled Agile" with capitals usually refers to Scaled Agile, Inc., the company behind SAFe. In lower case it means the general practice this guide covers.

2. Why do organizations need to scale agile?

Conway's law explains why this is structural and not a matter of effort: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."^[4] If teams cannot coordinate, the product will show it.

The pressure to prove value has also grown. In Digital.ai's 18th State of Agile Report, 76% of respondents cite increased scrutiny on the business impact and ROI of agile, and customer satisfaction, at 52%, remains the primary measure of success.^[5] Scaling is how leadership connects investment to what teams deliver, quarter by quarter.

The same report shows that scaling rarely means installing one framework unchanged: 74% now use hybrid, blended or homegrown agile models.^[5]

3. When do you need to scale agile?

Size alone is not the trigger. Ten independent teams with separate products do not need a scaling framework. Four tightly coupled teams might. Look for these symptoms:

• Teams finish their sprints, but features still arrive late because they wait on other teams.
• Integration problems appear at the end of a release instead of every sprint.
• Each team has a different answer to "what is the top priority this quarter?"
• The same people are committed to several teams at once.
• Leadership asks for a status report because there is no shared view of progress.
• Planning is done team by team, and dependencies are found during delivery.

4. How do you begin scaling agile?

There are two classic entry points. Bottom-up scaling starts with teams that already work well and connects them. It builds on real practice but stalls without leadership backing. Top-down scaling starts with an executive decision. It moves faster but fails if teams experience it as something done to them. Successful adoptions combine the two: leadership sets direction and removes obstacles, and teams shape the way of working.

A practical sequence, consistent with the SAFe Implementation Roadmap^[8]:

1. Name the problem. Agree which business outcome is suffering today. "We want to be agile" is not a reason anyone can measure.
2. Secure a sponsor with authority over budget, priorities and structure.
3. Train leaders first. People cannot lead a way of working they have not understood.
4. Choose one value stream where the pain is real, the sponsor is engaged and the teams are willing.
5. Organise teams around value, so each can deliver with as few hand-offs as possible.
6. Set a shared cadence. Same iteration length and same start dates for all teams.
7. Hold the first joint planning event. In SAFe this is PI Planning.
8. Execute, measure and adapt. Run an Inspect and Adapt at the end of the first interval.^[9]
9. Launch the next group and extend to portfolio level once several are running.

5. How do you assess readiness for scaling agile?

Scaling amplifies what is already there. DORA's 2025 research makes the same point about AI, describing it as "an amplifier, magnifying an organization's existing strengths and weaknesses."^[10] A scaling framework behaves the same way. It will make good teams better coordinated and make weak practices visible very quickly.

6. What are the main scaling agile methods and frameworks?

Scaled Agile Framework (SAFe)

SAFe organises teams into Agile Release Trains, each "a long-lived team of Agile teams" of generally 50 to 125 people^[11], planning together in a Planning Interval of 8 to 12 weeks.^[16] It comes in four configurations: Essential, Large Solution, Portfolio and Full SAFe.^[17] Essential SAFe holds "the minimal elements necessary for Agile Release Trains to deliver solutions"^[18] and is where most organisations start. Large solutions that need several trains and suppliers use a Solution Train.^[19]

SAFe 6.0 remains the latest numbered version. Scaled Agile now updates the framework continuously and introduced AI-Native SAFe in June 2026.^[20] Its own figures put trained practitioners at over two million.^[21] SAFe suits organisations that need clear roles, governance and a link from strategy to delivery. The usual criticism is its weight, so start with Essential SAFe and add only what solves a problem you have.

Large-Scale Scrum (LeSS)

LeSS applies one-team Scrum to many teams: one product, one Product Owner, one product backlog and one sprint. Basic LeSS covers up to eight teams of about eight people each, and LeSS Huge extends to a few thousand people on one product.^[6] LeSS Huge is intended for adoptions of more than eight teams.^[22] LeSS adds very few roles and asks instead for organisational simplification, which makes it light on paper and demanding in practice. Read more about how LeSS works.

Scrum@Scale

Scrum@Scale, by Scrum co-creator Jeff Sutherland, links teams through a Scrum of Scrums. The guide states that "the optimal number of teams in a Scrum of Scrums is 4 or 5"^[13], and larger organisations repeat the pattern as a Scrum of Scrum of Scrums. It defines a Scrum Master cycle and a Product Owner cycle, and leaves most practices to the organisation.

Nexus

Nexus, from Scrum.org, is "a group of approximately three to nine Scrum Teams that work together to deliver a single product."^[14] It adds a Nexus Integration Team and a small set of events to manage dependencies and integration. It is a natural step for organisations already committed to Scrum.

Disciplined Agile (DA)

Disciplined Agile, now part of the Project Management Institute, is a toolkit and not a single process. It describes goals and the options for achieving them, and asks teams to choose their own way of working. It fits organisations with varied contexts, for example a mix of agile, lean and traditional delivery. See our overview of Disciplined Agile Delivery.

The Spotify model (squads and tribes)

The Spotify model comes from a 2012 paper describing how Spotify had "scaled to over 30 teams across 3 cities" using squads, tribes, chapters and guilds, with tribes kept to around 100 people.^[15] It was a description of one company at one point in time and was never published as a framework. Borrow its ideas on autonomy and communities of practice, and do not expect it to tell you how to plan across teams. We look at its key elements here.

How do you choose a scaling framework?

• Many teams, several products, strong governance or regulation: SAFe.
• One product, up to eight teams, appetite for organisational change: LeSS.
• Scrum is established and you want to extend it: Nexus or Scrum@Scale.
• Mixed delivery methods across the organisation: Disciplined Agile.
• None fits: you are in the majority. Take a shared cadence, joint planning, visible dependencies and a regular review, and build from there.

Whichever you choose, the mechanics are similar: a regular joint planning event, a way to see dependencies, a cross-team sync and a review of results. For a deeper comparison of how each framework plans, see the agile scaling models overview and our comparison of scaling models.

7. What are the benefits of scaling agile?

• Alignment. Every team works from the same priorities, refreshed on a fixed cadence.
• Predictability. Committed objectives compared with delivered objectives give leadership a number they can trust, interval after interval.
• Fewer surprises. Dependencies and risks are discussed during planning, not discovered during delivery.
• Faster decisions. Trade-offs are made by the people with the information, in the planning event.
• Engagement. In Scaled Agile's 2025 State of SAFe survey of 1,200 professionals, 68% reported a significant or some increase in employee satisfaction. This is the vendor's own survey.^[23]
• Business results. The Business Agility Institute's 2025 report found that organisations that increased their business agility maturity saw a 10.3% increase in revenue per employee, compared with 5.1% for all organisations.^[24]

Kendis customers describe the same effects in practice. KBC moved to SAFe in 2018 and uses Kendis for objectives and risks, and Electrolux runs PI Planning across distributed teams.

8. What are the challenges in scaling agile?

The 17th State of Agile Report lists the top barriers on the business side as resistance to change or culture clash (47%), not enough leadership participation (41%), inadequate management support (38%) and business teams not understanding agile (37%).^[1]

Incomplete understanding of the framework

Adopting the vocabulary without the principles produces the meetings and none of the benefit. Train leaders and teams, and coach through the first two planning cycles.

Leadership that sponsors but does not take part

If leaders skip joint planning or keep assigning work outside it, teams learn that the plan is optional. Leaders need to be in the room and to make trade-offs there.

Changing mindset and culture

Scaling asks managers to move from directing tasks to setting goals and removing obstacles. That shift takes longer than any process change and is where most adoptions stall.

Dependencies between teams

Dependencies are the largest source of delay at scale. Make them visible during planning, give each one an owner and a date, and review them in every sync. See dependency management.

Distributed and hybrid teams

Most knowledge work is now hybrid. Gallup reports that 52% of US employees in remote-capable jobs work hybrid and 26% fully remotely as of May 2026.^[25] SAFe's guidance is that agile teams "can still be successful and achieve high performance" when members are not in the same place^[26], provided planning, working agreements and tooling are designed for it. Our guide to remote PI Planning covers how.

Tools that stop at the team

Team-level tools show a sprint well and a train poorly. When the cross-team picture lives in spreadsheets, it is out of date the day after planning. Section 11 covers what to look for.

9. How long does it take to scale agile?

These are planning estimates and not published benchmarks. What drives the timeline:

• Starting maturity. Teams already doing Scrum or Kanban well scale far faster.
• Leadership involvement. Active sponsors shorten every step.
• Architecture. Tightly coupled systems mean more dependencies to manage.
• Size and regulation. More teams and more governance mean more to change.
• Tooling. A shared view across teams removes weeks of manual reporting from each cycle.

Think in planning intervals. Expect the first one to be rough, the second to be better, and real predictability from the third or fourth. Scaling is never finished. Each interval ends with a review that changes how the next one runs.^[9]

10. How do you measure success when scaling agile?

SAFe groups measurement into outcomes, flow and competency, and names six flow metrics: distribution, velocity, time, load, efficiency and predictability.^[2]

Kendis reports these from live board data. See flow metrics, program analytics and Inspect and Adapt.

11. What tools do you need to scale agile, and where should the data live?

Team tools have added cross-team views, with limits worth knowing:

• Jira Plans. The Program board is available only in Jira Cloud Premium and Enterprise^[28], and dependency lines display for up to ten work items at a time.^[29]
• Azure DevOps Delivery Plans. A plan shows up to 20 team backlogs across projects.^[30] Microsoft documents how to configure Azure Boards for SAFe.^[31]
• Jira Data Center. Atlassian has announced the end of life of Data Center, with subscriptions and associated Marketplace apps expiring on 28 March 2029.^[32] Planning tools that run as Data Center apps are affected, so check how your scaling tooling is delivered.

What a scaling tool should give you beyond those views: a shared planning board, managed dependencies, objectives with business value, a risk register, scope change tracking and predictability reporting, without asking teams to leave the tool they already use.

Data residency for European organisations

A cross-team plan contains your roadmap, release dates, named people and known risks. Where it is stored is a legal question as well as a technical one:

• GDPR. Transfers of personal data outside the EU are allowed only under the conditions of Chapter V.^[33]
• Schrems II. In 2020 the Court of Justice invalidated the EU-US Privacy Shield.^[34]
• Data Privacy Framework. Its successor allows transfers to participating US companies^[35] and was upheld by the General Court in September 2025.^[36] An appeal to the Court of Justice was filed in October 2025.^[37]
• DORA. Since 17 January 2025, financial entities must have contracts with ICT providers that state where data is processed and stored.^[38]
• NIS2. Supply chain security, including relationships with service providers, is part of the required risk management measures.^[39]
• Data Act. In application since 12 September 2025, it includes rules that make switching between cloud providers easier.^[40]

Hosting in the EU with a European provider is the simplest way to keep these questions out of your tool selection. The Kendis European Cloud runs on OVHcloud in Frankfurt, Germany, with project data stored and processed in the EEA and no US cloud provider in the hosting chain. A US-hosted Global Cloud on AWS and a self-hosted option are also available. Kendis is ISO/IEC 27001 certified, and a DORA Schedule is available for financial-sector customers. See security and compliance and GDPR.