Scrum zeichnet sich als agiles Vorgehensmodell vor allem durch feste Regeln aus, die möglichst nicht verändert werden sollten. Doch wie praxisnah sind die Regeln tatsächlich? Passt das Modell ohne Änderungen oder Anpassungen auf jedes Team oder wäre es sinnvoll und effizienter, gewisse Veränderungen vorzunehmen?
Das Team an Scrum anpassen oder Scrum an das Team anpassen?
Sowohl im Scrum Guide (Ken Schwaber und Jeff Sutherland) als auch im Buch Scrum: The Art of Doing Twice the Work in Half the Time von Jeff Sutherland wird explizit darauf hingewiesen, dass die Regeln nicht verändert werden dürfen, nur dann sei ein Erfolg durch Scrum gewährleistet. Doch was ist, wenn doch Anpassungen vorgenommen werden? Ist das Projekt dann automatisch zum Scheitern verurteilt? Oder kann es unter Umständen sogar sinnvoll sein, dass sich nicht das Team an Scrum anpasst, sondern Scrum an das Team angepasst wird?
Ausgehend von dieser Fragestellung möchte ich eine Möglichkeit präsentieren, wie Scrum verändert werden könnte. Diese Idee soll Grundlage einer Diskussion sein und dazu anregen, eigene Ideen zu entwickeln. Ich bin sehr auf die Meinung der Leser gespannt und würde mich über Rückmeldung sehr freuen!
Idee: Abschaffung des Sprint Backlogs und des Backlog Groomings, andere Nutzung des Sprint Plannings
Begründung: Langfristige Planungen sind in Scrum nicht notwendig. Kurzfristige Planungen können sich schnell ändern
Abschätzung von Stories bleibt wichtig
Es findet weiterhin eine Abschätzung der User Stories statt, durch den Wegfall des Backlog Groomings allerdings nur noch im Sprint Planning. Die Abschätzung selbst ist sehr wichtig, da eine Auswertung geführt werden kann, wie viele Tage eine User Story (US) oder ein Defect (DE) in Bearbeitung waren. Sofern diese Auswertung einen guten Mittelwert bildet (diese Auswertung kann jederzeit gestartet werden), kann dann mit hoher Wahrscheinlichkeit gesagt werden, wie lange beispielsweise eine Story mit 5 Punkten (Story Points) dauert.
Die Pflege des Product Backlogs findet nur noch im Planning statt. Jeder im Team weiß über die obersten Elemente mit höchster Priorität Bescheid. Es müssen immer so viele Einträge geschätzt und besprochen sein, wie theoretisch in einen Sprint passen würden. Die Kapazität eines Sprints ergibt sich aus den Story Points und dem Mittelwert der letzten drei Sprints (bzw. der geschätzten Anzahl Tage, die dafür benötigt werden).
Das Product Backlog sollte in 3 Kategorien eingeteilt werden:
Begründung: Das Austasken in der Gruppe ist stark von den übergreifenden Fähigkeiten des Teams abhängig und kann im schlimmsten Fall sogar kontraproduktiv sein. Aufgrund unterschiedlicher Kenntnisse und Wissens-Schwerpunkte kann oftmals nicht jeder Mitarbeiter etwas zu den Tasks beitragen, viele Absprachen finden in der Folge dann erst nach dem Planning statt. In vielen Fällen wird die betroffene US alleine ausgetaskt, die der Mitarbeiter später auch selbst bearbeitet.
Die Sprint-Aktivitäten finden wie gewohnt im bisherigen Zyklus statt. Ebenfalls erhalten bleiben die Aufgabengrößen und Anforderungen, z.B. dass eine Story innerhalb eines Sprints zu schaffen sein muss. Für jede Story gilt aber ein individueller Beginn des Sprints ab Startzeitpunkt der Bearbeitung.
Der Hintergrund der Idee ist, dass das dynamische Backlog jederzeit angepasst werden kann. Es ist sichergestellt, dass die obersten und damit wichtigsten Elemente auf jeden Fall erledigt werden. Die starre Struktur eines Sprints wird aufgebrochen, ohne auf die Vorteile der Veranstaltungen zu verzichten. Es wird ein stetiger Strom an Aufgaben in den Sprint geschoben, jedoch ohne Zeitdruck, dass etwas bis zum Sprint-Ende erledigt sein muss. Es findet kein "das muss noch in den Sprint"-Vorgehen statt. Es wird keine "freien" Zeiten zwischen den Sprints oder am Ende eines Sprints mehr geben, die Zeit wird optimal genutzt, da bereits an Aufgaben für den nächsten Sprint (offiziell) begonnen werden kann. Aufgaben werden nicht mehr aufgeschoben sondern können sofort erledigt werden. Auch unvorhergesehene Ereignisse können besser abgefangen werden, da es kein Commitment vor dem Sprint gegeben hat.
Es muss darauf geachtet werden, dass ein Bearbeiter in so wenigen Aufgaben wie möglich involviert ist. Bei einem Blocker, bei dem mit kurzfristiger Erledigung gerechnet werden kann, kann eine andere Aufgabe übernommen werden. Falls dort aber noch Arbeit ansteht, wäre ein Wechsel nicht effizient. Blocker, bei denen keine Lösung ersichtlich ist, können direkt zurück ins Backlog geschoben werden, ohne erst das Ende des Sprints abzuwarten.
Diese Änderungen könnten die folgenden Probleme lösen:
Nachfolgend wird zunächst ein Schaubild dargestellt, dass das klassische Vorgehen nach Scrum abbildet:
Was folgt, ist ein Schaubild der beschriebenen, angepassten Variante von Scrum, bei der das Backlog Grooming fehlt und nur noch das Product Backlog existiert, das in drei Bereiche unterteilt wurde:
Welche Nachteile hätte der Vorschlag, bzw. würden die Vorteile die Nachteile aufwiegen? Oder wird diese oder eine ähnliche Variante bereits von anderen Teams praktiziert? Ich bin auf eure Meinungen gespannt!
Die Pflege des Product Backlogs findet nur noch im Planning statt. Jeder im Team weiß über die obersten Elemente mit höchster Priorität Bescheid. Es müssen immer so viele Einträge geschätzt und besprochen sein, wie theoretisch in einen Sprint passen würden. Die Kapazität eines Sprints ergibt sich aus den Story Points und dem Mittelwert der letzten drei Sprints (bzw. der geschätzten Anzahl Tage, die dafür benötigt werden).
Das Product Backlog sollte in 3 Kategorien eingeteilt werden:
- Typ 1: "Zum Überleben absolut notwendig" (must)
- Typ 2: "Wichtig zum Überleben" (need)
- Typ 3: "Damit wird das Leben einfacher und schöner" (nice)
Begründung: Das Austasken in der Gruppe ist stark von den übergreifenden Fähigkeiten des Teams abhängig und kann im schlimmsten Fall sogar kontraproduktiv sein. Aufgrund unterschiedlicher Kenntnisse und Wissens-Schwerpunkte kann oftmals nicht jeder Mitarbeiter etwas zu den Tasks beitragen, viele Absprachen finden in der Folge dann erst nach dem Planning statt. In vielen Fällen wird die betroffene US alleine ausgetaskt, die der Mitarbeiter später auch selbst bearbeitet.
Stressreduktion durch ein dynamisches Product Backlog
Die Sprint-Aktivitäten finden wie gewohnt im bisherigen Zyklus statt. Ebenfalls erhalten bleiben die Aufgabengrößen und Anforderungen, z.B. dass eine Story innerhalb eines Sprints zu schaffen sein muss. Für jede Story gilt aber ein individueller Beginn des Sprints ab Startzeitpunkt der Bearbeitung.
Der Hintergrund der Idee ist, dass das dynamische Backlog jederzeit angepasst werden kann. Es ist sichergestellt, dass die obersten und damit wichtigsten Elemente auf jeden Fall erledigt werden. Die starre Struktur eines Sprints wird aufgebrochen, ohne auf die Vorteile der Veranstaltungen zu verzichten. Es wird ein stetiger Strom an Aufgaben in den Sprint geschoben, jedoch ohne Zeitdruck, dass etwas bis zum Sprint-Ende erledigt sein muss. Es findet kein "das muss noch in den Sprint"-Vorgehen statt. Es wird keine "freien" Zeiten zwischen den Sprints oder am Ende eines Sprints mehr geben, die Zeit wird optimal genutzt, da bereits an Aufgaben für den nächsten Sprint (offiziell) begonnen werden kann. Aufgaben werden nicht mehr aufgeschoben sondern können sofort erledigt werden. Auch unvorhergesehene Ereignisse können besser abgefangen werden, da es kein Commitment vor dem Sprint gegeben hat.
Es muss darauf geachtet werden, dass ein Bearbeiter in so wenigen Aufgaben wie möglich involviert ist. Bei einem Blocker, bei dem mit kurzfristiger Erledigung gerechnet werden kann, kann eine andere Aufgabe übernommen werden. Falls dort aber noch Arbeit ansteht, wäre ein Wechsel nicht effizient. Blocker, bei denen keine Lösung ersichtlich ist, können direkt zurück ins Backlog geschoben werden, ohne erst das Ende des Sprints abzuwarten.
Vorteile der Anpassung des Vorgehensmodells
Diese Änderungen könnten die folgenden Probleme lösen:
- Stress am Sprintende, noch Aufgaben fertig zu bekommen
- Abschätzung des Sprints ungenau
- Schwere Abschätzung durch verteiltes Team (örtlich oder fachlich)
- Splitten von User Stories am Sprintende
- Behinderung des Sprints durch Blocker
- Kein Austasken möglich, da vorliegende Informationen unzureichend
- Leere Zeit zwischen zwei Sprints
- Sprint Backlog darf nicht geändert werden
- Sprint Backlog wird durch dringende Aufgaben trotzdem geändert
- Backlog Grooming
- Verwaltungsaufwand je nach Scrum-Tool hoch
- Defects, die kurz vor Sprintende bekannt werden, können nicht bearbeitet werden
Schaubilder
Nachfolgend wird zunächst ein Schaubild dargestellt, dass das klassische Vorgehen nach Scrum abbildet:
 |
| Das klassische Vorgehen in Scrum |
Was folgt, ist ein Schaubild der beschriebenen, angepassten Variante von Scrum, bei der das Backlog Grooming fehlt und nur noch das Product Backlog existiert, das in drei Bereiche unterteilt wurde:
 |
| Die angepasste Variante von Scrum |
Welche Nachteile hätte der Vorschlag, bzw. würden die Vorteile die Nachteile aufwiegen? Oder wird diese oder eine ähnliche Variante bereits von anderen Teams praktiziert? Ich bin auf eure Meinungen gespannt!
Keine Kommentare:
Kommentar veröffentlichen