“We implemented Scrum six months ago, but we aren’t shipping any faster. In fact, it feels like we are spending half our time in meetings talking about why we can’t work. Should we go back to the old way?”
I hear this frustration often from CEOs and investors. They buy into the promise of Agile: adaptability, speed, customer-centricity, but the reality feels like increased overhead and chaos.
Here is the uncomfortable truth: Scrum is not a turbocharger for your development team. Scrum is a diagnostic tool.
It does not inherently increase speed; it creates transparency. And for many executives, that transparency is painful.
The Transparency Trap
One of the most common reasons I see Agile transformations fail is not because the process wasn’t followed, but because it worked too well.
Before Scrum, your organizational inefficiencies were hidden behind long deadlines, opaque “work in progress” statuses, and hero-culture firefighting. When you introduce Scrum, you turn on the bright lights in a messy room. Suddenly, you see every delay, every dependency, and every bottleneck.
It often looks like everything is working worse than before.
I have seen organizations panic at this stage. They blame the process: “Scrum is slowing us down!” They revert to the old system because it feels safer. But the problems are still there; they are just no longer visible. You are flying blind again, and the transformation has failed for the wrong reasons.
Impediments are Strategic Data
If you can survive the initial shock of transparency, you gain access to one of the most powerful management tools available: The Impediment List.
Too many leaders ignore the Roadblocks raised in stand-ups or retrospectives, viewing them as complaints for the Scrum Master to handle. This is a mistake.
As a CTO, I learned to track organizational impediments structurally. I didn’t just want them fixed; I wanted to analyze them.
- Are the impediments disappearing? Good.
- Are new roadblocks popping up in multiple teams simultaneously?
This is your feedback loop. If I made a decision on the department level – say, changing a major process or restructuring a reporting line – the impediment data told me the truth. If “waiting for approval” suddenly spikes across three teams, my new policy is hurting productivity. You want to know that quickly and transparently, so you can act on it and figure out what went wrong.
Scrum doesn’t solve this problem. It gives you the data to know if your leadership decisions are helping or hurting. Figuring out how to solve the issues in your organization – remains a task that you and your leadership-team will need to work on.
The Hardest Part: The “Cross-Functional” Challenge
Even with transparency, you cannot move fast if your team structure is fighting against you. This was one of our hardest-earned learnings while scaling the engineering organization at Webfleet from 30 to over 300 engineers.
We all know the buzzword: “Cross-Functional Teams.” But what does that actually mean? How much cross-functionality do you actually need? And how much can you realistically get out of your people before they leave or break down due to cognitive load?
Stage 1: The Unicorn Hunt (Mistake) Initially, we thought this meant every individual needed to be T-shaped. We tried to build teams where everybody could do everything. This is not realistic. You cannot ask a backend specialist to suddenly be great at UI design. Well, you can ask – but 99% of the time, it will just not work and only lead to frustration on all sides.
Stage 2: The “Complete” Team (Better, but Flawed) Next, we moved to ensuring the team collectively possessed every possible skill in the engineering spectrum. So not everyone needs to be able to do everything – but someone in the team needs to be. This sounds better, but it leads to inefficiencies. If you put a firmware engineer in a team that works on a web app, they will sit idle or do busy work for 80% of the Sprint. Sounds familiar? Well – it was very common for us at this stage.
Stage 3: Mission-Based Capabilities (The Solution) The breakthrough came when we realized: Teams need to have all capabilities required to fulfill their specific mission.
If a team’s mission is to build a mobile app, they do not need firmware skills just to be “cross-functional.” They need iOS, Android, and API developers. If you force a firmware engineer into that structure, you break the team’s cohesion. Finding a good mission for the teams – and a good split of the required tasks into team missions becomes an extremely important exercise in organizational design at this point.
We had the most success structuring our team missions around products – but when your organization grows, it can also be helpful to have a couple of teams with specialized missions in other areas. To give an example: having a small team with the specific mission to “make R&D effective and efficient by providing a world-class developer platform” – can be a good investment when you reach a certain size.
The High-Level Takeaway
If your R&D department feels slow, do not blame the engineers, and do not blame the methodology.
- Accept the transparency: The mess was always there; now you can see it.
- Review the impediments: Are your leadership decisions causing the bottlenecks?
- Check the structure: Are your teams designed around a clear mission, or are they just collections of random skills? Is your organizational structure helping your teams to be effective – or is it hurting productivity?
Speed is a byproduct of removing the obstacles that Scrum exposes. If you aren’t willing to do the work and remove them, no amount of Agility will help you.
