Auch wenn ich persönlich ein Fan physischer Kanban-Boards bin1: In Zeiten zunehmend räumlich verteilter Teams und nun auch vermehrt des Homeoffices sind Softwarelösungen für Kanban-Boards fast unumgänglich2. Eine interessante Folge davon: Was im Falle physischer Boards des hohen Aufwandes und des Platzbedarfs wegen vermieden werden würde3 – das Anlegen neuer, zusätzlicher Boards – ist im Falle eines software-basierten Boards trivial und wird dementsprechend häufig getan. Gerade im Falle der eher projektorientierten Arbeit gibt es dann häufig ein Task-Board4 pro Projekt. Ich halte das aus mehreren Gründen für ungünstig wenn nicht gar fatal:
- Ist nicht ein Projekt (oder Prozess) nur genau einem Team zugeordnet, findet sich die Arbeit einzelner Teammitglieder zwangsläufig auf mehreren Boards. Der Einzelne hat also keine ganzheitliche Sicht auf seine Aufgaben – und es ist auch nur schwer zu erkennen, wer welche Arbeitslast hat. Gegenüber einer Lösung mit nur einem Board geht also der Überblick verloren und das, was u. a. Kanban für mich ausmacht – das Managen der Arbeit (und nicht der Menschen) auf Basis der Leistungsfähigkeit des Systems (und letztlich der Menschen) –, wird dadurch fast unmöglich. Lösbar wäre das natürlich durch ein ausgeklügeltes Reporting – aber das ist eben nicht die einfache und klare Sicht auf den Fluss am (einen) Board und erscheint mir nicht als gute Grundlage für echte Selbstorganisation.
- Ist ein einzelner Mensch mit seiner Arbeit auf mehreren Boards vertreten, dürfte also ein ähnlicher Effekt wie bei „Teilzeit-Scrum“5 auftreten – und der Konflikt zwischen Projekt‑, Betriebs- und Support-Arbeit6 dürfte sich eher verschärfen.
- Arbeite ich mit mehreren Boards, werden WIP-Limits7 pro Spalte bzw. Prozessschritt und eine Arbeitsorganisation per „Pull“ sehr schwer sinnvoll umsetzbar: Ich sehe ja auf dem einzelnen Board nicht die freie Kapazität; auf Basis nur eines Boards kann ich keine sinnvolle „Pull“-Entscheidung treffen. Dies gilt insbesondere, wenn die Arbeit Einzelner sich auf mehrere Boards verteilt (s. o.).
Wirklich sinnvoll erscheint es mir aus diesen Gründen, nur dann unterschiedliche Boards einzusetzen, wenn diese auch unterschiedlichen, sich personell nicht überlappenden Teams zugeordnet sind – sich jeder Mensch mit seiner Arbeit also nur auf genau einem Board wiederfindet. Stattdessen einzelne teamübergreifende „Projekt-Boards“ einzurichten, bremst m. E. die Weiterentwicklung von einer reinen „Task-Verwaltung“ zu einem echten Kanban-System massiv aus oder verhindert sie sogar.
Footnotes:
- ↑ Die Sichtbarkeit ist einfach größer, vgl. <https://www.kanbwana.de/2018/06/26/warum-haptische-boards-so-cool-sind/> (20.05.2021).
- ↑ Und dementsprechend verbreitet – vgl. bspw. den „State of Kanban 2012“-Report unter <https://resources.kanban.university/life-is-better-with-kanban-get-the-state-of-kanban-results/> (23.05.2021).
- ↑ In den meisten Fällen würde stattdessen vermutlich eine neue Swimlane eingeführt.
- ↑ Um bewusst nicht von „Kanban-Board“ zu sprechen.
- ↑ Vgl. „Warum ‚Teilzeit-Scrum‘ m. E. nur das Problem verlagert, Zielkonflikte verursacht und nicht effizient ist“ hier im Blog.
- ↑ Vgl. „Kamishibai in der IT“ hier im Blog.
- ↑ Vgl. „Little’s Law – wie man WIP-Limits möglichst nicht erklärt und wie es vielleicht besser geht“ hier im Blog.