So geht „Agile“: Scrum vs. Kanban

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 aus 2013 hat zum Beispiel ergeben, dass die große Mehrzahl von Unternehmen (~60%) Scrum oder Scrum-Hybrid Ansätze anwenden. An zweiter Stelle liegen Kanban und „Scrumban“ mit mehr als 10%. Im Vergleich zur Befragung in 2012 hat die Nutzung von Kanban am stärksten zugenommen. Deswegen wollen wir diese beiden Methoden miteinander vergleichen.

Dieser Beitrag wird sich um Scrum und Kanban im Allgemeinen drehen. Detailinformationen zu den beiden Methoden findet ihr z.B. auf www.scrum.org oder http://limitedwipsociety.ning.com/.

Wieso Agil?

Wieso werden agile Methoden in Projekten verwendet? Laut der 2013er „State of agile“ Befragung hat eine große Mehrheit der Befragten durch die Anwendung von agilen Methoden eine schnellere Abschlusszeit (~73%), wohin gegen nur 6% beklagten, dass Projekte länger gedauert haben.
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.

Laut Befragung ist es für 75% der Teilnehmer wichtig 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“ nieder geschrieben. 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 alle Teilnehmer 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. Um diese zu unterstützen, werden wir die beiden am weitesten verbreiteten Methoden detaillierter vorstellen.

Vergleich von Scrum und Kanban

Es wird allgemein behauptet, dass Projekte durch den Einsatz von agilen Methoden schneller abgeschlossen werden können. Das wird erreicht, da deren Verwendung 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, wie sie auf neue Anforderungen reagieren. Angenommen du hast die folgende Situation in deinem Scrum und Kanban Projekten und jemand kommt vorbei und möchte die Anforderung E zu deinen 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 dir Gemeinsamkeiten, Unterschiede und die wesentlichen Arbeitsregeln der beiden Methoden zeigen. Dadurch wollen wir deren Stärken und Schwächen zeigen. Außerdem soll dir der Vergleich dabei helfen den Ansatz (oder einige Aspekte) zu finden, die du in deinen Projekten verwenden kannst.

1. 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.

2. Arbeitsregeln
Die unterschiedlichen Ansätze der beiden Methoden zeigen sich am besten an ihren wesentlichen Arbeitsregeln:

ScrumKanban
Teile deine Organisation in kleine, "Cross-funktionale", sich selbst organisierende Teams.Visualisiere den Arbeitsprozess:
  • Unterteile Arbeit in Teile, schreibe jeden Teil auf eine Karte und hänge diese an die Wand.
  • Verwende beschriftete Spalten, um zu zeigen wo sich jeder Teil im Arbeitsprozess befindet.
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.

3. Unterschiede
Um die Unterschiede der beiden Methoden noch weiter zu untersuchen, wollen wir schauen welche Aspekte optional oder verpflichtend sind.

ScrumKanban
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 Geschwindigkeit als Kennzahl um Prozessverbesserungen zu planen.Verwendet Durchlaufzeit als Kennzahl um Prozessverbesserungen zu planen.
Schreibt Cross-funktionale Teams vor.Cross-functionale 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 2 Regeln vor.Schreibt keine Regeln 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.

Grundlegend sind Scrum und Kanban ähnlich, aber in einigen Details unterscheiden sie sich. Diese Unterschiede wollen wir anhand eines etwas komplizierteres Beispiels zeigen.

Ein etwas komplizierteres Beispiel

Das folgende Beispiel zeigt nun ein etwas umfangreicheres Projekt: es gibt ein Product 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 sollen die Karten A, B, C, D, E und F bearbeitet werden. 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, oder 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 Srum 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 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 sie 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:

  • Extream Programming (XP)
  • Lean Software Development
  • Feature Driven Development (FDD)
  • Crystal Familie
  • 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 Extream 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.

Diesen Beitrag teilen

Kommentare

Daniel Huchthausen
Consultant
Wenn er nicht gerade die Wildnis erkundet, beschäftigt sich Daniel mit Themen wie Qualitätssicherung, Testen oder PM-Methoden.