Hat man es endlich geschafft, die Beteiligten davon zu überzeugen, die Entwicklungsabteilung auf Scrum umzustellen, kommen vor dem Start einige Fragen zum Set-up. Eine davon ist die Frage nach der optimalen Sprint-Länge – also der Dauer einer Entwicklungs-Iteration. In der Literatur werden als optimale Zeitspannen zwei bis vier Wochen genannt, wobei eher längere Sprints empfohlen werden. Doch sollte man schon von Beginn an mit solch langen Sprints starten?
Gerade in der Anfangsphase der Implementierung von Scrum spielt der Grundsatz „Inspect and Adapt“ (Untersuchen und Anpassen) eine gewichtige Rolle. Die Team-Mitglieder sind unerfahren und unsicher, was den neuen Prozess angeht und auch die anderen mehr oder weniger direkt beteiligten Personen müssen erst noch lernen, wie nun mit dem Entwicklungsteam kommuniziert wird und wie Aufgaben an sie herangetragen werden.
Aus Fehlern lernen
Das wichtigste Werkzeug zur Erkennung und Optimierung von Schwierigkeiten und Problemen ist die Sprint-Retrospektive. Am Ende eines jeden Sprints treffen sich die Team-Mitglieder und besprechen den vergangenen Sprint. Es werden Stellen identifiziert, die nicht so gut funktioniert haben. Es werden aber auch positive Erfahrungen ermittelt. Aus beiden Beobachtungen werden konkrete Schritte und Handlungen für den nächsten Sprint eruiert und das Spiel beginnt vom neuen.
Schnell wird klar, dass eine zu lange Sprint-Länge eine erhebliche Auswirkung auf den Lernprozess hat, da bei den anfangs erwähnten Zeitspannen auch die wichtige Retrospektive nur alle zwei bzw. vier Wochen stattfindet. Im schlimmsten Fall kann man also nur alle vier Wochen im Team ausführlich über Probleme sprechen und daraus die entscheidenden Konsequenzen herleiten.
Reaktionszeit
Eine weitere Überlegung bei der Bestimmung der optimalen Sprint-Länge ist der Umgang mit täglichen Aufgaben der Entwicklungsabteilung und ihrer Reaktionszeit. In der Pre-Scrum-Zeit werden meistens kurzfristig wichtige Arbeiten auf Zuruf erledigt. Dies sorgt einerseits für eine extrem kurze Reaktionszeit. Es führt aber auf der anderen Seite oft zu einem regelrechten Chaos. Und letztendlich ist eben dieses „Chaos Driven Development“ der Grund für die Einführung von Scrum.
Nun befindet man sich häufig nicht in der idealisierten Welt eines Lehrbuchs und muss eben auch auf unerwartete und kurzfristige Anfragen reagieren. Der Unterschied zur chaosgetriebenen Entwicklung besteht darin, dass die Aufgaben jetzt nicht mehr auf Zuruf abgearbeitet werden, sondern jetzt im Product Backlog landen, vom Product Owner priorisiert und entsprechend in einen der nächsten Sprints eingeplant werden.
Je nach gewählter Sprint-Länge kann der nächste Sprint in ferner Zukunft liegen, da er erst in zwei oder vier Wochen startet. Gerade am Anfang der Implementierung von Scrum wird man hier nicht auf viel Verständnis bei den anfragenden Abteilungen hoffen können.
Der goldene Weg?
Wie kann man also die beiden genannten Anforderungen optimal lösen und sowohl durch häufige Retrospektiven schnell lernen als auch vergleichsweise zügig auf wichtige Anfragen reagieren? Man startet mit Sprints, die nicht länger als eine Woche dauern. Das Team kann so bereits nach sieben Tagen eine Rückschau durchführen. Gleichzeitig wird die Reaktionszeit auf eine einzige Woche reduziert und führt so zur Erledigung wichtiger Aufgaben nach bereits zwei Wochen, nämlich wenn der nächste Sprint endet.
Die Schattenseite
Natürlich gibt es auch eine Schattenseite, die hier nicht verschwiegen werden sollte. Zwar lernt das Team durch den Wochenrhythmus schneller und auch der Scrum-Overhead bestehend aus Planung, Schätzung, Review und Retrospektive verkürzt sich entsprechend proportional zur Sprint-Länge. Dennoch kann es passieren, dass das Team bei solch kurzen Iterationen scheinbar nur noch von Review zu Review hetzt.
Inspect and Adapt
Es empfiehlt sich daher nach einem halben Jahr die Entscheidung über die verkürzte Sprint-Länge erneut infrage zu stellen und gegebenenfalls die künftigen Sprints auf zwei oder mehr Wochen zu verlängern.
Der neue Prozess ist jetzt nämlich schon einige Monate in Verwendung und in der Unternehmung zumindest etablierter als am Anfang. Andere Abteilungen haben gelernt, mit dem Prozess umzugehen und gesehen, dass das Scrum-Team nicht gegen sie, sondern mit ihnen arbeitet – auch wenn die Abschirmung des Teams anfänglich einen anderen Eindruck vermittelt hat.