04.11.2020
in Methods
Scrum vs. Kanban – So wählen Sie die passende agile Methode für Ihren Einsatzzweck aus
Inhaltsverzeichnis
In den letzten Jahren sind agile Methoden in der Softwareentwicklung immer alltäglicher geworden. Die beiden am weitesten verbreiteten sind Scrum und Kanban. Die “State of Agile” Befragung erhebt schon seit vielen Jahren Daten über die Anwendung von agilen Methoden. Dabei ist es interessant zu sehen, dass sich Veränderungen bei Prioritäten und Zielen nur sehr langsam vollziehen. Schon seit einigen Jahren verwendet die große Mehrzahl von Unternehmen (~75%) Scrum oder Scrum-Hybrid Ansätze. An zweiter Stelle liegen Kanban und „Scrumban“ mit mehr als 15%. Deswegen wollen wir diese beiden Methoden miteinander vergleichen.
Dieser Beitrag wird sich um Scrum und Kanban im Allgemeinen drehen. Detailinformationen zu den beiden Methoden finden sich auf www.scrum.org oder http://limitedwipsociety.ning.com/.
Wieso Agil?
Wieso werden agile Methoden in Projekten verwendet? Laut der aktuellen „State of agile“ Befragung verbesserte eine große Mehrheit der Befragten durch die Anwendung von agilen Methoden ihre Fähigkeit, auf sich ändernde Prioritäten zu reagieren. Bevor man anfängt neue Methoden oder Vorgehensweisen anzuwenden, hat man Erwartungen an das Ergebnis und nachdem man die ersten Erfahrungen gesammelt hat kann man sagen, ob diese Erwartungen erfüllt wurden, oder nicht. Das folgende Bild zeigt die Wichtigkeit von Aspekten und, ob sie durch die Anwendung von agilen Methoden verbessert wurden. (Die Daten stammen aus dem achten State of Agile Bericht, haben sich aber über die Jahre nicht stark verändert.)
Zu sehen ist, dass es für 75% der Unternehmen wichtig ist die „Time to Market“ zu verbessern (blauer Balken). Für 83% der Projekte hat sich diese Kennzahl durch agile Methoden verbessert (gelber Balken). Dieser Zusammenhang kann für alle gezeigten Aspekte beobachtet werden: Wichtige Aspekte haben sich für den Großteil der Projekte verbessert. Die Befragung gibt leider keine Antworten oder Hinweise auf die Gründe, wieso sich für einige Teilnehmer die Aspekte nicht verbessert haben.
Das „agile Manifest“
Es gibt eine Vielzahl von agilen Methoden und Tools. Sie alle haben Gemeinsamkeiten und Unterschiede, aber sie basieren alle auf den selben Prinzipien. Diese sind im “Manifest für agile Softwareentwicklung” niedergeschrieben. Das Manifest legt fest, dass gewisse Aspekte wichtiger sind, als Andere und dass es wichtig ist diese Fakten zu verinnerlichen.
Das agile Manifest sagt beispielsweise, dass es wichtiger ist, schnell auf Änderungen zu reagieren, als einem Plan zu folgen. Außerdem ist ein wichtiger Erfolgsfaktor für agil durchgeführte Projekte, dass Teams die richtige Einstellung haben, um in einem agilen Projektumfeld arbeiten zu können. Ein weiterer wichtiger Rat ist, dass man sich nicht nur auf eine Methode beschränken sollte. Man soll versuchen verschiedene Aspekte von unterschiedlichen Methoden so zu kombinieren, dass die eigenen Bedürfnisse am besten bedient werden. Dabei sollte man sich aber auch immer bewusst sein, dass man mehrere Methoden miteinander kombiniert und nicht mehr nach „der reinen Lehre“ arbeitet.
Da die meisten agilen Methoden auf den gleichen Prinzipien basieren, verfolgen sie ähnliche Ansätze. Einige geben viele Regeln vor, andere lassen viel Freiraum. Das agile Manifest umfasst die grundlegenden Prinzipien, die alle Methoden gemeinsam haben. Jeder Ansatz hat aber seine eigenen Regeln und Vorgehensweisen. Die Herausforderung ist es die Methode, Tools und Regeln zu finden, die am besten zu den eigenen Bedürfnissen passen.
Vergleich von Scrum und Kanban
Nachdem wir die häufigsten Gründe für die Verwendung agiler Ansätze und ihre Grundprinzipien aufgezeigt haben, können wir nun die beiden am häufigsten verwendeten Methoden vergleichen: Scrum und Kanban. Wir möchten einen ersten Einblick in die Denkweise von Scrum- und Kanban-Teams geben und Ähnlichkeiten und Unterschiede der beiden Methoden aufzeigen.
Es wird allgemein behauptet, dass Projekte durch den Einsatz von agilen Methoden schneller abgeschlossen werden können. Das wird erreicht, da bei der Anwendung von Methoden wie Scrum oder Kanban Prozesse optimiert werden. Durch Transparenz sollen Optimierungspotentiale aufgezeigt und dadurch die Effizienz verbessert werden. Beide Methoden setzen voraus, dass die Teams „an Stellschrauben drehen“ und ihre Umgebung anpassen. Sie bieten ein Gerüst aus Regeln in dem die Teams den Spielraum nutzen können. Man kann aber sagen, dass Scrum stärker vorschreibend ist als Kanban.
Auslastung
Die Auslastung der Teams wird in beiden Methoden unterschiedlich reguliert. In Kanban wird die Auslastung (WIP = Work In Progress) direkt begrenzt, da nur eine bestimmte max. Anzahl von Karten je Spalte erlaubt wird. Scrum hingegen reguliert die Auslastung indirekt, indem die Auslastung je Iteration (Sprint) durch das Sprint Backlog begrenzt wird. Dieser Unterschied zeigt sich an dem folgenden Beispiel Board. In Scrum können bis zu 4 Karten parallel bearbeitet werden, da sich 4 Karten auf dem Board befinden. In Kanban hingegen können maximal 2 Karten parallel bearbeitet werden, da in der WIP spalte nur maximal 2 Karten erlaubt sind. In Kanban könnte also sofort mit Task C begonnen werden. Um dann aber mit Task D beginnen zu können, müsste zunächst Task B oder C abgeschlossen werden. Das Scrum Team hingegen könnte sofort mit der Bearbeitung von Task C und D beginnen.
Ansprechzeit für neue Anforderungen
Ein weiterer Unterschied zwischen beiden Methoden ist die Art auf neue Anforderungen zu reagieren. Angenommen man hat die folgende Situation in seinen Scrum und Kanban Projekten und jemand kommt vorbei und möchte die Anforderung E zu den Boards hinzufügen. Wie reagieren die beiden Teams auf den neuen Task?
Das Scrum Team wird üblicherweise so etwas wie „Sorry, aber wir haben uns zu den Tasks A, B, C und D in diesem Sprint committet. Gerne Kannst du E in das Product Backlog legen.“ sagen.
Das Kanban Team wird so etwas sagen: „Natürlich kannst du gerne E an das Board hängen, aber vorher musst du entweder C oder D entfernen. Wir dürfen nämlich nur max. 2 Tasks in „To Do“ haben. Du kannst aber auch gerne warten bis wir mit A oder B fertig sind, dann wird wieder ein Platz frei.“
Die Reaktion auf einen neuen Task ist also davon abhängig, zu welchem Zeitpunkt eine Anforderung auftaucht. In Scrum kann die Ansprechzeit zwischen der Länge eines Sprints und einem Tag (wenn die Anforderung am letzten Tag eines Sprints aufkommt) betragen. Die durchschnittliche Ansprechzeit ist also die halbe Sprintlänge. In Kanban ist die Ansprechzeit genau so lange, wie es dauert freie Kapazität zu bekommen. Das kann entweder unmittelbar (durch das Entfernen einer anderen Karte) sein, oder so lange dauern bis ein anderer Task abgeschlossen wird.
Vergleich
Die nachfolgenden Tabellen werden Gemeinsamkeiten, Unterschiede und die wesentlichen Arbeitsregeln der beiden Methoden zeigen. Dadurch wollen wir deren Stärken und Schwächen zeigen. Außerdem soll der Vergleich dabei helfen, den Ansatz (oder einige Aspekte) zu finden, die man in seinen Projekten verwenden kann.
Gemeinsamkeiten
Beide…
… lassen die Teams entscheiden, wann sie welche Tasks bearbeiten.
… basieren auf fortlaufender und erfahrungsbasierter Prozessoptimierung.
… betonen, dass die Anpassung an Änderungen wichtiger ist, als einem Plan zu folgen.
… sind „lean“ und „agil“.
… beschränken WIP.
… benutzen Transparenz, um Prozessverbesserungen voran zu bringen.
… sind darauf ausgerichtet Software früh und schnell auszuliefern.
… basieren auf selbstorganiserten Teams.
… setzen voraus Arbeit zu unterteilen.
… helfen dabei, durch empirische Daten kontinuierlich den Release-Plan zu optimieren.
Arbeitsregeln
Die unterschiedlichen Ansätze der beiden Methoden zeigen sich am besten an ihren wesentlichen Arbeitsregeln:
| Scrum | Kanban |
|---|---|
| Teile die Organisation in kleine, "Cross-funktionale", sich selbst organisierende Teams. | Visualisiere den Arbeitsprozess:
|
| Unterteile die Arbeit in eine Liste von kleinen, konkreten, Arbeitsergebnissen. Sortiere die Liste nach der Priorität und schätze den relativen Aufwand jedes Teils. | |
| Unterteile die Zeit in kurze Iterationen mit fester Länge, die immer ein potentiell auslieferbares Ergebnis haben. | |
| Optimiere den Release-Plan und aktualisiere die Prioritäten in Abstimmung mit dem Kunden. Mache dies auf Basis der bereits gewonnenen Erkenntnisse aus vorangegangenen Iterationen. | Beschränke die Auslastung (WIP) - gib eindeutig vor wie viele Karten sich in welchem Arbeitsschritt befinden dürfen. |
| Optimiere den Prozess durch Erkenntnisse aus den Retrospektiven am Ende jeder Iteration. | Messe die Durchlaufzeit (= "Lead Time", durchschnittlich benötigte Zeit zur Bearbeitung einer Karte) und verbessere den Prozess, um die Durchlaufzeit so kurz und vorhersagbar wie möglich zu machen. |
Unterschiede
Um die Unterschiede der beiden Methoden noch weiter zu untersuchen, wollen wir schauen welche Aspekte optional oder verpflichtend sind.
| Scrum | Kanban |
|---|---|
| Schreibt festen Zeitrahmen für Iterationen vor. | Zeitrahmen sind optional. Man kann feste Zeitrahmen für Planungen, Auslieferungen und Prozessverbesserungen haben. Diese können Event-gesteuert oder regelmäßig sein. |
| Selbstverpflichtung des Teams zu einem bestimmten Arbeitsumfang für jede Iteration. | Verpflichtung des Teams ist optional. |
| Verwendet Velocity als Kennzahl um Prozessverbesserungen zu planen. | Verwendet Durchlaufzeit als Kennzahl um Prozessverbesserungen zu planen. |
| Schreibt Cross-funktionale Teams vor. | Cross-funktionale Teams sind optional. Teams aus Spezialisten sind erlaubt. |
| Arbeit muss so aufgeteilt werden, dass sie innerhalb eines Sprints erledigt werden kann. | Es wird keine Größe für Arbeitspakete vorgeschrieben. |
| Schreibt ein Burndown Diagramm vor. | Schreibt kein bestimmtes Diagramm vor. |
| Auslastung (WIP) wird indirekt limitiert (per Sprint) | WIP wird direkt limitiert (durch Begrenzung der einzelnen Prozessschritte) |
| Schätzungen werden vorgeschrieben. | Schätzungen sind optional. |
| Erlaubt es nur nach Absprache neue Aufgaben während einer Iteration aufzunehmen. | Neue Aufgaben können immer aufgenommen werden, wenn Kapazität frei ist. |
| Gibt vor, dass ein Sprint Backlog immer genau einem Team gehört. | Ein Kanban Board kann von mehreren Teams oder Individuen geteilt werden. |
| Schreibt 3 Rollen vor. | Schreibt keine Rollen vor. |
| Setzt voraus, dass ein Scrum Board nach jedem Sprint zurückgesetzt wird. | Ein Kanban Board ist persistent. |
| Setzt ein priorisiertes Produkt Backlog voraus. | Priorisierung ist optional. |
Wie wählt man zwischen Scrum und Kanban?
Wie man sehen kann, weisen die beiden Tools grundlegende Ähnlichkeiten auf, unterscheiden sich jedoch in den Details erheblich. Wenn man eine von ihnen oder bestimmte Aspekte verwenden möchten, sollten man sich bewusst sein, dass beide mehr als nur Boards mit vielen Karten sind. Natürlich ist die Verwendung eines Boards ein Anfang, aber es gibt so viel mehr Möglichkeiten, ein Projekt zu verbessern. Wenn man sich an die Regeln und Werkzeuge der Methoden hält, können sie sehr helfen. Beachten sollte man, dass es nicht wichtig ist, sich an eine Methode zu halten. Man kann Aspekte, Tools und Regeln verschiedener Methoden kombinieren, um ein Projektmanagementsystem einzurichten.
Wie sehen Scrum und Kanban nun im wirklichen Leben aus? Wir zeigen ein Beispiel, wie Projekte in den verschiedenen Boards ablaufen. Dies zeigt erneut einige Vor- und Nachteile der beiden Methoden und kann helfen, die Lösung für ein eigenes Projekt zu finden.
Beispiele für Scrum und Kanban im Einsatz
Das folgende Beispiel zeigt nun ein etwas umfangreicheres Projekt: es gibt ein Produkt Backlog mit einigen Karten und einen Bearbeitungsprozess, der aus mehreren Schritten besteht. Dies ist die Ausgangssituation:
- Scrum: Das Team befindet sich gerade im ersten Sprint, in dem die Karten A, B, C, D, E und F bearbeitet werden sollen. A ist bereits erledigt, B bis E werden gerade bearbeitet und F wurde noch nicht begonnen. In den folgenden Sprints wird das Team die Karten G bis N bearbeiten.
- Kanban: Das Team kann bis zu 2 Karten auswählen, die als nächstes in die Bearbeitung übernommen werden sollen. In dem Bereich Entwicklung dürfen maximal 3 Karten hängen (Karten aus beiden Spalten zählen zusammen – in Bearbeitung und erledigt). Nach der Implementierung müssen die Funktionen getestet werden. Mit der Produktivnahme sind die Karten erledigt.
Das Scrum Board wird nach jedem Sprint zurückgesetzt. Das Kanban Board ist fortlaufend.
Nach ein paar Sprints bzw. einfach nach einiger Zeit, könnten die beiden Boards so aussehen:
Das Scrum Team hat im letzten Sprint die Karten K bis N ausgewählt. 3 Karten sind gerade noch in Bearbeitung. Auf dem Kanban Board ist zu sehen, dass N und K gerade noch getestet werden und M schon implementiert wurde, aber noch nicht getestet werden kann.
Tipp: Auf dem Kanban Board muss nicht zwangsweise ein Limit für jede Spalte vorgegeben werden. Die Limits helfen aber dabei zu erkennen, an welcher Stelle ein Engpass vorliegt.
Das Kanban Board mit seinen den Bearbeitungsprozess abbildenden Spalten und den Limits kann dabei helfen den Prozess zu optimieren. Wenn z.B. auffällt, dass oft Karten in der „Done“ Spalte hängen und auf den Test warten, könnte es sinnvoll sein die Testkapazität zu erhöhen, damit mehr Karten parallel getestet werden können. Ziel sollte es sein in jeder Spalte so wenig wie möglich Karten zu erlauben, ohne dass sich Wartezeiten ergeben. Das Scrum Board und die Aufteilung der Aufgaben in Sprints helfen dabei, sinnvolle Pakete zu schnüren und auslieferbare Zwischenprodukte zu produzieren. Jedes Team kann sich, wie bereits erwähnt, die Aspekte raussuchen und miteinander kombinieren, um das am besten passende Vorgehen zu finden.
Weitere agile Tools und Methoden
Neben den beiden Methoden Scrum und Kanban gibt es noch eine Vielzahl von anderen agilen Vorgehensweisen, die als Inspiration oder Beispiel für eine mögliche Umsetzung dienen können. Je mehr man sich in das Thema und unterschiedliche Modelle einliest, desto stärker wird man feststellen, dass agile Methoden auf den gleichen Prinzipien aufbauen (nämlich aus dem agilen Manifest) und dass auch die Umsetzungsansätze ähnlich sind. Folgende Methoden sind ebenfalls weit verbreitet:
- Extrem Programming (XP)
- Lean Software Development
- Feature Driven Development (FDD)
- Crystal Family
- Test Driven Development (TDD)
Fazit
Ein Kanban Board repräsentiert den individuellen Bearbeitungsprozess eines Teams, wohingegen ein Scrum Board immer gleich aufgebaut ist. Außerdem begrenzt Kanban die Zahl der Karten je Spalte direkt, wohingegen Scrum die Arbeitsbelastung indirekt begrenzt, indem die Zahl der Karten im Sprint Backlog begrenzt ist.
Neben den beiden vorgestellten Methoden gibt es noch weitere agile Ansätze. Einige von denen basieren auf Scrum oder Kanban. Ein sehr weit verbreiteter Ansatz ist die Kombination von Extrem Programming und Scrum, da beide sich sehr gut ergänzen. Jedes Team, das Agil arbeiten möchte, muss für sich die Methode(n) und Ansätze finden, die es dabei unterstützen das Projektziel möglichst effizient zu erreichen. Da es keine „One fits all“ Methode für alle Projekte gibt, muss man ausprobieren und variieren, um die beste Lösung zu finden.
Jetzt Newsletter abonnieren
Verpassen Sie nicht die neusten Informationen zur Digitalen Transformation, Ankündigungen von Produktneuheiten und Sonderaktionen.
