scrum vs. kanban: unterschiede und … · scrum vs. kanban: unterschiede und gemeinsamkeiten darf,...

5
SCRUM VS. KANBAN: UNTERSCHIEDE UND GEMEINSAMKEITEN darf, als ein Sprint lang ist. Größere Happen müssen also zwangsläufig in meh- rere kleine aufgeteilt werden. Bei Kanban hingegen gibt es keine Itera- tionen und damit auch keine Sprints. Daher sieht auch die Release-Planung in Kanban ein wenig anders aus: Analog zu Scrum erfolgt diese anhand einer festen Zeit- spanne („alle drei Wochen bringen wir ein Wartungs-Release heraus”) oder anhand von Minimal Marketable Features (MMF). Ein MMF ist ein (vorher definierter) fester Satz an Anforderungen, für den ein eigener Return-on-Investment (ROI) existiert (vgl. [Den03]). Aber auch Mischformen sind denkbar: Service-Packs alle x Wochen und neue Programmversionen, wenn bestimmte Anforderungen realisiert wurden. Projektsteuerung In Scrum gibt es zur Projektsteuerung eine priorisierte Liste von abzuarbeitenden Anforderungen: das Product Backlog, das vom Product Owner verwaltet wird. Zu Beginn einer Iteration übernimmt das Team eine gewisse Anzahl von Anforderungen in das Sprint Backlog, das alle Anforderungen enthält, die sich das Team für den folgenden Sprint vorgenommen hat. Einmal erstellt, darf es nicht mehr verändert werden. Die Release-Planung ist in Scrum daher immer ein Zusammenspiel zwischen Product Owner und Team: Der Product Owner gibt die Reihenfolge vor, in der die Anforderungen realisiert werden. Das Team entscheidet dann, wie viele dieser Anforderungen es in einem Sprint umsetzen kann. Am Ende der Iteration ist (im Normalfall) das Sprint Backlog komplett abgearbeitet und das Team holt sich für den nächsten Sprint neue Anforderungen aus dem Product Backlog. In Kanban läuft dies ein wenig anders ab: Da es hier keine Iterationen gibt, wird auch Eine der aktuell erfolgreichsten agilen Methoden ist Scrum. In letzter Zeit gehört jedoch auch Kanban mit zu den heiß diskutierten Themen. Beide Methoden basieren zwar auf denselben Ideen, weisen aber auch teilweise große Unterschiede auf. Dieser Artikel zeigt Gemeinsam- keiten und Unterschiede zwischen Scrum und Kanban und soll zu einem breiteren Verständnis der beiden Methoden beitragen. 42 43 Master ist der Samurai, der sich seinen Weg mithilfe des Schwertes bahnt. Der Kanban Practitioner dagegen macht eher so etwas wie Tai Chi, wo man die Er- leuchtung mithilfe von Meditation erlangt. Auch wenn am Ende dasselbe Ergebnis steht, der Weg dahin ist ein ganz anderer. Rollen und Iterationen Kanban fordert keine Rollen. Es gibt also keine zwingende Unterscheidung zwischen Product Owner, Scrum Master oder Team, wie das bei Scrum der Fall ist. Das bedeutet natürlich nicht, dass es in Kanban nicht trotzdem sinnvoll ist, einen Product Owner einzuführen. Fest vorgegeben ist diese Rolle jedoch nicht. Daher muss man sich bei Kanban die Rollen, die man für seine Arbeit benötigt (und die auch sinnvoll sind), selbst definieren. Eines der zentralen Konzepte von Scrum sind Sprints. Darunter versteht man Itera- tionen von fester Länge, an deren Ende eine neue, potenziell auslieferungsfähige Produktversion steht. Die Dauer einer sol- chen Iteration ist im Voraus bekannt und in der Regel immer gleich lang – natürlich kann man sie auch ändern, sollte dies aber nicht zu oft tun, da man ansonsten Gefahr läuft „aus dem Rhythmus” zu kommen. Diesem Konzept ordnet sich auch die Release-Planung unter: Für einen Sprint nimmt man sich genau so viel Arbeit vor, wie man denkt, in der vorgegebenen Zeit schaffen zu können. Die Reihenfolge, in der Anforderungen bearbeitet werden, ist nicht frei vom Team wählbar, sondern erfolgt nach dem Geschäftswert: Anforderungen mit dem höchsten Wert werden zuerst umgesetzt, die anderen später. Diese Priori- sierung festzulegen, ist eine der wichtigsten Aufgaben des Product Owners. Das bedeu- tet aber auch, dass die Umsetzung einer Anforderung in Srum nicht länger dauern In der letzten Zeit höre ich häufiger die Frage: „Macht ihr noch Scrum, oder seid ihr schon auf Kanban umgestiegen?” Teilweise hat man den Eindruck, Kanban sei so etwas wie der Nachfolger von Scrum. Aber das ist falsch! Ganz im Gegenteil: Beide Methoden werden zum Lean Software Development gezählt und basie- ren daher auf denselben Ideen. Im Detail offenbart sich jedoch auch eine Reihe von Unterschieden, vor allem in der zu Grunde liegenden Philosophie. Dieser Artikel beleuchtet die Gemeinsamkeiten und Unterschiede von Scrum und Kanban und zeigt, für welche Projektsituation sich wel- ches Modell am besten eignet. Wenn man ihn konsequent betreibt, ist Scrum ein sehr kämpferischer Weg: Der Scrum Master sammelt laufend die Probleme (Impediments), die das Team in seiner Arbeit behindern, und kämpft für deren Beseitigung – selbst wenn er sich damit hin und wieder unbeliebt macht. Das ist auch der Grund, warum Ken Schwaber, einer der Väter von Scrum, Scrum als Spiegel versteht, den man einer Organisation vorhält. Wenn man Scrum konsequent lebt, bringt man einem Unternehmen bei, auch komplexe Probleme (nicht nur softwarebezogene) in kurzer Zeit zu lösen (vgl. [Sch09]). Kanban (japanisch für „Signalkarte”) ist eine Technik, die aus dem „Toyota Production System” stammt. Ziel von Kanban ist es, einen gleichmäßigen Fluss (Flow) in der Fertigung herzustellen und Lagerbestände zu reduzieren. Kanban geht einen anderen, weicheren Weg als Scrum: Man beginnt damit, den Workflow sichtbar zu machen und die Durchlaufzeiten zu mes- sen. Anschließend limitiert man die Aufgaben in Arbeit (Work-In-Progress) und versucht, die Durchlaufzeiten zu verbessern. Ein schöner Vergleich findet sich bei den asiatischen Kriegskünsten: Der Scrum schwerpunkt Bernhard Findeiss (E-Mail: [email protected]) ist als Consultant der InterFace AG im Bereich Softwareentwicklung tätig. Schwerpunkt seiner Arbeit sind dabei vor allem agile Softwareprojekte. der autor

Upload: haque

Post on 14-Aug-2018

243 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: SCRUM VS. KANBAN: UNTERSCHIEDE UND … · SCRUM VS. KANBAN: UNTERSCHIEDE UND GEMEINSAMKEITEN darf, als ein Sprint lang ist. Größere Happen müssen also zwangsläufig in meh-rere

SCRUM VS. KANBAN:

UNTERSCHIEDE UND

GEMEINSAMKEITEN

darf, als ein Sprint lang ist. GrößereHappen müssen also zwangsläufig in meh-rere kleine aufgeteilt werden.

Bei Kanban hingegen gibt es keine Itera -tionen und damit auch keine Sprints. Dahersieht auch die Release-Planung in Kanbanein wenig anders aus: Analog zu Scrumerfolgt diese anhand einer festen Zeit -spanne („alle drei Wochen bringen wir einWartungs-Release heraus”) oder anhandvon Minimal Marketable Features (MMF).Ein MMF ist ein (vorher definierter) festerSatz an Anforderungen, für den ein eigenerReturn-on-Investment (ROI) existiert (vgl.[Den03]). Aber auch Mischformen sinddenkbar: Service-Packs alle x Wochen undneue Programm ver sionen, wenn bestimmteAnforderungen reali siert wurden.

ProjektsteuerungIn Scrum gibt es zur Projektsteuerung einepriorisierte Liste von abzuarbeitendenAnforderungen: das Product Backlog, dasvom Product Owner verwaltet wird. ZuBeginn einer Iteration übernimmt das Teameine gewisse Anzahl von Anforderungen indas Sprint Backlog, das alle Anforderungenenthält, die sich das Team für den folgendenSprint vorgenommen hat. Einmal erstellt,darf es nicht mehr verändert werden.

Die Release-Planung ist in Scrum daherimmer ein Zusammenspiel zwischenProduct Owner und Team: Der ProductOwner gibt die Reihenfolge vor, in der dieAnforderungen realisiert werden. DasTeam entscheidet dann, wie viele dieserAnforderungen es in einem Sprint umsetzenkann. Am Ende der Iteration ist (imNormalfall) das Sprint Backlog komplettabgearbeitet und das Team holt sich für dennächsten Sprint neue Anforderungen ausdem Product Backlog.

In Kanban läuft dies ein wenig anders ab:Da es hier keine Iterationen gibt, wird auch

Eine der aktuell erfolgreichsten agilen Methoden ist Scrum. In letzter Zeit gehört jedoch auchKanban mit zu den heiß diskutierten Themen. Beide Methoden basieren zwar auf denselbenIdeen, weisen aber auch teilweise große Unterschiede auf. Dieser Artikel zeigt Gemeinsam -keiten und Unterschiede zwischen Scrum und Kanban und soll zu einem breiteren Verständnisder beiden Methoden beitragen.

42 43

Master ist der Samurai, der sich seinenWeg mithilfe des Schwertes bahnt. DerKanban Practitioner dagegen macht eherso etwas wie Tai Chi, wo man die Er -leuchtung mithilfe von Meditation erlangt.Auch wenn am Ende dasselbe Ergebnissteht, der Weg dahin ist ein ganz anderer.

Rollen und IterationenKanban fordert keine Rollen. Es gibt alsokeine zwingende Unters cheidung zwischenProduct Owner, Scrum Master oder Team,wie das bei Scrum der Fall ist. Das bedeutetnatürlich nicht, dass es in Kanban nichttrotzdem sinnvoll ist, einen Product Ownereinzuführen. Fest vorgegeben ist diese Rollejedoch nicht. Daher muss man sich beiKanban die Rollen, die man für seineArbeit benötigt (und die auch sinnvollsind), selbst definieren.

Eines der zentralen Konzepte von Scrumsind Sprints. Darunter versteht man Itera -tionen von fester Länge, an deren Ende eineneue, potenziell auslieferungsfähigeProdukt version steht. Die Dauer einer sol-chen Iteration ist im Voraus bekannt und inder Regel immer gleich lang – natürlichkann man sie auch ändern, sollte dies abernicht zu oft tun, da man ansonsten Gefahrläuft „aus dem Rhythmus” zu kommen.Diesem Konzept ordnet sich auch dieRelease-Planung unter: Für einen Sprintnimmt man sich genau so viel Arbeit vor,wie man denkt, in der vorgegebenen Zeitschaffen zu können. Die Reihenfolge, in derAnforderungen bearbeitet werden, ist nichtfrei vom Team wählbar, sondern erfolgtnach dem Geschäftswert: Anforderungenmit dem höchsten Wert werden zuerstumgesetzt, die anderen später. Diese Priori -sierung festzulegen, ist eine der wichtigstenAufgaben des Product Owners. Das bedeu-tet aber auch, dass die Umsetzung einerAnforderung in Srum nicht länger dauern

In der letzten Zeit höre ich häufiger dieFrage: „Macht ihr noch Scrum, oder seidihr schon auf Kanban umgestiegen?”Teilweise hat man den Eindruck, Kanbansei so etwas wie der Nachfolger von Scrum.Aber das ist falsch! Ganz im Gegenteil:Beide Methoden werden zum LeanSoftware Development gezählt und basie-ren daher auf denselben Ideen. Im Detailoffenbart sich jedoch auch eine Reihe vonUnterschieden, vor allem in der zu Grundeliegenden Philosophie. Dieser Artikelbeleuchtet die Gemeinsamkeiten undUnterschiede von Scrum und Kanban undzeigt, für welche Projektsituation sich wel-ches Modell am besten eignet.

Wenn man ihn konsequent betreibt, istScrum ein sehr kämpferischer Weg: DerScrum Master sammelt laufend die Probleme(Impediments), die das Team in seiner Arbeitbehindern, und kämpft für deren Beseitigung– selbst wenn er sich damit hin und wiederunbeliebt macht. Das ist auch der Grund,warum Ken Schwaber, einer der Väter vonScrum, Scrum als Spiegel versteht, den maneiner Organi sation vorhält. Wenn manScrum konsequent lebt, bringt man einemUnternehmen bei, auch komplexe Probleme(nicht nur softwarebezogene) in kurzer Zeitzu lösen (vgl. [Sch09]).

Kanban (japanisch für „Signalkarte”) isteine Technik, die aus dem „ToyotaProduction System” stammt. Ziel vonKanban ist es, einen gleichmäßigen Fluss(Flow) in der Fertigung herzustellen undLagerbestände zu reduzieren. Kanban gehteinen anderen, weicheren Weg als Scrum:Man beginnt damit, den Workflow sichtbarzu machen und die Durchlauf zeiten zu mes-sen. Anschließend limitiert man dieAufgaben in Arbeit (Work-In-Progress) undversucht, die Durchlaufzeiten zu verbessern.

Ein schöner Vergleich findet sich bei denasiatischen Kriegskünsten: Der Scrum

schwerpunk t

Bernhard Findeiss

(E-Mail: [email protected])

ist als Consultant der InterFace AG im Bereich

Softwareentwicklung tätig. Schwerpunkt seiner

Arbeit sind dabei vor allem agile Softwareprojekte.

der au tor

Page 2: SCRUM VS. KANBAN: UNTERSCHIEDE UND … · SCRUM VS. KANBAN: UNTERSCHIEDE UND GEMEINSAMKEITEN darf, als ein Sprint lang ist. Größere Happen müssen also zwangsläufig in meh-rere

44 45

schwerpunk t

kein Sprint Backlog geführt. Stattdessenlimitiert man hier die Zahl der Items, diesich in einem bestimmten Schritt desWorkflows befinden können. Zur Visuali -sierung benutzt man, ähnlich wie in Scrumauch, eine einfache Tafel: das Kanban-Board.

Beispiel eines Scrum-BoardsAbbildung 1 zeigt eine Scrum-Tafel, wie siein vielen Projekten verwendet wird. An -forderungen aus dem Sprint Backlog (dar-gestellt durch gelbe Karten) werden ihremGeschäftswert nach an die Tafel geheftet.Die wichtigsten Anforderungen stehenganz oben, die weniger wichtigen unten. Siebekommen jeweils eine eigene Zeile undwerden in viele kleinere Tasks aufgeteilt(hier in weiß dargestellt).

Im Scrum-Board kann man anhand derSpalten, in denen sich die einzelnen Tasksbefinden, gut erkennen, wie weit die dazugehörigen Anforderungen bereits fertigge-stellt sind:

■ Wenn sich alle Tasks einer Anforderungim Zustand „fertig“ befinden, ist auchdie dazugehörige Anforderung fertig(Zeile 1 in Abb. 1). Um dies auch op -tisch zu verdeutlichen, hängt man auchdie gelbe Karte mit dem Eintrag ausdem Sprint Backlog nach ganz rechts.

■ Bei Anforderungen, mit deren Um -setzung noch nicht begonnen wurde,befinden sich alle Tasks im Zustand„Todo“ (Zeile 4 in Abb. 1).

■ In allen anderen Fälle, d. h. wenn sichTasks auf zwei oder gar alle dreiSpalten verteilen, wird an diesen An -forderungen aktuell gearbeitet (Zeile 2und 3 in Abb. 1).

Das Scrum-Team in diesem Beispiel machtes übrigens genau richtig. Es arbeitet sichnämlich von oben nach unten durch dieTafel. Zuerst bearbeitet es die wichtigstenAnforderungen. erst danach die wenigerwichtigen.

Beispiel eines Kanban-BoardsAbbildung 2 zeigt ein Kanban-Board. Aufden ersten Blick hat es durchaus Ähnlich-keit mit einer Scrum-Tafel, unterscheidetsich davon aber doch in einigen wesent-lichen Punkten:

■ In Kanban werden die Anforderungennicht in einzelne Tasks aufgeteilt wiebei Scrum, sondern durchlaufen als„Tickets” der Reihe nach die verschie-denen Bearbeitungsschritte („Statio -nen”) eines Workflows. Ein solcherWorkflow kann beliebig lang sein. Inunserem Beispiel beschränken wir unsauf Entwicklung, Test, Abnahme,Deployment und Inbetrieb nahme.

■ Die Anzahl der Tickets, die sich gleich-zeitig in einem Workflow-Schritt befin-den dürfen, ist limitiert. In einemSchritt dürfen sich nie mehr Ticketsgleichzeitig befinden, als das Limit vor-gibt. Erst wenn die nachfolgendeStation sich eines der Tickets holt, darfsich die aktuelle Station wieder ein neu-es nehmen.

Auf diese Weise entsteht ein Pull-Prinzip:Eine Station gibt ein Ticket nicht an dienächste Station weiter, sondern die nach-folgende Station „zieht” sich das Ticketselbst aus dem vorherigen Schritt rein. Inunserem Beispiel etwa würde sich dasDeployment eine der Karten aus derAbnahme holen. Dadurch würde nun auchin der Abnahme wieder ein Platz für eineder Karten aus dem Test frei, der sichwiederum eine der Karten aus derEntwicklung holen könnte. Die Ent -wicklung hätte dann wiederum Kapazi -täten frei, um eine neue Anforderung ausdem Backlog zu bearbeiten.

Limitierung desWork-In-Progress Die Limitierung ist eine relativ einfacheMöglichkeit, um sichtbar zu machen, wieTickets die verschiedenen Stationen durch-

Abb. 1: Beispiel einer Scrum-Tafel.

Abb. 2: Beispiel eines Kanban-Boards.

Page 3: SCRUM VS. KANBAN: UNTERSCHIEDE UND … · SCRUM VS. KANBAN: UNTERSCHIEDE UND GEMEINSAMKEITEN darf, als ein Sprint lang ist. Größere Happen müssen also zwangsläufig in meh-rere

2/2010

schwerpunk t

Planung übernimmt das Team nur genau soviele Anforderungen in das Sprint Backlog,wie es denkt, in der aktuellen Iterationbearbeiten zu können. Das Team setzt sichdas Limit also selbst, gestützt vor allem aufErfahrungen aus vorangegangenen Sprints.

Empirische ProzesskontrolleGenau wie Scrum ist auch Kanban einempirischer Prozess. Beide erlauben es,Regeln zu überprüfen und diese gegebenen-falls auch abzuändern. Sollte sich etwa imKanban-Prozess aus Abbildung 2 erweisen,dass sich die Durchlaufzeit durch andereLimitierungen senken lässt, sollte man diesauch tun.

Ein Beispiel dafür ist in Abbildung 3 zusehen. Um den Flaschenhals aus Abbildung 2zu beseitigen, wurde das Limit für den Testvon 4 auf 5 erhöht. Zeitgleich wurde jedochdas Limit der Entwicklung von 6 auf 5 ge-senkt.

In der Realität könnte man sich das zumBeispiel so vorstellen, dass ein Entwicklerins Testteam gewechselt ist. Das Testteamist nun um eine Person gewachsen, wäh-rend das Entwicklungsteam um eine Persongeschrumpft ist. Im Beispiel bringt dieseMaßnahme den gewünschten Erfolg: Auchdie Abnah me ist nun voll ausgelastet undder Flaschenhals ist beseitigt.

laufen und wo sie sich stauen: Das sindgenau die Stellen, an denen sich Ticketshäufen, während an nachfolgenden Sta -tionen noch Kapazitäten frei sind. DieseStellen nennt man auch Bottlenecks(Flaschen hälse bzw. Engpässe).

Auch in Abbildung 2 gibt es einen sol-chen Flaschenhals: die Station „Test”.Während der Test selbst bereits bei vollerAuslastung angelangt ist, wären in dernachfolgenden Station „Abnahme” nochPlätze frei. Auch auf die Entwicklungschlägt sich dies bereits durch, denn auchsie ist bereits am Limit angekommen. Umeinen möglichst gleichmäßigen Fluss zuerreichen, sollte man deswegen konsequentversuchen, Flaschenhälse zu eliminieren.Dazu kann man verschiedene Maßnahmenergreifen, beispielsweise indem man dieLimits ändert.

Limitierung in ScrumAnders als in Kanban gibt es in Scrum keinexplizites Limit von Tasks in den verschie-denen Schritten des Workflows. Die Zahlder Tasks pro Spalte auf dem Scrum-Boardist also prinzipiell unbegrenzt. Das ist aller-dings nur die halbe Wahrheit. Natürlichgibt es auch in Scrum eine Limitierung. Nursetzt diese bereits auf einem höheren Levelan: im Sprint Backlog. Während der Sprint-

Abb. 3: Kanban-Board mit geänderten Limitierungen.

Abb. 4: Aussehen einer Scrum-Tafel im Verlauf eines Sprints.

Kanban- und Scrum-Tafelüber die ZeitDie unterschiedliche Anzahl von Work -flow-Schritten sowie die explizitenLimitierun gen sind jedoch nicht der einzigeUnter schied zwischen einem Kanban- undeinem Scrum-Board. Auch das Aussehender Tafeln im Lauf der Zeit ist unterschied-lich: Während sich eine Kanban-Tafel imProjektverlauf nicht wesentlich verändert(außer dass vielleicht die Spalte „fertig”anwächst), wird eine Scrum-Tafel zuBeginn jedes neuen Sprints „zurückgesetzt”und durchläuft dann immer den inAbbildung 4 dargestellten Zyklus:

Zu Beginn eines Sprints sind alle Einträgeim Status „to do”. Läuft der Sprint einigeZeit, sind die Einträge über alle Zuständeverteilt: Einige Dinge sind bereits fertig,andere erst teilweise oder noch gar nichtrealisiert. Am Ende eines Sprints solltendann alle Einträge im Status „erledigt”sein.

Bei Kanban ist das anders: Weil Kanbankeine Iterationen kennt, macht ein Kanban-Board auch keinen solchen Zyklus durch.Items laufen ohne Unterbrechung von linksnach rechts durch die Tafel, weshalb diesedie meiste Zeit ziemlich gleich aussieht. DieZahl der Items in den verschiedenenSpalten ändert sich immer nur ein wenig.Bei Spalten, die auf eine bestimmte Zahlvon Einträgen beschränkt sind, ist dieseFluktuation manchmal sogar so gut wienicht vorhanden (sobald ein Item die Spalteverlässt, wird sofort eines nachgezogen).

Eine Tafel = ein Team?Bei Scrum gibt die Tafel genau die Arbeiteines Teams wieder. Sie ist zwar für die gan-ze Welt sichtbar, aber nur das Team darf sieauch verändern. Das Team selbst ist multi-funktional besetzt, d. h. alle Fähigkeiten,die benötigt werden, um den aktuellenSprint zu einem erfolgreichen Ende zu füh-ren, sind im Team enthalten.

Bei Kanban sind keine solchen Schran -ken vorgegeben. Multifunktionale Teamssind optional und Spezialistenteams sindexplizit erlaubt. Auch die Beschränkung„eine Tafel, ein Team” ist nicht gegeben.Stattdessen bezieht sich eine Kanban-Tafelimmer auf einen definierten Work flow, derjedoch prinzipiell beliebig viele Teamsumfassen kann. Hier ein Beispiel aus derAutomobilindustrie:

Würde man Autos nach Scrum bauen, sowürde jedes einzelne Auto von einem eige-

Page 4: SCRUM VS. KANBAN: UNTERSCHIEDE UND … · SCRUM VS. KANBAN: UNTERSCHIEDE UND GEMEINSAMKEITEN darf, als ein Sprint lang ist. Größere Happen müssen also zwangsläufig in meh-rere

46 47

schwerpunk t

nen Team gebaut werden – vom Presswerkbis hin zur Endmontage. Das ist jedochnicht die Art und Weise, wie Auto -mobilfabriken üblicherweise organisiertsind. In der Regel werden Autos heute nachdem Fließband-Prinzip gefertigt: Die Autosdurchlaufen nacheinander die einzelnenProduktions schritte, wo sich jeweils eineigenes Team von Spezialisten darum küm-

mert (siehe Abb. 5). Die Abbildung zeigteine typische Scrum-Tafel, die immer imBesitz eines einzigen Teams ist. Alle Spaltender Tafel werden ausschließlich durch die-ses Team geändert (der Product Owner unddas Product Backlog sind hier außen vor).

Abbildung 6 zeigt eine Kanban-Tafel, dienicht im Besitz eines einzigen Teams ist.Stattdessen spiegelt sie einen Workflow

(hier: Bestellungen, Presswerk, Lackierei,Motor, Innen ausstattung, Auslieferung)wider, der beliebig auf Teams aufgeteiltwerden kann. Im dem Beispiel wird etwadie Spalte „Bestellungen” von nur einereinzigen Person verwaltet (das könnte bei-spielsweise ein einzelnes Bestellsystemsein). Für die restlichen Spalten ist dagegenjeweils ein eigenes Team zuständig. Die ein-zige Ausnahme sind die Stationen „In -nenausstattung” und „Auslieferung”, beidenen sich eine Person um beides kümmert.Man kann sich das z. B. so vorstellen, dassdie Person, die die Innenausstattung mon-tiert, anschließend auch das Auto aus derWerkshalle auf den Auslieferungs parkplatzfährt.

Natürlich kann man den Workflow nochauf viele weitere Arten auf Teams verteilen.Bei einer hohen Zahl von Items könnte esetwa sinnvoll sein, dass sich zwei odermehr Teams eine Spalte teilen. Aber auchder bei Scrum eingesetzte Fall (ein Teamverwaltet die komplette Tafel) ist möglich.

Anforderungen schätzenZum Schätzen von Items bzw. ihren Durch -laufzeiten nutzt man in Scrum die Längeeiner Iteration als Bezugsrahmen: DasTeam schätzt alle neu ankommendenAnforderungen und selektiert davon immergenau so viele, wie es in dieser Iteration (= Sprint) umsetzen kann. Als Hilfsmittelverwendet man dazu die Erfahrungen ausvorangegangenen Sprints. Zählt man dieSchätzwerte aller Anforderungen einesSprints zusammen, die sich am Ende imStatus „fertig” befindet, so erhält man den„Gesamtwert” eines Sprints. Diese Zahlwird als Velocity bezeichnet (siehe auchAbb. 7). Den Wert kann man über mehrereSprints hinweg fortschreiben und verglei-chen. Er dient dem Team vor allem alsAnhaltspunkt bei der Sprintplanung, wennes darum geht, Anforderungen für dennächsten Sprint zu selektieren.

Bei Kanban ist das etwas anders. Da eshier von Haus aus keine Iterationen gibt,benötigt man natürlich auch einen anderenBezugsrahmen. Daher wird in Kanban dieDurchlaufzeit von Tickets durch den Work -flow gemessen. Diese Durchlaufzeit kannman verwenden, um Fertigstellungs zeitenvon An forderungen zu prognostizieren.Unterschiede zwischen den einzelnenTickets hinsichtlich ihrer Priorität werdenhier noch nicht gemacht. Sollte dies aber

Abb. 5: Eine Scrum-Tafel ist immer im Besitz eines einzigen Teams.

Abb. 6: Eine Kanban-Tafel kann von mehreren Teams gleichzeitig verwaltet werden.

Page 5: SCRUM VS. KANBAN: UNTERSCHIEDE UND … · SCRUM VS. KANBAN: UNTERSCHIEDE UND GEMEINSAMKEITEN darf, als ein Sprint lang ist. Größere Happen müssen also zwangsläufig in meh-rere

2/2010

schwerpunk t

Abb. 7: Berechnung der Velocity.

notwendig werden, z. B. weil man immerwieder Tickets mit verschiedenerWichtigkeit hereinbekommt, sieht Kanbandie Möglichkeit vor, Service Level Agree -ments (SLAs) einzuführen. Dies kann sogarso weit gehen, dass man für Tickets derhöchsten Priorität die Limitierung derWorkflow-Schritte außer Kraft setzt.

GemeinsamkeitenNeben vielen Unterschieden weisen Scrumund Kanban auch eine Reihe von Ge -meinsamkeiten auf:

■ Beiden Methoden entstammen demLean Software Development.

■ Beides sind Pull-Systeme.■ Beides sind empirische Prozesse, in

denen Daten aus dem laufenden Betriebausgewertet und für Prozessverbes -serungen eingesetzt werden.

■ Beide limitieren den Work-In-Progress.■ Beide basieren auf selbstorganisieren-

den Teams

Wann Scrum, wann Kanban?Für Unternehmen, die bisher eher nacheinem klassischen Prozess wie demWasserfall-Modell arbeiten, kann es einfa-cher sein, Kanban einzuführen. Änderun-gen und Prozessverbesserungen werdenhier erst allmählich im Lauf der Zeit einge-führt. Scrum hingegen könnte – als der eherkämpferische Weg – das Unternehmeneventuell überfordern, da hier in kurzerZeit weitreichende Veränderungen angesto-ßen werden.

Auch für Wartungs- und Betriebsauf -gaben kann Kanban die geeignetere Lösungsein. Gerade hier tut man sich nämlich oft-mals schwer mit der Einführung von fest imVoraus geplanten Iterationen, da selbst einZeitraum von nur einer Woche nur schwer

Scrum Kanban

Iterationen mit fester Länge Iterationen sind optional. Eine feste Länge istsind vorgeschrieben. nicht zwingend, auch Ereignissteuerung möglich.

Drei Rollen sind fest vorgesehen Initial sind keine Rollen vorgeschrieben.(Product Owner, Scrum Master und Team).

Das Team wählt eine Menge an Es gibt Keine Iterationen, daher sind auch keineAnforderungen für einen Sprint aus und festen Zusagen notwendig. Dank der Messung vonverpflichtet sich, diese auch umzusetzen. Zykluszeiten sind aber Voraussagen über den

Fertigstellungszeitpunkt möglich.

Velocity dient als Bezugsrahmen für Die Durchlaufzeit ist der BezugsrahmenSchätzung des Sprint Backlogs. für Schätzungen.

Der Produkt-Backlog ist (absteigend) nach Die Priorisierung von AnforderungenGeschäftswert sortiert. ist optional.

Die Anforderungen im Produkt-Backlog Tickets dürfen beliebig groß sein.müssen in maximal einem Sprint realisierbarsein. Größere Brocken müssen entsprechendaufgeteilt werden.

Keine Änderungen an den Anforderungen Neue Anforderungen können prinzipiell zu jeder Zeitwährend eines Sprints möglich. Neue eingebracht werden.Anforderungen werden frühestens mit dernächsten Sprintplanung übernommen.

Eine Scrum-Tafel wird nach jedem Sprint Eine Kanban-Tafel wird kontinuierlich fortgeschrieben.zurückgesetzt.

Ein Sprint Backlog (und damit auch eine Eine Kanban-Tafel kann beliebig auf TeamsScrum-Tafel) gehört immer genau aufgeteilt werden.einem Team.

Multifunktionale Teams sind vorgeschrieben Multifunktionale Teams sind optional. Auch mehrere-- und auch notwendig, da ein Sprint Teams von Spezialisten sind erlaubt.Backlog nur von einem einzigen Teambearbeitet wird.

Tabelle 1: Scrum und Kanban – Unterschiede und Gemeinsamkeiten.

abzuschätzen ist. Zudem ist ein ungestörtesArbeiten über einen gewissen Zeitraum oftauch gar nicht entscheidend (bzw. sogarmöglich). Hier kann Kanban, dessen Zielja eine möglichst schnelle Durchlaufzeitdurch einen definierten Workflow ist, diebessere Wahl darstellen. Gerade auch dann,wenn man mit verschiedenen Service-Levelsarbeitet. Notfälle und Routineaufgabenkann man so sehr gut voneinander trennen.Dagegen kann Scrum gerade bei Soft -wareentwicklungsteams, die ein (neues)Produkt entwickeln, seine Stärken entfal-ten. Fest geplante Sprints mit nicht (bzw.nur im absoluten Notfall) änderbarenAnforderungen geben dem Team hier denFreiraum, den es benötigt, um kreativ zuarbeiten. ■

Literatur & Links

[Den03] M. Denne, J. Cleland-Huang, Soft -

ware by Numbers: Low-Risk, High-Return

Development, Prentice Hall, 2003, siehe auch:

www.softwarebynumbers.org/

[Kni09] H. Kniberg, Kanban vs. Scrum – How

to make the most of both, Version 1.1, siehe:

www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

[Ohn93] T. Ohno, Das Toyota-Produktions -

system, Campus 1993

[Sch09] K. Schwaber, A. Cockburn,

Implementing Scrum, 2009, siehe: www.imple

mentingscrum.com/2009/03/16/alistair-cockburn-

and-ken-schwaber-scrum-gathering-monday-after

noon/