Scrum und Kanban sind wohl die bekanntesten agilen Frameworks. Der 13. jährliche „State of Agile Report“ zeigt auf: 58 Prozent der Projekte laufen nach Scrum, auf Platz zwei mit 10 Prozent findet sich ein merkwürdiges Kompositum: ScrumBan. Kanban fällt mit 7 Prozent stattdessen auf Platz fünf zurück. Grund genug, sich mit der Bedeutung von ScrumBan genauer auseinanderzusetzen. Gibt es hierbei ein einheitliches Vorgehen oder ist jeder Hybrid aus Kanban und Scrum automatisch ScrumBan?
Umsetzung von ScrumBan
So viel vorweg: Das Framework verspricht das Beste aus beiden Welten zu kombinieren. ScrumBan lässt sich am einfachsten beginnend von Scrum aus umsetzen, da ein Grundverständnis der Rollen, Events und Artefakte hilfreich ist. Das ist zwar keine Voraussetzung, allerdings sollte der Scrum Guide in Grundzügen bekannt sein. Der „Scrum“ Anteil gibt der kombinierten Methodik mehr „Halt“ bzw. agile Practices als Kanban. Der „Kanban“ Anteil lenkt den Fokus stärker auf den Prozess und die Verbesserung des Workflows.
Für welche Einsatzgebiete ist ScrumBan besonders geeignet?
ScrumBan eignet sich für Instandhaltungsprojekte, ggf. in Kombination mit der klassischen Produktentwicklung, Ereignisgesteuerter Arbeit (Helpdesk, Support) sowie problemorientiertes Projekt Management (mit häufig unerwarteten User Stories und / oder Bugs). Darüber hinaus können Scrum Teams vor (Backlog, F&E) und nach der Sprintentwicklung (Systemtests, -Paketierungen) darauf zurückgreifen.
Wie genau geht aber nun ScrumBan?
Hier sind sechs Schritte in denen ihr eine Arbeitsbasis aufstellen könnt:
1. Visualisieren der Arbeit
Erstelle ein KanBan Bord mit den wesentlichen Arbeitsschritten: „To Do, In Progress, Done“ oder übernehme die Spalten, welche ihr bereits verwendet. Jegliche Arbeit sollte in einem Board erfasst werden können. Wähle den Detailierungsgrad, der für dein Team notwendig ist.
2. „Work in Progress“ (WIP) begrenzen
Teams – auch Scrum Teams – haben häufig eine Schwachstelle: Verschiedene Arbeiten werden begonnen, unterbrochen und aus verschiedenen Gründen nicht weiter aufgriffen. Das ist Verschwendung. Bei Scrum kann sich das z.B. darüber äußern, dass alle geplanten Aufgaben gestartet sind, aber nicht alle abgeschlossen werden konnten. Häufig liegt das auch an Hindernissen wie Abhängigkeiten, Abwesenheiten, fehlendem Wissen bei Übergabe etc. Das „WIP“ limitiert die Anzahl der Aufgaben pro Person oder je Spalte des Boards. Wenn das Maximum erreicht ist, kann das Team nicht weiter arbeiten, ohne den Blocker zu lösen. Das bedeutet, dass jeder im Team an der Beseitigung des Hindernisses mitwirken sollte. Studien zeigen, dass es deshalb sinnvoll ist auch im ScrumBan von „Expertenrollen“ hin zu einem größeren „T-shaped“ Wissen pro Teammitglied zu entwickeln. Der Wissenstransfer, der dafür notwendig ist, ist demnach auf längere Sicht weniger zeitintensiv als die „verlorene Zeit“, wenn auf Experten gewartet werden muss, die Probleme lösen können. Das „WIP“ Limit stellt sicher, dass der Prozess läuft und jegliche begonnene Arbeit – prozessbedingt – auch beendet werden kann.
3. Pufferplätze bzw. weitere Spalten hinzufügen
Das von Kanban bekannte „Pull“ Prinzip wird im Scrum nicht ganzheitlich gelebt: Oftmals wird Arbeit „aufgedrückt“ z.B. vom Entwickler ins Code Review. Scrum federt das Problem mit der Idee eines selbstorganisierten Teams ab, in dem die Skills breit verteilt sind. In der Realität gibt es aber doch begrenzte Ressourcen, bei denen sich dann die Arbeit stauen würde. Deshalb gibt es „Pufferplätze“ wie „bereit für Code Review“, in denen der Entwickler seine Aufgabe nach Erledigung legen kann. Der nächste freie Reviewer zieht sich die dann, sobald er Kappazitäten frei hat. Auch Pufferplätze können mit einem „WIP“ von z.B. zwei Aufgaben belegt sein. Sind diese belegt, ist das ein Signal für den Rest des Teams im Code Review zu unterstützen. Der Fluss läuft wieder.
4. Arbeit priorisieren
Wie auch im Scrum sollte die Arbeit in eine sortierte Liste überführt werden. Was ganz oben ist, ist am wichtigsten. Alternativ kann auch mit Priorisierungsstufen gearbeitet werden (critical, high, middle, low o.ä). Das stellt sicher, dass das wichtigste zuerst bearbeitet wird. Wer priorisiert? Im Kanban ist das nicht festgelegt, im ScrumBan hat das letzte Wort der Product Owner. Wenn ihr bisher noch nicht mit den Rollen gearbeitet habt – führt sie jetzt ein.
5. Fluss messen, aber Schätzungen weglassen
Aus Kanban kommt der Fokus auf den Fluss, welcher z.B. über Durchlaufzeiten bemessen werden kann. Wie lange braucht eine Aufgabe durch den Workflow (z.B. von To Do bis Done?). Tools wie Jira können euch da unterstützen und eine dem Scrum ähnliche „Velocity“ über Zeit generieren. Schätzungen wie bei Scrum brauchen wir im ScrumBan allerdings nicht, da wir keine Iterationen (Sprints) planen. Schätzungen haben aber einen Vorteil: Im Gespräch, warum die Aufgabe größer oder kleiner geschätzt wird, ergibt sich meist eine wertvolle Diskussion, wie die Umsetzung aussehen kann. Diese kann auch im ScrumBan angeregt werden, auch ohne Schätzzahl als Ergebnis.
6. Trigger Refinements
Refinements müssen nicht immer an festen Iterationszyklen geknüpft sein. ScrumBan sagt: Setze einen Trigger für deine Aufgaben, die zu erledigen sind (idealerweise Spalte „Bereit zur Umsetzung“). Fällt die Anzahl der Aufgaben unter eine bestimmte Zahl (z. B. 5), wird ein Trigger ausgelöst: Zeit für ein Refinement. Dann erst werden neue Aufgaben erstellt bzw. bereit für die Umsetzung gemacht. Unter Berücksichtigung dieser sechs Schritte könnte ein ScrumBan in einem Projekt wie folgt aussehen:
Kontinuierlichen Verbesserungsprozess im Blick
Neben dem Refinement empfiehlt es sich auch, den kontinuierlichen Verbesserungsprozess im Auge zu behalten: Dafür hat sich die Retrospektive als Event im Scrum bewährt. Damit die tägliche Synchronisation von Teams von aus Scrum bewährten 3-9 Teammitgliedern nicht zu kurz kommt, empfiehlt sich auch ein Daily einzuführen. Somit kommen wir auf folgende min. empfohlene ScrumBan Events:
- Refinement (unregelmäßig – siehe Trigger)
- Daily
- Retrospektive
Abnahme der Aufgaben triggern
Ein Review im Sinne einer Abnahme der Aufgaben kann ebenfalls getriggert werden: Alle in einem bestimmten Status befindlichen Aufgaben werden dann vom PO geprüft und abgenommen. Hierfür kann der „Done“ Status oder aber ein „Ready for Review“ Status verwendet werden (Achtung mit der Terminologie um das Code Review davon abzugrenzen). Gibt es Klärungsbedarf mit dem Team kann das ad hoc organisiert werden – es gilt das gleiche Prinzip wie beim Refinement.
Fazit
ScrumBan verspricht – richtig eingesetzt und angewendet – eine hohe Qualität, Just-in-Time Entscheidungen, kurze Vorlaufszeiten und minimale Ressourcen-Verschwendung (alles was angefangen wird, auch wird umgesetzt). Wie immer gilt: Egal welche Methodik, es gibt nicht DEN Schlüssel zum Erfolg für alle Projekte. Sollten Sie aber gerade mit einer hohen Zahl ungeplanten Arbeiten oder viel angefangener, aber wenig abgeschlossenen Aufgaben kämpfen, lohnt es sich, ScrumBan als Framework auszuprobieren.
Sie interessieren sich für ScrumBan und möchten die Methode in Ihren Projekten nutzen?
Unsere Agile Projektmanagement Experten unterstützen Sie gerne.