Kanban Anti-Pattern: der Kanban-Modus

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.

— Spannendes Thema? —

Du interessierst Dich für weitere Informationen zu diesem Thema? Setz‘ Dich über unser Kontaktformular mit uns in Verbindung, wir stehen Dir gerne mit Rat und Tat zur Seite.

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!

Buchempfehlungen & Links

Für neue Blogupdates anmelden:


10 Gedanken zu “Kanban Anti-Pattern: der Kanban-Modus

  1. 2 learnings aus Kanban tauchen in der Liste nicht auf. Bzw. Was ich bei Scrum Teams, insbesondere wenn diese auf Termine zuarbeiten (um mal das Deadline Wort zu vermeiden), gerne öfter sehen würde:

    1. Auch ein Scrum Backlog hat ein WIP Limit. das sind Anzahl Items und Storypoints. Maximal würde ich Velocity*Restsprints nehmen. Bei Anzahl Stories kommt es darauf an.
    2. Klare Definitionen was in jedem Schritt passiert. Hier ist Kanban ja nicht laxer, sondern eigentlich viel klarer strukturiert. Das Teambacklog ist u.a. kein Planungswerkzeug für ein Projekt, sondern für die Sprints des Teams. Das kann man dann ja noch drüber packen. Aber bloß weil jemand ein Projekt auf Papier unterschreibt erhöht sich dadurch ja nicht die Kapazität des Teams.

    Kanban und Scrum müssen nicht so ein unterschied sein und die Annahme „Kanban Modus“ sei lax rührt imho oft von Unwisssen, was denn Kanban genau ist und das es eher mehr Disziplin und Orga erfordert als Scrum.

    • Hi Sebs,

      vielen Dank für deine Anmerkungen. Ich sehe alles genauso wie du und würde heute vieles anders machen. 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.
      Gruß
      Rupi

  2. 1. Kanban kann man nicht mal eben schnell einführen, schon gar nicht gegen Ende eines Projektes. Die Einführung von Kanban erfolgt schrittweise und braucht Zeit, das kann Monate oder gar Jahre dauern, je nach Art der Organisation. Einen „Kanban-Modus“ sehe ich daher eher kritisch

    2. Kanban ist für die Arbeit an klassischen Projekten eher ungeeignet. Typischerweise sollte Kanban eingesetzt werden bei Maintenance und Support-Aufgaben, wo es einen kontinuierlichen Arbeitsfluss gibt und kurze Reaktionszeiten erforderlich sind.

    • Hallo Oliver,

      danke für deinen Kommentar. Ich gebe auch dir recht, „mal eben schnell zu Kanban wechseln“ kann ich, vor allem unter den damals gegebenen Bedingungen, absolut nicht empfehlen.

      Viele Grüße
      Martin

  3. Einführung der Kanban braucht leider Zeit. Es ist nicht schwer die software zu lernen (Ich fand z.B. Kanban Tool – http://kanbantool.com/de – super intuitiv und Kommunikation erleichternd), es geht aber um den ganzen Wandel der Arbeitsystem. Es ist aber die Mühe wert und gibt spektakuläre Resultate.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.