KANBAN: KEEP IT SIMPLEKanban befindet sich im Aufwind. Zwar liegt der Bekanntheitsgrad nach wie vorhinter Scrum, jedoch zu Unrecht. Lassen sich doch mit Kanbans schlankemVorgehensmodell vor allem in der Support- und Wartungsphase von Projektenschnell verblüffende Ergebnisse erzielen.

TEXT DANIEL HALLER

Kanban [1] ist ein relativ neues, schlankes Vorgehensmodell zumeinfachen Verwalten von Entwicklungsprozessen. Man hat sichdabei die Grundprinzipien der – ursprünglich von Toyota für dieAutomobilindustrie entwickelten – „Lean Production“ zum Vorbildgenommen und versucht, diese Prinzipien auf die Software-Ent-wicklung zu übertragen. Die wichtigsten Ideen daraus:

⇶ Es soll eine gleichmäßige Arbeitsbelastung geschaffen werden.Engpässe und Lastspitzen sind zu vermeiden, da sie den ge-samten Prozess verlangsamen. Alles ist „im Fluss“.

⇶ Produktionsfaktoren und Mitarbeiter müssen aus-, aber nichtüberlastet sein. So lässt sich die Produktivität erhalten.

⇶ Nur der Nachschub wird extern organisiert („push“), in ihremAufgabenbereich arbeiten die Teams jedoch eigenverantwort-lich und weisen sich Aufgaben selbst zu („pull“).

EINSATZGEBIETSobald ein Projekt ausgeliefert wurde, beginnt dessen Nachbetreu-ung, also die Support- und Maintenance-Phase. Diese ist gekenn-zeichnet durch viele kleine, kurz getaktete, oftmals unzusammen-hängende Arbeitspakete von unterschiedlicher Priorität und Dauer.Aufgaben werden gern per Bugtracker-Ticket, Mail oder schlimms-tenfalls mündlich zugewiesen.

Typischerweise befinden sich außerdem noch weitere Projektein dieser Phase. Eine unübersichtliche Situation also, die sich kaumeffektiv organisieren oder zumindest kontrollieren lässt. Und we-der Scrum noch das alte Wasserfallmodell helfen hier weiter, dader Overhead beider Methoden einfach zu groß ist. Allein die Pla-nungsdauer einer Sprintphase kann bereits den Umfang eines Ar-beitspakets überschreiten. Hier nun liegen die Stärken von Kanban.

FUNKTIONSWEISEDas zentrale Element in Kanban ist das so genannte Kanban-Board,ein Whiteboard, auf das alle Mitarbeiter Zugriff haben. Das Boardist in verschiedene, frei definierbare Spalten aufgeteilt, die denWorkflow des Entwicklerteams visualisieren. In diesen Spaltenlanden anschließend Arbeitspakete, die auf Karten notiert undpriorisiert werden. Das Entwicklungsteam bedient sich anschlie-ßend selbst („Pull“ statt „Push“) und arbeitet so Paket für Paket ab.Ist eine Aufgabe erledigt, wandert das Paket eine Spalte weiter.

Was ein Paket ist, bestimmt das Team. Ebenso die Hürden, umvon einer Spalte in die nächste zu kommen: Wichtig sind einheit-

liche Kriterien. So kann ein Paket alles sein, was länger als zweiStunden und weniger als zwei Tage zur Umsetzung benötigt. Undals erledigt gilt ein Paket womöglich dann, wenn es tatsächlich insProduktivsystem gespielt wurde. Auf diese Art lässt sich auch eingroßes Arbeitspaket von mehreren Tagen Aufwand ganzheitlichnachverfolgen – von der Analyse bis zum Rollout.

Ein Kanban-Board visualisiert die einzelnen Prozesschritte und ihren Status.

Trotz geringer Reglementierung – ein Grundsatz Kanbans mussimmer gelten: Jede Spalte hat ein eigenes „Work in Progress“-Limit(WiP-Limit), das nicht überschritten werden darf. Das WiP-Limitlegt fest, wie viele Arbeitspakete sich gleichzeitig in einem Pro-zessschritt befinden dürfen. Es bestimmt sich somit aus der Ent-wicklungskapazität des Teams und verhindert damit dessenÜberlastung. Auch Engpässe im Prozess fallen sofort auf. Ein Ar-beitspaket, das partout nicht abgenommen wird, sorgt demnach fürStau in den vorhergehenden Schritten – in der Lehre des Kanban,die alles „im Fluss“ halten und gleichmäßig bewegen will, stellt dasein Problem dar, dem man sich umgehend annehmen muss.

MESSTECHNIKKanban bietet vielfältige Metriken, um die Leistung eines Teamszu messen oder Flaschenhälse im Prozess aufzuspüren. So lässtsich etwa feststellen, wie lange ein Arbeitspaket braucht, um dengesamten Workflow zu durchlaufen („Cycle Time“). Diese Zahl stelltim Durchschnitt und auf alle Pakete gerechnet nichts anderes alsdie Entwicklungsgeschwindigkeit des Teams dar.

1 © yeebase media 2011. Veröffentlichung und Vervielfältigung nur mit Genehmigung der yeebase media GbR. http://t3n.de

Ein „Cumulative Flow“-Diagramm hingegen deckt auf, in wel-chem Prozessschritt Engpässe auftreten und sich Arbeitspaketestauen. Dazu wird die Summe aller Pakete pro Prozessschritt inAbhängigkeit der Zeit gemessen. So kann man gezielt gegensteu-ern, indem man etwa das Abnahme/Testing-Team aufstockt, fallses bei der Abnahme immer wieder zu Verzögerungen kommt.

Ein Cumulative-Flow-Diagramm macht Engpässe sichtbar – zu sehen an den Stel-len, an denen die Linien stärker auseinander laufen.

Das Verwalten mehrerer Projekte ist ebenfalls problemlos zu be-werkstelligen, ohne für jedes Projekt ein neues Whiteboard auf-stellen zu müssen. Dazu gibt es zwei unterschiedliche Ansätze:Ergänzt man das Board um weitere Zeilen („Swimlanes“), lassensich diese jeweils einem bestimmten Projekt zuordnen. Alternativsind Kanban-Karten in verschiedenen Farben gebräuchlich.

Für unterschiedliche Projekte eignen sich entweder unterschiedlich gefärbte Kar-ten oder eigene Zeilen auf dem Whiteboard.

Auch online lässt sich das Kanban-Modell visualisieren. Entspre-chende Werkzeuge wie Greenhopper [2] oder das Kanban-Tool [3]sind aufgrund des zeit- und ortsunabhängigen Zugangs besondersbei verteilten Teams an unterschiedlichen Standorten sinnvoll.

FAZITNach einem Jahr Kanban-Nutzung in der Wartungsphase fällt dasUrteil des Autors durchwegs positiv aus: Denn so simpel das Prinzipauch ist, in der Praxis zeigen sich verblüffende Effekte, sobald sichdas Team darauf eingestellt hat. Durch die zentrale Bündelung allerAufgaben am Kanban-Board gerät nichts in Vergessenheit.

Arbeitspakete werden nicht mehr per Mail oder gar auf Zurufverteilt, sondern strukturiert erfasst und im Kontext der anderenProjekte betrachtet, was die Koordination der verschiedenen Auf-gaben erheblich verbessert. Entwickler können sich endlich wiederauf die Entwicklung konzentrieren, anstatt ihre anstehenden Auf-gaben verwalten zu müssen. Die WiP-Limits vermeiden indes eineÜberlastung und störende Kontextwechsel zwischen verschiede-nen Aufgaben. All das hat für erheblich mehr Ruhe und Konzen-tration im sonst hektischen Entwickleralltag gesorgt.

Aber auch das Projektmanagement profitiert von Kanban: Eineinziger Blick auf das Board sorgt für Transparenz und bringt einenschnellen Überblick. Wie hoch ist die Auslastung? Wer arbeitet ge-

rade an welcher Aufgabe? Was steht als nächstes an? AufwändigeStatus-Meetings und Nachfragen reduzieren sich von selbst auf einkurzes, tägliches Stand-Up-Meeting vor dem Board. Die Arbeits-planung und umständliche Lokalisierung freier Entwicklerkapazi-täten wird vereinfacht, da letztlich nur noch Karten ans Boardgepinnt werden müssen

Unterm Strich sorgt Kanban damit für eine höhere Mitarbei-terzufriedenheit und Produktivität, obschon das System (fast) ohneRegeln auskommt. Henrik Kniberg, Kanban-Evangelist, bemerktdazu lapidar: „Just inches from „Do whatever“, but still surprisinglypowerful“ [4]. Recht hat er. ↔

LINKS ↗ Softlink auf t3n.de/magazin 2901[1] Kanban: http://www.limitedwipsociety.org/[2] Greenhopper: http://www.atlassian.com/software/greenhopper/[3] Kanban-Tool: http://kanbantool.com/[4] Kanban and Scrum (Minibook): http://bit.ly/5iznN1

DANIEL HALLER studierte in Darmstadt Me-dia System Design, wo er 2009 diplomierte.Seitdem arbeitet er als Technischer Managerund Entwickler bei der Frankfurter AgenturBlueMars.

© yeebase media 2011. Veröffentlichung und Vervielfältigung nur mit Genehmigung der yeebase media GbR. http://t3n.de 2