Eine der hitzig diskutierten Aspekte des SAFe (Scaled Agile Framework) sind die speziaisierten HIP Sprints. HIP steht hier für Hardening, Innovation und Planning. In früheren Versionen von SAFe wurde diese noch also Hardening Sprints bezeichnet.
In Scrum-Implementierungen betrachten wir die Notwendigkeit einer Stabilisierungsphase normalerweise mit einer gehörigen Prise an Misstrauen – fast immer geht diese nämlich mit einer schlechten Codebasis und suboptimalen Entwicklungspraktiken einher. Daher haben diese Hardening-Sprints auch eine recht scharfe Reaktion in der Scrum – Community hervorgerufen (auch von mir).
Jetzt habe ich festgestellt, dass dieser Kritikpunkt sich zumindest relativiert hat – das gilt für mich nicht nur wegen der Umbenennung
- In einer großen Entwicklung muss das einzelne Scrum-Team eine höhere Planungssicherheit garantieren als in einer autonomen Umgebung. Planungssicherheit muss man sich durch einen Puffer erkaufen. Das ist der erste Einsatzzweck für den HIP-Sprint.
- Alle Scrum Teams sind an einer Grobplanung der Kadenz von 3-4 Monaten beteiligt und definieren dabei „objectives“, d.h. Ziele, die sie als erreichbar betrachten und „stretch objectives“, das heißt Dinge, die nur bei optimalen Bedingungen erreicht werden. Die Scrum Teams bereiten sich auf dieses große gemeinsame Planungsmeeting vor, das ist das zweite Ziel des HIP Sprint
- Drittens ist der HIP Sprint der Zeitraum, in dem Experimente, Lernaktivitäten und ähnliches durchgeführt werden – übergreifend: Innovation. Wenn das Team die beiden anderen Aktivitäten erledigt hat, ist dies die eingebaute Belohnung für eine effektive und gut geplante Arbeit.
Wenn man zurück auf das reine Scrum geht, bleibt eines gleich: die Notwendigkeit von Stabilisierungs-Sprints deutet auf Schwächen in den vorigen Sprints hin: das Ergebnis eines Sprints soll Software in auslieferfähiger Qualität sein.
Allerdings werden in Scrum seit jeher ebenfalls spezielle Sprints diskutiert (und zum Teil heftig umstritten):
- Sprint 0 für eine initiale Planung, evtl. auch für eine Kalibirierung der zu erwartenden Velocity
- Von einem Product Owner wird erwartet, dass er die Backlog Items so zusammenstellt, dass sich daraus benennbare Inkremente für die Sprints benennen lassen – wenn man es genau betrachtet sind dies ebenfalls spezialisierte Sprints.
