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

Das Pair Programming Experiment

Vor ein paar Wochen habe ich mit meinem verteilten Team ein Pair Programming Experiment durchgeführt: 2 Entwickler auf 2 Standorten (einer in Graz, einer in Rumänien) haben vier Wochen lang ausschließlich mittels Pair Programming entwickelt – das heißt ca. 160 Stunden Remote Pair Programming!

Ausgangslage:

Mein verteiltes Team hatte sich über die letzten Monate gut weiterentwickelt und an Professionalität gewonnen. Pair Programming war jedoch bis dato noch keine etablierte Praxis im Team. Das wollte ich ändern, da es auch gute Gründe gab die Entwickler zu engerer Zusammenarbeit zu bewegen. Es wurde bis dato nämlich bevorzugt alleine an Tasks zu entwickelt und für meine Begriffe zu wenig kommuniziert. Bei einem unserer Kollegen in Rumänien (Marius) war die Kommunikations-Situation besonders schwierig. Zum einen hatte Marius an seinem Standort in Rumänien keinen lokal arbeitenden Teamkollegen mit dem er sich vor Ort austauschen konnte. Zum Anderen hatte er häufig mit Impediments zu kämpfen, von denen er das Team selten in Kenntnis setzte und stattdessen versuchte selbst Lösungen zu finden. Die folgenden Probleme galt es in dieser Situation zu lösen:

  • Marius war als Einzelkämpfer an einem externen Standort zu wenig in das Team eingebunden
  • Marius kommunizierte seinen Bedarf an Hilfe zu spät ans Team
  • Marius versuchte aufkommende Probleme (meist erfolglos) selbst zu lösen

Idee:

In einer Retro kam mir dann die Idee für das Pair Programming Experiment. Marius solle einen Sprint lang kosequent mit einem in Graz arbeitendem Senior Entwickler (Edwin) ausschließlich Pair Programming machen. Ich wollte damit erreichen, dass die Isolation von Marius beendet und die Kommunikation verbessert wurde. In Folge erhoffte ich mir einen wechselseitigen Wissensaustausch, rasche Lösung von Marius’ Problemen und in Folge eine Leistungssteigerung des Teams. Da Marius selbst merkte, dass er mehr Hilfe benötigte als er selbst anforderte war er mit der Idee einverstanden und auch Edwin fand den Versuch spannend.

Verlauf des Pair Programming Experiments:

Nach wenigen Tagen war bereits klar, dass das Pair Programming zwischen Marius und Edwin seinen Zweck erfüllte. So konnte Edwin in den ersten zwei Tagen eine Vielzahl an Verbesserungen von Marius’ Entwicklungsumgebung und Infrastruktur identifizieren und umsetzen. Es wurde auch viel Smalltalk geführt, was die soziale Isolation von Marius aufbrach und der Motivation zu Gute kam. Durch die enge Zusammenarbeit wurde laufend Wissen zwischen Edwin und Marius ausgetauscht, was einen enormen Lernfeffekt hatte. Am Ende des Sprints konnten wir ein erfreuliches Resümee ziehen: Alle waren sich einig, dass uns das Pair Programming als Team verbesserte. Daher beschlossen wir das Experiment für weitere 2 Wochen fortzusetzen, die unsere Erfahrungen aus den ersten beiden Wochen bestätigen sollten.

Retrospektive:

Nach Ende der 4 Wochen machte ich mit Marius und Edwin eine Retrospektive über das Experiment. Vor allem deren persönliche Befinden, die erzielten Lerneffekte und die Rollenverteilung wärend des Experiments waren für mich interessant zu erfahren.

Rollenverteilung:

Im klassischen Pair Programming wechseln sich die Pairing-Partner regelmässig in den Rollen des Navigators und Drivers ab. Wärend der Driver den Code schreibt, sitzt der Navigator daneben und denkt mit, ohne selbst Code zu schreiben. Edwin sollte Anfangs als der erfahrenere Entwickler vorwiegend Marius’ Arbeitsweise beobachten und ihm Hinweise für Verbesserungen geben. Dadurch war Edwin typischerweise häufiger in der Rolle des Navigators. Durch die Beobachtungen von Edwin konnten rasch Schwächen in der Arbeitsweise und am Environment von Marius identifiziert und behoben werden. Über die gesamte Dauer des Experiments zeigte sich, dass sich Marius mit der Analyse von Problemen etwas schwerer tat als Edwin – er erkannte häufig nicht die Wurzel der Probleme und betrieb damit häufig Symptombekämpfung. War jedoch einmal klar was zu tun ist, war Marius wiederrum sehr effizient beim Code umsetzen. Die persönlichen Stärken und Schwächen der beiden Entwickler haben sich durch das Pair Programming sehr gut ergänzt.

Lerneffekte:

Die folgenden Lerneffekte wurden von Marius und Edwin genannt:

  • Gegenseitige Verbesserung der Programmierskills, durch engen Austausch und Beobachtung der anderen Arbeitsweise
  • Marius’ Schwächen in der Analyse konnte durch Edwins Analyse-Stärken kompensiert werden
  • Environment Probleme von Marius konnten identifiziert und gefixt werden, da mit Edwin’s System ein Vergleichsystem verfügbar war
  • Vor allem bei komplexen Tasks zeigte sich Pair Programming für beide effizienter
  • Kommunikations-Barriere minimierte sich durch den dauerhaft offenen Kommunikationskanal zwischen Graz und Rumänien

Persönliches Empfinden:

Marius und Edwin nannten folgende Punkte zu ihrem persönlichen Empfinden wärend des Experiments:

  • Sozial hat die Zusammenarbeit zwiscehn den beiden sehr gut harmoniert
  • Pair Programming half einen hohen Fokus auf die Arbeit zu halten
  • Durch die gemeinsame produktive Arbeit blieb die Motivation dauerhaft hoch
  • Für Marius wurde soziale Nähe zum Team geschaffen (Privatgespräche, Smalltalk,…)
  • Für Marius war die Identifikation mit dem Team höher
  • Das Dauer-Pair-Programming war für beide anstregend aber überzeugend

Conclusio:

Mein Resümee aus dem Experiment ist, dass Pair Programming verteilt mit den richtigen Tools genauso effizient eingesetzt werden kann, wie für lokale Teams. Voraussetzung ist allerdings die Bereitschaft des Teams, konsequent die Praktik umzusetzen sowie die soziale Verträglichkeit der Pairing Partner. Ein akuter Anlassfall bietet immer eine gute Möglichkeit für eine Veränderung, wie die Einführung einer neuen Programmier-Praktik. Tituliert man eine Veränderung als Experiment oder Versuch, so ist der Widerstand des Teams meist geringer, da der Versuch noch keine Verbindlichkeit erzeugt. Implizites Wissen (z.B. Erfahrung), das nicht durch Schulungen transportiert werden kann, lässt sich hervorragend über Pair Programming vermitteln.