Verschachtelte Sprints

Bild: Pixabay / Hannah Alkadi - Lizenz

Im Kosmos der agilen Frameworks gibt es Begriffe die niemand kennt, hinter denen sich aber Phänomene verbergen die in vielen Teams so alltäglich sind, dass es niemandem auffällt, dass sie keinen bekannten Namen haben. Verschachtelte Sprints (auf Englisch "nested Sprints") gehört in diese Kategorie. Kaum jemand nennt sie so, dort wo Scrum oder andere iterative Ansätze angewandt werden sind sie aber durchaus häufig anzutreffen.

Konkret verbergen sich dahinter mehrere aufeinanderfolgende Sprints deren Länge genau einem grösseren Zeitraum (der auch Sprint heissen kann, aber nicht muss) entspricht. Diese Anordnung - ein Objekt das mehrere andere Objekte enthält - entspricht genau der üblichen Definition von Verschachtelung. Die Benennung passt also. Nur - warum macht man so etwas? Die naheliegende Antwort: um die Arbeit von Scrum-Teams in grössere Planungs- und Lieferzyklen zu integrieren oder um Synchronisierungen zu erleichtern.

Häufig anzutreffen ist in diesem Zusammenhang ein "Einschachteln" in einen klassischen Planungszyklus, z.B. einem Quartals-, Halbjahres- oder Jahresplan. In einer klassisch aufgestellten umgebenden Organisation kann das ein einfacher erster Schritt in Richtung Agilität sein, da es die bestehenden Budgetierungs- und Planungsprozesse noch nicht angreift und so Konflikte vermeidet. Es besteht aber das Risiko, dass Sprints dadurch bewusst oder unbewusst lange im Voraus verplant werden, wodurch die eigentlich gewünschte Flexibilität verlorengeht.

Eine ebenfalls häufige Hybridform zwischen agilem und klassischem Vorgehen liegt vor, wenn mehrere Sprints der Dauer zwischen zwei Meilensteinen eines klassisch arbeitenden Teams entsprechen. Das macht vor allem Sinn wenn dieses andere Team zwar eine langfristige Grobplanung, dafür aber einen kürzeren Ausdetaillierungs-Rhythmus hat (eine so genannte Rolling Wave-Planung). Auch bei starrer geplanten Meilensteinen ist eine Synchronisierung mit Sprints möglich, dann aber erneut mit dem Risiko Flexibilität einzubüssen.

Selbst wenn verschachtelte Sprints vor allem in Hybrid-Kontexten häufig sind gibt es sie auch dort wo nur (mehr oder weniger) agile Teams zusammenarbeiten. Am bekanntesten dürften dabei die so genannten "Program Increments" im Scaled Agile Framework (SAFe) sein, die in der Regel vier bis fünf Sprints umfassen, ein anderes Beispiel sind die "light-weight, risk-based milestones" aus dem zum PMI gehörenden Disciplined Agile.

Zuletzt können mehrere Scrum Teams ihre Sprints ineinander verschachteln, etwa wenn ein Teil von ihnen Sprintlängen von einer Woche hat und ein anderer Teil von zwei Wochen. Ein Szenario in dem eine derartige Synchronisierung Sinn macht wäre zum Beispiel eines in dem gemeinsame Sprint Reviews stattfinden um die Kalender der Stakeholder zu entlasten. Ein anderes wäre gegeben wenn Nutzer einer Software um eine Zusammenlegung der Produktions-Releases am Sprintende bitten, um sich nur ein- oder zweimal pro Monat auf ein neues System-Verhalten einstellen zu müssen.

Zusammengefasst: es gibt viele gute, halbwegs gute oder schlechte Gründe dafür verschachtelte Sprints einzusetzen. Da nicht immer klar ist mit was man es zu tun hat (und da sich die Bewertung auch ändern kann) ist es sinnvoll ein regelmässiges Inspect & Adapt durchzuführen. Zum Glück ist das in derartigen Konstellationen leicht - gleichzeitig endende Sprints sind gute Anlässe für gemeinsame Retrospektiven.