Kanban und Scrum auf einem Board?

Einleitung

In diesem Artikel möchte ich mit euch ein paar Gedanken zum Thema Scrum-Board und Kaban teilen, die uns bei der Verbesserung der Abbildung unseres Arbeitsflusses beschäftigen. Sie verstoßen nicht gegen das “Lehrbuch-Scrum”, können aber dazu beitragen, sowohl den Entwicklern als auch den Projektleitern bzw. Product Ownern ein transparenteres Bild über den Arbeitsfluss zu geben und den Durchsatz der Arbeitspakete zu erhöhen.

Scrum-Board im Rechenzentrum

Bei uns im Rechenzentrum wird in der Softwareentwicklung “Scrum” als Vorgehensmodell des Projektmanagements verwendet. Wie Enrico in seinem Artikel “Sprintziele im RZ-Scrum” beschreibt, weicht unser Modell allerdings vom Lehrbuch-Scrum ab, allein schon aus dem Grund, weil die Entwickler an mehr als einem Projekt oder Produkt beteiligt sind. Somit haben wir unserer eigenes RZ-spezifisches Scrum entwickelt. Wir verwenden zur Visualisierung unsres Arbeitsflusses das sogenannte Scrum-Board. Es gibt eine Spalte mit neuen Items(Arbeitspakete) und eine Spalte mit geschätzten Items, also Arbeitspaketen, die mit einem geschätzten Arbeitsaufwand versehen sind. Im Sprint-Planning werden explizit für einen Sprint, einen Zeitrahmen von 2 Wochen, für jeden Entwickler Arbeitspakete bestimmt, d.h. aus dem Topf der geschätzten Items in das Spritbacklog gepullt. Beginnt ein Sprint, so können die Entwickler ihre Items in die “In Progress”-Spalte schieben. Wie jeder Entwickler weiß, ist ein Arbeitspaket schneller angefangen als abgeschlossen. Im Sprint kommt es somit nicht selten dazu, dass alle Sprint-Items den Status “In Progress” haben. Es ist also noch keine Arbeit vollständig abgeschlossen und keine Arbeit noch nicht angefangen. . Das kann verschiedene Gründe haben, ist aber alles andere zufriedenstellend.

Kanban-Elemente auf dem Scrum-Board

Dass alle Items den Status “In Progress” haben, heißt aber noch lange nicht, dass auch gerade an allen Items gearbeitet wird. Der tatsächliche Status des Arbeitspakets ist einfach nicht transparent abgebildet. Arbeitspakete können beispielsweise nicht abgeschlossen werden, weil auf eine Review gewartet wird, externe Abhängigkeiten es verhindern oder sich die Anforderungen geändert haben. Aus diesem Grund macht es Sinn, weitere Spalten wie “Has Impediment” oder “Waiting for Review” oder auch andere Status in das Scrum-Board zu integrieren. Dieser Faden lässt sich allerdings noch weiterspinnen.

WIP-Limits

Durch die bessere Abbildung des Status, verteilen sich nun die Aufgaben auf die verschiedenen Spalten. Jetzt wird klarer, an welcher Stelle der tatsächliche “Flaschenhals” sich befindet, also welcher Arbeitsschritt oder Status die Entwickler davon abhält, das Arbeitspaket auch tatsächlich abzuschließen. Hat sich dieser Status herauskristallisiert, ist es sinnvoll, ein sogenanntes Work-In-Progress-Limit für diesen Status zu implementieren. Das heißt, es wird eine maximale Anzahl an Arbeitspaketen in diesem Status zugelassen. Ist die Anzahl erreicht, darf kein neues Item mehr angefangen werden und keine Items mehr in die nächste Spalte geschoben werden. Kanban-Experten versprechen bei dieser Vorgehensweise einen höheren Durchsatz und eine sichtliche Verkleinerung der Anzahl “fast fertiger” Items.

Pullen statt Pushen

Die Einführung des WIP-Limits hat also dazu geführt, dass ein gewisser Stoppmechanismus in den Arbeitsfluss integriert wurde. Für Items die sich in den Spalten befinden, die kein WIP-Limit haben, bedeutet dies, dass ihr Status wieder nicht richtig abgebildet ist. Dies ist einer der Gründe, warum für jede Spalte eine zusätzliche “Done”-Spalte angelegt werden kann. Ist es zu einem Stopp im Arbeitsfluss gekommen, so werden in jeder Spalte die Arbeitspakete erstmal soweit bearbeitet, dass sie den Status ihrer Spalte erreicht haben und werden dann in ihrer Spalte auf “Done” gesetzt. Erst wenn ein weiteres Arbeitspaket in die Flaschenhals-Spalte gepullt wird und der Arbeitsfluss wieder in Gang kommt, wird in jeder Spalte aus der vorgeschalteten Spalte ein weiteres Item gepullt. Mit diesem Vorgehen wird ein Überlauf an Items im “Flaschenhals”-Status verhindert. Der ganze Arbeitsfluss passt sich an das Tempo des “Flaschenhals”-Arbeitsschritts an.

Zusammenfassung

Der Einsatz bestimmter Kanban-Elemente auf dem Scrum-Board kann dem Entwicklerteam dabei helfen, Arbeitspakete schneller fertig zu stellen und eine bessere Transparenz auf den Arbeitsfluss mitsichbringen. Also „Stop starting – Start finishing“.