Agiles Arbeiten in verteilten Teams

Inhaltsverzeichnis

Agil entwickelnde Teams arbeiten am besten gemeinsam vor Ort. Kurze Wege zur Abstimmung und Klärung von Rückfragen sowie ein stets verfügbares Whiteboard für schnelle Skizzen und Abläufe helfen ungemein bei der Lösungsfindung. Es gibt keine Hürden in der Kommunikation. Das steigert die Produktivität und damit die Zufriedenheit aller Mitglieder eines Entwicklungsteams. Auch die Koordination zu Themen wie Design, Usability und QA erfolgt am besten vor Ort.

Leider ist eine solche Konstellation für viele Teams ein Wunschtraum. Die lokale Zusammenarbeit ist zwar eines der agilen Prinzipien, aber in der Praxis oft schlicht nicht möglich. Dabei sind häufig nicht die oft genannten Kostenfaktoren der ausschlaggebende Grund, sondern schlicht nicht genügend Kollegen am Standort verfügbar. Einige Besprechungen erfordern Mitarbeiter mit spezieller Expertise, die aus unterschiedlichen Gründen nicht im Büro vor Ort sein können oder wollen.

Die damit einhergehenden Kompromisse sind nicht völlig aus der Welt zu schaffen – ein Team mit allen Mitarbeitern vor Ort arbeitet effizienter als ein verteiltes. Dieser Artikel soll Wege aufzeigen, mit denen die Arbeit im Team trotz verschiedener Standorte gut und koordiniert ablaufen kann.

Eine Frage der Kommunikation

Es dürfte wenige erfolgreiche Teams geben, die keine gemeinsame Sprache sprechen. International ist dabei Englisch gesetzt, insofern müssen die Mitarbeiter zwangsläufig Tickets und Dokumentationen in Englisch verfassen. Selbst wenn im Team ausschließlich deutschsprachige Kollegen tätig sind, kann Englisch als Projektsprache sinnvoll sein, da eventuell zu einem späteren Zeitpunkt ein auswärtiges Team die Betreuung des Projekts übernimmt.

In der IT ist Englisch naturgemäß weit verbreitet. Zwischen dem gelernten (und womöglich kaum angewendeten) Schulenglisch und der alltäglich gelebten Projektsprache besteht ein großer Unterschied. Letztlich müssen die Mitarbeiter komplexe Geschäftsprozesse und Abläufe verständlich erklären können, wofür ein kaum trainiertes Basisenglisch meist nicht ausreicht. Neben der reinen Kommunikation ist oft auch die domänenspezifische Fachsprache beziehungsweise Terminologie eine Herausforderung. Dafür bietet sich ein übergreifendes Glossar an. Gegebenenfalls sind Weiterbildungen sinnvoll, da das Gelernte direkt in die Praxis einfließt.

Wenn eine Diskussion ins Detail geht, steht es den Kollegen durchaus zwischenzeitlich frei, zur Muttersprache zu wechseln. Die Scrum Master beziehungsweise Projektleiter müssen aber darauf achten, dass eine für alle Kollegen verständliche Erklärung und Dokumentation der Quintessenz erfolgt.

Bei verteilten Teams spielt neben Sprachkenntnissen zusätzlich die Technik eine Rolle – rauschende Headsets und Laptop-Mikrofone erschweren die Kommunikation unnötig. Eine schlechte Internetanbindung lässt sich nicht immer beeinflussen, aber beispielsweise ein gutes Tischmikrofon sollte vorhanden sein. Im Idealfall erfolgt die Kommunikation über Video. Eingespielten Teams genügt oft auch der Austausch via Audio beziehungsweise Screensharing.

Neben der Sprache wirken sich kulturelle Unterschiede aus: In vielen Kulturen ist es absolut unüblich, "Nein" zu sagen. Ähnliches gilt für die Pünktlichkeit und die Direktheit in der Kommunikation. Hier gilt es vor allem, Verständnis für die Besonderheiten zu entwickeln und gemeinsame Regeln zu etablieren. Gegebenenfalls lässt sich mit vielen kleinen, konkreten Meilensteinen arbeiten. Auch eine Schulung zu "Cultural Awareness" kann zumindest für Projektleiter sinnvoll sein.

Die Bereitschaft, bei Unklarheiten oder Schwierigkeiten nach Unterstützung zu fragen, ist bei verteilten Teams oft geringer, da das Vorgehen als Schwäche ausgelegt werden könnte. Hier sind vor allem die Projektleiter gefragt, eine entsprechende Kultur und Vertrauen im Team aufzubauen, um solche Ängste abzubauen. Das ist auch für Retrospektiven wichtig.

Auch die Größe des Teams beeinflusst die Kommunikation: Ein Team mit 20 Mitarbeitern an unterschiedlichen Standorten wird kaum effizient kommunizieren können. Hier ist eine Aufteilung dringend angeraten – vier bis acht Kollegen sind für ein Kernteam eine sinnvolle Größe.

Meetings & Tools

Organisierte Meetings

Viele Entwicklungsteams arbeiten in einem Scrum-Prozess mit folgenden wesentlichen Meetings:

• Daily
• Retrospektive
• Review
• Grooming
• Planning

Ziel und Sinn der einzelnen Meetings sind Bestandteil der Scrum-Vorgaben, daher geht dieser Artikel nicht weiter darauf ein. Generell sollten sich zu den Meetings zumindest die Mitarbeiter am selben Standort in einem Raum treffen.

Dailies sind wie bei lokalen Teams eher kurz zu halten und sollten nur dazu dienen, über den aktuellen Stand aller Kollegen im Bilde zu sein und rechtzeitig auf Probleme und Schwierigkeiten hinzuweisen. Ein Daily ist kein Projektabstimmungstermin und nicht auf Detaildiskussionen ausgelegt. Dafür sind kleinere Runden außerhalb des Dailies besser geeignet.

In verteilten Teams sind Zeitzonen teilweise ein Problem, aber meist lässt sich ein gemeinsamer Zeitpunkt finden, an dem alle Kollegen arbeiten. Sofern das nicht möglich ist, kann das Team die Zeiten alternieren, um alle fair zu behandeln.

Retrospektiven sind in verteilten Teams nicht einfach – wie kein anderes Scrum-Meeting profitiert diese Form von einer lokalen Präsenz ("Face-to-Face" mit Körpersprache), um auch konstruktive Kritik einzubringen und Verbesserungen vorzuschlagen. Zum Einbeziehen aller Beteiligten ist ein gewisses Moderationsgeschick gefragt.

Feedback lässt sich nicht erzwingen, aber allen sollte klar sein, dass die Retrospektive das wichtigste Treffen zur Verbesserung der Prozesse und damit der Zusammenarbeit im Team ist. Um Retrospektiven locker einzuleiten, finden sich einige sogenannte Energizer bei funretrospectives und Retromat.

Bei den Reviews sollten im Idealfall alle Teammitglieder etwas vorstellen. Je nach Projekt muss es sich dabei nicht immer um ein neues Feature handeln: Ein Denkansatz oder eine elegante Implementierung genügt. Alle Kollegen sollten via Screensharing teilnehmen.

Plannings sollten vor allem kurz sein. Dabei müssen alle Beteiligten oft den Kontext wechseln und sollen auch noch eine realistische Einschätzung hinsichtlich der Komplexität der anstehenden Aufgaben treffen. Besonders im Planning leidet schnell die Konzentration, wenn nicht alle Beteiligten vor Ort sind, sodass Stories nur noch "durchgewunken" werden. Daher bietet sich die Besprechung der Aufgaben im Vorfeld in einem Grooming an. Oft ist das Schätzen dann eine Sache von Minuten oder etwa einer Stunde.

Viele Teams machen inzwischen gute Erfahrungen mit Ein-Wochen-Sprints. Das Vorgehen fördert vor allem die Fokussierung auf ein Thema, was in vielen Projekten gut passt – aber natürlich längst nicht immer. Generell sollten Drei-Wochen-Sprints das Maximum sein. Kurze Sprints machen das Ziel klarer, und es wirkt sich meist positiv auf die Motivation aus, wenn zum Ende der Woche etwas "fertig" ist.

Größere fachliche Themen oder Änderungen lassen sich ergänzend zu den Basis-Meetings in einem Ramp-up einleiten. Dabei geht es vor allem um das Vermitteln der Grundidee beziehungsweise Vision und weniger um Code oder technische Details. Beim Ramp-up lässt sich oft der Rahmen für einen ersten Durchstich (Minimum Viable Product) definieren, mit dem direkt im nächsten Sprint begonnen werden kann. Besonders in verteilten Teams hilft solche Grundlagenarbeit, um ein Ziel klarer zu beschreiben und Missverständnisse zu reduzieren.

Für verteilte Teams sollte ein gemeinsamer Kick-off zum Start des Projekts immer möglich sein. Inwieweit anschließend (regelmäßige) Termine am selben Ort machbar sind, ist eine Frage von Budget und Logistik. Oft dürften sie sich auch finanziell rechnen, aber eine verbesserte Stimmung im Team und die Verringerung potenzieller Missverständnisse sind monetär kaum zu belegen. Ein Kompromiss können Rotationen sein, bei denen einzelne Teammitglieder abwechselnd an den verschiedenen Standorten arbeiten.

Das richtige Werkzeug

Für das ganze Team sollte stets ein gemeinsamer Kommunikationskanal existieren. Viele Teams lösen das über eine oder mehrere spezifischere Chatgruppen via Skype, Slack, HipChat oder eine interne Anwendung.

Weiterhin ist eine sich an die Entwicklung anschließende Continuous-Integration-Umgebung inzwischen Standard. Das hilft auch verteilten Teams, da sich Änderungen kontinuierlich prüfen lassen und Fehler im Build in der Verantwortung aller liegen.

Eine QA beziehungsweise Abnahme erfolgt meist auf einer Deployment-Umgebung, die für alle Kollegen erreichbar ist und (weitgehend) den Stand des Produktivsystems widerspiegeln sollte. Dieses System sollte immer der Maßstab für eine erfolgreiche Abnahme sein: Features, die darin nicht laufen, sind nicht fertig. Eine gemeinsame "Definition of Done" sollte sowohl für rein lokale als auch verteilte Teams selbstverständlich sein.

In den meisten Projekten bildet ein virtuelles Kanban-Board das Aufgabenmanagement ab, etwa JIRA Agile, Trello oder Asana/Kasban. Damit ist der Status einer Aufgabe jederzeit für alle einsehbar. Die Entwickler pflegen das Board selbst. Meist ist initial nur die Definition der Prozesse für den Übergang erforderlich. Das betrifft Themen wie Code Review, QA, funktionale Abnahme, Lasttest und Security-Audit. Als Ersatz für ein physisches Kanban-Board lässt sich auch ein größerer Bildschirm mit dem virtuellen Board in den Büros aufstellen.

Workflows

Workflows in der Entwicklung

Code-Reviews sollten selbstverständlich sein. Sie können durch die Chefarchitekten beziehungsweise technischen Projektleiter oder durch Kollegen innerhalb des Teams erfolgen. Letzteres ist zu bevorzugen – wenn ein Team Vertrauen erfährt, wird es langfristig auch erfolgreich sein. Eigenverantwortliche Reviews sind ein Mittel, um solches Vertrauen zu schaffen. Die Umsetzung erfolgt häufig über einen Workflow mit Pull Requests. Dabei muss immer mindestens ein Mitarbeiter den Code reviewen. Das steigert den Austausch und fördert das Verständnis der gemeinsamen Codebasis. Weiterhin sind Pull Requests asynchron und damit auch weitgehend unabhängig von Zeitzonen.

Teams sollten generell ein gemeinsames Qualitätsverständnis besitzen oder aufbauen. Gemeinsame Programmierrichtlinien werden selten allen Wünschen gerecht, aber ein Kompromiss sollte sich eigentlich immer finden lassen. Die folgende Liste zeigt hilfreiche Tools, die sich meist gut in den Build integrieren lassen:

• IDE-/Editor-Konfiguration: Editorconfig
• Struktur, Formatierung, Kommentare: Checkstyle
• Bugs und Smells (Backend): Findbugs, PMD, SonarQube
• Bugs und Smells (Frontend): ESLint, JSHint, Gremlins

Verteilte Teams neigen manchmal dazu, auch die Aufgaben entsprechend des Standorts zu verteilen. Die Teams definieren dazu meist eine gemeinsame Schnittstelle (Contract) und arbeiten davon ausgehend weitgehend eigenverantwortlich. Dieses Vorgehen kann praktisch sein und wird unter anderem von Atlassian empfohlen. Ein Nachteil ist die fehlende Flexibilität: Wenn sich beispielsweise einige Kollegen nur um das Backend kümmern, können Urlaube, Krankheitsfälle oder Veränderungen innerhalb des Teams Probleme verursachen. Das ist vor allem in kleineren Teams ein Projektrisiko. Bei größeren oder mehreren Teams bietet sich eine in den Standorten widerspiegelnde Modularisierung des Projekts eher an.

Verteilte Schätzungen

Die in Scrum am häufigsten eingesetzte Schätzmethode dürfte das Planning Poker auf Basis von Story Points sein. Dabei schätzen alle Entwickler die User Stories unabhängig voneinander und diskutieren das Ergebnis der Schätzung gemeinsam. Bei Abweichungen lassen sich mehrere Schätzrunden ausspielen.

Eine Alternative ist die sogenannte Magic Estimation. Sie läuft weitgehend ohne Diskussion und offen ab: Reihum ordnet jeder Entwickler eine Story zu einer Komplexitätsstufe zu. Der nächste Entwickler kann die Story wieder verschieben. Beim häufigen Verschieben einer Story erkennen Team beziehungsweise Scrum Master, dass noch Klärungsbedarf besteht.

Für das Schätzen in verteilten Teams via Planning Poker eignet sich beispielsweise Pointing Poker gut. Magic Estimation erscheint für verteilte Teams aufgrund der höheren Effektivität und stärkeren Visualisierung mittlerweile als bessere Option. Ein Hindernis ist eher das Tooling – lokal lassen sich für Magic Estimation einfach User Stories auf einem Tisch oder Fußboden auslegen und verschieben. Diese Option besteht bei mehreren Standorten nicht. Eine Suche nach frei verfügbaren Lösungen für Magic Estimation endete ergebnislos. Daher entstand im Rahmen des Artikels auf Basis von Angular 1.5 und Dragula eine einfache webbasierte Applikation.

Die Anwendung verlangt ein JIRA-System mit Agile-Funktionalität, woraus über die REST API aus den angelegten Sprints alle Stories in die Web UI geladen und deren Komplexität dann über Drag-and-drop geschätzt werden können. Die Anwendung bietet noch einigen Raum für Verbesserungen (siehe Readme), erfüllt aber zunächst ihren Zweck.

Unabhängig von der Art der Schätzung liegen auch erfahrene Teams in ihren Schätzungen teilweise deutlich daneben. Im Produktbereich arbeiten Teams mittlerweile oft nach Kanban und können damit häufig ganz auf Schätzungen verzichten. Im Projektgeschäft brauchen zumindest Kunden und das interne Management hingegen meist eine möglichst genaue Aussage zum zeitlichen Rahmen der Umsetzung. Dafür sind Schätzungen weiterhin kaum zu ersetzen.

Diskussionen und Konflikte

Konfliktmanagement ist nie leicht. Die räumliche Distanz kann dazu führen, dass Mitarbeiter Konflikte tendenziell verschweigen oder teilweise auch übermäßig emotional austragen. Dagegen helfen Videokonferenzen und Einzelgespräche. Teams sollten Diskussionen über kritische Themen vorbereiten und dokumentieren. Eine schriftliche und visuell aufbereitete Grundlage ist meist besser als die rein verbale Kommunikation und kann viele Missverständnisse verhindern. Eine Endlosdiskussion via Chat beziehungsweise Mail oder Ticket-Ping-Pong nützt niemandem und stiehlt allen Beteiligten Zeit und Nerven. Ist letztlich keine Einigung möglich, müssen im Zweifel die Projektleiter entscheiden. Das sollte aber die Ausnahme sein.

Ein Fingerpointing ("das hat XY gemacht") oder Unzuständigkeit ("nicht mein Code") sollten Scrum Master beziehungsweise Projektleiter unterbinden. Oft beziehen sich solche Konflikte nicht nur auf einzelne Personen, sondern auf alle Kollegen am jeweils anderen Standort. Dagegen hilft meist ein Hinweis auf den Teamgedanken und die gemeinsame Verantwortung.

Dokumentation & Fazit

Gut dokumentiert

Die Dokumentation sollte sich bei verteilten Teams kaum von anderen Konstellationen unterscheiden. Wichtig ist eine gepflegte Dokumentation des Projekt-Set-ups, wofür sich Readmes im Projekt analog zu Github anbieten.

Ein Wiki eignet sich besonders für langfristig relevante Beschreibungen, HOWTOs und sonstige Kontextinformationen. Auch übergreifend genutzte Personas sollten im Wiki hinterlegt sein. Wikis sind ebenfalls gut geeignet, um verschiedene Medien zu verknüpfen (Text und Diagramme). Eine gut funktionierende Suche ist elementar. Da Wikis oft unter mangelnder Pflege und Struktur leiden, ist zu hinterfragen, ob sie ein guter Ort für den Großteil der Dokumentation sind.

Andere Dokumentationen sollten eher nah am Code erfolgen. Dadurch steigt die Chance, dass sie gelesen und gepflegt werden. Weiterhin ist die Versionierung durch das Versionsverwaltungssystem quasi gratis. Neben der Dokumentation des Projekt-Set-ups eignen sich solche Readmes beispielsweise für Migrationsanleitungen, Beschreibungen für manuelle Tests und Lasttests oder ein Changelog.

Die Dokumentation soll in verteilten Teams vor allem dazu dienen, Missverständnisse zu vermeiden. Dabei helfen visuelle Darstellungen wie UML- (Unified Modeling Language) und BPML-Diagramme (Business Process Modeling Language) sowie Skizzen, Fotos und Mock-ups. Besonders Use-Case- und Sequenzdiagramme sind für komplexere Anforderungen nützlich und international verständlich. Über Tools wie Balsamiq Mockups oder Axure lassen sich auch klickbare Mock-up-Prototypen erstellen.

Für die Demonstration von Abläufen eignen sich Videos in Form von Screen Recordings. Eine pragmatische Lösung sind animierte GIFs, die sich unter anderem über LICECap leicht aufzeichnen lassen. Sie funktionieren praktisch überall und lassen sich in jegliche Doku beziehungsweise Tickets integrieren oder anhängen. Nachteile sind der recht hohe Speicherbedarf und der fehlende Ton, was jedoch beides bei kurzen Demos meist keine Rolle spielt.

Fazit

Sofern die Abläufe klar sind, das Tooling erprobt ist und ein gemeinsames Verständnis der Aufgaben und Ziele existiert, sollten verteilte Teams gut und effizient arbeiten können. Das A und O für den Erfolg ist das Schaffen einer offenen und vertrauensvollen Kultur im Team, damit sich verteiltes Arbeiten gar nicht wirklich verteilt anfühlt.

Jan Petzold
arbeitet als Senior Consultant für die Westernacher Solutions AG in Berlin. Er ist seit mehreren Jahren als Entwickler und Projektleiter in weltweit verteilten agilen Teams aktiv

(rme)