Der geschützte Sprint wird von vielen Entwicklungsteams sehr ernst genommen. Dieses Mittel ermöglicht es den Teams, fokussiert an ihren Themen zu arbeiten. Diese Aussage kann doch nur positiv gesehen werden oder ist dieses Vorgehen gar nicht agil und in Wirklichkeit ein großer moderner Wasserfall?
Was ist ein geschützter Sprint?
Ein Sprint wird meinst als geschützt bezeichnet, wenn die Entwickler in den zwei Wochen unter möglichst wenig Ablenkung leiden und Änderungen nicht vorgenommen werden. Dabei ist das Wort „geschützter Sprint“ im SCRUM Guide nicht einmal enthalten. Da dies allerdings gelebte Praxis ist, beschäftigen wir uns mit diesem Vorgehen.
No changes are made that would endanger the Sprint Goal;
Scope may be clarified and renegotiated with the Product Owner as more is learned.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
https://scrumguides.org/scrum-guide.html
Das erste Prinzip der agilen Softwareentwicklung¹
“Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.”
https://agilemanifesto.org/iso/de/principles.html
In diesem Prinzip wird das “Der Kunde ist König”-Prinzip beschrieben. Dies und nicht “Der Entwickler ist Happy” – Sicherlich soll der Entwickler happy sein, um erfolgreich seiner Arbeit nachzugehen. Allerdings sollten späte Änderungen des Scopes problemlos möglich sein, wenn dies den Kunden zufrieden stellt.
Dies wird folgerichtig auch im zweiten Prinzip beschrieben:
“Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.”
¹ Prinzip nicht Gebot siehe: https://agilemanifesto.org/iso/de/principles.html
Nun wird in diesem Prinzip von früher Auslieferung gesprochen. Der SCRUM Prozess besagt eine fixe Länge eines Sprints und erst im folgenden wird ausgeliefert. Warum nicht, sofern das Teilergebnis erreicht wurde?
Der geschützte Sprint führt im weiteren auch häufig zu absurden erlebten Szenarien, bei dem die unagilität schnell erkannt werden sollte.
Falsche Anforderungen
Der Hauptgrund, warum Agilität in der Softwareentwicklung so wichtig ist ist die Erkenntnis, dass wir nicht perfekt sind. Sofern perfekte Anforderungen vollständig erstellt werden könnten, wäre es ein Leichtes, ein perfektes Pflichtenheft zu schreiben, welches dann im Wasserfallmodell abgearbeitet wird. Nur das Scheitern drängt dieses Unternehmen in die Agilität.
Auch wenn die Zyklen kleiner sind, kann es dennoch dazu führen, dass nicht alle Anforderungen abgebildet werden.
Nicht mehr benötigte Stories
Die Welt dreht sich weiter und so kann es schnell passieren, dass eine erstellt Story zwischen Planning und Umsetzung nicht mehr benötigt wird. Häufig wird diese Story trotzdem umgesetzt, um die Planung nicht zu verändern. Dies ist verlorenes Kapital!
Eine Möglichkeit ist es, den Sprint abzubrechen, dass ich noch nie erlebt habe. Häufig auch, da die Releasecyclen nicht verändert werden können, was auch nicht sehr agil ist.
Fehlende Akzeptanzkriterien
Häufig werden Details während des Refinement nicht beachtet. Diese fallen dann während der Entwicklung auf. Die SCRUM-Lösung wäre es nun eine neue Story zu schreiben, welche im nächsten Sprint bearbeitet wird. Der Kunde bekommt dieses Feature schon, allerdings ohne dieses “Detail”. Dies führt häufig dazu, dass das Feature nicht vollständig nutzbar ist. Dadurch entsteht kein Mehrwert für den Kunden. Wenn nun unsere höchste Priorität ist, Mehrwert für den Kunden zu schaffen. Wie kann dieses SCRUM Vorgehen agil sein?
Ein besonderes Beispiel aus der Praxis ist die Trennung zwischen Frontend und Backend. In einem meiner Projekte hatten wir den Fall, dass das Frontendteam, in welchem ich war, einen fehlenden REST Endpunkt entdeckte. Anstatt nun umzuplanen, wurde die Story des Endpunktes in den nächsten Spring geschoben. So wurde das Feature mit der höchsten Priorität nicht weiter bearbeitet.
Support
In vielen SCRUM Teams werden Fehlerbehebungen immer erst im nächsten Sprint bearbeitet, da diese nicht eingeplant sind. Diese pauschale Ablehnung ist allerdings auch sehr unagil. Denn woher wissen wir, ob dieses Problem für die Kunden nicht viel größer ist, als alle im Sprint befindlichen Tasks? Daher sollten Supporttickets immer in die Sprints mit aufgenommen werden. Ein gutes Verhalten ist es, Fehler nur dann nicht zu beheben, wenn sich das Kosten/Nutzenverhältnis NIE lohnt. Dann sollte auch kommuniziert werden, dass dies nicht behoben wird. Dadurch entsteht eine bessere Software und fehlerlose Software erhöht die Geschwindigkeit, neue Funktionen zu erstellen.
Messungen
Wenn wir nun regelmäßig umplanen und alle Supporttickets beheben, wie können wir nun gesetzte Ziele erreichen? Wir von der Biga Software sind große Fans vom Sprinten, denn dieses Format eignet sich hervorragend kleine Meilensteine und Ziele zu setzen.
Um diese Ziele zu erreichen, ist es gut zu messen. Mit diesen Messungen können wir voraussehen, wie viele Supporttickets pro Sprint gemeldet werden und können so einen Durchschnitt ermitteln. Natürlich kann es da Abweichungen geben, aber die Abweichung zwischen erfolgreichen und nicht erfolgreichen Sprints sollte nicht größer sein als mit traditionellen Schätzungen.
