Addressing some myths and misconceptions people have when considering Kanban

I frequently get contacted by people who like Kanban in general but are worried that it might not be a good fit for their context. In some cases the concern is legit but in many others it is just a result of basic misunderstanding of Kanban. We need to figure out why this happens so often but in the meantime here is a short FAQ:

Q: Is Kanban just for ongoing maintenance or also complex product development?

A: Short answer - No. Kanban is applicable in complex product development as well as most other knowledge work contexts. Longer answer - This myth/misconception is based both on the roots of kanban in the IT world as well as the fact that early on kanban was quite popular in teams that did ongoing maintenance/support where scrum sprint-based planning wasn’t a good fit. It was so popular that a lot of people made the association that kanban should be limited to this use case. (Scrum people who tried to protect their turf didn’t mind so much and probably helped this misconception propagate). As a coach actually most of the teams/organizations I work with use Kanban for complex enterprise-level product development involving SW and sometimes even embedded/HW development.

Q: We heard estimates are not used in Kanban? How is it possible to plan and predict then? (also asked as “We heard it is forbidden to estimate in Kanban?”)

A: Short answer - you can use estimates with Kanban and many teams do that.

Longer answer - Actually Kanban says to start with what you’re currently doing and evolve over time so many teams/organizations continue with their legacy estimation approaches initially. The source of this legitimate question is the understanding in the kanban community that estimates only reflect the work part of the overall delivery time and don’t take into account the delay/queuing time which we learned has a major impact on the overall delivery time. When using SLA-based predictability approaches therefore an accurate effort estimate is not that useful. It is sufficient to ensure the work going into the system is granular. the exact size is not that important.

Having said that, Many kanban teams/programs use  a more classic bigger-batch planning approach like “Agile Release Planning” and in those cases some sort of estimate is useful in order to have a prediction of the Time/Scope/Capacity required to deliver the Release/Project. These teams typically use classic agile estimation approaches like Story Points, Ideal Days etc.

Q: How do we deal with dependencies in Kanban?

A: The answer is not Kanban-specific but more of a “Feature Driven Development” question. The answer is that when moving to a Feature-driven-development approach using good independent stories/features most dependencies go into the specific cards themselves. The remaining dependencies are typically “This story must be finished before that one” and reflecting those cases in the priority order can be enough. Some teams block cards that are dependent to give better visibility to the situation. And some tools even provide a dependency mapping capability. I have to admit though that while I hear this question often from people coming over from the waterfall task-based gantt-based world, once they go into feature-driven/story-driven world most of them just understand they don’t need anything special.

Q: Are same sized stories really a must in Kanban?

A: Short answer: NO.

Longer answer: Kanban actually lives quite well with variable-sized work items. Most teams I worked with have not reached the nirvana where their stories are the same size and even those teams that have are working on features that vary in size. Kanban cares more about making sure the work is granular so it can flow effectively than having same-sized work items. The main advantage of same-sized work items is that it simplifies prediction, analytics etc. But most tools and teams deal fine with variability in the work size by taking size into account when making their prediction (e.g. in their CFD) or their analytics (e.g. in a size-based cycle time control chart)

I hope this helps…

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.