SCRUM vs Kanban – Wo liegen die Unterschieden? Wo liegen die Gemeinsamkeiten? Mit SCRUM beschäftige ich mich seit über 10 Jahren im Rahmen des Führungskreises Softwareentwicklung. Beiträge von mir findet ihr unter anderem hier, hier und hier. Kanban hingegen hat eine bemerkenswerte Entwicklung genommen. Was mir zunächst nur als Konzept zur Produktionssteuerung bekannt war, taucht dank David Anderson seit 2007 vermehrt im IT-Umfeld auf.
Woher kommt Kanban?
Eines meiner ersten Projekte während des Studiums beschäftigte sich mit der Wäschereilogistik in einem Krankenhaus – auch das gibt es. Ziel des Projektes war die Wäschebestände auf den Stationen zu senken, da die Schwestern aus Furcht vor Engpässen immer auf Vorrat bestellt haben. Die Antwort damals hieß Kanban.
Kanban aus dem japanischen Übersetzt heißt (Signal-)Karte und ist unweigerlich mit Toyota und dem Pull-Prinzip verbunden. Anstelle auf Verdacht zu produzieren, wir nur hergestellt was am Ort der Entnahme verbraucht wird. Der entstandene Bedarf wird dann von der verbrauchenden Stelle an die produzierende Stelle über eine Kanban-Karte gemeldet.
Das System galt/gilt als todschick und wird in der Produktion vielfach eingesetzt. Schließlich verspricht das System reduzierte Lagerbestände und ermöglicht die gewünschte Just-in-Time Produktion. Nicht zu viel produzieren, nicht zu wenig produzieren – eben genau was der Kunde braucht. Was hat Kanban aber nun im IT-Umfeld verloren?
Kanban in der IT
David Anderson hat die wesentlichen Funktionsprinzipien hinter Kanban übernommen, also Lean Production und Lean Development und anschließend auf die IT angewendet. Heraus gekommen sind sechs Kernpraktiken:
- Mach Arbeit sichtbar: Hier kommen die berühmten Kanban-Boards zum Einsatz, um den Prozess transparent zu machen. Die einfachste Form eines solchen Boards seht ihr in der untenstehenden Abbildung.
- Limitiere den Work in Progress (WiP): hier kommt das genannte Pull-Prinzip zum Einsatz. Stelle nur her was verbraucht wird bzw. in der nächsten Station weiterverarbeitet werden kann. Alles andere würde zu unnötigem Stau führen.
- Manage Flow: Messen – Messen – Messen. Wie hoch ist der Durchsatz im System? Wie viele Kanban-Karten können pro Woche abgearbeitet werden? Wie lange dauert die durchschnittliche Bearbeitungsdauer?
- Mache Prozessregeln explizit: Die Regeln müssen allen im Team klar sein. Wer zieht Aufgaben durchs System bzw. wer ist der Kunde? Wann werden Aufgaben gezogen? Wann ist eine Aufgabe wirklich erledigt (Definition of Done)?
- Implementiere Feedback-Mechanismen: Hier sind die Parallelen zwischen Kanban und SCRUM sowie Shopfloor Management am offensichtlichsten. Kurze, regelmäßige, strukturierte Meetings; um sich abzustimmen und die Arbeitsweise fortlaufend zu verbessern.
- Führe gemeinschaftliche Verbesserungen durch: Hier gibt es keine konkrete Methodenvorgabe, aber der Kerngedanke KVP ist mehr als klar. Aufgrund der Messergebnisse werden Maßnahmen ergriffen, um das System zu optimieren – Plan – Do – Check – Act.
SCRUM vs Kanban im Vergleich
SCRUM und Kanban werden häufig gleichgesetzt. Teilweise wird argumentiert SCRUM wäre eine mögliche Implementierung von Kanban. Andersherum wird Kanban als eine erweiterte Version des SCRUM-Boards abgetan. Egal wie man es dreht und wendet, im Kern gibt es Überschneidungen aber auch Unterschiede – deshalb auch SCRUM vs Kanban:
Das nachfolgende Video „SCRUM vs Kanban“ gibt weiterführende Einblicke:
Fazit – SCRUM vs Kanban
Durch Kanban nach David Anderson wird der Versuch unternommen, Aufgaben von Wissensarbeitern möglichst effizient abzuarbeiten (labour vs work oder Beschäftigung vs Arbeit). Dazu wird Stau vermieden, indem die Ware in Arbeit limitiert wird. Der Engpass bestimmt den Durchsatz. SCRUM hingegen limitiert die Ware in Arbeit nur indirekt über die Dauer des Sprints bzw. das Commitment des Teams. Bei SCRUM gilt es durch Timeboxing, in regelmäßigen Abständen ein lauffähiges Produkt zu erzeugen. Im Kern sind SCRUM und Kanban zwei Werkzeuge, die versuchen die Effizienz der Arbeit im Team zu steigern, allerdings mit unterschiedlichen Zielsetzungen. Kanban fokussiert sich auf die Abarbeitung von Aufgaben, z.B. am IT-Servicedesk. SCRUM versucht die Entwicklung von Produkten effizienter zu gestalten, z.B. in der Softwareentwicklung. Oder wie Franz Votapek im untenstehenden Kommentar treffend bemerkt: „Kanban für Prozesse, SCRUM für Projekte, eigentlich ganz einfach.“
Dr. Patrick Fritz
Kommentar verfassen