In meinem letzten Artikel habe ich einen kleinen Vergleich zwischen Scrum und Kanban angestellt und einige Gemeinsamkeiten und Unterschiede zwischen den beiden Methoden aufgezeigt. Diesen Vergleich möchte ich dieses Mal gerne fortführen und einige weitergehende Punkte beleuchten. Darunter u.a. die Verteilung von Kanban-Tafeln auf Teams und der Arbeit an mehreren Produkten zur selben Zeit.
Dieser Artikel baut auf dem vorherigen auf. Sollten Sie den ersten Teil des Artikels bisher noch nicht gelesen haben, so wäre es daher nicht verkehrt dies noch nachzuholen, bevor Sie weiterlesen.
Wie im ersten Teil erwähnt durchläuft ein Scrum-Board im Laufe einer Iteration immer wieder denselben Zyklus, und wird am Ende der Iteration wieder zurückgesetzt. Dies hat als Konsequenz, daß eine Anforderung, die mittels Scrum realisiert wird, nicht länger dauern darf als der Sprint lang ist. Grössere Happen müssen also in mehrere kleine aufgeteilt werden.
Kanban jedoch kennt von Haus aus keine Iterationen. Deshalb macht ein Kanban-Board auch keinen solchen Zyklus durch. Items laufen ohne Unterbrechung von links nach rechts durch die Tafel, weswegen ein Kanban-Board die meiste Zeit ziemlich gleich aussehen wird. Die Zahl der Items in den verschiedenen Spalten ändert sich nur immer ein wenig. Bei Spalten, die auf eine bestimmte Zahl von Einträgen beschränkt sind, ist diese Fluktuation manchmal sogar so gut wie nicht vorhanden (sobald ein Item die Spalte verlässt wird auch eins nachgeschoben).
Dies ist aber nicht der einzige Unterschied der beiden Tafeln: Bei Scrum gibt die Tafel genau die Arbeit eines Teams wieder. Es darf zwar jeder die Tafel sehen, aber nur das Team darf sie auch verändern. Das Team ist cross-funktional besetzt. D.h. alle Fähigkeiten, die benötigt werden, um den aktuellen Sprint zu einem erfolgreichen Ende zu führen, sind im Team enthalten.
Bei Kanban sind hier von vorneherein keine solchen Schranken gesetzt. Cross-funktionale Teams sind hier optional. Auch die Beschränkung auf ein einziges Team ist nicht Voraussetzung. Stattdessen bezieht sich eine Kanban-Tafel auf einen bestimmten Workflow. Ein Workflow kann prinzipiell jedoch auch mehrere Teams umfassen. Eine Kanban-Tafel darf daher auch von mehreren Teams geändert werden.
Um es sich besser vorstellen zu können, hier das Ganze nochmal graphisch dargestellt:
Abbildung 1 zeigt eine typische Scrum-Tafel. Sie ist immer im Besitz eines einzigen Teams. Alle Spalten der Tafel werden ausschließlich durch dieses Team geändert.
Abbildung 2 zeigt eine Kanban-Tafel. Sie ist nicht nicht im Besitz nur eines einzigen Teams. Stattdessen spiegelt sie einen Workflow wieder (hier ganz einfach „Todo -> In Bearbeitung -> Fertig“). Die einzelnen Schritte des Workflows können jedoch beliebig auf Teams aufgeteilt werden.
In diesem Beispiel hier wird z.B. die Spalte „Todo“ von nur einer einzigen Person verwaltet (das könnte z.B. eine Art Projektleiter oder Product Owner sein). Für die restlichen Spalten ist dagegen ein anderes Team zuständig. In der Realität würde man die Tafel aus Abbildung 2 wahrscheinlich noch etwas erweitern, um damit wirklich sinnvoll arbeiten zu können. Links der Spalte 2 „Todo“ könnte man etwa noch eine Spalte „Backlog“ einführen, eine Art ungeordneter Wunschliste ohne Priorisierung, die als Sammelbecken für alle zukünftigen Anforderungen dient. Soll eine der Anforderungen daraus realisiert werden, so wird sie einfach nach „Todo“ verschoben.
Natürlich kann man den Workflow noch auf viele weitere Arten auf Teams verteilen. Bei einer hohen Zahl von Items könnte es etwa sinnvoll sein, daß sich zwei oder mehr Teams eine Spalte teilen. Aber auch der bei Scrum eingesetzte Fall (ein Team verwaltet die komplette Tafel) ist möglich.
Eine Scrum-Tafel ist daher eigentlich nichts anderes als der Spezialfall einer Kanban-Tafel.
Ganz ähnlich verhält sich der Fall auch mit der Schätzung von Items, bzw. ihren Durchlaufzeiten auf der Tafel:
Bei Scrum nutzt man die Länge einer Iteration als Bezugsrahmen. D.h., das Team schätzt alle neu ankommenden Anforderungen und selektiert davon immer genau so viele, wie es in dieser Iteration (= Sprint) umsetzen kann. Zählt man die Schätzwerte aller Anforderungen eines Sprints zusammen, so erhält man den „Gesamtwert“ eines Sprints (in Function Points). Man nennt diese Zahl auch „Velocity“. Diesen Wert kann man dann über mehrere Sprints hinweg fortschreiben und vergleichen. Er dient dem Team als Anhaltspunkt bei der Sprintplanung wenn es darum geht, Anforderungen für den nächsten Sprint zu selektieren.
Bei Kanban hingegen ist dies etwas anders. Da es von Haus aus keine Iterationen gibt, und auch die Beschätzung neuer Anforderungen nicht zwingend notwendig ist, gibt es auch keinen festen Bezugsrahmen, den man zur Berechnung der Velocity verwenden könnte. Stattdessen muß man sich hier anders behelfen. Manche Teams gruppieren etwa Anforderungen in sog. „MMF“ (Minimum Marketable Features). Dann messen sie die Zeit die es braucht, alle Anforderungen dieser Gruppe umzusetzen. Auf dieser Basis können später dann auch Service Level Agreements (SLAs) arbeiten. „Wir liefern ein MMF immer in max. 10 Tagen aus“ wäre ein Beispiel hierfür.
Andere Teams brechen Anforderungen (ohne sie explizit zu beschätzen) in etwa gleich große Stücke auf und messen anschließend die Durchlaufzeit. Bezogen auf einen festen (beliebig zu wählenden) Zeitraum kann man dann auch hier wieder eine „Velocity“ berechnen („10 Anforderungen pro Monat).
Die Möglichkeiten sind schier unbegrenzt. Man kann sich natürlich jederzeit wieder einen festen Bezugsrahmen einführen, und mit Schätzungen und/oder Iterationen wieder auf eine Scrum-ähnliche Methode kommen. Am besten ist, man probiert verschiedenes aus und nimmt sucht sich dann das aus, das sich für den aktuellen Fall am geeignetsten ist.
Gemeinsam ist den beiden Methoden jedoch die Möglichkeit, ein und dasselbe Team an mehreren Produkten gleichzeitig arbeiten zu lassen. In Scrum hat man zwar oft den Eindruck, daß das nicht geht (da ein Product Backlog sich immer auf genau ein Produkt bezieht). Allerdings könnte man ein Team ja durchaus an mehreren Product Backlogs gleichzeitig arbeiten lassen. Die Reihenfolge der Abarbeitung (hintereinander, abwechselnd pro Sprint, gleichzeitig etc.) wird dabei vom Team gemeinsam mit dem/den Product Owner(n) festgelegt.
Bei Kanban ist das Ganze noch wesentlich einfacher: Eine Tafel gehört ja immer zu einem Workflow, nicht zu einem Produkt. Es ist daher ohne weiteres möglich, mehrere Produkte zur selben Zeit über denselben Workflow zu fahren. Zur besseren Unterscheidung könnte man noch verschiedenfarbige Karten nehmen, oder man führt mehrere Zeilen ein (eine Zeile pro Produkt). Ansonsten aber sind keine weiteren Änderungen am Prozess notwendig.
Soweit fürs erste der Vergleich zwischen Scrum und Kanban. Hier die Ergebnisse nochmal in einer Tabelle kurz zusammengefasst:
| Scrum | Kanban |
| Iterationen mit fester Länge vorgeschrieben. | Iterationen sind rein optional. Feste Länge nicht zwingend, auch Ereignissteuerung möglich. |
| 3 Rollen fest vorgesehen (Product Owner, Scrum Master und Team). | Initial keine Rollen vorgeschrieben. |
| Team wählt eine Menge an Anforderungen für einen Sprint aus und verpflichtet sich, diese auch umzusetzen. | Keine Iterationen, daher auch keine festen Zusagen notwendig. Es besteht aber die Möglichkeit, SLAs einzuführen. |
| Velocity (geleistete Arbeit pro Sprint) als primärer Parameter für Planung und Verbesserung. | Durchlaufzeit als primärer Parameter. |
| Product Backlog ist (absteigend) nach Geschäftswert sortiert. | Priorisierung optional. |
| Einträge im Product Backlog müssen in max. einem Sprint realisierbar sein. Tasks auf dem Scrum Board sind <= 1 Tag. | Anforderungen dürfen beliebig groß sein. |
| Keine Änderungen an den Anforderungen während eines Sprints möglich. Neue Anforderungen werden frühestens mit der nächsten Sprintplanung übernommen. | Neue Anforderungen können prinzipiell zu jeder Zeit eingebracht werden (wenn ein Slot frei ist). |
| Eine Scrum-Tafel wird nach jedem Sprint zurückgesetzt. | Eine Kanban-Tafel wird kontinuierlich fortgeschrieben. |
| Ein Sprint Backlog (und damit auch eine Scrum-Tafel) gehört immer genau einem Team. | Eine Kanban-Tafel kann beliebig auf Teams aufgeteilt werden. |
| Cross-funktionale Teams vorgeschrieben (und auch notwendig, da ein Sprint Backlog nur von einem einzigen Team bearbeitet wird). | Cross-funktionale Teams optional. Auch mehrere (spezialisierte) Teams pro Workflow möglich. |
Wenn man sich diese Tabelle so ansieht, dann erkennt man auch recht gut, wie Scrum und Kanban eigentlich zusammenhängen: Kanban und Scrum schließen sich nicht gegenseitig aus. Ganz im Gegenteil: Da jede Regel in Scrum ein Spezialfall einer Kanban-Regel ist, ist auch Scrum eigentlich nichts weiter als ein Spezialfall von Kanban.
Scrum ist also eine von (wahrscheinlich unendlich) vielen Möglichkeiten Kanban zu machen…
BFI
Wird geladen ...