Select topic
Was ist Scrumban?
Scrumban ist ein Hybridmodell, das aus Scrum und Kanban besteht. Ursprünglich wurde es als Übergangsschritt zwischen Scrum und Kanban konzipiert, wird aber inzwischen auch als eigenständiges Framework eingesetzt.
Ein umfassender Überblick über das Framework, Praktiken und Tools
Was ist Scrumban? Die meisten Praktiker von den agilen Methoden sind mit Scrum und Kanban vertraut, aber weniger mit der Mischung von beiden – Scrumban. Ein dazwischen liegendes Framework, das darauf abzielt, das Beste aus beiden Seiten zusammenzubringen. Welche Teile beider Ansätze sind dafür erforderlich? Und wie können sie zusammenwirken? All dies und weitere Informationen finden Sie weiter unten.
Geschichte von Scrumban
Die Idee, Scrum und Kanban miteinander zu verbinden, ist nicht neu.
Jeff Sutherland und Ken Schwaber stellten den Scrum-Prozess erstmals 1995 vor, um zu helfen, kleine effektive Teams zu leiten. Im Jahr 2001 wurde das Agile Manifest veröffentlicht, in dem die 4 Werte und 12 Prinzipien definiert wurden, denen alle agilen Systeme folgen sollten. Und die Zahl der Teams, die Scrum als ihren wichtigsten agilen Ansatz verwendeten, begann zu wachsen.
Dann, im Jahr 2004, schlug David J. Anderson vor, Kanban-Praktiken auf Softwareentwicklungsprojekte anzuwenden. Der Ansatz hat sich bereits in der Produktionsindustrie als wertvoll erwiesen, und dieselben Praktiken wurden nun auch bei der Lieferung von Software angewandt. Kanban bot ein visuelles Task Board, um den Prozess zu kontrollieren, Engpässe zu identifizieren und einen klaren Workflow zu ermöglichen.
Scrumban sollte ein Zwischenschritt zwischen den beiden Praktiken sein, aber es wurde bald klar, dass es gut genug ist, um ein separates Agile Framework zu sein. Es bot einen guten Mittelweg zwischen Scrum und Kanban und blieb somit eine weitere Option für agile Praktiker.
Was ist Scrumban?
Immer häufiger anzutreffen sind Mischformen aus Kanban und Scrum, kurz »ScrumBan« genannt. Die Kombination von Scrum mit einigen Kanban-Ideen soll das System flexibler und reaktiver machen. Je nach den Anforderungen des Teams kann zum Beispiel jedes Scrum-Etappenziel auf dem Scrum Board in die drei Kanban-typischen Arbeitsphasen unterteilt werden. So lassen sich einzelne Abschnitte des Projektplans detaillierter darstellen und verwalten.
Sprints werden häufig komplett eliminiert und durch die inkrementelle Arbeitsplanung von Kanban ersetzt. Je nach Personalsituation kann sich das Team aber weiterhin durch einen Scrum Master verwalten lassen. Retrospektiven werden ebenfalls gestrichen, Mitarbeiter sollen stattdessen nach dem Kaizen-Prinzip an der Prozessoptimierung arbeiten und in den Daily Meetings gemeinsam Lösungen für arbeitsintensive oder problematische Aufgaben suchen.
ScrumBan ist keine fest definierte Methode. Jedes Team kann individuell die nützlichsten Aspekte von Scrum und Kanban übernehmen und diese frei kombinieren. Ähnlich wie bei ScrumButs ist es hier ratsam, sich zuerst mit den beiden Methoden vertraut zu machen und diese dann Stück für Stück zu modifizieren. Stellen sich messbare Verbesserungen ein, ist das Team auf dem richtigen Weg.
Wie funktioniert Scrumban?
Nach den Grundlagen können wir nun die Elemente von Scrum und Kanban auswählen, die wir miteinander kombinieren wollen, um so eine Struktur zu definieren, mit der wir unsere Ziele erreichen. Dazu schauen wir uns das Team, die Rollen und den Ablauf an:
Die Rollen
Scrum beinhaltet strikte Formalismen, Rollen wie Scrum Master, Product Owner, Development-Team, Artefakte wie Product Backlog, Sprint Backlog, Inkremente und Ereignisse (Events) wie Sprint (das eigentliche Herzstück von Scrum), Daily Scrum, Sprint Planning, Sprint Review und die Sprint Retrospektive.
Kanban hingegen hat seinen Ursprung in der Fertigungsindustrie. Hier geht es um Prozessoptimierung, also darum, nicht-wertschöpfende Tätigkeiten zu eliminieren und Fertigungsprozesse in einen gleichmäßigeren Rhythmus zu bringen.
Die Methode ScrumBan beinhaltet nach wie vor die wichtigsten Scrum-Prinzipien, bietet aber zugleich mehr Flexibilität und Freiheit, sich vorwärts zu bewegen. Der Einbezug von Kanban bringt Erweiterungen in den Prozessablauf und sorgt für eine entsprechende Visualisierung. Es ist nicht notwendig, die strikten Rollen von Scrum zu behalten. Das wichtigste ist, dass das Team schnell, effektiv und autonom Ergebnisse liefert.
Die Tools
Zur Organisation und Überwachung des Prozesses verwendet das Framework bestimmte Werkzeuge – ein Scrumban-Board mit WIP-Limits, Task Cards und Durchlaufzeit. Alle diese Werkzeuge dienen dazu, den Prozess zu visualisieren und zu kontrollieren, um sicherzustellen, dass er den größtmöglichen Wert liefert.
Scrumban-Board
Gewöhnlich teilen Teams, die Scrumban-Boards verwenden, den Arbeitsablauf in mehrere Phasen auf als bei einem Kanban-Board üblich. Dies soll verdeutlichen, dass es sich um einen graduellen Prozess handelt, der sich aus dem Sprint-ähnlichen Projektplanungsansatz ergibt. Sehr oft enthält ein Scrumban-Board immer noch eine “Sprint”-Phase oder “Story”-Arbeitspakete. So ist es möglich, den Bearbeitungsfortschritt in Bezug auf eine Story oder einem Sprint zu verfolgen, ungeachtet der Tatsache, dass das Team kontinuierlich arbeitet.
Auch sind Scrumban-Teams meist freier bei der Priorisierung von Spalten-Elementen als ihre Kanban-Kollegen, die die First-In-First-Out-(FiFo)-Regel zu beachten haben.
Die Scrumban Aufgabentafel ist als Hilfsmittel gedacht, um den aktuellen Stand eines Sprints ersichtlich zu machen. Bei einem Sprint handelt es sich um ein klar abgegrenztes Zeitfenster innerhalb eines Scrumban-Projekts. Jedes Projekt besteht aus mehreren Sprints. Sie alle dauern gleich lang; oft zwei Wochen. Alle für einen Sprint ausgewählten Aufgaben werden in den Sprint Backlog aufgenommen. Häufig in der Form von Post-its hängen sie auf der Scrumban Board bzw. dem Aufgabenboard in einer von drei Spalten: To Do, Doing oder Done.
Hier ist ein Beispiel vom Scrumban-Board in Teamhood.
WIP Limits
WIP Limits werden manchmal unbequem (sonst sind sie nicht streng genug). Die Regel ist ja: wenn eine Spalte “voll” ist, fange dort keine neue Arbeit an. Wenn also z.B. in “Development” das Limit 4 ist und dort gerade 4 Karten in Bearbeitung sind, kann keine neue Karte angefangen werden. Ein Entwickler ist dann vielleicht blockiert, das ist unbequem und am Anfang ungewohnt. Was kann er tun? Den Entwickler-Kollegen helfen, ihre Karten abzuarbeiten, z.B. durch Code Review. Oder in anderen Spalten helfen, z.B. etwas testen, ein Deployment machen usw.
Die Arbeitskarten
Ein zentrales Element in Kanban ist die Arbeitskarte, die die Beschreibung des zu erledigenden Auftrags enthält. Diese Karte wird vom Team in den „FLOW“ gezogen, der sich in verschiedene „Stadien“ bewegt. Auf meine Anregung hin initiierten wir einen Scrumban-Prozess mit einem leicht modifizierten Bug-Tracking-System: Die Fehler, die in das System eingegeben wurden, erforderten spezifische Zusatzinformationen wie bspw. Programmversion, Branche, Herkunftsregion etc. Diese wurden für die nachfolgende Priorisierung verwendet.
Lieferzeit und Zyklus-Zeit
Die Vorlaufzeit oder Lieferzeit (Lead Time) misst in Kanban die Zeit von dem Moment, in dem der Kunde eine Anfrage stellt, bis zu dem Zeitpunkt, an dem er etwas erhält. Die Zyklus-Zeit (Cycle Time) misst die Zeit, die das Entwicklungsteam benötigt, um an der Anfrage zu arbeiten und sie auszuliefern.
Beide sind gute Indikatoren für die Fähigkeit eines Teams, seinen Kunden Mehrwert zu liefern. Eine einmalige Messung ist nur von begrenztem Nutzen, da sie nicht viel aussagt und keine Zusammenhänge verdeutlicht. Dasselbe gilt für die meisten einmaligen Metriken, z.B. sagt Ihnen eine einmalige NPS-Messung ebenfalls kaum etwas aus. Im Laufe der Zeit und durch kontinuierliche Messungen kann man sehen (wie z.B. im Gantt-Diagramm), ob sich ein Team in seiner Fähigkeit verbessert, den Kunden einen Wert zu liefern.
Die Praktiken
Da Sie nun mit den Rollen und Werkzeugen vertraut sind, lassen Sie uns Sie darüber informieren, wie die Durchführung eines Scrumban-Projekts aussieht. Das Framework organisiert die Arbeit in 1-4-wöchigen Iterationen, die mit Reviews und Retrospektiven synchronisiert werden. Es gibt jedoch keine täglichen Besprechungen, und die Planung erfolgt immer nach Bedarf.
Scrumban Iterationen
Obwohl die Regel 1-4 Wochen ist, sind die meisten Scrumban-Iterationen kürzer (ca. 2 Wochen). Dies ermöglicht eine schnellere Reaktionszeit und weniger aufkommende Probleme. Ähnlich wie bei Scrum muss eine einmal begonnene Iteration bis zum Ende geführt werden. Das Team muss jedoch nicht für jede Iteration neue Aufgaben planen und kann die Aufgaben einfach nach Priorität aus dem Backlog verschieben.
Planning
Zu Beginn eines Sprints findet das Sprint Planning (auch als Sprint Planning Meeting oder Sprint-Planungssitzung bezeichnet) als Kick-off statt. Es ist ein Treffen zur Planung der Anforderungen und Arbeitspakete, die im aktuellen Sprint umgesetzt werden sollen. Voraussetzung für das Meeting ist ein gepflegtes und priorisiertes Product Backlog. Es dient als Quelle zur Erstellung eines Selected Backlogs mit den wichtigsten und am höchsten priorisierten Anforderungen. Das Selected Backlog ist quasi eine Wunschliste des Product Owners. Wie viele und welche Backlog Items ins Sprint Backlog aufgenommen und in der Folge tatsächlich umgesetzt werden, entscheidet das Entwicklungsteam.
Die Review
Das Sprint Review ist ein Treffen am Ende eines Sprints zur Beurteilung und Abnahme der erledigten Arbeit in Bezug auf das gesteckte Sprintziel. Idealerweise hat das Team jedes Sprint Backlog Item fertiggestellt, wichtiger ist aber die Erreichung des Sprint-Ziels, das im Sprint Planning gemeinsam vereinbart wurde. Präsentiert werden beim Review lediglich die Items, die entsprechend der Definition of Done auch tatsächlich fertiggestellt wurden.
Die Retrospektive
An der Scrumban-Retrospektive nehmen das Entwicklungsteam und der Scrum Master teil. Über die Teilnahme des Product Owners gibt es unterschiedliche Auffassungen.
Die Retrospektive gibt Raum und Gelegenheit für offenes Feedback im Team, zur Vermeidung von Frust und Beseitigung von Missverständnissen. Es geht hier auch um die Verbesserung der Zusammenarbeit im Team und somit um die Verbesserung von Abläufen und Inhalten. Es geht auch um das Zusammenspiel zwischen einzelnen Entwicklern, um das Wirken des Scrum Masters und die Kommunikation mit dem Product Owner. Damit ist die Retrospektive wichtiger Teil eines kontinuierlichen Verbesserungsprozesses (KVP).
Langzeitplanung
Ein großer Vorteil von Scrumban im Vergleich zu Scrum und Kanban ist die Möglichkeit, langfristig zu planen. Anstatt sich nur auf die aktuelle Situation zu konzentrieren, bietet dieses Framework die Möglichkeit, Visionen und Ziele zu erstellen. Die Praxis heißt – Bucket-orientierte Blockplanung .
Die Bucket-orientierte Kapazitätsprüfung stellt ein Verfahren dar, das es ermöglicht, im Rahmen der Blockplanung die Kapazitätsverfügbarkeit von wichtigen Ressourcen zu überprüfen und die notwendige Kapazität zu reservieren.
1-Jahr-Bucket – für große, grob definierte Ziele, die ein Team innerhalb eines Jahres erreichen möchte.
6-Monat-Bucket – für Ziele, die kurz vor der Umsetzung stehen. Sie werden zu etwas konkreteren Plänen, die erreicht werden sollen.
3-Monat-Bucket – für Pläne, die fast fertig sind. Es werden weitere Details hinzugefügt und notwendige Schritte wie die Analyse durchgeführt.
„Current Bucket“ – für Aufgaben, die das Team als nächstes umsetzen wird. Wenn ein Plan bereit ist, wird er vom Team in diesen Bereich verschoben und in klare Aufgaben aufgeteilt, die zu erfüllen sind.
Wollen Sie noch mehr über Scrumban wissen? Hier ist unsere „Scrumban ultimative Anleitung„. Werfen Sie einen Blick darauf!
Scrumban Software
Mit der wachsenden Popularität verschiedener agiler Frameworks bieten immer mehr Projektmanagement-Tools die Möglichkeit, agile Methoden einzusetzen. Scrumban ist keine Ausnahme, und inzwischen gibt es eine Vielzahl von Auswahlmöglichkeiten für Teams. Solche Tools ermöglichen eine einfachere und schnellere Verwaltung von Projekten, bieten zusätzliche Informationen über den Arbeitsprozess und verhindern die Speicherung von Projektinformationen an verschiedenen Orten.
Wenn Sie sich für ein Scrumban-Tool entscheiden, sollten Sie nach einer Lösung suchen, die leicht modifizierbar ist und Ihre Bedürfnisse nicht nur jetzt, sondern auch in der Zukunft erfüllen kann. Eine Lösung wie Teamhood bietet Ihnen alle traditionellen agilen Funktionen ebenso wie andere Projektmanagement-Tools wie ein Gantt-Diagramm und Projektportfolio-Management. Schauen Sie sich dieses Video an, um zu sehen, wie Kanban-Boards in Teamhood funktionieren.
Zusammenfassung
Scrumban begann als eine Möglichkeit für Scrum-Praktiker Kanban auszuprobieren. Für einige schien es jedoch eine bessere Alternative zu sein, und so wurde Scrumban zu einem eigenständigen Framework.
Obwohl Scrum und Kanban unter Praktikern von den agilen Methoden immer noch beliebter sind, hat Scrumban seine eigenen Anwender. Es ist perfekt für diejenigen, die etwas Struktur brauchen, aber nicht mit Zeremonien überfordert sein wollen. Ebenso wie für diejenigen, die ihren Prozess klar visualisieren und Aufgaben bis zum Abschluss verfolgen wollen. In unserem nächsten Artikel können Sie sich auch mit einem detaillierteren Vergleich der drei Methoden befassen.
Scrumban passt am besten zu Projekten mit unklaren und wechselnden Prioritäten. Es eignet sich auch gut für Teams, die sich auf das Hinzufügen von Funktionen und die Unterstützung eines bestehenden Produkts konzentrieren.
Erstellen Sie Ihr Scrumban-Board in Teamhood und sehen Sie selbst, ob dieses Framework Ihren Bedürfnissen entspricht!
