Has your Scrum implementation caused more problems than it solved?

Implementing Scrum helps your development department but breaks the old way of doing things, so the overall process actually slows down.

Everyone was bashing your development department. You were too slow, you were the bottleneck – if only development would be faster, we could earn so much more money … you know what I’m talking about. It was time to change something so you introduced Scrum. A couple of months (and quite a few crises) later your team churns along with impressive speed and better quality. The bottleneck is gone. Surprisingly though, the business results haven’t moved an inch. What’s wrong here? Weren’t we supposed to be swimming in money if development was faster?

Changing one tire

Imagine a formula one car. The driver doesn’t go as fast as we’d like. He feels that his left rear tire doesn’t have enough grip, so he asks the pit crew: “Hey guys, my left rear tire lost some grip. Please fix it.”
He comes in for a pit stop, and the mechanics do exactly what he asked: they change his left rear tire. They put on the greatest tire they have in stock: the über super-duper extra grip tire. The driver gets exactly what he wanted and puts the pedal to the metal.

Changing one tire is a bad idea

Fast forward into the next hairpin bend: the driver breaks and the car starts to sideslip. He has to fight to get the car back on track and loses valuable seconds. He’s slower than before. But why? It’s obvious, right? The “über super-duper extra grip” tire – while perfect in its own right – caused an inbalance in the grip for the car and made it sideslip. There are really good reasons for usually changing all four tires on a formula one car.

Introducing Scrum only in development is like changing one tire

If you only optimize one department, you’re changing just one tire. Even if your development department is top notch it will slow down the overall throughput, because it breaks the old way of doing things without improving the core business processes. Product management, QA, and Operations will be overwhelmed with the amount of work done by the Scrum team. And, unlike before, there won’t be any more valuable features in the pipeline if product management doesn’t improve its processes as well.

The bashing has stopped, but an eerie silence follows. Everyone stares in disbelief at the unchanged quarterly earnings report. Slowly, it dawns on them that they need to do more: they need to optimize the overall, end-to-end process.

What’s your experience been with introducing Scrum in just development? Let us know in the comments below.