Der Arbeitsplatz im Büro ähnelt manchmal einer papiernen Wüste. Hier und da machen sich abstehende neon-gelbe Pappzettel bemerkbar. Sie wirken wie Oasen in der Wüste und versuchen so die Unmenge an unterschiedlichen Aufgaben zusammenfassend darzustellen. In den meisten Fällen ist es wirkungslos, weil sie vom weiteren Papierstapel zugedeckt werden.

Nicht so bei Kanban – einem Vorgehen in der Softwareentwicklung, welches die kleinen Gedächtnisstützen als Medium in der Ticketverwaltung einsetzt. Diese gelben Zettelchen werden auf eine Tafel (sog. Whiteboard) geklebt und zeigen den Fortschritt des Projektes an.

Ein schönes Beispiel für diese Praxis liefert stackoverflow. Eine weiße Tafel ist aufgeteilt in Spalten: Backlock (Ideenpool), ’selected‘ (Vorauswahl – nicht unbedingt notwendig), Entwicklung (unterteilt in: ‚in Bearbeitung‘ und ‚fertig‘), Testen (mit ähnlicher Unterteilung wie Entwicklung) sowie Freischaltung. Die Anzahl und Namen der Spalten dürfen ein wenig modifiziert werden, aber bleiben fast immer dazu vergleichbar.

Im Backlog stauen sich Ideen und Tickets. Hier werden sie auch meist vorsortiert und nach Priorität geordnet. Die Prioritäten kommen meist auch in der Farbe der Zettel zum Ausdruck. Eine Farbe bekommt immer den Vorrang: sie signalisiert eine Störung, die sofort beseitigt werden muss. (Auch Psychologen sagen: „Störungen haben Vorrang“, weil sie eine normale Entwicklung verhindern.)

Die Tickets (zu erledigende Aufgaben, die aus mehreren Tasks bestehen können) werden von den Zuständigen „gezogen“ (das Pull-Prinzip). Jeder Zuständige oder jedes Team kann prinzipiell nur ein Ticket bearbeiten. Manchmal sind auch 2 möglich. Diese Begrenzung, die auch für den Chef gilt, nennt sich: Work in Progress (WiP). Es ist somit nicht möglich, einem bestimmten Angestellten unter Zwang etwas zuzuordnen oder mehr zuzuordnen als das WiP es erlaubt. Das schützt nicht nur ihn, sondern auch sein Kollegen, weil „gepushte“ Aufgaben oft zurecht von den Zuständigen als „für später“ zurückgelassen wurden: sei es wegen Abhängigkeiten, aktueller Arbeitsbelastung oder mangelnder Reife eines Tickets. (Schnell unter Druck an Kollegen vorbei abgearbeitete Tickets sorgen oft für Fehler, Zerstörung der gemeinsamen Wissensbasis und Stress.)

Das schöne ist, dass auch die Chefs (meist BWLer mit tausenden von innovativen Ideen) eine Spalte für ihre Ideen bekommen (wo die Tickets ständig ihre Priorität wechseln dürfen) und eine, die für die Dauer der Ausgestaltung und zur genauen Beschreibung, wie es überhaupt umgesetzt werden soll. Diese vorselektierten Beschreibungen des Was und der Wie wird zur Umsetzung von den Programmierern angenommen. Manchmal kann es sogar passieren, dass die Zettelchen zurückwandern (weil zu ungenau). Bei größeren Vorhaben wird es intern womöglich erst im gesamten Team besprochen und designed bevor auch eine Zeile Code entsteht. Erst, wenn man glaubt, alles erledigt zu haben, schiebt man es zu „fertig“. Der Tester nimmt es an und erkennt möglicherweise Mängel. Der Schwarze Peter muss nun zurück – aus diesem Grund sollte man auch nicht mehr als ein Ticket annehmen (wegen des möglichen Rücklaufs).

Was ist der Vorteil von dem Ganzen?

  1. Die Dauer des Entwicklungszykles ist messbar
  2. Messung der Wartezeit zeigt schnell, wo Verstärkung notwendig ist (sog. Bottlenecks)
  3. Es gibt keine persönliche Schuld für die zu lahme Entwicklung (vor allem in Asien – wo Kanban herkommt – ist das sehr wichtig)
  4. Kurze Release-Zeiten
  5. Time-Boxes (vorgegebene Zeiteinheiten pro Schritt) sind nicht nötig aber möglich (bei Termin-gebundenen Entwicklungen)
  6. Kanban ist auf die kontinuierliche Verbesserung ausgerichtet
  7. Es sorgt für eine gleichmäßige Auslastung der Mitarbeiter (im Optimalfall)
  8. Keiner wird überfordert, die Arbeit macht wieder Spaß: jeder holt sich das, was er kann und mag bis die unliebsamen Aufgaben kommen.
  9. Priorität ist nicht alles, zeigt aber die Laufrichtung
  10. Es passt zu agilen Vorgehensweisen.

Wo sind die Schwachstellen?

  1. Es schützt nicht vor Abhängigkeiten zwischen den Tickets, aber schützt vor Rückentwicklung fertiger Tickets (was manchmal noch komplizierter ist als die Fertigstellung)
  2. Auch der Chef muss sich begrenzen wollen. Tut er das nicht, hilft auch Kanban nicht. Demoralisierung und Streit im Team können nur verhindert werden, wenn sich der Chef als „primas inter pares“ versteht.
  3. Es beseitigt keine Unterbesetzung, es zeigt sie nur auf. (Aber das müsste eigentlich jedem klar sein.)

Ich finde, es ist eine genial-einfache Idee, die man ausprobieren sollte. Es ist nicht starr und gut anpassbar in vielen Bereichen.

Eine Liste von Software für Kanban finden sie hier.

Mein Favorit ist das Kanban-Tool. Außer dem obligatorischen Whiteboard besitzt es viele Reporting-Optionen, die die Analyse der Schwachstellen erleichtern.