... and vice versa. You might be familiar with the maxim that speed is a by-product of .. something. In software development. We would sell our souls to get hold of a magic recipe that would guarantee fast delivery times. The paradox is that the faster we want to get sh... done, the slower it seems to move. Why is it like that?
Let's compare software development flow with a car on a highway, for the sake of easier understanding. What is needed for the trip to take as little time is possible? A good highway (as opposed to a sloppy mountain road), clear signs on the way, no traffic jams. You need to rely on the car, as it's the primary tool that gets you going. That is, you need to take care of the technical maintenance in advance. In general, as a thoughtful driver you would want to bring the probability of unexpected emergencies to a minimum.
What would happen to a single-minded driver who only wants to get fast to the final point of his destination, but whose car has a leak in a tire, or a low battery, or no fuel, and there are no gas stations on the way? What if the road is steep and rugged? Such a driver would face huge delays. It could take him twice as more to get to the destination, and then he would rub the back of his head saying: "Hmm, I needed to get there fast, and I ended up being so awful late".
The metaphor with driving by car gives a perfect explanation to the reasons for delays in releases. The very act of driving is the actual work, such as writing code or designing an interface. If a person who is doing the actual work is distracted by side factors, it takes more time and effort to continue driving. Re-work, poor balance of tasks and incoherent interactions slow us 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 auto-pilot as soon as an agile process is in place in your company. No. The process has to allow a wise fix-and-go, to maximize the time spent on actual driving in the right direction, with no detours. It does take some hard thinking and the ability to follow through if we want to bring the unexpected interactions to zero, making sure that most of the time is spent on the actual work.
What is slowing your organization down? Which bottlenecks recur? Can you identify them? How do they slow you down? Can you re-arrange the development process to dissipate the bottlenecks? As per my observations, 99% of unexpected emergency work and distractions boil down to continuously overlooked bottlenecks in communication and interactions. A wise 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 organization from a fast-running careless hare to a wise tortoise that reaches the destination just in time.