Scrumban: Agiles Projektmanagement mit dem Besten von Scrum und Kanban

Es ist nicht immer einfach, berühmte Eltern zu haben. Scrumban verdankt seine Popularität jedoch mit Sicherheit seiner Herkunft: Das relativ neue agile Projektmanagement-Framework geht nämlich aus zwei bereits etablierten agilen Methoden hervor – Scrum und Kanban. Doch kann Scrumban auch für sich selbst stehen?

Scrumbans Konkurrenz ist groß, denn Projektleitungen können heutzutage aus einer wachsenden Anzahl an Frameworks und Methoden wählen, mit deren Hilfe sie die Projekte steuern. Doch nicht jedes Framework ist für alle Teams gleich gut geeignet. Weil Rahmenbedingungen und Anforderungen variieren, muss die Auswahl gut überlegt sein.

In diesem Artikel erfahren Sie, was Scrumban konkret ausmacht und wann es sinnvoll ist, auf diese Methode zu setzen.

Scrumban entstand als Zwischenschritt zwischen Scrum und Kanban, um Softwareentwicklern den Übergang von der einen zur anderen Lösung zu ermöglichen. Die Methode funktionierte eigenständig aber so gut, dass sie selbst zum agilen Framework wurde.

Scrum und Kanban gaben der Hybrid-Methode verschiedene Eigenschaften mit auf den Weg. Bevor wir diese betrachten, möchten wir Ihnen kurz die beiden Elternteile vorstellen. Die Terminologie dieser Methoden ist übrigens sehr eigen und wir verwenden die gängigen Anglizismen.

Scrum hat seinen Ursprung in der Softwareentwicklung. Das agile Framework basiert auf der Grundannahme, dass ein Produkt nie fertiggestellt ist. Stattdessen werden nach Sprints, welche jeweils nicht länger als 4 Wochen andauern, stets neue Iterationen und Versionen geliefert. 

Die Zyklen während des Projektablaufes sind genau festgelegt. Es gibt ein Sprintplanning, in welchem das Team Ziele in Form von Storys festlegt. Dabei bezieht das Team die Aufgaben aus dem Backlog. Sogenannte Dailys finden in Form 15-minütiger Besprechungen statt: Hier hat das Team die Möglichkeit, den Projektfortschritt zu verfolgen.

Am Ende eines Sprints erfolgen Review und Retrospektive. Das Team stellt den Stakeholdern die Sprintergebnisse zur Verfügung und nimmt sich Zeit, ihre Zusammenarbeit zu bewerten und zu verbessern.

Auch die Rollen sind klar definiert. Der Product Owner ist für die Wertsteigerung des Produktes verantwortlich und kümmert sich um das Backlog. Der Scrum Master beseitigt Hindernisse und ist oft auch die Person, die Termine und Moderation vorbereitet.

Die agile Methode Kanban zeichnet sich durch ihre visuelle Natur aus. Auf einem Kanban-Board sind die Arbeitsstände transparent dargestellt, wobei es üblicherweise 3 Spalten gibt:

Der Autohersteller Toyota entwickelte diese Methode, um neue und bestehende Arbeits- und Produktionsprozesse zu verbessern. Auf dem Board bewegen sich die Arbeitskarten von einer Spalte in die Nächste.

Eines der Hauptelemente bei Kanban stellt das Work-In-Progress (WIP) Limit dar. Jenes legt eine Höchstgrenze für Aufgaben fest, die sich „in Arbeit“ befinden dürfen. Damit verhindert die Methode eine Überlastung des Teams. Solange diese jedoch nicht erreicht ist, können Teammitglieder nach dem Pull-Prinzip Aufgaben aus dem Backlog in Bearbeitung nehmen.

Das Framework lässt dem Anwender eine Vielzahl an Gestaltungsmöglichkeiten, denn weder Termine noch Rollen sind vorgegeben. Auch die Spalten lassen sich nach Bedarf variieren. 

Scrumban setzt sich aus den beiden oben beschriebenen Methoden zusammen.

Vererbt wurden dabei unterschiedliche Bestandteile beider Eltern:

Scrumban ist nicht fest definiert und bietet Teams damit einen großen Spielraum. So kann sich der Sprintcharakter stärker in einer Arbeitsweise verlaufen, die kontinuierlich und Flow-basiert ist. Oder das Team wendet sich vermehrt dem einen oder dem anderen „Elternteil“ zu. So steht unter anderem frei, Rollen zu etablieren, wenn es das Team für notwendig erachtet.

Abgesehen davon zeichnet sich Scrumban dadurch aus, dass keine Teamhierarchie existiert. Alle Teammitglieder sind gleichberechtigt und organisieren sich und das Team selbst. Auch eine Deadline für Aufgaben ist kein Muss, wodurch sich auch Produktlebenszyklen abbilden lassen. Teams können die Parameter wählen, unter denen sie am effektivsten arbeiten können.

Wie Sie sehen, lässt sich die Methode leicht variieren und anpassen. Nachfolgend betrachten wir einige Elemente, die Scrumban in der Praxis ausmachen.

Wie oben kurz angedeutet, gibt es bei Scrumban keine Teamhierarchien und Rollen, sofern das Team diese nicht selbst setzt. Dies bedeutet, dass Teammitglieder nicht nur auf Augenhöhe zusammenarbeiten, sondern auch gemeinsam das Projekt steuern.

In anderen Worten: Das Team ist auch für die Priorisierung gemeinsam verantwortlich. Dafür könnte man sich beispielsweise die Frage stellen, welches Element für das Produkt am wichtigsten ist. Die Antwort entscheidet das Team jedoch gemeinsam.

Das Board dient wie bei Kanban (und Scrum) als Visualisierung des Arbeitsprozesses. Anders als bei Kanban befinden sich jedoch mehr als nur drei Spalten auf dem Board. Die Kategorie „To-do“ wird oft in die zwei Spalten „Product-Backlog“ und „Sprint-Backlog“ unterteilt. Auch die Spalte „in Prüfung“ oder „zu prüfen“ sind beliebte Ergänzungen.

Wie das Board aufgeteilt ist und welche Spalten sich letztendlich darauf befinden, entscheidet das Team ebenfalls gemeinsam. Die Arbeitskarten, auf welchen die Aufgaben definiert sind, bewegen sich über das Board und visualisieren den Workflow.

Das Team legt fest, wie viele Karten gleichzeitig in einer Spalte bearbeitet werden dürfen. Das WIP-Limit gilt dabei nicht nur für die Spalte „in Bearbeitung“, sondern kann ebenfalls für andere Spalten wie „Testen“ definiert werden. Ist das maximale Limit erreicht, darf ein Teammitglied keine weitere Karte hineinziehen, bis ein Platz frei wird.

Durch Learnings kann das Team das WIP-Limit anpassen, auch hier zeigt sich die Flexibilität des Modells.

Das Team arbeitet nach dem Pull-Prinzip. Das bedeutet, jeder kann sich eigenständig Aufgaben aus dem Backlog oder einer Spalte ziehen, solange das WIP-Limit nicht erreicht ist.

Damit ist der Arbeitsfluss selbstbestimmt und Aufgaben werden einer Person nicht „aufgedrückt“. Dies lässt einen schnelleren Prozess zu, als es bei einer zentralen Vergabestelle möglich wäre. Es gibt keinen Aufseher, der erst schauen muss, wo man eine offene Aufgabe unterbringen kann. Das Team geht eigenständig und selbstverantwortlich mit den vorhandenen Kapazitäten um.

Der Vorteil der Flexibilität des Modells zeigt sich ebenfalls in der Zeitplanung. Ganz nach Bedarf kann das Team die Planung ausrichten und auch kurzfristig anpassen. Neue Aufgaben mit einer hohen Priorisierung können, anders als bei Scrum, Einzug auf das Board halten. Das Team kann also noch schneller auf neue Anforderungen reagieren.

Außerdem ist eine langfristige Planung mit Scrumban möglich, sodass nicht nur aktuelle Aufgaben, sondern auch langfristige Visionen planbar sind. Dies wird über einen Bucket-Plan ermöglicht, in welchem die Ressourcen für bestimmte Zeiträume, wie etwa Halbjahres- oder Jahrespläne, zugeordnet werden.

Das Daily, welches wie bei Scrum 15 Minuten dauert, stellt die Grundlage für die Zusammenarbeit dar. Jedes Teammitglied weiß damit genau, wo eine Aufgabe steht und wie die Kapazitäten des Teams verteilt sind.

Auch weitere Termine aus Scrum sind vorhanden:

Hier gilt: Je nach Bedarf passt das Team die Abstände und Prozesse an.

Scrumban ist durch seine Flexibilität sehr vielfältig. Das bringt zwar so einige Vorteile, aber auch ein paar Nachteile mit sich:

Wie bei jeder Methode sollten Unternehmen prüfen, ob das Framework gut zu den eigenen Anforderungen passt. In gewissen Konstellationen können wir den Einsatz jedoch besonders empfehlen – insbesondere wenn:

Das agile Framework Scrumban vereint die besten Aspekte seiner Eltern Scrum und Kanban. Es ermöglicht eine schlanke und agile Projektsteuerung und punktet mit einer Struktur, die viel Freiraum und Gestaltungsspielraum zulässt. Durch die Flexibilität des Frameworks lässt es sich auf Projekte unterschiedlichster Art anwenden und ist dabei besonders für den langfristigen Einsatz geeignet.

Scrumban bewegt sich flexibel zwischen Scrum und Kanban: Je nachdem, wie das Framework letztlich angepasst wird, kommt es mal der einen und mal der anderen Methode näher. Wenn Sie mehr über die beiden übergeordneten agilen Methoden erfahren möchten, können Sie unsere Artikel zu Scrum und Kanban lesen.