Beispiel: "Scrumban" in der Anwendung

Das Beste aus Kanban und Scrum in 11 Schritten
Kommentare

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

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.

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
Torsten Zimmermann berät Großunternehmen im Rahmen international angelegter Projekte und Programme zu den Themen Softwarequalität, Qualitäts-/Testmanagement, Offshore-Projektmanagement und Entwicklungsmethoden. Daneben entwickelt er neue Ansätze für leistungsfähige Prozessframeworks und Testtechnologien in Kooperation mit einem Netzwerk aus Hochschulen und Universitäten. Kontakt: Torsten Zimmermann bei Xing.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -