November 9, 2015

Froschfigur mit Koffer

In Deiner Arbeit als Scrum Master bleibst Du selbst ständig auf der Strecke? 

Dann hole Dir hier die Anleitung für Deine persönliche Retrospektive. 

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.

About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

  1. 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.

    1. 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.

  2. 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 🙂

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir die kostenlose Anleitung für
Deine persönliche
 Retrospektive