Someone once asked me this question and I want to share some personal view on the topic. My experience shows that depending on who you ask, you may get different answer for the above question.
First off all Kanban is often recognized as software development metodology, that in contrary to Scrum removes iteration boundaries, introduces board with WIP limits and visible queues. Whenever there is a free capacity team is picking next most priority item from the backlog – this way we are achieving steady flow of tasks. Some iterative aspects borrowed from Scrum framework ( bi-weekly grooming or retrospective) are required when team is not mature enough to do them ad-hoc (retrospective) or just-in-time (grooming)
Another understanding of Kanban in software world is built by David Anderson’s book. The book actually describes Kanban Method – which is a meta-process that can be used to improve organization of work and drive evolutionary change. Kanban Method principles are saying to:
- start with what you do now,
- agree to pursue incremental and evolutionary change,
- initially respect current roles, responsibilities and job titles and
- encourage acts of leadership at all levels.
When all agree about the principles, it’s time to implement practices that can help us, like visualization, WIP limits, flow management, explicit policies, feedback loops and collaborative improvement by experiments. Practices without principles may lead to shallow implementation of Kanban Method.
Third understanding of Kanban (or Kanban System) treats it as a signal (set of signals) – similarly to how it was introduced by Toyota. This is my preferred way of understanding Kanban. It was designed to convey visual signals in the pull system so that it is explicitly visible to everyone that some work should be done. Visualized Kanban signals are creating Kanban System. Using this understanding we can safely say that every team having f.e. a wall with light that can be switched on and off is doing Kanban. Going further, every team having a board that visualizes work is implementing Kanban System. WIP limits here are not the starting point, they are side effects of properly managed pull system with Kanbans (signals) in it.
How to apply this traditional ‘Toyota’ understanding? My view is that before using Kanban signals (most often in the form of Kanban Board) we should focus on creating pull system and understand how variability, batch size, lead time and WIP limits are influencing our work. Kanban board can greatly help us in build that understanding. For me flow theory and theory of constraints must be foundations of any development process. I encourage all to start with that and later on introduce Kanban board to build proper and wide awareness what is happening in the ‘system’.
It is also crucial to agree to pursuit evolutionary change and continuously improve our development process – Kanban Method is designed to help with that and this is something I strongly encourage to try as well.
So what’s the conclusion? ‘Kanban’ word (like many others in software delivery) has been dressed in ambiguity and it’s good to be aware of that. At the end it’s just a name, traditionalists like me may prefer strict Toyota understanding, others interpret it differently. Meaning is not the key, being fanatic about it doesn’t help – what helps is mature understanding about our delivery process and ways how we can improve it.