2/2010

KANBAN IN DER

SOFTWAREENTWICKLUNG:

SCHLANKE SOFTWARE-

ENTWICKLUNG IM FLUSS

nichts stockt – wenn Henning und Martingleich schnell arbeiten.

Nehmen wir an, Henning produziertPlatinen schneller, als Martin diese verar-beiten kann. Dann erlaubt das Kanban-System es ihm nicht, weitere Platinen aufVorrat zu produzieren – ohne Kanban-Karte keine Arbeit. Das hört sich zunächstvielleicht eigenartig an, aber es ist vernünf-tig. Wenn Henning schneller Platinen pro-duziert als Martin sie weiter verarbeitenkann, wächst das Lager mit Platinen (alsohalbfertigen Produkten) immer weiter.Martin hat keine Chance, dieses stetigwachsende Lager jemals abzuarbeiten.

Mit Kanban wird Henning natürlichtrotzdem nicht tatenlos herumsitzen undwarten, bis Martin wieder eine Kanban-Karte auf den Tisch legt. Stattdessen wirder mit Martin darüber sprechen, wie sie dasSystem gemeinsam in den Fluss-Zustandbekommen können. Eine Möglichkeit ist,dass Henning einen Teil von MartinsTätigkeiten übernimmt. So könnten sichbeide darauf verständigen, dass Henning inZukunft die Platinen gleich in das Gehäuseschraubt und Martin sich auf dasAnschließen des Displays und der Tastaturbeschränkt.

Sollte Martin schneller arbeiten als Hen -ning, greift dasselbe Prinzip. Martin hatnichts mehr zu tun und Henning hat nochkeine weitere Platine fertig. Martin ergreiftdann die Initiative, um das System wiederin den Fluss-Zustand zu bekommen. Damitentsteht durch den Einsatz von Kanban einselbstregulierendes System, um Fluss herzu-stellen. Probleme werden schnell sichtbarund sollen von den Beteiligten direkt gelöstwerden.

Die konkrete Anzahl der Kanban-Kartenhängt von der Variabilität der Bearbei -

Seit Kurzem bereichert Kanban die Diskussion um die Softwareentwicklungsmethoden.Kanban überträgt das Konzept der Kanban-Karten aus der „Lean Production” auf dieSoftwareentwicklung. So wie Kanban in der Produktion einen gleichmäßigen Fluss der Produktedurch die Fabrik herstellt, soll es in der Softwareentwicklung für reibungslose Abläufe sorgenund damit die Effizienz steigern. Dieser Artikel beschreibt Idee und Technik des Kanban-Ansatzes für die Softwareentwicklung.

m e h r z u m t h e m a :www.agilemanagement.net/Articles/Weblog/KanbaninAction.htmlhttp://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html

aufträge symbolisieren (in Abb. 1 nichtdar gestellt). Zu Beginn des Prozesses sitzenHenning und Martin an ihren Arbeits -plätzen und Martin legt die beidenKanban-Karten auf den Lagertisch. Hen -ning nimmt sich eine Kanban-Karte alsArbeitsauftrag und fertigt eine Haupt -platine. Sobald er fertig ist, heftet er dieKanban-Karte an die Platine und legt bei-des auf den Tisch. Sofort nimmt er sich diezweite Kanban-Karte und beginnt mit derArbeit an der nächsten Platine. Gleichzeitignimmt Martin die Platine inklusiveKanban-Karte vom Tisch, baut die Platinein das Gehäuse ein und schließt Displayund Tastatur an. Sobald er damit fertig ist,legt er die Kanban-Karte wieder auf denTisch. Wenn alles glatt gelaufen ist, hatHenning jetzt die nächste Platine fertig,sodass Martin direkt mit dieser fortfahrenkann. Henning nimmt dann die gerade frei-gewordene Kanban-Karte für dieProduktion der nächsten Platine. Martinfordert also über Kanban-Karten Platinenbei Henning an. Hierbei handelt es sich umdas so genannte Pull-Prinzip. Alles fließt,

Kanban in der Lean ProductionKanban ist ein japanisches Wort und bedeu-tet Signalkarte (Kan heißt Signal und Banbedeutet Karte). Es hat sich im Deutscheneingebürgert, dass man die SignalkarteKanban-Karte nennt, auch wenn danneigentlich Karte doppelt im Begriff vorhan-den ist. Mit Kanban wird das Pro -duktionssystem bezeichnet, das auf Kanban-Karten basiert. Ein Kanban-System regeltden Produktionsfluss (den Flow) in der LeanProduction (vgl. [Ohn88]).

Das sehen wir uns an einem sehr einfachenBeispiel einmal an. Henning und Martin bau-en Notebooks zusammen. Henning baut ausgelieferten Einzelteilen die Hauptplatineinklusive Festplatte etc. Martin baut dieHauptplatine in das Gehäuse ein und schließtDisplay sowie Tastatur an. Henning undMartin sitzen nebeneinander und haben zwi-schen sich einen Tisch als Zwischenlager ste-hen (siehe Abb. 1).

Die beiden haben sich vom ToyotaProduction System (vgl. [Ohn88]) inspirie-ren lassen und setzen daher Kanban ein. Esgibt zwei Kanban-Karten, die Arbeits -

schwerpunk t

Stefan Roock

(E-Mail: stefan.roock@it-agile.de)

ist Senior IT-Berater bei der it-agile GmbH.

Er verfügt über mehrjährige Erfahrung aus agilen

Softwareprojekten (Scrum. XP, FDD) als Coach,

Trainer und Entwickler und ist Buchautor.

der au tor

Abb. 1: Henning und Martin bauen Notebooks.

18 19

schwerpunk t

tungszeiten an den einzelnen Stationen ab.Henning und Martin arbeiten sehr kon-stant und benötigen daher nur zweiKanban-Karten. Je größer die Variabilitätder Bearbeitungszeiten ist, desto mehrKanban-Karten sind notwendig, um Flussherzustellen.

Kanban hat also die Aufgabe, die inBearbeitung befindlichen Produkte zu kon-trollieren, um Fluss herzustellen und dieDurchlaufzeiten zu minimieren. DieDurchlaufzeit – also die Zeit vom Beginnbis zum Ende der Wertschöpfungskette – istin der Lean Production die Messgrößeschlechthin. Die Lean Production versucht,die Durchlaufzeit zu minimieren – im Ge -gensatz zur klassischen Massenproduktion,in der die Auslastung teurer Maschinen imVordergrund steht.

Kanban ohne KartenWenn Henning und Martin das Kanban-Prinzip klar ist, können sie in ihrem einfa-chen Fall auf die physikalischen Karten ver-zichten. Sie legen fest, dass es auf dem Tischgenau zwei Lagerplätze für Platinen gibt.Der Zustand des Zwischenlagers gibt die-selbe Information her, wie die Kanban-Karten es tun: Darf ich arbeiten oder mussich warten?

Bei Kanban für Softwareentwicklungverzichtet man ebenfalls auf die physikali-schen Karten und begrenzt stattdessen dieLagerkapazität für Zwischenergebnisse.Ein so genanntes Kanban-Board visuali-siert, welche Zwischenprodukte in wel-chem Zustand existieren (siehe Abb. 2).Die auf dem Kanban-Board dargestelltenKarten sind dabei keine Kanban-Karten imeigentlichen Sinne mehr – vielmehr reprä-sentieren sie die bearbeiteten Produkte. InAbbildung 2 werden fünf Stationen in derSoftwareentwicklung unterschieden:

■ Anforderung: Spezifikation der Anfor -derung, sodass sie anschließend pro-grammiert werden können.

■ Programmierung: Programmierung derAnforderung.

■ Dokumentation: Externe Dokumen -tation zu den Anforderungen (Benut -zer- und Betriebshandbuch).

■ Test: Testen der Anforderung.■ Betrieb: Inbetriebnahme der Anfor -

derung.

Zunächst sind diese Stationen tatsächlichsequenziell zu verstehen. Prinzipiell sprichtnichts dagegen, Stationen zu überspringenoder sich auch rückwärts zu bewegen.Wenn allerdings häufig Aufgaben rück -wärts verschoben werden, ist dieAussagekraft des Kanban-Boards zweifel-haft. Man kann dann nicht mehr so einfacherkennen, wo z. B. Stauungen auftreten.

Im Beispiel ist jede Station auf zwei Ele -mente beschränkt (siehe Zahlen über denSpalten). Das bedeutet für Abbildung 2,dass die Dokumentation keine weiterenElemente entgegen nimmt, solange nichtmindestens eines abgearbeitet ist. Wennjetzt also ein weiteres Element spezifiziertwird, liegen bei der Programmierung eben-falls zwei Elemente. Und selbst wenn dieProgram mierung diese beiden Elementeumgesetzt hat, kann sie keine weiterenElemente entgegennehmen, solange die bei-den Lager plätze bei der Dokumentationbelegt sind. Durch die vollständigeBelegung bei der Dokumentation wird dieProgrammierung die erledigten Elementenämlich gar nicht los.

Falls eine Station (z. B. die Dokumen -tation) überlastet oder blockiert ist, würdesich also als Rückstau schrittweise bis anden Anfang der Wertschöpfungskette fort-pflanzen und das Problem sehr deutlichsichtbar machen. Gerade dieses Sichtbar -

machen von Problemen hat in der Soft -ware ent wicklung einen hohen Wert. Sehrhäufig behindern Probleme und Blockadenauf vielfältige Art und Weise den Projekt -fortschritt und werden gar nicht richtigdeutlich. Man geht einfach zur nächstenAufgabe über. Von außen betrachtet hatjeder immer gut zu tun und es gibtFortschritt. Das böse Erwachen kommtzum Projektende, wenn man gezwungenist, die ganzen begonnenen Arbeiten zuEnde zu führen.

Lagerkapazitäten in derSoftwareentwicklungMöchte man Kanban in der Software -entwicklung einführen, stellt sich natürlichsofort die Frage, wie groß die Lager -kapazitäten sein sollen. Im oben genanntenBeispiel hatten wir an allen Stationen zweiPlätze vorgesehen. Die Durchlaufzeit sinkt,wenn die Lager kapazität gering ist. Einesehr geringe Lagerkapazität setzt allerdingsvoraus, dass Probleme bei der Bearbeitungeiner An forderung sofort beseitigt werden– dazu sind viele Organisationen nicht inder Lage, wenn auf Zuarbeiten gewartetwird. Eine entsprechend höhere Kapazitätadressiert dieses Problem. Wenn einElement blo ckiert ist, weil man aufZuarbeiten wartet, kann man mit demnächsten Element weiterarbeiten. Aberirgendwann ist die Kapazität erschöpft undman muss sich aktiv selbst darum küm-mern, dass die fehlenden Zuarbeitenschnell erfolgen.

Man sollte nicht mit einem System star-ten, das sofort still steht, denn das sorgt fürkeine gute Presse im Unternehmen. Statt -dessen sollte man sich in kleinen Schrittenan das Ideal heranarbeiten. Beispielsweisekönnte man ein Kanban-Board zunächstohne Kapazitätsbeschränkung einführen.Anschließend lässt man das System eineWeile laufen und analysiert, wie vielLagerplatz wo benötigt wurde. Auf dieserBasis definiert man dann großzügig dieinitialen Kapazitäten.

Über kontinuierliche Verbesserungen (z. B.über Retrospektiven) verringert man nunschrittweise die Lagerkapazität. Eine hilfrei-che Messgröße ist dabei die durchschnittli-che Durchlaufzeit, die sich als Summe ausallen Lager- und Bearbei tungszeiten berech-net. In der Software entwicklung sindAnalyse, Entwurf, Programmierung, Test,Dokumentation etc. Bearbeitungszeiten. DieLagerzeiten sind einfach die Zeiten, in denenAnforderungen nicht bearbeitet werden. Das

Abb. 2: Kanban-Board in der Softwareentwicklung.

Anfor-derung

Program-mierung

Doku-mentation

Test Betrieb

2/2010

schwerpunk t

rieren. Daher arbeitet man bei Kanban inder Softwareentwicklung mit so genanntenminimal marktfähigen Features (MinimalMarketable Features, MMF, vgl. [Den03])als Elemente des Kanban-Boards. EinMMF ist eine möglichst kleine Menge vonFunktionen, die einzeln in Betrieb genom-men werden können und einen Mehrwertfür den Kunden darstellen.

Sind die MMFs auf dem Kanban-Boardsehr unterschiedlich groß, wird die durch-schnittliche Durchlaufzeit weniger aussage-kräftig und die Varianz wird sehr groß.Außerdem benötigt man mit steigenderVarianz in der Größe der MMFs mehrLagerplätze. Alle MMFs auf ungefähr die-selbe Größe zu bekommen, ist meist gutmachbar, wenn ein existierendes Systemweiterentwickelt wird. Wird ein neuesSystem entwickelt, sind die ersten MMFshäufig deutlich größer als nachfolgendeMMFs. Dieses Problem kann man durchein zweidimensionales Kanban-Boardlösen, auf dem die MMFs in Storys (vgl.[Coh04]) herunter gebrochen werden (siehe Abb. 3).

Eine User-Story ist eine für den An -wender nützliche Funktion im System. Umwirklichen Geschäftswert zu generieren,muss man jedoch mehrere Storys zu einemMMF bündeln. Für die Anwendung inKanban sollen die Storys ungefähr allegleich groß sein – auch hier werdenVarianzen reduziert.

Neben dem Herunterbrechen auf Storyswerden MMFs häufig auch nach Größeklassifiziert (z. B. mit T-Shirt-Größen wieS, M, L, XL), sodass die Durchlaufzeiten jenach Größe optimiert werden.

ten Notebooks entgegennimmt und repa-riert. Henning und Martin verfolgen aller-dings die Philosophie, dass Probleme nichtverwaltet, sondern beseitigt werden sollten.Daher suchen sie nach der eigentlichenUrsache – und das sind letztlichQualitätsprobleme in der Produktion. Sieentscheiden sich daher dafür, diese genauerzu analysieren und zu beseitigen. Sind sieerfolgreich, sinkt die Varianz im Durchsatzund Lagerplätze können reduziert werden.

Bei der Softwareentwicklung hat manimmer deutlich größere Varianzen als in derProduktion. Je innovativer die entwickeltenSoftwareprodukte sind, desto größer wer-den häufig diese Varianzen. Bei der Über-tragung muss man also aufpassen, dassman nicht zu weit geht und damit kreativeArbeit behindert – z. B. indem Varianzensoweit reduziert werden, dass kein Raummehr für kreative Lösungen bleibt.

Minimal marktfähige FeaturesDamit Kanban reibungslos funktioniert,müssen die durch das System laufendenElemente zwei Anforderungen genügen:

■ Jedes Element muss für sich genommeneinzeln einen Wert besitzen.

■ Die Elemente müssen ungefähr gleichgroß sein. Sind diese sehr unterschied-lich groß, liegen wieder Varianzen vor,denen mit größeren Lagerkapazitätenbegegnet werden muss.

Es soll Geschäftswert generiert werden undder Fokus auf die Durchlaufzeit ergibtunternehmensweit gedacht nur dann Sinn,wenn man die Durchlaufzeiten vonElementen misst, die Geschäftswert gene-

Verhältnis von Bearbeitungs- zu Lagerzeitenin der Softwareentwicklung liegt häufig bei1 zu 10 oder schlechter. Möchte man also dieDurchlaufzeiten reduzieren, lohnt sich einscharfer Blick auf die Lagerzeiten. EineReduktion der Lager zeiten wirkt sich häufigselbst dann verkürzend auf dieDurchlaufzeiten aus, wenn sich durch dieseOptimierung die Bear beitungszeiten verlän-gern.

Lager puffert VarianzenDie Reduktion der Lagerplätze findetzunächst seine natürliche Begrenzungdurch Varianzen in der Wertschöp -fungskette. Wenn Martins Produktivitätbeispielsweise einmal zehn Notebooks proStunde beträgt und einmal nur sechs, dannkommen wir mit unseren zwei Lager -plätzen zwischen Henning und Martin inSchwierigkeiten. Martin verarbeitet imSchnitt acht Notebooks pro Stunde. WennHenning eine immer gleichbleibendeProduktivität von acht Notebooks proStunde an den Tag legt, sieht imDurchschnitt zwar alles gut aus. In derPraxis gibt es aber keinen Fluss. DieBeschränkung auf zwei Lagerplätze führt ineiner langsamen Martin-Stunde dazu, dassHenning nur fünf Mother-Boards produ-zieren kann und untätig herumsitzt. Ineiner schnellen Martin-Stunde kommtHenning mit dem Produzieren nicht nachund Martin hat nichts zu tun.

Dem Problem kann man mit einer erhöh-ten Anzahl an Lagerplätzen begegnen.Anschließend sollte das Ziel aber wiederdie Reduktion von Lagerplätzen sein –dazu müssen die Varianzen im Prozessreduziert werden. In unserem Fall würdenwir also analysieren, warum Martinmanchmal zehn und manchmal nur sechsNotebooks pro Stunde fertigt. Nehmen wiran, Henning und Martin finden bei derAnalyse heraus, dass der schwankendeDurchsatz bei Martin seine Ursache inRückläufern hat: Immer wieder kommenNotebooks von Kunden zurück, weil dieseProduktionsdefekte aufweisen. Martinnimmt die Notebooks entgegen und besei-tigt die Defekte. Da die defektenNotebooks nicht gleichmäßig eintreffenund die Reparatur unterschiedlich langedauert, hat das Varianzen in MartinsDurchsatz zur Folge.

Jetzt gibt es eine Reihe von Möglich -keiten, um die Varianzen zu reduzieren.Beispielsweise könnten Henning undMartin jemanden einstellen, der die defek-

Abb. 3: MMFs und Storys (S1...) auf dem Kanban-Board.

20 21

schwerpunk t

Scrum Kanban PERT / Gantt

Organisation selbst gesteuert selbst gesteuert fremd gesteuert

Push oder Pull Pull Pull Push

Management- empirisch empirisch vorhersagendansatz

Umfang der komplette komplette Wert- Nicht festgelegt;Betrachtung Wertschöpfung schöpfung teilweise Fokus nur auf

reine Programmierung & Test

Optimierungs- Kurzes Time-to- Minimale Minimale Aufwände,richtung Market Durchlaufzeiten maximale Auslastung

Planungs- MMFs, Storys MMFs, Storys Aktivitätenelemente

Timeboxes Iterationen als Keine Iterationen/ MeilensteineTimeboxes Timeboxes

Commitment auf Sprintziel evtl. auf Durchlaufzeiten keine Commitments

Spezialisierung Generalisten neutral häufig mit Spezialistenbevorzugt

Rollen 3 Rollen beliebig beliebig

Einführungs- Scrum bedeutet schrittweise –strategie Wandel Einführung

Tabelle 1: Kanban im Vergleich.

Warteschlangen imKanban-BoardDas bisher gezeigte Kanban-Board erlaubtkeine Unterscheidung zwischen Elementen,die in Bearbeitung sind, und solchen, die aufBearbeitung warten. Um diese beidenZustände zu differenzieren, werden zusätzli-che Warteschlangen im Kanban-Board einge-führt (siehe Abb. 4). Kapazitäts beschrän -kungen (Zahlen über den Spalten) werdenjetzt sowohl auf den Verarbei tungsschrittenals auch auf den Warte schlangen definiert.

Insbesondere die initiale Modellierungdes Kanban-Boards kann mit Warte -

schlangen vereinfacht werden. DieKapazitätsbeschränkungen für die Verar -beitungsschritte kann man dann an derAnzahl der verfügbaren Personen orientie-ren. So kann man sich für den Anfang vor-stellen, dass man für die Programmierungdavon ausgeht, dass jeder Entwicklerjeweils genau ein Element in Bearbeitunghat. Bei sechs Entwicklern wird dann z. B.die Kapazitäts beschränkung auf sechs fest-gelegt. Die Warteschlangen orientieren sichan den Varianzen bei der Abarbeitung derAufgaben und daran, ob man bestimmteAufgaben in Gruppen zusammenfasst –

beispielsweise, weil man wegen hoherOverhead-Kosten nicht jedes Element ein-zeln dokumentiert, sondern immer inGruppen von vier.

Ein weiterer Vorteil der Warteschlangenbesteht darin, dass man leichter sehenkann, wo genau ein Engpass (Bottleneck)auftritt – z. B. bei der Programmierung odervor der Dokumentation.

IterationenKanban selbst kennt keine Iterationen oderSprints. Wenn beispielsweise neueAnforderungen benötigt werden, wird diesauf dem Kanban-Board durch leere Stellenin der ersten Spalte sichtbar. Prinzipiellkann man jedes MMF einzeln begutachtenund in den Betrieb bringen.

So kann man allerdings nur dann agieren,wenn die jeweils notwendigen Personenschnell verfügbar sind. Daher ist es beiKanban üblich, dass es regelmäßige (z. B.wöchentliche) Priorisierungsmeetings gibt.Hier wird festgelegt, welche MMFs als näch-stes in das Kanban-System eingebracht wer-den. Dieses Meeting hat also große Ähnlich-keiten mit einer Iterations-/ Sprint planung.

WerkzeugeDas hier beschriebene Kanban-Board istzunächst eine physikalische Tafel an derWand, einer Stellwand oder auf einem gro-ßen Whiteboard. Wie auch bei den Task-Boards aus Scrum und dem XP (eXtremeProgramming) ist die physikalische Exis -tenz des Boards wichtig. Die Wand ist derTreffpunkt zu kurzen Statusmeetings(Standup-Meeting, Daily Scrum) und dasVerschieben der Karten an der Wand machtden Projektfortschritt sowie die vorhande-nen Blockaden erlebbar. Daher arbeiten diemeisten Unternehmen, die Kanban einset-zen, mit physikalischen Kanban-Boards.

Soll oder muss ein Softwaresystem einge-setzt werden, gibt es hierfür eine Reiheunterschiedlicher Systeme am Markt.

Die Rückkehr desWasserfall-Modells?Wenn man sich Kanban-Boards ansieht,kann man schnell den Eindruck gewinnen,dass hier das Wasserfall-Modell unter neu-em Namen verkauft werden soll.Schließlich werden auf vielen Kanban-Boards genau diejenigen Schritte abgebil-det, die wir aus dem Wasserfall-Modellauch kennen: Analyse, Design, Imple -mentierung und Test. Tatsächlich kannman Kanban auch in Wasserfall-Projekten

Abb. 4: Warteschlangen im Kanban-Board.

2/2010

schwerpunk t

■ Es besteht die Gefahr, dass Durch -laufzeiten auf Kosten der Wert -schöpfung reduziert werden.

Tabelle 1 stellt Scrum, Kanban und einklassisches Verfahren mit PERT und Ganttin Stichworten einander gegenüber. Eindetaillierter Vergleich von Scrum undKanban findet sich in [Kni]. ■

Concept, vgl. [Pop06]). Damit adressiertKanban den Umstand, dass die lokaleOptimierung der Softwareentwicklung fürdas Unternehmen keinen Nutzen hat, wennder Flaschenhals woanders liegt – z. B., weildie Gruppe für den Betrieb überlastet ist unddie vielen neuen Funktionen gar nicht schnellgenug in den Betrieb überführen kann.

FazitKanban hat seine Wurzeln im Wartungs -bereich: Hier müssen viele kleineAnforderungen, die ungefähr dieselbeGröße haben, umgesetzt werden. Systemund Anwendungsbereich sind gut verstan-den, sodass gemeinsame Iterationspla -nungen zwischen Team und Fachexpertennicht notwendig sind. Iterationsplanungenim klassischen Sinne erscheinen wieOverhead – vor allem, wenn offshore ent-wickelt wird und dadurch Fachexpertenund Team weit voneinander entfernt sind.

Inzwischen wird Kanban aber auch inanderen Projekttypen eingesetzt, beispiels-weise für die Spieleentwicklung (vgl.[Kei08]). Kanban birgt aber auch Risikenund Nebenwirkungen:

■ Der durch Iterationen vorgegebeneRhyth mus entfällt. Dadurch kann esfür die Organisation schwerer werden,sich mit der Softwareentwicklung zusynchronisieren.

■ Durch das Weglassen der Iterations -meetings können eventuell vorhandeneKommunikationsprobleme noch ver-stärkt werden.

■ Es wird schwerer, einen Release-Terminfür einen größeren Funktionsumfangabzuschätzen.

einsetzen und tatsächlich kann jede Spalteim Kanban-Board auch eine Arbeits -übergabe an einen Spezialisten bedeuten:Der Analyst übergibt an den Designer undder wiederum an den Programmierer. Dasist jedoch nur eine Option und keineswegsetwas, was in Kanban fest angelegt ist.

Kanban für die Softwareentwicklung istkeine neue konkurrierende Methode. Es istein System zur Fluss-Steuerung, das sichsowohl mit klassischen als auch mit agilenAnsätzen kombinieren lässt. Durch dieschrittweise Verkürzung der Durchlauf -zeiten und den Abbau von Lagerplätzen hatKanban das Potenzial, für viele ProjekteEffizienzsteigerungen zu erbringen.

Die Kanban-Protagonisten werbendamit, dass Kanban methodenneutral istund zum Beispiel auch in Wasserfall-Projekten eingesetzt werden kann. Das isttheoretisch richtig, aber auch etwas ge -schummelt. Natürlich kann man in einemWasserfall-Projekt ein Kanban-Boardmodellieren. Alle MMFs würden sichimmer gleichzeitig in derselben Spaltebefinden und als großer Block bewegt wer-den. Und die Durchlaufzeit für jedesElement wäre maximal lang – nämlich diekomplette Projektlaufzeit. Kanban wärealso nur sinnvoll, wenn man bereit ist, vondieser „Massenverarbeitung” in eineMMF-orientierte Arbeitsweise überzuge-hen – und dann kommt man den agilenAnsätzen automatisch schon nahe.

Auf jeden Fall liefert Kanban den Blicküber den Tellerrand der reinen Software -entwicklung. Kanban bezieht die Prozessevor und nach der eigentlichen Software -entwicklung mit ein und betrachtet diegesamte Wertschöpfungskette (Cash to

Literatur & Links

[And07] D.J. Anderson, Kanban in Action,

2007, siehe: www.agilemanagement.net/Articles/

Weblog/KanbaninAction.html

[Coh04] M. Cohn, User Stories Applied,

Addison-Wesley, 2004

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

Software by Numbers: Low-Risk, High-Return

Development, Prentice Hall Computer, 2003

[Kei08] C. Keith, Beyond Scrum: Lean and

Kanban for Game Developers, 2008, siehe:

http://www.gamasutra.com/view/feature/3847/beyond

_ scrum_lean_and_kanban_for_.php

[Kni] Henrik Kniberg's blog, Kanban vs

Scrum, siehe: http://blog.crisp.se/henrikkniberg/

2009/04/03/1238795520000.html

[Lad10] C. Ladas, Lean Software Engineering

– Scrum-ban, 2010, siehe: http://leansoftware

engineering.com/ksse/scrum-ban/

[Ohn88] T. Ohno, Toyota Production System:

Beyond Large-scale Production, Productivity

Press, 1988

[Pop06] M.&T. Poppendieck, Implementing

Lean Software Development: From Concept to

Cash, Addison-Wesley Longman, 2006