Scrum und Kanban – wann nutze ich was?

Scrum und Kanban, das Eine ein vollumfassendes Framework, das Andere eine mächtige Methode, um Prozesse zu optimieren, sofern das Unternehmen mitspielt. In diesem Artikel zeige ich die Unterschiede, aber auch die Gemeinsamkeiten der beiden Methoden auf und gebe eine Entscheidungshilfe, wann welche Methode zum Einsatz kommen sollte.

Scrum vs. Kanban: Gemeinsamkeiten

Schauen wir uns die Gemeinsamkeiten von Scrum und Kanban an:

• Beide nutzen das Pull-Prinzip. In Scrum kommt es beim Sprint Planning zum Einsatz, in Kanban gilt es auf dem gesamten Board.
• Die beiden sind sowohl lean als auch agile im eigentlichen Sinne.
• Alle zwei machen durch Transparenz das Optimierungspotenzial des Prozesses sichtbar. In Scrum treibt dieses Thema maßgeblich der Scrum Master, in Kanban wird es durch die Stakeholder und das Management forciert, sofern WIP-Limits die Bottlenecks aufzeigen.
• Die Zwei nutzen WIP-Limits. In Scrum limitiert der Sprint die Anzahl der zu erledigenden Aufgaben, in Kanban ist es das WIP-Limit bei den Statusübergängen.
• Beide arbeiten mit dem Ziel, dass die Teams sich selbst organisieren.
• Beide versuchen den Releaseplan zu optimieren. In Scrum mithilfe der Team-Velocity, bei Kanban dient dazu die Lead-Time.
• Beide möchten auslieferbare Softwareinkremente möglichst oft und schnell releasen.

Scrum vs. Kanban: Unterschiede

Das Ziel ist das gleiche, aber der Weg dorthin unterscheidet sich doch maßgeblich. Genau hier kommen die Unterschiede zum Tragen:

• Rollen: Scrum sieht drei Rollen vor: Scrum Master, Product Owner, Entwicklungsteam. Kanban kennt normalerweise keine dieser Rollen.
• Timebox: Vom Daily bis zum Sprint, alles ist bei Scrum mit einer Timebox versehen. In Kanban gibt es eine solche nicht – zumindest keine vorgegebene.
• Team-Forecast: In Scrum gibt diesen das Team für den Sprint, indem es sich fragt, welche Arbeit sie bis zum Ende schaffen. In Kanban ist derartiges nicht vorgesehen.
• Velocity vs. Lead-Time: Scrum nutzt die Team-Velocity als Metrik für Planungen und Prozessoptimierungen. In Kanban ist dies die Lead-Time.
• Schätzungen: Per Scrum Guide vorgeschrieben, in Kanban optional.
• WIP-Limit: Scrum hat ein indirektes (den Sprint), Kanban ein direktes per Statusübergang im Workflow.
• Burndowncharts: Gibt es in Scrum, in Kanban nicht.
• Unvorhergesehene Arbeit: In Scrum ist der Sprint geschützt, streng genommen wandern neue Aufgaben in das Product Backlog und werden im nächsten Sprint erledigt. In Kanban entscheidet die verfügbare Kapazität darüber, ob ein Arbeitspaket erledigt wird oder nicht. Dies kann durch die betroffenen Stakeholder unmittelbar beeinflusst werden.
• Boards: Ein Scrumboard ist optional und wird zu jedem Sprint neu mit Arbeitspaketen bestückt. Ein Kanbanboard bleibt hingegen dauerhaft erhalten und wird erst mit Beendigung des Produktes/Projektes gelöscht.
• Product Backlog: In Scrum zwingend priorisiert, bei Kanban ist dies ebenfalls optional.

Stacey-Matrix als Entscheidungshilfsmittel

Wann nutze ich nun was? Es kommt darauf an! Ein Hilfsmittel hierfür ist die Stacey-Matrix:

Die Einteilung ist recht simpel. Die vier Bereiche lassen sich wie folgt charakterisieren:

• Einfach: Eine Aufgabe gilt als einfach, wenn die relevanten Dinge zu ihrer Erledigung bekannt oder weitgehend bekannt sind.
• Kompliziert: Eine Aufgabe gilt als kompliziert, wenn von den relevanten Dingen zur Erledigung der Arbeit mehr bekannt als unbekannt ist.
• Komplex: Eine Aufgabe ist als komplex zu bezeichnen, wenn für die Aufgabenerledigung mehr unbekannt als bekannt ist.
• Chaotisch: Eine Aufgabe gilt als chaotisch, wenn sehr wenig über sie bekannt ist.

Schaue ich mir nun die beiden Achsen an, ergibt sich schnell ein Gefühl dafür, mit was ich es hier zu tun habe. Ist die verwendete Technologie für jeden bekannt oder gibt es hier Defizite? Gleiches gilt für die Einigkeit im Team oder der Organisation, was genau erstellt werden soll.

Einfache Aufgaben hinsichtlich der funktionalen Anforderungen und der verwendeten Technologien schreien geradezu nach einer Automatisierung. Hier komme ich weder mit Scrum noch mit Kanban weiter. Eine komplizierte Aufgabenstellung kennzeichnet in der Regel eine etablierte Struktur, die es mit bereits definierten Architekturen und Schnittstellen umzusetzen gilt. Wer meint, eine komplexe Aufgabenstellung planen zu können, der irrt. Hier muss ich mich schrittweise meinem Ziel nähern.

Wann Kanban, wann Scrum

Kontinuierliche Verbesserung, eines der Kernprinzipien von Kanban, deutet es bereits an: Ein Einsatz von Kanban in einem beherrschbaren Softwareprozess ergibt einen Sinn. Die Softwareentwicklung ist in der Regel soweit strukturiert, dass man sich im komplizierten Teil der Stacey-Matrix befindet. Daher findet sich Kanban auch häufig in Support- oder Wartungsteams. Die dort zu lösenden Aufgaben sind kompliziert, aber in der Regel nicht komplex.

Scrum legt seinen Aufgabenschwerpunkt in den komplexen Bereich der Stacey-Matrix, in dem übrigens der überwiegende Teil der Softwareentwicklung angesiedelt ist. Wie schon geschrieben, lässt sich eine komplexe Aufgabe nicht planen.
Durch Scrum lässt sich zwar nicht besser planen – dies gibt das Vorgehensmodell nicht her –, aber Scrum hat hierfür Antworten: Crossfunktionale Teams und kurze Planungs- und Iterationszyklen. Somit macht man sich diesen Umstand bewusst und verwendet nur so viel Zeit wie unbedingt notwendig auf eine Planung. Wer nicht genau sagen kann, was erstellt werden soll, kann nicht durch den Einsatz einer bestimmten Methodik einen exakten Plan verlangen, auch wenn dafür manchmal “Experten” eingekauft werden. Komplexe Aufgabenstellungen können aber durch den Einsatz von Scrum mit interdisziplinären Teams und kurzen Feedbackzyklen ideal dazu genutzt werden, das richtige Produkt mit einem überschaubaren Einsatz an Aufwand zu erstellen.

Fazit Tl;DR

Scrum setze ich ein, wenn meine Aufgabenstellung im komplexen Bereich der Stacey-Matrix angesiedelt ist. Bedingt kann ich auch den chaotischen Bereich mit Scrum strukturieren, so dass er komplex wird. Jedoch würde ich hier andere Methoden, wie Lean Startup oder Design Thinking vorziehen.

Kanban legt den Fokus auf die Effizienz des bestehenden Prozesses und möchte die Produktivität erhöhen, das geht mit komplizierten Aufgaben wesentlich besser als mit komplexen.