(luKa)

When the basic concepts and practices of Kanban are in place in the team, it is time to look at the whole picture.


A general principle
WIP limit is a tool to adapt the work commitments to the current whole system bottlenecks/capacity and an help to achieve continuous flow and implement a pull-system.

WIP limit, continuous flow, whole system value stream mapping, a pull-system , transparency and visualization and frequent inspections are prerequisites in the sense that they are the means to achieve the goal of:


The main WIP to limit
All the work done prior to the production use of the system when the system start to generate business value, and all the work done from concept but before cash, or the work done from the customer request until the features go in production, all this  *is* Work In Progress.  
This is probably the most important WIP to limit. Are you limiting also this WIP?



WIP Limit: optimize the whole with continuous improvement
While the Lean principle say Optimize the Whole, an evolutionary improvement of the system with Kanban, Agile, Lean or Lean-Agile must start somewhere and people too needs training and to make practical experience. So a software development team and the IT department are common places to start with.

The local optimization of a dev team or the IT dept can sometime lead to global worsening. This can happen for example when the resources/focus/energies used for the dev team/IT dept improvement are subtracted from the people/team/dept that is a current bottleneck of the system. Or it can happen that the improvement achieved in the dev team/IT dept increase the pressure on another team/department that already is a current bottleneck of the system and this make things worse. This is why the Lean principle Optimize the Whole require to look at the whole system.

What is important to avoid with an evolutionary approach, is making the local optimization with global worsening as a permanent unsatisfactory point of arrival.
Sometime things go worse before improving, this can happen with a local optimization that can be a stepping-stones to the success when it is used to build the capacity to look at and understand and begin to improve the whole value stream and so adhere to the Lean principle Optimize the Whole.

This is where continuous improvement come in handy: it can make the difference between a Kanban-but or Scrum-but unsatisfactory adoption and a successful Lean-Agile one.



WIP Limit: how and where
Once the team become aware that is not an island but instead is part of the whole system, the WIP Limits and the columns on the board start to make much more sense.

Which columns on the board
The work of the team is connected to the work of other teams, suppliers, customers and external resources. And this should be reflected in the Kanban board of the team. 

Beside the columns "To do", "In progress" and "Done" in the Kanban board there should be a column for each interaction/cooperation with an external team/supplier/customer/user that is needed to get the team's work done.
 
How to set the WIP Limit
The cooperation needed from external teams/suppliers/customers is the place where potentially there could be bottlenecks.
For example the external teams/suppliers/customers can have a limited capacity to fulfill the requests and need also to be informed some time in advance before they can fulfill the requests. The column on the board for that supplier is where the team signal in advance the tasks that need help from the supplier and the WIP Limit  and its unit of measurement are determined by the capacity of the Supplier.

One effective flow
The requests for the external team/supplier/customer that pile up in the the board column turn into tasks that go into the external team/supplier/customer board in the "To do" column. Those requests are one of the sources of the pull-system of the external team/supplier/customer. 
A way to describe this is to say that the flow is made of many distinct interconnected interdependent Kanban.
An evolutionary approach to improvement consist into

• reducing, when and where possible, the number of distinct Kanban merging them together by merging teams, tearing down artificial walls/barriers/silos
• growing the capacity of each distinct Kanban and it's ability to fulfill the requests Just-In-Time
• adapt the work commitments to the current capacity and bottlenecks of the whole system/work flow

A final word: WIP Limit is about People
All things discussed here begin with people and continue with people. The evolutionary improvement consist in building the awareness and ability and expertise in the people and their cooperation and coordination and in their ability to collectively make sense of things, generate meaning and build consensus.

Not in Lean nor in Agile there are predefined processes, every process in empirical and is determined by the people that enact it constantly adapting to each specific context and situation and reacting to each event.

Eiji Toyoda said: