Die Situation kommt vielleicht bekannt vor: Das Scrum-Team rückt einer Deadline näher, der Scope ist noch immer groß und die Projektbeteiligten machen sich Sorgen, ob denn die Deadline zum geplanten Release gehalten werden kann. In so einer Situation gibt es verschiedene Herangehensweisen, um erfolgreich zu sein.
Ich war Scrum Master eines Teams, das sich entschlossen hat, in dieser heißen Phase in den sogenannten Kanban-Modus zu wechseln. In diesem Blogpost möchte ich beschreiben, was sich das Team davon erhofft hat, was wir dabei gelernt haben und ob wir damit die Deadline halten konnten.
In Fachbüchern wird Kanban als „evolutionäres Change Management Tool“ beschrieben, das auf Werten, Grundprinzipien und Kernpraktiken basiert. Bevor man mit Kanban startet, sollte das Problem identifiziert sein, das es zu lösen gilt. Ein Wechsel zu Kanban ohne ein konkretes Problem kann zurecht in Frage gestellt werden.
Was war unser Problem?
Die vergangenen (großen) Launches haben im Team immer Unzufriedenheit aufkommen lassen, vor allem, weil sich Anforderungen spät geändert haben und dies schwerwiegende Auswirkungen auf unseren Scope hatte. Dadurch wurden die Ziele in den Sprints selten geschafft. Es blieb viel Arbeit liegen, die sich bis zum Launch aufgestaut hat.
Was versprach sich das Team vom Wechsel in den Kanban-Modus?
Als Resultat des Wechsels in den Kanban-Modus erhoffte sich das Team vor allem eines: Man wird schneller und die Deadline kann gehalten werden.
Wir versprachen uns von einem Wechsel in den Kanban-Modus eine größere Flexibilität. Schließlich hatten wir keinen Sprint-Backlog mehr, der uns den Scope für zwei Wochen stabil hielt. Der Product Owner konnte täglich Prioritäten neu verteilen. Die Wunschvorstellung war schnell gefunden: Bugs können schnell gefixt werden, oder aus dem Feedback der Tester kann gleich eine Story geschrieben werden, die dann zügig umgesetzt wird. Das Team kommt ins Rollen und arbeitet in einem kontinuierlichen Arbeitsfluss, auch Flow genannt, eine Story nach der anderen ab ohne viel Prozess nebenher.
Zusätzlich wurden die Scrum-Meetings in der heißen Phase auf die Deadline hin als Zeitverschwendung angesehen und dankend abgesagt. „Wir machen jetzt nur noch das Wichtigste!“, hörte man oft. Dies wurde auch so an die Stakeholder kommuniziert. Als Resultat von all den genannten Punkten erhoffte sich das Team vor allem eines: Man wird schneller und die Deadline kann gehalten werden.
Reality-Check: Wie war das Arbeiten im Kanban-Modus wirklich?
Der Wunsch nach mehr Flexibilität in der Abarbeitung der Stories und die Möglichkeit der täglichen (Um-)Priorisierung durch den Product Owner ergab für uns eine explosive Mischung mit fatalen Folgen: Arbeitsaufgaben kamen unkontrolliert auf das Board, es wurde mehr Arbeit angeschafft als abgearbeitet werden konnte. Wir tappten in die Hey-Joe-Falle und akzeptierten Arbeit auf Zuruf, schließlich „machen wir nur noch das Wichtigste“. Leider wurde auf einmal alles wichtig und wir kamen in einen Modus „Wer lauter schreit, kommt früher dran“.
Wir produzierten viele lose Enden und versanken im Chaos.
Weil wir Meetings konsequent abgesagt hatten, fand auch die notwendige Abstimmung untereinander nicht mehr regelmäßig statt. Das führte sogar soweit, dass wir teilweise gar nicht mehr wussten, wer an welchen Stellen gerade arbeitet, und es wurde mehrmals Arbeit doppelt gemacht.
Der Wunsch nach einem besseren Arbeitsablauf ging ebenfalls nicht in Erfüllung: Wir haben sehr schnell den Überblick verloren, wann etwas fertig werden wird und welche Aufgaben kürzlich hinzugekommen sind. Nicht zuletzt stellte sich auch kein richtiger Arbeitsfluss ein. Wir produzierten viele lose Enden und versanken im Chaos.
[smartblock id=6342]
Was haben wir daraus gelernt?
Das Team hat sich in der Retrospektive nach dem Launch beschwert, dass es mit viel zu vielen Aufgaben konfrontiert wurde, was der unkontrollierten Aufnahme der Backlog Items auf das Board geschuldet war. Eine der Kernpraktiken von Kanban lautet: Limitiere Work in Progress.
Beherzigt man diese Praktik, entsteht ein geregeltes System. Eine Situation wie in unserem Team kann damit gar nicht mehr entstehen. Somit entsteht auch nicht der Eindruck, dass beliebig viele Aufgaben an das Team herangetragen werden können. Konkret hätte das bedeutet, dass wir zu jeder Spalte auf unserem Board ein WiP-Limit hinzufügen hätten sollen.
Nur weil wir es Kanban-Modus nannten, hatten wir kaum Gemeinsamkeiten mit Kanban in der IT …
Eine wirksame und vor allem spielerische Methode, um im Team die Auswirkungen von zu hohem WiP kennenzulernen, ist das Multitasking Name Game von Henrik Kniberg. Schon nach kurzer Zeit wird den Spielern klar, warum es keine gute Idee ist, an zu vielen Dingen gleichzeitig zu arbeiten. Probiert es doch mal aus und schreibt mir gerne dazu euer Feedback als Kommentar (smile)
„Wenn alles wichtig ist, ist nichts wichtig!“
Diese alte Weisheit hat sich auch bei uns bewahrheitet und war ein zentrales Learning.
Für die Zukunft haben wir uns vorgenommen:
- eine Priorisierung gerade in Situationen mit einer straffen Zeitlinie vorzunehmen, uns eng mit den anderen Projektbeteiligten abzustimmen und auch über den Umfang zu diskutieren.
- wieder regelmäßig in Meetings zusammenzukommen, um die notwendige Abstimmung innerhalb im Team zu gewährleisten oder um Abhängigkeiten aufzulösen.
- wir möchten Feedback-Zyklen einhalten, um Verbesserungen etwa am Arbeitsfluss anzugehen.
Mein persönliches Learning war: Nur weil wir es Kanban-Modus nannten, hatten wir kaum Gemeinsamkeiten mit Kanban in der IT, wie es beispielsweise von David J. Anderson beschrieben wird. Das Lesen von verschiedenen Büchern zu Kanban und eine Schulung der Lean Kanban University haben mir gezeigt, dass Kanban kein Tool oder Framework ist, das ein einzelnes Team schneller macht. Der Fokus der Kanban-Methode liegt auf der Wertschöpfung für den Kunden. Der Grund, warum einzelne Teams schneller werden (können), liegt daran, dass alle Projektbeteiligten koordiniert zusammenarbeiten und regelmäßig nach Verbesserungen gesucht wird – dabei kann die Kanban-Methode helfen.
Wie kann ich also die Deadline halten?
Gerät ein Projekt etwas in Schieflage und eine Deadline ist in Gefahr, würde ich andere Optionen und Herangehensweisen dem von uns gewählten Ansatz (Kanban-Modus) unbedingt vorziehen. Meine Kollegin Carry Heil hat in einem Blogpost beschrieben, was gemacht werden kann, wenn eine Deadline in Gefahr ist.
Kennt ihr den Kanban-Modus? Habt ihr damit womöglich auch schon Erfahrungen gemacht? Schreibt mir in den Kommentaren!
Schreibe einen Kommentar