Eine Kampfansage: Blocker statt „On Hold“ für Kanban- und Task-Boards

Der Status "On Hold" ist ein Problem. Er sollte durch Blocker ersetzt werden. Egal, ob man Kanban verwendet oder nur einfach einen Workflow mit einem Taskboard: "On Hold" ist des Teufels. Hier die Argumente...

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.

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.

 

Taskboard mit OnHold-Spalte

 

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.

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!

 

Alle On-Hold-Tickets gleichzeitig reaktiviert

 

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.

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.

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.

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.

 

Taskboard mit Blockern

Neueste Posts

Schnelle Tipps für gutes UX-Writing Adobe beschleunigt Experience Driven-Commerce mit zentralen Neuerungen in Magento Commerce Cloud PHP Developer Days 2018 – Ein Erfahrungsbericht Wie Sie zum Top 5% Projektmanager werden Was sind gute Fragen?

Archiv

Oktober September August Juli Juni Mai April März Februar Januar
Dezember November Oktober September August Juli Juni Mai April März Februar Januar
Dezember November Oktober September August Juni Mai April Februar Januar
Dezember November Oktober September August Juli Juni März Februar
Oktober September August Juli Juni Mai April März Januar
Dezember November Oktober September August Juli Mai April Februar
November Oktober September April Februar
Dezember September Juni Mai Februar Januar
Juli Mai April März Februar Januar
September August Juli März
Oktober September Juli Juni Mai März Februar
Februar

Kategorien

E-Commerce Unternehmensmeldung Online-Marketing Magento Commerce Neos TYPO3 SEO SEA Usability Digitale Transformation Agile Projektentwicklung Corporate Web Analytics Künstliche Intelligenz Mobile Marketing Social Media Veranstaltungen Research & Development
powered by YouTube: Beim Abspielen des Videos wird eine direkte Verbindung zu einem Server von YouTube aufgebaut. Näheres erfahren Sie in unserer Datenschutzerklärung.

Unser Herz schlägt online -
Deins Auch?

 

Wir stellen uns jeden Tag neuen Heraus-forderungen des Online-Business – immer auf der Suche nach spannenden Lösungs-ansätzen und sinnvollen Technologien. Eine Vielzahl namhafter Kunden vertrauen auf das Online Know-how „Made in Kolbermoor / Rosenheim und München“. 

Lust auf TechDivision? Hier geht zu unseren Stellenanzeigen

eStrategy Magazin


Erfahren Sie mehr zu den Themen E-Commerce, Online-Marketing, Mobile, Projektmanagement, Webentwicklung und E-Recht in unserem kostenlosen Online-Magazin.

Jetzt herunterladen!

Whitepaper:
Agiles Projektmanagement


In unserem kostenlosen Whitepaper versuchen wir Basiswissen und Erfahrungen aus vielen Jahren täglicher Projekt- und Unternehmenspraxis zu vermitteln, mit denen Sie die Anforderungen des Arbeitslebens von Heute besser bewältigen können.

Jetzt herunterladen!

Autor

Haben wir Ihr Interesse mit unserem Blog geweckt?

Wir sind der richtige Partner für anspruchsvolle Projekte im Bereich E-Commerce, Corporate Web, Consulting und Online-Marketing. Sprechen Sie mit uns!

Autor

Sacha Storz Agile Coach