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.

Tools für verteilte Teams

Seit 13 Monaten bin ich nun Scrum Master eines verteilten Teams – Ich habe vor Kurzem darüber berichtet. Ich möchte in diesem Blogpost nun auf die unterstützenden Tools, die für die verteilte Entwicklung notwendig sind, genauer eingehen. Welche Tools gebraucht werden hängt sehr stark von der konkreten Projekt- und Team-Situation ab. Ma sollte sich zu Beginn die Anforderungen an die unterstützenden Tolls definieren.

Unsere Anforderungen:

  • Alle verwendeten Tools müssen unter Windows und Linux laufen (MUST)
  • 3 Standorte müssen an Meetings teilnehmen können (MUST)
  • 7 verteilte Hosts müssen an verteilten  Meetings teilnehmen können (MUST)
  • Die Auflösung bei Scrennsharing muss für Pair Programming und Code Reviews ausreichend hoch sein (MUST)
  • Ein virtuelles Taskboard soll ein physikalisches Board ersetzen (MUST)
  • Tasks, Defects, User Stories müssen gesammelt an einem Ort verwaltete werden (MUST)
  • Das Online Meeting Tool muss als Service (ohne Wartungsaufwand) verfügbar sein (MUST)
  • Die Kontrolle für das Screensharing sollte übergeben werden können (SHOULD)
  • Meetings sollten von unterschiedlichen Standorten und Computern gehostet werden können (SHOULD)

Ich bin bei der Auswahl der Tools (ganz im Sinne von agilem Vorgehen) nach dem “Trial and Error” Ansatz vorgegangen. Im Laufe der 13 Monate haben wir fast 40 Tools recherchiert, verglichen und die Vielversprechendsten vertieft auf ihre Praxistauglichkeit getestet. Für unsere Rahmenbedingungen haben sich folgende Tools als “die Besten” herausgestellt:

Meine Auswahl an Tools für die verteilte Entwicklung:

Taskverwaltung / Virtuelles Taskboard:

Für verteilte Teams sollte immer ein virtuelles Taskboard verwendet werden, da es ortsunabhängig über den Browser zugegriffen werden kann. Physikalische Boards in Kombination mit virtuellen Boards haben sich nicht bewährt, da die Boards manuell synchron gehalten werden müssen, was fast unmöglich ist. Auch das Sharing eines physikalischen Boards über Kameras ist äußerst umständlich und daher nicht zu empfehlen. Unsere Wahl ist letztlich auf folgende Tools gefallen:

  • Jira + Greenhopper Plugin wurde bereits in unserer Firma eingesetzt und für gut befunden. Weitere Recherchen wurden daher nicht vorgenommen. Jira bietet über das klassisch Issue Tracking das Agile Plugin “Greenhopper”, welches eine erweiterte Funktionalität für agile Teams bietet.
  • Confluence ist das passende Enterprise Wiki zu Jira. Es integriert sich nahtlos mit Jira und bietet etwas mehr Funktionalität und Erweiterbarkeit als ein durchschinittliches Open Source Wiki.

Beide Tools sind kostenpflichtig. Es mag sein, dass es kostenlose Tools gibt, die ähnlich gut sind, jedoch habe ich hierzu leider keine Erfahrungswerte.

Online Meetings / Kommunikation:

Wesentlich schwieriger hat sich die Suche nach einem passenden Online Meeting Tool gestaltet. Der größte Constraint ist “Linux”. Es gibt zwar ettliche Online Meeting und Konferenz Lösungen für Windows, jedoch gibt es kaum Tools, die unter Linux zuverlässig und in guter Qualität funktionieren.

Wir haben daher auch die Verwendung einer Virtual Box getestet. Das Ausführen von Windows Programmen in einer Virtual Box hat jedoch den massiven Nachteil, dass die VM jedes mal gestartet werden muss und man schwierig zwischen VM und native Linux interagieren kann. Die Performance des Computers leidet durch den erhöhten Ressourcenbedarf ebenfalls. Alles in Allem ist die VM-Lösung nicht zu empfehlen!

Von den nativen Linux Lösungen konnte kein Einziges für unsere Anforderungen überzeugen. Abstürze, Einschränkungen der Funktionalität und Inkompatibilität waren die größten Hindernisse, die uns begegneten. Folgende Tools führten zu den besten Ergebnissen bei Online Meetings und Konferenz-Calls:

  • Teamviewer + Skype: Teamviewer bietet neben Videocalls und Screensharing auch ein Whiteboard und die Übergabe des Screensharings in einem Meeting. Die Windows Version läuft etwas stabiler als die Linux Variante. Unter Linux gibt es keine Audio Unterstützung! Für die Audio-Übertragung haben wir daher Skype additiv verwendet. Auch die Videoqualität ist unter Linux sehr schlecht. In seltenen Fällen treten unter Windows und Linux Abstürze auf. Das Meeting wird jedoch automatisch “resumed” sobald der Client neu gestartet wurde. 
  • Adobe Connect: Der Flex Client läuft im Browser. Für das Screensharing ist allerdings ein lokal ausgeführtes Programm erforderlich, welches nur unter Windows läuft. Daher gibt es keine Screensharing Möglichkeit für Linux User! Es werden Video-Calls und Screensharing in ansprechender Qualität angeboten.
  • Screenleap: Kann in einer freien Version 2 Stunden pro Tag für Screensharing über den Browser verwendet werden. Bei längerer Nutzung schränkt sich das tägliche Limit allerdings immer weiter ein. Eine Lizenz für ein Team ist extrem teuer, da pro Useraccount und Monat Kosten anfallen.
  • Google Hangout: Videocalls und Screensharing funktionniert unter Windows und Linux stabil. Größter Nachteil ist, dass Google “mithört” und jeder Teilnehmer einen Google Account benötigt.

Folgende Tools sind für reine Windows Umgebungen zu empfehlen:

  • Skype Premium: Skype ist weit akzeptiert und einfach auf die Premium Version aufgerüstet. Leider bietet der Linux Client keine Premium Features (z.b.: Videocalls + Screensharing mit mehr als 2 Teilnehmern) , was es für Linux-Benutzer auf ein reines Audio Tool beschränkt. Für Windows Umgebungen ist das Toll jedoch zu empfehlen.
  • Microsoft Lync: Biete eine Menge Features (ähnlich wie Teamviewer) in guter Qualität und Stabilität. Es ist außerdem bei Verwendung von Exchange mit Outlook sehr gut integriert. Sehr Empfehlenswert!
  • Join.me: Einfach bedienbares Tool, das Screensharing über den Browser anbietet. Das Tool ist in einer kostenlosen Variante verfügbar. Es bietet allerdings nur Screensharing!

Fazit:

Mit Jira und Confluence hat man zwei solide Tools für die User Story- und Task-verwaltung. Mit Jira Rapid Boards lässt sich ein konfigurierbares, virtuelles Taskboard (Scrum, Kanban) erstellen. Professionelle Online Meeting Tools, die anstandslos funktionieren, sind für Linux nicht zu finden. Die meisten Anbieter von Online Meeting Tools bieten entweder nur Windows Versionen an oder vernachlässigen die Linux Versionen bei updates und Bugfixes massiv. Bei 40 getesteten Tools kann ich kein Einziges uneingeschränkt empfehlen. Teamviewer und Adobe Connect können noch am ehesten überzeugen. Hat man nur Windows in Verwendung gibt es eine ganze Reihe an qualitativ hochwertigen Tools. Microsoft Lync oder Skype Premium bieten sich als Alleskönner an, aber auch Teamviewer oder Adobe Connect sind unter Windows zu empfehlen. Für einfaches Screensharing unter Windows hat sich Join.me als sehr praktisch erwiesen. Alles in Allem ist “Linux” der größte Constraint bei der Verwendung von Online Meeting Tools. Welches Tool letztlich “das Richtige” ist hängt immer von den Anforderungen des Teams ab.

Verteilte Entwicklung mit Scrum in der Praxis

Seit mehr als einem Jahr führe ich nun ein verteiltes Entwicklungsteam. Die Entwickler sind dabei auf drei Standorten verteilt:

  • Graz: 3 Entwickler
  • Cluj (Rumänien): 2 Entwickler
  • Brasov (Rumänien): 1 Entwickler

Keine optimale Situation für ein Scrum Team, aber dafür umso herausfordernder! In diesem Blogpost möchte ich den Lernprozess, den ich und das Team die letzten Monate durchlaufen haben kurz skizzieren.

Initiales Teambuilding und Ramp-up

Da das Team rasch an Performance zulegen musste wurde für das initiale Ramp-up ein 2-monatiger Aufenthalt des gesamten Teams in Graz vorgesehen. In dieser Phase wurden die externen Kollegen aus Rumänien mit unserer Arbeitsweise, dem Projekt und der Business Domäne vertraut gemacht. Berührungsängste konnten so rasch abgebaut werden. Ein erstes Kennenlernen konnte stattfinden und das Teamgefühl wurde initial geprägt.

Verteilung auf drei Standorte

Nachdem das erste Ramp-up gut verlaufen war verteilten sich die Teammitglieder auf die drei Standorte. Es wurde vereinbart alle 6 Monate für einen Sprint (2 Wochen) wieder an einem der Standorte zusammenzukommen um das Teamgefühl wieder zu stärken. Was zu Beginn bereits kritisch beurteilt wurde, war die Tatsache, dass ein Entwickler alleine in Brasov stationiert war und dadurch nicht nur die Komplexität des Teams stieg sondern auch das Teamgefühl für ihn verloren ging. Diese Kritik sollte sich später noch bestätigen.

Technische Hilfsmittel

Um die Zusammenarbeit über drei Standorte zu ermöglichen sind technische Hilfmittel unverzichtbar und maßgeblich für den Erfolg oder Misserfolg verantwortlich. Es war klar dass wir ohne Audiocalls und Screensharing nicht arbeiten konnten. Später stellte sich heraus, dass Videocalls einen erheblichen Mehrwert für die ohnehin eingeschränkten Kommunikationsmöglichkeiten lieferten. Digitale Whiteboards, Jira + Greenhopper Plugin und Confluence waren weitere Werzeuge, die analoge Tools ersetzten. Das Problem ist, dass digitale Tools wesentlichen unflexibler und umständlicher sind und viel mehr Disziplin bei der Benutzung erforderlich ist als das bei analogen Tools der Fall ist. Weiters gehören Headsets, Polycoms und Webcams in verteilten Teams für jedes Teammitglied zur Basisausstattung.

Kommunikation

In der modernen Softwareentwicklung steht und fällt ALLES mit der Kommunikation. Neben der eingeschränkt spürbaren Teamdynamik liegt in der Kommunikation die Haupt-Einschränkung von verteilten Teams. Technische Hilfmittel sind letztlich zwar die “Enabler” für Kommunikation, können aber die fehlende physische Präsenz nicht vollständig kompensieren. Es geht also darum das Optimum aus der weniger optimalen Lage herauszuholen. Probleme von verteilten Teams in Bezug auf Kommunikation sind:

  • Es wird viel zu wenig kommuniziert!
  • Selbst das Aufsetzen eines Headsets, das Einschalten einer Kamera, das Drücken eines “Anrufen” Buttons, etc können bereits ein ausreichendes Hindernis zur Kommunikation darstellen
  • Entwickler an verteilten Standorten fühlen sich tendenziell weniger  stark verantwortlich, als jene, die mit dem Team vor Ort sind
  • Die Kommunikation ist zu hundert Prozent von der Technik abhängig
  • Viele Menschen fühlen sich nicht wohl wenn sie gefilmt werden (Videocalls) oder über Mikrofon sprechen müssen und unterlassen es deshalb einfach
  • Ein Großteil der Kommunikation, der über Mimik und Gestik stattfindet geht verloren (trotz Audio & Videocalls)
  • Digitale Tools (Whiteboard, Korbboard, Texteditor,…) sind umständlicher zu bedienen als Analoge und werden daher weniger oft zur Unterstützung verwendet

Die Zusammenkünfte

Wie eingangs erwähnt wurde vereinbart, dass sich das Team in Abständen von etwa 6 Monaten an einem Standort treffen sollte um einen Sprint gemeinsam zu arbeiten. Retrospektiv waren die zwei Zusammenkünfte die mit Abstand produktivsten Sprints, die ich mit dem Team erleben durfte. Die Zusammenfkunft hatte aber nicht nur auf die Velocity (die sich jeweis fast verdoppelte) eine positive Wirkung. Es wurden auch Social Events durchgeführt, was das Team stärker zusammenwachsen ließ. Es zeigte auch die Leistungsfähigkeit des Teams unter verbesserten Bedingungen für alle Teammitgleider auf. Letzlich gaben die Zusammenkünfte dem Team einen immensen Energieschub, der sich jedoch langsam bis zur nächsten Zusammenkunft wieder abschwächte und wieder eine Auffrischung brauchte.

Lessons Learned

  • Initiales Teambuilding und Ramp-up sind gemeinsam an einem Standort effizient durchführbar
  • Zusammenkünfte in regelmässigen Abständen liefern einen nachhaltig andauernden Energieschub für das Team und sind für länger existierende verteilte Teams unverzichtbar
  • Videocalls stärken das Teamgefühl und erhöhen die Qualität der Kommunikation
  • Kommunikations-Tools müssen vorab getestet und das richtige Set an Werkzeugen (abhängig von OS, Anforderungen,…) für das Team ausgewählt werden
  • An einem Standort sollte immer ein Sub-Team von mindestens zwei Entwicklern existieren
  • Verteilung über mehr als zwei Standorte sollten vermieden werden
  • Der Scrum Master muss sicherstellen, dass sich jeder im Team mit allen Stakeholdern  kommunizieren kann (Direkt Kontakte austauschen)
  • Verteilte Teams braucht pro-aktive Kommunikatoren mehr als jedes andere Team – introvertierte Personen sind für verteilte Teams nicht geeignet.

Next Steps

  • Ein ständig offener Kommunikationskanal (Audio + Video 24h eingeschaltet) zwischen den verteilten Sub-Teams soll die Teams noch stärker zur Kommunikation anregen und Kommunikationsbarrieren weiter minimieren.
  • Dauerhaftes Pair-Programming (8h pro Tag), wobei ein Paar aus einem Entwickler aus Graz und einem aus Rumänien besteht, um Wissen und Arbeitsweisen stärker auszutauschen und die Kollaboration über die geografische Grenze hinweg zu forcieren.