Scrum Sprints verständlich erklärt – Warum Iterationen Sinn ergeben

Manche Teams fragen mich, warum es in Scrum eigentlich Sprints gibt und ob solch eine künstliche Einteilung in Wochenrhythmen überhaupt mit der Arbeit eines Teams vereinbar ist?

Prinzipiell ist ein Sprint ein gleich langer sich regelmäßig wiederholender Zeitabschnitt eines Scrum Teams, um Feedback zu ritualisieren.

Schauen wir uns an, was dieses ritualisierte Feedback in einem Softwareprojekt bringt:

Von der “Black Box Entwicklungsabteilung” zum Vertrauensverhältnis durch Kundennähe

Die Sprintplanung gibt dem Product Owner und damit auch dem Kunden eine Vorschau, was das Team in der kommenden Iteration schaffen möchte. Zum Sprintende folgt dann das Review-Meeting, in dem Stakeholder wie Kunde, Anwender, Management und Team zusammenkommen.

Durch die dort entstehende regelmäßige Transparenz über Liefergegenstände und Gespräche von Angesicht zu Angesicht wird Fortschritt erlebbar und Hintergründe von Entscheidungen oder Verzögerungen verständlich. Es entsteht eine Diskussions- und Vertrauensbasis zwischen Kunde und Team.

Weniger unfertige Arbeit

Ein Team, dass früher Feedback vom Kunden erhält, weiß schneller, ob eine Funktion so gelungen ist, dass Sie das Bedürfnis des Kunden tatsächlich deckt. Damit werden Features schneller “als fertig” abgehakt und weniger unfertige Arbeit ist gebunden, die im Kopf der Teammitglieder den Fokus und das Gefühl von Fortschritt verhindert. Wer mag schon haufenweise unerledigte Dinge in seinem Hinterkopf?

Kostengünstigere Fehlerbehebung

Wer Software entwickelt, produziert auch Fehler. Das ist normal und Teil des Handwerks. Gerade deshalb sollten wir mit diesem Wissen unser Möglichstes tun, um sie dann so günstig wie möglich zu finden und zu korrigieren. Günstig bedeutet in diesem Fall, das ein Fehler um so weniger Geld kostet, um so schneller wir ihn finden. Am besten noch vor der Produktivsetzung. Hierfür haben wir viele Mittel in der Softwareentwicklung wie z.B. Automatische Tests, Code Reviews oder auch Pair Programming. Ein Sprint ist eine Qualitätsschranke, die uns ritualisierte Qualitätskontrollen ermöglicht, in einem Rahmen der so zeitnah ist, dass ich als Entwickler tatsächlich noch wissen kann, in welchem Kontext der Fehler steckt. Besser jetzt gleich nochmal an den Quelltext als in zwei Monaten, oder?

Wissen, wann welches Feature kommt

Softwareentwicklung findet immer für Menschen statt, die Erwartungen an unsere Produkte und Lösungen haben. Ein Teil dieser Erwartungen ist zeitlicher Natur: Wann kann eine Software dies oder jenes? Wann wird mein Kundenfeedback umgesetzt? Wie lange muss ich mit einem Fehler noch leben?

Auf diese Fragen braucht ein Product Owner zuverlässige Antworten, um glaubwürdig zu sein. Sprints ermöglichen es einem Scrum-Team, Daten über die bisherige Produktionsleistung zu ermitteln und diese in die Zukunft fortzuschreiben. So wird eine Roadmap zur Basis des Erwartungsmanagements. Versetzen wir uns mal in die Sicht des Kunden: Wieviel Transparenz würden Sie als Kunde über den Fertigstellungszeitpunk Ihres Features gerne haben?

Niedrigerer Koordinationsaufwand

Und zu guter Letzt spart ein Sprint auch noch Koordinationsaufwand durch regelmäßig festgelegte Termine für alle Beteiligten und somit planbare Räumlichkeiten, Teilnehmer und Ergebniserwartungen.

Vereinbarkeit von Sprints und Arbeitsinhalten

Doch wie teile ich nun meine Arbeit so auf, dass ich sie in Sprints umsetzen kann? In der Essenz geht es darum, Features richtig zu zerteilen und somit kleinere, abgeschloßene Einheiten zu produzieren.

Ein Bild sagt mehr als tausend Worte

Eine graphische Übersicht dieser Aspekte finden Sie auch auf meinem Teamraum – Poster (PDF; 8 MB).

Sie können es zum Beispiel auf Postergröße ausgedruckt im Teamraum aufhängen, um mit Ihren Kollegen darüber zu sprechen, warum wir in Scrum iterativ arbeiten und was Team und Unternehmen davon haben.

Oder ergänzen Sie es doch noch in einer Retrospektive mit dem Team um neue Aspekte mit Haftnotizzetteln, weshalb Sprints einfach Sinn ergeben?