Projektmanagement mit Kanban

Kanban Kanban – ein Begriff, den man bisher vor allem aus der Industrie kannte. Kanban ist eine Vorgehensweise, die ein hohes Maß an Flexibilität in der Entwicklung ermöglichen soll. Inzwischen hat Kanban auch Einzug in die Softwareentwicklung erhalten. Der agile Ansatz löst mehr und mehr klassisches Wasserfall-Projektmanagement ab. Doch auch die Kombination von klassischem Projektmanagement und Kanban ist möglich. Ein Erfahrungsbericht.

Was ist Kanban?

Die Frage, was Kanban ist, kann man am besten damit beantworten, was Kanban nicht ist. Kanban ist nämlich weder eine Projektmanagement- noch eine Entwicklungsmethode. Kurz gesagt ist Kanban eine Methode des Change Managements. Kanban visualisiert den Arbeitsfluss und zeigt auf, woran gerade gearbeitet wird, wo es gerade Probleme gibt und welche Arbeitsschritte durchlaufen werden müssen.

Kanban wurde ursprünglich bei Toyota eingeführt mit dem Ziel der Kostenoptimierung in der Produktionskette. Es wird dabei nach dem Pull-Verfahren vorgegangen, bei dem sich jeder Arbeitsschritt die für seine Tätigkeiten benötigten Vorprodukte aus Zwischenlägern bezieht. Auf diese Weise entsteht eine effiziente Arbeitskette mit kurzen Transportwegen. Für die IT entdeckt und angepasst wurde Kanban durch David J. Anderson, der die Technik in seiner Lean-Kanban University weiterentwickelt.

Der Begriff „Kanban“ stammt – wie die Technik selbst - aus dem Japanischen und bedeutet so viel wie „Karte“. Letztendlich lassen sich alle Arbeitspakete auf jeweils einer oder mehreren Karten abbilden, die dann auf der Kanban-Wand angebracht werden. Die Ausgestaltung der Kanban-Karten und der Kanban-Wand kann in unterschiedlicher Weise erfolgen. Alle Varianten haben jedoch gemein, dass es einen mehrstufigen Arbeitsprozess gibt, der von jeder Karte von links nach rechts durchlaufen wird. Im einfachsten Fall sind dies das Backlog, das als Sammelbecken neuer Karten dient, der Bereich „Selected“ für die Auswahl als nächstes anzugehender Aufgaben, das „Doing“ für in Arbeit befindliche Karten und „Done“ für abgeschlossene Aufgaben. Je nach Bedarf kann es eine oder mehrer zusätzliche Bereiche wie etwa für die Qualitätssicherung geben.

Kanban-Wand

Als weiterer Bestandteil von Kanban gilt Kaizen bzw. die kontinuierliche Verbesserung. Es findet eine ständige Reflektion des Arbeitsablaufs statt. Dies passiert zum einen während der Umsetzung und zum anderen in so genannten Kanban-Retrospektiven. Ziel ist es jeweils, Verbesserungspotentiale zu entdecken und umzusetzen. Dabei folgt man dem Regelkreis des „Plan-Do-Check-Act“ nach Deming. Probleme werden erkannt, Lösungen werden umgesetzt und im Anschluss auf ihre Tauglichkeit geprüft.

Deming-Circle

Typischer Ablauf bei Kanban

Normalerweise treffen sich die Beteiligten eines Kanban-Teams täglich zu einer Besprechung, in der berichtet wird, was am Vortag getan wurde, wo es Probleme gab und was am anstehenden Tag erledigt werden soll. Im Zuge dessen können abgeschlossene Karten verschoben und neue Karten ergänzt werden. Gemeinsam bestimmen die Beteiligten die Priorität der einzelnen Karten. Je nach Wunsch kann es für die Auswahl neuer Karten aber auch einen wöchentlichen oder zweiwöchentlichen zuzsätzlichen Termin geben.

Wichtig: Kanban ist im Gegensatz zu Scrum oder vergleichbaren Ansätzen keine iterative Methode. Das bedeutet, dass es keine festen Releasezyklen gibt. Die Umsetzung ist viel mehr kontinuierlich und im Fluss.

Auch die Rollen unterscheiden sich von denen bei Scrum. So gibt es keinen „Kanban-Master“ oder Ähnliches. Das Team agiert als Ganzes. Das stellt vor allem traditionelle Teams mit festen Rollenzuordnungen vor Probleme, weil es eben diese Rollen in Kanban so nicht mehr gibt.

Erfahrungen mit Kanban und Best Practices

Ein Kernpunkt bei Kanban ist die so genannte Work in Progress (WIP). Diese besagt, wie viele Karten oder Aufgaben gleichzeitig in Bearbeitung sind. Dabei gilt: Die Durchlaufzeit pro Karte ist umso geringer, je kleiner die Zahl der gleichzeitig in Arbeit befindlichen Karten ist.

Durchlaufzeit=WIP/Durchsatz

Gerade das stellt viele Teams erst einmal vor Herausforderungen, denn der Wunsch nach möglichst vielen bearbeiteten Karten beißt sich auf den ersten Blick mit der Forderung nach einer Reduzierung des WIP. Schaut man allerdings genauer hin, dann zeigt sich, dass es durchaus von Vorteil ist, sich auf die Fertigstellung weniger Karten zu konzentrieren, anstatt viele Bälle gleichzeitig in der Luft zu halten. Daher lautet auch einer der Kanban-Wahlsprüche: „Stop starting, start Finishing“.

Definition von „Fertig“

Was bedeutet es aber überhaupt, wenn eine Karte fertig bearbeitet ist? Was muss getan werden, damit eine Karte diesen Zustand erreichen kann? Um diese Fragen zu beantworten, ist es notwendig und hilfreich, eine so genannte „Definition of Done“ festzulegen, und das für jeden Abschnitt des Arbeitsfortschritts. Die Entwicklung kann beispielsweise dann abgeschlossen sein, wenn keine Fehler mehr gefunden werden und alle Tests erfolgreich durchgelaufen sind. Nur mit Hilfe einer solchen Festlegung herrsch Klarheit über den Arbeitsfortschrittt.

Erfolgsmessung

Für die Messung der Effizienz und Effektivität in Kanban gibt es eine Reihe von Hilfsmitteln – je nachdem, was man sich als Messziel setzen möchte. In der eigenen Erfahrung hat es sich als hilfreich erwiesen, jeder Karte beim Eintreten in die nächste Stufe des Arbeitsprozesses einen Stempel mit dem aktuellen Datum zu geben. Somit lässt sich nachvollziehen, wann die Karte in „Selected“ gelandet ist, wann die Bearbeitung gestartet ist und wann diese abgeschlossen wurde. Somit lassen sich die Durchlaufzeiten der Karten statistisch erfassen. Man kann diese Statistiken dann später dazu für die Erfolgsmessung von Optimierungsmaßnahmen verwenden. Haben sich die Durchlaufzeiten reduziert? An welcher Stelle ging es schneller und so weiter. Dargestellt werden die Ergebnisse dann üblicherweise in einem so genannten Cumulative Flow Diagram (CFD), das die Anzahl der Karten in den einzelnen Prozessschritten über die Zeit veranschaulicht. Auf der X-Achse lässt sich dann ablesen, wie lange eine Karte durchgelaufen ist. Die Y-Achse zeigt dagegen die Anzahl der Karten in den einzelnen Prozess-Schritten. Die folgende Grafik zeigt ein fiktives Beispiel eines solchen CFDs.

Cumulative Flow Diagramn (CFD)

Je nach Bedarf kann man auch noch den pro Karte eingesetzten Aufwand erfassen und eine zusätzliche Statistik führen

Kanban und Projektmanagement

Auf den ersten Blick passen Kanban und klassisches Projektmanagement nicht zueinander. Kanban stellt einen kontinuierlichen Arbeitsablauf dar. Die Aufgaben werden nach Priorität abgearbeitet. Es wird selten mit Aufwandsschätzungen erstellt. Vielmehr lautet die Devise, dass die einzelnen Karten einen vergleichbaren Arbeitsaufwand abbilden sollten. Zwar gibt es auch in Kanban die Möglichkeit, Termine festzulegen, indem man Karten rechtzeitig in die Bearbeitung gibt und sie mit dem Prädikat "Fixed Date" versieht, doch unterscheidet sich diese Art der Terminplanung von bekannten Projektplanungsmethoden.

Wie kann nun trotz Kanban eine Projektplanung aussehen?

Dennoch wird die Festlegung und Planung von Terminen immer ein wichtiger Bestandteil der Entwicklung sein, dann auf Ebene des Managements werden verbindliche Zusagen benötigt. Eine Möglichkeit, dies zu erreichen, besteht darin, pro Karte einen mittleren Aufwand anzunehmen. Will man empirische Daten einbeziehen, dann kann man noch die aus der Statistik entnommenen durchschnittlichen Werte einsetzen und stetig aktualisieren. Je nach Zahl der Entwickler, die am Projekt arbeiten und je nach anfänglich angenommener Gesamtzahl der Karten für das Projekt ergibt sich die jeweilige Dauer des Projekts.

Was tun, wenn nicht alle Teams nach Kanban arbeiten?

Wenn nun nur ein Teil des Projekts per Kanban umgesetzt wird, dann muss man die einzelnen Komponenten im Plan in geeigneter Weise zusammenführen. Dies ist zum Beispiel dann notwendig, wenn die Softwareentwicklung nach Kanban arbeitet, die Grafik und die IT aber per Auftrag oder Ticketsystem. Eine Möglichkeit zur Zusammenführung besteht darin, die Planung des mit Kanban arbeitenden Teams wie oben beschrieben durchzuführen und die ermittelte Dauer als einen Vorgang im Gesamtprojekt abzubilden. Danach müssen noch die Abhängigkeiten zu den vor- und nachgelagerten Tätigleiten der anderen Teams abgebildet werden. In der Erfahrung hat sich gezeigt, dass ein solches Vorgehen durchaus erfolgreich sein kann.

Bewertung: Pros und Contras von Kanban

In der Praxis hat sich gezeigt, dass Kanban das Team vor Herausforderungen in der Einführungsphase stellt – gerade dann, wenn das Team klassisches Wasserfall-Projektmanagement gewohnt war. Sobald sich jedoch eine Vertrautheit mit Kanban einstellt und auch auf die regelmäßigen Retrospektiven und Verbesserungsrunden geachtet wird, steigert sich die Produktivität.

Das Schöne an Kanban ist die Transparenz: Man sieht jederzeit, woran gearbeitet wird und wo es hängt. Dies umso mehr, wenn konsequent Statistiken geführt werden. Dazu kommt ein hohes Maß an Flexibilität: Prioriäten können neu gesetzt werden, wenn es erforderlich ist. Neue Aufgaben können kurzfristig ergänzt werden.

Eine tatsächliche Herausforderung ist der Umgang mit festen Terminen, die so nicht in Kanban vorgesehen sind. Hier kommt die Verknüpfung zum klassischen Projektmanagement ins Spiel. Sofern diese Verknüpfung gelingt, ist Kanban eine sinnvolle und hlifreiche Methode, die Entwicklung schneller und flexibler zu machen, ohne auf eine gewisse Verlässlichkeit verzichten zu müssen.

Christian Kunz