Agiles Projektmanagement im Close Up: Scrum vs. Kanban

Eines der Schlüsselelemente im Projektmanagement ist die Auswahl einer geeigneten Projektmanagementmethode. Ist von Softwareentwicklung die Rede, fallen fast immer auch Sätze wie "Wir sind agil", "Wir arbeiten nach der Kanban-Methode" oder "Wir sind Scrum-Ninjas". Während es kein Problem ist, die Unterschiede zwischen traditionellen und agilen Methoden in der Verwaltung von Projekten zu unterscheiden, kann das Verstehen der Diskrepanzen zwischen den Scrum- und Kanban-Methoden für viele durchaus problematisch sein.

Wir haben uns daher dazu entschieden, dass es einer Gegenüberstellung der Methoden Scrum und Kanban bedarf. Wie funktionieren die Methoden? Wofür sollte man sich bestmöglich entscheiden?

Agil, Scrum, Kanban… ist das nicht alles dasselbe?

Wer sich mit den verschiedenen Projektmanagement Methoden noch nicht allzu sehr vertraut gemacht hat, hat möglicherweise den Eindruck, die Begriffe „Scrum“ und „Agil“ beschreiben ein und dieselbe Sache. Das ist jedoch nicht ganz richtig.

Agil meint einen Ansatz, der – angelehnt an das Agile Manifest - auf eine Reihe von Methoden und Praktiken verweist. Im Prinzip beschreibt es der Begriff „Agilität“ schon sehr gut: agil und flexibel bleiben, auf Veränderungen reagieren, sich anpassen können und selbstbestimmt arbeiten.

Scrum hingegen bezeichnet eine spezielle Methodik, im Zuge derer der agile Ansatz angewendet wird. Scrum gilt also – ebenso wie Kanban – als Methode des agilen Projektmanagements. Oberflächlich betrachtet scheinen auch die beiden Methoden ein und dieselbe Vorgehensweise zu verfolgen. Schließlich geht es sowohl bei Scrum als auch bei Kanban vor allem darum, offene Aufgaben in Richtung „erledigt“ zu befördern. Außerdem findet in beiden Praktiken ein „Board“ Verwendung, welches so ziemlich das auffälligste Instrument ist. Es gibt jedoch einige wesentliche Unterschiede...

Scrum

Scrum ist ein Framework für die Teamzusammenarbeit, das dem gesamten Team hilft, an komplexen Produkten zu arbeiten und auf dem gesamten Weg kreativ zu bleiben. Ein Blick in den Scrum Guide hilft, das Konzept ein wenig besser zu verstehen:

Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz "Empirie". Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Scrum verfolgt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit zu optimieren und Risiken zu kontrollieren.

Das bedeutet, dass die Maßnahmen, die das Team in Zukunft ergreifen wird, größtenteils auf den Erfahrungen basieren, die während des laufenden Prozesses gemacht wurden. Innerhalb dieses Ansatzes impliziert Scrum sogenannte Sprints (iterativ) - regelmäßige Iterationen, die jeweils mit einem „fertigen“ Zwischenergebnis / -produkt (inkrementell) enden. Dieser „Step-by-Step“ -Ansatz minimiert auch das Risiko experimenteller Ansätze (jedes Sprint-Ergebnis ist offen für das Feedback aller Beteiligten), was wiederrum ein Umfeld schafft, in dem auch neue Ideen berücksichtigt werden können.

Scrum Artefakte

Scrum ist bestrebt, Flexibilität und Transparenz zu erhalten, um eine bessere Feedbackkultur zu schaffen und Änderungen bzw. Anpassungen innerhalb des Prozesses zu ermöglichen. Schlussendlich soll so eine voll funktionsfähige Software (oder ein anderes Produkt) entstehen, die den Kunden einen Mehrwert bringt. Dazu arbeitet Scrum mit sogenannten Events (regulären Meetings) und drei Artefakten:

1. Product Backlog

Das Product Backlog ist eine Liste aller Anforderungen für das Endprodukt, die vom Product Owner erstellt, verwaltet und priorisiert wurden. Dabei handelt es sich sozusagen um seinen eigenen „kleinen“ Bereich, in dem er alles sammelt (Funktionen, Verbesserungen, Korrekturen usw.), was im Zuge der Produktentwicklung erledigt werden muss. Die Struktur ist recht einfach: Die wichtigsten Punkte stehen ganz oben auf der Liste.

Das Product Backlog ist weder unveränderbar, noch ist es von Anfang an vollständig ausgearbeitet. Eigentlich ist es nie wirklich vollständig, sondern entwickelt sich zusammen mit dem Produkt.

2. Sprint Backlog

Die gesamte Product-Backlog-Strategie ist eigentlich recht simpel, nicht wahr? Allerdings befinden sich auf der Backlog-Liste ziemlich schnell sehr viele Anforderungen. Wie viele dieser Anforderungen müssen während des nächsten Sprints umgesetzt werden? Genau dafür ist das Sprint Backlog gedacht. Das Sprint Backlog ist sozusagen eine kleinere Version eines Produkt Backlogs, das ausgewählte Elemente enthält, die beim nächsten Sprint abgearbeitet werden müssen.

Das Sprint Backlog ist eine Prognose des Entwicklungsteams darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird, sowie über die erforderliche Arbeit, um diese Funktionalität in einem fertigen [„Done“] Inkrement zu liefern.

3. Produktinkrement

Wie bereits erwähnt, ist das Inkrement das Ergebnis eines jeden Sprints. Dies bedeutet, dass es sich auch um die Summe aller Product-Backlog-Einträge handelt, die während der vorausgehenden Sprints implementiert wurden. Am Ende muss das Inkrement (gemäß der Definition des Teams) fertig sein – also „Done“.

Wie all diese Artefakte zusammenwirken und wie der gesamte Scrum-Prozess organisiert ist, lässt sich am besten mit einem Scrum-Board verdeutlichen.

Das Scrum-Team

Scrum definiert drei grundlegende Rollen:

1. Der Product Owner

Der Product Owner (PO), ist dafür verantwortlich, dass das Team das Bestmögliche aus dem Produkt herausholt.

Das Product Backlog liegt im Verantwortungsbereich des PO! Er erstellt, strukturiert, erweitert, ändert und verwaltet während des gesamten Projektprozesses alle Elemente des Product Backlog. Er priorisiert alle Anforderungen und niemand außer ihm kann an dieser Struktur etwas ändern. Die Person, die diese Rolle einnimmt, ist schlussendlich auch für den Erfolg oder Misserfolg des Projekts verantwortlich.

2. Das Entwicklungsteam („Das Team“)

Das Ziel der Entwickler ist es, das Sprint Backlog abzuarbeiten, um schließlich ein fertiges Inkrement zu erhalten, das bis zum Ende präsentiert werden kann. Wie alle Beteiligten trifft auch das Entwicklungsteam alle Entscheidungen, die den eigenen Geltungsbereich betreffen, selbst - insbesondere über die Aufgabenverteilung.

Ein Scrum-Entwicklungsteam muss vielseitig kompetent, aber dennoch leicht zu koordinieren sein, weshalb auch die Größe des Teams von nicht unwesentlicher Bedeutung ist. Um beide genannten Qualitäten zu gewährleisten, werden Entwicklungsteams einer Größe von 3-9 Mitgliedern empfohlen.

3. Der Scrum Master

Die letzte der drei vorgegebenen Rollen ist der Scrum Master, der dem gesamten Team dabei hilft, die Prinzipien von Scrum zu verstehen und zu auch umzusetzen.

Interessant ist, dass das gesamte Scrum-Team von keiner übergeordneten Instanz geleitet wird. Das Scrum-Team ist selbstorganisierend und bleibt dynamisch.

Ablauf und Scrum-Ereignisse/Events

Bringen wir nun alle Artefakte und Rollen in einen Kontext, indem wir uns das eigentliche Verfahren genauer ansehen. Das Herzstück von Scrum sind (wie bereits erwähnt) die Sprints. Ein Sprint ist eines von 5 Scrum-Events, alle weiteren können als Teilbereiche des Sprints gesehen werden:

Ein Sprint sollte nicht länger als einen Monat dauern. Die tatsächliche Länge hängt von einzelnen Faktoren ab - wie den individuellen Fähigkeiten innerhalb des Entwicklungsteams, der Komplexität der Aufgaben usw. -, wobei kürzere Intervalle von (zwei Wochen) häufig bevorzugt werden, um Probleme schneller aufzudecken.

Das Sprint Planning soll im Vorfeld definieren, was das Team in der vorgegebenen Zeit des Sprints leisten kann. Das Ereignis markiert also den Start des Sprints. Basierend auf den vom Product Owner festgelegten Prioritäten und den Zeitschätzungen für bestimmte Aufgaben, wählt das Team eine bestimmte Anzahl von Elementen aus dem Backlog aus und definiert ein Sprint-Ziel. Es ist äußerst wichtig, dass das Team versteht, was machbar ist und was nicht, da es bis zum Ende des Sprints keine Änderungen geben sollte.

Nachdem die Planung abgeschlossen ist, beginnt das Team mit der Umsetzung der für das Inkrement ausgewählten Anforderungen. Die Arbeitsprozesse werden durch die Verwendung eines Scrum-Boards vereinfacht, mit dem sich Backlog, Aufgaben und Ressourcen verwalten lassen. Arbeitsabläufe und Verantwortlichkeiten innerhalb des Teams bleiben somit transparent für alle. Das zentrale Ereignis während der Sprints ist das sogenannte Daily Scrum – ein täglich abgehaltenes 15-minütiges Meeting zur Planung der kommenden 24 Stunden, in dem auch mögliche Hindernisse und Probleme angesprochen werden.

All tasks are „Done“? Während der Sprint Review kann den Stakeholdern schließlich das fertige Product Increment gezeigt werden. Bei diesem Event wird für gewöhnlich auch das Product Backlog aktualisiert und diskutiert, was als Nächstes zu tun ist.

Schlussendlich markiert die Sprint Retrospektive das Ende des Sprints. Diese wird in der Regel vom Scrum Master durchgeführt, welcher sowohl positive als auch negative Aspekte des Prozesses beleuchtet. Auch Ideen zur Optimierung der Prozesse sollen im Rahmen der Sprint Retrospektive diskutiert werden.

Und mit dem Abschluss des Sprints kommt schon der Startschuss für den nächsten...

Scrum in Kürze

In acht einfachen Schritten gelingt der Start ins Projektmanagement mit Scrum:

1. Downloade den offiziellen Scrum Guide als Leitfaden.
2. Verteile die Rollen: Product Owner, Scrum Master und Entwicklungsteam. Hinweis: Scrum funktioniert mit kleinen, funktionsübergreifenden, selbstorganisierten Teams (mit bis zu 9 Mitgliedern).
3. Erstelle ein Scrum Board. Ein schlichtes Whiteboard oder unkompliziert in Stackfield – beides ist möglich. Beides wird für mehr Transparenz während der Sprints sorgen.
4. Erstelle das Product Backlog. Dort werden alle Anforderungen aufgelistet und priorisiert. Hinweis: Der Product Backlog wird fortlaufend gepflegt.
5. Plane den ersten Sprint. Relevante Anforderungen aus dem Product Backlog, aus denen schlussendlich ein fertiges Inkrement entstehen soll, wandern hierfür in den Sprint Backlog. Hinweis: Sprints sollten die Dauer von 4 Wochen nicht überschreiten.
6. Integriere Daily Scrums. Die täglichen Meetings während den Sprints sollen dem Team innerhalb von 15 Minuten die wichtigsten Updates liefern. Hinweis: Wir empfehlen einen festen Ort für das Daily Scrum, an dem sich alle Mitglieder jeden Tag zur selben Uhrzeit treffen. Das ist einfach und bringt Routine.
7. Halte eine Sprint Review ab. Hier wird das Inkrement und die Updates für den Product Backlog besprochen.
8. Halte eine Sprint Retrospektive ab. Dabei zielt das Team darauf ab, die Prozesse zu optimieren.

Kanban

Im Gegensatz zu Scrum hat Kanban nur sehr wenige Regeln:

• Visualisierung des Workflows
• Begrenzung der gleichzeitig in Arbeit befindlicher Aufgaben (Work-In-Progress, kurz: WIP)
• Messung der Durchlaufzeit zur Verbesserung der Prozesse

Arbeit Step by Step

Die Projektmanagementmethode gibt nur sehr wenig Struktur vor – das Team verfolgt lediglich das Ziel, die für die Fertigstellung eines Projekts erforderliche Zeit zu verkürzen. Dabei dreht sich alles eindeutig um die Visualisierung der Arbeitsprozesse und um die Begrenzung der Work-In-Progress. Indem also eine Aufgabe nach der anderen abgearbeitet wird, soll Ineffizienz aufgrund von Multitasking verhindert werden.

Visualisierung mit Kanban Board

Das Herzstück der Methode ist das sogenannte Kanban Board, welches den gesamten Workflow strukturiert abbildet. Für jede Aufgabe werden individuelle Karten (Kan) erstellt, die den Stand des Projektes innerhalb eines Gefüges von Prozessschritten (z.B. Backlog, To Do, WIP, Testing, Done) visualisiert (Ban). Die Grundstruktur von Scrum und Kanban Board ist also grundsätzlich sehr ähnlich. Sehen wir uns das Kanban Board also genauer an:

Der Workflow in der Kanban-Methode lässt sich als kontinuierlicher Fluss beschreiben. Die Beteiligten picken sich eine Karte nach der anderen heraus, arbeiten sie ab und so wandert im Zuge des Projekts eine Anforderung nach der anderen in die „Done“-Spalte, bis das Projekt beendet ist. Der Workflow ist also fortlaufend – anders als bei Scrum, denn hier wird nach jedem Sprint ein Cut gemacht, „auf Reset gedrückt“ und ein neuer Sprint mit neuem Ausgangsprodukt gestartet. Wie aber behält ein Team bei Kanban den Überblick? Ganz einfach: Die Work-In-Progress-Aufgaben sind auf eine gewisse Anzahl begrenzt – es müssen also erst Aufgaben abgeschlossen werden, bevor neue begonnen werden könnten.

Projektmanagement frei und flexibel gestaltbar

Anders als bei Scrum schreibt Kanban keine speziellen Rollen und keine festen Meetings vor. Auch gibt es keine Vorschriften in Bezug auf Iterationen. Änderungen und neue Anforderungen können also jederzeit und unmittelbar in die Bearbeitung mit einfließen, da keine starren Vorgaben bestehen, die eingehalten werden müssen.

Kanban in Kürze

• Kreiere einen Backlog. Führe eine fortlaufende Liste mit allen Anforderungen an das Projekt.
• Erstelle das Kanban Board. Versuche einen perfekten Workflow für deine Prozesse zu finden und diesen optimal zu visualisieren. Die Schritte/Statusspalten können je nach Bedarf angepasst werden. Das Board sollte aber mindestens aus „To Do“, „WIP“ und „Done“ zusammengesetzt sein.
• Lege dein WIP-Limit fest.
• Überprüfe den Fortschritt und versuche die Durchlaufzeit weitestgehend zu verkürzen.

Scrum vs. Kanban: Welche Methode ist die beste Wahl?

Beide Projektmanagementmethoden verfolgen im Prinzip das gleiche Ziel: Das Projekt soll auf möglichst effiziente Weise erfolgreich abgeschlossen werden. Dabei basieren sowohl Scrum als auch Kanban auf einem inkrementellen Ansatz, d.h. die Prozesse gehen Schritt für Schritt vonstatten und die Arbeit wird jeweils auf andere Art und Weise eingegrenzt – bei Scrum in Form von Sprints, bei Kanban mit einem WIP-Limit.

Grob betrachtet ist die komplexere Methode mit den meisten Regelungen Scrum, was jedoch nicht bedeutet, dass Kanban immer der stressfreiere Weg ist.

Scrum kommt mit einigen Regeln und Einschränkungen (Artefakte, Rollen, Events). Die Kanban-Methode erfordert zunächst nichts weiter, als die Möglichkeit, Prozesse visuell darzustellen – ob digital oder analog (Whiteboard). Scrum schafft jedoch klare Strukturen, indem es spezielle Rollen vorgibt: den Product Owner (definiert die Vision und die Prioritäten des Produkts), das Entwicklungsteam (implementiert alle Produktelemente) und den Scrum Master (versucht, alle Hindernisse für die Implementierung zu beseitigen und stellt sicher, dass der Workflow effizient bleibt). Dagegen gibt es bei Kanban keine klare Rollenstruktur.

Im Jahr 2018 verfolgten bereits 46% der vom Project Management Institute befragten Organisationen einen agilen oder hybrid agilen Ansatz. Hybride Methoden sind in der Tat keine Seltenheit – viele Teams verwenden hybride Modelle, die von Scrum und Kanban beeinflusst sind. Dies ermöglichen nicht zuletzt fortschrittliche Projektmanagement Tools, die sich einfach an die verfolgte Methodik anpassen lassen. Empfehlenswert ist, sich mit den „Standardoptionen“ vertraut zu machen und den Ansatz zu verfolgen, der sich am besten mit den Projekten vereinen lässt. Nicht immer ist dieser Ansatz das strikte Verfolgen einer einzelnen Methode.

Diese Faktoren spielen bei der Wahl eine Rolle

Projekttyp

Weist das Projekt einen hohen Grad an Komplexität auf? Sind die Abläufe über Sprints von mindestens zwei Wochen planbar? Steht das Produkt in der Entwicklung mit einigen unbekannten Variablen, deren Aufwand und Risiko noch nicht abgeschätzt werden kann? Gilt es ein Produkt in seiner bestmöglichen Form zu entwickeln? In diesen Fällen ist Scrum eine gute Wahl. Scrum bietet in der Tat eine gute Möglichkeit, Ideen und neue Ansätze zu integrieren ohne ein zu hohes Risiko einzugehen: Ein Misserfolg oder unüberwindbares Problem ist nach einem Sprint erkennbar, und kostet dem Projekt nur diese eine Iteration bzw. ein Inkrement. Im Zentrum von Scrum steht das Erforschen, Experimentieren und die Risikominimierung. Teams suchen nach der bestmöglichen Lösung und diese findet sich meist auf dem Weg selbst.

Ist es dagegen das Hauptziel des Teams, agile Methoden zu nutzen, um Transparenz zu schaffen und Prozesse fließend und effektiv zu gestalten, sollte Kanban ins Auge gefasst werden. Kleine Projekte mit geringer Komplexität sind mit Kanban gut bedient, ebenso wie Projekte, bei denen das Endergebnis kein Produkt ist. Kanban funktioniert auch gut um generell Arbeitsabläufe zu strukturieren. Administrative Aufgaben, Anfragen von Kunden oder schlichtweg die anfallenden Arbeiten in Kanzleien beispielsweise – diese Arbeiten sind nur schwer zu planen und es gibt kein Produktziel, das eine Entwicklung oder gar Inkremente erfordert. In solchen Fällen ist es das alleinige Ziel, die Arbeiten schnell und organisiert zu erledigen (ohne sich zu verzetteln), womit Kanban die geeignete Wahl wäre.

Art des Teams

Scrum erfordert eine Teamarbeitsgemeinschaft. Es werden die Rollen der Entwickler, des Product Owners und des Scrum Masters beschrieben, die ein gemeinsames Ziel haben – das fertige Endprodukt. Es gibt auch Vorgaben für die Größe des Teams, um zu garantieren, dass dieses optimal zusammenarbeiten kann und sich die individuellen Fähigkeiten der Beteiligten ergänzen.

In Kanban ist keine Teamstruktur erforderlich und womöglich gibt es nicht einmal ein Team mit einem gemeinsamen Ziel. Kanban illustriert lediglich den Workflow und nutzt WIP-Limits, um Ineffizienz zu vermeiden.

Zeitliche Strukturierung

Es gibt eine Art Vereinbarung in Scrum, die den Sprintzustand betrifft. Die für den Sprint ausgewählten Anforderungen werden sozusagen „eingefroren“ und haben mit dem Sprintziel – dem Inkrement – eine feste Deadline. Änderungen sind daher nicht vorgesehen und sollten vermieden werden, um das Inkrement nicht zu gefährden.

Kanban geht allerdings davon aus, dass Änderungen jederzeit möglich sind. Es muss also nicht mit einem Iterationsrhythmus abgestimmt werden, wenn eine Anforderung erfüllt werden soll. Hier liegt eine Art Pull-System vor, bei dem die zu erledigenden Aufgaben sofort nachrücken und in Angriff genommen werden, wenn die vorherige Abgeschlossen ist.