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:
3. Unterschiede
Um die Unterschiede der beiden Methoden noch weiter zu untersuchen, wollen wir schauen welche Aspekte optional oder verpflichtend sind.
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.
Interessante Links:
> http://www.extremeprogramming.org/
> http://en.wikipedia.org/wiki/Lean_software_development
> http://www.agilemodeling.com/essays/fdd.htm
> http://en.wikiversity.org/wiki/Crystal_Methods
> http://www.agiledata.org/essays/tdd.html
Dieser Beitrag wurde ursprünglich in unserem Partnerblog vom SCM-Manager Universe Team veröffentlicht. Dort war er in 3 Beiträge aufgeteilt.
Kommentare
Keine Kommentare