A brief visual management tactic born out of Kanban: Limited Work In Progress.
Our teams have been limiting their work in progress for a good while now to great benefit. To visualise these limits we place physical Work In Progress (WIP) limits on our team board:
You can limit work in progress for the whole workflow, or for individual workflow steps or groups of steps. We also call the limit out at the top of each stage in the workflow, as so:
These limits are difficult to violate without someone noticing: “Use visual control so no problems are hidden”. Take a look at the following board. Someone is clearly being nefarious here:
Swimlanes
We’ve tended away from setting these limits in stone; prefering to treat them as a point for discussion and root cause analysis of why a limit is being broken.
It’s worth noting that we don’t use swimlanes for limits. As each of our work items go through the same process there is no need for swimlanes: it’s worth noting not to conflate the two. Swimlanes in Kanban had some interesting coverage at Lean Kanban Benelux 2011, with John Seddon raising the opinion that swimlanes hurt capacity. Whilst this may be true, there is value in them, which we’ll cover in a future Visual Management series.
Determining an initial Limit
Our approach is simple: keep it simple. Have the smallest possible number of workflow steps (columns) and iterate from an initial Work in Progress limit, say: (N / 2) + 1 where N is the number of team members.
You can find out more about limiting Work In Progress in Kanban from David Anderson.
As a simple visual technique to trigger these discussions “hard WIP limits” on your board may just work for you. How do you visualise your WIP limits? Let us know @14principles.
Photo: Creative commons, Michael Lokner
