Scaling Agile Across Teams with SAFe, LeSS and More

Scale agile across several teams on one product: map dependencies, choose SAFe, LeSS or a lighter setup, and pilot it before rolling out.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Scaling agile, or running agile at scale, means keeping the benefits of small, self-organizing teams when several of them work on the same product. The problems it solves are coordination problems: teams blocked by each other, integration left to the end, conflicting priorities from different stakeholders, and nobody able to say when a cross-team feature will ship. The risk is solving them by adding a management layer that slows every team down.

Several frameworks address this. The Scaled Agile Framework (SAFe) organizes teams into an Agile Release Train, "a long-lived team of Agile teams"; SAFe says ARTs are generally made up of 50-125 people (SAFe, Agile Release Train). Trains plan together in Planning Intervals, typically "8 to 12-week" timeboxes of four or five development iterations followed by an Innovation and Planning iteration (SAFe, Planning Interval). SAFe adds roles such as the Release Train Engineer, Product Management and the System Architect.

Large-Scale Scrum (LeSS) takes a lighter approach to scaling Scrum across multiple teams. It keeps one Product Owner, one Product Backlog, one Definition of Done and one common Sprint for up to eight teams, with LeSS Huge for larger products (LeSS framework). It changes Scrum's events for many teams, with a two-part Sprint Planning, multi-team refinement and an Overall Retrospective, and states that "scaling Scrum starts with understanding standard one-team Scrum."

The squads-and-tribes structure often called the Spotify model is a third reference point, covered in the catalog's Spotify Squad Model method. Henrik Kniberg, who described it, writes that it was "just an example of how one company works" and was not intended as a generic framework (Kniberg). Marcin Floryan, a Spotify chapter lead, later gave a talk that InfoQ summarized as "there is no Spotify model" (InfoQ).

This skill does not pick a framework for you. It walks through the analysis that should come first, the choice itself, and a pilot that tests the choice before it spreads.

How It Works

Scaling works when three things are true: teams are organized so most work can be finished inside one team, the few real dependencies are visible and planned together, and the parts are integrated often enough to find problems early.

Team design comes first. Many coordination problems come from how teams are cut. Teams organized by technical layer, such as front end, back end and database, need each other for almost every feature. Teams organized around features or customer journeys can finish more work alone. LeSS builds on cross-functional teams working from one shared backlog. Before adding any coordination process, check whether redrawing team boundaries would remove the dependency.

Shared cadence makes dependencies plannable. When teams start and end their cycles on the same days, they can plan dependencies together and integrate at the same points. SAFe does this with Planning Intervals and a joint planning event. LeSS does it with one common Sprint for all teams and a two-part Sprint Planning.

One backlog or a clear hierarchy keeps priorities consistent. LeSS uses one Product Backlog with one Product Owner so teams cannot optimize for conflicting priorities. SAFe uses a hierarchy of portfolio, train and team backlogs, and prioritizes with Weighted Shortest Job First, "the relative cost of delay divided by the relative job duration" (SAFe, WSJF).

Frequent integration keeps the product whole. A shared Definition of Done for the whole product means an increment is finished only when it works with everyone else's. LeSS asks for one potentially shippable increment per Sprint across all teams.

Coordination roles should remove obstacles. Whatever the framework, roles such as a Release Train Engineer or a cross-team coordinator exist to make dependencies visible and remove impediments. When those roles start assigning work to teams, the organization has rebuilt the hierarchy agile was meant to replace. Martin Fowler's warning that "The team doing work decides how to do it" applies at scale too (Fowler, 2018).

Step-by-Step Guide

Step 1: Map the teams and their dependencies

List every team working on the product, what each owns, and every recurring dependency between them over the last few cycles. Draw it as a simple diagram with arrows for "needs something from." Count how often each dependency caused a delay. This map is the evidence for everything that follows.

Step 2: Remove dependencies by redesigning teams where you can

Look for dependencies that exist only because of how teams are split. If two teams always need each other for the same kind of feature, consider merging them or redrawing their boundaries around the feature. Every dependency removed here is one the scaling framework does not have to manage.

Step 3: Check readiness

Confirm that each team already runs agile well on its own: stable membership, a working cadence, a Definition of Done, and regular retrospectives. LeSS's own guidance is to start from one-team Scrum. Scaling amplifies whatever each team already does, including its problems.

Step 4: Choose the lightest approach that fits

For two or three teams with few dependencies, a shared cadence, a joint planning session and a regular cross-team sync may be enough. For a single product with several teams, compare LeSS's one-backlog model with SAFe's train structure. For many teams across several products or value streams, SAFe's portfolio layer may be needed. Write down why you chose what you chose.

Step 5: Design the backlog and cadence

Decide whether teams share one backlog or work from a hierarchy, who orders it, and how cross-team features are split. Align cycle start and end dates across teams and schedule the joint events: planning, review and a cross-team retrospective. Publish the calendar for the whole planning horizon.

Step 6: Agree a product-wide Definition of Done

Write a Definition of Done that applies to the integrated product, covering testing, integration and deployment. Make sure every team can meet it within a cycle, or name the gaps and a plan to close them. Integration left until the end of a long planning interval brings back the late-discovery problem agile was meant to fix.

Step 7: Pilot with a subset of teams

Run the new setup with a few closely linked teams for at least one full planning cycle before involving everyone. Measure the things that motivated the change: delays caused by dependencies, how often cross-team features ship when planned, and how teams feel about the overhead. Hold a joint retrospective at the end.

Step 8: Adjust, then expand

Change what the pilot showed did not work, then extend the setup to more teams in stages. Keep the cross-team retrospective as a permanent event so the scaling structure itself keeps improving. Remove any process that no longer earns its cost.

Best Practices

• Fix team design before adding process. Redrawing boundaries so teams can finish features alone removes coordination work instead of managing it.
• Start from teams that already work well. The LeSS framework makes understanding one-team Scrum the starting point for scaling it.
• Adapt any framework to your context. Kniberg's advice about the Spotify model, to adapt to the local context, applies to every framework (Kniberg).
• Integrate continuously. A product-wide Definition of Done and frequent integration expose conflicts while they are cheap to fix.
• Keep coordination roles facilitative. Their job is making dependencies visible and removing obstacles, which keeps decisions about how to work inside the teams.
• Measure the coordination problem you set out to solve, such as dependency delays, and check it after the pilot.

Common Mistakes

• Adopting a framework wholesale: Installing every role, event and artifact at once overwhelms teams and hides which parts help. Start with the smallest set that addresses your dependency map.
• Copying another company's structure: Floryan's warning that the Spotify model "is not something that you should copy" applies to any company's setup (InfoQ). Start from your own dependencies.
• Scaling teams that are not yet agile: If individual teams cannot deliver working increments, coordinating them will not fix that. Stabilize teams first.
• Adding a management layer under a new name: Coordinators who assign work and approve decisions recreate the hierarchy. Keep decisions about how to work in the teams.
• Deferring integration to the end of the planning interval: Long gaps between integrations let incompatible work pile up. Integrate at least every team cycle.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Agile

Related Skills

• Running Sprint Planning and Agile Sprint Execution
• Product Backlog Management and Refinement
• Agile Coaching: Guiding a Team Through Adoption
• Choosing Between Scrum, Kanban, and Scrumban

Sources

• Scaled Agile Framework: Agile Release Train
• Scaled Agile Framework: Planning Interval
• Scaled Agile Framework: WSJF
• LeSS: Large-Scale Scrum
• Henrik Kniberg: No, I didn't invent the Spotify model
• InfoQ: There Is No Spotify Model
• Martin Fowler: The State of Agile Software in 2018

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.