11. April 2018

Kanban für Scrum-Teams: Wilder Mix der Methoden oder evolutionäres Best-of?

Martin Stahl

Ein neues Angebot auf dem umkämpften Zertifizierungsmarkt sorgt aktuell für eine Kontroverse in der agilen Szene: die Organisation scrum.org um Ken Schwaber bietet neuerdings einen "Scrum mit Kanban (PSK)" - Kurs an. Das theoretische Fundament ist im "Kanban-Guide for Scrum-Teams" beschrieben.

Die Kontroverse

Doch woher kommt die Kontroverse? Neutral betrachtet sind beide Methoden eine Sammlung von empfohlenen agilen Praktiken - jeweils mit unterschiedlichem Fokus. Viele Entwicklungsteams dürften sich daher in ihrem Alltag ohne weitere Berührungsängste an beiden Methoden bedienen oder arbeiten intuitiv mit einem Kanban-Board ohne tiefere Methoden-Kenntnis. Auch pflegen viele seniore Agilisten einen methodischen Agnostizismus. Ganz im Gegensatz zu den Organisationen, die die jeweilige Methode verwalten und weiter entwickeln. Und natürlich mit Zertifizierung und Beratung auch eine veritable Gelddruckmaschine in der Hinterhand haben. Welche ihrer Einwände sind vielleicht berechtigt? Oder ergänzen sich die Praktiken sinnvoll und die vermeintlichen Widersprüche sind nur Form einer Territorialverteidigung der Methodiker-Platzhirsche?

Schauen wir uns mal an, was sich in dem neuen Paket "Kanban für Scrum-Teams" versteckt. Erst einmal wird von einem bestehenden Scrum-Prozess "by the book" ausgegangen. Dieser kann dann mit mit einer Auswahl von Schlüsselpraktiken aus dem Kanban erweitert werden:

Visualisierung des Workflows

Wie die anderen Erweiterungen ein Kernelement des Kanbans. Der komplette Workflow soll auch im Scrum-Prozess visualisiert werden. Es wird also anerkannt, dass vor dem Sprint Planning bzw. Backlog Refinement bereits vorbereitende Arbeitsschritte nötig sind. Um mit Kanban-Vokabeln zu sprechen: nicht nur der downstream-, sondern auch upstream-Prozess wird jetzt sichtbar. Dies ist bemerkenswert, da Scrum bisher zu einem eher isolierten Blick auf den Prozess eingeladen hat, der mit dem Backlog Refinement beginnt und mit der Delivery endet.

Limitierung des Work in Progress

Auch so ein vermeintlich typisches Kanban-Element. Doch die Limitierung des Work in Progress ist nicht komplett neu in Scrum. Bisher galt als Empfehlung, erst dann mit einem neuen Thema zu beginnen, wenn die Entwicklung des vorigen abgeschlossen ist oder zumindest so weit wie sinnvoll parallele Streams zu vermeiden. Diese eigentlich recht radikale Limitierung auf ein WiP von 1 steht weniger im Vorzeichen der Flow-Optimierung, sondern eher im Hinblick auf klaren Fokus und das Liefern von sinnvollen Software-Teilen. Eine Limitierung an sich ist also in Scrum nicht neu, sondern wir dürfen davon ausgehen, dass dies in vielen Scrum-Teams schon praktiziert wurde.

Aktives Management der Tickets in Bearbeitung

Wie funktioniert dies nun im neuen “Methodenmix”? Wie bisher schauen wir beim Daily Scrum-Meeting auf die sich in Bearbeitung befindlichen Arbeitspakete. Zusätzlich werden einige aus Kanban übliche Flow-Metriken wie Durchlaufzeit, Durchsatz oder Total WIP übernommen. Allerdings setzen wir uns bei dem Blick auf die tägliche Arbeit nun eine ganz andere Brille auf: Anstatt zu fragen, ob jeder wirklich genug zu tun hat (das alte Konzept "optimale Resourcenauslastung" winkt durch die Hintertür), fragen wir uns nun, wie wir unseren Flow und damit unsere Vorhersagbarkeit verbessern können.

Spannend hierbei: die evolutionäre Anpassung (!) unseres Workflows auf Basis unserer neuen Erkenntnisse ist im "Kanban-Guide for Scrum-Teams" nicht vorgesehen - schließlich soll es ja Scrum “by the book” bleiben.

Feedback-Mechanismen zur Workflow-Optimierung einführen

Ziel ist es, den Workflow zu verbessern - eine Sichtweise, die in Scrum bisher so nicht explizit vorgesehen ist und durch die zeitlich fixierten Sprints auch nicht nahegelegt wird. Während Kanban versucht, durch Visualisierung und Metriken zu verstehen, wo sich Arbeitspakete stauen oder ganz hängen bleiben und die gefundenen Hindernisse beiseite räumt, bleibt die Struktur von Scrum grundsätzlich vorgegeben. Die Umstellung auf ein reines "Pullen" der Stories und die Flow-Optimierung von rechts nach links (von Prozessende in Richtung -beginn) dürfte am Anfang nicht ganz leicht fallen. Der "Kanban-Guide for Scrum-Teams" sieht für das "flow-based Daily Scrum" überraschenderweise diese Betrachtungsweise nicht vor. Regeln, wann eine Story weitergezogen werden kann, haben Teams in der Regel schon - idealerweise sind diese auch explizit.

Ordentliche Flow-Metriken ermöglichen also eine solide und realistische Prognose, die dann auch gerne als Basis für Service Level Agreements (SLAs) benutzt werden können. Die meisten Scrum-Teams versuchen, die Velocity stabil zu halten und dadurch eine Prognose liefern zu können. Das funktioniert auch (meistens) recht gut, zumindest in dem geschützten Raum namens Sprint. Nimmt man aber den upstream-Part dazu, ist das velocity-basierte Optimieren nur mit ordentlichem Verbiegen des eigentlichen Scrum-Prozesses möglich. Zum Beispiel gibt es mehrstufige und parallele Sprints, die sich aber dann schon sehr nach Wasserfall anfühlen.

Fazit

Zunächst einmal ist es an sich eine gute Idee, eine Methode durch bewährte Praktiken aus einer anderen zu erweitern. Die aktuelle Version der Scrum-Kanban-Erweiterung bleibt dabei nur ein kleiner erster Schritt. Andere wichtige Praktiken aus dem Kanban wie z.B. die  Serviceklassen, deren Fehlen Softwareteams so manche Schmerzen bereiten, sind (noch) nicht vorgesehen.

Bleibt die Frage, ob sich eine in ihrem Ansatz evolutionäre Methode wie Kanban mit einer eher festgeschriebenen wie Scrum verträgt. Da muss jedes Team auf seine eigene Reise gehen und individuell entscheiden, wie weit es sich von einer definierten Methode zu einem kontinuierlichen Verbesserungsprozess wagt und welche Konsequenz das "inspect and adapt" haben darf und soll. Zugegeben: nicht jedes Team kann (und will) evolutionär den Prozess verbessern, mag es auch ein Grundprinzip von Agilität sein. Ein rund laufendes und motiviertes Team mit eingespieltem Prozess und konstanter Delivery ist schließlich viel wert.

Wir raten daher zu einer nüchternen und pragmatischen Diskussion. Teams, die schon bisher mit einem Kanban-Board arbeiten, erhalten mit der neuen PSK-Schulung wertvolle Praktiken aus der Kanban-Welt vermittelt. Ganz neu ist die Vermählung von Scrum und Kanban nicht: Ansätze wie ScrumBan laden schon bisher zu einer solchen Reise ein, allerdings mit offenem Ende. Gute Hilfestellung gibt es auch mit dem Kanban-Guide (Poster zum Download hier: http://kanbanguide.com), einer Sammlung an Praktiken, die fortgeschrittene Teams einfach mal “pullen” können und ausprobieren. Steigt man hoch in die Welt der skalierten agilen Systeme, findet man dort ebenfalls Elemente von Scrum und (Portfolio-)Kanban vereint.

Für Scrum Master, Product Owner oder generell interessierte Agilisten gibt es neben dem neuen PSK-Zertifikat auch die sinnvolle Alternative, sich direkt im Kanban-Umfeld fortzubilden und mit dem Team dann zu entscheiden, welche Praktiken davon passen und hilfreich sind. Denn darum geht es: motivierte Teams, die gerne und engagiert ihre Arbeit machen!

Martin Stahl
Product | Coaching | Training

Schreibe einen Kommentar

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

Hiermit akzeptiere ich die Datenschutzbedingungen.

Rufen Sie uns an: 030 – 555 74 70 0

Made with 
in Berlin. 
© leanovate 2024