Wann Kanban eigentlich Wasserfall ist: Vom vermeintlichen Anspruch an uns selbst

Nehmen wir ein x-beliebiges Projekt in der Softwareentwicklung. Das Team arbeitet mit Scrum, alles läuft. Soweit so schön. Nun möchte der Product Owner im laufenden Projekt auf Kanban wechseln. Warum genau und wann Kanban kein Kanban mehr ist, lest ihr im folgenden Blogartikel.

Das Projekt läuft gut. Das Team sprintet sich durch das Backlog. Es entsteht ein Produkt, welches jederzeit vorzeigbar ist, funktioniert und sich ständig weiterentwickelt. Wunderbar. Nun fragt der PO plötzlich sein Team, ob es nicht mit Kanban arbeiten möchte. Kanban? Warum nicht! Keine festgelegten Iterationszeiten und die Möglichkeit, jederzeit neue Anforderungen an das Team zu geben, bieten Vorteile – vor allem (aber nicht nur) für den PO. Wenn es denn mal Kanban wäre.

Kanban as a better Scrum tool?

Während eines laufenden Projekts auf Kanban umsteigen? Kann sinnvoll sein – es lohnt sich aber, genauer hinzuschauen. Augenscheinlich empfindet der vorschlagende PO die Meetings, welche im Scrum obligatorisch sind, als Zeitfresser: Unnötig oder zumindest zu lang und bitte nicht so häufig. Seine Sicht auf die Wahl der agilen Methode scheint ausschließlich zeitgetrieben. Der Sprint in seiner Abgeschlossenheit – für ihn ein Problem. Das Team committet sich auf die anstehenden Tasks und daran ist für ihn in den nächsten zwei Wochen kaum etwas zu rütteln. Dabei schätzt er seine neue Anforderung doch gerade jetzt als so wichtig ein. Sein Anspruch: derart wichtige Dinge nicht unnötig liegen lassen! Aus der Sicht des PO ein Grundsatz von Qualität! Zettel auf „Done“ hängen schüttet bekanntlich so viel Glückshormone aus, wie eine Tafel Schokolade. Mindestens. Der PO liebäugelt also mit Kanban und dem „Zauberticket“ names Expedite.

Der Kanban-Missbrauch

Die Anzahl der Tickets in den Spalten eines Kanban Boards (der Work in Progress, kurz WiP) ist grundsätzlich limitiert. Ein Expedite Ticket jedoch zählt hier nicht hinein. Es besitzt eine besonders hohe Priorität. Wenn beispielsweise der Server ausfällt, muss das Team seine gesamte Kapazität darauf abstellen, dieses Ticket zu erledigen. Doch das geht nur vorübergehend. Schließlich darf die Wahl der agilen Methode nicht darin gipfeln, mit dessen Möglichkeiten künstlich die Kapazität des Teams zu erhöhen!
Kanban heißt nicht, immer mehr Tickets ins System hineinstopfen zu dürfen. Das ist kein Kanban, sondern nur der Versuch, Scrum zu umgehen. Mit dem Pull-Prinzip hat das nichts zu tun. Und das ist dann nichts anderes, als ein Ruck gen Wasserfall. Inklusive Absturz. Denn mit reihenweise Expedites als Folge chaotischer Priorisierung legt man sein System erfolgreich lahm. Stau. Immer am WIP-Limit vorbei. Bis zum völligen Zusammenbruch. Das Team also ausschließlich mit enorm wichtigen Tasks zu füttern ist gewissermaßen „Taskforce-Kanban“.
Doch wie gehe ich als Entwickler in solch einem Kampfteam gegen den Druck im System vor? Ein Blick in den Duden zeigt: Jede Taskforce, also eine auf begrenzte Zeit gebildete Arbeitsgruppe, hat umfassende Entscheidungskompetenzen zur Lösung von komplexen Problemen. Kommt uns doch bekannt vor! Wie im Scrum Guide beschrieben, ist die Entscheidungsfreiheit des Teams die Basis.

Der richtige Anspruch

Während die Macht nun also mit dem Entwicklerteam zu sein scheint, sind falsche Gründe, (vermeintliches!) Kanban einzuführen, der eigentliche Gewaltakt und nur ein Weglaufen vor Problemen.
Klar, können die Entwickler auch Kanban! Und es gibt Gründe zu Kanban zu wechseln. Aber das gesamte Scrum-Team sollte gemeinsam überlegen, was das Motiv hinter dem vorgeschlagenen Wechsel der agilen Methode ist und ob dieser wirklich ihre Probleme löst. Die Begründung, dass Kanban mehr Flexibilität bietet, ist absolut valide. Einfach mehr Aufgaben dem Team aufdrücken zu wollen, ist jedoch kein Grund für einen Wechsel. Und das was dabei raus kommt, ist eben auch kein Kanban.
Häufig sind Probleme in der Organisation das wahre Motiv: Ziele wechseln im Tagesrhythmus, die Prioritäten ebenso. Zu viele Köche und nur ein Topf. Wer das Problem durch den Wechsel auf Scheinkanban zu lösen glaubt, klebt wahrscheinlich auch Warnlampen im Autocockpit ab. Agilität zeigt uns eben schnell auf, wo es klemmt. Und liefert gleichzeitig die Lösung: Denn egal, welche agile Methode – Fokussierung ist nicht umsonst ein im agilen Manifest ein bedeutender Wert. Sie ist wertvoll, um unsere Ziele zu erreichen und vor allem, um sie nicht aus dem Auge zu verlieren. Nur weil mal wieder irgendetwas wichtiger zu sein scheint...
Das Fazit also: Es ist nicht der Anspruch an uns selbst, alles sofort umsetzen zu wollen. Sondern: