Verteilte Sprint Planung

Ich habe in einem früheren Blogpost bereits über die Agile Planung geschrieben. In diesem Blogpost möchte ich auf die Besonderheiten der Sprint Planung mit meinem verteilten Team eingehen. Mit lokal arbeitenden Teams habe ich die Sprint Planung immer wie folgt abgehalten:

Standard Sprint Planung:

Ich unterteile die Sprint Planung für gewöhnlich in zwei Teile:

Sprint Planung 1 (SP1):

  • Leitfrage: Was soll gemacht werden?
  • Teilnehmer: PO, SM, Gesamtes Entwicklerteam
  • Output: Commitment des Teams

Sprint Planung 2 (SP2):

  • Leitfrage: Wie setzen wir die User Story um?
  • Teilnehmer: Gesamtes Entwicklerteam, SM (optional)
  • Output: Technische Tasks

Dieser Modus wird von Boris Gloger empfohlen und funktioniert für meine Teams meist sehr gut. Für mein verteiltes Team habe ich jedoch das SP2 kleineren Änderung unterzogen.

Motivation zur Veränderung:

Das SP2 kann mitunter über mehrere Stunden dauern und erfordert intensive Denkarbeit der Beteiligten. Vor allem bei meinem verteilten Team war es schwierig die Aufmerksamkeit der Entwickler auf Dauer hoch zu halten. Folge war, dass nur wenige (meist immer die selben) Entwickler den Großteil der Denkarbeit erledigten. Dementsprechend war auch das Verständnis der erstellten Lösung  sehr unterschiedlich, was wiederrum im Sprint zu Produktivitätseinbußen führte. Ich beobachtete folgende Faktoren, die mit dem Phänomen des “Sozialen Faulenzens” in Zusammenhang stehen:

  • Fehlende Identifikation mit der Firma / dem Produkt (Off-shoring)
  • Unterschiedlich stark ausgeprägtes Fachwissen der Entwickler
  • Geringes Fachwissen bei externen Mitarbeitern (Off-shoring)
  • Kulturelle Unterschiede im Team
  • Niedriger Bekanntheitsgrad der Teammitglieder
  • Fehlende Präsenz des Scrum Masters im SP2

Verteilte Sprint Planung:

Um dem Problem zu begegnen haben wir den Modus des SP2 etwas abgeändert. Grundidee war nicht mehr das gesamte Team alle User Stories sequentiell ausarbeiten zu lassen, sondern zuerst in kleineren Sub-Teams (2-3 Entwickler) Designvorschläge auszuarbeiten, die danach mit dem gesamten Team diskutiert wurden. Wir unterteilten das Meeting also in folgende Abschnitte:

  • Designvorschlag ausarbeiten: Die ersten Designvorschläge wurden parallel von Sub-Teams ausgearbeitet (je 2-3 Entwickler). Jedes Sub-Team arbeitete an Designs für andere User Stories. Time-box: 1 – 1,5 h
  • Präsentation & Diskussion: Die Designvorschläge wurden den anderen Sub-Teams präsentiert und diskutiert
  • Einigung: Das gesamte Team einigte sich für jede User Story auf eine Lösung
  • Tasks erstellen: Das gesamte Team schrieb die Tasks für die User Stories

Erzielte Verbesserungen:

Die folgenden Verbesserungen konnten in der Folge erzielt werden:

  • In den kleineren Sub-Teams beteiligten sich alle an der Lösung (“Soziales Faulenzen” wurde deutlich minimiert)
  • Die Designvorschläge wurden noch einmal von den anderen Sub-Teams “gechallenged”, was die Designs robust machte
  • Die Motivation der Entwickler war in den Sub-Teams als auch in den Diskussionen höher als im alten SP2 Modus
  • Die Lösungen wurden vom gesamten Team verstanden
  • Das Team fühlte sich im SP2 produktiver

Agile Planung

Seit längerem komme ich wieder dazu einen Blogpost zu schreiben. Es hat sich einiges an Posting-Material in den letzten Monaten angesammelt. Das heutige Thema ist Planung in der agilen Welt.

Kent Beck und Martin Fowler sagen dazu in “Planning Extreme Programming” folgendes:

“We plan to ensure that we are always doing the most important things left to do, to coordinate effectively with other people, and to respond quickly to unexpected events”

In der Praxis zeigt sich immer wieder wie wichtig es ist, den Spagat zwischen Planung und Agilität zu schaffen. Als Scrum Master sehe ich vor allem die Herausforderung der Sprintplanung. Auch im Sprint gilt nämlich: Spät entdeckte Planungsfehler sind teuer!

In meinen Scrum Teams teilen wir das Sprint Planning in 2 Teile:

Sprint Planning 1 (SP1)

Leitfrage: WAS soll in diesem Sprint umgesetzt werden?

Fokus: Fachlich (Business Value, Kundensicht)

Outcome:

  • Fachlich, einheitliche Sicht auf die einzelnen User Stories, die im Sprint Planning vom Product Owner vorgestellt wurden
  • Commitment des Teams, welche User Stories es im Sprint umsetzen kann

Sprint Planning 2 (SP2)

Leitfrage: WIE sollen die im Commitment enthaltenen User Stories umgesetzt werden?

Fokus: Technisch (Design, Architektur)

Outcome:

  • Technisches Design für die im Commitment enthaltenen User Stories
  • Tasks, welche alle Aufgaben zur Umsetzung der User Stories umfassen

Wie immer, sieht die Theorie einfacher aus, als die praktische Umsetzung dann tatsächlich ist. Folgende Probleme treten in der Praxis in der Sprint Planung auf:

Problem Lösungsvorschlag
Im SP1 sind noch fachliche Anforderungen des Kunden unklar. Jene User Stories, die noch unklar sind nicht in das Commitment aufnehmen. Der PO muss sich um die Klärung der Anforderungen erst kümmern. Es macht keinen Sinn diese User Stories zu beginnen!
Für das technische Design ist zu wenig Know-how im Team vorhanden. Architekten, Know-how Träger aus der Domäne zum SP2 einladen.
Im SP2 wird das Design nur oberflächlich geplant. Konkreten “Desired Outcome” für das SP2 festlegen: z.B.: UML Klassen-Diagramme, Interface-Beschreibungen, Tracer Bullets, Tasks < 8h, Codestellen gemeinsam inspizieren, Offene Fragen wenn möglich gleich im SP2 klären.
Für das technische Design ist zu wenig Know-how im Team vorhanden. Architekten, Know-how Träger aus der Domäne zum SP2 einladen.
Das SP2 verläuft unproduktiv. Jeder Entwickler moderiert für eine User Story das SP2, Pausen machen wenn keine Energie mehr vorhanden ist, Jede User Story einzeln planen.
Im SP2 wurden Tasks vergessen aufzuschreiben. Für jede User Story einen abschließenden Check machen, ob alle Tasks für die vollständige Implementierung (+ Tests) der User Story vorhanden sind.
Während der Implementierung (Sprint) herrscht Unklarheit über den Scope der einzelnen Tasks. Wording der Tasks im SP2 genau besprechen, Besser 2 speziellere Tasks statt einen generischen Task aufschreiben, Falls die übliche Taskbeschreibung nicht ausreicht um die Semantik zu klären, eine erweiterte Beschreibung hinzufügen.