Make Kanban Work – Limit WIP Don’t get stuck on Visualization.

Kanban Method as advocated by David Anderson lists the first foundational principle as “Start with what you do now” and the first core practice as “Visualize”. This essentially means all you need kick-start Kanban is to set up a Kanban board for your process – the way it works now. And then you gradually improve, one step at a time.

People love this evolutionary approach to improvement and change management. Sounds so reasonable isn’t it? All you need to do is start without rocking the boat too much and continue to inspect and adapt – gradually improving. The setup part is great. Teams easily transition to visual boards that might be physical or electronic. The setup process and the visualization itself bring benefits. The entire process of setting up the board involves a deep dive in your process, analyzing your work types and understanding your policies and definitions of done. This is so liberating for many teams and they love it – especially for those who have not had a hard and detail look at their processes for a long time. It increases their productivity and levels of performance. They think Kanban is great and they have got it. They have arrived and then…. they Stop.

Many teams stop here at visualization , when in fact the exciting journey into the world of flow has just begun. What they have done so far is just to lay the foundation and prepare themselves. However they find it hard to move beyond.

There are reasons why teams stop (or as some would say, a long pause) at this stage. First and foremost, the levels of motivation required beyond this stage are higher compared to the setup phase. The challenge is typical of teams that have been “motivated” to do Kanban – which is not uncommon in an “enterprise” environment. However the pattern is seen in teams that are self motivated too.

Limit WIP and the Manage the flow are the next steps on the journey. You need to limit the WIP to get a handle on the system and manage the flow effectively. However they are not trivial to implement. Though it seems obvious that doing less items at a time would increase your throughput, practical implementation of it in a complex noisy business process is not trivial.

In my observation, the struggle is mainly on three fronts:

They struggle to reduce batch size
You can have flow when items are moving faster through your process. However moving from a traditional management style which is typically optimized for economies of scale to work with  large batches, change to  a smaller batch size is difficult. Yes, from a shorter term perspective, the way you are structured currently and the ways things work in your ecosystem, at this given point, maybe large batches are more economical. However if you really want to bring real change and enjoy the benefits of flow, you need to reduce the batch size. This is unavoidable. Large batches are unsustainable when you are working with flow.

They struggle to come out of fixed date commitments
Working with a project plan or some type of fixed date commitment is the traditional way projects are managed. Nothing fundamentally wrong with it. However in many cases, the level of detail at which the fixed date commitments are done turns the system into a “Date has arrived. Start this task” regardless of state of the system and the bottlenecks. A flow based system on the contrary requires that you focus on your bottlenecks and imbibe the philosophy of “Stop Starting Stop Finishing”. The challenge of breaking to small batches further compounds this problem.

They struggle to optimize flow over optimizing resources
Optimizing resources is what we have been doing for a long time. Most people are aware that the a deterministic approach to planning does not hold for long because of the variations and inter dependencies between tasks. Still we try to plan at a detail level as if we can predict the future, optimizing and leveling the resources. The reality soon hits us in execution when we actually end up trying to optimize the flow (remember the war rooms). However starting with that approach is not so easy for most as it’s so hard to see resources not fully utilized to their capacity.

They struggle to do smaller incremental improvements
Now everyone likes to improve. Theoretically. In the most practical sense, improving continuously requires discipline. It takes effort to do those retrospectives time and again. The discipline of retrospectives is more easy to miss when you have a couple of not so fruitful retrospectives. Facilitating and make retrospectives to work for you is both an art and a science. Most time people end up cribbing about stuff they have no control to influence and/or set objectives that are lofty and seemingly impossible to achieve. When in fact what is needed is the small improvement that they can make happen without needing any external stimulus. There’s a lot of such opportunities always, just that they are never glamorous enough.

Most people are stuck because they want to solve these problems before they can start Limiting WIP. In fact it would work the other way round. Limiting WIP would bring the right constraints in your system that will help you to solve those problems.

Yes it would require engagement to understand your system and setting decent thresholds for WIP at the start. It also requires commitment to shift to this mode of working and not do WIP exceptions in all cases. This can be done gradually. You need to experiment with WIP Limits. Just introduce enough constraints to cause some pain yet not impact the deliveries severely. Without any pain, there is no impetus to improve. Yet we don’t want so much pain that it kills the initiative.

Visualization using Kanban boards is mapping your system. Limiting WIP is what will get you to improving your system.

Make Kanban work for you. Limit WIP. Don’t get stuck at visualization. Move On.