Der Sprint
Heute widmen wir uns dem Sprint. Schon oft angesprochen und auch schon oft Andiskutiert. Beispielsweise bei der Sprintlänge. Beim Sprint handelt es sich um den Namen der Iteration im Scrum. Im Agilen wird häufig in Iterationen, also kurzen Zeitabschnitten entwickelt. Der Sprint ist dabei die Bezeichnung für genau solch einen Zeitabschnitt. Im Scrum ist dieser Abschnitt 
kleiner als ein Monat und ein Sprint folgt direkt auf den anderen.
Diese Folge auf YouTube: https://youtu.be/-p5mcetTJKQ
Artefakt
Beim Sprint handelt es sich um ein Artefakt und auch um ein Ritual als dem Scrum Guide. Der Sprint gibt den Takt oder Herzschlag des Scrum Teams an.
Während des Sprints werden nach Möglichkeit keine Anpassungen an dem Sprint und vor allem nicht am Ziel gemacht. Ändert sich das Ziel, so kann der Sprint abgebrochen und ein neuer gestartet werden.
Für mich als Projektleiter enthält der Sprint quasi alle Elemente, die ich auch im klassischen Projektmanagement habe, nur eben auf deutlich kürzere Zeiträume. Sogenannte Iterationen oder Sprints.
Diese kurzen Zyklen reduzieren das Risiko, ermöglichen schnelles lernen und vermeiden Verschwendung bei der Planung.
Der Sprint selbst ist dabei ein fester Zeitraum. Die Länge ist also nicht variabel und wird mit dem Team und der Organisation vereinbart. Natürlich kann die Länge dann über Retrospektiven oder ähnliche Verbesserungsprozesse doch mal angepasst werden. Der Sprint selbst gibt damit eine feste Timebox vor.
Der Name
Der Name lässt eine kurze starke sportliche Anspannung, genau auf den Punkt vermuten. Das ist aber nicht das, was wir wollen. Wir wollen Teams, die kontinuierlich gute Leistung abliefern können. Also eher einen Staffellauf zwischen Sprints. Auch die Metapher past nicht so ganz. Wie wäre ein Marathon?
Jedenfalls glauben wir, dass die Bezeichnung aus dem Taskforce-Modus stammt, wo aufgezeigt werden sollte, dass das Team nun jetzt einmal kurz konzentriert an einem Thema arbeitet und dies auch zum Erfolg bringt. Wir leiten es daher ab, dass Scrum zum großen Teil ein Destillat aus vielen tausenden erfolgreichen Projekten ist. Diese waren wahrscheinlich häufig in einem Taskforcemodus und dann daraufhin erfolgreich. Agilität ist aber nicht nur alle schneller machen.
Parallelität
Während eines Sprints mache ich nichts anderes nebenbei, sondern arbeite konzentriert auf das Sprintziel hin. Dies ist auch sehr verwandt mit den Prinzipien hinter OKR.
Das Ziel steht fest und ich halte es für einen kurzen Zeitabschnitt stabil. Gerne kann ich mich danach auf ein anderes Ziel hinbewegen. Selbst im selben Projekt ist dies manchmal nötig, da wir dazugelernt haben oder sich die Umwelt verändert hat. Wir arbeiten ja genau aus dem Grund agil. Dementsprechend sollte ich nur ein einziges Ziel zu einem Zeitpunkt haben und im Scrum ist dies eben das Sprintziel, welches für den Sprint stabil bleibt.
Dies gilt natürlich auch für die Personen im Team. Jede Person sollte also nur einen Sprint und damit auch nur ein Ziel haben.
Die Länge
Um hier Vorhersagbarkeit zu wahren ist der Sprint absichtlich kurz. Hier möchte ich noch einmal auf die Folge zur Sprintlänge verweisen.
Im Scrum Guide ist die Länge mit unter einem Monat beschrieben. Klar, je länger der Sprint ist, desto unwahrscheinlicher ist, dass meine Annahmen auch eintreffen werden. Allein das Umfeld wird sich wahrscheinlich auf einen längeren Zeitraum hinweg verändern.
Die kurze Länge senkt also das Risiko enorm. Zudem reduziert eine fixe Länge des Sprints die Komplexität für alle Beteiligten enorm.
Klassisches Projektmanagement
Henry Schneider behauptet gern, dass der Sprint ähnlich einem klassischen Projektmanagement sei. Nur eben sehr viel kürzer. Damit ist gemeint, dass alle wichtigen Projektmanagementelemente im Sprint sind. Der Sprint hat einen festgelegt Start- und Endzeitpunkt. Auch Ressourcen und Umfang sind allokiert. Der Sprint startet mit einem Planning, hat eine Umsetzungsphase und ein Ende mit Lessons-Learned. Vorher natürlich das Rievew. Lastenheft, Pflichtenheft, alles da.
Design-, Technik- und sonstige Sprints
Viele Teams haben spezielle Sprints für spezielle Themen. Hier sind unsere Meinungen zwiegespalten dazu. Eigentlich sollte das alles auch ohne diese konkrete Kapselung und Planung funktionieren. Manchen Teams und vor allem ProductOwnerinnen hilft es allerdings enorm, dass es diese festgelegten Sprints gibt. Beispielsweise jeder vierte Sprint ist ein Techniksprint. Dann wissen die Stakeholder Bescheid. Vor allem ein gutes Mittel, wenn die ProductOwnerin noch nicht so fest im Stakeholdermanagement ist.
Hier auch Vorsicht, häufig bauen Technische Dinge aufeinander auf, so dass dieser eigentlich sequentiellen Sprints bräuchten, statt eines dedizierten.
Der beste Tag
Wann fangen bei Dir die Sprints an? Unser häufig am Montag, da es offenbar für viele Menschen leichter ist in Arbeitswochen von Montag bis Freitag zu denken. Wir würden Sprintstarts in der Mitte der Woche trotzdem bevorzugen, dann ist der Wochenstart nicht so krass und auch das Wissen ist vielleicht nicht weg, welches am Freitag noch in der Retrospektive aufgebaut wurde. Oder die Vorbereitung ist nicht so gut.
Sprintstart also Dienstag, Mittwoch oder Donnerstag könnte eine gute Idee sein.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
