Problems with Kanban?
Having observed Kanban implementations over the last decade, there rises a question of why do so many of us fail at making it work? I’ve tried to find the most common reasons for Kanban failure. Take a look and see what you think?
“It’s only for linear processes”
A belief, that because Kanban was originally used to manage one-line processes, this is how it is meant to stay, whereas you can and should foresee and inject any additional steps into the process and really visualize it, to truly benefit from seeing where it is that the project gets stuck the most and what can be done to improve it. People still associate Kanban with car making, which indeed follows a one direction process, but the fact that this is the way it’s always being depicted does not actually set that take on Kanban in stone. Kanban — as a change management method, which it is — is meant to be used as a way of looking at the process, not taken as
a prescribed, strict method.
“Kanban is a ready-made way to work”
Constantly comparing Kanban to Scrum, XP, Waterfall and other management methods — again, coming from a perspective, that Kanban is a way of bringing in change, these comparisons are pointless. There’s no real goal, nor value in bringing together an evolutionary change management method and a task management process to try to weigh in which is more valuable. Kanban on its own, without any customization and thorough process analysis, for complex projects — like software development — is likely to not be quite enough, as it brings no strict rules nor practices to the table.
It’s a tool for managing a change, demanding that you find the right way to do things yourself, it’s not a ready to use system, it requires building on it by the team in question. Whether it’ll be another system within the Kanban, or just a set of good practices for the team to follow, you need to get involved a little more. The point is constant improvement and evolution.
“My team cannot do Kanban”
An often observed problem with Kanban implementation are issues caused by the people. But hang on, this can be applied to absolutely everything that involves people. People doing Scrum, not doing anything, selling bread — these are all situations, in which the people involved will cause and experience problems. Is this is really a Kanban issue then? No.
However, there are some great tips for the people doing Kanban, which can decrease the probability of creating difficulties associated with the board. They are:
- Keeping the board up to date — if the team is doing one thing and the board is showing something completely different, you know that things will go wrong. Make sure that the board reflects the work
- Making the board represent the real process that is being followed, not one that the team aspire to have
- Sticking to the set WIP limits — there will be times, when breaking them may be allowed and possibly beneficial, but making this a common practice equals giving up on Kanban altogether. They’re there to improve the flow, not to be fought.
If there’s one thing that could be taken from this, it’s not to treat Kanban as a self-implementing magical tool. It will work fine, provided that you take it seriously and spend time on making it as closely follow what you really are doing (including all the waiting, recycling and rethinking type columns) and keep coming back to it to see which steps aren’t needed, what should be added and what overall improvements need to happen to make the process better.
First published on the Kanban Tool Blog.