Was ist die opti­ma­le Sprint-Länge

|

Hat man es end­lich geschafft, die Betei­lig­ten davon zu über­zeu­gen, die Ent­wick­lungs­ab­tei­lung auf Scrum umzu­stel­len, kom­men vor dem Start eini­ge Fra­gen zum Set-up. Eine davon ist die Fra­ge nach der opti­ma­len Sprint-Län­ge – also der Dau­er einer Ent­wick­lungs-Ite­ra­ti­on. In der Lite­ra­tur wer­den als opti­ma­le Zeit­span­nen zwei bis vier Wochen genannt, wobei eher län­ge­re Sprints emp­foh­len wer­den. Doch soll­te man schon von Beginn an mit solch lan­gen Sprints starten?

Gera­de in der Anfangs­pha­se der Imple­men­tie­rung von Scrum spielt der Grund­satz „Inspect and Adapt“ (Unter­su­chen und Anpas­sen) eine gewich­ti­ge Rol­le. Die Team-Mit­glie­der sind uner­fah­ren und unsi­cher, was den neu­en Pro­zess angeht und auch die ande­ren mehr oder weni­ger direkt betei­lig­ten Per­so­nen müs­sen erst noch ler­nen, wie nun mit dem Ent­wick­lungs­team kom­mu­ni­ziert wird und wie Auf­ga­ben an sie her­an­ge­tra­gen werden.

Aus Feh­lern lernen

Das wich­tigs­te Werk­zeug zur Erken­nung und Opti­mie­rung von Schwie­rig­kei­ten und Pro­ble­men ist die Sprint-Retro­spek­ti­ve. Am Ende eines jeden Sprints tref­fen sich die Team-Mit­glie­der und bespre­chen den ver­gan­ge­nen Sprint. Es wer­den Stel­len iden­ti­fi­ziert, die nicht so gut funk­tio­niert haben. Es wer­den aber auch posi­ti­ve Erfah­run­gen ermit­telt. Aus bei­den Beob­ach­tun­gen wer­den kon­kre­te Schrit­te und Hand­lun­gen für den nächs­ten Sprint eru­iert und das Spiel beginnt vom neuen.

Schnell wird klar, dass eine zu lan­ge Sprint-Län­ge eine erheb­li­che Aus­wir­kung auf den Lern­pro­zess hat, da bei den anfangs erwähn­ten Zeit­span­nen auch die wich­ti­ge Retro­spek­ti­ve nur alle zwei bzw. vier Wochen statt­fin­det. Im schlimms­ten Fall kann man also nur alle vier Wochen im Team aus­führ­lich über Pro­ble­me spre­chen und dar­aus die ent­schei­den­den Kon­se­quen­zen herleiten.

Reak­ti­ons­zeit

Eine wei­te­re Über­le­gung bei der Bestim­mung der opti­ma­len Sprint-Län­ge ist der Umgang mit täg­li­chen Auf­ga­ben der Ent­wick­lungs­ab­tei­lung und ihrer Reak­ti­ons­zeit. In der Pre-Scrum-Zeit wer­den meis­tens kurz­fris­tig wich­ti­ge Arbei­ten auf Zuruf erle­digt. Dies sorgt einer­seits für eine extrem kur­ze Reak­ti­ons­zeit. Es führt aber auf der ande­ren Sei­te oft zu einem regel­rech­ten Cha­os. Und letzt­end­lich ist eben die­ses „Cha­os Dri­ven Deve­lo­p­ment“ der Grund für die Ein­füh­rung von Scrum.

Nun befin­det man sich häu­fig nicht in der idea­li­sier­ten Welt eines Lehr­buchs und muss eben auch auf uner­war­te­te und kurz­fris­ti­ge Anfra­gen reagie­ren. Der Unter­schied zur cha­os­ge­trie­be­nen Ent­wick­lung besteht dar­in, dass die Auf­ga­ben jetzt nicht mehr auf Zuruf abge­ar­bei­tet wer­den, son­dern jetzt im Pro­duct Back­log lan­den, vom Pro­duct Owner prio­ri­siert und ent­spre­chend in einen der nächs­ten Sprints ein­ge­plant werden.

Je nach gewähl­ter Sprint-Län­ge kann der nächs­te Sprint in fer­ner Zukunft lie­gen, da er erst in zwei oder vier Wochen star­tet. Gera­de am Anfang der Imple­men­tie­rung von Scrum wird man hier nicht auf viel Ver­ständ­nis bei den anfra­gen­den Abtei­lun­gen hof­fen können.

Der gol­de­ne Weg?

Wie kann man also die bei­den genann­ten Anfor­de­run­gen opti­mal lösen und sowohl durch häu­fi­ge Retro­spek­ti­ven schnell ler­nen als auch ver­gleichs­wei­se zügig auf wich­ti­ge Anfra­gen reagie­ren? Man star­tet mit Sprints, die nicht län­ger als eine Woche dau­ern. Das Team kann so bereits nach sie­ben Tagen eine Rück­schau durch­füh­ren. Gleich­zei­tig wird die Reak­ti­ons­zeit auf eine ein­zi­ge Woche redu­ziert und führt so zur Erle­di­gung wich­ti­ger Auf­ga­ben nach bereits zwei Wochen, näm­lich wenn der nächs­te Sprint endet.

Die Schat­ten­sei­te

Natür­lich gibt es auch eine Schat­ten­sei­te, die hier nicht ver­schwie­gen wer­den soll­te. Zwar lernt das Team durch den Wochen­rhyth­mus schnel­ler und auch der Scrum-Over­head bestehend aus Pla­nung, Schät­zung, Review und Retro­spek­ti­ve ver­kürzt sich ent­spre­chend pro­por­tio­nal zur Sprint-Län­ge. Den­noch kann es pas­sie­ren, dass das Team bei solch kur­zen Ite­ra­tio­nen schein­bar nur noch von Review zu Review hetzt.

Inspect and Adapt

Es emp­fiehlt sich daher nach einem hal­ben Jahr die Ent­schei­dung über die ver­kürz­te Sprint-Län­ge erneut infra­ge zu stel­len und gege­be­nen­falls die künf­ti­gen Sprints auf zwei oder mehr Wochen zu verlängern.

Der neue Pro­zess ist jetzt näm­lich schon eini­ge Mona­te in Ver­wen­dung und in der Unter­neh­mung zumin­dest eta­blier­ter als am Anfang. Ande­re Abtei­lun­gen haben gelernt, mit dem Pro­zess umzu­ge­hen und gese­hen, dass das Scrum-Team nicht gegen sie, son­dern mit ihnen arbei­tet – auch wenn die Abschir­mung des Teams anfäng­lich einen ande­ren Ein­druck ver­mit­telt hat.