I was working with a client not long ago when we hit a wall that almost every organization eventually runs into: what happens when your Scrum team isn’t truly cross-functional?
It started with something simple. The team wanted to show a number on their company website…nothing fancy, just a clean data point that would make the customer experience better. But to do it, they needed an API to pull the number from the database. The problem? No one on the team could build the API. Another team owned that layer, and they had their own backlog, priorities, and deadlines.
On paper, it was just a dependency. In reality, it was a spotlight on a much bigger issue, a system design problem hiding under the surface.
When the Framework Meets the System
Scrum assumes a team can deliver a potentially shippable increment every Sprint. That’s what keeps learning cycles short and value flowing. But when a team can’t deliver without waiting on someone else, the framework starts to break down under the strain.
The team’s Sprint Goal isn’t under their control anymore. Velocity tanks, forecasts feel like guesses, and instead of focusing on outcomes, everyone’s managing handoffs and dependencies. It’s not that Scrum isn’t working, it’s doing exactly what it was meant to do: reveal the flaws in your system/organization.
I’ve seen this happen so many times it’s almost predictable. Work gets sliced by component instead of value. Teams deliver pieces of the puzzle, an API here, a front-end there, but no one delivers the whole picture. By the time it reaches the user, the original intent has faded or the needs have changed.
The Mirror Moment
That “number on the website” became our mirror moment. Every conversation circled back to the same truth: the team couldn’t deliver value end-to-end because of how they were structured.
It wasn’t a motivation problem or a skills problem. It was a design problem. The organization had built functional silos, API teams, front-end teams, database teams, all optimized for local efficiency. Everyone was busy, but the customer was still waiting.
That’s when I started teaching them something I’ve carried with me for years: Richard Hackman’s 60-30-10 rule.
Why Team Design Matters More Than Anything
Hackman’s research found that 60% of a team’s success comes from how it’s designed before the work even begins. Thirty percent comes from how it’s launched. And only ten percent comes from what happens while it’s running.
That insight changes everything. You can coach, facilitate, and train all day long, but if the team can’t deliver value without outside help, you’re swimming upstream. The system wins every time.
This is why most “agile transformations” fail. Organizations try to fix behavior before they fix structure. They add standups, retros, and Jira boards, but the teams are still trapped in silos. You can’t iterate your way out of a design flaw.
The Multitasking Trap
Gerry Weinberg’s research on multitasking adds another layer to this. Every time we switch between projects or teams, we lose focus, and productivity drops fast.
When specialists are spread across three, four, or five teams, they become permanent bottlenecks. Everyone’s busy, but nothing’s getting done. It looks like velocity, but it’s really just motion. Weinberg called it “the illusion of progress.”
Scrum exposes this illusion. The Daily Scrum/standup becomes a chorus of “waiting on…” and “blocked by…” It’s not that the people aren’t capable, it’s that the structure forces them into constant context switching instead of flow.
What We Can Do Now
In the short term, you can reduce the pain.
- Map your dependencies so everyone can see them.
- Invite upstream and downstream teams into refinement.
- Define what “Done” means when work crosses boundaries.
- Pair across teams for a Sprint to build trust and shared learning.
These steps help, and they’re worth doing. But they’re not the fix. They just make the pain visible enough that people can no longer ignore it.
The Real Fix
The real fix is to build teams that are cross-functional and empowered to deliver value independently. Teams that can design, build, test, and ship, all within the same group. That’s where learning accelerates and ownership comes alive.
It’s also the hardest change for most companies to make, because it touches everything: reporting lines, budgets, HR policies, even identity. Moving from functional silos to value-aligned teams means rewriting the organization’s operating system.
But that’s the point. Scrum isn’t failing when these problems appear, it’s shining a light on them. It’s holding up a mirror and asking, “Is this the system you want?”
I’ve watched teams transform when they’re finally given end-to-end ownership. The energy shifts, the conversations change, and they stop talking about dependencies and start talking about outcomes. They stop waiting for permission and start experimenting, and they begin to see the customer again.
That’s what Hackman meant by good design. That’s what Weinberg meant by focus.
When we get the structure right, we don’t have to fight for agility anymore. It just happens.
