The value of Kanban

Kanban (capital-K, as in the method) uses a kanban (lowercase-k, as in the board) to visualise and reduce work in progress (WIP for short). This is the most well-known, and visible, part of Kanban. It is achieved by limiting how many pieces of WIP any one work centre can have assigned. At first glance, this may seem to be incompatible with IT support work. This is as erroneous as assuming Kanban is incompatible with knowledge work in general, whereas it has been proven to be an excellent match for software development (for details, I recommend David Anderson’s book “Kanban: Successful Evolutionary Change for Your Technology Business”).

I believe the source of this mistaken assumption is a misunderstanding of what Kanban achieves by reducing WIP. What it achieves is focus. By having a reduced number of tasks to contend with, greater focus may be applied to each. This will in turn ensure that each task is resolved more quickly, and with higher quality. While most literature I’ve found looks specifically at Kanban applied in software engineering environments, I believe that the lessons it has to tell are universal to knowledge work. My takeaways from looking at it are these:

• Identify and isolate your bottlenecks

• Reduce work in progress

• Create and foster a kaizen culture

The value of identifying and isolating bottlenecks is fairly self-explanatory to me – it lets your bottleneck direct the flow of work that needs to go through them, while allowing other work to be handled regardless of their (the bottleneck’s) capacity. Reducing work in progress is a little less intuitive. By changing from a push-system (assigning tasks to a work center as soon as it enters the queue) to a pull-system (assigning tasks to a work center as they get available capacity), it allows for better control of assigned tasks, more focus on those same tasks, and quicker resolution (as fewer tasks equals more time to assign to the tasks remaining).

The third point also bears looking into. Kaizen, Japanese for improvement, is commonly used in the sense of continuous improvement. The term came into common usage in industry with the advent of the Toyota Production System (TPS), an important antecedent of lean manufacturing. In IT service management, this same idea is exemplified in the continual service improvement (CSI) process of the ITIL lifecycle. The difference is that CSI is often a top-down process, managed by the service level manager, incident manager, problem manager and change manager, while the onus of kaizen lies on everyone.

As Anderson showed in his book, kaizen, like CSI, starts at the top; management makes changes, and – crucially – makes those changes (and the reason for them) transparent. This empowers their subordinates, granting them agency to suggest (and ideally enact) changes themselves. By embracing kaizen, the organisation will automatically be in compliance with CSI, and can reduce efforts on that part.