Welche Unterschiede es gibt und welche Vor- und Nachteile die beiden Modelle haben, beleuchten unsere Cassini-Berater Patrick Daut und Peter Kalvelage. Sie raten dazu, zwischen beiden Methoden zu wechseln – wenn es Sinn macht.
Worin unterscheiden sich Scrum und Kanban?
Kalvelage: Scrum gibt ein komplettes Framework vor. Die Rollen zur Erreichung des Ziels sind definiert, der Ablauf ist vorgegeben – genau wie die Artefakte, die an bestimmten Punkten im Zeitverlauf entstehen. Ein Scrum-Team hat also einen klaren Orientierungsrahmen ...
Daut: ... während Kanban nun mal kein Framework, sondern ein Ansatz zur Prozessoptimierung ist, der sich an den klassischen Lean-Prinzipien orientiert. Am Anfang steht der aktuell in der Organisation gelebte Prozess, über den im ersten Schritt Transparenz hergestellt wird. Zur Visualisierung dient das bekannte Kanban-Board. Hat man den Prozess soweit im Griff, verbessert man ihn schrittweise, so dass immer weniger „Waste“ – vor allem in Form von Wartezeiten – entsteht.
Welche Einflussfaktoren sind bei der Entscheidung für die eine oder die andere Methode ausschlaggebend?
Daut: Man muss den konkreten Fall betrachten. Grundsätzlich kann man sagen: Bei Scrum steht das Produkt und seine wertmaximierende Entwicklung im Vordergrund. Die agilen Prinzipien werden über konkrete Vorgaben umgesetzt. Kanban hat das Ziel effektiverer Abläufe durch die Anwendung möglichst schlanker Grundsätze. Im Zentrum stehen das Pull- und Flussprinzip. Deshalb wird Kanban oft in Betriebssituationen mit wiederkehrenden Prozessen und kleineren Aufgaben eingesetzt. Scrum dagegen bei komplexeren Projekten und in der Produktentwicklung.
Kalvelage: Wobei sich die Methoden im Laufe der Evolution eines Teams abwechseln können...
Daut: Warum auch nicht? Es ist durchaus möglich, zunächst Scrum einzuführen, um mit Hilfe des definierten Frameworks agile Denkweisen zu etablieren. Mit zunehmender Reife des Teams kann ein Wechsel zu Kanban eine größere Flexibilität ermöglichen. Oder man setzt Kanban ein, um von Scrum ausgehend den Arbeitsprozess weiterzuentwickeln. Es gibt also fließende Übergänge.
Kalvelage: Wie fließend sie sind, zeigt sich darin, dass Kanban theoretisch umgekehrt auch zu Scrum führen kann. Optimiert man einen gegebenen Prozess mit Kanban und stellt fest, dass es Sinn macht, bestimmte Rollen einzuführen – wie einen Scrum Master oder Product Owner –, kann man bei Scrum landen. Wenn man so will, kann man Kanban als ein Metaframework bezeichnen.
Daut: Genauso kann ein erfahrener Scrum-Master auf die Visualisierungsmethode des Kanban-Boards zurückgreifen oder Scrum nach Kanban-Prinzipien verändern – das Framework also verlassen. Diese Übergänge zeigen, dass das agile Scrum und das von Lean-Prinzipien abstammende Kanban analoge Ziele verfolgen.