Scrum vs. Kanban (1/2)

In der letzten Zeit höre ich öfter etwas über Kanban. Oft auch verbunden mit der Frage „macht ihr noch Scrum, oder seid ihr schon auf Kanban umgestiegen?“.

Teilweise hat man den Eindruck, Kanban sei so etwas wie der „Nachfolger“ zu Scrum.
Dem ist jedoch nicht so. Ganz im Gegenteil. Beide basieren auf denselben Ideen. Ein ausführlicher Vergleich findet sich z.B. hier. Damit Sie dort nicht alles im Detail nachlesen müssen, hier eine kurze Zusammenfassung.

Wenn man sich Projektmanagementmodelle ansieht, so kann man sie z.B. danach klassifizieren, wieviele Regeln und Vorschriften sie beinhalten. Das eine Extrem wäre, daß für alles eine Regel existiert. Dies bedeutet, der Anwender muß (darf) niemals sein Gehirn einschalten, da jede mögliche Entscheidung bereits durch das Modell abgedeckt ist. Dieses System wäre also vollständig bestimmt.
Das genaue Gegenteil ist aber auch denkbar: Ein vollständig anpassbares System, das komplett ohne Regeln auskommt. In der Realität ist natürlich beides nicht sinnvoll. Die Produktivität wäre in beiden Fällen nicht allzu hoch. Der Idealfall sollte daher irgendwo dazwischen liegen.
Ordnen wir nach diesem Kriterium mal einige bekannte Modelle ein:

• V-Modell XT und RUP würden auf alle Fälle näher am Ende „vollständig bestimmt“ der Skala liegen. Diese beiden Vorgehensmodelle haben wesentlich mehr Umfang als für ein Projekt notwendig ist. Der Nutzer muß sich davon die Teile raussuchen, die für sein Projekt benötigt werden. Er „schneidert“ sich also sein Vorgehensmodell aus einer Vielzahl von Möglichkeiten zurecht. Daher z.B. auch die Erweiterung „XT“ beim V-Modell („Extreme Tailoring“). Problem dabei ist jedoch, daß man dazu geneigt ist, im Zweifelsfall lieber ein Artefakt zuviel als zuwenig dazuzunehmen. Das Modell wird dadurch größer als es eigentlich sein müsste.
• Scrum und Kanban finden sich dagegen eher am anderen Ende der Skala. Diese beiden Modelle beinhalten nur wenige Regeln, die für ein tatsächliches Projekt alleine nicht ausreichen (Scrum macht z.B. keine Vorgaben bzgl. der Abarbeitung von Tasks). Der Benutzer muß hier die für sein Projekt benötigten Teile hinzufügen. Allerdings sollte man sich hier an die Vorgabe „Weniger ist mehr“ halten! Kanban ist noch ein wenig weiter rechts auf der Skala als Scrum, da es einige Regeln aus Scrum nicht beinhaltet. So enthält es z.B. keine Rollen (wie „Product Owner“ oder „Scrum Master“), und auch keine Iterationen. Das bedeutet nicht, daß man keine Rollen und/oder Iterationen haben darf. Sie sind nur durch das Modell nicht gefordert.

Diese Skala könnte dann in etwa so aussehen:

Wie sieht nun aber der Unterschied zwischen Scrum und Kanban genau aus?
Als erstes fällt auf, daß Kanban keine Rollen fordert. Es gibt also von Haus aus keine Unterscheidung wie Product Owner, Scrum Master oder Team. Das bedeutet natürlich nicht, daß es in Kanban nicht trotzdem Sinn macht einen Product Owner einzuführen. Es ist lediglich vom Modell her nicht fest vorgegeben. D.h. man muß sich die Rollen, die man für seine Arbeit benötigt (und die auch sinnvoll sind), selbst definieren.

Kanban enthält auch keine Iterationen. Anders als bei Scrum gibt es also keinen festen Zeitraum, an dessen Ende eine fertige und potentiell auslieferungsfähige Produktversion steht. Releaseplanung in Kanban kann man daher auf verschiedene Arten planen: Analog Scrum anhand einer Zeitspanne (“Alle 3 Wochen bringen wir ein Wartungsrelease heraus”), oder anhand von erledigten Features (“Wir bringen die Software immer dann raus, wenn wir genau 50 neue Features umgesetzt haben”). Sogar Mischformen sind denkbar: Service Packs alle x Wochen, neue Programmversionen, wenn bestimmte Anforderungen realisiert wurden.
Wie wird ein Kanban-Projekt eigentlich gesteuert?

In Scrum gibt es zur Projektsteuerung eine priorisierte Liste von abzuarbeitenden Anforderungen (das Product Backlog), von der das Team zu Beginn jeder Iteration eine gewisse Anzahl in ein Sprint Backlog übernimmt. Dieses Sprint Backlog wird anschließend nicht mehr verändert. Am Ende der Iteration ist (im Normalfall) das Sprint Backlog komplett umgesetzt und das Team holt sich neue Anforderungen aus dem Product Backlog.

In Kanban läuft das ganze ein wenig anders: Da es hier ja keine Iterationen gibt macht es ja auch keinen Sinn mehr, ein Sprint Backlog zu führen. Stattdessen limitiert man hier nun die Zahl der Items, die sich in einem bestimmten Workflowschritt befinden können. Am einfachsten geht dies, indem man sich ähnlich wie bei Scrum ein „Kanban Board“ baut und die Limits dann einfach über die einzelnen Spalten schreibt.

Um sich das Ganze ein wenig besser vorstellen zu können, hier einige Beispiele:

In Bild 1 sieht man eine ganz normale Scrum-Tafel, so wie auch wir sie in unseren Projekten verwenden. Anforderungen aus dem Sprint Backlog bekommen jeweils eine eigene Zeile und werden dann in viele kleine Einheiten von <= 1 Tag aufgeteilt. Auf der Beispiel-Tafel wäre nun ein Feature (das oberste) bereits fertig realisiert, zwei sind noch in Bearbeitung (wobei eines der beiden zumindest schon teilweise fertiggestellt ist), und mit einem wurde noch gar nicht begonnen.

In Bild 2 nun eine Kanban-Tafel. Auf den ersten Blick sieht sie genauso aus wie die Scrum-Tafel, nur die Spalte „In Bearbeitung“ wurde zusätzlich mit einer „2“ versehen. Dies soll zum Ausdruck bringen, daß sich nur 2 Tasks im Status „In Bearbeitung“ befinden dürfen. Mit etwas Neuem darf erst dann begonnen werden, wenn einer der beiden aktuellen Tasks fertiggestellt wurde.

In Scrum hingegen ist die Zahl der „Zettel“ pro Spalte prinzipiell unbegrenzt. In der Praxis wird man (in der Spalte „In Bearbeitung“) jedoch trotzdem eine Art impliziter Beschränkung haben: Da die Bearbeitung eines „Zettels“ für eine Person in etwa 1 Tag in Anspruch nehmen soll, sollten eigentlich nie mehr Zettel in diesem Status hängen, als das Team Mitglieder hat. Ausnahmen können natürlich mal vorkommen, sollten aber nicht die Regel sein. Wenn das passiert deutet das oft auf ein Problem hin, das man lösen muß (z.B. von einander abhängige Aufgaben werden auf 2 Zettel verteilt).

Eine Aussage, wann wieder ein Slot zur Bearbeitung frei wird, lässt sich übrigens bei Kanban nicht direkt ablesen: Anders als bei Scrum ist die Granularität der einzelnen Aufgaben nicht von vorneherein festgelegt, sondern kann von „1 Stunde“ bis „1 Monat“ alles sein (länger als 1 Monat ist zwar möglich, aber in der Praxis nicht sinnvoll). Um hier abschätzen zu können, wie lange die Bearbeitung noch dauert müsste man also

• jede Aufgabe einzeln beschätzen, und
• überwachen, wie lange sie sich bereits im aktuellen Status befindet,

oder

• analog Scrum wieder eine feste Länge einzelner Aufgaben einführen

Natürlich ist Kanban, genau wie Scrum, ein empirischer Prozess. D.h. auch in Kanban ist es erlaubt Regeln zu überprüfen und ggf. abzuändern. Sollte sich z.B. im obigen Beispiel die Zahl „2“ als Beschränkung nicht als sinnvoll erweisen, so kann man sie auch ändern. Außerdem ist es natürlich auch erlaubt, die anderen beiden Spalten zu beschränken.

Ein Beispiel dafür ist in Bild 3 zu sehen. Die Beschränkung der Spalte „In Bearbeitung“ wurde auf 8 Einträge angehoben. Zusätzlich wurde auch noch eine Beschränkung von 3 Einträgen auf die Spalte „Todo“ gelegt.

Das Hinzufügen eines vierten Eintrags wäre hier nicht mehr erlaubt. Möchte der Product Owner/Auftraggeber etc. dennoch, daß das Team seine neue, hoch priorisierte Anforderung realisiert, so müsste er/sie dazu erst eine der bestehenden Anforderungen im Status „Todo“ entfernen.

Änderungen an der „Todo“-Spalte durch den Product Owner sind in Kanban übrigens zu jedem Zeitpunkt erlaubt. Es darf nur die Zahl der maximal zulässigen Einträge nicht überschritten werden.

In Scrum sieht das hingegen ganz anders aus: Der Product Owner darf hier nur das Product Backlog ändern. Auf der Scrum-Tafel stehen hingegen nur Einträge des Sprint Backlogs. Änderungen am Sprint Backlog sind im Nachhinein aber nicht mehr erlaubt. Zudem darf nur das Team die Zettel auf dem Scrum Board bewegen (und nicht der Product Owner).

Über die Zeit gesehen wird sich eine Kanban-Tafel daher nicht wesentlich verändern, außer daß vielleicht die Spalte „Fertig“ anwächst.

Ein Scrum Board hingegen wird zu Beginn jeder neuen Iteration „zurückgesetzt“ und durchläuft dann immer den in Bild 4 dargestellten Zyklus:

Zu Beginn eines Sprints sind alle Einträge im Status „Todo“. Läuft der Sprint einige Zeit, so sind die Einträge über alle Zustände verteilt: Einige Dinge sind bereits fertig, andere erst teilweise oder gar nicht realisiert. Am Ende eines Sprints sollten dann alle Einträge im Status erledigt sein.

Das solls nun fürs erste mit dem Vergleich von Scrum und Kanban gewesen sein. Der nächste Teil wird dann u.a. die Verteilung der Tafeln auf Teams (was in Kanban anders gehandhabt wird als in Scrum), die Arbeit an mehreren Produkten zur selben Zeit, und einige weitere (kleinere) Unterschiede zum Thema haben.

BFI