Scrumban

Scrumban ist eine agile Methode, die Elemente sowohl aus Kanban als auch aus Scrum nutzt und so zu einer neuen Methode kombiniert. Folgerichtig besteht das Wort Scrumban aus Silben beider Frameworks.

Scrum entstand in den 1970er Jahren und revolutionierte die Softwareentwicklung. Bis zu diesem Zeitpunkt entwickelte man Software nach der sogenannten Wasserfall-Methode. Ausgehend von Pflichten- und Lastenheften wurde ein Konzept erstellt. Dann begann die Implementierung gefolgt von Dokumentation und Qualitätssicherung. Erst danach, also meist erst Monate später, wurde die neu entwickelte Software den Anwendern vorgestellt. Oft zeigte das Feedback der Anwender, dass die neue Software nicht den Erwartungen entsprach. Teure und aufwändige Nacharbeiten waren die Folge.

Mit Hilfe des neuen Frameworks wurde die bisherige Art, Software zu entwickeln durch eine Arbeit in kurzen Iterationen abgelöst. Der sogenannte Product Owner erstellt ein Backlog, das die Anforderungen an die neue Software in Form von User Stories sammelt. Diese werden hinsichtlich des Implementierungsaufwands geschätzt. Aus der Gesamtmenge werden dann die Userstories für den Sprint zusammengestellt. Das Entwicklungsteam hat das Ziel, diesen Arbeitsvorrat im nächsten Sprint zu erledigen. Am Ende des Sprints, oft ein Zeitraum von zwei Wochen, stellt das Team lauffähige Software vor und der Product Owner nimmt das Ergebnis ab.

Das in diesem Framework sehr zeitnah stattfindende Feedback sorgt für zielgenaue Ergebnisse, vermeidet Fehlentwicklungen und spart somit Entwicklungsaufwand bei gleichzeitig steigender Qualität. Durch die Arbeit in Sprints steigt auch die Reaktionsfähigkeit des Teams.

Kanban entstand in den 1950er Jahren bei Toyota im Rahmen des Toyota Production Systems. Durch die Visualisierung des Produktionsgeschehens, die Einführung des Pull Prinzips und die Beachtung von WIP-Limits wurde der Materialfluss verstetigt und Qualität und Produktivität gesteigert. Kern ist dabei das Kanban Board. Dieses besteht aus Spalten, die den Produktionsschritten entsprechen. Jeder Arbeitsauftrag wird nun als Karte in einer Spalte platziert. Die Workitems wandern nun von der linken Spalte, in der sich alle neuen Aufträge befinden, Schritt für Schritt bis in die ganz rechte Spalte, in der sich die fertigen Aufträge befinden.

Hier wird intensiv das Pull-Prinzip genutzt. Erst, wenn in einer Spalte ein Platz freigeworden ist, wird ein neues Workitem aus der Spalte links davon auf den freien Platz gezogen. Auf diese Weise wird der Produktionsfluss verstetigt. Durch die gute Visualisierung der gesamten Produktionssituation werden Probleme schnell sichtbar und können behoben werden. Das Limit für die maximal in einer Spalte befindlichen Karten erzwingt quasi die Einhaltung des Pull-Prinzips.

Heute zählen beide Frameworks zu den agilen Methoden. Dabei kombiniert Scrumban Elemente beider Methoden. Scrumban orientiert sich etwas mehr an Scrum. Es nutzt dessen strukturierte Vorgehensweise und kombiniert diese mit dem prozessorientierten Vorgehen auf Basis des Pull Prinzips. Die verteilte Rollenstruktur kommt nicht zum Einsatz.

	Kanban	Scrum	Scrumban
Meetings	Daily Meeting bzw. Durch das Team festzulegen	In der Regel: täglich	Vom Team festzulegen
Sprints	nein	ja	Ja, mit Einschränkungen
Retrospektive	nein	ja	nein
Scrum-Master	nein	ja	nein
Product Owner	nein	ja	nein
Pull-Prinzip		nein	ja
Kanban Board		nein	ja
Backlog	nein	ja	ja

Scrumban vs Kanban vs Scrum in der Übersicht

Scrumban entsteht durch die Kombination von Elementen aus beiden zugrunde liegenden agilen Methoden. Aus Scrum werden die Konzepte des Backlogs und des iterativen Arbeitens übernommen. Durch das Backlog wird der gesamte Arbeitsvorrat des Projektes sichtbar. Auch wenn Iterationen genutzt werden, werden diese tendenziell kürzer und weniger stringent gehandhabt. Insbesondere der Planungsaufwand wird reduziert.

Verzichtet wird auf die komplexe Rollenverteilung und die strengen organisatorischen Vorgaben. Es gibt also weder Product Owner noch einen Scrum-Master in diesem neuen Framework. Die zeitaufwändige Planungsrunde fehlt ebenso wie die formalisierte Retrospektive.

Aus dem Kanban Framework wir das Konzept des Kanban Boards zur Visualisierung genutzt. Darüber hinaus steht des Pull-Prinzip einschließlich des WIP-Limits im Zentrum. Dieses mächtige Prinzip vermeidet Überlastungen und verstetigt den Workflow.

Lesen Sie mehr über die Scrum und Kanban Unterschiede im Vergleich.

Scrumban Board

An dieser Stelle finden Sie eine Schritt-für-Schritt-Anleitung, die Ihnen helfen soll, einfach zu beginnen. Kern ist das sogenannte Scrumban Board. Dieses ist in Spalten aufgebaut, die jeweils einen Prozessschritt darstellen. Die Workitems werden später in diesen Spalten platziert.

In der linken Spalte ist das Product Backlog enthalten. Hier werden also alle bis zum Projektende notwendigen Arbeiten aufgelistet. Es ist auch möglich, den Arbeitsvorrat nicht auf dem Scrumban Board selbst, sondern z.B. auf einer separaten Fläche darzustellen. Hierdurch bleibt die Darstellung übersichtlich.

Häufig wird zwischen der Spalte für das Backlog und der Spalte „in Arbeit“ eine weitere Spalte eingefügt. Diese kann z.B. „fertig zur Produktion“ heißen. Sie nimmt Elemente des Backlogs auf, die mit hoher Priorität erledigt werden sollen. Wird nun ein Platz in der Spalte „in Arbeit“ frei, zieht sich der Mitarbeiter eine neue Aufgabe aus der zweiten Spalte. Es werden also die Priorisierung von Aufgaben und die Zuteilung von Aufgaben zu einer Person separiert.

Obwohl in Scrumban mit Iterationen gearbeitet wird, kann das Team kontinuierlich Aufgaben aus dem Vorrat der Aufgaben bzw. der zweiten Spalte „in Arbeit“ nehmen. Dabei wird großen Wert auf ein WIP-Limit (work in progress) gelegt. Dies stellt zunächst einmal sicher, dass das Pull-Prinzip eingehalten werden muss: erst wenn in einer Spalte ein Platz freigeworden ist, kann aus der Vorspalte eine Arbeitsauftrag in die Spalte gezogen werden. Das Limit sorgt somit dafür, dass paralleles Arbeiten vermieden wird. Die Produktivität steigt enorm. Im Framework ist nicht klar festgelegt, ob das Limit nur für die Spalte gilt. Auch das Limit gleichzeitig in Arbeit befindlicher Aufgaben eines Mitarbeiters kann bzw. sollte bedacht und je nach Komplexität ggf. festgelegt werden.

Der Arbeitsvorrat kann regelmäßig ergänzt werden ohne bestimmte Zyklen zu beachten.

Durch die fehlende Retrospektive ist das Team aufgerufen, kontinuierlich zu überprüfen, ob die Methode optimal angewendet wird. Sobald Probleme festgestellt werden, ist das Team in der Verpflichtung, Abhilfe zu schaffen bzw. den Prozess zu verbessern.

Vorteile und Nachteile von Scrumban

Durch die Kombination von Elementen zweier agiler Methoden entsteht ein guter und pragmatischer Ansatz. Scrumban kombiniert die Einfachheit von Kanban mit iterativer Arbeitsweise. Dabei verzichtet es auf einige Rollen und Strukturen.

Natürlich hat auch diese Methode Vor- und Nachteile.

Vorteile

Individuell anpassbares Framework:
Da Scrumban eine relativ freie Zusammenstellung von Elementen aus Kanban und Scrum ist, kann sich das Team ein individuelles Scrumban definieren. Agile Elemente werden so zu einem Prozess zusammengestellt, der das Team bei einer gegebenen Aufgabenstellung optimal unterstützt.
Einfachheit:
Das Fehlen der Rollen und der strikten Regeln macht die Einführung einfacher und ermöglicht einen schnellen Start mit dieser agilen Methode. Gerade erfahrene Teams können so profitieren, da sie maßgeschneiderte bzw. angemessene Abläufe implementieren und so Mehraufwand vermeiden.
Visualisierung des Workflows:
Die Nutzung der Idee des Kanban Boards in Form eines Scrumban Boards erweitert die Visualisierungsmöglichkeiten und sorgt so für eine gute Transparenz.
Kontinuität des Prozesses:
Im Vergleich zur Arbeit in Sprints verfolgt Scrumban den kontinuierlichen Arbeitsfluss wie er in Kanban zur Anwendung kommt. Diese Kontinuität kann je nach Aufgabenstellung vorteilhaft sein.
Geringer organisatorischer Aufwand:
Da Planungssitzungen aus Scrum in Scrumban nicht vorgeschrieben sind, fällt deutlich weniger Aufwand für rein organisatorische Aufgaben an. Dies kann die Effizienz eines Teams deutlich verbessern.

Nachteile

Keine fest vorgegebenen Regeln:
Anders als für Scrum sind die Regeln für Scrumban nicht fest vorgegeben. Jedes Team kann daher die genutzten Elemente aus Kanban und Scrum selbst zusammenstellen. Dies kann für Neulinge in der agilen Arbeitsweise eine Herausforderung darstellen. Es kann also sinnvoll sein, sich zuvor mit Scrum und Kanban bzw. mit agilen Methoden im Allgemeinen zu beschäftigen.
Keine festen Rollen:
Im Scrum sind die Rollen des Scrum-Masters und Product Owners klar definiert. Der Scrum-Master sorgt für die Beseitigung von Hindernissen und für die Einhaltung des Prozesses. Der Product Owner sorgt für die richtige Priorisierung des Backlog und nimmt das Sprint-Ergebnis ab. Fehlen hier explizite Verantwortlichkeiten, läuft das Team Gefahr, diese Aufgaben nicht intensiv genug wahrzunehmen.
Keine Retrospektive
In der Scrum Methodik ist die Retrospektive fester Bestandteil. Hier werden Probleme sowohl in der Organisation des Ablaufs als auch im zwischenmenschlichen Bereich aufgedeckt und behoben. Bei Scrumban geht man davon aus, dass das Entwicklungsteam Schwächen im Prozess selbständig erkennt und eigenständig Verbesserungen implementiert. Dies stellt hohe Anforderungen an die Kompetenz und Autonomie des Teams. Gerade Probleme innerhalb des Teams werden auf diese Weise oft ausgeblendet und Lösungsmöglichkeiten nicht genutzt.
Keine Planungssitzungen:
Das in Scrum übliche Backlog Grooming entfällt in Scrumban. Ein Team hat hierdurch möglicherweise das Risiko, unnötige Aufgaben zu erfüllen oder nicht in der richtigen Reihenfolge zu arbeiten.

Fazit

Scrumban ist für diejenigen geeignet, denen Kanban zu wenig Struktur und Scrum zu aufwändig ist. Scrumban führt zu weniger organisatorischem Overhead also auch zu weniger Meetings. Dies kann zu höherer Effizienz des Teams führen. Gleichzeitig entfallen Rollen und Tätigkeiten, die in Scrum bewusst genutzt werden. Sie sorgen für die richtige Priorisierung, eine ständige Neubewertung des Arbeitsvorrats hinsichtlich der Wichtigkeit von Aufgaben und eine zuverlässige Aufwandschätzung.

Sie sollten sich also bewusstwerden, dass die Einfachheit von Scrumban auch durch fehlende Funktionen erkauft wird. Solange dies für die jeweilige Aufgabenstellung nicht nachteilig ist und das Team trotzdem die agilen Prinzipien berücksichtigt, kann Scrumban eine einfacher anwendbare Alternative zu Scrum sein.

Für diejenigen, für die Scrumban nicht die passende Herangehensweise ist, eignet sich möglicherweis Kanplan. Diese Methode ist stärker an Kanban orientiert, allerdings ergänzt um ein Backlog.

Sie wollen zunächst mit einem klassischen Kanban Board starten? Kein Problem. Schauen Sie sich direkt unsere Kanban Board Vorlagen an.

Wer mehr kombinieren will und z.B. direkt in den Vorgängen auf einem Kanban-Board arbeiten möchte, der profitiert von humbee. Hier finden Sie Dokumente, Aufgaben, Informationen und sogar E-Mails im Vorgang. Diese Vorgänge können Sie Kunden, Produkten oder Lieferanten zuordnen. Das Team entscheidet selbst, in welcher Form diese Vorgänge dann visualisiert werden.

Erfahren Sie, warum agile Methoden wie Kanban mit der humbee Software effektiver nutzbar sind.

Egal für welche Methode Sie sich entscheiden, humbee unterstützt Sie dabei optimal. Sie erzielen sogar zusätzliche Ergebnisse durch eine nochmals verbesserte Zusammenarbeit im Team.