Archive for February, 2013

Importance of pull, WIP limits and Kanban system

February 20, 2013 Leave a comment

When improving a performance of a system (for example SW development department), people often try to improve the system itself by doing process improvement, organizational changes or removing waste. Such initiatives look at the system detached from its environment and from customer demand.

This inside-out approach will not create significant impact. Changes are not sustainable or the system returns to un-optimal state whenever the environment changes. Fixing the system from inside-out is like taking aspirin for headache: helps for a short while but won’t take away the reason for pain.

More important is to look at the system outside-in, together with its environment and create balance between demand and capability.

A scale is a common illustration of this. Most organizations act on the righthand side of the scale and ignore the left.


The organization operates at its optimal when demand and capability are balanced. For example, a simple system of supermarket checkout register: if there are more customers (demand) than cashier can handle, it creates a queue. This case is easy to solve by adding a new cashier, i.e. increasing capacity.

In software and service development the imbalance creates non-value-adding work (sometimes called waste). Have you ever been in a prioritization meeting? Or tried to work with several tasks in parallel? Waited for your colleagues to finish their part of the job? Filled in status reports for management? Been asked to work overtime? All of these are signs of overload. They are not only unpleasant — they significantly decrease the throughput of an organization: dealing with overload (imbalance) is failure demand: work that does not add any value and is created by the system itself because original work could not be done as promised.

Demand and capability are all the time fluctuating. Therefore balancing must happen when the work enters the system, not before and not speculating. Working in projects hides the real demand (as well as the real capability). Projects make assumptions about work and this makes it virtually impossible to take any balancing actions once the work is put into a project.

In order to reach the balance, the system must be a pull system. In a pull system the downstream work takes (pulls) work from upstream only when downstream has capability to proceed with new work.

Push systems ignore the capability of next step. In out supermarket example, push system would be customers piling up their groceries on the belt. That would block the flow totally.

Pull system requires that work stages have limits for work-in-progress (WIP-limits). Unless the work is limited, there is no mechanism to enable pull and the system turns into a push system.

A pull system creates flow of work that is optimal for the current system. Once flow is established, it helps to estimate completion of work. Such system is more predictable and has less unwanted variation (caused by failure demand). Having a stable flow also helps to improve the system (right side of the scale): once the work becomes more predictable, the impacts of changes are clear.


Click to enlarge

Kanban system is not only blue tape and yellow PostIts. It is more than just visualizing workflow or measuring cycle times. Kanban creates a pull system that balances demand with capability. In addition, Kanban allows to study the real workflow and improve gradually.

To put it short: WIP limits create Pull and this balances demand with capability. Such system operates at its optimal and provides predictability.