Why switching to Kanban won’t solve your problems

In the past I observed more than one Scrum team, that moved to Kanban. The reasons for that were manifold, but seldom the right ones. Here is a short list:

  • “All these Scrum meetings take too much of our time.”
  • “This Scrum thingy doesn’t really work for us, let’s try Kanban.”
  • “In Kanban you only need a board with the columns ToDo, Doing, Done and you can start. Isn’t that awesome?”
  • “These bi-weekly retrospectives are annoying. I like our process as it is.”
  • “We are not able to deliver a potentially shippable product at the end of our Sprint. In Kanban there is no such rule…”
  • “We have to adapt our planning continuously; this is not needed in Kanban.”
  • etc…

None of the above mentioned cases is a good reason to switch to Kanban, especially if you want to take it seriously. If a team moves to Kanban because of one of them, they are doing nothing else than running away from their problems. Many of the principles behind Scrum and Kanban are similar, which means, that the problems won’t vanish. The opposite is the case.

Both methods are based on the “principle of the bad mother in law”: They always remind you, to take a good look at yourself and point to your deficiencies. They won’t solve your problems, but make them visible. It is up to the team to take care of the problems and get rid of them, no matter which method you are using. It doesn’t make sense to switch to the next fancy method, if you’re not able to fix you stuff.

Both methods have a strong focus to deliver as often as possible. In Kanban this focus is even stronger than in Scrum, as there are no iterations and you can deliver 10 times a day, if you are able to. And this is exactly the part, where most of the software teams struggle. So again: Switching to Kanban won’t help.

Both methods demand an attention on a continuous improvement process. One of the biggest mistakes made in Kanban is to just put some board (you found on the internet) on the wall, which doesn’t represent your current process at all. And even if it represents your current process, nobody cares to adapt and improve it, even if this is one of the core elements of Kanban.

As you can see: Switching to Kanban is not easy either. There are a lot of cases where switching to Kanban makes perfectly sense. But you always have to be aware, that you take your problems and challenges with you and Kanban won’t solve them for you. If you take this into account, before you switch, you are already on the right track to a successful Kanban implementation.

What experiences did you make when switching to Kanban? Please leave a comment.

marc

Click Here to Leave a Comment Below
Kurt - 9. November 2015 Reply

I can’t really see how „switching to Kanban“ even makes sense. You start with Scrum, add Kanban to evolve from there to something, but I can’t really see how someone can switch from Scrum to Kanban. What would the underlying process be? If it is Scrum, then you aren’t really switching away from Scrum. If it is something else, then you are a) not doing Kanban (which requires you to start where you are) and b) it is the „something else“ you are switching to, not Kanban.

I would suggest rewording this post. Change „switching to Kanban“ with „applying Kanban to your Scrum process“ or something, otherwise it just looks like you don’t know anything about Kanban and it will confuse the reader.

    marc - 9. November 2015 Reply

    I totally agree, that the title may be misleading for people who understand Kanban. But unfortunately, most people don’t get that they have to start from where they are. They just put up a new board, define some columns and WIP limits and call it Kanban. I’ll keep the title of this blog post as it is, as I want to reach exactly this group of people.

Ville-Pekka Vahteala - 24. März 2017 Reply

In our case it was exactly the thing that solved problems.
There was no way that scrum would have been the right choice.
It is not that we did not try. We tried to apply scrum for year and half.
Developers were unhappy and did not want to attend daily meetings or any other meetings. There was constant mental pressure finishing sprints in time.
After switching to kanban we did not change anything but decided to concentrate on very next release at the beginning.
After half a year developers are happy to attend daily meetings. Flow is constant and we are even able to decrease technical debt 🙂

Leave a Comment: