Attending Kanban Training
It started on a rainy August morning of 2016 in Mumbai. I was thrilled to be attending the Kanban Design Practitioner workshop and was eager to learn Kanban concepts that originated on the manufacturing floor of an automobile company. The concepts are now being relentlessly applied in Agile practices of Information Technology organizations across the world. I hoped to understand the concepts that made the Kanban approach so universally popular. The masterclass started by introducing what essentially is Kanban and the very important concepts around ‘Flow’ and ‘Visualization’. The concepts were deceptively simple and I was feeling very confident by mid-day about my knowledge of Kanban.
Experiences in a Kanban Board Game
What was to follow would make me revise this perception and appreciate the beauty of Kanban. This alteration was caused by a great Kanban board game that we were to play as part of the workshop.
The entire group was divided into 2 teams of 7 participants each. And we were asked to run an Information Technology project with the intention of maximizing the dollar revenue at the end of the game. The game would encapsulate 10 man days and cover a given number of user story cards to be processed. Each card upon reaching the ‘Production’ system would help our enterprise realize a given dollar value. Hence, the greater number of cards completed the higher the dollar earned value. To our team what seemed to be the simplest way to achieve this goal was to increase the ‘WIP’ limits in each of the lanes.
Increasing WIP does not increase Resource Availability
As per our collective opinion increasing WIP limits of lanes would automatically ensure that more cards enter the workflow and hence reach the completion state. We were up for a rude surprise. By increasing the WIP for each lane we started pulling in more cards than we could process. This was because of a basic glitch in our thinking and decision-making process. Increasing WIP did not translate into an increased resource availability. Soon we had a crowded board full of cards and our team’s energy was dissipated by the confusion for having the high number of permutations caused by the scenario. We were unable to move the cards in a continuous flow and our resources were getting eaten up between the different work items.
Limited WIP – the soul of a Pull-based system
Eventually at the end of the game we realized that the concept of WIP is to ensure that number of work items are limited. A high WIP is self-defeating and not in alignment with the concepts of Kanban. A pull-based system with a high-WIP limit is no different from a push-based system. This is because a high-WIP implies that there is capacity available in the lane (even when there isn’t any). Hence, the surrounding environment can pressurize the team into ‘pulling’ more work by citing the capacity available (a deception created by increasing the WIP without increasing the resources proportionately). The WIP limit has to be as less as possible to the extent that it should pinch. A thumb rule is that the WIP limit should be no more than 1 card per resource for any lane.
WIP 1
At the end of the game, our team collectively understood that keeping a low-WIP is supposed to be hard and requires moral courage. A low-WIP ensures the system becomes predictable and delivers output in a continuous flow. A low-WIP also provides flexibility and options in the system when something breaks down causing a bottleneck. The bottleneck is resolved by multiple resources collaborating and focusing on resolving the items causing a break in flow. The epiphany made us realize the beauty of a pull-based system like Kanban and how a low-WIP is the soul of such a system. That day made me an advocate of the adage that the best WIP is 1. However, there are other common practices recommended as well, based on the kind of Kanban system design and policies that help them ensure that all team members in a Kanban system are utilized optimally and flow is optimized as well.
WIP 1.5
Another common principle several thought-leaders advocate is a WIP limit of 1.5 per person in the team. This is to ensure that if something gets held up or blocked and the person working on that work-item is unable to successfully resolve the block, they should be able to go pick up something else to work on. Keeping a WIP limit of 1.5 per team member helps in doing this.
However, if your team policies say that a team member cannot take up something new while they are working on a blocked card, then perhaps the WIP limit of 1 would work fine.
WIP 2.0
During the last Lean Kanban India conference, in Sep 2016, the well-known thought-leader said that teams starting with Kanban initially should start with no WIP limits. Once the system achieved some stability, the WIP limit could be defined as twice the average observed WIP for the board.
I thought this was very practical advice for teams who grapple with this question – how to decide your WIP limits when you’ve very little to go on.
Conclusion
Whichever be your favored method of deciding your WIP limits, the important thing to keep in mind is that you need to have some WIP limits! You cannot have a situation where there are no WIP limits or very high WIP limits. WIP limits serve as the channel or constraints between which the wworkflows Without those constraints, there will be no flow.
If you have any other suggestions, please let me know.
Anshuman Singh
Product Manager, Digité, Inc.
