scaling

Scaling agile: Lessons from the Trenches (AKA the Burning Hell of Real-Life Implementations)

Mise Ă  jour le

Last week, a few friends nudged me to check out an article with the bold statement: « Agile scales beautifully when done right. » It came with a neat list of tips 
 you know the drill :

“ Here’s my approach: 1ïžâƒŁ Start small, think big: A focused pilot can create momentum for broader change. 2ïžâƒŁ Get things in order before scaling: Scaling unresolved challenges just multiplies inefficiencies.3ïžâƒŁ Focus on team autonomy: Empowered teams move faster and innovate better.4ïžâƒŁ Align on shared goals: Unity creates clarity and reduces friction.5ïžâƒŁ Invest in cross-team collaboration: Collaboration breaks silos and fosters synergy. 6ïžâƒŁ Adapt practices to your context: Frameworks are guides, not rules.”

At first glance, it sounds logical, inspiring even. But if you’ve ever been in the trenches of scaling agile across complex organizations, you probably feel the same way I do: this advice is too clean, too optimistic, too
 fluffy. Scaling agile isn’t just about following good principles; it’s a messy, brutal, iterative slog.

And yes, often it fails spectacularly.

So, let’s dig in. Here’s my take, based on 13+ years of wrestling with agile at scale across industries, org charts, and budgets—and being humbled by the realities every single time.

1ïžâƒŁ Start small, think big

Truth: Starting small is great. Sure, pilots are a great starting point. But the trap is treating a pilot as a proof of concept when it hasn’t been stress-tested in the actual organizational system. Pilots are often too small, and are without any real thought about scalability. Pilots often operate in isolation—detached from the broader system of dependencies, governance structures, and real-world complexities.

Here’s the systemic risk: when you optimize locally (within the pilot), you risk suboptimizing the whole. The improvements seen in one part of the system might create bottlenecks, inefficiencies, or misalignments elsewhere. For instance, a highly efficient pilot team might accelerate delivery only to clash with slower downstream processes—or overwhelm other teams that aren’t equally equipped.

Scaling Agile demands systems thinking. Before treating a pilot as a green light, ask:

  • What ripple effects could this success create across the organization?
  • Are we optimizing one area at the expense of another?
  • What interdependencies need to be considered and resolved before expanding?

Pilots shouldn’t just validate local success; they should stress-test the system as a whole. Otherwise, you’re scaling suboptimization, not agility.

👉 What I’ve learned: Don’t stop at the pilot’s success. Your “small start” must explicitly address real-world complexity: cross-team dependencies, governance models, and the nasty bottlenecks that will emerge at scale. Otherwise, you’ll sell an illusion, not an honest truth.

2ïžâƒŁ Get things in order before scaling

It seems obvious: clean up the mess, then scale. Yet many organizations get stuck in an endless loop of « fixing » before making any real progress. The reality? There will always be inefficiencies, technical debt, and silos. The key is knowing what actually needs fixing before scaling and what can be improved while scaling.

đŸ”„ The Common Pitfall: The « Cleanup Trap »

Organizations often overcorrect when preparing to scale. They embark on multi-year transformation projects, aiming to standardize processes, upgrade legacy systems, and eliminate every inefficiency. Or they think. Meanwhile, competitors are moving faster, capturing market share, and adapting in real-time. By the time the « perfect system » is in place, the business context has often changed—rendering parts of that effort obsolete. So much effortscand money burned !!

👉 What I’ve learned: Prioritize critical bottlenecks— aka the stuff that could derail scaling completely. But accept that some inefficiencies will only surface as you scale. Scaling isn’t about reaching a utopian level of efficiency before growing—it’s about balancing structural readiness with adaptability. The best organizations scale while refining their processes, ensuring they don’t get stuck in an endless prep phase.

✅ Identify mission-critical constraints—the things that will make scaling impossible or create exponential inefficiencies (e.g., a payment system that can’t handle increased transactions, a single-point-of-failure team, or a compliance issue that will block expansion).

✅ Use a « just enough » approach—fix what will break under scale, but don’t aim for an ideal state before moving forward.

✅ Leverage scaling to expose hidden inefficiencies—some problems only emerge because you scale. Don’t try to predict and solve everything upfront. Instead, create adaptive mechanisms to handle issues as they surface.

✅ Build agility into the process—scaling is not a one-and-done event; it’s a continuous evolution. Create feedback loops (retrospectives, data-driven decision-making, quick iterations) to keep improving as you grow.

And, before you embark on a multi-year cleanup project, ask yourself: What’s the minimum viable structure that allows us to scale without imploding? What feedback loops do we have in place to adapt as new challenges arise?

Because in the end, perfection kills momentum—progress is what matters.

3ïžâƒŁ Focus on team autonomy

“Empowered teams innovate better.”

100% agree. Absolutely. When teams have ownership, they move faster, take smarter risks, and find creative solutions. But there’s a dark side to autonomy at scale: chaos. Without alignment, you’ll end up with teams duplicating efforts, pulling in opposite directions, and burning resources on mismatched priorities.

👉 What I’ve learned: Autonomy without alignment isn’t empowerment – is just noise. True autonomy isn’t about letting teams do whatever they want—it’s about enabling them to make decisions in the right direction. The best organizations scale autonomy intentionally, ensuring teams are free to innovate while staying connected to a larger purpose. Autonomy needs guardrails.

✅ Define a strategic North Star—whether it’s a clear product vision, OKRs, or value streams, teams need a shared destination to align their efforts.

✅ Use a lightweight governance model—set up decision-making principles that create clarity without excessive control. For example:

  • What decisions are decentralized? (E.g., team-level process improvements)
  • What decisions require coordination? (E.g., major architectural changes)
  • What decisions need top-level alignment? (E.g., strategic bets, key integrations)

✅ Encourage cross-team visibility—foster communication mechanisms (like regular syncs, shared roadmaps, or knowledge-sharing rituals) to reduce duplication.

✅ Empower within boundaries—think of autonomy like a sandbox: give teams space to experiment within a structured environment that ensures alignment.

So before pushing for full autonomy, ask yourself: Do teams understand how their work fits into the bigger picture? Are there lightweight mechanisms in place to ensure alignment without bureaucracy?

Because autonomy at scale isn’t about removing structure—it’s about designing just enough structure to let innovation thrive.

4ïžâƒŁ Align on shared goals

“Unity creates clarity.” Sounds nice, right? Except most “shared goals” in the real life are abstract fluff that mean different things to different teams. The result? False alignment. Everyone thinks they’re on the same page, but when execution starts, priorities diverge, creating friction, wasted effort, and misallocated resources.

Many organizations assume that because a goal is communicated, it’s understood the same way by everyone. In reality:

  • High-level goals are often too vague (“Improve user engagement”)—leaving teams to interpret them in conflicting ways.
  • There’s a disconnect between leadership vision and team execution—causing frustration when efforts don’t ladder up.
  • Goals are misaligned across functions—engineering, design, and product might all agree on an outcome but prioritize different paths to get there.

Sounds familiar?

👉 What I’ve learned: Alignment without actionability is useless. True alignment doesn’t come from broad mission statements—it comes from clearly defined, measurable objectives that guide decisions at every level. The best organizations ensure that strategy isn’t just set but translated into execution with clarity.

✅ Translate high-level goals into clear, actionable objectives—use frameworks like:

  • OKRs (Objectives & Key Results) to create measurable progress.
  • North Stars to ensure teams focus on meaningful impact, not vanity metrics.
  • Strategic Bets to align risk-taking with company priorities.
  • Product Strategy & Roadmaps to bridge long-term vision with short-term execution.

✅ Use data to create clarity—ground shared goals in metrics that remove ambiguity. Instead of “Increase retention,” define how much, for whom, and by when.

✅ Foster continuous alignment—goals should be revisited regularly, not just set once a year. Create feedback loops (e.g., quarterly planning, cross-team reviews) to ensure teams stay aligned as priorities evolve.

✅ Make alignment a two-way street—teams shouldn’t just receive goals; they should help shape them. This ensures buy-in and makes execution smoother.

Without this, alignment will remain an illusion.

So before assuming your teams are aligned, ask yourself: Can every team explain how their work contributes to the bigger picture? Do goals have clear, measurable outcomes—or are they just aspirational statements?

Because without a bridge between strategy and execution, alignment will always be an illusion – a costly one.

5ïžâƒŁ Invest in cross-team collaboration

Collaboration is often romanticized as the key to innovation – especially by us Agile Coaches and Collaboration Experts. « Collaboration is magical «  😍… Yeah we get that except when it’s not. At scale, too much collaboration is a hidden tax. Endless meetings, excessive handoffs, and complex dependencies slow everything down. Ironically, the more an organization scales, the less it should rely on constant coordination. Yes : the more you scale, the less you should “collaborate” (hear me out).

Many organizations assume more collaboration = better alignment. In reality, excessive collaboration will :

  • Drain productivity—too many meetings leave little time for … work.
  • Increase bottlenecks—when teams rely on constant syncs, execution slows down.
  • Create decision fatigue—when every decision requires input from multiple teams, speed and autonomy suffer.

đŸ€Ż

👉 What I’ve learned: Reduce agressively dependencies, don’t manage them. The best organizations treat collaboration as an investment, not a default behavior. They minimize unnecessary dependencies, structure teams for autonomy, and use targeted collaboration methods that drive real impact. « But we organised our team into ART » … Yeah cool, but you need to go further.

✅ Minimize shared dependencies from the start—instead of coordinating around bottlenecks, redesign teams to avoid them. Use:

  • Domain-Driven Design (DDD) to clarify ownership and boundaries.
  • Team Topologies to structure teams around flow, not functions.
  • Dynamic Reteaming to evolve team structures as needs change.

✅ Use collaboration as a last resort, not a default—first, ask: Can this be solved through better team design or automation? If collaboration is truly needed, make it intentional.

✅ Make remaining collaboration lean & high-impact—instead of daily syncs and excessive coordination:

  • Async tools (Notion, Loom, Slack updates) to reduce unnecessary meetings.
  • Big Room Planning for focused, high-value alignment instead of scattered touchpoints.
  • Clear decision-making frameworks and clear delegations rules so teams know when they need to coordinate vs. when they can act independently.

So before pushing for more collaboration, ask yourself: Are we solving the root issue (dependencies) or just adding more process to manage them? Is this collaboration truly necessary, or can we enable teams to move faster without it?

Because at scale, smart collaboration beats excessive coordination every time.

6ïžâƒŁ Adapt practices to your context

“Frameworks are guides, not rules.” True, but also sooooooo vague. Many organizations say they’re “adapting frameworks,” but what they’re really doing is taking the easy superficial bits while dodging the hard cultural changes.

👉 What I’ve learned: Forget frameworks and on-the-self stuff and do the hard work. The best organizations don’t scale by copying what others have done—they build their own operating models through experimentation, feedback loops and continuous learning :

✅ Forget rigid frameworks—focus on first principles

  • Instead of asking “Which framework should we use?”, ask “What problem are we solving?”
  • Build a system tailored to your business model, culture, and constraints.

✅ Design around feedback loops & real data

  • Use leading indicators (not just lagging metrics) to see if your ways of working are effective.
  • Measure decision cycle times, team flow, and customer impact—not just process adherence.

✅ Treat everything as an experiment

  • Scaling isn’t about blindly applying “best practices.” It’s about constant iteration.
  • Pilot changes, track results, and discard what doesn’t work.

✅ Be pragmatic, not dogmatic

  • Process should serve outcomes, not the other way around.
  • If something feels bureaucratic, question it. If a practice stops adding value, cut it.

So before adopting a framework, ask yourself: Are we solving for our reality—or just applying something because it worked elsewhere? Do we have fast feedback loops in place to test and refine our approach?

Experiment relentlessly. Keep what works, throw away what doesn’t. Scaling is hard enough—don’t drag unnecessary baggage with you. Scaling isn’t about collecting frameworks—it’s about designing a system that actually works for you.

Why This Matters

It was important for me to respond—not to this specific post, or this author (there are hundreds of similar ones), but to the broader narrative that scaling agile is simple if you “just follow the steps.”

Too many consultants and organizations are selling this dream—at high prices—without being honest about the challenges, failures, and consequences. The truth is, scaling agile is messy, exhausting, and deeply humbling. It demands honesty, adaptability, and a willingness to confront uncomfortable realities about your organization.

So, the next time someone tells you scaling agile is just a matter of following six steps, take a moment to ask: are they selling the dream or living the reality?

Scaling agile isn’t a checklist; it’s a balancing act. It’s about managing polarities and making trade-offs : autonomy – alignment, collaboration – efficiency, starting small -thinking big. There’s no “right” way—just lots of wrong ones to avoid.

I’ve been there countless times, I can qualify for « agile at scale expert » hat for sure, yet the truth is that every time I engage myself in those projects : I am uncertain. Because here’s the brutal truth: even when you “do everything right,” scaling agile will be painful sometimes, and costly, and can fail. Sometimes the organizational culture won’t shift. Sometimes leadership doesn’t buy in. Sometimes teams burn out. That’s reality. Because scaling agile means adding complexity on an already complex system. So whenever you can avoid scaling, avoid it. Keep things simple as long as you can.

But when it works—when teams align, dependencies shrink, and innovation flows—it’s worth every painful lesson.

What’s been your experience scaling agile? Let’s swap war stories. 🌍

(P.S. If you’re curious about some of the methods I mentioned—DDD, Team Topologies, Dynamic Reteaming—drop me a DM or comment below. Always happy to nerd out.)

Vous pourriez aussi aimer...