Overcoming delays due to variability, complexity, bottlenecks and constraints.

It’s crunch time! Your deadline looms and the software is far from ready. You work overtime to rush through the most important functions (see "Taking the Crunch out of Crunch Time," Management Forum, Mar. 2000). You skimp on the testing, skip the quality assurance and somehow get it out the door. Then you resign yourself to customer complaints, frayed nerves and a never-ending cycle that always seems to have the same pattern: There is never enough time to do it right. Still, your customers keep wanting faster service and your competitors are offering to deliver it sooner than you think possible.

Shortening your cycle time would give you a competitive edge. Deliver before your competitors do, and they have to catch up while you work on the next release. The life expectancy of software products is typically short, so meeting tight schedules means your company profits more. Even if you have no competitor, the faster you develop software, the more business opportunities you can accept. Even if you have no market-driven need to do it faster, just having the ability to do so means you can start implementation later, so requirements will be firmer and there will be less time for them to change.

Causes

In a cycle-time improvement team I worked on a few years ago, we found that the causes of project delays are pretty much the same as the causes of traffic delays. In a long freeway commute, you encounter frayed nerves, plans that go awry because of unexpected delays and an infinite supply of "other guys" who seem to move into the lane just before you do. Experts on cycle time say it all boils down to three fundamental problems: variability, overly complex processes, and bottlenecks and constraints.

As my team implemented cycle-time improvements, we discovered that over half of the unnecessary delays were caused by innocuous things that we had not paid much attention to before, such as incompatible tools and data formats, overly complex approval processes and a failure to plan effectively. On one maintenance project, the typical customer complaint took three months to resolve. About 40 percent of that delay was traced to an arcane approval process that nobody had thought to question because it had been done that way for ages.

Some delays are simply a matter of wrong priorities. I once spoke with a team whose job was to prepare the shrink-wrap packages for a popular line of software products. The packaging process added two to three months to the cycle time for delivering the software. The team knew it could reduce this to under a month by starting much sooner. But the chief programming guru, who had to approve the artwork for the boxes, would not pay attention to such "trivial" graphic decisions until the code had passed all of its final tests. As a result, the CD-ROMs sat there for months, ready to ship, while the artists prepared the final packaging. This example illustrates both a fundamental problem and a fundamental principle. The problem is that the programming guru was focused only on his part of the process, not on the big picture. The principle is that you need to optimize the entire process. This often means being suboptimal for the individual steps of the process, which is a concept that many find hard to swallow.

Symptoms

Cycle-time problems are usually easy to spot, as, for example, when you see a backlog of work, such as software waiting to be tested. Such work is called WIP (work in process). Simple queuing theory shows that the more WIP you have, the longer your cycle time. A simple equation captures the gist of it: average cycle time = WIP / throughput.

To shorten cycle time, you must increase throughput and/or decrease WIP. However, it’s hard to increase throughput without increasing WIP, so the smart approach is to reduce the WIP. What causes excess WIP? The three culprits mentioned before: variability, complexity, and barriers or bottlenecks.

A more fundamental symptom of cycle-time problems is rework. The more you do things over, the more WIP you have, which means you add cost and introduce delays. Much rework comes from simple things: rushing (which causes more errors), miscommunication (which may result in doing the wrong thing) and inadequate training (which means you waste time learning and making mistakes on the job).

The Value Stream

You improve cycle time by attacking the three fundamental problems, but you must pick your battles. It helps to begin by defining the "value stream," that is, the sequence of things you do that really matter to the customer. A process called value-added analysis is a formal way to do this, but you can accomplish a lot by just thinking about what is really necessary and what is not. Examples of the necessary, value-stream tasks include designing the software, writing the code, integrating the components and preparing the help files. Many things you do are not in the value stream: debugging, rewriting bad modules, waiting for approvals, translating between incompatible tools and correcting misunderstandings. By focusing on the value stream, you open your mind to the things that really matter. Everything else is ripe for streamlining or removal. Once you make a list of the tasks that waste the most time and resources, reduce or eliminate them. Then make another list and repeat. Before long, you will be pleasantly surprised at how fast your projects go.

What about testing, reviewing and managing your projects? These are not technically in the value stream, but they are essential for getting the work done, so they are usually targets for streamlining rather than removal. Nevertheless, your customer would be just as happy if you could write perfect code with no management direction and no need for testing. Indeed, some day you may know how to do just that. After all, some Japanese cars have outstanding quality records even though they are not tested until they arrive at the dealer’s lot.

You should design your process to maximize efficiency of the value stream. That is what cycle-time improvement is really all about. In most cases, there are plenty of processes that don’t add value to target.

Every method of cycle-time improvement is a way to make the value stream as optimal as possible. It’s a lot like code optimization, so try thinking like a programmer. Imagine your program has one primary execution sequence that must proceed as fast as possible (the value stream). Think about how you might optimize the software to make that happen. You would design the input and output to minimize delays. You would make sure there are no empty input buffers or full output buffers. You would optimize the code in inner loops. You would match your hardware and software for maximum performance. You would evaluate your algorithms to see if there is a faster way. Every line of code you remove will speed things up, especially if you choose the ones in inner loops.

Now, stand back and imagine your software development process as a program. You are the processor and the value stream is the primary execution sequence. Where are the I/O bottlenecks? What are the repeated processes, the inner loops? Is there too much delay getting something approved or through configuration control? Is there a long wait for test resources? Do you wait and wait for requirements specifications or approvals? What steps of your process could benefit the most from better hardware? Are you taking too long to do a critical design step because the workstations are not up to the task? Is there too much paperwork to purchase needed development tools? Is your development process just too complicated? Every step you eliminate reduces variability and complexity and means fewer opportunities to introduce defects.

Measures

Sometimes the causes are clear, but you have trouble justifying the solutions. An important step is measurement. Do you know how much time you spend doing various software development tasks? Can you measure your cycle times? If not, this may be the best place to start. My team found that by measuring and quantifying, we could make things happen. For example, we convinced the company to change the approval cycle for new equipment because we were able to show how much money the delays of the former system were costing. Measurement has other benefits. When we started to record where we actually spent our time, we were sometimes surprised. For example, the programmers typically felt they should reach agreement on the best coding conventions, but we found that the time spent reaching the best solution was much longer than the savings. A "good enough" convention would have served (see "Habits of Productive Problem Solvers," Management Forum, Aug. 1999, for other ways to avoid wasting time).

Cycle-Time Principles

Sometimes the actions needed to reduce cycle time are counterintuitive. For example, consider the Cycles of Learning Principle, which says it is faster to do a job several times, in small increments, than to do it all at once. By attacking a job in small chunks, you make mistakes and learn from them on the early cycles but perform at top speed in later cycles, when the problems are usually more difficult. Most of us recognize this as true for software development: Iterative or incremental development is often the fastest approach, provided you learn to do better each time through (see "Throwaway Software," Management Forum, Oct. 1999).

The Small Batch Principle is also counterintuitive. It says economies of scale do not always work. Why? Because large-scale economies are only realized when the requirements do not change. In software development, requirements are changing all the time. Small batches reduce the amount thrown away or reworked when the rules are rewritten. Most of the time you are better off building small things and using a modular approach than trying to do everything in one large "waterfall" cycle.

The Smooth Flow Principle states that the optimal process is one where each step flows at the same speed, like boxcars in a train, rather than having each step go as fast as it can, like cars on a highway. Having everyone go as fast as possible does more harm than good because people end up getting in each other’s way. What does this mean for software development? It may mean you should analyze the flow through your development process, find the slowest points–the bottlenecks–and spend more of your time helping there, even if it means taking time away from design or coding tasks and helping out the people in test or configuration control.

Naïve cycle-time improvement efforts often start with the obvious approach of trying to shorten the longest step in the development process. However, rather than optimizing locally, you need to look at the whole process. Ironically, sometimes you get better results by lengthening a process step, even though this may not seem to make common sense at first. A classic example is taking longer to define requirements and to prepare an integration plan, so there will be fewer problems and much less rework later. One successful project defined the integration-and-test plan first and gave control over all interface changes to the integration-and-test team. This can dramatically cut integration problems.

Another cycle-time mistake is to cut out "overhead" activities, such as quality assurance and configuration control, because they seem to slow things down. If you look closely, you may find that these activities can, by cutting out rework, add more to the overall value stream than you might think. How can you tell? Measure and see.

Hares, Tortoises and Bureaucrats

Do you reward programmers who work late every night and wonder about those who leave early? This is a natural tendency. However, instead of looking at how busy developers are, maybe you ought to measure how productive they are, that is, how much value they produce. When you do, you may find that some of the busiest people are spinning their wheels a lot. Not always, of course, but we have discovered a number of cases where the real work was being cranked out by people we had once considered "too slow." Sometimes the tortoise really does beat the hare.

Overly complex processes and bottlenecks often result from precautionary measures that protect against unlikely or inexpensive problems. Each time a problem arises, the bureaucratic tendency is to create a new rule. One company eliminated the requirement for travel authorizations, saving millions each year–much more than the slightly increased cost of inappropriate travel. After all, how many employees will risk their jobs just to take an unjustified trip? Identifying and removing such obstacles is another aspect of cycle-time improvement.

You Can Do It

By attacking the root causes of cycle-time problems, you can improve your delivery schedules permanently. Dealing with causes instead of symptoms saves money and improves product quality. The techniques are not hard. Simply apply basic principles in a methodical fashion and be open to new ways of doing your work. The biggest problem is often selling your "counterintuitive" ideas, which is where measurement really counts. If you are not sure whether to try cycle-time improvement, remember that your competitors are constantly striving to be faster than you.