Why Fast Is Slow
… and the other way round. We are all familiar with the maxim that pace is a by-product of … something else, not only the sheer will to get from point A to point B fast. This stands true for life in general, and for software development in particular. Anyone in charge of releases would sell their souls to get hold of a magic recipe for fast & smooth deliveries. The paradox is that the faster we want to get things done, the bumpier the progress. Why is it like that?
Let’s compare software development flow with a car ride. What is needed for the trip to take as little time as possible? An even driving surface, clear signs on the way, and no traffic jams. Plus, you will have to rely on the car, the very vehicle that carries you. That is, you need to take care of the technical maintenance in advance. As a thoughtful driver, you will want to bring the probability of unexpected emergencies to a minimum.
What would happen to a single-minded driver who is itching to get to their destination fast, but whose car has a leak in a tire, or a low battery, or little fuel in tank? What if there are no gas stations on the way? What if the road is steep and rugged? The speed-addict driver would be confronted with draining setbacks and delays all along, and it would get them twice (or 3x, or 6x, or 12x) as much time to reach their destination, and then they would rub the back of their head saying: “Hmm, I needed to get there fast, and I ended up so awful late”.
Driving by car provides a fitting metaphor to the reasons for bumps and delays in releases. The very act of driving is the actual work, same as code writing, bug fixing, build integration, etc. If those doing the actual work get distracted by side factors, it takes more time and effort to continue driving. Re-work, a poor balance of tasks and incoherent interactions slow things down. An organization which has the smoothest process, with all the slow-down factors kept to a minimum, gets to the destination faster. It doesn’t mean that the car will fly on an auto-pilot as soon as this elusive perfect development process is in place in your team (if ever). No. The process has to allow for a wise fix-and-go to maximize the time spent on actual driving in the right direction, with no detours and stopovers. It does take some hard thinking and the ability to follow through if we want to bring the unexpected setbacks to zero, making sure that most of the time is spent on the actual work.
What slows your team down? Which bottlenecks recur? Can you identify them? How do they slow you down? Can you re-arrange the development process to eliminate the bottlenecks? As I’ve observed, 99% of unexpected emergency work and distractions drill down (if you drill real, real deep) to continuously overlooked bottlenecks in communication and in team interactions. A clever strategy would be to dig down to the root causes, find the repetitive lapses and fix them. As simple as it sounds, this would shape-shift your team from a fast-running careless hare to a wise tortoise that reaches the destination in good time … and in good health.
This story has been re-crafted from one of my earlier articles.
