Scrumban

Scrumban ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde in der Softwaretechnik entwickelt, ist aber davon unabhängig. Der Name Scrumban leitet sich daraus ab, dass Elemente aus Scrum mit denen aus Kanban kombiniert werden.

Geschichte

Der Begriff Scrumban wurde von dem US-amerikanischen Unternehmensberater und ehemaligen Microsoft-Software-Entwicklungsmanager Corey Ladas geprägt. Laut ihm ist Scrumban ein Abkömmling eines Konzepts von Microsoft, das feature crews benennt,^[1] und entstand ab dem Jahr 2005. Der Anstoß zur Entwicklung von Scrumban sei die Unzufriedenheit Ladas’ mit dem Scrum-Vorgehen gewesen. Er schlug eine Modernisierung vor, bei der die Scrum-Rollen mit einem verkleinerten Feature-Crew-Planungsmodell kombiniert werden.^[2]

Die Methode

Grundlagen

Das Team organisiert seine Arbeit bei Scrumban in kleinen Iterationen. Den Arbeitsfortschritt überwacht es dabei mittels einer visuellen Plantafel (Planning Board), ähnlich einem Scrum- und Kanban-Board. Zur Veranschaulichung der einzelnen Arbeitsschritte setzt man entweder eine physische Tafel oder eine virtuelle Tafel einer Softwarelösung ein. Auf dem Board befinden sich die Aufgaben (User Stories), die bearbeitet werden sollen, als einzelne Karten. Auf den Karten steht eine Zusammenfassung der Aufgabe. Während der Planung legt das Team fest, welche Aufgaben in der nächsten Iteration bearbeitet werden sollen. Danach kommen sämtliche Aufgaben auf das Board. Das Team arbeitet diese schrittweise ab, wobei so wenig Aufgaben wie möglich auf einmal bearbeitet werden sollen. Um die Iterationen kurz zu halten, verwendet das Team WIP-Limits (WIP: Work in Progress). Zudem setzt das Team Planungs-Trigger ein, um zu wissen, wann die nächste Planung ansteht. Das ist immer dann der Fall, wenn der WIP unter ein bestimmtes Niveau fällt. In Scrumban gibt es keine vordefinierten Rollen; das Team behält die Rollen, die es bereits hat.^[3]

Iterationen

Die Iterationen in Scrumban sind kurz gehalten. Dadurch soll sichergestellt werden, dass ein Team seine Vorgehensweise leicht an sich schnell verändernde Anforderungen anpassen und ändern kann. Die Länge der Iteration wird in Wochen gemessen. Die ideale Länge einer Iteration hängt vom Arbeitsprozess des jeweiligen Teams ab. Es wird empfohlen, dass Iterationen nicht länger als zwei Wochen dauern.^[4] Die Velocity (ein Maß für die Produktivität) wird häufig vom Team verwendet, um Probleme und Trends in seinem Durchsatz zu bewerten, um eine kontinuierliche Verbesserung zu unterstützen.

Planung auf Abruf

Die Planung in Scrumban basiert auf dem Bedarf des Projekts. Sie wird nur dann ausgelöst, wenn die verbleibenden Aufgaben im „To Do“-Bereich der Plantafel auf eine bestimmte Anzahl sinkt. Die Anzahl der Aufgaben, die ein solches Planungsereignis auslösen, ist nicht vordefiniert. Sie hängt von der Geschwindigkeit eines Teams ab und von der Zeit, die für die Planung der nächsten Iteration benötigt wird. Die für die nächste Iteration geplanten Aufgaben werden dem Abschnitt „To Do“ der Plantafel hinzugefügt.

Priorisierung

Es wird empfohlen, die Aufgaben während des Planungsvorgangs zu priorisieren. Das bedeutet, dass die Aufgaben der Tafel mit markierten Prioritäten hinzugefügt werden. Dies hilft den Teammitgliedern zu wissen, welche Aufgaben zuerst erledigt werden sollten und welche später erledigt werden können. Die Priorisierung kann durch das Hinzufügen von Zahlen zu den Aufgaben oder durch das Hinzufügen einer zusätzlichen Prioritätsspalte erfolgen, in der die wichtigsten Aufgaben oben und die weniger wichtigen Aufgaben unten stehen.

Bucket-Size-Planung

Die Planung der Größe von sogenannten Buckets (Eimern) hat den Sinn, eine langfristige Planung zu erreichen. Sie basiert auf einem System von drei Buckets, die die Arbeitsaufgaben durchlaufen müssen, bevor sie auf der Scrumban-Tafel erscheinen. Die drei Buckets repräsentieren drei verschiedene Phasen des Plans und werden üblicherweise als 1-Jahres-, 6-Monats- und 3-Monats-Buckets bezeichnet. Der 1-Jahres-Bereich ist für langfristige Ziele des Unternehmens vorgesehen, z. B. die Erschließung eines neuen Marktes, die Einführung eines neuen Produkts usw. Wenn das Unternehmen beschließt, mit einem Plan voranzukommen, wird er in den 6-Monats-Bereich verschoben, in dem sich die wichtigsten Anforderungen dieses Plans herauskristallisieren. Wenn ein Unternehmen bereit ist, mit der Umsetzung des Plans zu beginnen, werden die Anforderungen in den 3-Monats-Eimer verschoben und in klare Aufgaben unterteilt, die vom Projektteam zu erledigen sind. Aus diesem Eimer zieht das Team während seiner Bedarfsplanungssitzung Aufgaben und beginnt mit der Arbeit an den Aufgaben.^[5]

Das Scrumban-Board

Das Scrumban-Board stellt den Fortschritt des Teams auf einer Tafel visuell dar. Die einfachste Planungstafel hat lediglich drei Spalten: „Zu erledigen“ (To Do), „In Arbeit“ (Doing) und „Erledigt“ (Done). Wenn ein Teammitglied bereit ist, eine Aufgabe zu übernehmen, verschiebt es sie von der Spalte „Zu erledigen“ in die Spalte „In Arbeit“. Wenn es die Aufgabe abgeschlossen hat, verschiebt es sie von der Spalte „In Arbeit“ in die Spalte „Erledigt“. Als zusätzliche Spalten der Aufgabentafel sind „Entwurf“, „Fertigung“ oder „Prüfung“ üblich.

WIP-Limits – Um sicherzustellen, dass das Team effektiv arbeitet, sieht die Scrumban-Methodik vor, dass ein Teammitglied nicht mehr als eine Aufgabe gleichzeitig bearbeiten sollte. Um sicherzustellen, dass diese Regel eingehalten wird, verwendet Scrumban eine WIP-Grenze (WIP: Work in Progress). Dieses Limit wird oben auf dem In-Arbeit-Abschnitt des Boards angezeigt (es kann auch auf jeder Spalte dieses Abschnitts stehen) und bedeutet, dass nur diese Anzahl von Aufgaben gleichzeitig in der entsprechenden Spalte sein darf. Ein WIP-Limit entspricht in der Regel der Anzahl der Personen im Team, kann aber je nach den Besonderheiten der Arbeit des Teams erweitert werden.

To-Do-Limits – Um produktivere Planungsbesprechungen zu ermöglichen, kann die Anzahl der Aufgaben im To-Do-Bereich ebenfalls begrenzt werden. Wie bei den WIP-Limits wird die Anzahl der Aufgaben im To-Do-Bereich oder in den entsprechenden Spalten oben angegeben.

Das Team

Scrumban schreibt keine bestimmte Anzahl von Teammitgliedern oder Teamrollen vor. Die Rollen, die ein Team vor der Einführung von Scrumban hatte, werden bei der Umsetzung von Scrumban beibehalten. Sie werden dadurch verstärkt, dass die Teammitglieder die zu erledigenden Aufgaben selbst wählen müssen. Die Teamrollen in Scrumban sind spezialisierter und weniger funktionsübergreifend als in Scrum-Teams erwartet.

Pull-Prinzip

In Scrumban werden die Aufgaben den Teammitgliedern nicht vom Teamleiter oder Projektmanager zugewiesen. Stattdessen wählt jedes Teammitglied aus, welche Aufgabe aus dem To-Do-Bereich es als nächstes erledigen möchte.

Einfrieren von Funktionen

Das Einfrieren von Features (Feature Freeze) wird in Scrumban verwendet, wenn sich das Projektende nähert. Das bedeutet, dass nur noch an den Features gearbeitet werden kann, die das Team bereits in der Entwicklung hat, und keine zusätzlichen Features mehr hinzugefügt werden können.^[6]

Triage

Die Triage erfolgt in der Regel direkt nach dem Feature Freeze. Angesichts des nahenden Projekttermins entscheidet der Projektleiter, welche der in der Entwicklung befindlichen Funktionen fertiggestellt werden und welche unvollendet bleiben. Dadurch wird gewährleistet, dass sich das Team auf die Fertigstellung wichtiger Funktionen vor dem Projekttermin konzentrieren und die weniger wichtigen vergessen kann.^[7]

Begriffe

• Bucket-Size-Planung langfristiger Planungsansatz in Scrumban, der darauf basiert, dass die Pläne in wenigen Schritten durchlaufen werden.
• Vorlauf- und Zykluszeit die Zeit, die von der Erstellung einer Aufgabe oder dem Beginn der Arbeit an einer Aufgabe bis zu ihrer Fertigstellung vergeht. Wird auch in Kanban verwendet.
• On-Demand-Planung Planungstechnik, die nur dann ausgeführt wird, wenn ein Bedarf an neuen Aufgaben auf der Tafel besteht.

Werkzeuge

Die einfachste Scrumban-Einrichtung ist ein physisches Board mit Haftnotizen. Es gibt auch Softwarelösungen, die den Boards von Scrum und Kanban ähneln. Sie bieten eine vollständige Automatisierung des Boards, das von den Teammitgliedern aktualisiert werden muss. Elektronische Boards bieten oft auch automatische Berichte, die Möglichkeit von Anhängen und Diskussionen über Aufgaben, Zeiterfassung sowie Integrationen in andere gängige Projektmanagement-Software^[8].

Siehe auch

• Scrum
• Kanban (Entwicklung)

Literatur

• Corey Ladas: Scrumban – Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press, Seattle 2008, ISBN 978-0-578-00214-9. 

Weblinks

• Ajay Reddy: What Is Scrumban and Why Should I Care? InformIT (Pearson Education), 9. September 2015, abgerufen am 21. Januar 2022. 

Einzelnachweise

1. ↑ Building productive teams. Microsoft, 28. November 2022, abgerufen am 21. Januar 2023. 
2. ↑ Corey Ladas: The Meaning of Scrumban. Agile Alliance, abgerufen am 19. Januar 2023 (englisch). 
3. ↑ Vidas Vasiliauskas (Eylean webinars): Scrumban - mixing agile and lean auf YouTube, 23. Oktober 2014, abgerufen am 19. Januar 2023 (englisch; Laufzeit: 46:37).
4. ↑ Don Wells: Iterative Planning. In: agile-process.org. 2009, abgerufen am 19. Januar 2023 (englisch). 
5. ↑ Dovilė Misevičiūtė: Scrumban: on demand vs. long-term planning. In: Eylean Blog. 18. November 2014, archiviert vom Original (nicht mehr online verfügbar) am 21. November 2014; abgerufen am 19. Januar 2023 (englisch). 
6. ↑ FeatureFreeze. OpenStack, archiviert vom Original (nicht mehr online verfügbar) am 4. März 2016; abgerufen am 19. Januar 2023. 
7. ↑ Software Triage. In: stickyminds.com. 11. Januar 2008, abgerufen am 19. Januar 2023. 
8. ↑ Eylean for Scrum teams – Scrum-ban. 22. Dezember 2014, archiviert vom Original (nicht mehr online verfügbar) am 9. November 2015; abgerufen am 22. Dezember 2014 (englisch).