Scrum spricht bei der Dauer eines Sprints von einer Woche bis zu einem Monat. Die meisten Teams und Unternehmen haben sich bei 14 Tagen eingependelt, weil das der beste Kompromiss zwischen dem Wunsch nach kurzen Entwicklungseinheiten und der Furcht vor überhandnehmenden Planungssitzungen zu sein scheint. Aber sind zwei Wochen immer die ideale Sprintlänge?
Die Antwort ist das übliche »Es kommt darauf an«, und wahrscheinlich habt ihr auch genau das erwartet, also sollten wir die Sache etwas genauer auseinandernehmen, damit Ihr Euer Projekt und Euer Team etwas besser einordnen könnt.
Was möchten wir eigentlich mit den Sprints erreichen?
Scrum soll uns dabei helfen, das Agile Prinzip aus kontinuierlichem Lernen aus Erfahrung zu leben. Dafür sind feste Iterationen vorgesehen, an deren Ende wir unsere Ergebnisse mit dem Kunden / Anwender durchleuchten und aus deren Feedback weitere Schlüsse ziehen (ganz kurz zusammengefasst). Zusätzlich wollen wir aber auch Planungssicherheit schaffen, indem wir in kleineren Einheiten denken und eine sehr genaue Vorhersage für das Ergebnis am Ende eines Sprints treffen können.
Diese beiden Dinge gehen Hand in Hand. Wenn ich nach einem Arbeitsintervall – also nach einer Iteration – mit dem Kunden zusammenkomme, möchte ich sehr konkret sprechen können. Je größer das präsentierte Arbeitspaket ist, desto oberflächlicher werde ich in meiner Diskussion sein (müssen), weil ich in der nötigen Tiefe, um wirklich etwas daraus lernen zu können, nicht auf so viele Dinge gleichzeitig eingehen kann.
Für unsere Überlegung, wie lang ein Sprint sein sollte, ist das demnach unser erster Anhaltspunkt: wie detailliert will oder muss ich mit meinem Kunden sprechen? Je tiefer ich einsteigen möchte, desto kleiner die jeweiligen Arbeitspakete und desto häufiger der Austausch.
Natürlich ein kurzes Wort der Warnung: ich kann das auch übertreiben. Wenn ich zwei Stunden lang darüber diskutiere, ob ein Button drei Pixel zu weit links oder rechts steht, dann läuft offensichtlich irgendwas schief. Lacht jetzt nicht. Das passiert häufiger als ihr denkt, oder habt ihr etwa noch nie in so einem Meeting gesessen, in dem wir uns in endlosen völlig unwichtigen Detaildiskussionen verloren haben?
Ich möchte für meinen regelmäßigen Austausch mit meinem Kunden genau die Größe eines Arbeitspakets schaffen, die groß genug ist, echten Fortschritt zu zeigen, aber auch klein genug ist, detailliert genug sprechen zu können, um sinnvoll verwertbares Feedback zu generieren, ohne mich in allgemeinen Plattheiten zu verlieren.
Als zweiten Aspekt möchten wir Planungssicherheit erhalten. Die brauchen wir sowohl für die Zusammenarbeit mit dem Kunden als auch für die Zusammenarbeit mit anderen Einheiten in unserer eigenen Organisation. Dabei werden zwei Teilaspekte relevant: zum einen, wie hoch der Innovationsgrad meines Projekts ist, zum anderen die Erfahrung meines Teams mit dieser Form der Planung.
Und den zweiten vergessen wir sofort wieder. Die Erfahrung meines Teams ändert sich zu schnell. Wenn ich meinem Team einen Gefallen tun will und wir einen sehr kurzen Planungsintervall schaffen, hat das Team nach drei oder vier Durchläufen genug über sich selbst gelernt, um mit dieser Planung gut umgehen zu können. Das Argument für den kurzen Planungszyklus ist damit weg. Und nun?
Unsere Sprints sind über einen längeren Zeitraum konstant. Das bedeutet nicht, dass wir nicht irgendwann von einer auf zwei Wochen Iterationsdauer switchen können – das ist möglich, wenn es einen guten Grund dafür gibt, und wenn es eine bewusste Entscheidung ist. Es bedeutet aber sehr wohl, dass wir nicht alle drei Sprints unsere Sprintlänge ändern. Planungssicherheit werde ich so nämlich nie erreichen, und für die Zusammenarbeit mit dem Kunden ist das auch nicht wirklich Gold.
Der Innovationsgrad meines Projekts ist allerdings ungleich wichtiger. Je besser ich meine Anforderungen und die dazugehörigen Tätigkeiten kenne, desto mehr Erfahrungswerte habe ich, und desto besser kann ich auch in die Zukunft schauen. Sagen wir mal, wir erstellen ein Produkt, das wir in sehr ähnlicher Form schon einmal gebaut haben. Vielleicht können wir uns sogar sehr sicher sein, dass sich die Anforderungen nicht großartig ändern werden. Vielleicht weil der Zielmarkt extrem stabil ist. Wir nutzen bewährte uns gut bekannte Technologien, und alle anderen Aspekte, die Stabilität bringen, sind auch abgehakt. In einem solchen Projekt spricht wahrscheinlich sehr wenig gegen ein Vier-Wochen-Intervall, weil hier auch der Austausch mit dem Kunden aller Wahrscheinlichkeit nach nicht jedes Mal viele neue Erkenntnisse bringen wird.
Machen wir uns nicht viel vor: solche Projekte gibt es, und ich muss nicht Innovation um ihrer selbst willen um jeden Preis in jedes Projekt quetschen.
Am anderen Ende der Skala haben wir Projekte mit größten Unsicherheiten und vielen Unbekannten. Hier müssen wir uns fast alles neu erarbeiten. Der Kunde weiß genauso wenig wie wir, und alle Technologien sind neu. In so einem Projekt haben wir naturgemäß sehr viel Diskussionsbedarf. Hier kann es sinnvoll sein, wöchentlich mit dem Kunden zusammenzukommen und auch in Wochenintervallen zu planen.
Das Argument, das uns am häufigsten begegnet, hat allerdings nichts mit den Anforderungen des Projekts selbst zu tun, sondern bezieht sich ausschließlich auf den zeitlichen Aufwand für Planning, Review usw.
Ist relativ kurzsichtig, oder?
Natürlich werden die einzelnen Events kürzer, wenn auch der Sprint kürzer wird, das ist jedoch nicht komplett linear. Wenn ein Planning für zwei Wochen 90 Minuten dauert, dann bin ich wahrscheinlich für einen einwöchigen Sprint nicht nach 45 Minuten fertig, eher nach 60 oder so.
Ich bin jedoch bereit, in der Gesamtheit zwei Stunden mehr zu investieren, wenn das zu erwartende Ergebnis dies rechtfertigt. Ich möchte, dass wir eine bewusste Entscheidung treffen. Wir sprechen bei einem einwöchigen Sprint vielleicht über zwei Stunden Mehraufwand für Besprechungen und Events für das gesamte Team. Bei acht Personen sind das 16 Stunden. Damit ist das ein richtig teures Vergnügen. Ich darf das Argument nicht einfach wegwischen. Das wäre unternehmerisch höchst fahrlässig.
Auf der anderen Seite befinden wir uns aber in einem hohem Innovationsgrad, d.h. wir haben sowieso einen erhöhten Diskussionsbedarf. Und seien wir ehrlich: sprechen müssen wir sowieso in der einen oder anderen Form miteinander. Ob wir das im Rahmen eines einen Plannings oder Refinements tun, oder irgendwann zwischendurch – der Aufwand bleibt gleich.
Worauf ich hinaus will: Wir treffen eine bewusste Entscheidung, und auch den Jungs und Mädels aus dem Controlling können wir das genau so erklären. Es ist uns klar, dass wir einen höheren Aufwand treiben, der Innovationsgrad des Projekts erfordert dies jedoch. Das Controlling ist nicht unser Feind. Es hat durchaus Sinn, dass wir ab und zu daran erinnert werden, auch kostenbewusst zu denken.
Sprints von zwei Wochen Länge haben sich in den meisten Teams durchgesetzt, weil sie ein guter Kompromiss sind. 14 Tage lassen sich mit recht großer Sicherheit planen, ohne zu kleinteilig zu werden. Meine Empfehlung, wenn Ihr sehr unsicher seid und gerade starten wollt, ist also folgende: Mit einer Sprintlänge von zwei Wochen seid Ihr im allgemeinen sehr gut unterwegs. Wenn Euer Projekt einen extrem hohen Innovationsgrad hat, denkt über einwöchige Sprints nach. Wenn Euer Projekt extrem stabil und gut bekannt ist (weil Ihr das schon zum fünften Mal macht), dann denkt vielleicht Richtung längerer Sprint. Drei Wochen sind schräg, also lieber gleich vier.
Das mit der Monatslänge vergesst auf jeden Fall ganz schnell wieder. Wir möchten immer am selben Wochentag unsere Sprints enden und starten lassen. Wenn das einmal Montag und einmal Freitag ist, müssen wir immer wieder neu diskutieren, wann wir dies und wann wir jenes tun. Jede Planung in jeder Organisation ist auch Wochentage ausgerichtet. Montags passieren bestimmte Dinge und Freitags passieren bestimmte andere Dinge. Das sollten wir nicht durchbrechen.
Kernaussagen: Je höher der Innovationsgrad des Projekts, desto kürzer die Sprints. Zwei Wochen sind in den meisten Teams und Organisationen ein guter Kompromiss zwischen Planungssicherheit und Diskussionsbedarf. Kürzere Sprints können bei extrem viel Unklarheiten im Projekt angebracht sein. Längere Sprints sind empfehlenswert, wenn wir sehr viel Vorwissen haben und Anforderungsänderungen nur selten zu erwarten sind.
Wenn Ihr mehr Fragen habt, oder in Eurem Projekt bzw. Eurer Organisation Unterstützung braucht, sprecht einfach mit mir.
