Die passende Sprintlänge finden – Ein empirischer Prozess.

Der Inhalt ist nicht verfügbar.
Bitte erlaube Cookies, indem du auf Übernehmen im Banner klickst.

Die Sprintlänge ist ein sehr wichtiges und sensibles Thema, wenn es um das Thema Scrum und agiles Arbeiten geht. Selbstverständlich darf man hier die Zeitspanne nicht pauschalisieren, da jedes Unternehmen verschieden ist und auch die Marktdynamik individuell eine Rolle spielt. In dieser Episode #38 gehe ich insbesondere auf die richtige Aufstellung eines Sprints ein und beantworte die Frage: “Wie finde ich als Team die geeignete Sprintlänge?”. Natürlich werden hier spezielle Faktoren wichtig und berücksichtigt, um die Sprintlänge optimal zu definieren. Da Scrum auf einer empirischer Steuerung basiert, lernen wir in jedem Sprint aus Erfahrungen dazu und können den nächsten Sprint anpassen und verbessern. Mein Tipp: Die Faktoren zu Beginn einmal wirken lassen und einfach mal loslegen.

30 Tage Sprint 

Der Scrum Guide besagt, dass ein Sprint nicht länger als 30 Tage sein sollte. In der Praxis arbeiten viele Teams mit einer Sprintlänge von zwei Wochen. Eine Sprintlänge sollte meiner Meinung nach nicht einfach pauschal definiert werden. Es ist viel wichtiger, sich darauf zu konzentrieren, eine für das Team und den Kontext passende Länge zu finden. Dass der Scrum Guide für Sprints eine Obergrenze von 30 Tagen festgelegt hat, ist jedoch sinnvoll. Die Intention dahinter findet sich in der empirischen Steuerung, auf der Scrum als agile Methode basiert. Konkret bedeutet das, dass Lernen aus der Erfahrung heraus ein wichtiger Bestandteil dieser agilen Arbeitsweise ist. Sprint für Sprint wird dabei das Ergebnis inspiziert (inspect) und dementsprechend Maßnahmen daraus abgeleitet (adapt). Die Obergrenze von 30 Tagen soll sicherstellen, dass dieser Austausch regelmäßig und oft genug stattfindet, um diese Erfahrung schnell aufzubauen. 

 

Die Intention dahinter wird besonders deutlich, wenn man sich vor Augen hält, was passieren würde, wenn das Ergebnis nicht in kurzen Zeitabständen betrachtet wird und der Sprint auf einen längeren Zeitraum (z.B. auf ein halbes Jahr) gedehnt wird. Die Konsequenz daraus wäre, dass das Team im Rahmen einer “eingefrorenen” Umgebung für ein halbes Jahr an einem Produkt arbeitet und das Ergebnis erst nach sechs Monaten betrachtet. Zum einen ist es sehr wahrscheinlich, dass sich die Gegebenheiten in diesem Zeitraum bereits wieder geändert haben und das Ergebnis nicht mehr dem entspricht, was eigentlich gebraucht wird. Darüber hinaus ist es sehr wahrscheinlich, dass diese Arbeitsweise mit einer vorgeschalteten Planung im klassischen Sinne einhergehen würde. Das Resultat ist klar: Scrum ist dann einfach nicht mehr Scrum. Es ist also wichtig, dass Sprints nicht zu lange sind. Die Obergrenze von 30 Tagen sollte meiner Meinung nach daher unbedingt eingehalten werden, um “inspect and adapt” auch wirklich zu leben. 

Fünf Faktoren, um die passende Sprintlänge zu finden

Um die passende Sprintlänge zu finden, betrachte ich fünf Faktoren als ausschlaggebend. 

 

1.ausreichend Zeit für das Entwicklungsteam 

Um gute Ergebnisse zu schaffen, benötigt das Entwicklungsteam Zeit. Um die passende Sprintlänge zu finden gilt es also, zu hinterfragen, wie viel Zeit notwendig ist, um Ergebnisse in der gewünschten Qualität hervorzubringen. Das Entwicklungsteam  wird grundsätzlich eher zu längeren Sprints tendieren. Um eine balancierte Einschätzung zu treffen, gilt es, weitere Faktoren in Betracht zu ziehen. 

 

 2.Die Dynamik des Umfelds 

Dem Wunsch nach ausreichend Zeit für die Hervorbringung von Ergebnissen, steht die Dynamik der Umgebung, beispielsweise die Marktsituation und Kundenwünsche gegenüber. Wenn Teams in einem besonders dynamischen Umfeld arbeiten und während des Sprint mit viel ungeplanter, zusätzlicher Arbeit konfrontiert werden, empfiehlt es sich, die Sprintlänge eher kürzer zu wählen.

 

3.Vertrauensverhältnis zwischen Product Owner und Entwicklungsteam 

Das Entwicklungsteam arbeitet in Scrum selbstorganisiert und übernimmt Verantwortung für den Sprint. Der Product Owner steht dabei für Fragen zu Verfügung und wird im Falle von Problemen frühzeitig in die Arbeit eingebunden. 

Damit dieses Zusammenspiel über einen längeren Sprintzyklus von beispielsweise vier Wochen funktionieren kann, benötigt es ein intaktes Vertrauensverhältnis zwischen Entwicklungsteam und Product Owner. Dieses ist besonders am Anfang einer Zusammenarbeit oft noch nicht ausgeprägt genug. Dies hat zur Folge, dass Product Owner nach einer gewissen Zeit anfangen, enger zu überwachen oder gegebenenfalls sogar aus Angst, am Ende des langen Sprints zu scheitern, Einfluss nehmen und nach steuern. Es empfiehlt sich also, das Vertrauensverhältnis bei der Festlegung der richtigen Sprintlänge zu hinterfragen und besonders am Anfang eine kürzere Sprintlänge zu wählen

 

4.Lerneffekte im Team 

Je kürzer der Sprintzyklus, desto schneller der Lerneffekt. Scrum Master tendieren daher häufig zu kurzen Sprints, um diese Lerneffekt zu forcieren. In der Praxis beobachte ich, dass Teams nach ca. drei bis vier Sprints eingespielt sind – unabhängig von der Sprintlänge. Bei einwöchigen Sprints bedeutet das, dass Teams sich bereits nach drei oder vier Wochen gemeinsam als Team sehr weit entwickelt haben. Im Vergleich dazu sind Teams bei einer Sprintlänge von vier Wochen erst viel später an diesem Punkt. Es empfiehlt sich also, auch aufgrund der schnell eintretenden Lerneffekte, die Sprintlänge eher kürzer zu gestalten

 

5.Kurze Sprintzyklen erfordern Disziplin

Ein kurzer Sprintzyklus von einer Woche hat den großen Vorteil, als Team sehr schnell eingespielt zu sein. Darüber hinaus ist wesentlich reaktionsfähiger, als bei langen Sprints. Die Umsetzung von sehr kurzen, beispielsweise einwöchigen Sprints, erfordert insgesamt allerdings ein sehr hohes Maß an Disziplin. Dies setzt eine hohe Fokussiertheit innerhalb der unterschiedlichen Scum Events voraus. Sie müssen auf den Punkt sein und ihren Sinn und Zweck erfüllen, damit effektiv weitergearbeitet werden kann. Dies bedingt ebenfalls eine optimale Vorbereitung. Aufgrund der schnellen Lerneffekte und der Reaktionsfähigkeit wären einwöchige Sprints sehr wünschenswert. In der Praxis zeigt sich jedoch, dass das notwendige Maß an Fokussiertheit häufig nicht umzusetzen ist. Wenn die Entscheidung getroffen wird, einwöchige Sprints umzusetzen, sollte man sich über die dafür notwendige Disziplin im Klaren sein. 

Diskussionen über längere Sprints spiegeln häufig Dysfunktionen bei der Arbeit mit Scrum wider

In der Praxis erkenne ich häufig, dass Gespräche und Diskussionen über die passende Sprintlänge mit einer Dysfunktion in der Umsetzung von Scrum einhergehen. Diese werden nämlich nach Abschluss eines Sprints besonders sichtbar. Um Missstände zu beseitigen, muss an dieser Stelle eine Auseinandersetzung mit den Problemen erfolgen. Ich erkenne häufig, dass diese Auseinandersetzung nicht stattfindet. Vielmehr versuchen die Beteiligten, teils bewusst, teils unbewusst, das Problem durch eine Veränderung der Sprintlänge zu lösen. “Wir brauchen mehr Zeit” ist dann das Standardargument. 

 

Gründe, die den Wunsch nach einem längeren Sprintzyklus aufkommen lassen, sind unterschiedlich. Eine Dysfunktion zeigt sich häufig in der suboptimalen Zusammenarbeit als Team. In diesem Szenario zeigt sich in der Praxis immer wieder, dass Teams nicht zusammenarbeiten, sondern jedes Teammitglied sich “in seine Ecke verzieht”, um alleine an einem Teil des Produktes zu arbeiten. Austausch und gegenseitiges Aushelfen finden kaum statt. Der Gedanke, alle Teile des Produktes am Ende eines Sprints zusammenzusetzen und ein funktionierendes Ergebnis zu erhalten, erweist sich aber meist unrealistisch. Am Ende des Sprints wird dieses Problem dann radikal sichtbar, indem das Ergebnis nicht zufriedenstellend oder unfertig ist. Eine Ausweitung des Sprintzyklus wird hier jedoch keine Abhilfe schaffen. Im Gegenteil: Dadurch, dass der Sprint verlängert wird, vergrößern sich auch die Probleme. Meine Empfehlung ist es daher, eine gewünschte Verlängerung des Sprints kritisch zu hinterfragen und zu analysieren, ob eine mögliche Dysfunktion das Problem sein könnte, welches dadurch nicht gelöst wird, sondern lediglich aufgeschoben oder gar verschlimmert wird.   

Zusammenfassung

Um schnell zu lernen und sich als Team weiterzuentwickeln ist es wichtig, eine Sprintlänge unter 30 Tagen zu wählen. Viele Teams arbeiten mit zweiwöchigen Sprintzyklen. Eine pauschale Antwort auf die Frage nach der richtigen Sprintlänge gibt es jedoch nicht. Jedes Team muss basierend auf unterschiedlichen Faktoren (Dynamik des Umfelds, Vertrauen zwischen Team und PO, passende Lerngeschwindigkeit und Disziplin) entscheiden, was die passende Sprintlänge darstellt. Der Wunsch nach längeren Sprintzyklen resultiert nicht selten aus einer vorhandenen Dysfunktion. Eine Veränderung der Sprintlänge sollte daher kritisch hinterfragt werden.

Hast du Fragen oder Anmerkungen? Ich freue mich immer über Feedback.

Alle Folgen kannst du dir auch über meinen Podcast “Scrum meistern” anhören. Besuche auch meinen YouTube Channel “Scrum meistern”.

Dort findest du alle Interview-Videos.

Übrigens: Solltest Du interessiert sein, dich im Rahmen eines Trainings noch einmal genauer mit den Scrum Events oder Rollen theoretisch sowie praktisch auseinanderzusetzen, empfehle ich das Certified Scrum Master Training. Speziell für Product Ownership empfehle ich das Certified Product Owner Training.

 

 

Schreibe einen Kommentar

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen