Scrum oder Kanban?

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.

Welche Methode lässt sich einfacher einführen?
Daut: Das lässt sich nicht pauschal beantworten. Meiner Erfahrung nach lässt sich aus einer Organisation mit funktional getrennten Abteilungen deutlich einfacher eine Struktur mit interdisziplinären Scrum-Teams bilden, wozu z. B. Anforderungsentwickler, Softwareentwickler und Tester gehören. Möchte man ein komplexes Produkt mit Kanban entwickeln, empfehle ich reifere Teams: Hat sich die Gruppe bereits gefunden und das Pull- und Flussprinzip verinnerlicht, ist die Gefahr deutlich geringer, am Ende ein Kanban-Board ohne merklichen Nutzen zu haben. Hellhörig werde ich bei Kanban-Einführungen, wenn sich die Karten nicht schnell über das Board bewegen. Das ist ein deutlicher Hinweis darauf, dass die Prinzipien noch nicht gelebt werden.

Kalvelage: Kanban macht Sinn, wenn die Arbeit durch einen Prozess fließt und am Kanban-Board visualisiert werden kann. Um Verschwendung zu optimieren, muss man die einzelnen Schritte messen können. Das heißt, größere Aufgaben oder zu implementierende Funktionalitäten müssen in Teile zerlegt werden, die weiterhin sinnvoll nutzbar bleiben. Keine leichte Aufgabe, die Übung erfordert. Reichen die Fähigkeiten dafür noch nicht aus, kann der Sprint im Scrum-Framework als Begrenzung dienen. Setzt man Kanban ein, hat man keine Hilfestellung.

Daut: Ja, bei Kanban muss bereits ein gewisses Verständnis für die Wertstromkette vorhanden sein. Man kontrolliert und optimiert den Prozess mit seinen Einzelschritten. Das Scrum-Team agiert im Rahmen des Frameworks freier und stellt in Iterationen ein Produktinkrement nach dem anderen fertig – was sich übrigens durchaus wieder mit den Einzelschritten bei Kanban vergleichen lässt.

Zu welcher Methode raten Sie bei Innovationsprozessen?
Kalvelage: Von seinem Wesen her zu Scrum, weil es dem Team kreativen Raum lässt, während Kanban eher auf eine Abarbeitung von Teilschritten hinausläuft. Hier müsste erst der Rahmen für Innovation gebaut bzw. der Prozess entsprechend optimiert werden. Scrum baut mehr auf die Erfahrung des konkreten Teams und der weiteren Rollen. Dafür ist man flexibler.

Welche Methode würden Sie als kundenorientierter bezeichnen?
Daut: Scrum beruht auf dem agilen Manifest, das auch das Prinzip Kundenorientierung beinhaltet. Das Framework gibt zu diesem Zweck Meetings und eine explizite Rolle vor. Der Product Owner nimmt die Sicht des Kunden ein und sorgt dafür, dass das Produkt dem Kunden nach jeder Iteration den maximalen Mehrwert bringt.

Kalvelage: Bei Kanban steckt das aber auch drin. Was der Kunde nicht braucht, wäre Verschwendung im Lean-Sinne. Aber tatsächlich müsste man Kanban anpassen – eben durch die Einführung entsprechender Rollen und Meetings. Mit anderen Worten: Kanban hindert einen nicht daran, sich kundenorientiert zu strukturieren. Aber richtig: Scrum bringt das schon mit.

Das klingt danach, als wäre Kanban ziemlich frei einsetzbar.
Kalvelage: Ja, denn Kanban bringt keinen eigenen Prozess mit, sondern nimmt den vorhandenen Prozess auf. Das kann ein Vorteil sein. Die Scrum-Methode hat ganz konkrete Annahmen, die für sehr viele Bereiche passen. Für andere aber nicht. Dann wäre Scrum für die eigene Arbeitsweise ein Regel-Overhead.

Daut: Bei Kanban entwickelt man aus einem gegebenen Prozess seine eigenen Arbeitsweisen. Das führt auch dazu, sich mehr mit den dahinterstehenden elementaren Ideen der Lean-Literatur auseinanderzusetzen.

Ohne die agile bzw. Lean-Kultur im Hintergrund ist alles nichts?
Kalvelage: Bei Scrum besteht die Gefahr, sich in den Vorgaben zu verlieren und die Idee zu vergessen. Deshalb ist es wichtig, sich mit dem agilen Mindset dahinter zu beschäftigen. Kanban zwingt einen schon eher dazu, die Prinzipien zu verinnerlichen. Sonst ist letztlich gar nichts da – außer das Board.

Daut: Der Kontext muss stimmen. Werden die Leitgedanken von Lean und Agilität nicht verstanden, kann keine der beiden Methoden ihre Vorteile ausspielen. Die Ideen dahinter müssen mittransportiert werden. Werden nur die formalen Elemente umgesetzt, bleibt der Erfolg aus.