Hardening Sprints

Bild: Pexels / Sternsteiger Stahlwaren - Lizenz

Eine der kontroverseren agilen Praktiken sind die so genannten "Hardening Sprints", in denen keine neuen Funktionalitäten entwickelt werden, sondern in denen stattdessen die noch fehlenden Restarbeiten erledigt werden, die nötig sind um mit Betrieb, Benutzung, Verkauf, o.Ä. beginnen zu können. Warum sie kontrovers ist? Weil sie dem Anspruch zuwiderläuft, nach jedem Sprint durch Erfüllung der Definition of Done "potentially shippable", also direkt gebrauchsfertig zu sein.

Trotz dieser umstrittenen Natur gehören Hardening Sprints zu den ältesten und langlebigsten Scrum-Praktiken. Bereits 2007 wurden sie vom Scrum-Pioneer Mike Cohn (moch unter dem Namen Release Sprint) als ein übliches Vorgehen beschrieben, zu Beginn der 2010er Jahre waren sie Teil von SAFe, (wo aus ihnen später die Innovation and Planning Iteration wurde) und bis heute werden sie von vielen Teams und Unternehmen vor Releases durchgeführt.

Vermutlich geht die kategorische Verteidigung oder Ablehnung von Hardening Sprints aber ohnehin in die falsche Richtung. Statt dogmatisch auf einer dieser Positionen zu verharren könnte man sich fragen, was in einem solchen Sprint stattfinden könnte, selbst wenn das in der vorherigen Zeit entwickelte Produkt nach jedem Sprint potentially shippable gewesen ist (zur Abgrenzung: um Kontexte in denen kontinuierliches potentially shippable nicht möglich ist geht es hier nicht, das ist ein eigenes Thema).

Refactoring

Es kann vorkommen, dass eine Anwendung funktionierend auf Production deployed ist, ohne dass es unter der Motorhaube durchgehend Clean Code, eingehaltene Benennungskonventionen, konsistente Architektur, o.Ä. gibt. Das kann in einem nachgelagerten Sprint nachgeholt werden, um sicherzustellen, dass auch zukünftig alles verstanden und mit geringem Aufwand erweitert werden kann.

Langlaufende Tests

Es ist zugegebermassen ein Edge Case, aber es in manchen Kontexten (z.B. bei kombinierten Hardware-/Software-Produkten) gibt Last- und Regressiontests, die mehrere Tage lang laufen, und damit gegebenfalls sogar länger als ein Sprint dauert. Diese Tests zu Ende zu führen kann sinnvoll und notwendig sein um sicherzustellen, dass wirklich alles funktioniert.

Löschen von Testdaten

Mitunter können sich an erstaunlich vielen Stellen eines Systems noch Testdaten befinden, was ggf. auch unvermeidbar ist, wenn bis zum letzten Tag des letzten richtigen Sprints noch entwickelt und getestet wird. Ein System vor dem Go Live auf derartige Datensätze fiktiver Produkte, Nutzer, etc. zu durchsuchen, bzw. sie mit Probe-Durchläufen sichtbar zu machen, kann eine gute Idee sein.

Aufspielen von Produktionsdaten

Der umgekehrte Fall. Bei vielen der im Echtbetrieb verwendeten Daten ist es wichtig, dass sie so aktuell und genau wie möglich sind, etwa im Fall von Zahlungs- und Auslieferungsbelegen. Dazu kommt, dass ihre Aufspielung auf Entwicklungs- und Testsysteme oft datenschutz- und haftungsrechlich problematisch wäre. Ihre Übertragung kann eine der Entwicklung nachgelagerte Arbeit sein. 

Monitoring (und ggf. Bugfixing)

Auch nach dem Übertragen aller Funktionen und Daten auf die Produktionsumgebung können noch zu erledigende Arbeiten übrigbleiben. Da sich der echte Livebetrieb nie völlig simulieren lässt, beginnt er oft mit einer "Hypercare"-Phase in der durch intensives Monitoring sichergestellt wird, dass nur dort auftretende Bugs schnell gefunden und behoben werden.

Schulung der Service-Mitarbeiter

Ein in vielen Fällen nicht zu unterschätzender Aufwand ist die Schulung der Service-Mitarbeiter, die für die Betreuung der Anwender einer neuen Software zuständig sind. Gerade wenn agil bin in den letzten Sprint Features entwickelt werden, kann sich das Systemverhalten auch bis zum letzten Entwicklungstag ändern, so dass eine Schulung in einer stabilen Phase sinnvoll sein kann.

User Onboarding

Eine ähnliche, und häufig auf den letzten Punkt aufbauende Tätigkeit. Vor allem bei grossflächig firmeninternen Anwendungen kann es notwendig sein, den Anwendern neuer Funktionen die Möglichkeit zu geben, sie auszuprobieren, Fragen zu stellen und Erklärungen zu erhalten. Das kann ggf. bereits im Echtbetrieb stattfinden.

Natürlich ist diese Aufzählung nicht vollständig. Es sind noch viele weitere Tätigkeiten denkbar, die in einem nach dem Ende der Entwicklung stattfindenden Hardening Sprint stattfinden können, ohne dass es sich dabei um Dinge handelt, die bei Einhaltung der Definition of Done früher hätten erledigt werden müssen. Und mit diesem Wissen im Hintergrund sollte es möglich sein, die Diskussion um derartige Sprints sachlich und undogmatisch zu führen.