Kanban System Design


Work In Process
Work in process (WIP), and the way it is limited, is the means by which we can create a pull system which balances capacity and demand through a value network.

In a pull system, work is processed through being signalled, rather than being scheduled. This is what avoids a build-up of inventory and enables work to flow through the system as capacity allows. Kuroiwa-san, an ex-Toyota manager, used the analogy of a chain of paperclips in a talk at Agile Japan in 2009. Pushing the paperclips will inevitably cause them to pile up, whereas pulling them will result in them moving smoothly.

Applying this to a software development workflow means that upstream work can be made available, but it is the team members’ responsibility to decide when they are able to take it. The act of taking, or pulling, the work, is a signal for the more upstream work to be processed. However, when work is available but not being pulled, then production upstream will gradually throttle down to avoid any pile-up. With a push system on the other hand, work will be scheduled and handed downstream regardless of whether there is capacity to process it or not.

WIP has an impact on productivity, inventory, and teamwork, and by being aware of WIP, and reducing and limiting it, we can improve a kanban system.

Productivity can be measured in terms of cycle-time and throughput of valuable units of work. Cycle time is the length of time to complete a process and throughput is the amount of output from a process in a given period of time. Cycle time and throughput are both improved by decreasing WIP. A simple example of this effect is CPU load, where application performance goes down as CPU load increases. The effect can be explained by looking at Little’s Law for Queuing Theory:

Cycle Time = Number of Things in Process / Average Completion Rate

Little’s Law tells us that to improve cycle time, there are two options: reduce the number of things in process or improve the average completion rate. Of the two, reducing the number of things in process is the easier, and once that is under control, then the more challenging changes to improve completion rate can be applied.

A further understanding can come from Traffic Flow Theory:

Flow = Speed * Density

Traffic jams occur as traffic density increases and traffic speed decreases. However, when traffic density decreases, speed only increases to a point (which should be the speed limit). As a result, there is a point at which decreasing WIP below a certain density will reduce throughput.

Another factor in improving cycle time and throughput is that of multitasking. Reducing multitasking is beneficial for two primary reasons. Time is lost to context switching per task, so fewer tasks means less time lost. Gerald Weinberg, in his book Quality Software Management: Systems Thinking [7] suggests that 20 percent of time is lost per additional task. Thus one task can consume 100 percent of time available, two tasks will consume 40 percent of time available each with 20 percent lost to context switching, three tasks will consume 20 percent of time available each with 40 percent lost to context switching, etc.

Performing tasks sequentially yields results sooner.

Dr. Eliyahu Goldratt introduced the idea of throughput accounting in his business novel The Goal [8]. Throughput accounting suggests that the business goal is to make a profit, and that this is determined by work in process, operating expense, and throughput. Profit is increased by decreasing work in process, decreasing operating expense, and increasing throughput.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!