Beispiel: "Scrumban" in der Anwendung

Das Beste aus Kanban und Scrum in 11 Schritten
Kommentare

Im ersten Artikel der zweiteiligen Reihe wurde der Methodenhybrid, bestehend aus Kanban und Scrum, vorgestellt. Anhand eines fiktiven Beispiels – in Form eines Comics – soll im zweiten Teil nun das Arbeiten mit Arbeitspaketen nach Scrumban über verschiedene Teams hinweg illustriert werden.

Ausgangssituation

Abb. 1: Ausgangssituation

Abbildung 1 zeigt die Ausgangssituation. Es gibt eine Reihe priorisierter Aufgaben in dem Product Backlog. Der Product Owner, das Entwicklungsteam, bestehend aus vier Entwicklern, und das Qualitätssicherungsteam mit zwei Kollegen bilden eine Abteilung, die Funktionen für verschiedene Softwareprodukte realisieren soll. Die WIP-Limitierungen auf dem stilisierten Kanban-Board der einzelnen Bereiche sind am Anfang auf 3 („Ausgewählt“), 2 („Entwicklung“) bzw. 1 („QS“) festgelegt. Zu jeder Zeit kann der Product Owner das Product Backlog und die Arbeitspakete der Spalte „Ausgewählt“ ändern bzw. austauschen. Die anderen Spalten sind jedoch für den Product Owner tabu. Die Spalten „Entwicklung“ und „Qualitätssicherung“ sind jeweils in „in Arbeit“ und „erledigt“ unterteilt.

Mehrere verschiedene Produkte in einem Team bearbeiten? Wie in Abbildung 1 zu erkennen ist, können Arbeitspakete für verschiedene Produkte von den gleichen Teams bearbeitet werden. In Scrum ist das normalerweise so nicht vorgesehen; in Kanban beziehungsweise dem Methodenhybrid „Scrumban“ hingegen schon.

Schritt 1

Der Product Owner schiebt die ersten drei Arbeitspakete, die als Nächstes erledigt werden sollen, in die Spalte „Ausgewählt“. In einem bereits priorisierten Product Backlog sind das die drei obersten Stories. Eine vierte Story kann der Product Owner nicht in die besagte Spalte verschieben, da das WIP-Limit bereits erreicht ist. Ist das Product Backlog nicht priorisiert – eine Priorisierung der Backlog-Einträge ist in Kanban nicht zwingend – so erfolgt die Priorisierung der Stories indirekt durch das Verschieben der jeweils nächsten Stories in die Spalte „Ausgewählt“. Egal, welche Methode letztlich gewählt wird: Eine auf den Kundenbedarf gut abgestimmte Priorisierung ist in jedem Fall ein Erfolgsfaktor.

Abb. 2: Schritt 1

Schritt 2

Abb. 3: Schritt 2

Das Entwicklungsteam wird in zwei Gruppen unterteilt. Jede übernehmen jeweils ein Arbeitspaket aus der Spalte „Ausgewählt“ in die „in Arbeit“-Spalte des Entwicklungsbereiches und führen die notwendigen Arbeiten aus.

[ header = Seite 2: Schritt 3-6 ]

Schritt 3

Dies erlaubt es dem Product Owner, die beiden frei gewordenen Plätze mit neuen Aufgaben aus dem Product Backlog zu belegen.

Abb. 4: Schritt 3

Schritt 4

Abb. 5: Schritt 4

Eine der beiden Entwicklungsaufgaben ist erledigt und wird damit in die „Erledigt“-Spalte verschoben. Jetzt kommt das QS-Team zum Zuge: Es kann nun diese Aufgabe zwecks Prüfung der Umsetzungsarbeit übernehmen.

Schritt 5

Das Product Backlog kann natürlich stets um weitere Stories erweitert und – wenn nötig – umpriorisiert werden.

Abb. 6: Schritt 5

Schritt 6

Abb. 7: Schritt 6

Das eine Entwicklungsteam verfügt über freie Kapazitäten und kann eine neue Aufgabe übernehmen. Inzwischen konnte über Auswertungen erkannt werden, dass das WIP-Limit mit dem Wert 3 bezüglich der „Ausgewählt“-Spalte keinen positiven Effekt auf einen nachhaltigen Flow und den Kanban-Stream-Effekt hat. Einer der Gründe sind die geringeren Kapazitäten der Folgestationen. Deshalb wird das WIP-Limit auf 2 korrigiert. Der Product Owner kann keine neue Story in die „Ausgewählt“-Spalte schieben, da sich bereits zwei Stories in dieser Spalte befinden. Das QS-Team führt Tests bezüglich des Arbeitspaketes C durch.

Agil bedeutet nicht Chaos Der Vorteil agiler Methoden liegt darin, sich neuen Situationen rasch anzupassen. Nicht selten verleitet diese Besonderheit allerdings zu häufigen Veränderungen der konkreten Ausprägung der Entwicklungsmethode oder der Prozessparameter – Maßnahmen, die nicht immer notwendig sind. Des Weiteren bringen häufige Änderungen im Entwicklungsumfeld das Risiko mit sich, Prozesse nicht mehr sinnvoll steuern und kontrollieren zu können. Mögliche Folgen: chaotische Zustände und eine schlechtere Teamperformance. Geplante Änderungen sollten deshalb stets auf der Basis von verlässlichen Prozessdaten entwickelt und abgestimmt eingeführt werden. Hierbei ist es ratsam, einen CIP (Continuous Improvement Process) oder KVP (Kontinuierlicher Verbesserungsprozess) zu etablieren, der entsprechende Änderungen professionell plant, entwickelt und umsetzt. Ferner bedarf es eines Messsystems, welches in der Lage ist, die prozessrelevanten Werte periodisch korrekt zu messen und auszuwerten. Wichtig ist dabei auch, bereits vor geplanten Änderungen über umfassende Prozessdaten zu verfügen: Denn nur so lassen sich, durch den Vergleich von alten und neuen Daten, vorgenommene Veränderungen an Umfeld und Prozessen auf deren Erfolg hin sinnvoll überprüfen.

[ header = Seite 3: Schritt 7-11 ]

Schritt 7

Die Tests bezüglich des Arbeitspaktes C verlaufen schlecht. Das QS-Team befindet sich in der Analyse, während eines der Entwicklungsteams gerade mit der Aufgabe B fertig wurde und das Paket in die Spalte „Erledigt“ schiebt. Eines der Entwicklungsteams könnte eine neue Aufgabe übernehmen. Doch das Arbeitspaket B kann nicht vom QS-Team übernommen werden, da das Problem in Paket A noch immer nicht gelöst ist. Solange A nicht gelöst ist, stoppt also der gesamte Kanban-Stream. Jetzt gibt es genau drei Möglichkeiten:

  1. Das Problem in A wird behoben und die Wiederholungen der Tests laufen erfolgreich, sodass das Paket endlich abgeschlossen werden kann. Hierbei könnte auch das Entwicklungsteam unterstützen, welches gerade über freie Kapazitäten verfügt.
  2. Es wird beschlossen, das Paket A nicht weiter zu bearbeiten. Die Umsetzung wird gestoppt und nicht ausgeliefert.
  3. Das WIP-Limit wird erhöht. Bei dieser Maßnahme sollte aber auch die Teamstärke entsprechend angepasst werden.

Abb. 8: Schritt 7

Schritt 8

Abb. 9: Schritt 8

Eines der Entwicklungsteams unterstützt das QS-Team bei der Fehleranalyse. Zu beachten ist, dass das Arbeitspaket in der Verantwortung des QS-Teams verbleibt. Es wird nicht zurückdelegiert.

Schritt 9

Der Fehler im Paket A ist endlich gefunden. Das Entwicklungsteam hat ihn behoben und die Wiederholungen der Tests waren erfolgreich, sodass Paket A nun vom QS-Team auf „Erledigt“ gesetzt werden kann. Dasselbe gilt für das andere Entwicklungsteam, das ebenfalls erfolgreich war.

Abb. 10: Schritt 9

Schritt 10

Abb. 11: Schritt 10

Damit können sowohl das QS-Team als auch die beiden Entwicklungsteams neue Aufgaben übernehmen, und der Product Owner kann endlich die beiden obersten Stories aus dem priorisierten Product Backlog in die Spalte „Ausgewählt“ nachziehen – der Kanban-Stream funktioniert wieder! Die Erfahrungen aus dem aktuellen Projekt haben jedoch gezeigt, dass zwischen den beiden Teams Entwicklung und QS noch ein Ungleichgewicht in Sachen Kapazität besteht. Da das QS-Team nur die Hälfte der Entwicklungskapazitäten besitzt, kann bereits bei einem einzigen Problem der Kanban-Stream bzw. der gleichmäßige Flow abreißen. Es wird die Entscheidung gefällt, die Teamstärke bei QS zu erhöhen und das WIP-Limit auf 2 zu setzen.

Schritt 11

Die Teams haben ihren Takt gefunden, mit dem positiven Ergebnis, dass ein gleichmäßiger Flow entstanden ist. Im Endeffekt heißt das: Durch alle Arbeitsstationen hindurch werden die Arbeitspakete schneller erledigt als vor der Einführung der „Scrumban“-Methode.

Abb. 12: Schritt 11

Autor

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag