Podcast: Darf ich eigentlich...

"Darf ich eigentlich..." ist einer der häufigsten Anfänge bei Fragen, gerade wenn Menschen erste Erfahrungen mit der Kanban-Methode machen. Es gibt keine Gesetze, aber ein paar Erfahrungen, die in dieser Folge besprochen werden.

Fragen, Meinungen, Anregungen? Gerne an post@florianeisenberg.de

Viel Spaß!

Immer mal wieder werde ich Fragen gefragt, die mit "Darf ich eigentlich..." anfangen. Nun, als allererstes: Ich mache hier ja keine Gesetze, sondern gebe Empfehlungen und Erfahrungen. Zweitens dann: Es gibt keine Kanban-Polizei, die dann die Exekutive zu meiner nicht existenten Legislative übernimmt.

Das Dumme daran ist: Es muss jeder für sich selbst herausfinden, ob das, was er oder sie da veranstaltet, eine schlaue Idee für den eigenen Kontext ist.

Nichtsdestotrotz und wie gesagt: Ich kann ein paar Empfehlungen geben.

Lieber zuhören? Hier ist der Podcast:

Schauen wir uns doch jetzt mal eine dieser Fragen an. Sie lautet:

"Darf ich eigentlich schon bei der Systemmodellierung verändern oder verbessern?"

Da gibt es zwei Interpretationen – jetzt bin ich ja auch noch in der Judikative... Aber klären wir erst mal, worüber wir sprechen. Die "reine Lehre" sagt, dass wir unser Arbeitssystem erst mal so abbilden sollen, wie es eigentlich wirklich gelebt wird. Dann sollen wir beobachten, was denn eigentlich Auslöser der Unzufriedenheiten sind und an diesen Punkten dann intervenieren. Das wird in Kanban-Schulungen auch immer wieder genau so gelehrt. Ist auch richtig und trotzdem gibt es auch noch eine andere Perspektive. Stell dir vor, du hast einen oder zwei Tage investiert, gegebenenfalls sogar noch eine Schulung beauftragt oder besucht, und ein Arbeitssystem modelliert. Jetzt wirst du gefragt, was denn dieses Kanban gebracht hat. Da dann nur antworten zu können, dass du jetzt das System besser kennenlernst, kann durchaus fraglich sein. Klingt ein bisschen viel nach Selbstbeschäftigung und -Erfahrung.

Es gibt also auch die, die dann empfehlen, gleich Änderungen umzusetzen, wenn denn zumindest für alle ersichtlich ist, dass da die Veränderung auch Positives bewirken könnte. Wenn du also beispielsweise einen Arbeitsablauf modellierst und der hängt an der Wand und alle sagen: "Das ist ja Quatsch, da müssten wir was vertauschen, weil das bisherige Vorgehen XYZ zu einem Problem führt" dann kann man das durchaus in meinen Augen auch tun. Das habe ich sowohl schon unterstützt, als auch bei Implementierungen schon gebremst. Und sogar die erste Beschreibung einer Fallstudie, in der Kanban-Pate David Anderson massiv involviert war, zeigt eine initiale Veränderung, um ein neu gestaltetes System sinnvoll in den Kontext einzubetten. Was spannend daran ist: Die meisten relevanten Informationen waren tatsächlich schon da oder wurden im Rahmen der Implementierung gesammelt. Ich empfehle also nicht, einfach so aus Lust und Laune größere Veränderung zu beschließen. Stattdessen sollten sie zum einen kohärent zur Realität sein und zum anderen nicht so riesig, dass sie wiederum Widerstand erzeugen.

Also, zusammenfassend: Ich vertrete den Standpunkt, dass wir offensichtliche Mängel durchaus auch schon während der Modellierung beseitigen können. Das gilt, wenn wir uns einig sind, dass diese Mängel zu unseren Problemen beitragen.

Die nächste Frage: "Darf ich eigentlich Tickets von rechts nach links bewegen?"

Auch hier: Ich kann nichts tun, wenn du es gerne so machen magst, ich empfehle aber an diesem Punkt im Allgemeinen, es nicht zu machen.

Also, manchmal entdecken wir in Arbeitsaufträgen, dass ein vorheriger Schritt entweder nicht genau gearbeitet hat oder sich die Welt zwischendrin verändert hat oder oder oder. Sowas führt dann zum Reflex, dieses Ticket wieder zurückzuschicken, zum Nachbessern. Das machen elektronische Tools wie JIRA auch noch total einfach, weil wir hier nur klick-klick zuweisen und die Aufgabe per Dropdown auswählen müssen. Und die Visualisierung wird nachgeführt, so dass das Ticket auch visuell zurückwandert.

Warum empfehle ich aber, es nicht zu tun und wie stattdessen? Beginnen wir mal mit dem letzten Punkt. Ich empfehle nämlich, das Ticket da hängen zu lassen und stattdessen einen Blockade-Sticky dranzuhängen. Dann spätestens im Kanban-Meeting, über das wir bald mal sprechen, klären, wie das Problem kurzfristig gelöst wird. Das hat mehrere bedeutende Effekte. Erstens: Wenn sich mehr als ein Ticket als problematisch erweist, sehen wir die Probleme gehäuft. Wir können dann eine systemisch-kluge Entscheidung darüber treffen, wie wir damit umgehen. Zweitens: Wenn wir mit fehlerhaften Tickets beschäftigt sind, sollten wir keine weiteren, neuen Tickets produzieren, die weitere Last auf die Arbeitsschritte legen. Durch die WIP-Limits – du hast doch bestimmt welche, oder? – staut sich die Arbeit dann ab einem bestimmten Punkt zurück und wir bekommen den Freiraum, um die Probleme zu lösen.

Drittens: Tickets, die später selektiert wurden und in den Dienstleistungsprozess gekommen sind, überholen die anderen im Allgemeinen nicht. Wir behalten also das bei, was meistens Priorisierung genannt wird.

Also: Tickets lieber festpinnen, besprechen, was damit passiert und dann nach deren Lösung weiterlaufen lassen. Wir sprechen beim Prozess auf dem Kanban-Board ja auch häufig von "vorherrschenden Aktivitäten". Da ist es nicht ganz so zwangsläufig, dass nur das da gemacht werden darf. Darüber hinaus benenne ich Spalten auch gerne mal um. Aus "Testen" wird dann beispielsweise "Qualität sichern" - da fallen viele andere Aktivitäten drunter!

Ein bisschen Raum haben wir noch, also noch eine:

Darf ich eigentlich mehr als ein Backlog haben?

Ha, ja, ganz sicher. Da schreien die Scrum-Jünger jetzt alle wieder auf, aber Kanban ist ja nunmal anders. Das Thema bekommt vielleicht mal ne ganze Folge, aber kurz lässt es sich auch beantworten. Also: Erst am Commitment-Punkt, beispielsweise unsere "als Nächstes"-Spalte, wird festgelegt, was als nächstes bearbeitet werden soll. Davor kann es unterschiedliche Quellen für Aufträge geben – das sind dann alles Optionen, die gezogen werden können. Je nachdem, was diese Menschen vorhaben, haben die nicht nur einen einzigen Auftrag, sondern gleich eine ganze Liste. Die könnten sie miteinander konsolidieren, aber ist in der Vielzahl der Fälle einfach Quatsch. Die müssen sich gar nicht vorher absprechen, wenn sie sich immer beim Commitment-Meeting darauf einigen können, wer als nächstes mit wie vielen Aufträgen dran ist – oder die Service Request Managerin übernimmt das. Die Selektion aus den einzelnen Backlogs bleibt aber bei den Backlogbesitzern. So einfach ist das. Da bekommt man dann auch keinen Single-Wringable-Neck-Szenario mehr, sondern hat einfach die Verantwortung der Interessenvertretung zurück an die Interessierten verlagert.

Zusammenfassend: Ja, mehrere Backlogs sind valide, sie stellen dann mehrere Quellen von Optionen dar, die gezogen werden können.