Situationsbedingt komme ich mit meiner Präferenz für physische, „haptische“ Kanban-Boards im Moment nicht weit; die pandemiebedingte Verbreitung von Home Office macht digitale Lösungen geradezu notwendig. Bei der nun vermehrten Auseinandersetzung mit Kanban-Software fällt auf: Praktisch jede Lösung am Markt offeriert zusätzlich zur Visualisierung des Arbeitsflusses am eigentlichen Kanban-Board eine Darstellung als Gantt-Diagramm und wirbt oftmals sogar damit – was für eine absurde, das Werkzeug seines Kerns entkleidende Methoden-Chimäre!
- Kanban – per se übrigens keine Projektmanagement-Methode, sondern eine generische Methode, beliebige Arbeitssysteme zu managen – ist flussorientiert und pull-basiert:
-
-
- Die Visualisierung am Board zeigt den Fluss beliebiger Arbeitseinheiten durch den Arbeitsprozess, nicht aber deren Abhängigkeiten oder gar Termine. Abhängigkeiten existieren an der Kanban-Tafel allerhöchstens als (den Fluss störende) Blocker1; nutzt man Kanban im Projektmanagement, werden Abhängigkeiten meist bereits beim regelmäßigen Replenishment berücksichtigt, um im eigentlichen Arbeitsfluss möglichst keine Rolle zu spielen. Bestimmen vor allem komplexe Abhängigkeiten mein Projekt, ist Kanban m. E. für das Management dieses Projektes mindestens nicht ausreichend, wenn nicht gar ungeeignet.
-
-
-
- Wichtige Aspekte einer Kanban-Implementierung sind in aller Regel die Begrenzung der gleichzeitigen Arbeit („WIP“, vgl. bspw. hier) und die Etablierung eines Pull-Systems: Nicht Termine entscheiden, wann mit der Bearbeitung einer weiteren Arbeitseinheit begonnen wird, sondern einzig und allein die Kapazität des Systems. „Himmelfahrtskommandos“ mit völlig arbiträren Terminzusagen sollten mit Kanban kaum möglich sein; eine [Termin-]Zusage („Commitment“2) erfolgt (nur) genau dann, wenn auch Kapazität verfügbar ist. Der Abschluss einer Arbeitseinheit ist also auch frühestens nach dem Commitment Point planbar, vorher existiert dafür kein Termin – und jeder Termin, den man trotzdem geplant hat, wäre schlichtweg geraten.
-
- Gantt-Diagramme wiederum sind im Kern ein Zeitstrahl: [Start-]Termin und Dauer der jeweiligen Arbeit[spakete] werden entlang einer kalendarischen Skala aufgetragen, Abhängigkeiten ggf. durch Verbindungen visualisiert. Möchte ich ein Gantt-Diagramm erstellen, müssen also mindestens die ersteren beiden Informationen vorliegen – die Arbeit fest terminiert und der Aufwand bestmöglich geschätzt sein. Die Tatsache, dass Gantt-Diagramme über Jahrzehnte von Hand auf Papier gezeichnet wurden und dementsprechend im Falle von Terminverschiebungen komplett neu gezeichnet werden mussten3, verdeutlicht, wie stark deterministisch die Weltsicht hinter dieser Planungstechnik ist. Im Ergebnis dürfte gelten: Wirklich exakt ist der Balkenplan sowieso nur in der Retrospektive. Nicht ohne Grund übrigens mutet diese Sicht auf die [Projekt-]Zukunft geradezu tayloristisch an: Henry L. Gantt arbeitete lange mit Frederick W. Taylor zusammen und gilt als einer der Begründer des Scientific Managements.
Automatisiert aus den Inhalten eines Kanban-Boards ein Gantt-Diagramm zu erstellen, ist also unmöglich, habe ich nicht mindestens bereits alle Arbeit terminiert und geschätzt, idealerweise die Abhängigkeiten bestimmt und alle diese Information in den Tickets hinterlegt. Tickets ohne diese Informationen (also i. d. R. zumindest alle Tickets vor dem Commitment Point) könnten im Gantt-Diagramm nur quasi freischwebend auf der Start-Linie des Zeitstrahls festhängen – eine ziemlich sinnlose Visualisierung. Terminiere ich aber alle Arbeitseinheiten, habe ich definitiv kein Pull-System mehr, Termine werden wichtiger als WIP-Limits und jede Form von Selbstorganisation rückt zudem in weite Ferne – und ohne jetzt an dieser Stelle ausschließlich die „reine Lehre“ propagieren zu wollen: „Agile“ im Sinne von „Reagieren auf Veränderung mehr als das Befolgen eines Plans“4 ist sicherlich etwas anderes. Arbeit fest zu terminieren ist eine Form von „Push“ – vor allem, wenn ich mich bereits vor dem eigentlichen Commitment Point festlege.
Kann man problemlos seine Kanban-Tickets in ein plausibles Gantt-Diagramm wandeln, nutzt man vielleicht ein Kanban- oder besser Task-Board5, m. E. aber nur sehr begrenzt die Kanban-Methode – und managt man die Arbeit nicht wirklich flussorientiert, erscheint mir ein Task-Board nebenbei bemerkt eine ausgesprochen wenig sinnvolle Visualisierung, geradezu eine MeToode.
Sollte Ihre Kanban-Software eine Gantt-Funktionalität haben: Schalten Sie sie ab! Gibt es daraufhin Proteste (vermutlich meist von der Führungsebene): Das ist eine wirklich wunderbare Gelegenheit, Konzept und Wirkungsweise eines WIP-limitierten Pull-Systems zu diskutieren!
Würde ich Kanban überhaupt um eine weitere Darstellungsform für die anstehende Arbeit ergänzen wollen, wäre das wohl ein (stark vereinfachter) Netzplan (ohne Termine) – die Abhängigkeiten auf den ersten Blick erkennen zu können, würde womöglich manchmal das Replenishment wirklich vereinfachen. Den Zustand eines Kanban-Arbeitssystems aber in Form eines Gantt-Diagramms dazustellen, ist wirklich widersinnig und widerspricht fast allem – zerstört womöglich gar fast alles –, was Kanban aus- und wirksam macht.
Footnotes:
- ↑ Zum Umgang mit Abhängigkeiten vgl. bspw. <https://www.kanbwana.de/2020/04/30/podcast-mit-abhängigkeiten-umgehen/> (19.09.2020).
- ↑ Vgl. bspw. <https://www.kanbwana.de/2020/03/27/podcast-commitment-replenishment/> (19.09.2020).
- ↑ Seinen Siegeszug hat das Gantt-Diagramm also wohl erst mit der Digitalisierung des Projektmanagements angetreten. Vgl. bspw. <https://www.apm.org.uk/blog/a‑brief-history-of-gantt-charts/> (08.11.2020) und <http://projekt-manager.eu/projektmanagement/balkenplan.html> (08.11.2020).
- ↑ Vgl. <https://agilemanifesto.org/iso/de/manifesto.html> (08.11.2020).
- ↑ Ich neige insbesondere im Zusammenhang mit Scrum dazu, von einem „Task-Board“ zu sprechen und den Begriff „Kanban“ zu vermeiden. Dazu, wie sich Scrum und Kanban effektiv und effizient kombinieren lassen vgl. <https://www.scrum.org/resources/kanban-guide-scrum-teams> (08.11.2020).