On Lean and Agility

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.

Bild: Pixabay - Mabel Amber - Lizenz

Zu den Firmen, die in der agilen Community gehypt und als Vorbild gesehen werden, gehört seit einigen Jahren auch Tesla. Dass das so ist, hängt weniger damit zusammen, dass man wirklich weiss wie dort gearbeitet wird, und mehr mit einem bekannten "Methodenbotschafter". Joe Justice hat dort als Agile Coach gearbeitet und erzählt oft von dieser Zeit (zum Beispiel hier). Und die eine Erzählung die zum "agilen Mythos" von Tesla beiträgt ist diese: dort gibt es Teams, deren Sprint nur drei Stunden dauern.

Wie genau das vor sich geht, verrät er mit Verweis auf eine Geheimhaltungsvereinbarung nicht, er betont aber, dass am Ende jedes Sprints ein Increment steht, was durchaus beeindruckend ist. Wenn wir jetzt unterstellen, dass sich dahinter nicht nur eine Fantasie-Geschichte verbirgt, sondern ein echter Erfahrungsbericht, verlockt all das sehr zur Spekulation. Wie kann es Tesla wohl geschafft haben, auf diese unglaublich wirkenden Lieferzyklen zu kommen?

Um mit etwas nicht Unwesentlichem zu beginnen - es ist nicht so, dass alle Teams diese schnelle Taktung haben. Justice berichtet selber, dass es nur einige Teams sind die so organisiert sind, bei anderen dauert es deutlich länger, bis zu drei Monaten.¹ Das relativiert die Geschichte bereits ein bisschen, alleine deshalb weil nicht klar wird, wie die Mengenverhältnisse sind. Würden z.B. nur 10 Prozent der Teams in Dreistunden-Sprints arbeiten wäre das immer noch beachtlich, aber nicht so sehr wie bei 90 Prozent.

Eine zweite wesentliche Rahmenbedingung ist die, dass es sich nicht um Sprints handelt, wie wir sie aus Scrum kennen. Scrum ist für eine bis vier Wochen konzipiert und würde in derartig kurzen Zeiträumen für Meeting-Overhead sorgen, dazu kommt, dass es die zentrale und im Framework zwingend vorgegebene Scrum Master Rolle laut Justice bei Tesla nicht gibt. Dort wird also nicht nach Scrum gearbeitet. Um welche andere Variante von Sprints es sich handelt, bleibt offen, es könnten z.B. auch Endsprints sein.

Eine dritte Information gibt es wieder bei Justice selbst: bei vielen Teams handelt es sich nicht um langfristig stabile Produktteams, sondern um Ad hoc-Teams, die kurzfristig in einem Open Space-artigen Prozess aus den gerade verfügbaren Mitarbeitern zusammengestellt werden. Das bedeutet aber auch, dass diese Teams nicht alle drei Stunden, bzw. jeden Sprint, ein Increment liefern, alleine deshalb nicht, weil sie sich nach jedem Sprint wieder auflösen und ihre Mitglieder ins nächste Ad hoc-Team wechseln.

Mit diesem Wissen im Hinterkopf - möglicherweise ist es am Ende viel banaler als man denkt. Ein Teil der Mitarbeiter arbeitet in tage-, wochen- oder monatelangen Zyklen mehr oder weniger agil, nur der andere Teil findet sich in kurzfristig gebildeten Ad hoc-Teams zusammen, die dann relativ kleine Aufgaben übernehmen (etwa den Austausch eines Maschinen-Bauteils oder das Anpassen eines Formulars auf einer Webseite). Und diese schnellen Klein-Arbeiten nennt man dann "Sprint".

Bild: Pexels / Run4FFWPU - Lizenz

Dass der Ursprung von Scrum sich irgendwo im Dunkel der Geschichte verliert hat zur Folge, dass sich Vieles nicht mehr genau nachvollziehen lässt. Da nicht absehbar war welche Popularität das Framework einmal erreichen würde wurden z.B. Entscheidungen und Entwicklungen nicht dokumentiert, weshalb bei vielen Begriffen nicht mehr genau zu sagen ist warum sie damals gewählt wurden. Zumindest bei einem ist jetzt aber Licht ins Dunkel gekommen - beim Sprint.

Verdanken tun wir das Mike Cohn, einem der ersten Scrum-Pioniere. In der ersten Folge seines Agile Mentors Podcast erzählt er, dass er bereits im Jahr 1994 mit Scrum in Berührung gekommen ist, also noch bevor es 1995 auf der OOPSLA-Konferenz erstmals der Öffentlichkeit vorgestellt wurde. Er hat es damit in seiner frühesten Form erlebt, und in der sah es noch deutlich anders aus als heute. Das betrifft auch die Sprints, deren Ursprung er wie folgt beschreibt:

In den ersten Jahren hatte Scrum (bzw. dessen Vorformen) noch starke Züge von Wasserfall. Anders als heute folgte nicht unmittelbar ein Sprint dem nächsten, stattdessen waren die Sprints lediglich die Umsetzungsphasen im Anschluss an vorgelagerte längere Planungs- und Konzeptionszeiträume. In diesen vorgelagerten Schritten wurde bereits vieles vordefiniert was danach nur noch abzuarbeiten war, und dieses finale Abarbeiten erfolgte möglichst schnell - als Endspurt, oder auf Englisch als Sprint.¹

Im Rahmen der methodischen Weiterentwicklung wurde die vorgelagerte Planung und Konzeption in den 90ern dann nach und nach als eigenständige Phase abgeschafft und in die Sprints integriert, heute findet sie sich dort in den Planning- und Refinement-Meetings wieder. Infolgedessen rückten die Sprints immer näher aneinander, bis zu der heute üblichen Regelung, in der sie nur noch durch eine logische Sekunde voneinander getrennt sind.

Man könnte argumentieren, dass man die Sprints irgendwann in dieser Zeit hätte umbenennen müssen um semantisch korrekt zu bleiben, da sie durch den Wegfall der vorgelagerten Planungsphasen ihren Endspurt-Charakter verloren haben. Andererseits liesse sich sich aber auch der Standpunkt vertreten, dass ein Sprint weiterhin der Umsetzungs-Endspurt nach den vorgelagerten Backlog Refinements ist, die jetzt während oder parallel zu den früheren Sprints stattfinden.

¹Im OOPSLA-Konferenzpapier finden sich diese Planungs- und Umsetzungsphasen noch abgeschwächt als "Pre-Game" und "Game" wieder

Bild: Unsplash / Jason Goldman - Lizenz

Um mit dem Naheliegendsten anzufangen: zuerst stellt sich die Frage warum es keine zu erledigende Arbeit mehr im Sprint gibt. Es ist keineswegs immer so, dass bereits alles erledigt wurde - oft ist zwar noch Arbeit da, die aber durch fehlende Zulieferungen oder ausgefallene Systeme nicht beendet werden kann. Statt neue Arbeit nachzuziehen sollte man sich in solchen Situationen zuerst fragen ob die nötigen Zulieferungen und Reparaturen im Sprint nicht auch selbst erledigt werden können.

Selbst wenn alle Aufgaben im ursprünglichen Sprint Backlog erledigt sind müssen nicht zwangsläufig neue gesucht werden. Stattdessen kann es auch sein, dass zu der bereits erledigten Arbeit sinnvolle Ergänzungen möglich sind. Refactorings des Code können durchgeführt werden, Tests können automatisiert werden, Dokumentationen können vereinheitlicht werden, etc. etc. Das jetzt schon zu tun kann verhindern, dass später "Aufräum-Sprints" nötig werden.

Und noch etwas kann man mit der bereits fertigen Arbeit machen wenn im Sprint noch Zeit übrig ist: sie den Anwendern und Stakeholdern vorführen, deren Feedback einholen und das gegebenenfalls noch im selben Sprint nutzen um die Arbeitsergebnisse noch weiter zu verbessern. Dieser Austausch kann in Scrum auch deutlich vor dem Sprint Review stattfinden, schliesslich steht nirgendwo geschrieben, dass die Neuerungen erst da gezeigt werden dürfen.

Aber unterstellen wir, dass all das nicht möglich (oder bereits erledigt) ist und noch immer Kapazität im Sprint übrig ist. Auch dann ist die oberste Aufgabe im Product Backlog nicht automatisch die Beste. Sie sollte auch im verbleibenden Sprint abschliessbar sein. Ist das nicht der Fall besteht das Risiko, dass sich im nächsten Planning die Prioritäten ändern und dass das halbfertige Ergebnis danach so lange auf Halde liegt bis es veraltet ist und die Arbeit umsonst investiert wurde.

Ein weiterer zu berücksichtigender Fall tritt ein, wenn der Backlog-Eintrag für sich genommen noch keine nutzbare Funktionalität erzeugt.¹ Es mag zwar verlockend erscheinen durch eine frühe Umsetzung "Vorarbeit" für das nächste Sprint-Ziel zu erledigen, zum einen besteht aber auch hier das Risiko, dass es im nächsten Planning zum Umpriorisierungen kommt, zum anderen führt eine solche asynchrone Fertigstellung oft zu nicht gut abgestimmten Ergebnissen und zu höheren Integrationsaufwänden.

Um es auch von der positiven Seite zu betrachten - was kann man denn guten Gewissens in einen Sprint nachziehen? Idealerweise Arbeitspakete deren Umsetzung bereits für sich genommen einen Mehrwert erzeugt und die in der noch verbleibenden Zeit des Sprints vollständig umsetzbar sind. Selbst wenn sie nicht die höchste Priorität im Backlög haben sollten stiften sie einen Mehrwert, gleichzeitig können die in den letzten Absätzen genannten Risiken vermieden werden.

Falls sie alle in der verbleibenden Zeit umsetzbar sind können auch mehrere zusammengehörende Backlog-Einträge in den Sprint gezogen werden, die sich dann durch ein "Zusatz-Sprintziel"² verbinden lassen. Gegebenenfalls ist es zu diesem Zweck auch möglich aus einem für die verbleibende Sprintdauer zu grossen Ziel einen Spike, ein Proof of Concept oder ein MVP herauszulösen, das auch allein für sich genommen von Wert ist.

Was ich auch schon erlebt habe ist, dass sich Teams die ihr Sprintziel vorzeitig erreicht haben aus dem Backlog eine "Carte Blanche" ziehen konnten, mit der sie an allem arbeiten konnten wozu sie sonst nicht gekommen sind, vom Abbau technischer Schulden über die Verbesserung der eigenen Entwicklungstools bis hin zum Erlernen neuer Programmiersprachen. Für viele war das ein zusätzlicher Anreiz um ihre Arbeit möglichst schnell und gut zu erledigen.³

Und ganz zuletzt - vielleicht muss man auch gar keine Arbeit nachziehen und kann stattdessen Überstunden abbauen. Auch das passiert in manchen Teams viel zu selten.

Bild: Pexels / Jonathan Borba - Lizenz

Auf den ersten Blick sieht Scrum wie eine Arbeitsweise aus auf die man sich einfach umstellen kann, der Scrum Guide scheint schliesslich lediglich den Sprint, die drei Rollen, die vier Meetings und die drei Artefakte vorzugeben. Das scheint sich schnell einführen zu lassen. Auf den zweiten Blick wird es allerdings deutlich schwieriger, denn das dritte der drei Artefakte hat es in sich: das Increment ist eine neue, benutzbare Produktversion, und davon muss es mindestens eine pro Sprint geben.

Wer schon einmal in einem komplexen Produktentwicklungs-Umfeld gearbeitet hat wird erkennen welche Herausforderung das bedeuten kann: die initialen Anforderungen müssen so geklärt sein, dass die Arbeit an ihnen sofort beginnen kann, das Team muss crossfunktional genug sein um nicht auf Zulieferungen warten zu müssen und Tests und Deployments müssen automatisiert sein um möglichst schnell stattfinden zu können.

Die wenigsten Teams die bisher in einem eher klassischen Umfeld mit bürokratischem Anforderungs-Management, starker Arbeitsteilung und vielen manuellen Arbeitsschritten gearbeitet haben werden aus dem Stand dazu in der Lage sein, mit dem Effekt, dass aus einem sofort gestarteten Sprint kein auslieferbares Increment entstehen kann (und aus den nächsten vermutlich auch nicht). Frustration und Enttäuschung wären die Folge.

Um es dazu nicht kommen zu lassen ist es wichtig, dass vor dem ersten Sprint die Grundlagen dafür geschaffen werden ihn überhaupt durchführen zu können. Es wird häufig versucht das in einen so genannten Sprint 0 zu packen, was aber nicht immer funktioniert. Gerade in grösseren Organisationen können Wochen und Monate dafür nötig sein, was den Begriff des Sprints völlig konterkarieren und unbrauchbar machen würde.

Zielführender ist es in solchen Fällen überhaupt erstmal die Sprintfähigkeit herzustellen bevor man mit Scrum beginnt. Das kann ein letztes mal in Form eines klassischen Projekts entstehen, es kann aber auch nach einem anderen mehr oder weniger agilen Vorgehen durchgeführt werden. Wichtig ist in jedem Szenario aber ein klares Zielbild: nur wenn nachvollziehbar definiert ist welche Kriterien für eine Sprintfähigkeit zu erfüllen sind ist klar wann diese Vor-Phase vorbei ist.

Ein Sonderfall dieser Situation tritt ein wenn ein bereits nach Scrum arbeitendes Team seine Sprintfähigkeit verliert, zum Beispiel durch Personalabgänge oder ausfallende Infrastruktur. Der Scrum-Begründer Ken Schwaber empfiehlt in diesem Fall (zumindest bei grösseren Vorhaben) so genannte Scrumble-Phasen, in denen die Sprints ausgesetzt werden und stattdessen an der Wiederherstellung der Sprintfähigkeit gearbeitet wird.

Elementar in beiden Varianten ist, dass in ihnen ein möglichst ausschliesslicher Focus darauf liegt an den Voraussetzungen für Scrum zu arbeiten. Wird parallel dazu bereits mit der Arbeit am Produkt begonnen, werden diese fehlenden Voraussetzungen dazu führen, dass sich nicht integrierte Arbeit anstaut oder Vorarbeiten durchgeführt werden die sich später ggf. nicht abschliessen lassen. Beides würde wieder zu den Problemen führen für deren Beseitigung Scrum eigentlich erfunden wurde, es wäre also nicht im Sinne der Idee.

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.