Scrum vs. Kanban

Viele Teams und Organisationen stehen vor der Frage, ob Scrum oder Kanban die richtige Vorgehensweise für ihre momentane Situation bzw. Herausforderung darstellt. Mit diesem Artikel möchte ich Dir dabei helfen, die grundlegenden Gemeinsamkeiten und Unterschiede beider Frameworks besser zu verstehen und Dir damit einen schnellen Überblick zu verschaffen. Zum Schluss gebe ich Dir natürlich noch einige Denkanstöße mit auf den Weg, die Dir bei der Entscheidungsfindung helfen sollen.

Die Unterschiede zwischen Scrum und Kanban sind sehr viel geringer, als Du vielleicht annimmst. Beide Ansätze basieren auf den Agilen Werten & Prinzipien und betrachten beispielsweise Selbstorganisation also adäquate Antwort auf komplexe Herausforderungen. Und natürlich geht es in beiden Frameworks bzw. Methoden hauptsächlich um die Frage, wie eine Organisation möglichst schnell bzw. häufig Nutzen & Wert für Kunden schaffen und auf Veränderung reagieren kann.

Scrum formuliert einen Team-fokussierten Lösungsansatz, während Kanban einen Workflow-fokussierten Ansatz favorisiert.

Als erstes möchte ich mit Dir deshalb einen gemeinsamen Blick darauf werfen, was hinter diesen Ansätzen genau steckt.

Den Team-fokussierten Ansatz von Scrum kannst Du leicht daran erkennen, dass der Scrum Guide die Bildung eines interdisziplinären Teams bzw. Scrum Teams vorschreibt.

Dieses Team hat zum einen klar definierte Rollen bzw. Verantwortlichkeiten, nämlich den Product Owner, einen Scrum Master und Entwickler.

Zum anderen – und das ist an dieser Stelle viel wichtiger – ist der Grundgedanke von Scrum, dass ein einziges Team den Nutzen bis zum Kunden bringt.

Wenn Du so möchtest “trägt ein Scrum Team Arbeit durch den gesamten Workflow vom Beginn bis zum Ende.”

Kanban kennt diesen Team-Fokus aus Scrum hingegen nicht. Es konzentriert sich ausschließlich auf den Workflow und seine kontinuierliche Verbesserung.

Dabei ist es in Kanban egal, ob es ein einzelnes agiles Team ist, dass mit diesem Workflow arbeitet, ob innerhalb des Workflows Übergaben zwischen einzelnen Teams existieren oder an manchen Prozessschritten nur einzelne Menschen die notwendige Arbeit erledigen (oder sogar mehrere Teams).

In dieser Hinsicht ist Kanban deshalb deutlich flexibler, freier und einfacher, was seine Umsetzung bzw. Einführung angeht. Andererseits gibt Dir Kanban (im Gegensatz zu Scrum) nicht die Antwort vor, wie der Aufbau Deiner Organisation und Deiner Teams genau auszusehen hat.

Den zweite wichtige Unterschied zwischen Scrum und Kanban kannst Du in der Organisation von Arbeitszyklen entdecken. Das Scrum Framework erzeugt ein rhythmisches Vorgehen, das durch kurze Iterationen entsteht, in denen ein klares Ziel verfolgt wird. Kanban hingegen erzeugt einen kontinuierlichen Wertstrom. Allerdings kennt auch Kanban feste Zeiträume, die den Iterationen aus Scrum sehr ähnlich sind, jedoch Kadenzen genannt werden.

Scrum verfolgt den Ansatz, innerhalb eines fest definierten, sehr kurzen Zeitraums, ein Ziel zu erreichen.

Der Grundgedanke ist also, auf ein Ziel hinzuarbeiten und am Ende des Zeitraums zu überprüfen, ob das Ziel erreicht wurde (oder nicht).

Aus der Reflexion darüber, passt ein Scrum Team seine Arbeitsweise an und setzt sich für den folgenden (gleichlangen) Zeitraum sein nächstes Ziel.

Um den erwähnten Rhythmus zu erzeugen, sind diese Zeiträume immer gleich in Aufbau und Abfolge, weshalb sie auch Iterationen genannt werden.

Kanban kennt dieses rhythmische Vorgehen aus Scrum nicht. Weder wird für einen klaren Zeitraum ein Ziel gesetzt, noch wird ein solcher Zeitraum durch vorgeschriebene Events strukturiert, die eine immer gleiche Abfolge haben.

Vielmehr geht es in Kanban darum, einen gleichmäßigen (Wert-)strom zu erzeugen.

Allerdings kennt auch Kanban wiederkehrende Meetings, die diesen Wertstrom verbessern sollen. Tatsächlich gibt es dabei viele Überschneidungen und Gemeinsamkeiten mit Scrum. Beispielsweise das Daily Stand-up, das in Scrum lediglich als Daily Scrum bezeichnet wird.

Weil die Kanban-Meetings jedoch weniger stringent ausgelegt sind als in Scrum, spricht Kanban von Kadenzen und nicht von Iterationen.

Neben diesen beiden grundlegenden Unterschieden in der Philosophie, um Nutzen zum Kunden zu bringen und den Wertstrom zu verbessern, gibt es zwischen Scrum und Kanban auch eine wichtige Gemeinsamkeit. Denn beide nutzen Mechanismen, um den Wertstrom vor Überlastung zu schützen.

Kanban stützt sich dabei auf ein explizites Work-In-Progress-Limit, während Scrum den gleichen Effekt durch ein Sprint Backlog erreicht.

Weil Scrum mit festen Iterationen arbeitet, die ein einzelnes Team durchläuft, nutzt es eine Art Arbeitsspeicher für jeden Scrum Sprint: das Sprint Backlog.

Ein Scrum Team setzt sich wie oben erwähnt ein Ziel für seine nächste Iteration und notiert die dazu notwendige Arbeit in sein Sprint Backlog.

Sobald ein Sprint begonnen hat, ist dieses Sprint Backlog eine Art Container, in den (im Optimalfall) keine neue Arbeit von außen hineingedrückt werden kann, die die Erreichung des Sprintziels gefährdet.

Weil Kanban weder feste Iterationen noch ein einziges Team fordert bzw. kennt, besteht natürlich auch nicht die Möglichkeit eine Art Sprint Backlog wie in Scrum zu etablieren.

Deshalb begrenzt Kanban den Workflow durch ein sogenanntes WIP-Limit, das sich auf den gesamten Workflow bezieht.

Das Grundprinzip ist jedoch auch in Kanban genau das Gleiche.

Sowohl Scrum als auch Kanban begrenzen die Menge paralleler Arbeit.

Mit diesen Erkenntnissen fällt es Dir nun hoffentlich leichter, Dich zwischen Scrum und Kanban zu entscheiden. Falls Du noch immer unsicher bist, habe ich jedoch noch einige Tipps und Hinweise für Dich.

Im Gegensatz zu Kanban wird Scrum umso stärker und nützlicher, je komplexer Deine Herausforderungen sind. In Situationen, in denen viel Unklarheit herrscht und hohe Risiken existieren, bietet Scrum durch sein empirisches Vorgehen einen hervorragenden Lösungsansatz. Generell würde ich zwar nicht sagen, dass komplexe Herausforderungen nicht auch mit Kanban lös- bzw. handhabbar wären, aber hier geht der Punkt ganz klar an Scrum.

Gleichzeitig gilt jedoch: Je geringer die Komplexität von Projekten und Anforderungen wird oder ist, desto attraktiver wird die Nutzung von Kanban.

Besonders gut wird dieser Umstand daran sichtbar, wenn Scrum Teams Schwierigkeiten dabei haben, ein Sprintziel festzulegen. Denn viele Teams sind schlichtweg in der Situation, dass sie “nur” viele verschiedene Aufgaben möglichst effizient (für andere Abteilungen) umsetzen sollen. Folgerichtig tun sich solche Teams schwer, ein Ziel für die nächsten 2 Wochen zu formulieren, anhand dessen sie ermitteln wollen, ob sie auf dem richtigen Weg sind.

Kanban kennt wie oben erwähnt keine Ziele und ein Kanban Team kann daher in den Workflow hineinfließende Arbeit direkt umsetzen. Es hat also seine Gründe, warum Kanban beispielsweise häufig im Kundenservice genutzt wird.

Eine Stolperfalle bei der Entscheidung, ob Scrum oder Kanban das bessere Vorgehen für Deine Organisation ist, liegt in einer fehlerhaften Wahrnehmung beider Frameworks.

Zum einen hat Scrum ein echtes Imageproblem. Viele Menschen sehen sich bereits vor unüberwindbare Herausforderungen gestellt, wenn es darum geht, die Grundelemente von Scrum in ihrer Organisation zu verwirklichen. Schon die Gründung eines Scrum Teams kollidiert dann mit den vielen schönen Abteilungssilos, die über Jahre hinweg mühselig aufgebaut wurden.

Daneben gibt es noch einige weitere Dinge, die Scrum als echter Nachteil ausgelegt werden, obgleich sie keine sind. Manchmal kommt es sogar zu der Behauptung, dass Scrum viel zu dogmatisch sei.

Zum anderen kommt Kanban scheinbar sehr viel einfacher daher. Das erste Kanban-Prinzip “Beginne dort, wo Du Dich aktuell befindest” erweckt bei vielen den Eindruck, dass Kanban deutlich weniger Vorschriften als Scrum habe und deshalb weniger Mühe mache. Übersehen wird dann allerdings gerne das zweite, direkt folgende Prinzip “Vereinbare, dass evolutionäre Veränderung verfolgt wird”. Auch in Kanban wird es deshalb immer darum gehen, Abhängigkeiten zu reduzieren und eine notwendige Umgestaltungen in Deiner Organisation voranzutreiben.

Hinzu kommt noch, dass Kanban den Workflow mit Hilfe diverser Metriken optimiert und die vielen Kennzahlen dem einen oder anderen ziemlich schnell übel aufstoßen. (Das gilt natürlich nur dann, wenn man Kanban ernsthaft betreiben möchte, und nicht “nur das Kanban Board benutzt”.)

So oder so bleibt deshalb auch in Kanban die Arbeit die gleiche wie in Scrum. Der einzige Unterschied besteht darin, dass die agile Transformation mit Kanban ein wenig “nach hinten” geschoben wird und nicht direkt zu Beginn viele Umbaumaßnahmen notwendig werden wie in Scrum.

Drittens musst Du vielleicht gar nicht zwischen Scrum vs. Kanban entscheiden, sondern kannst beides gleichzeitig einsetzen. Dieser Ansatz ist auch unter dem Kofferwort Scrumban bekannt und ermöglicht es Dir, sowohl Scrum als auch Kanban einzusetzen.

Darüber hinaus stehen Dir jederzeit zwei weitere Optionen zur Verfügung: Zum einen kannst Du mit Kanban beginnen, um die Entwicklung Deines Produktes später auch mit Scrum voranzutreiben und zum anderen kannst Du (jederzeit) von Scrum auf Kanban umschwenken. Deine Entscheidung, ob Scrum oder Kanban das bessere Vorgehen für Dich und Deine Organisation ist, ist so gesehen alles andere als endgültig.