Wenn „To Do“ und „Done“ fehlen …

Struk­tu­riert man sein Task- oder Kan­ban-Board, beginnt der Work­flow nahe­lie­gen­der­wei­se häu­fig mit einer „To Do“ oder „Backlog“-Spalte und endet mit einer „Done“-Spalte – und alles dazwi­schen ist mehr oder min­der „WIP“, „Work in Progress/​Process“, ggf. in meh­re­ren Schritten:

Etwas, das man auf phy­si­schen Boards gele­gent­lich sieht, mir aber im Fal­le von Soft­ware-Boards tat­säch­lich kaum begegnet​¹, ist eine Tren­nung sämt­li­cher ein­zel­ner Spal­ten im „WIP-Bereich“ (bis auf die Spal­te vor der „Done“-Spalte) in „To Do“ und „Done“ bzw. (m. E. deut­li­cher) in „In Pro­gress“ und „Rea­dy“​²:

Was auf den ers­ten Blick unnö­tig (über‑)​komplex wirkt, hat je nach Arbeits­wei­se jedoch gro­ße Vor­tei­le: Ohne die­se Unter­tei­lung ist auf dem Board nicht sicht­bar, ob ein Arbeits­schritt abge­schlos­sen oder noch in Arbeit ist – es sei denn, der Bear­bei­ter schiebt die Kar­te nach Abschluss ein­fach in die nächs­te Spal­te. Letz­te­res ist aber poten­ti­ell nicht mög­lich, ist die nächs­te Spal­te bzw. der nächs­te Arbeits­schritt WIP-limi­tiert – und die Kar­te nach Abschluss des Schritts ein­fach wei­ter­zu­schie­ben, ist auch eher als „Push“ denn als „Pull“ zu betrach­ten. Sofern ein­zel­ne Arbeitsele­men­te („Kar­ten“) expli­zit und fest über den gesam­ten Arbeits­fluss nur genau einer Per­son zuge­ord­net sind, mag die­se Intrans­pa­renz der Dar­stel­lung noch zu ver­kraf­ten sein, spä­tes­tens aber, wenn die ein­zel­nen Arbeitsschrit­te ver­schie­de­nen Per­so­nen zuge­ord­net sind, wird sehr viel Abstim­mung zwi­schen den Betei­lig­ten not­wen­dig, um das Sys­tem nicht aus­ge­rech­net im „WIP-Bereich“ aus Ver­se­hen zu einem „Push“-System zu machen und jede Form von WIP-Limi­tie­rung zu erschweren.

Eric Brech­ner geht übri­gens gar so weit, das Feh­len die­ser Unter­tei­lung als Kanban-„Anti-pattern #1“ zu bezeichnen​³ – und bedenkt man, wie sel­ten die­se Unter­tei­lung trotz ihrer offen­kun­di­gen Rele­vanz zu fin­den ist (Goog­le-Bil­der­su­che), könn­te er damit durch­aus recht haben.

Nun könn­te man natür­lich ein­wen­den, dass die durch das Feh­len die­ser Unter­tei­lung man­geln­de Trans­pa­renz an die­ser Stel­le ja durch die Abstim­mun­gen im (womög­lich täg­li­chen) Kan­ban-Mee­ting ersetzt wür­de, man sich schon bespre­che und das dann qua­si von allein funk­tio­nie­re. Dem möch­te ich aller­dings aus min­des­tens zwei Grün­den widersprechen:

• Ist erst nach dem Kan­ban-Mee­ting klar, wel­che Kar­ten „wei­ter­wan­dern“, wird auto­ma­tisch eine Art „Takt“ vor­ge­ge­ben, der das Arbeits­sys­tem poten­ti­ell erheb­lich bremst. Mit Arbeit, für die Kapa­zi­tät vor­han­den ist, zu war­ten, bis ein Mee­ting statt­ge­fun­den hat, erscheint mir wenig fluss­ori­en­tiert und wenig effizient.

• Der Fokus des Kan­ban-Mee­tings soll­te m. E. auf mög­li­chen Blo­ckern lie­gen; Abstim­mun­gen über den „nor­ma­len“ Fluss soll­ten kaum nötig sein – denn u. a. genau dafür gibt es ja die Visua­li­sie­rung des Arbeitsflusses.

Min­des­tens an den Punk­ten, an denen sys­tem­im­ma­nent poten­ti­ell ein Wech­sel des Bear­bei­ters stattfindet​⁴, soll­te also eine Unter­tei­lung der Spal­ten in „To Do“ und „Done“ erfolgen​⁵. Der­je­ni­ge, der einen „Pull“ in die nächs­te Spal­te erwägt, kann dadurch auf den ers­ten Blick sehen, ob ein Schritt erle­digt und zumin­dest die aus­schließ­lich auf das Arbeits­ele­ment bezo­ge­nen Pull-Kri­te­ri­en erfüllt sind – m. E. eine der Grund­vor­aus­set­zun­gen für ein funk­tio­nie­ren­des „Pull“-System. Zudem ist trans­pa­rent, ob sich Arbeit in einem Schritt bzw. einer Spal­te „sta­pelt“, weil der Schritt nicht abge­schlos­sen wur­de oder weil (bei­spiels­wei­se auf­grund von WIP-Limits) ein­fach nur kein „Pull“ in den fol­gen­den Schritt erfolgt ist.