Kanban is a poorly understood concept, and as it happens with poorly understood concepts, myths and misconceptions flourish. Agile community has developed many such myths around Kanban which I will assume are purely out of ignorance – that is, there is a no personal purpose behind it. 🙂
Let’s take a quick look at some of the most common myths around Kanban:
"Kanban is just a Visual Board to track your work!"
In other words, if a waterfall team starts using a visual board to track their work, they are basically using Kanban.
The meaning of the word ‘kanban’ (in Japanese and Chinese) can be roughly equated to visualization. Then, there is a term ‘Kanban System’ – a concept developed at Toyota Production System to help them manage the flow of work, a significant step towards Just-in-time (JIT) manufacturing.
Among the Kanban practitioners, the term Kanban generally refers to ‘Kanban Method’ – a management method that provides process structure to help you implement a Kanban System for knowledge work, as against manufacturing. Some of the key concepts used in Kanban Method are WIP Limits, Replenishment meeting, Input Queue, Daily Kanban, Class of Service, Work Item Type, Throughput, Lead Times and Cumulative Flow Diagram.
You may want to review this blog to understand different Kanban terms… http://www.izenbridge.com/blog/kanban-card-board-system-method/
"Kanban in good only for Support Projects"
This is probably the most prevalent myth about Kanban. The reality is – only Kanban (not Scrum) will work for support projects, but that does not mean Kanban will not work for development projects.
"Kanban is Scrum without Iterations"
I reckon people who say this are limiting their Kanban definition to Kanban board only. They have no clue about Kanban System or Kanban Method. While there are no iterations in Kanban, that is not the essence of Kanban Method. It helps you implement smooth flow of work without over-stressing the team.
"Start with Scrum, move to Kanban"
I would actually say the opposite – start with Kanban, move to Scrumban, and six months later let the team decide if they wish to transition to pure Scrum.
My reasons – Kanban is an evidence-based evolutionary change while Scrum is a big bang change. There are good chances the productivity of your new Scrum team will go down in the short-term. In fact, you should not attempt Scrum if your management does not have the tolerance for the initial investment phase. Please explore “J Curve Effect” section in this blog… http://services.leankanban.com/organizational-maturity-j-curve-effect
"You either use Scrum or you use Kanban"
While a team may adopt either one successfully, there are numerous examples where a team combined the two to their benefit. You guessed it right… it is called ‘Scrumban’. Please explore my previous blog if you need more details on the idea of ‘Scrumban’.
"Kanban is too complex to adopt"
Any change is tough! That being said, Kanban Method provides an incremental and evolutionary change process that lets you to take on only as much change as you are ready for. In other words, it is much easier and more economical than a ‘Big Bang’ change approach.
"You can't do release planning with Kanban"
Well, the essence of release planning is matching demand with capability within a given time constraint. Since we don’t have team velocity in Kanban (no sprints), you can use throughput (finished work items per week) for your release planning.
"There is no place for Review and Retrospective in Kanban"
No sprints mean no ‘Sprint Review’ and no ‘Sprint Retrospective’. Right, but we can always call them ‘Product Demo’ and ‘Retrospective’ or ‘Process Review’. And, you can do them as often as it serves you right – ‘Product demo’ every other week and ‘Retrospective’ once every month.
"You don't estimate your work in Kanban"
You may or may not – it entirely depends on you. The teams that don’t estimate work in Kanban usually break the requirements into small comparable units so each item can considered almost equal. But, you can also use story point estimates in Kanban if you like it.
Thanks for taking time to read my thoughts. If there is a prevalent Kanban myth you feel I have missed, request you to share in the comments section below. Cheers!
