Von Visualisierung und Kennzahlen – Scrum mit Kanban

Scrum ist ein Framework für die Durchführung agiler Projekte. Kanban ist bekannt als System bzw. Strategie zur Prozessoptimierung. Aber passt das beides zusammen? Häufig liest man auch den Begriff „Scrumban". In diesem Artikel wollen wir uns den Zusammenschluss beider Techniken einmal genauer anschauen.

Scrum-Wissen vorausgesetzt

Keine Sorge, ich werde hier nicht noch einmal das Scrum-Framework vorstellen, denn mittlerweile wird dieses in sehr vielen agil geführten Projekten eingesetzt, und es gibt nahezu kein Magazin, das nicht schon einmal darüber berichtet hat. Seminare zu diesem Thema tragen ebenfalls dazu bei, das Wissen zu verbreiten.

Daher setze ich für das Studium dieses Artikels grundlegendes Wissen über Scrum voraus.

Was ist Kanban

Laut Definition ist Kanban eine Strategie zur Optimierung des Wertflusses durch einen Prozess, der sich auf die laufenden Arbeiten beschränkt, diese visualisiert und nach dem Pull-Prinzip funktioniert.

Kanban ist dort gut geeignet, wo viel Dynamik stattfindet und Aufgaben schnell erledigt werden müssen. Durch den Einsatz von Kanban kann so eine Optimierung und damit eine höhere Effizienz erreicht werden.

Kanban bedient sich als visuelles Medium dem so genannten Kanban Board, das sicher jedem zumindest aus der Literatur bekannt ist.

Der Zusammenschluss von Scrum und Kanban

Bei Scrum und auch bei Kanban organisieren sich die Teams selbst.

Kanban legt den Fokus auf Transparenz und Visualisierung und schafft so am Ende eine Steigerung der Qualität des Ergebnisses.

Der Einsatz von Kanban lässt sich gut in Scrum integrieren, z.B. für die Aufgaben eines Sprint-Backlogs oder zur Messung und Optimierung der Arbeit des Developer-Teams.

Das dachten sich sicher auch Vertreter von scrum.org und der Kanban-Community und veröffentlichten in Zusammenarbeit einen Leitfaden mit dem Titel „The Kanban Guide for Scrum Teams" auf ihrer Seite.

Kanban: Vier wichtige Kennzahlen

• WIP (Work in Progress): Die Anzahl der gleichzeitig in Bearbeitung befindlichen Aufgaben während eines Sprints.
• Cycle Time (Zykluszeit): Die Zeitspanne, die zwischen dem Anfang einer Aufgabe und der Fertigstellung vergeht.
  
• Work Item Age: Die Zeit, die vergangen ist zwischen dem Start der Bearbeitung einer Aufgabe und dem aktuellen Zeitpunkt. Dies gilt nur für Aufgaben, die noch nicht abgeschlossen sind.
  
• Durchsatz: Die Anzahl der Aufgaben, die pro Zeiteinheit abgeschlossen werden (z. B. drei Aufgaben pro Tag).
  

Optimierung des Arbeitsflusses mit Kanban

Klingt durchaus logisch, denn mehr Arbeit zur gleichen Zeit lässt das Team auf Dauer langsamer werden und führt im Worst Case bis zur Überlastung bzw. zum Stillstand. Sicher spielen dort auch Dinge wie Unmut, Überarbeitung und Frustration eine Rolle oder einfach die Rüstzeiten in Form von Umdenken bzgl. der vielen Aufgabenstellungen.

Damit es nicht soweit kommt und gleichzeitig der bestmögliche Output erzielt wird, kann ein Scrum-Team durch Berücksichtigung der folgenden Punkte eine Flussoptimierung erreichen:

Die Visualisierung des Workflows hilft dabei, einen Überblick über alle Aufgaben für den aktuellen Sprint zu erhalten. Dazu bedient man sich in der Regel des so genannten Kanban Boards, auf das ich später im Text noch etwas genauer eingehen möchte.

Durch die Begrenzung der gleichzeitig in Arbeit befindlichen Aufgaben (WIP) wird sichergestellt, dass das Entwickler-Team die angefangenen Dinge im aktuellen Sprint auch zu Ende bringt und nicht durch die Menge an Aufgaben ausgebremst wird. Das Team selbst bestimmt dazu die maximale Anzahl in Arbeit befindlicher Items aus dem Sprint-Backlog und ist auch daran gehalten, diesen selbst gewählten Wert nicht zu überschreiten. Neue Aufgaben aus der To-Do-Liste werden also nur dann in Arbeit genommen (Pull Prinzip), wenn die Kennzahl WIP eingehalten wird.

Auch während des Sprints sollten regelmäßig, z. B. im Zuge des Daily Scrums, die in Arbeit befindlichen Items betrachtet und entsprechend gegengesteuert werden. Eine wichtige Kennzahl, auf die geachtet werden sollte, ist neben der eben schon erwähnten maximal in Arbeit befindlichen Aufgaben (WIP) die schnelle Bearbeitung (Work Item Age). Aufgaben sollten nicht zu lange in Arbeit sein, sondern zügig bearbeitet und abgeschlossen werden. Auf blockierte Items in der Warteschlange sollte der Scrum Master ein Auge werfen und sich schnellstmöglich um die Beseitigung der Impediments kümmern, damit alles bis zum Ende des Sprints erledigt werden kann und unterwegs der Fluss nicht unterbrochen wird.

Regelmäßige Überprüfung und Anpassung der Definition des Workflows ist Teil der Scrum-Ereignisse, z. B. in der Retrospektive. Dort wird der derzeitige Ablauf bewertet und notfalls angepasst. Dies können Änderungen am Kanban Board sein oder aber eine Anpassung an der Arbeitsweise.

Kanban in Scrum Events

Wie eingangs bereits erwähnt ergänzt Kanban den Scrum-Prozess um Metriken und eine visuelle Komponente. Es sind keine zusätzlichen Events vorgesehen.

Schon bei der Sprint-Planung kann das Kanban-Board zur Entwicklung des Sprint-Backlogs verwendet werden.

Das Daily Scrum mit dem Entwicklerteam sollte vor dem Kanban-Board stattfinden. Auf den ersten Blick ist sichtbar, wer gerade woran arbeitet, wo es langsamer voran geht und wo eventuell Hilfe benötigt wird. Durch die Visualisierung der Aufgaben ist es einfacher, den Fluss der Abarbeitung zu gewährleisten und eventuell gegenzusteuern. Auch wird hier überprüft, ob das WIP-Limit eingehalten wird.

Beim Sprint Review wird am Ende eines Sprints ein Blick auf die erledigten Arbeiten geworfen und überprüft, ob das Sprint Goal erreicht wurde. Hier können die oben vorgestellten Kennzahlen herangezogen werden, zum Beispiel der Durchsatz der fertig gestellten Aufgaben. Daraus lassen sich für die Zukunft die Termintreue für zugesagte Lieferungen gegenüber dem Product Owner verbessern.

Eines der Ziele des Sprints Retrospective ist die Verbesserung der Velocity beim nächsten Sprint. Auch hier kann ein Blick auf die Metriken helfen, um den nächsten Sprint zu optimieren. Definition des Workflows, WIP, Zyklus- und Durchlaufzeiten können analysiert und gegebenenfalls überlegt werden, wie diese Zahlen in Zukunft verbessert werden können.

Das Kanban-Board

Für die Visualisierung des Workflows benutzt das Team ein Kanban-Board. In Form einer Tabelle sind dort alle Aufgaben, die in einem Sprint zu erledigen sind, in verschiedenen Spalten abgebildet.

Bewährt haben sich die Spalten „ToDo", „In Progress" und „Done". Die Tabelle kann nach Belieben angepasst oder erweitert werden, sollte der Übersicht halber aber einfach gehalten bleiben.

Weitere optionale Spalten, die oft angetroffen werden, sind „Backlog" für alle Aufgaben, die für den aktuellen Sprint eingeplant sind und „On Hold" für angefangene Arbeiten, die grade blockiert sind, und an denen daher nicht weitergearbeitet werden kann. Eine exemplarische Darstellung für ein simples Kanban-Board ist in folgender Abbildung zu sehen.

Häufig findet man diese Kanban-Boards an den freien Wänden in Besprechungsräumen oder Fluren. Verwendung finden dabei Klebezettel, die vom jeweiligen Bearbeiter in die passenden Spalten geklebt werden. Genau an diesen Orten findet passenderweise auch dass Daily Scrum statt, sodass das Team einen Überblick über die aktuellen Aufgaben hat und diese entsprechend in den nächsten Bearbeitungsstatus setzen kann.

Es existieren auch digitale Lösungen, die Teil der Software ist, die von den Entwicklerteams verwendet werden. Jira, Gitlab oder Microsofts Team Foundation Server bieten Ansichten für Kanban-Boards an und ein Sprint-Backlog lässt sich so auch in dieser tabellarischen Form darstellen.

Fazit

Scrum mit Kanban, das geht in der Tat! Dabei erweitert und verbessert Kanban den Scrum-Prozess. Durch die visuelle Komponente des Kanban-Boards und die Überwachung von Kennzahlen werden Probleme in den Abläufen noch schneller erkannt und es kann zeitnah gegengesteuert und somit der Output optimiert werden.

Es existiert sogar eine offizielle Zertifizierung von scrum.org mit dem Namen „Professional Scrum with Kanban (PSK I)".