Reducing Cycle Time

An increasing number of organizations are moving towards radical reductions in cycle time as they move towards rapid business responsiveness and Continuous Delivery. (I’m trying to reduce my personal cycle time, but that’s another issue.)

One mantra that seems to help teams and organizations in this quest is, “If it’s hard to do, do it more often!” Keep this mantra in mind. If something appears too hard, or too costly, or too slow—figure out a way to do it more often. I once worked with a company whose product took six months of Q/A prior to release. The Q/A manager couldn’t imagine how to reduce the time to two-week iterations, so I asked him if he could figure out how to do it every two months. After several subsequent iterations, his group was able to support two-week iterations. From lean manufacturing examples, we often see that 80% or more of the time taken to accomplish a process usually works out to be wait time, not work time, so pushing for significant reductions is often much easier than anticipated at first.

In trying to answer the question “How can we do something frequently?” the answer may come from a combination of simplification, eliminating constraints, and automation. Every time we push to do something more often, be it a software build and integration or design, we learn. Learning comes from repetition.

From Goldratt’s theory of constraints we have learned to look for process bottlenecks. The bottleneck could be the lack of a particular skill or the throughput of a machine or a computer, but the key aspect of a bottleneck is that eliminating it can create significant improvements in overall throughput and cycle time reduction. Conversely, if we don’t think about bottlenecks, we can add significant resources without impacting throughput at all.

Teams should always ask the question, “How could we simplify this process or activity?” Or, the question may be more like, “What can we eliminate or streamline in order to reduce the time to do this from 6 weeks to 1?” Again, the time to accomplish some overall process can often be traced to delays between groups and excessive control processes or steps. For example, if there is a sequential process that takes eight weeks and involves four groups, each group may have a logging, prioritization, and reviewing process for work items. Reducing the process to a week by eliminating communication delays may also eliminate the need for these control processes.

Since we are in the business of IT, automation always comes to mind as an enabler to doing things more often, but we shouldn’t jump to automation until some of these other ideas have been tried.

The mantra “If it’s hard to do, do it more often!” espouses the agile value of responding to change. In today’s high-change world responsiveness to change is tied to the cost of change—reducing its cost increases our responsiveness. The high cost of some change should not be viewed as a barrier to responsiveness, but as an opportunity to increase our responsiveness by overcoming that barrier.

This post is from Adaptive Imagineering by Jim Highsmith. Click here to see the original post in full.