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…
What a great post! Thank you!
I’d add one observation about dependencies. People sometimes ask me about dependencies (and they use this word), when they really mean dependent tasks (one must precede the other) that are different activities in the delivery workflow. These people are at the beginning and struggle with the transition from local tasks to longer value streams. Once they get that, their concern about “dependencies” diminishes.
Hi, I’ve just come across your blog after reading one of your SlideShare presentations – so apologies if this is already addressed elsewhere…
One the question:
> Q: Is Kanban just for ongoing maintenance or also complex product development?
How do you define complex product development? I understand this to mean development where the end state is not known, the work iterates through solutions until it matches closely enough to the business needs in order to be of use.
I think of this as when creating a new cookery recipe – tasting a dish to see if you are on track for a good final result or not. Would this work well in Kanban? Or would the work simply cycle back numerous times between two states until it could complete the Kanban workflow?
I can live with your definition of complex product development.
And yes, kanban works quite well with that in my experience. As long as what you try to visualize and manage with kanban is the flow of “experiments”/”iterations”/”probes” (choose your favorite lean/complex adaptive system language…) from idea all the way to validation. In this case you use Kanban to help you focus on disciplined exploration and learning – accelerating the “think build measure learn” loop using all the goodies of Kanban.
Some in the kanban world call this “Discovery Kanban” I think… or in general talk about Kanban in the context of “Knowledge Discovery”.
Thanks for the response. The “Discovery Kanban” that you describe makes a lot of sense and I can see how that fits in to a Kanban work-flow. This helps resolve one of the main blockers/concerns, on a project I’m scrum master/coaching, move from scrum to Kanban. Since Kanban is a better “fit/match” for the type of projects that this team works on.
Thanks again, it was very helpful advice.