Kanban [1] ist ein relativ neues, schlankes Vorgehensmodell zum einfachen Verwalten von Entwicklungsprozessen. Man hat sich dabei die Grundprinzipien der – ursprünglich von Toyota für die Automobilindustrie entwickelten – „Lean Production“ zum Vorbild genommen und versucht, diese Prinzipien auf die Software-Entwicklung zu übertragen. Die wichtigsten Ideen daraus:

• Es soll eine gleichmäßige Arbeitsbelastung geschaffen werden. Engpässe und Lastspitzen sind zu vermeiden, da sie den gesamten 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 ihrem Aufgabenbereich arbeiten die Teams jedoch eigenverantwortlich und weisen sich Aufgaben selbst zu („pull“).

Sobald ein Projekt ausgeliefert wurde, beginnt dessen Nachbetreuung, also die Support- und Maintenance-Phase. Diese ist gekennzeichnet durch viele kleine, kurz getaktete, oftmals unzusammenhängende Arbeitspakete von unterschiedlicher Priorität und Dauer. Aufgaben werden gern per Bugtracker-Ticket, Mail oder schlimmstenfalls mündlich zugewiesen.

Typischerweise befinden sich außerdem noch weitere Projekte in dieser Phase. Eine unübersichtliche Situation also, die sich kaum effektiv organisieren oder zumindest kontrollieren lässt. Und weder Scrum noch das alte Wasserfallmodell helfen hier weiter, da der Overhead beider Methoden einfach zu groß ist. Allein die Planungsdauer einer Sprintphase kann bereits den Umfang eines Arbeitspakets überschreiten. Hier nun liegen die Stärken von Kanban.

Kanban einfach anwenden. Unser Videokurs zeigt dir, wie es geht.

Das zentrale Element in Kanban ist das so genannte Kanban-Board, ein Whiteboard, auf das alle Mitarbeiter Zugriff haben. Das Board ist in verschiedene, frei definierbare Spalten aufgeteilt, die den Workflow des Entwicklerteams visualisieren. In diesen Spalten landen anschließend Arbeitspakete, die auf Karten notiert und priorisiert 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, um von einer Spalte in die nächste zu kommen: Wichtig sind einheitliche Kriterien. So kann ein Paket alles sein, was länger als zwei Stunden und weniger als zwei Tage zur Umsetzung benötigt. Und als erledigt gilt ein Paket womöglich dann, wenn es tatsächlich ins Produktivsystem gespielt wurde. Auf diese Art lässt sich auch ein großes Arbeitspaket von mehreren Tagen Aufwand ganzheitlich nachverfolgen – von der Analyse bis zum Rollout.

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

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

Ein „Cumulative Flow“-Diagramm hingegen deckt auf, in welchem Prozessschritt Engpässe auftreten und sich Arbeitspakete stauen. Dazu wird die Summe aller Pakete pro Prozessschritt in Abhängigkeit der Zeit gemessen. So kann man gezielt gegensteuern, indem man etwa das Abnahme/Testing-Team aufstockt, falls es bei der Abnahme immer wieder zu Verzögerungen kommt.

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

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

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

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

Aber auch das Projektmanagement profitiert von Kanban: Ein einziger Blick auf das Board sorgt für Transparenz und bringt einen schnellen Überblick. Wie hoch ist die Auslastung? Wer arbeitet gerade an welcher Aufgabe? Was steht als nächstes an? Aufwändige Status-Meetings und Nachfragen reduzieren sich von selbst auf ein kurzes, tägliches Stand-Up-Meeting vor dem Board. Die Arbeitsplanung und umständliche Lokalisierung freier Entwicklerkapazitäten wird vereinfacht, da letztlich nur noch Karten ans Board gepinnt werden müssen

Unterm Strich sorgt Kanban damit für eine höhere Mitarbeiterzufriedenheit und Produktivität, obschon das System (fast) ohne Regeln auskommt. Henrik Kniberg, Kanban-Evangelist, bemerkt dazu lapidar: „Just inches from „Do whatever“, but still surprisingly powerful“ [4]. Recht hat er.