Scrumban

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]

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.

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.

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.

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]

Ein einfaches Kanban-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.

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.

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.

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]

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]