Scrum und Kanban im Vergleich – Unterschiede und Gemeinsamkeiten

Scrum und Kanban haben unterschiedliche Zielsetzungen

Scrum ist ein Rahmenwerk für die Produktentwicklung im komplexen Umfeld. Es ist ein empirisches Prozessvorgehen und basiert daher auf Inspektion und Adaption. In immer gleich langen Zeitabschnitten werden fokussiert einige wenige Ideen realisiert. Am Ende des Zeitabschnitts wird das Ergebnis einer Inspektion unterzogen, um daraus Erkenntnisse zu gewinnen, welche Aufgaben im nächsten Zeitabschnitt angegangen werden. Nach demselben Prinzip wird auch die Arbeitsweise beleuchtet, um sie in der Folge adaptieren (anpassen) zu können. Dieser sich wiederholende Ablauf zielt darauf ab, dass die Beteiligten schnell und stetig erlernen, wie das Produkt wirklich wertvoll für seine Nutzer wird.

Kanban ist eine Vorgehensweise zur Prozesskontrolle und -verbesserung.
Das Ziel von Kanban ist es, die Durchlaufgeschwindigkeit von Aufgaben in einem System zu optimieren. D.h. jede einzelne Aufgabe sollte so schnell wie möglich erledigt werden (können). Prozessschritte, die dies verhindern, werden erkannt und verbessert.

Lesen Sie auch “Was ist Scrum?”

Revolution und Evolution

Scrum gibt einem Team durch wenige Verantwortlichkeiten, Artefakte, Commitments und Ereignisse/Events einen stabilen Rahmen. Schon durch die Beschränkung auf lediglich drei Verantwortlichkeiten (ehemals Scrum Rollen) im Team gleicht die Einführung von Scrum einer Revolution. Als erstes muss ein interdisziplinäres Team gegründet werden, welches über alle Kompetenzen verfügt, um unabhängig von Außenstehenden arbeiten und entscheiden zu können. Ein revolutionärer Gedanke in vielen Organisationen, in denen Entscheidungen in der Regel auf höheren Hierarchie-Ebenen getroffen und überwacht werden.
Im Unterschied zu Scrum ist Kanban ein sog. evolutionäres Vorgehen. Das bedeutet, dass man mit dem beginnt, was man vorfindet und als erstes Transparenz über den Ist-Zustand erzeugt: Man visualisiert, welche Aufgaben derzeit bekannt sind und sich noch nicht oder schon in der Bearbeitung befinden. Dabei respektiert man zunächst alle Regeln, Rollen und Titel, die zu diesem Zeitpunkt im betrachteten Team, Abteilung oder Unternehmen gibt.
Anhand dieser Ausgangsbasis betreibt man in der Folge eine kontinuierliche Prozessverbesserung. Regeln, Rollen und Titel können sich also nach und nach ändern, aber eben nicht sofort und auf einen Schlag.

Einfach zu verstehen und schwierig zu meistern ist beides

Ken Schwaber und Jeff Sutherland schreiben im Scrum Guide, dass Scrum einfach zu verstehen und schwierig zu meistern sei. Ein Grund dafür ist, dass bei der Einführung von Scrum großer Wille zur Veränderung vorhanden sein muss – und zwar nicht nur von den Beteiligten im Team, sondern auch von der gesamten Organisation. Vielfach wird deshalb stattdessen ein Kanban-Ansatz gewählt, da es dort vergleichsweise wenige Vorgaben gibt, Kanban also als “einfacher” umzusetzen als Scrum fehlinterpretiert wird. Nur genau diese Freiheit durch fehlende Vorgaben macht es so schwer, einen wirklichen Nutzen mit Kanban zu generieren. Es bedarf eines strikten Willens an der kontinuierlichen Verbesserung zu arbeiten und sich fortwährend zu fragen: Sind wir wirklich schon gut? Oder könnten wir nicht noch besser sein?

Rahmenbedingungen bedenken

Um eine gute Entscheidung treffen zu können, wann Scrum oder wann Kanban eine gute Wahl ist, sollten neben der zentralen Zielsetzung beider Ansätze weitere Rahmenbedingungen bedacht werden.

1. Team oder Gruppe

Um eine gute Entscheidung treffen zu können, wann Scrum oder wann Kanban eine gute Wahl ist, sollten neben der zentralen Zielsetzung beider Ansätze weitere Rahmenbedingungen bedacht werden. Sehr wichtig ist die Frage, ob die Herausforderung für ein Team oder eine Gruppe geeignet ist. Bei einer Team-Herausforderung kann der Erfolg nicht auf den Beitrag der Einzelpersonen heruntergebrochen werden. In diesem Fall können sowohl Scrum als auch Kanban passende Vorgehensweisen sein. Wenn allerdings die Herausforderung eher für eine Gruppe geeignet ist, dann dürfte man sich mit Scrum schwertun. Bei einer Gruppen-Herausforderung kann jedes Gruppenmitglied prinzipiell für sich alleine einen bestimmten Aufgabenbereich betreuen. Wenn der Arbeitsfluss aufrecht erhalten werden kann und Ergebnisse den Erwartungen entsprechen, ohne dass die Einzelnen zwangsläufig im Austausch miteinander sein müssen, dann wäre Kanban die bessere Wahl. Gleiches gilt, wenn eine einzelne Person gerne mit agilen Methoden arbeiten möchte: Dafür ist die Methode “Personal-Kanban” hervorragend geeignet.

2. Priorisierung der Aufgaben

Wenn ein Team autonom arbeitet hat dies zur Folge, dass das Team die zu bewältigende Arbeit eigenständig verwaltet und priorisiert – eine unabdingbare Voraussetzung für Scrum. Wenn hingegen Aufgaben von Außen an das Team herangetragen und deren Fertigstellungstermine festgelegt sind, dann ist Scrum als Vorgehensmodell nicht gut geeignet. Ein Kanban-System, in dem der Abarbeitungsprozess und dessen Verbesserung im Vordergrund steht, könnte in diesem Fall die besser Wahl sein.

3. Kultur

Wenn die Unternehmenskultur bereits von kollegialer Zusammenarbeit geprägt ist, ist dies eine gute Voraussetzung für eine Scrum-Einführung. Dazu müssen vertrauensvolles Miteinander und gegenseitige Unterstützung als Wert in der Kultur verankert sein. Wenn in der Unternehmenskultur dagegen Kontrolle stark geschätzt wird, wenn Regeln und deren Einhalt einen wichtigen Wert darstellen, dann hat eine Arbeit mit Kanban bessere Chancen.

Scrum und Kanban gemeinsam betrachtet

Scrum und Kanban können sich sehr gut ergänzen. Tatsächlich passiert dies bereits in vielen Scrum Teams, obwohl es im Scrum Guide nicht explizit erwähnt wird. In den letzten Jahren sind die meisten Teams dazu übergegangen, ihr Sprint-Backlog auf einem Kanban-Board zu visualisieren und zu verwalten. In gewisser Weise ist also ein Kanban-Prozess innerhalb des Scrum Sprints integriert. Gleiches gilt für Aufgaben, die nicht planbar sind bzw. nicht sinnvoll in den Scrum-Prozess integriert werden können: Man kann für sie eine eigene Spalte am oberen oder unteren Ende des Boards des Scrum Teams einführen, um auch über diese Aufgabengruppe und deren Abarbeitungsstand Transparenz zu gewährleisten.

Mehr erfahren: “Was ist Scrum?”

Neueste Blogposts

Entfalten Sie Ihr volles Potenzial
im neuen Jahr

Sichern Sie sich jetzt 10% Rabatt auf unsere Ausbildungen und starten Sie 2024 mit neuem Wissen!

*Bis einschließlich 31.12.23