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.

Erfolgreiche Meetings planen

Was ist eigentlich ein “erfolgreiches Meeting”? – nun ich würde sagen das hängt davon ab, was man sich von einem Meeting erwartet. Für ein erfolgreiches Meeting ist es also essentiell die erzeugte Erwartungshaltung zu erfüllen. Die Planung im Vorfeld spielt da eine wesentliche Rolle.

Eine große Hilfe bei der Planung meiner Meetings war mir u.A. das Buch Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Dave Gray, Sunni Brown und James Macanufo beschreiben darin das 7 P’s Framework zur Meeting Vorbereitung:

  • Purpose: Welchen Zweck hat das einberufene Meeting? Durch einen klaren Zweck werden die Teilnehmer motiviert und dem gemeinsamen Zusammensitzen wird ein Sinn gegeben.
  • Product: Was soll in dem Meeting produziert werden? Mit welchem “Produkt” verlassen wir das Meeting? Die klare Kommunikation der Zielvorstellung ist wesentlich um zu jedem Zeitpunkt im Meeting den Fokus zu erhalten.
  • People: Wer muss am Meeting teilnehmen um das gewünschte Ziel zu erreichen? Welche Personen teilnehmen sollen ergibt sich aus dem Zweck und der Zielvorstellung. Es ist außerdem wichtig, dass allen Personen deren Rolle im Meeting klar ist.
  • Process: Der Ablauf des Meetings wird über die Agenda festgelegt. Diese dient vorab um den Teilnehmern den Inhalt grob zu vermitteln und während des Meetings um den “Fahrplan” einzuhalten.
  • Pitfalls: Jedes Meeting birgt individuelle Gefahren in sich. Sind die Räumlichkeiten geeignet? Gibt es die notwendige Infrastruktur? Gibt es “schwierige” Persönlichkeiten im Meeting? Es ist daher wichtig die Gefahren im Vorfeld abzuklären.
  • Preparation: Was muss vor dem Meeting noch alles erledigt werden? Darunter fällt das Vorbereiten der Präsentationsunterlagen (Flip-Charts, Folien, Ausdrucke,…) sowie alle weiteren Aufgaben, die vor dem Meeting erledigt werden müssen.
  • Practical Concerns: Wann und wo wird zu Mittag gegessen? Wer ist für die Raumreservierung verantwortlich? Jedes Meeting bedarf eines logistischen Aufwands. Dieser kann sehr unterschiedlich sein, sollte jedoch nicht vergessen werden.

Ich beachte bei jedem Meeting die 7 P’s und mache diese auch den Teilnehmern vorab transparent. Damit habe ich bisher sehr gute Erfahrungen gemacht und kann diese Praxis nur jedem weiterempfehlen.

Zum Thema “erfolgreiche Meetings” bin ich vor Kurzem auch auf einen Blogpost von Olga Repnikova von Borisgloger.com gestoßen, den ich hier noch aufgreifen möchte. Olga Repnikova unterscheidet darin 3 Ebenen der Meeting Vorbereitung:

  • Inhaltliche Vorbereitung: Hier geht es, wie der Name schon sagt, um die Definition der Inhalte und der Zielsetzung des Meetings. Leitfragen: Handelt es sich um ein Review- oder Planungsmeeting?, Geht es um Informationsaustausch und Diskussion oder sollen bereits Entscheidungen getroffen werden?, Welche Themen werden zur Sprache kommen?, Wie bin ich für die Themen vorbereitet?,…
  • Methodische Vorbereitung: Hier geht es um die Definition des Regieplans. Jedes gute Meeting hat einen spannenden Einstieg, flüssige Übergänge zwischen den Themen und einen klaren Abschluss. Leitfragen: Wie gestalte ich den Einstieg?, Wie ermögliche ich Überleitungen zwischen den Themen?, Wie schließe ich das Meeting?, Wann sind Pausen geplant?, Ist die Teilung der Gruppe erforderlich?,…
  • Organisatorische Vorbereitung: Die organisatorische Vorbereitung beinhaltet die Definition der Räumlichkeiten, Personen, Zeit, Medien, usw für das Meeting. Leitfragen: Welche Personen müssen eingeladen werden?, Wann soll die Einladung raus gehen?, Gibt es eine Teilnehmer-Mindestanzahl?, Ist das Meeting an eine bestimmte Person geknüpft?,…

Ich persönlich präferiere die 7 P’s von Gray, Brown und Macanufo zur Meetingvorbereitung, da diese meiner Meinung die ktitischen Punkte der Meeting-Planung klar hervorheben jedoch finde ich die 3 Ebenen von Repnikova eine gute Ergänzung um die Meeting-Planung auf den unterschiedlichen Ebenen klarzumachen.

Wie plant ihr eure Meetings? Was sind eure Erfahrungen, was erfolgreiche Meetings ausmacht?