Iteration

Aufgrund der unterschiedlichen Interpretationen einer Iteration lässt sich nicht allgemein festlegen, wie lange eine Iteration dauert oder wie häufig sie sich wiederholt. Entsprechende Festlegungen müssen projektspezifisch getroffen werden.

In Scrum als bekanntestem Vertreter der agilen Softwareentwicklung werden Iterationen als Sprints bezeichnet. Es handelt sich um Ereignisse von fester Länge von einem Monat oder weniger, wobei ein neuer Sprint sofort nach dem Abschluss des vorherigen Sprints beginnt. Theoretisch könnte ein Sprint nur einen Tag dauern, in der Praxis dauert er aber üblicherweise eine Woche, zwei, drei oder vier Wochen. In zahlreichen Publikationen finden sich Hinweise, dass zwei Wochen „üblich“ sind.

Eine solche Vorgabe kennt das V-Modell XT als Vorgehensmodell bundesdeutscher Behörden nicht; dort werden Iterationen im Zuge des Tailorings statisch zum Projektbeginn oder dynamisch im Laufe des Projekts mit zu bestimmenden Zeitintervallen definiert. Die Zeitintervalle richten sich nach den Inhalten – ein wesentlicher Unterschied zu Scrum, denn dort werden die Inhalte so definiert, dass sie sich in den fixierten Zeitintervallen realisieren lassen.

Es kann eine Herausforderung sein, die Dauer einer Iteration zu bestimmen, insbesondere da verschiedene Faktoren unterschiedlich berücksichtigt werden können:

• Der Umfang von kontinuierlich anfallenden Aufgaben. Beispiel: Implementierte Features gilt es zu dokumentieren. Die Dokumentation erfolgt auf Deutsch und muss technisch und semantisch abgenommen werden. Folglich muss die Dauer dieser wiederkehrenden Aktivität bei der Planung der Iterationsdauer berücksichtigt werden. Angenommen die Dokumentation müsste zusätzlich auf Englisch und Spanisch erfolgen. Welchen Einfluss hätte dies auf die Dauer? Würde diese auf 3 Tage ansteigen, oder stehen entsprechende Kapazitäten zur Verfügung und die Aufgaben können parallel durchgeführt werden, so dass zwar der Aufwand, aber nicht die Dauer steigt?
• Die Anzahl der beteiligten Personen oder Parteien. Beispiel: Wie viele Menschen werden bei einem Review involviert? Wie viele Ergebnisse werden von anderen Entwicklungen übernommen? Je mehr Menschen beteiligt sind, desto größer wird der Aufwand und vermutlich auch die Dauer innerhalb einer Iteration.
• Die Verfügbarkeit von beteiligten Personen. Beispiel: Ein wichtiger Stakeholder steht nur einmal in 14 Tagen zur Verfügung. Eine Iterationsdauer von einer Woche erscheint daher sinnlos. Naheliegend wäre eine Dauer von 2 oder möglicherweise 4 Wochen.

Zur Bestimmung der Iterationslänge empfiehlt es sich,

• die Dauer einzelner Aufgaben zu schätzen,
• die Dauer einzelner Events – Scrum definiert bspw. das Sprint Planning, das Sprint Review und die Retrospektive – im Auge zu behalten,
• die Verfügbarkeit von Ressourcen sowie
• Abhängigkeiten zu anderen Projekten oder Entwicklungen zu berücksichtigen, und
• Abstimmungswege und Prozesse zu inkludieren.

Darüber hinaus ist es überaus sinnvoll, im Team ein gemeinsames Gefühl über die „ideale“ Dauer zu entwickeln. Es empfiehlt sich, zu Beginn mit einer etwas längeren Iteration zu beginnen, Erfahrungen zu sammeln, um nach einigen Durchläufen festzustellen, ob die Iteration gut terminiert ist, oder sie verkürzt bzw. verlängert werden sollte.

Im Sinne der Vergleichbarkeit von Ergebnissen ergibt es unabhängig vom genutzten Vorgehen – bspw. Scrum, Kanban, SAFe oder V-Modell XT – Sinn, Iterationen möglichst mit derselben Dauer zu planen. Bei der Vergleichbarkeit geht es aber nicht um einen Wettbewerb mit anderen Teams, sondern um Kenngrößen, die innerhalb eines Teams die zukünftige Aufgabenplanung erleichtern.

• Stehen zentrale Stakeholder auch dann regelmäßig zur Verfügung, wenn sie jetzt einmal pro Woche anstelle einmal in 14 Tagen für die Planung oder ein Review benötigt werden?
• Welche Abhängigkeiten bestehen zu anderen Projekten oder Teilentwicklungen? Bedeutet die geplante Verlängerung von Iterationen, dass andere Bereiche länger als bisher auf Lieferungen warten müssen?
• Wie verändert sich ggf. die Kommunikation mit Kunden?
• Welche Bedeutung hat die Veränderung auf die interne Planung und die teaminterne Vergleichbarkeit der Velocity?

Natürlich empfiehlt es sich, eine solche Entscheidung mit Bedacht zu treffen. Regelmäßige Wechsel – von einer Woche, auf drei Wochen, dann zwei Wochen etc. – sollten aber mit Sicherheit vermieden werden.

Üblicherweise werden Iterationen mit Nummern versehen. Das ist einerseits praktisch und relativ leicht verständlich („Wir entwickeln gerade XY 10.1“), andererseits aber manchmal auch etwas „langweilig“. An sich sind der Kreativität keine Grenzen gesetzt, so dass die Benennung auch mit

• Film- oder Musiktitel,
• Biermarken,
• Künstlernamen,
• Tieren oder
• Charakteren aus Computerspielen

erfolgen kann. Grundsätzlich sollten die Beteiligten bei der Benennung darauf achten, welches Ziel damit verfolgt wird: Interner Spaß, Schaffung einer Gemeinschaft oder Kommunikation mit anderen Bereichen oder gar Kunden?

„Wie weit seid ihr mit Rambo III?“ wirkt unternehmensintern vermutlich lustig, eine Aussage in Richtung Kunde „Leider verzögert sich Rambo III noch etwas“ wirkt vermutlich seltsam. Ergo: Es kommt auf den Zweck an und wer wie mit dem Namen interagiert.

Die sogenannte Velocity ist vermutlich das bekannteste Maß zur Geschwindigkeitsmessung von Iterationen bzw. Sprints. Sie basiert auf realisierten Story Points. Story Points sind eine Einheit zur Beschreibung der Größe einer User Story und repräsentieren den Entwicklungsaufwand und die Faktoren, die diesen Aufwand beeinflussen. Die Velocity ist ein team-internes Hilfsmittel zur Planung und zur Risikokontrolle, das ein gleichmäßiges Tempo adressiert, das Auftraggeber, Entwickler und Anwender über einen unbegrenzten Zeitraum halten können. Es ist kein Maß, um Teams einer Organisation miteinander zu vergleichen. Ein solcher Vergleich würde fast zwangsläufig zu einer Inflation der Story Points führen.

Es gibt eine ganze Reihe von alternativen Metriken wie bspw. die Cycle Time, Mean Time to Repair oder Time to Value.

Zur Beantwortung dieser Frage hilft ein Blick auf die jeweiligen Definitionen:

• Eine Iteration beschreibt einen sich wiederholenden Prozess von ähnlichen oder sogar gleichen Handlungen mit dem Ziel eine definierte Lösung zu realisieren.
• Ein Scrum Sprint ist eine Iteration von gleichbleibender Dauer und ähnlichen Handlungen, sowie dem Ziel, eine definierte Lösung zu realisieren.

Beide Begriffe liegen also sehr nahe beieinander, wobei der Scrum Guide, der die Regeln von Scrum beschreibt, den Sprint mit einer maximalen Dauer von 4 Wochen definiert. Im Vergleich zu traditionell oder klassisch geplanten Vorhaben, deren Iterationen häufig mehrere Monate dauern, ist der Sprint schnell. Es geht darum, in kürzeren Zyklen zu arbeiten, um frühzeitig Feedback von Stakeholdern zu erhalten, und folglich Enwicklungen in die angemessene Richtung zu lenken.

Wie integrieren Sie dies Stakeholder am besten in den Iterationsprozess? Die Antwort lautet:

• frühzeitig und
• kontinuierlich.

Frühzeitiges Feedback hilft Erwartungen abzugleichen und mögliche Fehlentwicklungen zu vermeiden. Kontinuierliches Feedback hilft, ein Produkt zu entwickeln, dass für Stakeholder Nutzen stiftet.

Die Stakeholderkommunikation adressiert den regelmäßigen Austausch eines Unternehmens mit seinen Interessengruppen. Sie unterscheidet sich nach Art, Mittel, Frequenz und Zeitpunkt. Und sie ist sehr wichtig, denn Menschen verfolgen individuelle Ziele. Zwischen den Zielen der einzelnen Anspruchsträger kann es leicht Konflikte geben, umso wichtiger ist das frühzeitige und kontinuierliche Feedback.

Die iterative Planung beschreibt ein Vorgehen, bei dem nicht nur einmalig zu Projektbeginn das gesamte Vorhaben geplant wird, sondern die Planung wiederholt im Laufe des Vorhabens erfolgt. Insbesondere wenn Vorhaben kompliziert und/oder komplex sind, sich also Parameter wie Rahmenbedingungen, Anforderungen, Ziele im Projektverlauf verändern, ist es sinnvoll, entsprechende Erkenntnisse schrittweise zu berücksichtigen. Natürlich ist es auch weiterhin sinnvoll, zu Projektbeginn einen Weg in Richtung des definierten Ziels festzulegen, jedoch erfolgt die Planung einzelner Abschnitte und Aktivitäten iterativ „auf Sicht“, sodass flexibel auf Veränderungen reagiert, Feedback integriert und Ergebnisse kontinuierlich verfeinert werden können.