Eine der häufigsten Fragen in meinen Kanban-Schulungen ist, ob Tickets eigentlich auch wieder nach links wandern dürfen. Und wie so häufig ist die Antwort ein klares „Kommt darauf an!“ Allerdings hat diese Antwort auch eine klare Tendenz. Denn eigentlich sollen Tickets in einem Kanban-System nur von links nach rechts wandern, beziehungsweise vom Commitment-Punkt in Richtung der Lieferung der Dienstleistung.
Sehen wir uns erst einmal die gestellte Frage etwas genauer an. Wieso sollte sich ein Ticket entgegen dem Strom bewegen? Nun, da fallen mir schon ein paar Dinge ein. Beispielsweise wird in einem Schritt entdeckt, dass in einer vorhergegangenen Aktivität ein Fehler unterlaufen ist. Das ist gar nicht so selten der Fall – gerade in der Softwareentwicklung ist es leider eher die Regel als die Ausnahme. Das häufig gelernte Verhalten ist dann: An den Bearbeiter zurückverweisen, der das Problem verursacht hat. Als Fehlerfinder ist man ja nicht betroffen oder verantwortlich!
Auf dem Kanban-Board würde das dann so aussehen, dass ein Ticket sich von rechts, wo der Fehler entdeckt wurde, zum Entstehungsort – der vorhergegangenen Aktivität – zurückbewegt: Entgegen dem Strom.
In Extremfällen wurde sogar beim Commitment ein Fehler gemacht: Ein Ticket, das eigentlich nicht hätte eingeplant werden dürfen, hat es geschafft, bearbeitet zu werden. Also zurück auf Los?
Es entstehen aus diesem Verhalten mehrere Probleme, weswegen die Kanban-Community eher eine Präferenz dafür hat, die Tickets nicht zurück zu bewegen.
Erstens muss eigentlich kontinuierlich der Status eines jeden Tickets inklusive seiner Bearbeitungshistorie mitgeführt werden. Was ist aktuell daran zu tun? Woher kommt es? Wohin geht es nach der Bearbeitung? Überspringt es gegebenenfalls bereits fertiggestellte Aktivitäten? Elektronische Werkzeuge wie Jira machen uns hier das Leben zwar relativ leicht. Aber auch hier muss jedes Mal die komplette Historie betrachtet werden, bevor wir eine Karte weiterbewegen können.
Zweitens, und das ist ein größeres Problem, verwischt die Denkweise, Dinge erst fertig zu stellen bevor etwas Neues begonnen wird. „Stop starting, start finishing.“ ist ein beliebter und prägnanter Ausspruch der Kanban-Praktiker. Wenn wir Dinge wieder nach vorne in den Wertstrom verschieben können, befreien wir uns selbst von der Last, uns um die Fertigstellung zu kümmern. Als Fehlerfinder geben wir die Verantwortung für die Fertigstellung problemlos ab und widmen uns einem neuen Ticket, das hoffentlich zur Verfügung steht.
Das größte Problem betrifft allerdings das initiale Scheduling: Die Reihenfolge, in der die Tickets eingeplant wurden, geht verloren, wenn wir sie zurück verschieben dürfen. Ich zeichne hier gerne das Bild einer Waschmaschine, die sich dann auf dem Kanban-Board bildet. Durch die Rotation und das ständige Vor und Zurück verknoten sich die Dringlichkeiten, Deadlines und Abhängigkeiten miteinander. Was am Ende herauskommt ist keine einigermaßen vorhersagbare Reihenfolge, sondern ein wilder Mix dessen, was vorne einmal strukturiert hineinging. Da können wir uns die Arbeit mit der Priorisierung auch schon fast sparen und die Tickets einfach ungeplant hineinwerfen. Das ist erst einmal total unintuitiv und normalerweise wird durch aktives Eingreifen in den Arbeitsprozess durch "Hochpriorisieren" oder ähnliches der Unordnung entgegen gewirkt. Damit wird das Arbeitssystem aber weiter anfällig für Variabilität: Sie wird ja geradezu zwanghaft hineingetragen! Variabilität erzeugt aber immer wieder Probleme mit der Geschwindigkeit und ganz besonders, der Vorhersagbarkeit.
Ein Problem, was nicht ignoriert werden sollte, ist die fehlerhafte Planung. Schieben wir ein Ticket zum Commitment-Punkt oder darüber hinaus zurück, brechen wir eine Zusage dem Auftraggeber gegenüber. Das ist für den gegebenenfalls unangenehm und schadet unserer Verlässlichkeit. Darüber hinaus haben wir auch schon Arbeit geleistet, die dann verloren ist: Investitionen, die sich nie lohnen werden. Das ist für einzelne Tickets zu verkraften, sollte eben aber nicht zum Standardverhalten werden.
Wie gehen wir also damit um? Es gibt verschiedene Szenarien, die sich etabliert haben und zu denen ich rate.
-
Bei Abbruch Retrospektive/Review
Abgebrochene Tickets sollte man nicht leichtfertig behandeln. Sie deuten auf Dinge wie ein fehlendes, wirtschaftliches Entscheidungsframework, spekulative Wetten auf die Zukunft, aber auch zu lange Durchlaufzeiten hin. Es ergibt durchaus Sinn, nach einem oder mehreren Tickets, die hinter dem Commitment-Punkt abgebrochen wurden, ein Review dieser Tickets durchzuführen. Es muss ergründet werden, warum die Tickets abgebrochen wurden und warum sie es bis zum Punkt des Abbruchs geschafft haben. Dann können Maßnahmen dafür entworfen und umgesetzt werden. -
An Ort und Stelle belassen und lösen
Tritt lediglich ein Fehler aus einer vorhergegangenen Aktivität hervor, ist es sinnvoll, das betroffene Ticket an der aktuellen Stelle hängen zu lassen und mit einer Visualisierung für Blockaden zu versehen. Hier endet allerdings die Verantwortlichkeit des aktuellen Bearbeiters nicht: Er oder sie sollte dazu ermutigt werden, das Problem beispielsweise im täglichen Standup zu erwähnen und Hilfe bei der Lösung einzufordern. Jetzt ist das Standup nicht der einzige Punkt, an dem Probleme besprochen werden sollten, aber es ist zumindest mal ein Anfang.
"Aber ich habe das Problem doch nicht verursacht!" Das bekomme ich immer wieder zu hören. Und es stimmt: Ich gebe da absolut Recht. Leider benötigen wir für eine kooperative Erbringung einer Dienstleistung Kooperation und einhergehend eine gemeinsame Verantwortung. Überprüfen Sie mal, ob Ihre Ziele, OKRs oder mit was auch immer gesteuert wird nicht der Zusammenarbeit entgegenwirken! - Mit einem Fehlerticket die Bearbeitung tracken
Eine Möglichkeit, den Fehlerfindenden von seiner Verantwortung etwas zu entbinden und ggf. andere Teile der Dienstleistung mehr zu integrieren, ist die Verwendung von sogenannten Bug-Tickets. Das sind Tickets, die unabhängig von Planungszyklen und WIP-Limits durch das Kanban-System wandern. Sie werden normalerweise präferiert gezogen – so geht die Dringlichkeit nicht verloren – und die Reihenfolge der Tickets bleibt ebenfalls einigermaßen verlässlich.
Zusatz
Für Punkt 2. und 3. gilt: Wir sollten Fehler nicht einfach leichtfertig als gegeben annehmen. Ich halte es hier mit Dr. Edwards Deming, der postulierte, dass die Abhängigkeit von Qualitätskontrollen eliminiert werden sollte. Stattdessen sollten wir Qualität von vorne herein in den Prozess einbauen. Das kann nur dann geschehen, wenn wir über die auftauchenden Probleme und Fehler regelmäßig reflektieren.
Aber warum denn eigentlich?
Drei Gründe sprechen für eine Fehlerbehebung vor Ort und eine regelmäßige Reflexion.
Erstens: Der Fluß der Arbeit wird aufrecht erhalten. Der Antrieb, ein stockendes Ticket zu bearbeiten und wieder zum Fließen zu bekommen, ist typischerweise höher als beispielsweise ein Ticket zu bearbeiten, das zum dritten Mal vorbeikommt.
Zweitens: Die Dringlichkeit und die Reihenfolge der Tickets wird hoch gehalten. Stocken mehrere Tickets an der gleichen Stelle, so sollte das ein Alarmsignal sein! Andere Tickets dürfen nicht überholen, das Problem muss erst gelöst werden. Vielleicht verbirgt sich ja auch ein systematisches Problem dahinter!
Drittens: "Ticket-Pingpong", wie das Verhalten in der IT manchmal genannt wird, wird als ungewünschtes Verhalten offengelegt. Stattdessen soll fokussiert am Fortschreiten des Tickets gearbeitet werden. Spezifische und systematische Probleme sollen angegangen werden. Kanbans drittes Prinzip des Veränderungsmanagements tritt hier ganz deutlich hervor: "Ermutige Führungsverhalten auf allen Ebenen."
fazit
Tickets sollten möglichst nicht nach links zurückgehängt werden, bzw. einfach dem ursprünglichen Bearbeiter zurück zugewiesen werden. Elektronische Werkzeuge wie Jira machen das allerdings zu leicht, weil zum einen Workflow und Bearbeiter häufig zu eng miteinander modelliert werden. Zum anderen suggerieren die Workflow-Namen häufig auch die Stelle, an der die Verantwortung aktuell getragen wird.
Auch aus Gründen der verbesserten Kooperation präferiere ich übrigens die Strategie, ein Ticket zu blockieren und spätestens im Standup über die Lösung des Problems zu sprechen. Sie ermöglicht eine schnelle Erarbeitung einer Lösung, Improvisation zugunsten der Geschwindigkeit und eine kurze Beurteilung, ob das Problem systemisch oder nur individuell behoben werden kann oder muss.
Der Nutzen ist ein Arbeitsfluss, der kontinuierlich weiterentwickelt wird, geteilte Verantwortung und kooperatives Arbeiten, wo dies Sinn ergibt.