Die agilen Methoden Scrum und Kanban:
Was ist der Unterschied?
Scrum und Kanban sind Methoden, die im agilen Umfeld genutzt werden, um einen effizienten Projektverlauf zu gewährleisten. Je komplexer und unvorhersehbarer die Anforderungen an ein Projekt sind, desto wichtiger ist es, agil zu arbeiten, sodass schnell und flexibel auf Veränderungen oder auftretende Probleme reagiert werden kann. Um den Prozess eines Projektes übersichtlich und transparent darzustellen, arbeiten beide agilen Methoden mit der Visualisierung der einzelnen Arbeitsschritte. Im agilen Projektmanagement bei einer agilen Transformation finden daher beide Methoden großen Anklang.
Doch was sind die Unterschiede zwischen den beiden Methoden und wie lässt sich entscheiden, welche agile Methode am besten geeignet ist? Hierfür macht es Sinn, sich beide agile Methoden im Detail anzuschauen.
Was ist Scrum eigentlich?
Agile Methode: Scrum
Scrum ist ein agiles Framework, das die Teamzusammenarbeit in den Fokus rückt und sowohl bei IT-Projekten als auch anderen komplexen Projekten Anwendung findet.
Bei Scrum handelt es sich um einen iterativen und inkrementellen Ansatz. Eine Iteration beschreibt das Wiederholen einer Handlung, um diese kontinuierlich zu überarbeiten und sich der Lösung anzunähern. Inkrementell bedeutet, dass ein Produkt Schritt für Schritt zusammengebaut wird, um nacheinander die Features zu ergänzen, die einen Nutzen für Kund:innen liefern sollen. Verschiedene Aufgaben, die während eines Projektes anstehen, werden in kleine Teilaufgaben unterteilt und priorisiert in einzelnen Sprints bearbeitet. Dadurch können Risiken, welche unweigerlich bei großen Projekten entstehen, kontrolliert werden.
Durch ständiges Überprüfen und Anpassen (“Inspect & Adapt”) sowie der Implementierung einer offenen Feedbackkultur werden mögliche Fehler schnell korrigiert und auf auftretende Veränderungen reagiert. Auf diese Weise werden Kostenrisiken gesenkt und das Entwicklungsteam kann sich regelmäßig an die neuen Anforderungen anpassen.
Was ist ein Sprint? Wer sich für die Arbeit nach Scrum entscheidet, arbeitet in sogenannten Sprints. Dabei handelt es sich um Iterationen, die in der Regel zwei bis vier Wochen dauern. Das gesamte Projekt wird also in kleinere Teilprozesse unterteilt. So können basierend auf den Erfahrungen des laufenden Sprints Maßnahmen ergriffen werden und eine schnelle Anpassung an Veränderungen (beispielsweise von Anforderungen von Kund:innen) wird ermöglicht.
Die einzelnen Entwicklungsprozesse des Projektes werden auf einem sogenannten Scrum Board visualisiert und schriftlich dargestellt, um Transparenz zwischen den einzelnen Teammitgliedern zu schaffen.
Doch was gilt es bei der Arbeit nach Scrum zu beachten?
Die drei Verantwortlichkeiten nach Scrum
Der Product Owner
Wie schon erwähnt ist der Product Owner für die Verwaltung und Priorisierung des Product Backlogs zuständig. Der Product Owner (PO) trägt also die Verantwortung für den Erfolg des gesamten Produktes und sorgt dafür, dass der Nutzen des Produktes maximiert wird.
Das Team
Das gesamte Team ist für die Umsetzung der im Sprint Backlog festgelegten Aufgaben zuständig und präsentiert am Ende des Sprints das fertige Produkt Increment. Jedes Teammitglied trägt die Verantwortung für den Entwicklungsprozess der jeweiligen Aufgabe und trifft die Entscheidungen, die in diesen Geltungsbereich fallen, selbst.
Der Scrum Master
Der Scrum Master unterstützt das Team, indem er die Verantwortung dafür trägt, dass jedes Teammitglied und auch weitere Stakeholder der Organisation die Prinzipien von Scrum verstehen und diese korrekt umsetzen. Außerdem moderiert der Scrum Master die unterschiedlichen Scrum Events und schützt das Team vor unberechtigten Eingriffen während des Sprints. Da Scrum insbesondere bei komplexen und unvorhersehbaren Projektvorhaben angewendet wird, gibt es einige Vorschriften und Regeln zu beachten. Unterschieden wird hier zwischen drei Artefakten und regelmäßigen Scrum Events.
Die drei Artefakte von Scrum
Product Backlog
Alle Anforderungen, die die Stakeholder an ein Produkt stellen, werden nach Abstimmung mit dem Product Owner in das Product Backlog aufgenommen und dort verwaltet. Der Product Owner ist für die Priorisierung der einzelnen Aufgaben verantwortlich. Diese werden häufig in sogenannten User Stories formuliert, um die Funktionalitäten eines Produktes aus Sicht des:der Nutzer:in zu beschreiben und ein gemeinsames Verständnis zu schaffen. Hier erfahren Sie mehr zum Thema User Stories und User Story Mapping.
Sprint Backlog
Im Sprint Backlog befinden sich ausgewählte Elemente des Product Backlogs, die im nächsten Sprint bearbeitet werden sollen. Diese werden während des Sprint Plannings vom Entwicklungsteam gemeinsam mit dem Product Owner gemäß des priorisierten Product Backlogs festgelegt. So lässt sich auf einen Blick erkennen, welche User Stories während des Sprints bearbeitet werden sollen, um das Sprintziel zu erreichen.
Product Increment
Das Increment ist das Ergebnis eines jeden Sprints. Ziel ist es, ein potenziell lieferbares Product Increment entwickelt zu haben, welches einen Wert für den den:die Nutzer:in schaffen soll. Die in den User Stories definierten Akzeptanzkriterien sollen erfüllt sein, sodass das Increment nach der vom Team formulierten „Definition of Done“ fertig ist. Bei der Definition of Done identifiziert das Entwicklungsteam gemeinsam mit dem Product Owner die Akzeptanzkriterien, die erfüllt werden müssen, damit eine Story als abgeschlossen gilt. Doch welche Scrum Events gilt es zu unterscheiden?
Die drei Scrum-Events
Sprint Planning
Zu Beginn eines jeden Sprints führt das Team ein Planungs-Event durch, das sogenannte Sprint Planning. Die vom Product Owner priorisierten Aufgaben werden je nach Komplexität der Aufgabe relativ zueinander geschätzt. Wichtig ist es, realistisch zu schätzen, da während des Sprints keine Änderungen mehr vorgenommen werden sollen. Die zu erfüllenden Aufgaben (Stories) werden nach dem Pull-Prinzip („Hol“-Prinzip) verteilt.
Die einzelnen Teammitglieder nehmen sich den priorisierten Aufgaben an, indem sie sich die Stories vom Backlog in den Sprint ziehen und sich diesen während des Sprintzeitraums verpflichten. Auf diese Weise wird eine Überlastung des Teams vermieden, da nur die Anzahl an Aufgaben in den Sprint gezogen werden, die realistisch zu schaffen sind. Alle weiteren Aufgaben, die nicht im Sprint bearbeitet werden, werden im Backlog festgehalten und in den darauffolgenden Sprints aufgegriffen.
Daily Scrum
Täglich wird mit dem gesamten Team ein 15-minütiges Meeting abgehalten. Dieses dient dazu, den Status Quo zu besprechen sowie aufkommende Hindernisse und Probleme zu diskutieren, welche die Erreichung des Sprintziels gefährden könnten.
Sprint Review
Beim Sprint Review wird dem Product Owner und gegebenenfalls weiteren Stakeholdern das fertige Produkt Increment vorgestellt. Jedes Teammitglied präsentiert dabei seine Arbeitsergebnisse, die während des Sprints erarbeitet wurden. Idealerweise sind zu diesem Zeitpunkt alle Stories im Status „Done“.
Sprint Retrospektive
Bei der Sprint Retrospektive reflektiert das Team, welche Aspekte des Sprints positiv und welche negativ verliefen. Dieses Event wird vom Scrum Master moderiert, mit dem Ziel, Ideen und Vorschläge zur Optimierung zu sammeln und alle Teammitglieder auf ein gemeinsames Verständnis auszurichten. Das Scrum Team einigt sich darauf, zwei bis drei dieser Ideen direkt im nächsten Sprint umzusetzen.
Doch wie geht man bei der Arbeit nach Kanban vor?
Agile Methode: Kanban
Kanban ist eine agile Methode, die der Visualisierung von Arbeitsprozessen dient. Der gesamte Workflow eines Projektes wird abgebildet, indem jede zu erledigende Aufgabe auf eine Karte geschrieben und auf einem Kanban Board visualisiert wird. Die entsprechenden Aufgaben werden typischerweise je nach Ausführungsstatus in die Spalten „To Do“, „in Progress“, „in Validation“ und „Done“ geschoben. Auf diese Weise können sich Teammitglieder jederzeit einen Überblick über einzelne Arbeitsschritte und den gesamten Entwicklungsprozess verschaffen.
Nach der Kanban-Methode wird eine Aufgabe nach der anderen bearbeitet und in „Done“ geschoben, bis das Projekt abgeschlossen ist. Wichtig ist zu beachten, dass die Anzahl der Aufgaben in jedem Stadium des Kanban Boards begrenzt ist („Work in Progress“-Limit). Dies dient sowohl der Effizienz als auch der Übersichtlichkeit des Projektes.
Was sind die Gemeinsamkeiten und Unterschiede von Scrum und Kanban?
Die Gemeinsamkeiten von Scrum und Kanban
Beide agilen Methoden funktionieren nach dem Pull-Prinzip, welches für schnelle Ergebnislieferung sorgt und Überlastung vermeidet. Dieses kommt bei Scrum innerhalb des Sprint-Plannings zum Einsatz, bei Kanban findet das Prinzip fortlaufend Anwendung.
Außerdem zeichnen sich die Methoden durch eine sehr ähnliche Zielausrichtung aus, bei welcher eine hohe Transparenz, Flexibilität und die Effizienzmaximierung von Projekten und Prozessen im Vordergrund stehen.
Die Unterschiede von Scrum und Kanban im Überblick
SCRUM
KANBAN
Planung in Iterationen
Kontinuierlicher Entwicklungsprozess
Setzt Teamarbeit voraus
Kann für individuelle Einzelarbeit eingesetzt werden
Scrum Boards werden für jeden Sprint erneuert und sind immer gleich aufgebaut
Kanban Boards werden fortlaufend verwendet und können individuell aufgebaut sein
Begrenzung der Arbeit durch Sprints
Begrenzung der Arbeit durch Work in Progress Limits
Prioritäten und Aufgaben können nur zwischen den Sprints geändert werden
Prioritäten und Aufgaben können jederzeit verändert und angepasst werden
Komplexer durch Vorschriften & Regeln (Meetings, Verantwortlichkeiten etc.)
Flexibler durch Optionalität von Meetings und größeren Gestaltungsspielräumen
Höherer Zeitaufwand durch Planungsmeetings und verschiedene Events
Zeitersparnis (da der gesamte Entwicklungsprozess abgebildet wird, sind weniger Abstimmungen nötig)
Crossfunktionale Teams mit spezifischen Verantwortlichkeiten
Teams können spezialisiert sein, keine Verantwortlichkeiten
Fazit: Scrum oder Kanban – welche agile Methode ist wofür geeignet?
Scrum und Kanban sind keine Methoden, die sich gegenseitig ausschließen – sie können auch kombiniert werden. Beispielsweise können bei einem Entwicklungsprozess mit Scrum auch Kanban Boards verwendet werden. Kanban ist stark auf Visualisierung ausgerichtet, die Scrum-Methode ist jedoch verglichen zu Kanban umfangreicher und setzt Teamarbeit voraus. Scrum eignet sich besonders gut, wenn ein inkrementelles Vorgehen möglich ist und große Projekte in Einzelbestandteile aufgegliedert werden können.
Demnach gilt: Je komplexer das Projekt, desto sinnvoller ist es, nach Scrum zu arbeiten. Durch die Einteilung in Sprints wird der Prozess schlanker, leichter und übersichtlicher.
Kanban kann hingegen auch für kleine Projekte genutzt werden, wie beispielsweise für die Organisation eines Events. Diese agile Methode ist insbesondere zu empfehlen, wenn ein schnelles Reagieren auf neue Aufgaben gefragt ist. Einsatz findet Kanban zum Beispiel bei Produktionsabläufen sowie Testungs-, Fehlerbehebungs- oder Wartungsaufgaben. Hier können Durchlaufzeiten minimiert und der Ablauf kontinuierlich verbessert werden.
Welche agile Methode im Endeffekt die passende ist, hängt jedoch stark vom jeweiligen Projektvorhaben ab. Es lohnt sich also, die Strukturen und den Aufbau des Projektes näher zu durchleuchten und gegebenenfalls eine Testphase der beiden agilen Methoden Scrum und Kanban durchzuführen.
Kontakt
Wenn Sie Fragen zum Thema Scrum und Kanban haben, die agilen Methoden in Ihren Arbeitsprozess etablieren oder eine agile Transformation durchführen möchten, nehmen Sie gerne Kontakt zu uns auf
