Scrum doesn’t scale if your portfolio design doesn’t
If you’re an experienced Scrum Master, you’ve probably seen this pattern:
Your team’s Scrum is in good shape: clear Sprint Goals, decent refinement, steady value delivery. However, the organization feels slow. Work sits in queues, prio’s change and what are all these dependencies on other teams….?
Leadership asks for improvements and suddenly you are scaling ending up with more alignment ceremonies… but not more outcomes.
The problem here might not be the process… It’s worth inspecting how the company is designed to make commitments and manage dependencies: funding & governance. Why? Adaptability is constrained less by team rituals and more by how the enterprise allocates authority, funding, and decision rights.
Why dependencies aren’t always “bad”
A dangerous thinking mistake is to assume that we should optimise for minimising team dependencies. Let me explain:
Autonomous Product Groups
If you have loosely coupled products (different strategies, different customers, limited reuse between products) in your portfolio then you want few dependencies between product groups. Why? because each dependency becomes a drag. Centralized planning and control often add cost without adding value. Loosely coupled products benefit from local autonomy, experimentation and decision power, This enables them to adapt quickly on their own which suite their independent business model.
As a Scrum Master you will see different strategies, limited need for shared capabilities. Adaptability, speed and success comes from local decision-making.
What it feels like in Scrum
- Teams should ship with minimal coordination
- Heavy enterprise governance becomes drag
- Local outcomes matter more than global “alignment”
Synergetic Product Groups
On the other hand, in a strongly coupled product portfolio(shared strategy, shared business model, shared capabilities), integration is a source of advantage: standards, platforms, cross-sell, coordinated pivots. So, dependencies are a good thing as this make it easier for the product portfolio to move as one.
As a Scrum Master you see different products, similar strategies and real benefits from shared platforms, services, capabilities, standards, and reuse.
What it feels like in Scrum
- Some dependencies are worth it (platforms, shared services)
- Guardrails matter (standards, interfaces, decision forums)
- Autonomy exists, but inside a shared direction
Figure 1. Balancing Adaptability
source: Changing the Engine Midflight. Cesario Ramos, 2027.
So, dependencies are neither good nor bad on their own. Their value depends on your portfolio design. In a strongly coupled portfolio, you often want stronger, intentional dependencies. In a loosely coupled portfolio, you want weaker dependencies so each group can adapt at low cost.
Why this matters?
Most “scaling pain” shows up when the org tries to live in two quadrants at once (Figure 2 dynamics):
Needs high integration, but wants high autonomy → misalignment, rework, escalations
Needs autonomy, but enforces heavy integration → waiting, approval gates, dependency theater
Worst case: low integration and low autonomy → fragmented and slow (committees everywhere)
As a Scrum Master, you can’t “ceremony” your way out of that. What shows up in refinement, Sprint Planning, and daily coordination is often a portfolio/governance design problem surfacing as team-level friction exactly the kind of mismatch Creating Agile Organizations warns about.
What you can do?
Design your product groups to match the right level of dependencies. Try naming the portfolio pattern first and connecting it to the strategy. For example: In a retro or leadership conversation, replace “we need better process” with:“What level of connectedness do we actually require between these products?” Then either increase and decrease dependencies with govarnance, funding rules and censtrlized coordination. In a strongly coupled portfolio you want to P&L responsibility to be more centralised, while in a loose couple portfolio you want the P&L to be more decentralised.
Strongly coupled portfolio → more centralized P&L / funding rules / decision forums
Loosely coupled portfolio → more decentralized P&L / local funding authority / fewer cross-group gates
Key Point
Dependencies between teams and groups are not inherently good or bad, and your job isn’t to “scale Scrum.” It’s to help the system integrate where it creates advantage and to decouple it otherwise.
Want to learn more about Agile organization design?
Visit the Creating Agile Organizations (CAO) website.