On Lean and Agility: Sprints

Posts mit dem Label Sprints werden angezeigt. Alle Posts anzeigen

Montag, 19. Juni 2023

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".

Wie es wirklich ist wird man wohl erst erfahren, wenn Tesla Wissenschaftler oder Journalisten in die Fabriken lässt. Bis dahin werden die Dreistunden-Sprints als Mythos durch die agile Community ziehen und zum Ruf von Tesla beitragen. Und möglicherweise ist das auch genau so gewollt.

¹Je nach Vortrag spricht er manchmal statt Sprints von Projekten. Diese Gleichsetzung wäre nochmal ein Thema für sich.

Montag, 6. Juni 2022

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.

Der Grund für die Nicht-Umbenennung ist aber vermutlich banal: der Begriff der Sprints ist bereits früh so stark mit Scrum assoziiert worden, dass seine Aufgabe die Anwender zu stark irritiert hätte. Und wirklich wichtig scheint der Benennungs-Hintergrund für die Scrum-Gründer Ken Schwaber und Jeff Sutherland auch nicht zu sein, jedenfalls haben sie ihn in keinem ihrer Grundlagenwerke thematisiert. Um so dankbarer kann man Mike Cohn dafür sein, dass er sein "historisches Wissen" geteilt hat.

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

Dienstag, 15. Februar 2022

Bild: Unsplash / Jason Goldman - Lizenz

In der Theorie ist es ganz einfach: wenn einem Scrum Team während des Sprints die Arbeit ausgeht zieht es neue nach, und zwar die jeweils am höchsten priorisierte Aufgabe im Product Backlog. Das macht erstmal intuitiv Sinn, in der Realität kann die Situation aber deutlich vielschichtiger sein, bis zu dem Punkt an dem sich dieses scheinbar naheliegende Vorgehen als eines erweist das man gerade nicht wählen sollte. Schauen wir uns das Ganze mal näher an.

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.

¹Dass in Scrum jeder Backlog-Eintrag zwingend potentiell nutzbare Funktionalität erzeugen müsste ist ein Mythos, das trifft nur auf Sprint-Ziele zu.
²Ggf. mit anderem Namen, da es ja eigentlich nur ein Sprintziel geben soll.
³Nur um es klarzustellen: natürlich sollte man auch unabhängig vom Sprint-Status an diesen Themen arbeiten können.

Montag, 17. Mai 2021

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.

Donnerstag, 21. Januar 2021

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.

Donnerstag, 9. Juli 2020

Bild: Pexels / Bruno Bueno - Lizenz

Das Sprint Backlog ist ein kleines Mysterium. Eigentlich ist es ein so zentraler Teil von Scrum (und ähnlichen Ansätzen), dass jeder der schon einmal mit diesem Framework gearbeitet hat es kennen sollte, andererseits dürfte man aber bei den meisten Teams eher Ratlosigkeit verursachen wenn man danach fragt. Bestenfalls kommt irgendwann die Erkenntnis, dass das die Arbeit ist "die man in den Sprint zieht". Das ist auch nicht falsch, aber auch nicht ganz richtig. Es ist mehr als nur das.

Um mit dem Offensichtlichsten zu beginnen: genau wie im Fall des Product Backlog hat auch das Sprint Backlog im Englischen eine Bedeutung die sich problemlos ins Deutsche übersetzen lässt. Es ist das Backlog des Sprints, also der Rückstau (→ Backlog) unerledigter Arbeit, der während des nächsten Umsetzung-Zeitraums (→ Sprint) abgearbeitet werden muss. Das klingt zunächst banal, hat bei näherer Betrachtung aber Folgen, und zwar sowohl in Bezug auf die Größe als auch in Bezug auf die Darstellung.

Beginnen wir mit der Grösse. Um im nächsten Sprint abgearbeitet werden zu können darf der Rückstau nicht grösser sein als die Arbeitskapazität des Team in dieser Zeit. Auch das klingt banal, hat aber weitreichende Implikationen. Es verhindert, dass Wunschlisten undefinierbarer oder ausufernder Grösse in die Umsetzung gegeben werden und erzwingt eine Reduzierung auf das Wesentliche, da ja am Sprintende ein benutzbares Ergebnis stehen soll. Das gilt zwar theoretisch auch im klassischen Projektmanagement, in dessen grossen Releaseplanungen fällt "die eine zusätzliche Anforderung" aber oft nicht auf. Die maximal vierwöchigen Sprints erzwingen eine wesentlich grössere Disziplin.

Nun zur Darstellung. Selbst wenn Teams den Begriff des Sprint Backlogs kennen verwechseln sie ihn häufig mit der Summe aller Arbeit die im Sprint ist. Auch hier hilft eine Erinnerung an die Übersetzung: der Rückstau (→ Backlog) ist eben nicht "alles auf dem Board" sondern lediglich das was noch unberührt auf seine Erledigung wartet. Vereinfacht gesagt könnte man demnach alles was noch im To Do-Bereich ist als das Backlog bezeichnen, oder noch stärker vereinfacht - das Sprint Backlog ist der linke Teil des Boards.

Zusammengenommen ergibt sich aus diesen beiden Aspekten noch ein dritter, nämlich der der Planbarkeit, bzw. Prognostizierbarkeit. Da von einem Sprint mit fortschreitender Zeit immer weniger Tage übrigbleiben muss zwangsläufig auch das Backlog immer weiter schrumpfen wenn es noch umsetzbar bleiben soll. Das kann entweder dadurch passieren, dass nach und nach immer mehr Arbeit erledigt (und damit aus dem Rückstau/Backlog entfernt) wird, es kann aber auch heissen, dass Aufgaben wieder aus dem Sprint herausgenommen werden müssen¹ um ihn wieder erfolgreich abschliessbar zu machen.

Wer schon einmal in komplexen Entwicklungsprojekten gearbeitet hat dürfte mittlerweile ahnen, dass ein Sprint Backlog durchaus anspruchsvoll zu erstellen ist. Es soll in wenigen Wochen umsetzbar sein, ein brauchbares Ergebnis erzeugen, schrittweise abzuarbeiten sein und eine im Zweifel modifizierbare Grösse haben? Wie soll das gehen? Die kurze Antwort: durch schlankes, flexibles, ergebnisorientiertes und in Kommunikation eingebettetes Formulieren von Anforderungen. Mögliche lange Antworten stehen hier, hier, hier und hier.

¹Bei einer korrekten Umsetzung von Scrum nur so, dass das Sprintziel erreichbar bleibt. Geht das nicht sollte der Sprint abgebrochen werden.

Donnerstag, 18. Juni 2020

Bild: Flickr / A Healthier Michigan - CC BY-SA 2.0

Gerade dann wenn die Bedeutung eines Begriffs für alle Beteiligten scheinbar selbstverständlich ist lohnt sich ein näherer Blick. Das gilt natürlich auch für die Fachsprache die sich über die Jahrzehnte im Rahmen der agilen Arbeitsweisen entwickelt hat. Ein Fall an dem sich das aufzeigen lässt ist der Sprint. Je nach Kontext können sich hinter diesem Wort stark unterschiedliche Ausprägungen verbergen, derer man sich bewusst sein sollte wenn man es benutzt.

Die in der Realität am häufigsten anzutreffende Variante lässt sich am besten als "Endspurt" beschreiben. Nach längeren Anforderungserhebungs- und Planungsprozessen geht es hier nur noch darum das definierte Ergebnis in kurzen Schüben umzusetzen (häufig anzutreffen in SAFe). Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse relativ klar und stabil sind, die Umsetzung aber technisch oder organisatorisch anspruchsvoll ist. Der Inspect & Adapt-Zyklus dient dann nur noch der Überprüfung und Anpassung des Umsetzungsvorgehens. Das mit diesem Ansatz verbundene Risiko ist, dass er entgleisen kann wenn die Anforderungen sich ändern.

Auch der umgekehrte Fall existiert, es sind die so genannten "Design Sprints". In ihrer bekanntesten Variante enthalten sie nicht nur das blosse Anforderungsdesign sondern auch die Erstellung erster Prototypen oder Vorführ-Versionen und deren Validierung an einer echten Anwender-Zielgruppe. Sobald diese positiv reagiert erfolgt die Übergabe an die eigentliche Umsetzung. Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse noch unklar oder instabil sind. Der Inspect & Adapt-Zyklus dient vor allem dem Erstellen und Verwerfen von Bedarfs- oder Anwendungs-Hypothesen. Das mit diesem Ansatz verbundene Risiko ist, dass seine Ergebnisse sich als nur schwer umsetzbar herausstellen können.

Der dritte Typ entspricht den Sprints in Scrum oder den Iterationen in Extreme Programming. Der Anspruch dieses Ansatzes ist, auf der Basis einfach formulierter Anwender-Bedürfnisse sowohl das Design als auch die Umsetzung einer Funktionserweiterung in einem (!) Intervall umzusetzen. Sinn macht dieses Vorgehen wenn sowohl die Anforderungen und Nutzerbedürfnisse als auch die Bedingungen der Umsetzung sich ändern können. Der Inspect & Adapt-Zyklus sollte alle dieser Aspekte berücksichtigen. Das mit diesem Ansatz verbundene Risiko ist, dass er bei vielen Abhängigkeiten und hohem Abstimmungsbedarf unverhältnismässig viele Ressourcen für diese Themen verwendet.¹

Was anhand dieser verschiedenen Ausprägungen erkennbar ist: abhängig von Verständnis und Erfordernissen kann sich jeweils etwas Unterschiedliches hinter dem scheinbar klaren Begriffs des Sprints verbergen (dazu kämen noch Antipattern wie z.B. der Konzeptions-Sprint", der "Test-Sprint" oder der "Gewaltmarsch"), es macht also grossen Sinn sich zu vergewissern welches im eigenen Fall vorliegt.

¹Der übliche Lösungsansatz im agilen Vorgehen wäre die Vermeidung oder Auflösung von Abhängigkeiten, z.B. durch crossfunktionale Teams oder shared Code.

Montag, 23. Dezember 2019

Bild: Pixabay / destressguy - Lizenz

Die Vorweihnachtszeit ist voller Traditionen die jedes Jahr wieder aufleben. Die Städte hängen voller Leuchtdekorationen, auf Weihnachtsmärkten wird Glühwein ausgeschenkt, im Fernsehprogramm laufen Der kleine Lord und Stirb langsam und in den Scrum Teams rund um die Welt wird kontrovers diskutiert wie der nächste Sprintwechsel aussehen soll.

Der Hintergrund ist einfach: je nach Sprint-Länge und -Rhytmus wird dieser Sprintwechsel entweder in die Weihnachtsfeiertage oder in die Zeit zwischen Weihnachten und Neujahr fallen, in der fast alle Menschen sich im Urlaub befinden. Dass ein geordnetes Durchführen aller Arbeiten und Meetings damit schwer bis unmöglich wird ist klar, aber was soll stattdessen gemacht werden?

Natürlich gibt es darauf mehrere mögliche Antworten. Einige wenige Teams rechnen die Feiertage aus der Sprintlänge heraus, was zwar effektiv ist aber den Kalenderrhytmus durcheinanderbringt. Andere lassen einen Sprint ausfallen und überlassen es den wenigen Kollegen die nicht im Urlaub sind ihre Zeit selbst zu verplanen. Manche ziehen die üblichen Intervalle durch, zur Not mit reduzierter Mannstärke. Die meisten machen aber einen Weihnachts-Sprint mit angepasster Länge.

In der Anwendung sieht das so aus, dass die üblichen Wochentage des Sprintwechsels beibehalten werden, allerdings nicht in den üblichen Abständen zueinander sondern in Relation zu den Feiertagen. Bei einem Mittwochs-Sprintwechsel würde das bedeuten, dass der Weihnachtssprint am letzten Mittwoch vor dem 24.12. beginnt und am ersten Mittwoch nach dem 01.01. endet.

Je nach Jahr würde ein solcher Sondersprint unterschiedlich lang dauern, etwa 2018/19 zwei Wochen oder 2019/20 drei Wochen. Abhängig von der normalen Sprintlänge (möglich sind 1 bis 4 Wochen) kann eine solche Abweichung einen deutlich kürzeren oder längeren Sprint ergeben als üblich, und aufgrund der Gruppierung um die Feiertage auch den davorliegenden Sprint spürbar verkürzen.

Dort wo eine Velocity berechnet wird macht es Sinn diese Sprints aus der Berechnung herauszunehmen, da diese sonst ihre Aussagekraft verlieren würde. Zum einen wegen des von der Norm abweichenden Verhältnisses von Dauer und Durchsatz, zum anderen aber auch weil aufgrund der Urlaube die Crossfunktionalität nicht durchgehend gewährleistet werden kann, was natürlich Auswirkungen auf die Leistungsfähigkeit hat.

Eine Tradition der besonderen Art kommt in manchen Unternehmen noch dazu: als Entschädigung für die Mitarbeiter die im Büro den Betrieb aufrechthalten währen die Kollegen sich auf den Pisten und Stränden befinden wird ihnen ermöglicht selbst zu entscheiden woran sie in dieser Zeit arbeiten wollen. In gewisser Weise ist auch das ein Weihnachtsgeschenk.

Donnerstag, 13. Juni 2019

Es geht doch nichts über eine Erklärung komplexer Sachverhalte anhand von abseitigen Beispielen.

Montag, 8. Oktober 2018

Bild: Pixabay / Magic Desk - Lizenz

Es ist eine traurige Geschichte die ich schon von vielen Scrum Teams gehört habe: der Sprint ist beendet, alle Anforderungen sind umgesetzt, alles ist in einem präsentationsfähigen Zustand - aber kein einziger Stakeholder erscheint zum Review Meeting. Nach zwei Wochen Arbeit ist das frustrierend, aber es geschieht selten ohne Grund. Folgende Ursachen habe ich bereits bei verschiedenen Teams erleben dürfen:

Es gibt keine Stakeholder

So einfach ist es manchmal. Wenn z.B. die aktuellen Entwicklungsziele die Kopfgeburt eines einzelnen Topmanagers sind, die dieser gegen den Willen aller Beteiligten durchgesetzt hat, dann ist es nicht verwunderlich wenn ausser ihm keiner erscheint.

Es wurden keine Features entwickelt, sondern Komponenten

Wenn das was entwickelt wurde nicht benutzbar und bewertbar ist, warum sollte dann jemand zum Review kommen wollen? Es gibt ja nichts worüber man reden könnte (und ganz nebenbei hat dieses Vorgehen auch nicht viel mit Scrum zu tun).

Es gab kein Sprintziel / keinen Fokus im Sprint

Wenn ein Sprint kein Ziel hat sondern stattdessen unterschiedliche Anforderungen hineingestopft werden stellen viele Stakeholder die Sinnfrage. Lohnt sich ein zweistündiges Meeting wirklich, wenn für jeden nur ein Feature dabei ist, das von Interesse ist? Eher nicht.

Es ist kein Review sondern eine Demonstration

Manche Teams führen kein Sprint Review durch sondern ein Demo-Meeting. Der Unterschied: Neuerungen werden nur vorgeführt und nicht diskutiert. Wird den Stakeholdern so die Möglichkeit zum Feedback geben genommen sinkt erfahrungsgemäss die Teilnahmebereitschaft.

Es gab keine Ankündigung

Da nicht jedes Thema für jeden gleich interessant ist kommen viele Stakeholder nicht zu jedem Review. Um sie zu aktivieren hilft es, wenn die Inhalte mit einigen Tagen Vorlauf kommuniziert werden, so dass klar ist ob sich das Erscheinen lohnt.

Die Vorführung der neuen Features ist konfus oder lustlos

Wer die Teilnehmer eines Meetings nicht ernstnimmt muss sich nicht wundern wenn sie wegbleiben. Und ein nicht vorbereitetes, unstrukturiertes oder widerwillig durchgeführtes Review ist ein Zeichen, dass dieses nicht ernst nehmen stattfindet.

Es gibt keine gemeinsamen Reviews

Ein Sonderfall für Projekte oder Produkte mit mehreren Teams. Wenn es den Anschein hat, dass zu viele Meetings stattfinden neigen, Stakeholder dazu nicht mehr alle zu besuchen. Die einzelnen Reviews zusammenzulegen kann dem entgegenwirken.

---

Natürlich gibt es noch viele weitere mögliche Gründe dafür, dass Sprint Reviews schlecht besucht sind, diese hier sind mir aber vergleichsweise häufig aufgefallen. Behebt man sie ist zumindest die Wahrscheinlichkeit, dass sich weitere Teilnehmer einfinden, deutlich höher.

Donnerstag, 26. April 2018

Bild: Wikimedia Commons / Santeri Viimäki - CC BY 4.0

Kurze Frage: welcher Begriff wird im Scrum Guide ganze 26 mal erwähnt [Edit: seit 2020 18 mal], findet sich aber in sehr vielen Scrum Teams nicht wieder? Die Antwort: das Sprintziel, bzw. Sprint Goal. Obwohl Sprintziele von offensichtlich so großer Bedeutung sind würde ich sagen, dass sie bestenfalls in der Hälfte der über 100 Teams mit denen ich über die Jahre zusammengearbeitet habe verwendet wurden. Die anderen haben einfach nur mehr oder weniger zusammenhängende Arbeit in ihre Sprints gezogen, im Normalfall die obersten User Stories / Anforderungen ihres Product Backlogs. Und das ist ein Problem, denn ohne diese Ziele sind einige Vorteile schwerer erreichbar.

Ein Sprintziel hilft dem Product Owner bei der Planung. Wie in anderen Vorgehensweisen lassen sich auch in Scrum Aufgaben vom Grossen ins Kleine herunterbrechen. Aus der Produktvision wird z.B. eine Teilvision, daraus einige Meilensteine und daraus mehrere Sprintziele. Auch die können und sollen einem Inspect & Adapt unterliegen, trotzdem (oder gerade deswegen) können sie ein gutes Werkzeug sein um Arbeit in Etappen einzuteilen, die man nach und nach planen und angehen kann.

Ein Sprintziel hilft dem Product Owner bei der Priorisierung. Was im Backlog weiter oben stehen sollte und was nicht ist oft nur schwer zu bestimmen. Ist z.B. eine bessere Exportierbarkeit von Kundendaten wichtiger als eine bessere Importierbarkeit von Stammdaten? Wer kann das sagen? Werden die einzelnen Anforderungen zu Sprintzielen gruppiert kann das einfacher sein. Wenn das nächste Sprintziel z.B. lautet, bis zum bald bevorstehenden Stichtag DSGVO-kompatibel zu sein, dann ist klarer was dazugehören sollte (Kundendaten exportieren) und was nicht (Stammdaten-Import).

Ein Sprintziel hilft einem Team dabei fokussierter und konzentrierter zu arbeiten. Gerade bei komplexen und komplizierten Themen gibt es kaum einen größeren Produktivitäts-Hemmer als häufiges Kontext Switching. Sich in kurzen Abständen in immer neue Themen eindenken und immer neue Schnittstellen und Abhängigkeiten klären zu müssen kann in absurdem Ausmass Zeit fressen. Umgekehrt kann das fokussierte Arbeiten an einem Themenkomplex für Synergieeffekte im Denken und Umsetzen sorgen, die vieles beschleunigen.

Ausserdem hilft ein Sprintziel auch bei der Erfolgsmessung, und zwar in der denkbar einfachsten Weise. Man muss sich nur fragen: Haben wir das Sprintziel erreicht, ja oder nein? Damit das möglich ist müssen die Formulierungen natürlich klar und überprüfbar sein, also nicht "Wir wollen ein besseres Nutzungserlebnis bieten" sondern "Wir wollen die Anzahl der bis zum Geschäftsabschluss notwendigen Mouseclicks unter 20 drücken". Als Nebeneffekt führen die dafür nötigen Überlegungen und Diskussionen auch zu einem besseren Verständnis dessen was mit der Anforderung eigentlich gewollt ist.

Zuletzt noch ein Hinweis der selbstverständlicher klingt als er ist - es sollte ein Sprintziel geben, nicht mehrere. Auch hier ein Beispiel: "Wir wollen die die Performance erhöhen und das Design von Rot-Blau auf Grün-Silber umstellen" ist zwar ein Satz, trotzdem sind es mehrere Ziele. Ich habe mit Teams gearbeitet, die alle Sprintziele abgelehnt haben in denen ein Komma, ein Punkt oder die Wörter "und" und "ausserdem" vorkamen. Es hat ihnen geholfen.

Montag, 21. August 2017

Bild: Pixabay / Walkerssk - Lizenz

Als Agile Coach besuche ich bei einem meiner Kunden in unregelmässigen Abständen die Scrum Teams bei ihren Sprintwechseln. Auch letzte Woche war es wieder soweit, allerdings nur in kleinster Runde - neben dem Product Owner waren nur ein Entwickler und ein Business Analyst anwesend, das restliche Team (den Scrum Master eingeschlossen) befand sich in den Sommerferien. Naheliegenderweise war das auch das Thema der Retrospektive: wie kann unter solchen Bedingungen noch ein geregelter Arbeitsbetrieb aufrechterhalten werden?

Diese Frage dürfte bei so gut wie jedem Scrum Team regelmässig auftreten, und das nicht nur im August sondern in allen üblichen Ferienzeiten, z.B. Ende Dezember. Jedesmal wenn sich ein Teil der Teammitglieder für einige Tage oder Wochen verabschiedet fehlen Erfahrungswerte, unerwartete Mehraufwände fallen schwerer ins Gewicht und Arbeitstechniken wie Pair Programming oder Code Reviews können ggf. gar nicht mehr angewandt werden, weil wie im gerade genannten Beispiel nur ein Entwickler übrig ist.

Ein Lösungsansatz den ich bei einem anderen Kunden gesehen habe war, dass ein Team sich entschieden hat geschlossen in den Urlaub zu gehen, und zwar für genau einen Sprint. Nach der Retrospektive des Sprints davor gingen alle in ihre Ferien. Nach der Rückkehr gab es ein kurzes Backlog Refinement um sicherzustellen, dass sich in der Zwischenzeit nichts Neues ergeben hatte, danach ging der normale Rhythmus mit einem Planning wieder los.

Der Vorteil dieses Vorgehens war, dass die oben genannten negativen Effekte auf diese Art vermieden werden konnten. Statt mehrere Sprints mit ausgedünnter Personaldecke zu haben war das Team mit Ausnahme dieser zwei Wochen durchgehend voll besetzt, der "Urlaubssprint" wurde in der Sprintplanung ignoriert und auch in der Berechnung der Velocity nicht berücksichtigt. Dass das Review ausfallen würde wurde den Stakeholdern rechtzeitig vorher mitgeteilt.

Was dieses Vorgehen in diesem Fall begünstigt hat war eine besondere Rahmenbedingung: das Team war Teil eines Tribes, so dass andere Teams einspringen konnten wenn Bugfixing- oder Support-Aufgaben zu erledigen waren. In Konstellationen in denen das nicht der Fall ist müsste man über Ausgleichsmaßnahmen nachdenken. Eine die ich an anderer Stelle miterlebt habe war z.B. die, dass ein Team-Mitglied sich bereiterklärt hat seinen Urlaub später zu nehmen. Während des Urlaubssprints arbeitete er aber in einem anderen Team mit, wodurch die Auswirkungen der Ferienzeit auch dort abgeschwächt wurden.

Donnerstag, 19. Januar 2017

Bild: Pxhere/Matt Lee - CC0 1.0

Vor den ersten "echten Sprint" (einen in dem Software entwickelt wird) einen vorbereitenden "Sprint 0" zu setzen ist in vielen Scrum Teams üblich. Häufig werden hier allerdings Tätigkeiten durchgeführt die nicht so wirklich zu Scrum passen: die nächsten Sprints werden detailliert durchgeplant, Teile der Entwicklung (z.B. Teile des Backends) werden vorweggenommen oder alle User Stories werden bereits in Unteraufgaben geteilt. Alles Dinge die das Inspect & Adapt zu sehr einschränken würden. Ich empfehle eine Konzentration auf andere Dinge:

Onboarding:

Diese klassischen Anfangs-Tätigkeiten fallen in jeder Methode an: Beschaffung und Verteilung von Schlüsselkarten, Zugangsberechtigungen, Nutzeraccounts, Hardware, Arbeitsplätzen, Schrankfächern und dergleichen mehr.

Knowledge Transfer:

Wer kennt die bestehenden Anwendungen besonders gut, wer ist Experte für welche Programmier-Sprache, wie bedient man Wikis und Ticketsysteme, welche Tricks gibt es beim Einrichten der Zugänge und nicht zuletzt: welche Gerichte sollte man in der Kantine essen und welche nicht.

Besuche beim Kunden/Benutzer:

Da man Anwendungen nicht für sich selber baut sondern für diejenigen die sie später anwenden sollen ist ein Besuch bei denen sehr zu empfehlen. Haben sie wirklich die Wünsche und Bedürfnisse die von den Business Analysten und Requirement Engineers unterstellt wurden? Das ist nicht immer der Fall.

Produktvision formulieren:

Welches Problem lösen wir mit unserem Produkt, welchen Bedarf befriedigen wir oder welchen neuen Markt wollen wir mit ihm erschaffen? Nur wer das weiß kann auf ein Ziel hinarbeiten ohne sich auf halbem Weg in einem Gemischtwarenladen unnötiger Features zu verlieren.

Backlog Refinements:

Gerade zu Beginn sind Anforderungen oft in einem noch nicht umsetzbaren Zustand. Zu groß, zu unklar, zu detailliert, zu mehrdeutig, etc. Um nicht im Planning von Sprint 1 in Probleme zu laufen macht es Sinn bereits Vorarbeiten zu leisten.

Architektur/Teststrategie/Entwicklungsstandards/etc.

Ein großer Unterschied zum klassischen Vorgehen. Diese Dinge sollen nicht komplett im voraus festgelegt werden, im Gegenteil. Sie müssen so schlank und flexibel gestaltet werden, dass sie im Zweifel den Bedürfnissen angepasst werden können.

Technische Infrastruktur:

Von den Staging-Umgebungen über die Build Pipeline bis hin zu den Testautomatisierungs- und Monitoring-Tools gibt es einiges an technischen Voraussetzungen die in Scrum zwingend nötig sind, so dass sie schon von Beginn an bereitgestellt werden müssen.

Workshops zu Methoden und Techniken:

Scrum, Kanban, XP, TDD, Micoservices und was es sonst noch gibt - dort wo die Teammitglieder es noch nicht kennen sollte es vermittelt werden. Und selbst wenn alle es bereits kennen macht das Sinn, denn häufig verstehen verschiedene Menschen etwas völlig Unterschiedliches unter den selben Begriffen.

Last but not least: Teamevents:

Auch das Socializing sollte nicht unter den Tisch fallen. Das kann vom gemeinsamen Mittagessen bis zum mehrtägigen Hackathon alles Mögliche bedeuten, wichtig ist, dass die Teammitglieder sich kennen und schätzen lernen. Das ist die Grundlage für vieles weitere.

Montag, 16. Januar 2017

Ich gestehe, ich bin im Moment zu faul um etwas zu schreiben, stattdessen mal wieder ein Video, diesesmal zum Thema Design Sprints.

Einen Hinweis gebe ich aber noch mit: wer glaubt, dass in einem Designsprint der Inhalt des folgenden Entwicklungssprints vorbereitet wird, der hat das Konzept nicht verstanden.

Montag, 6. Juni 2016

Bild: Wikimedia Commons/Photobobil - CC BY 2.0

Zu den Besonderheiten Deutschlands gehört sicherlich die Häufung von Feiertagen im Mai. Ostern, Tag der Arbeit, Christi Himmelfahrt, Pfingsten und Fronleichnam folgen relativ kurz aufeinander, weshalb dieser Monat signifikant weniger Arbeitstage hat als alle anderen. Nimmt man noch die Brückentage dazu kann in Summe mehr als eine Woche wegfallen, allerdings nicht auf einmal sondern verteilt.

Für Unternehmen die mit Scrum arbeiten kann das ein Problem sein. In den Mai-Sprints stehen weniger Arbeitstage zur Verfügung, es wird weniger vervollständigt, die Velocity sinkt. Und an dieser Stelle tritt ein Verfälschungseffekt ein: das Sinken der Velocity liegt nicht an sinkender Leistungsfähigkeit sondern eben an den Feier- und Brückentagen. Das lässt sich allerdings aus den Zahlen nicht herauslesen - sowohl in der kurzfristigen als auch in der langfristigen Auswertung wirkt das Absinken wie ein Leistungsabfall. Wenn man jetzt basierend auf der Velocity eine Prognose der verbleibenden Arbeitszeit machen will wird diese unrealistisch niedrig sein.

Ein Unternehmen mit dem ich vor ein paar Jahren zu tun hatte, hatte einen interessanten Weg gefunden mit diesem Effekt umzugehen: Sprint-Längen wurden dort nicht in Wochen festgelegt sondern in Arbeitstagen, z.B. 10 Arbeitstage pro Sprint. Ein Sprint im letzten Mai hätte demnach nicht einfach die Kalenderwochen 20 und 21 umfasst sondern wäre wegen des Feiertages am Pfingstmontag erst am 17. losgegangen und 10 Werktage später am Montag dem 30. beendet worden.

Für jedes Unternehmen das auf diese Weise vorgeht hat die Velocity eine wesentlich höhere Aussagekraft und Brauchbarkeit als für diejenigen, die noch mit Kalenderwochen arbeiten. Auf der Negativseite ist es dafür aber auch so, dass der "gefühlte Rhytmus" aus dem Gleichgewicht kommen kann, schließlich können Planning, Review und Retrospektive jetzt nicht mehr alle zwei Wochen stattfinden sondern gegebenenfalls etwas später. Vor allem bei der Einbindung von Stakeholdern kann das zu Problemen führen.

Andererseits - irgendwelche Probleme gibt es ja immer. Für mich kommt diese alternative Festlegung von Sprint-Längen auf jeden Fall auf die Liste der Dinge die ich irgendwann mal ausprobieren muss.

Montag, 15. Februar 2016

Bild: Wikimedia Commons/Jocelyn Augustino - CC0 1.0

[Edit: aktualisiert um den aktuellen Stand des Scrum Guide abzubilden]
Sprint-Abbrüche sind in Scrum ein Mythos. Manche kennen sie gar nicht, viele haben nur eine ungefähre Vorstellung gesehen hat sie fast niemand. Das hat mich zu ein paar eigenen Überlegungen zu diesem Thema inspiriert. Tatsächlich ist mir nämlich aufgefallen, dass ich in den hunderten von Sprints die ich als Scrum Master, Teammitglied, Scrum Coach oder sonstwas erlebt habe kein einziger dabei war, der abgebrochen worden ist. Ich habe darüber noch nie nachgedacht, frage mich aber gerade warum das wohl so ist.

Zunächst das Grundlegende: einen Sprint abzubrechen ist möglich und unter bestimmten Voraussetzungen sogar sinnvoll, weshalb der Scrum Guide diese Möglichkeit sogar explizit erwähnt:

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Man sieht - das Vorgehen ist klar geregelt. Ich war auch bereits mehrfach in Situationen in denen ein Abbruch Sinn gemacht hätte und meine mich erinnern zu können, dass ich meinen Product Ownern auch zum Abbruch geraten habe. Dazu gekommen ist es nicht.

Rückblickend würden mir mehrere Gründe einfallen, aus denen sich die Product Owner vermutlich dagegen entschieden haben¹:

Unkenntnis der Scrum-Regeln

Angst vor Strafe oder Gesichtsverlust

In solchen Firmen

Falsch verstandenes Eliminate Waste

"Wenn wir den Sprint abbrechen war die ganze Arbeit umsonst."

Einheitlicher Sprintrhythmus

Faulheit

Vom Gefühl her müsste ich jeden dieser Gründe mindestens einmal erlebt haben, könnte aber nicht mehr sagen wie die Verteilung war. Sollte es in Zukunft wieder auftauchen mache ich vielleicht Notizen.

¹Natürlich werden wir uns über die Entscheidung unterhalten haben, allerdings habe ich an der Stelle Erinnerungslücken.