Do’s and don’ts bei der empirischen Prozesssteuerung in Scrum

Sichtbarkeit, Inspektion und Anpassung, das sind die drei Handlungsfelder der empirischen Prozesssteuerung, welche Scrum nutzt um komplexe Produkte erfolgreich zu entwickeln.

Die Sichtbarkeit und ein team-übergreifendes Verständnis der Artefakte sind Voraussetzung für eine erfolgreiche Inspektion. Die Inspektionen finden kontinuierlich statt, um Abweichungen möglichst bald zu identifizieren und mit Aktionen entgegen zu steuern. Welche Aktionen für eine Anpassung geeignet sind, ist jedoch nicht immer eindeutig. Angenommen, das Entwicklungsteam scheitert regelmäßig daran das Sprint Backlog vollständig abzuarbeiten. Basierend auf der Inspektion sind folgende weniger-zielführende Aktionen (Don‘ts) und mögliche sinnvolle Aktionen (Do’s) möglich:

Sprintdauer

Don’t: Die Sprintdauer verlängern, so dass das Entwicklungsteam mehr Zeit zur Abarbeitung des Sprint Backlogs hat!
Warum? Allgemein ist zu sagen, je größer die Zeitkomponente, desto schwieriger die Planung, da Wahrscheinlichkeit von Ungewissem steigt. Abbildung 1 visualisiert die Schere möglichen Outputs von User Story über Zeit.

Do: Alternativ kann die Sprintlänge verkürzt werden, um früher zu erkennen und zu verstehen, wo das tatsächliche Problem liegt. Allgemein sollte ein mehrmaliges Ändern der Sprintlänge vermieden werden, da das Team sonst den Sprint-Rhythmus verliert.

Entwicklungsteam

Don’t: Unter Zeitdruck das Entwicklungsteam mit einem weiteren Entwickler aufstocken.
Warum? Falls nicht grundsätzliche Kompetenzen im Entwicklungsteam fehlen, ist eine Aufstockung nicht sinnvoll. Ein Entwicklungsteam durchläuft die Team-Building-Phasen in folgender Reihenfolge: Forming->Storming->Norming->Performing. Ein neues Team-Mitglied würde das Team wieder in die Forming-Phase zurück-katapultieren, egal in welcher Phase sich dieses gerade befindet.
Do: In der Retrospektive gemeinsam erforschen, was die tatsächlichen Ursachen sind.

Sprint Planning

Don’t: Die Definition of Ready und Definition of Done abschwächen.
Warum? Qualität vor Quantität. Wir wollen keine technische Schuld aufbauen, die wir später teuer zahlen müssen.
Do: Wenige Sprint Backlog Items mit guten Akzeptanzkriterien, als viele Sprint Backlog Items mit schwachen Akzeptanzkriterien. Akzeptanzkriterien sind das Bindeglied von User Stories zum Testen und bestimmen somit die Qualität des Produktinkrements.

Daily

Don’t: Daily entfallen lassen, um mehr Zeit fürs Entwickeln zu haben.
Warum? Das Daily ermöglicht ein tägliches Inspect & Adapt.
Do: Überprüfe die Transparenz! Werden Hindernisse beim Daily wirklich ausgesprochen und basierend darauf Aktionen abgeleitet?

Retrospektive

Don’t: Bei jeder Retrospektive die gleiche Vorgehensweise wählen.
Warum? Es gibt verschiedene Möglichkeiten eine Retro durchzuführen. So kann eine Retro-Methode Impediments aufzeigen, die vielleicht bei einer anderen Methode nicht gefunden worden wären.
Do: Nicht jedes Mal die gleiche Retro, sondern abwechselnde Retros.

Taskboard

Don’t: Das Taskboard nicht inspizieren.
Warum? Das Taskboard visualisiert neben dem Arbeitsfortschritt auch die Arbeitsweise des Entwicklungsteams. Abbildung 2 zeigt, dass das Entwicklungsteam die Priorisierung von Tasks nicht berücksichtigt und neue Tasks beginnt, bevor begonnene Tasks abgeschlossen worden sind.

Do: Die Abarbeitungsreihenfolge von Stories beachten. Allgemein eine Story abschließen, bevor eine Neue begonnen wird.

Impediment-Liste

Don’t: Keine Impediment-Liste führen.
Warum? Die Impediment Liste ist laut Scrum Guide kein Artefakt, jedoch hat sich diese in der Praxis bewährt! Möglicherweise ist das Hindernis, welches zum regelmäßigen nicht-erfolgreichen Abarbeiten des Sprint Backlogs führt bereits identifiziert worden und befindet sich auf der Impediment Liste.
Do: Die Impediment Liste sichtbar halten und abarbeiten.

Scrum-but

Don’t: Eine Veränderung des Frameworks in der Einführungsphase.
Warum? Jedes Element in Scrum hat eine Funktion und eine Veränderung oder das Weglassen von Elementen in der Einführungsphase könnte den Nutzen und die Verbesserungen, die durch den Scrum-Einsatz erzeugt werden können, abschwächen. Beachte jedoch, dass Scrum sich stetig weiterentwickelt. Während im Scrum Guide von 2011 das Sprint Planning Meeting aus zwei Events (What/How) besteht, ist in der Scrum Guide Version 2013 nur mehr ein Sprint Planning Event vorgesehen.
Do: Befolge das Shu-Ha-Ri Prinzip! Follow the rule (Shu), break the rule (Ha), be the rule (Ri). Bevor man Änderungen am Scrum Framework vornimmt, sollte man dieses vollständig beherrschen.

Die Liste an Don’ts & Do‘s Aktionen ist nicht vollständig, sollte jedoch einen guten Einblick geben, wie wichtig es ist:

• Sichtbarkeit von Artefakten zu gewährleisten
• Abweichungen richtig interpretieren
• Abweichungen eine oder mehrere Ursachen haben können
• Alle möglichen Aktionen zur Anpassung zu identifizieren
• Identifizierte Aktionen und deren Auswirkungen gegenüberzustellen
• Sorgfältig Aktionen zur Anpassung auszuwählen