Donnerstag, 23. März 2017

Verbesserung von Scrum: Eine mögliche Variation



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:
  • Typ 1: "Zum Überleben absolut notwendig" (must)
  • Typ 2: "Wichtig zum Überleben" (need)
  • Typ 3: "Damit wird das Leben einfacher und schöner" (nice)
Ein Austasken in der Gruppe während des Sprint Plannings findet nicht mehr statt. Es wird die Selbstorganisation vorausgesetzt und den Mitarbeitern vertraut, dass sich diese vor der Bearbeitung einer neuen User Story oder eines Defects mit einem direkten Kollegen zusammen setzen und gemeinsam austasken. Dabei ist es egal, ob die Person etwas dazu beitragen kann oder nicht.

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 
Zu überlegen gilt, warum Scrum es vorgegeben hat, Änderungen am Sprint nicht zuzulassen. Änderungen gehen oft mit hohen Kosten einher. Für "echtes" Scrum sollten die offiziellen Regeln eingehalten werden. Es muss überlegt werden, welche Nachteile das bedeuten würde. Ist es ohne Probleme möglich, diese Regeln einzuhalten? Wenn ja, warum gibt es trotzdem immer Ausnahmen? Wenn nein, wäre der oben genannte Vorschlag eine mögliche Lösung?

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 posten