8.8 Agile at scale

OPEN Module 2: Project Planning Unit 8: Agile Project Management 8.8 Agile at scale

Discover how to scale Agile across teams and departments without losing focus, speed, or value. Learn what works, what doesn’t, and why it matters.

Adding manpower to a software project makes it later.

Brooks’ Law

Key terms

Cross-functional teams: Groups made up of people with different skills (e.g., design, dev, marketing) who work together to deliver end-to-end value.

SAFe (Scaled Agile Framework): A structured, top-down Agile framework designed for large, complex organizations with many teams and strict planning needs.

LeSS (Large-Scale Scrum): A minimalist framework for applying Scrum across multiple teams working on the same product with one shared backlog.

Scrum of Scrums: A short meeting where team leads (or reps) from multiple Agile teams coordinate progress, raise issues, and align plans.

Spotify model: An informal way of working based on autonomous teams (“squads”) grouped into “tribes,” supported by shared learning groups called chapters and guilds.

Squad: A small, cross-functional Agile team responsible for delivering a specific piece of customer value.

Tribe: A group of related squads working in the same general product or service area.

Chapter: A group of people in similar roles (like designers or testers) who share best practices and support each other across different squads.

Cargo cult Agile: When an organization copies Agile practices (like stand-ups or boards) without understanding or applying the underlying principles, so nothing really improves.

Agile theater: Similar to cargo cult Agile—when teams go through the motions of Agile (meetings, rituals) but the work and mindset don’t actually change.

8.8.1: Too much of a good thing?

In earlier topics, we looked at how Agile works best in small, cross-functional teams. A few people, sitting (or Zooming) together, with just enough structure to move fast, deliver often, and learn as they go.

But most organizations aren’t made up of one team.

When Agile scales across departments, divisions, or even the entire business, everything changes. You can’t just multiply your team by ten and hope for the best. You need new ways to stay aligned, manage complexity, and keep delivery meaningful.

In predictive projects, large-scale work is carefully mapped out in advance. The team is structured around a central plan. You might have one big master team, with smaller sub-teams joining or leaving at various stages depending on the phase of the project.

Take a satellite launch, for example. You’d have systems engineers, software developers, rocket specialists, mission planners—all coming in at the right time, doing their part, then handing off to the next team. The project manager controls the timeline, dependencies, and scope to ensure everything fits together.

Agile doesn’t work like that.

Take the development of the iPhone. Apple didn’t release a 5-year plan for the entire product. Instead, they used cross-functional teams—hardware, software, design, marketing—all working in tight loops, feeding insights back into development continuously. It wasn’t a single project with rotating teams. It was multiple teams, working in parallel, toward a shared vision, while learning and adapting as they went.

Agile at scale looks just like that.

So what actually changes?

1. Dependencies multiply

One team is simple. Ten teams means shared systems, timelines, and decisions. The complexity explodes. You need lightweight ways to manage those interdependencies—without defaulting to top-down command-and-control.

2. Communication gets harder

Small teams rely on fast, informal communication. At scale, you need systems for alignment—shared goals, synchronized cadences, and intentional ceremonies to avoid silos and duplication.

3. Autonomy must be aligned

Agile empowers teams to make decisions. But if each team is optimizing only for itself, you lose coherence. Alignment on goals, customer outcomes, and priorities is what makes autonomy effective at scale.

4. Leadership shifts sideways

One team? One leader. Many teams? You need leadership that’s distributed. It should be focused on enabling, not instructing. You’re guiding the system, not just managing the work.

5. Tools and metrics evolve

Shared backlogs. Visible dependencies. Scaled delivery tracking. Tools don’t replace communication, but they help it scale.

6. Transformation is a change journey

Scaling Agile often comes with restructuring and role changes. It’s not just a delivery shift—it’s a cultural one. Expect resistance. Expect uncertainty. And lead with clarity and empathy.

The lesson here is that even though Agile is simple, scaling it isn’t.

If you try to grow without adapting, you’ll get “Agile theater”—where teams go through the motions, but nothing really improves. Delivery stalls. Alignment fades. Confidence drops.

To make it work, you need to shift from more Agile to better-coordinated Agile.

In the next lesson, we’ll explore a few of the major frameworks that help organizations do exactly that—SAFe, LeSS, and the Spotify model.

They’re not one-size-fits-all solutions, but they offer useful patterns to start from.

8.8.2: Scaling frameworks – SAFe, LeSS, and the Spotify Model

Scaling Agile is hard. That’s why a number of frameworks have emerged over the last two decades to help larger organizations coordinate Agile delivery across dozens—or even hundreds—of teams.

Let’s take a look at three of the most common:

SAFe (Scaled Agile Framework)

SAFe is a comprehensive, top-to-bottom framework designed for large organizations. It tries to bring Agile, Lean, and DevOps practices together while still allowing for traditional structures like portfolios and roadmaps.

Key features:

Breaks work into multiple levels (team, program, portfolio).
Uses a synchronized cadence, with teams delivering in the same sprint cycle.
Introduces roles like Release Train Engineer, Solution Architect, and Product Manager.
Builds in planning events, governance, and metrics at scale.

Good for:

Organizations with strict governance requirements, multiple teams working on shared platforms, or the need to align Agile delivery with broader strategic planning.

Things to watch:

SAFe can feel heavy if implemented rigidly. It works best when adapted, not adopted wholesale. The risk is replacing traditional bureaucracy with Agile-sounding bureaucracy.

LeSS (Large-Scale Scrum)

LeSS is designed to keep things lightweight. It’s basically Scrum—but applied to multiple teams working on the same product.

Key features:

One Product Owner and one backlog across all teams.
Teams work in sync and deliver together.
Minimal added roles or ceremonies beyond what Scrum already includes.
Strong emphasis on descaling the organization rather than scaling the framework.

Good for:

Organizations with a strong Scrum culture, or products that don’t need multiple business units to coordinate.

Things to watch:

LeSS assumes high team maturity and tight coordination. Without it, things can fall between the cracks. It’s also less suited to environments with strict regulatory or reporting obligations.

Spotify Model

The Spotify model isn’t a formal framework. It’s a way of working that was developed at Spotify and has since been adopted (and often misunderstood) by others.

Key features:

Squads: autonomous, cross-functional teams.
Tribes: collections of squads working on related areas.
Chapters: functional groups (like designers or data analysts) that support each other across squads.
Guilds: informal communities of interest.
Strong culture of autonomy, alignment, and engineering excellence.

Good for:

Fast-moving, product-driven organizations looking for high autonomy and continuous improvement.

Things to watch:

The Spotify model was built for Spotify, at a certain point in time. Copying it without adapting it to your own culture and needs usually backfires. Use the ideas without cloning the org chart.

None of these are magic solutions. Each one offers different tools to help you:

Coordinate multiple teams
Align delivery with strategy
Support continuous learning
Keep Agile principles alive at scale

The best approach? Start with the problem you’re trying to solve. Then pick the bits that help.

These days, most organizations use a hybrid approach. The goal isn’t to be “SAFe-certified”—it’s to deliver value, continuously, at scale.

In the next lesson, we’ll take a deeper look at how Agile teams stay coordinated across shared backlogs, product lines, and time zones, without falling into chaos.

8.8.3: Coordinating across multiple teams

Scaling Agile isn’t just about adding more teams. It’s about keeping those teams aligned without creating bottlenecks or bureaucracy. When multiple squads work on the same product or system, coordination becomes just as important as execution.

Here’s how successful teams stay in sync.

One product, one backlog (even if it’s big)

In Agile, the backlog is your single source of truth. When scaling across teams, that doesn’t change—you still want one prioritized backlog per product.

Each team pulls work from it, and the Product Owner (or Product Manager) is responsible for prioritizing based on value. This reduces duplication, avoids clashing priorities, and ensures everyone’s heading in the same direction.

For large programs, you might structure the backlog into themes, epics, and user stories, so different teams can pick up stories that align with their skills while staying aligned to the same larger goal.

Program-level coordination

Some coordination is unavoidable at scale. If three teams are building different components of the same feature, someone needs to keep the bigger picture in view.

Common coordination practices include:

Scrum of Scrums – A short, cross-team stand-up to share updates, dependencies, and risks.
Integration planning – A recurring check-in to make sure deliverables line up across teams.
Shared demos or sprint reviews – Where all teams showcase what they’ve delivered and get feedback from stakeholders together.

These don’t need to be heavyweight ceremonies. They just need to keep the loop tight between teams.

Clear ownership of shared systems

When multiple teams touch the same platform, database, or component, it helps to define:

Who owns what
Who maintains what
Who approves changes

Otherwise, teams either block each other or trip over one another.

Some organizations assign ownership by platform, API, or product domain. Others rotate ownership based on workload. What matters is that someone’s responsible—and available—when questions arise.

Aligning sprint cycles

Not all teams need to sprint in lockstep. But when dependencies are high, it helps to at least:

Use the same sprint length (e.g., two weeks)
Start and end on the same day
Align reviews or demos

That way, planning is easier, handovers are cleaner, and stakeholders aren’t overwhelmed by conflicting rhythms.

Communicate like a network, not a hierarchy

Agile at scale works best when teams communicate peer-to-peer, not just up and down the chain. Make sure:

Designers are talking to designers
Testers are aligning test plans
Product Owners are coordinating roadmap changes

Encourage people to connect horizontally—across teams, not just within them. That’s how knowledge flows and duplication gets caught early.

Keep the customer in view

As you scale, it’s easy to slip into internal complexity. But the goal is still the same: delivering value to users. Keep that front and center by:

Using shared outcomes or OKRs (Objectives and Key Results)
Anchoring teams to real customer journeys, not just components
Inviting real users to multi-team reviews or demos

In the next lesson, we’ll look at what happens when scaling Agile goes wrong, and how to avoid falling into the trap of “cargo cult Agile,” where the rituals are followed, but the results never come.

8.8.4: Cargo cult Agile

At its best, Agile is transformative. But at its worst, it becomes theater—stand-ups without purpose, Jira boards no one trusts, and teams sticking their plans without regard for others.

This is cargo cult Agile, where teams copy the visible rituals but miss the underlying intent.

The term comes from post-WWII islanders who built wooden airstrips and bamboo control towers, hoping planes would return with supplies. They had seen the outcomes, but not the systems behind them.

In the context of Agile, it looks like this:

Teams “do sprints” but aren’t delivering anything usable.
Retrospectives are scheduled but never acted on.
Product Owners don’t really own the product.
“Agile” is used as an excuse for skipping planning, design, or governance.

When scaling fails, it usually falls into one of these traps:

1. Top-down command wearing Agile clothes

Leaders still expect rigid plans and fixed outputs, but call it Agile because it’s in two-week sprints. This creates confusion, pressure, and burnout.

2. Process without purpose

Teams follow the rules—stand-ups, demos, velocity tracking—but no one knows why. There’s no learning, no ownership, and no value.

3. Agile as a team-only solution

Leadership stays waterfall, governance stays rigid, and Agile becomes something “the delivery team does.” It’s never integrated into how the organization makes decisions.

4. Metrics without meaning

Velocity becomes a target. Charts are optimized, not outcomes. The team looks productive, but delivers the wrong things faster.

So, what should you do instead?

1. Anchor to real value

Ask: What problem are we solving? How do we know it’s working? What are users doing differently now? Agile is a means to an end, not the end itself.

2. Treat mindset as infrastructure

It’s not enough to train teams. Leaders, PMOs, finance, and HR all need to understand Agile principles. Otherwise, the system will fight itself.

3. Empower, don’t just restructure

Changing reporting lines won’t fix delivery. Teams need clarity, safety, support, and a voice in decision-making. Without that, autonomy becomes chaos.

4. Go slow to go fast

Scaling Agile means unlearning habits. Give teams time to try, reflect, and improve, rather than just launching a new model with a date and a slide deck.

The irony is that failed Agile transformations often forget to be Agile about the transformation itself. You don’t need to get it all right up front. What you need is: