Single-Team Scrum: the Swiss Army Knife
With one Scrum team, life is simple. You can use Scrum effectively to optimise for pretty much anything:
- Innovation – focus on discovery, experiments, learning.
- Efficiency – focus on throughput, predictability, flow.
- Customer tailoring – work closely with one client, co-create, shape the solution together.
You swap in different practices, adjust how you use events and artefacts, and off you go. It still “looks” like Scrum, and it mostly works. This flexibility is exactly why people start to believe: “Scrum (or Agile) works for everything.” At single-team, that’s almost true.
Many Teams, Scaling Frameworks: The Mask Comes Off
Now add many teams and a scaling framework. Suddenly, the true optimisation goal becomes visible. You start seeing things like:
- Shared standards (Definitions of Done, common processes)
- Waste reduction and removal of duplication
- Reuse across teams
- Small batches and controlled WIP
- Focus on flow and handoffs
- Overlapping skills and roles to keep flow
What is all this really about? You guessed it: efficiency.
Most scaling approaches are built on ideas from:
- Toyota Production System (TPS)
- Queueing Theory
- Theory of Constraints (ToC)
- and more…
These are excellent bodies of knowledge, but their default settings are about throughput, predictability, and utilisation, not innovation and not deep customer tailoring.
Are These Mechanics Effective for Innovation and Customer Tailoring?
That’s the key question. My answer: usually not. In the exploration phase, efficiency is not the goal. In the early stages of a product when you’re still figuring out what to build and why, the primary goal is learning, not efficiency.
In that phase:
- Strict standards narrow your option space too early.
- Removing “waste” and “duplication” can kill useful parallel experiments.
- “Small batches” assumes stable, repeatable work items—but early discovery is messy, irregular, and not really “batched” at all.
If your multi-team setup is designed around standardisation and flow, but you think you’re optimising for innovation, you’ll unintentionally constrain exploration.
You won’t see this immediately. It shows up as:
- fewer cool ideas
- lots of “continuous improvement” around a solution that maybe shouldn’t exist in the first place.
Product Vision Not Compatible With Custom Tailoring
There’s another subtle mismatch: product vision and customer focus.
A strong product vision:
- Fits very well with innovation
- Helps you say “no” to ideas and requests that don’t align.
- Intentionally excludes some customers, ideas or stakeholder requests
- Helps team self-organise
That’s good strategy. But it’s not the same as “customer focus” in a tailoring sense.
A vision-led product organisation will say “no” to some customers, or decline features that might be valuable for a specific client but not for the broader product.
That’s perfectly rational from a product strategy perspective, but it’s not co-creating a tailored total customer solution. It’s not the same thing as “We’ll shape this around you.”
Can TPS, Queueing Theory and ToC Help Innovation? Yes… If You Flip the Goal
The good news: the frameworks and theories themselves aren’t the enemy. Most of them say, directly or indirectly: “Here’s how to think. Now design your own system.” So you can absolutely repurpose them, for example:
- Queueing Theory: Apply it to experiments, not just features or tasks. Limit WIP on hypotheses so you actually learn.
- TPS-style problem solving: Use A3s and root cause analysis to deeply understand customer problems, not just process issues.
- Theory of Constraints: Direct attention to whatever blocks discovery and learning, not just what blocks throughput.
At that point you are no longer optimising primarily for efficiency. Instead, you’re building a learning system.
But let’s be honest: if you change a method/framework far enough to truly optimise for a different goal (innovation or deep customer tailoring), you are no longer really doing the thing as designed. And that’s okay as long as you know it.
Why This Matters (a Lot More Than It Sounds)
Who cares? Well, you might care when you start seeing one or more of these:
- Burnt-out teams: People are held accountable for innovation and customer delight, but the underlying process is built for efficiency. Result: permanent overload, constant tension, and a feeling of failing at goals the system never truly supported.
- Frustrated customers: The organisation talks about “customer focus”, but in reality optimises for reuse and uniformity at scale. Result: customers hear the right words but experience rigid offerings and slow, generic responses.
- Fake innovation: Teams genuinely believe they’re innovating, but the system quietly optimises for standardisation and predictability. Result: lots of incremental tweaks, “innovation theatre”, and very little meaningful change.
So What To Do?
If you care about innovation, efficiency, or tailored customer focus, then:
- Be explicit about which one you’re really optimising for.
- Don’t assume your scaling framework is neutral, it already picked one.
- Look at your mechanics (standards, reuse, flow, batching) and ask:
What are these really designed to maximise? - Evolve Your Own Framework tailored to your specific needs.
Because in the end if you do not pick an optimizing goal on purpose your framework probably already picked one by accident.