I attended a Kanban workshop in Frankfurt, Germany in the fall of 2018. It was early in the morning, the conference room located in one of the hotel high-rises was not yet oxygen-deprived, coffee had been excellent and the group appeared lively. We were ready and eager to absorb Kanban knowledge.
It was within the first hour that the referent Klaus Leopold moved to the subject of WIP limits that is so central to Kanban. I expected the usual definition of WIP as „Work in Progress“. But Klaus pointed out that in his opinion WIP should rather stand for „Work in Process“ since we should not only count those work items that are actively progressing. At the time, it came across like an innocent remark – a very fine, subtle point. But it stuck with me and it got me thinking.
Is there more to the difference?
Somehow, the remark had set a filter in my perception. In the days to follow the workshop, whenever I looked at my team’s Kanban board, I would see active and passive cards (blocked or in the buffer columns) as if painted in two different colors.
Interestingly enough, the passive cards were driving the process, the discussions and the improvements we identified. Actually, this should not come as a surprise. In work systems without WIP limits, there is usually a high percentage of work items that are not active. This is exactly the waste (Japanese: muda) that Taichi Ohno, the inventor of the Toyota Production System (TPS) noticed on the factory floors. In WIP-limited work systems, a high number of tickets in a buffer column will finally challenge the WIP limit and signal a bottleneck in the work station following the buffer column. Yet, the extent to which active cards were really almost irrelevant to the team discussions was startling.
Manage the work not the workers
This difference in perception, is one of the great strengths of Kanban. In Kanban you look at the waste: the passive tickets, the work nobody works on. In the Kanban thought system, improvements come about by reducing the waste.
Contrast this with the standard (default) format of the Daily Scrum. Every Scrum developer takes turns and reports whatever she has worked on yesterday, what she intends to work on today and whether there are any impediments. This view is worker-centric and not work-centric. It aims at improving individual efficiency. The underlying misconception in my eyes is that many efficient workers make for an efficient overall process.
A system is never the sum of its parts it is the product of their interaction.
Russel Ackoff
In Kanban, we manage the work and not the workers in an attempt to improve system efficiency. In a later blog, I will showcase improvements in a 20-person software development team using this particular Kanban view.
