Hardening Sprints - Scrum Anti-Patterns oder Notwendigkeit

Handelt es sich bei Hardening Sprints um eine Art Scrum Anti-Patterns oder stellt es möglicherweise eine Notwendigkeit dar? Wie kann diese Iteration eventuell vermieden oder zumindest weniger anspruchsvoll gestaltet werden? Da sich die Arbeitswelt mittlerweile so sehr in Richtung Agil und Scrum verändert hat, ist es nicht schwer, Meinungen zu dem Thema einzufangen. Die einen sagen, dass Hardening Sprints notwendig sind – Andere sehen sie eher als zu kostspielig an. Auf Techtarget hat sich Jim Brown von der Universität in Boston dazu Gedanken gemacht. Im Folgenden fassen wir seinen Artikel für Sie zusammen.
Hardening Sprints - Eine Person tippt auf einem Laptop. Vierecke mit der Aufschrift Work Item schweben in der Luft.
Zunächst einmal sollte der Begriff klar sein. Seit einem Jahrzehnt ist von „Hardening Sprints“ die Rede. Viele Anhänger des Scaled Agile Frameworks befürworten das Konzept. Sie sehen im Sprint Hardening und seinem konzeptionellen Begleiter – dem Stabilisierungssprint – ein Scrum Anti-Patterns, weil diese Praxis dem Wesen von Scrum eigentlich entgegensteht. Gleichzeitig verfechten sie das agile Manifest und den Scrum Guide in sehr wortgetreuer Form. Sprint Hardening ist im Grunde ein Ansatz, der sich vor allem in Unternehmen findet, in welchen die Fehlerbehebung bis ganz ans Ende des Projekts verschoben wird. Der Vorteil, den die Befürworter darin sehen, ist, dass die Teams ihre Sprints abschließen und zum jeweils nächsten Sprint übergehen können, weil sie ja genau wissen, dass am Ende des Projekts noch ein Hardening Sprint stattfindet, so dass sie am Ende zu jedem Punkt im Projekt wieder zurückkehren können. Erst dann werden Regressions-Integrationen, Tests von Drittanbietern und End-to-End-Tests durchgeführt.
Daher sehen einige diese Hardening Sprints als Arbeit an, die einfach verschoben wird, aber selbst keine Wertsteigerung bietet.

Woher kommt Sprint Hardening?

Wie sind diese Hardening Sprints entstanden? Sie sind in vielen größeren Unternehmen der IT-Branche üblich, in denen ein Scaled Agile Framework eingeführt wurde, in dem ein Team aus acht bis zehn Personen gleichzeitig arbeitet. In jedem der Sprints, die teils parallel laufen, wird ein Stückchen Funktionalität erarbeitet – solange, bis das System für eine Härtung bereit ist oder bis die Entwickler vor einer Veröffentlichung noch eine Stabilisierung brauchen. 
In den früheren agilen Konzepten waren sogenannt HIP Sprints immer am Ende eines Projekts fest eingeplant. Erst seit SAFe 5.1 wird die Notwendigkeit solcher HIP Sprints nicht mehr gesehen. Grund dafür waren DevOps und kontinuierliche Entwicklungsansätze. Heute sehen Scaled Agile Framework keine solchen Sprints mehr vor, aber es gibt dennoch ähnliche Konzepte. Im Large Scale Scrum gibt es Sprints, die Produkte liefern sollen, welche potenziell auslieferbar sind, also dem Done entsprechen. In der Methode des DA, des Disciplined Agile, wird es den Teams überlassen, die am besten geeignete Methodik zu finden - hier sind die Hardening Sprints explizit nicht ausgeschlossen. Die dynamische Systementwicklungsmethode DSDM ist eine eher projektorientierte Technik mit schneller Anwendungsentwicklung, die erst bei Bekanntwerden eines festen Projekttermins entscheidet, was in das Produkt aufgenommen werden soll und was nicht. Auch Nexus kann hier genannt werden. Hier wird ein Integrationsteam über mehrere Scrum Teams gespannt. Dieses stellt sicher, dass die Integration während der Sprints schon erfolgt, statt in einem Hardening Sprint, der aber durchaus als Option offensteht.

Wann ist „Done“?

Die genaue Definition von Done ist von großer Bedeutung. Wann ein Sprint fertig ist, hängt meist eng damit zusammen, wie viel Restarbeit noch verbleibt. Diese bleibt für den Hardening Sprint übrig. Wer im Team mit einer Story Card arbeitet, erklärt gerne mal einen Sprint für fertig, auch wenn klar ist, dass geringfügige Fehler in der Produktion auftauchen und behandelt werden müssen. Es gibt aber auch deutlich strengere Definitionen von Done, wenn zum Beispiel alle Anforderungen einer Story Card vollends umgesetzt und auch schon getestet wurden. Im Grunde arbeiten aber alle Teams daran, einen Sprint mit möglichst wenig Restrisiko und Restarbeit zu erledigen. Das hält den Backlog schlank und reduziert die Erfordernis einen Hardening Sprint durchführen zu müssen.

Aufgeschoben ist nicht aufgehoben

Ein Team, das mehr Restarbeit ansammelt, braucht am Ende mehr Zeit, bis das Projekt tatsächlich abgeschlossen ist. Ein Problem bei Hardening Sprints ist, dass sich alle, die an der Fehlerbehebung am Ende arbeiten, auch erst wieder in die Problematik eindenken müssen. Oft wird also für die Fehlerbehebung während eines Hardening Sprints mehr Zeit benötigt als es bei der sofortigen Behebung desselben Fehlers der Fall wäre. Diese technischen Schulden fordern also einen Zins. Große Teams haben oft Spielraum für eine lockerere Definition von Done. Kleine Teams haben diese Möglichkeit selten. Und das ist ja auch der Sinn von Scrum: sich im eigentlichen Sprint mit einem Thema befassen und so fertig wie möglich zu werden.

Hardening Sprints vermeiden

Wie vermeidet man also Hardening Sprints am Ende eines Projekts? Eine Idee ist es, User Stories zu reduzieren, indem eine Anforderung mit mehreren Szenarien und Bedingungen heruntergebrochen wird. Erstellen Sie ein minimal lebensfähiges Produkt, statt alle Anforderungen halb zu erfüllen und für später aufzuheben. Priorisieren Sie gegebenenfalls. Lassen Sie Sonderfälle nach Möglichkeit außer Acht. 
Kurz: Gestalten Sie Sprints so, dass ihre Anforderungen erfüllbar sind, sodass am Ende ein Produkt entsteht, das von der QS getestet werden kann. Alles weitere kommt in der nächsten Iteration. Ein weiterer Ansatz ist die Spillover-Arbeit. Wenn ein Team feststellt, dass es unmöglich ist, im aktuellen Sprint die Anforderungen zu erfüllen, kann die Arbeit auf diesen und den kommenden Sprint aufgeteilt werden, um nicht kritische Fehler aus einem Sprint herauszutragen. Auch eine Abarbeitung außerhalb des Zyklus ist eine Möglichkeit. Durch Spillover-Arbeit können Teams entschieden, wie viel Spielraum sie sich lassen und wann eine neue Story in einen Sprint eingebunden wird.

Das Logo der IAPM
Autor: IAPM intern 
Schlagworte: Projektmanagement, Begriff, Tipps, Hardening Sprints

Die IAPM-Zertifizierung

Die Zertifizierung kann über ein reputiertes Onlineprüfverfahren abgelegt werden. Die Kosten richten sich nach dem Bruttoinlandsprodukt Ihres Herkunftslandes.

Aus dem IAPM Blog

Network Official werden

Wollen Sie sich in Ihrem Umfeld für Projektmanagement engagieren und dazu beitragen, Projektmanagement weiterzuentwicklen? Dann werden Sie aktiv als IAPM Network Official oder als Network Official der IAPM Network University. 


Aufgrund besserer Lesbarkeit nennen wir in unseren Texten meist nur die generische männliche Form. Nichtsdestotrotz beziehen sich die Ausdrucksformen auf Angehörige aller Geschlechter.