Viele Teams nutzen für die Visualisierung des Workflows und der Tasks, die gerade bearbeitet werden, ein Whiteboard, auf dem der sog. Value Stream abgebildet ist. Tasks sind als Klebezettel dargestellt, die von links nach rechts über das Board wandern. Der einfachste Value Stream, also die generischste aller Wertschöpfungsketten, lautet dabei TODO, Doing, Done. TODO ist meist eine umfangreiche Liste an Dingen, die demnächst oder irgendwann geschehen sollen, oft Backlog genannt. „Doing“, also die Aufgaben, die gerade in Bearbeitung sind, wird gern auch als „In Progress“ bezeichnet. So hat man ein Taskboard, auf dem man jederzeit einen guten Überblick erhält, was gerade in Arbeit ist, wo Staus im Arbeitsfluss entstehen usw.
Warum „On Hold“ Gift ist
Es ist nicht selten, dass Teams mit einem weiteren Status, i.e. einer Spalte arbeiten, der „On Hold“ heißt. Hier werden Tickets geparkt, die derzeit nicht weiter bearbeitet werden können, weil sie auf etwas warten. Zum Beispiel auf die Zulieferung einer anderen Abteilung, eine Information vom Kunden oder die Beendigung eines anderen Tickets, zu dem eine Abhängigkeit besteht.
Das klingt zunächst plausibel, weil so visualisiert wird, welche Tickets wirklich gerade bearbeitet werden, und für welche die Bearbeitung pausieren muss. „On Hold“ ist aber eine vergiftete Idee und hier sind die drei Argumente, warum das so ist:
- „On Hold“ bläst die Menge der Arbeit auf, die derzeit (gleichzeitig!) in Bearbeitung ist. Das ist schlecht.
- „On Hold“ ist ein Anzeichen, dass die Anforderungsdefinition nicht zufriedenstellend war. Das sollte man ändern.
- „On Hold“ ist ein Anzeichen, dass versteckte Abhängigkeiten aufgetaucht sind, als die Tickets schon in Arbeit waren. Das sollte man ändern.
So, jetzt habe ich weit genug ausgeholt, um meinen tödlichen Schlag gegen „On Hold“ zu führen, auf geht’s.
„On hold“ bläst das „Work in Progress“ auf
Was das gezeigte Taskboard heuptsächlich von einem Kanban-Board unterscheidet, ist das Fehlen von sog. Work-in-Progress-Limits, WIP-Limits. Die Logik dabei ist einfach: Je mehr wir gleichzeitig in Arbeit haben, desto länger dauert es, bis die Sachen fertig werden und desto mehr müssen die Bearbeiter vermutlich von Task zu Task springen. So ein Task-Switching ist mental aufwendig („dauernd wird man rausgerissen!“) und ineffizient. Falls die Bearbeiter nicht von Task zu Task springen, sondern jeweils einen Task fertig machen, ist das ein intelligentes und effizientes Vorgehen, und dann kann man gleich nur so viel Tasks in progress nehmen, wie viel tatsächlich gleichzeitig bearbeitet werden können, also einen pro Bearbeiter. Die Devise lautet: Stop starting, start finishing. Solange wir etwas nicht fertig machen können, brauchen wir es auch nicht anfangen. Die Versuchung ist groß, weil das Reporting „wir schon X angefangen“ besser klingt als das Reporting „wir haben X noch nicht angefangen“. Es verschleiert aber, dass X und alle anderen Tasks langsamer fertig werden, je mehr wir gleichzeitig anfangen. Deshalb: Limit Work in Progress!
Was passiert nun, wenn wir Tickets in „On Hold“ haben? Im besten Fall kommt die fehlende Information, um das Ticket weiter zu bearbeiten, relativ schnell. Trotzdem haben wir derweil neue Tickets angefangen, weil wir ja nicht leerlaufen wollen. Nun haben wir plötzlich mehr Tickets in progress, müssen task-switchen und alles wird langsamer. Besser wäre es doch gewesen, wir schieben das Ticket, das warten muss, zurück nach TODO. „On Hold“ hat keine Vorteile, sondern nur Nachteile.
„On Hold“ ist ein Zeichen für ungenügende Anforderungsdefinition
Wieso ging das Ticket überhaupt auf „On Hold“? Oft ist der Grund: Wir haben jetzt erst gemerkt, dass dies und das noch unklar ist oder dies und jenes noch fehlt. Aber hallo?! Das ist alarmierend. Das heißt, wir können, wenn wir etwas anfangen, nicht sicher sein, dass wir es fertig machen können. Das heißt, wir lassen halbfertige Arbeit liegen, müssen task-switchen, blasen das WIP auf usw. Das ist nicht gut.
Das sollten wir nicht hinnehmen, indem wir das Ticket non-chalant auf „On Hold“ schieben. Das sollte als Alarm sichtbar werden, um uns anzuhalten, erstens das Problem so schnell wie möglich zu lösen und zweitens daran zu arbeiten, dass so etwas zukünftig weniger oft bzw. nicht mehr passiert. Lasst uns also lieber einen auffälligen roten Klebezettel für „Blockiert“ auf den Task-Zettel machen.
„On Hold“ ist ein Zeichen für unentdeckte Abhängigkeiten
Naja, was heißt hier unentdeckt, wir haben die Abhängig doch entdeckt? Ja, aber erst, als wir das oder sogar die abhängigen Tickets schon bearbeiten. Das ist ein schlechter Zeitpunkt. Wir sollten unseren Anforderungsdefinitionsprozess verbessern, um Abhängigkeiten so früh wie möglich zu entdecken, damit wir sie managen können. Softwareentwickler sind sich einig, dass Abhängigkeiten eines der zentralen Probleme in der Softwareentwicklung sind, aber auch für Nicht-Software-Tasks gilt höchstwahrscheinlich: Kenne die Abhängigkeiten und organisiere entsprechend. Warte nicht, bis dich zuvor unentdeckte Abhängigkeiten in Schwierigkeiten bringen.
Auch hier finde ich, das Ticket einfach in Warteposition nach „On Hold“ zu schieben, wird der Ernsthaftigkeit der Sache nicht gerecht. Das Ticket ist blockiert, weil wir vorher nicht gründlich genug geforscht, nachgedacht, gearbeitet haben. Um zielstrebig vorwärts zu kommen, müssen wir das Abhängigkeitsproblem so schnell wie möglich lösen. Und analysieren, wie wir solche Abhängigkeiten in Zukunft früher identifizieren können. Lasst uns also lieber einen auffälligen roten Klebezettel für „Blockiert“ auf den Task-Zettel machen.
On Hold muss weh tun! Blocker tun weh
Aus den dargestellten Gründen finde ich, dass „On Hold“ ein Alarmzeichen ist. Ein Zeichen für eine Schwäche in unseren Prozessen. Das muss weh tun. Das muss man schrill sichtbar darstellen und sofort aktiv werden. Deshalb bin ich grundsätzlich gegen „On Hold“ und denke, wenn man Tickets, die warten müssen, als blockiert betrachtet und diese Blockade als ein Signal für unmittelbaren Handlungsbedarf, wird man der Problemlage gerechter als mit der Schutthalde, die „On Hold“ letztlich repräsentiert.
