Agile, Kanban

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.