Scrumban

Inhaltsverzeichnis: Definition – Entstehungsgeschichte – Unterschiede und Gemeinsamkeiten zwischen Scrum und Kanban – Bucket-Size-Planung – Varianten – Fragen aus der Praxis – Hinweise

Wissen kompakt: Scrumban kombiniert Teile von Scrum und Kanban mit eigenen Elementen, um Projekte agil, strukturiert und mit guter Übersicht durchzuführen.

Scrumban – das Beste aus verschiedenen Ansätzen kombiniert und erweitert

Sie wollen agil arbeiten, aber jederzeit erkennen, wie der Stand der Entwicklung ist? Sie wollen flexibel und gleichzeitig strukturiert agieren, und gleichzeitig die Arbeitslast der Projekt- oder Entwicklungsmitarbeiter sinnvoll managen? Sie wollen lang-, mittel- und kurzfristig planen? Dann könnten Scrumban ein interessanter Ansatz für Sie sein!

Scrumban kombiniert zentrale Teile von Scrum, einem Framework mit Events, Verantwortlichkeiten und Artefakten für die iterative Entwicklung von komplexen Produkten und Services, und Kanban, einer Methode zur Visualisierung von Arbeitsprozessen, die hilft, Engpässe zu identifizieren und Abläufe kontinuierlich zu verbessern. Diese Kombination wird durch zusätzliche Elemente erweitert.

Scrumban - das Beste aus verschiedenen Ansätzen kombiniert und erweitert

Die Entstehungsgeschichte von Scrumban

Die Entwicklung von Scrumban geht auf eine wachsende Notwendigkeit zurück, die Vorteile von Scrum und Kanban zu kombinieren, um Teams ein flexibleres und effizienteres Arbeiten zu ermöglichen. Corey Ladas, ein US-amerikanischer Unternehmensberater und ehemaliger Microsoft Entwicklungsmanager, prägte den Begriff 2008 in einem gleichnamigen Dokument und veröffentlichte 2009 das Buch “Scrumban: Essays on Kanban Systems for Lean Software Development”, in dem er den Ansatz umfassend schrieb [1].

Scrum und Kanban sind zwei der bekanntesten agilen Ansätze, die unterschiedliche Stärken haben. Scrum bietet ein festes Framework, das u. a. sogenannte Sprints, definierte Verantwortlichkeiten (Scrum Master, Product Owner, Entwickler) und eine klare Struktur für die Organisation von Aufgaben verwendet. Es ist besonders effektiv für Projekte, die regelmäßige Iterationen und Feedback-Schleifen benötigen.

Kanban ist ein Ansatz, der auf der Visualisierung von Arbeitsabläufen basiert. Es erlaubt Teams, Aufgaben in einem kontinuierlichen Fluss zu bearbeiten und verwendet Work-in-Progress (WIP)-Limits, um die Produktivität zu maximieren und Engpässe zu vermeiden. Kanban eignet sich besonders für Teams, die dynamisch auf Änderungen reagieren müssen und keine festen Zyklen benötigen.

Beeinflusst wurde die Entwicklung von Scrumban durch das Konzept der Feature Crews bei Microsoft. Feature Crews sind individuell zusammengestellte, funktionsübergreifende Teams, die für die Entwicklung bestimmter Features verantwortlich sind. Innerhalb dieser Crews wurde häufig das Kanban-Board verwendet, um die Arbeitsschritte zu visualisieren und die Aufgabenverteilung zu optimieren.

Corey Ladas beobachtete, wie die Feature Crews bei Microsoft arbeiteten, und erkannte das Potenzial, die Flexibilität von Kanban mit der strukturierten Planung von Scrum zu verbinden. Und er entwickelte Scrumban als einen Ansatz, um Teams, die bereits Scrum verwendeten, den Wechsel zu Kanban zu erleichtern. Viele Teams waren mit den festen Strukturen von Scrum zufrieden, benötigten jedoch mehr Flexibilität in ihren Arbeitsabläufen, besonders wenn sie kontinuierliche Aufgaben wie Wartung oder Support übernahmen. Was als Übergang gedacht war, entwickelte sich jedoch schnell zu einem eigenständigen Ansatz. Viele Teams fanden heraus, dass Scrumban auch als dauerhafte Lösung genutzt werden konnte.

Unterschiede und Gemeinsamkeiten zwischen Scrum und Kanban

Um sich den Unterschieden und Gemeinsamkeiten von Scrum und Kanban zu nähern. lohnt sich ein Blick auf zentrale Elemente der Ansätze, auf die Zusammenarbeit der Beteiligten und auf Werte.

Beginnen wir mit Scrum:

Scrum ist ein Framework für die schrittweise Planung und Realisierung von Produkten und Services. Es hilft Unternehmen, wenn Entwicklungen zu Projektbeginn zu komplex für exakte Planungen sind, sich Anforderungen oder Prioritäten ändern, Kunden schnelle Mehrwerte benötigen oder Risiken minimiert werden müssen. Es definiert ein inkrementelles, iteratives Vorgehen und basiert auf Empirie (Wissen entsteht aus Erfahrung und das Treffen von Entscheidungen erfolgt auf der Grundlage von Beobachtungen) sowie Lean Thinking (Verschwendung wird vermieden und der Fokus liegt auf dem Wesentlichen).

Definiert ist das Framework mit seinen “Spielregeln” im Scrum Guide. Dieser nennt

fünf Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive),
drei Verantwortlichkeiten (Scrum Master, Product Owner und Entwickler) und
drei Artefakte (Product Backlog, Sprint Backlog und Inkrement).

Das Herz des Frameworks ist der sogenannte Sprint. Er umfasst alle anderen Events. Es handelt sich um eine Iteration von gleichbleibender Dauer mit ähnlichen Handlungen. Damit das Vorgehen funktioniert, müssen Organisationen aber nicht nur lernen, die Regeln des Frameworks anzuwenden, sondern eine offene Haltung zu entwickeln, um die Werte (Commitment bzw. Selbstverpflichtung, Mut, Offenheit, Fokus und Respekt) mit Leben zu füllen.

Und wie sieht es bei Kanban aus?

Kanban ist eine Methode des Arbeits- und Prozessmanagements, die in den 1940er Jahren in der japanischen Automobilindustrie entwickelt wurde, um den Materialfluss in Produktionsprozessen zu optimieren. Seit den 2000er Jahren wird Kanban auch in der Wissensarbeit genutzt und gilt als eine Methode im agilen Projektmanagement bzw. in der Software- und Produktentwicklung.

Es basiert auf vier Grundprinzipien, die sicherstellen, dass Prozesse effizient und kontinuierlich verbessert werden können:

Beginnen Sie mit dem, was Sie jetzt tun
Verfolgen Sie inkrementelle, evolutionäre Veränderungen
Respektieren Sie bestehende Prozesse, Rollen und Verantwortlichkeiten
Ermutigen Sie Menschen auf allen Ebenen, Führung zu übernehmen

Diese Prinzipien sind universell anwendbar, egal ob in der Produktion, der Softwareentwicklung oder in anderen Bereichen der Wissensarbeit. Neben den vier Prinzipien kennt Kanban auch sechs Praktiken:

Visualisieren Sie Ihre Arbeit
Limitieren Sie die parallele Arbeit (WIP-Limit)
Managen Sie den Arbeitsfluss
Formulieren Sie explizite Prozessregeln
Implementieren Sie Feedback-Schleifen
Verbessern Sie kontinuierlich und gemeinsam den Prozess

Neben den Prinzipien und Praktiken basiert Kanban auf neun Werten:

Transparenz
Balance
Kollaboration
Kundenfokus
Arbeitsfluss
Führung
Verständnis
Vereinbarung
Respekt

Diese Werte bilden das Rückgrat der Kanban-Methode und helfen Teams, nicht nur ihre Arbeit zu organisieren, sondern auch eine Kultur der kontinuierlichen Verbesserung, des Lernens und der Zusammenarbeit zu entwickeln.

Bei genauerer Betrachtung lässt sich erkennen, dass viele Aspekte der beiden Ansätze sehr nah beieinanderliegen. Kanban spricht von Kundenfokus, Scrum definiert ein Sprint-Ziel, das festlegt, warum der Sprint für Stakeholder wichtig ist. Kanban nutzt Feedback-Schleifen und Scrum fordert Sprint Reviews und Retrospektiven. Kanban spricht von Führung und Vereinbarung, Scrum von Mut und Selbstverpflichtung.

Und wo liegen Unterschiede zwischen Scrum und Kanban?

Scrum arbeitet mit definierten Iterationen von gleichbleibender Dauer, den sogenannten Sprints, die in der Regel 1 bis 4 Wochen dauern. Am Ende jedes Sprints muss ein funktionsfähiges Produktinkrement vorliegen. Es definiert drei spezifische Verantwortlichkeiten bzw. Accountabilitys (Scrum Master, Product Owner und Developer) mit entsprechenden Aktivitäten, verwendet fünf Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive) und deklariert drei Artefakte (Product Backlog, Sprint Backlog und Increment).

Im Gegensatz dazu arbeitet Kanban ohne feste Iterationen. Aufgaben werden kontinuierlich durch den Workflow geschoben, sobald Kapazitäten frei werden. Es gibt keine festen Rollen und das Vorgehen ist flexibel in Bezug auf Meetings bzw. Events, dennoch werden regelmäßige Reviews, Feedbackschleifen und Anpassungen des Workflows praktiziert. Darüber hinaus werden bei Kanban WIP-Limits verwendet, um die Anzahl der gleichzeitig bearbeiteten Aufgaben zu begrenzen und den Fokus auf die Fertigstellung der Aufgaben zu legen.

Scrum adressiert die Lieferung eines definierten Umfangs innerhalb eines Sprints. Es betont das inkrementelle Wachstum des Produkts mit dem Ziel, am Ende jedes Sprints ein potenziell auslieferbares Produktinkrement zu haben. Der Umfang wird vor jedem Sprint gemeinsam geschätzt und vereinbart. Änderungen während eines Sprints sind möglich, werden aber idealerweise vermieden. Die Priorisierung neuer Aufgaben erfolgt in der Regel im Sprint Planning. Hilfsmittel wie Taskboards, Burn-Down- oder Burn-Up-Charts sind in der Praxis häufig anzutreffen, werden aber im Scrum Guide nicht erwähnt.

Kanban hingegen stellt den kontinuierlichen Arbeitsfluss und die Optimierung des Gesamtprozesses in den Vordergrund. Es geht darum, Durchlaufzeiten zu verkürzen und Engpässe zu identifizieren. Ziel ist es, einen gleichmäßigen, stabilen Arbeitsablauf zu erreichen, bei dem die Aufgaben möglichst schnell und effizient erledigt werden. Änderungen können jederzeit vorgenommen werden, da es keine festen Iterationen gibt. Aufgaben werden dynamisch priorisiert, oft in Echtzeit, basierend auf dem aktuellen Bedarf und der Verfügbarkeit. Visualisiert wird der Arbeitsfluss mithilfe des Kanban-Boards.

Fazit: Es gibt viele Ähnlichkeiten und Gemeinsamkeiten zwischen beiden Ansätzen. Scrum definiert Elemente, die Kanban nicht explizit nennt. Und Kanban bietet durch die Visualisierung des Workflows und die Nutzung von WIP-Limits Aspekte, die eine praktische Anwendung von Scrum sinnvoll ergänzen können.

Die Bucket-Size-Planung von Scrumban

Die Bucket-Size-Planung ist eine spezielle Methode in Scrumban, die dazu dient, Aufgaben basierend auf ihrem Zeithorizont in unterschiedliche “Buckets” (Eimer) einzuteilen. Diese Einteilung hilft Teams, Prioritäten zu setzen und gleichzeitig eine langfristige Planung zu ermöglichen, die flexibel auf Veränderungen reagieren kann. Die Buckets repräsentieren verschiedene Planungsphasen und reichen von langfristigen strategischen Zielen bis hin zu kurzfristigen, detaillierten Aufgaben.

In der Regel umfasst das System drei Buckets:

Der langfristige Bucket (häufig der 1-Jahres-Bucket) wird für strategische Ziele verwendet, wie z. B. die Erschließung neuer Märkte oder die Einführung eines neuen Produkts. Entsprechende Aufgaben sind wenig detailliert und bieten lediglich eine grobe Übersicht über zukünftige Tätigkeiten.
Sobald das Unternehmen beschließt, mit einem Plan voranzuschreiten, werden Aspekte konkretisiert und landen im zweiten Bucket (oft der 6-Monats-Bucket). In dieser Phase kristallisieren sich die Hauptanforderungen des Plans heraus, und die Aufgaben werden detaillierter ausgearbeitet. Diese Phase dient der Vorbereitung für die tatsächliche Umsetzung.
Im dritten Bucket (oft der 3-Monats-Bucket) landen schließlich die Aufgaben, die in klare, umsetzbare Teile zerlegt werden, die unmittelbar bearbeitet werden können. Sobald das Team bereit ist, neue Aufgaben zu übernehmen, “zieht” es die Arbeit aus diesem Bucket und beginnt mit der Umsetzung. Dieser dynamische, bedarfsorientierte Ansatz stellt sicher, dass die Arbeit kontinuierlich fließt, ohne auf feste Planungsmeetings angewiesen zu sein.

Die Bucket-Size-Planung ermöglicht es Teams, strategische Langfristziele in kleinere, kurzfristige Aufgaben herunterzubrechen, die dann je nach Kapazität und Priorität bearbeitet werden. So bleibt das Team flexibel und reaktionsfähig, während die langfristige Planung im Blick bleibt und schrittweise umgesetzt wird.

Was sind praktische Varianten von Scrumban?

Scrumban ist ein äußerst flexibler Ansatz, der je nach Team und Projekt unterschiedliche Ausprägungen annehmen kann. Teams können entscheiden, welche Elemente aus Scrum und Kanban sie beibehalten oder anpassen wollen. Hier sind einige der Varianten von Scrumban in der Praxis:

Scrum mit Kanban-Board und WIP-Limits

In dieser Variante nutzt das Team den vollumfänglichen Scrum-Ansatz und zusätzlich das Kanban-Board zur Visualisierung der Arbeit und WIP-Limits zur Einschränkung gleichzeitiger Aufgaben. Je nach Ausprägung kann dabei das Kanban-Board das klassische Sprint Backlog ersetzen oder als Anzeige des Workflows der Tätigkeiten fungieren, die im Sprint Backlog eingeplant wurden. So oder so verbessert sich die Übersicht im laufenden Sprint; wenig überraschend dürfte dies die häufigste Variante in der Praxis sein.

Scrumban ohne Accountabilitys

In dieser Variante verzichtet das Team auf die formalen Accountabilitys wie Scrum Master und Product Owner. Das Team arbeitet dahingehend selbstorganisiert, dass es mittels Pull-System und WIP-Limit den Arbeitsfluss steuert, während die Planungs- und Rollenstruktur von Scrum reduziert oder ganz weggelassen wird. Diese Variante eignet sich bspw. für Teams, die mit klassischen Rollen agieren.

Scrumban ohne Iterationen

Hier wird auf die festen Sprints verzichtet, was dem Team erlaubt, in einem kontinuierlichen Fluss zu arbeiten, ohne den Zyklus fester Iterationen. Das Kanban-Board ist das zentrale Element, während Aufgaben flexibel durch den Workflow geschoben werden. Teams arbeiten dynamisch und reagieren flexibel auf neue Anforderungen oder Änderungen, ohne sich an feste Zeitrahmen zu binden. Diese Variante passt gut zu Umgebungen mit schnell wechselnden Anforderungen oder Support- und Wartungsteams, bei denen eine kontinuierliche Bearbeitung von Aufgaben wichtig ist.

Scrumban mit Bucket-Size-Planung

Diese Variante verwendet den Bucket-Size-Ansatz, bei dem Aufgaben in langfristige, mittelfristige und kurzfristige Kategorien (Buckets) eingeteilt werden. Teams ziehen ihre Aufgaben aus den kurzfristigen Buckets. Diese Variante eignet sich besonders gut für größere Projekte mit mehreren Phasen oder für strategische Planungen, die nach und nach in detaillierte Aufgaben überführt werden.

Fazit:

Scrumban bietet verschiedne Möglichkeiten, Scrum und Kanban zu kombinieren und anzupassen. Teams können das Framework flexibel gestalten, indem sie entweder die strukturierten Elemente von Scrum beibehalten und um Kanban-Elemente ergänzen oder sich mehr in Richtung Kanban orientieren, um Agilität und Flexibilität zu maximieren. Egal ob man Scrumban mit oder ohne Sprints, Rollen oder Buckets praktiziert – es lässt sich individuell an die Anforderungen und Arbeitsweisen eines Teams anpassen.

Fragen aus der Praxis

Hier finden Sie einige Fragen und Antworten aus der Praxis:

Was sind die Vorteile von Scrumban?

Scrumban kombiniert die besten Elemente von Scrum und Kanban und bietet eine flexible, anpassbare Methode, die sich für verschiedene Arbeitsumgebungen eignet. Hier sind einige der wichtigsten Vorteile:

Es ist besonders flexibel, da Teams entscheiden können, welche Elemente von Scrum und Kanban sie nutzen möchten. Sie können Sprints verwenden, müssen es aber nicht, und können je nach Projektanforderung entweder stark strukturiert oder locker organisiert arbeiten. Dadurch passt sich Scrumban leichter an sich ändernde Anforderungen oder neue Prioritäten an.
Durch die Verwendung von Work-in-Progress (WIP)-Limits und einem Pull-System wird der Fokus auf den Abschluss der Aufgaben gelegt. Dies hilft, Multitasking zu reduzieren und die Effizienz zu steigern, indem das Team sich auf eine begrenzte Anzahl von Aufgaben gleichzeitig konzentriert. Engpässe werden schnell sichtbar und können direkt angegangen werden, was zu einer besseren Kontrolle über den Arbeitsprozess führt.
Es erlaubt Teams, kontinuierlich Anpassungen und Verbesserungen vorzunehmen, da es keine festen Sprints oder abgeschlossene Zeiträume gibt. Teams können ihren Arbeitsprozess regelmäßig optimieren, indem sie auf die aktuellen Bedürfnisse reagieren und ihren Workflow verbessern. Diese kontinuierliche Überprüfung führt zu inkrementellen Verbesserungen ohne fest vorgeschriebene Retrospektiven wie in Scrum.
Die Planung erfolgt dynamisch und ist weniger aufwändig als in Scrum. Anstelle eines festen Sprint-Backlogs können Teams on-demand Aufgaben priorisieren und die Arbeit je nach Verfügbarkeit und Bedarf anpassen. Dies macht die Planung schlanker und schneller, ohne dabei die langfristigen Ziele aus den Augen zu verlieren.
Es eignet sich besonders gut für dynamische Umgebungen, in denen Anforderungen oft wechseln, wie etwa bei Wartungs-, Support- oder kontinuierlichen Entwicklungsprojekten. Teams, die sowohl kontinuierliche Aufgaben als auch größere, geplante Meilensteine haben, profitieren von der Flexibilität und Anpassungsfähigkeit, die der Ansatz bietet.
Wie bei Kanban liegt ein zentraler Vorteil in der Visualisierung des Workflows durch ein Kanban-Board. Das Board macht den Fortschritt der Aufgaben und potenzielle Engpässe sichtbar, was zu einer besseren Übersicht und Teamtransparenz führt. Es unterstützt das Team dabei, auf einen Blick zu erkennen, wo es Probleme gibt und wo Ressourcen effizienter eingesetzt werden könnten.
Im Gegensatz zu Scrum, das festgelegte Verantwortlichkeiten vorschreibt, erlaubt Scrumban es den Teams, ohne feste Rollen zu arbeiten, wenn dies besser zum Team passt. Diese Selbstorganisation kann die Effizienz steigern, wenn die Verantwortung flexibel aufgeteilt wird.
Da Scrumban auf kontinuierlichem Fluss basiert und nicht auf fixierten Sprint-Zyklen, können Teams schnell auf Änderungen reagieren. Neue Anforderungen können sofort aufgenommen und priorisiert werden, ohne dass sie auf das Ende eines Sprints warten müssen. Dies macht den Ansatz besonders nützlich in Projekten, bei denen sich Anforderungen oft und schnell ändern.

Und zu guter letzt können Teams durch die Bucket-Size-Planung können Teams ihre langfristigen, mittelfristigen und kurzfristigen Aufgaben besser strukturieren. Dies ermöglicht es, strategische Ziele zu verfolgen und gleichzeitig flexibel auf kurzfristige Anforderungen zu reagieren. So wird die Balance zwischen strategischer Ausrichtung und operativer Effizienz gewahrt.

Was sind Herausforderungen bei der Arbeit mit Scrumban?

Obwohl Scrumban eine flexible und anpassbare Methode ist, bringt es auch einige Herausforderungen mit sich, die Teams beim Einsatz beachten sollten. Diese Schwierigkeiten resultieren oft aus der Kombination von Scrum- und Kanban-Prinzipien sowie aus der Flexibilität, die Scrumban bietet. Hier sind einige der häufigsten Herausforderungen:

Da Scrumban im Gegensatz zu Scrum keine fest definierten Verantwortlichkeiten wie den Scrum Master oder Product Owner vorgibt, kann es zu Unsicherheiten kommen, wer für welche Aufgaben verantwortlich ist. Diese fehlende Klarheit kann dazu führen, dass sich niemand zuständig fühlt. Teams, die von Scrum kommen, müssen möglicherweise ihre Arbeitsweise anpassen und klare Verantwortlichkeiten selbst festlegen.
Ohne Sprints kann es schwierig sein, den Fortschritt und die Einhaltung von Fristen zu überwachen. Ohne klare Zeitrahmen fehlt möglicherweise der Druck, Aufgaben bis zu einem bestimmten Zeitpunkt zu erledigen, was das Risiko birgt, dass Projekte ins Stocken geraten. Es besteht die Herausforderung, den richtigen Rhythmus zu finden, um Aufgaben effizient abzuschließen, ohne die Strenge eines Sprint-Zyklus.
Trotz der Verwendung von WIP-Limits, kann es für Teams schwierig sein, diese Limits richtig zu setzen und einzuhalten. Wenn zu viele Aufgaben gleichzeitig bearbeitet werden, kann es zu Überlastung und Multitasking kommen, was die Produktivität verringert und den Fokus verwässert. Teams müssen oft experimentieren, um die richtige Anzahl an parallelen Aufgaben zu finden, die sowohl machbar als auch effizient ist.
Da feste Meetings fehlen, besteht die Gefahr, dass die kontinuierliche Verbesserung vernachlässigt wird. Ohne regelmäßige Überprüfung kann es dazu kommen, dass das Team festgefahrene Prozesse nicht erkennt und keine Verbesserungen vornimmt. Es erfordert Disziplin, die Prozesse ständig zu hinterfragen und anzupassen, ohne fest eingeplante Zeiträume zur Reflexion.
In Scrumban erfolgt die Priorisierung oft dynamisch, je nachdem, welche Aufgaben als nächstes verfügbar sind oder welche Anforderungen neu aufkommen. Das Fehlen eines festen Sprint-Backlogs kann dazu führen, dass Teams Schwierigkeiten haben, Prioritäten klar zu setzen und den Überblick über wichtige Aufgaben zu behalten. Diese flexible Priorisierung kann in Umgebungen mit vielen schnell wechselnden Anforderungen chaotisch wirken, wenn nicht klare Kriterien für die Priorisierung festgelegt sind.
Ohne festgelegte Sprint-Zyklen oder einen strikten Fokus auf langfristige Ziele kann die Gefahr bestehen, dass sich Teams zu stark auf kurzfristige Aufgaben konzentrieren und strategische Themen vernachlässigen. Es erfordert zusätzliche Planung, um sicherzustellen, dass langfristige Ziele weiterhin verfolgt werden.
Zudem kann es für Teams eine Herausforderung sein, die richtige Balance zwischen Scrum und Kanban zu finden. Es ist wichtig, die Arbeitsweise zu iterieren und anzupassen, um herauszufinden, welche Elemente aus beiden Ansätzen am besten funktionieren und wie sie optimal kombiniert werden können.

Fazit: Die Arbeit mit Scrumban bringt eine Reihe von Herausforderungen mit sich, insbesondere in Bezug auf die klare Definition von Rollen, die dynamische Priorisierung und das Fehlen fester Zeitrahmen. Dennoch bietet der Ansatz Teams auch die Flexibilität, ihre Prozesse kontinuierlich zu verbessern und effizienter zu gestalten. Um diese Herausforderungen zu bewältigen, müssen Teams diszipliniert sein, ihre Arbeitsweise regelmäßig hinterfragen und flexibel auf die Bedürfnisse des Projekts reagieren.

Ist Scrumban ein Scrumand oder ein Scrumbut?

Um diese Frage zu beantworten, lohnt ein kurzer Blick auf die Definitionen der Begriffe Scrumand und Scrumbut.

Die Erweiterung des Scrum Frameworks um Elemente oder Methoden wird als Scrumand bezeichnet. Die Bezeichnung geht auf “We use Scrum and …” zurück. Wird also Scrum durch die Visualisierung des Workflows mithilfe eines Kanban-Boards und der Verwendung von WIP-Limits ergänzt, handelt es sich um ein Scrumand.

Der Verzicht auf einzelne Scrum Elemente wird als Scrumbut bezeichnet. Die Bezeichnung geht auf “We use Scrum, but …” zurück. Verzichtet also eine Organisation bei der Verwendung von Scrumban auf die Nutzung von Iterationen und Verantwortlichkeiten, dann handelt es sich um ein Scrumbut. Gleichzeitig handelt es sich aber auch um ein Scrumand, denn die Verwendung der Visualisierung des Arbeitsflusses und die Limitierung der Arbeitslast ergänzt Scrum um zusätzliche Aspekte.

Was ist ein Feature Freeze?

Ein Feature Freeze bezeichnet im Rahmen von Scrumban (und auch anderen agilen Methoden) den Moment, in dem entschieden wird, dass keine neuen Features oder größeren Änderungen mehr hinzugefügt werden. Stattdessen konzentriert sich das Team ausschließlich auf das Abschließen der laufenden Arbeit, die Korrektur von Fehlern oder das Testen des bestehenden Codes, um ein stabiles Produktinkrement zu gewährleisten.

In Scrumban kann ein Feature Freeze vor einem wichtigen Meilenstein oder Release stattfinden. Da Scrumban normalerweise keinen festen Sprint-Rhythmus hat, sondern einen kontinuierlichen Workflow mit dynamischer Priorisierung, kann ein Feature Freeze helfen, vor einem spezifischen Ziel (wie einem Produkt-Release) Klarheit und Stabilität zu schaffen. Er wird eingeführt, um sicherzustellen, dass alle laufenden Arbeiten abgeschlossen und das Produkt stabil ist, bevor weitere Funktionen implementiert werden.

Was ist eine Software Triage?

Nach einem Feature Freeze, wenn keine neuen Features mehr einem Release hinzugefügt werden, kann eine Software Triage durchgeführt werden. Hier wird vom Projektleiter oder Team entschieden, welche der bereits in Entwicklung befindlichen Features oder Aufgaben bis zum anstehenden Projekttermin fertiggestellt werden sollen und welche unvollendet bleiben. Das Ziel ist es, sicherzustellen, dass sich das Team auf die kritischen Features fokussiert und diese pünktlich fertigstellt, während weniger wichtige Funktionen gegebenenfalls verschoben oder gestrichen werden.

Der Ablauf einer Software Triage ist wie folgt:

Alle Features, die sich bereits im Workflow befinden, werden überprüft. Jedes Feature wird hinsichtlich seiner Bedeutung für das Projekt bewertet. Features, die unbedingt erforderlich sind (z. B. für die Markteinführung), werden als kritisch eingestuft, während andere als optional oder weniger dringend betrachtet werden.
Es wird überprüft, wie weit die Entwicklung der einzelnen Features fortgeschritten ist. Features, die bereits fast abgeschlossen sind, werden tendenziell priorisiert, während Features, die noch viel Arbeit erfordern, möglicherweise verschoben werden.
Basierend auf der Bewertung entscheiden die Verantwortlichen oder Beteiligten, welche Features unbedingt bis zum Projekttermin abgeschlossen werden müssen und welche möglicherweise unvollendet bleiben oder aus dem aktuellen Release gestrichen werden.
Die Priorisierung wird dann im Sprint Backlog oder im kurzfristigen Bucket abgebildet und das Team fährt mit der Abarbeitung fort.

Idealerweise haben die Projektbeteiligten bereits im Vorfeld den vereinbarten Lieferumfang im Blick, sodass es in der Praxis nicht zu einer Software Triage kommt.

Impuls zum Diskutieren:

Welche Herausforderungen entstehen in Scrumban durch das Fehlen fester Rollen wie dem Scrum Master?

Hinweise:

[1] Scrumban: Essays on Kanban Systems for Lean Software Development

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads und Empfehlungen.

Hier finden Sie ergänzende Informationen aus dem t2informatik Blog:

Das ist doch kein Scrum

Stolpersteine bei der Kanban-Einführung

Scrumban in der Softwarewartung

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.