Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03512.jsonl.gz/3156

Viele Unternehmen starten mit 2-Wochen-Sprints. Weil 2-Wochen-Sprints sowohl für das Team als auch für die Organisation anspruchsvoll sind, da man den gesamten Entwicklungsprozess in zwei Wochen erledigen muss (Business Modelling, Requirements, Analyse & Design, Implementation, Testing, Deployment), diskutieren Teams rasch auch über die Möglichkeit von 3-Wochen-Sprints. In diesem Blog-Beitrag möchte ich die beiden populärsten Sprint-Varianten vergleichen.
Der Sprint ist der grosse Lern- und Feedback-Zyklus im Scrum. Ein Sprint schafft Transparenz über die Lieferfähigkeit eines Entwicklungsteams, so der Scrum Guide.
Sprints ermöglichen eine Vorhersagbarkeit, indem sie mindestens einmal im Monat [falls 4-Wochen-Sprint] Überprüfung und Anpassungen des Fortschritts zu einem bestimmten Sprint-Ziel ermöglichen.
Falls das Entwicklungsteam nicht (ausreichend) liefert, müssen mittels Überprüfung (z. B. Sprint Retrospektive und Sprint Review) der Prozess wie das Produkt angepasst werden. Je kürzer der Feedback-Zyklus, umso schneller der gemeinsame Lerneffekt, umso höher die nachhaltige Lieferfähigkeit des Entwicklungsteams - so die Formel. Als klassische Massnahme zur Agilisierung eines Entwicklungsteams empfehle ich für den Start mit Scrum den 1-Wochen-Sprint.
Das Argument, das Entwicklungsteam "vertrödle" zu viel Zeit in den Sprint-Zeremonien und mittels eines 3-Wochen-Sprints könnte man netto Sprint-Zeremonien-Zeit einsparen, ignoriert die Vorgaben des Scrum Guides. Die grossen Sprint-Zeremonien werden nämlich anteilig der Sprint-Länge berechnet. Zum Beispiel ist für das Sprint Planning folgende Timebox empfohlen:
In einem 3-Wochen-Sprint kann man mehr liefern als in einem 2-Wochen-Sprint, so die Argumentation. Meiner Erfahrung nach liefern Teams in 3-Wochen-Sprints gleichviel wie in 2-Wochen-Sprints. Somit netto weniger. Denn der 3-Wochen-Sprint verführt das Team zu falscher Sicherheit, Prokrastination ist die natürliche Folge. Der gesunde Druck eines 2-Wochen-Sprints ist verflüchtigt.
Das Team könne in 2-Wochen-Sprints nichts Fertiges liefern, weil sie von anderen Teams abhängen, so der Mythos. Das Symptom ist durchaus richtig, aber bloss oberflächlich analysiert worden. Ein Causal Loop Diagramm würde offenbaren, dass entweder das Team ungünstig "geschnitten" ist und/oder das Team nicht über alle notwendigen (IT-)Disziplinen verfügt, um ein lauffähiges Produktinkrement zu schaffen. 3-Wochen-Sprints bekämpfen nicht die Symptome, sondern verdecken diese bloss und reduzieren die Transparenz über die "wahre" Lieferfähigkeit des Teams.
Das Team kann eine Story nicht in einem 2-Wochen-Sprint umsetzen, so das Argument. Doch in diesem Fall ist die Aufgabe nicht angemessen "geschnitten". Ursache dafür ist, dass das Backlog Management unterschätzt und nicht mit der erforderlichen Qualität praktiziert ist. Ein erfahrenes Team konstruiert immer gleich grosse Storys - no estimates ist die natürliche Evolution im Backlog Management. Ein matures Team akzeptiert auch keine Storys im Sprint, wo das gemeinsame Verständnis noch unterentwickelt ist (unterstützt mit einer Definition of Ready). Ohnehin überfordern uns zu grosse Aufgaben kognitiv und der Team-Informations-Fluss kann bei zu grossen Aufgaben nicht mehr bewältigt werden.
Einen 3-Wochen-Sprint könne das Team genauer planen als einen 2-Wochen-Sprint, so der Mythos. Diese Argumentation verkennt, dass die Planungssicherheit mit zunehmendem Planungshorizont abnimmt. Je kleiner der Planungshorizont, umso höher die Planungssicherheit. Gewisse Agilisten (z. B. ich) sind überzeugt, dass der Planungshorizont von einem Tag im Daily Scrum zu gross und zu unsicher sei - und man deswegen einen Planungshorizont von "bis zur nächsten Pause" einführen müsse. Ein 3-Wochen-Sprint verschlechtert somit die Planungssicherheit.
In manchen Situationen können aber 3-Wochen-Sprints durchaus berechtigt sein. Hier einige Hinweise:
Dein Team hat die Technische Exzellenz gemäss LeSS verinnerlicht. Das bedeutet, dass jeder Commit getestet und deploybar ist. Dein Team hat die eigenen Prozesse soweit mittels Inspektion und Adaption optimiert, dass nun die Abnahme den natürlichen Flaschenhals bildet. Und den Abnahmeprozess kann und darf dein Team aufgrund organisatorischer Rahmenbedingungen nicht beeinflussen. Ein (künstlich) verlängerter Sprint kann helfen, die Abnahmekapazitäten besser auszulasten. Allerdings droht auch hier die allgemeine Prokrastination.
Je nach Definition des Produkts sind mehrere Teams gleichzeitig gefordert, um ein Produktinkrement herzustellen. Auch ein kluges Schneiden der Teams in z. B. Feature-Teams gemäss LeSS, ist aus Komplexitätsgründen ausgeschlossen. Wenn mehrere Teams gleichzeitig an einem Feature arbeiten können und keine Abhängigkeitsketten entstehen, dann kann das der 3-Wochen-Sprint unterstützen. Im 3-Wochen-Sprint haben die Teams ausreichend Zeit, ihre Abhängigkeiten unterhalb aufzulösen und gemeinsam ein Produktinkrement zu bauen, ohne dass sie Abhängigkeiten über die Sprints hinweg planen müssen.
Gemäss meiner Beobachtung können die Befürworter von 3-Wochen-Sprints wie folgt kategorisiert werden:
Diese Team-Mitglied-Kategorie lehnt im Grundsatz die Scrum-Zeremonien ab. Sie sind blosses Geschwätz. Für diese Kategorie sind ebenfalls Communitys oder Pausen nutzlos. Falls die Kategorie keinen Einfluss hat, kann sie ignoriert werden. Bei Einfluss innerhalb der Organisation muss der Scrum Master Einzelgespräche führen und die Kategorie vom Geschäftswert der Scrum-Zeremonien begeistern.
Diese Team-Mitglied-Kategorie spürt zwar die Herausforderungen einer unzulänglichen Lieferfähigkeit (z. B. Backlog Management, Team-Konstellation, Team-Fähigkeiten, Komplexität), kann die Probleme aber nicht an der Ursache lösen, sondern will einfach "mehr Zeit". Diese Kategorie ist zu beobachten, weil sie damit unabsichtlich die wahren Herausforderungen eines nicht lieferfähigen Teams kaschiert und versteckt. Denn der 3-Wochen-Sprint reduziert die Transparenz über die Lieferfähigkeit.
Alternativ beraten wir dich auch gerne, um den möglichst optimalen Sprint-Zyklus für deine Organisation zu entwickeln. In den meisten Fällen genügt der 2-Wochen-Sprint. Manchmal sind aber auch 3-Wochen-Sprints berechtigt - aber nur manchmal ;-).