Ein Erfahrungsbericht: agiles Arbeiten mit verteilten Teams

Foto des Autors
Denis Vollmer

Alles begann mit einer der unschuldigen Fragen eines unserer Geschäftsführer wie mein Englisch wäre. Als ich überzeugend mit einem lockeren „sehr gut“ antwortete wusste ich noch nicht was auf mich zukommen sollte.

Alles begann mit einer der unschuldigen Fragen eines unserer Geschäftsführer wie mein Englisch wäre. Als ich überzeugend mit einem lockeren „sehr gut“ antwortete wusste ich noch nicht was auf mich zukommen sollte.

Die Aufgabe

Meine Aufgabe sollte darin bestehen, Grundlagen der agilen Softwareentwicklung zu vermitteln, dem Team coachend zur Seite zu stehen, und es auf die kommenden Aufgaben vorzubereiten.

Mir wurde die Information mitgegeben, dass es sich um ein frisch zusammengestelltes, verteiltes Entwicklungsteam handelt, das Software für Embedded Hardware entwickelt. Das Team hatte wenig bis keine Erfahrung mit der agilen Softwareentwicklung, sollte aber als eines von mehreren Teams im Scaled Agile Umfeld zum gemeinsamen Entwicklungserfolg beitragen. Ein Teil der Teammitglieder arbeitete aus Indien und der andere aus Deutschland. Die Kommunikation erfolgte auf Englisch.

Die ersten Projekttage begleitete ich das Team bei den Scrum Zeremonien. Die Zeremonien waren zu dem Zeitpunkt schon zeitlich festgesetzt. Außerdem hatte ich regelmäßige Feedback-Gespräche mit dem Scrum Master und dem Product Owner des Teams. Scrum Master und Product Owner hatten einiges an Vorwissen, das Entwicklungsteam jedoch noch sehr wenig. Um auch hier weitere Grundlagen zu legen, habe ich einen Workshop zum Thema „Von der Anforderung zum Produkt-Inkrement“ beim Entwicklungsteam in Deutschland gehalten. Des Weiteren begleitete ich das Team beim im SAFe Umfeld quartalsweise stattfindenden Produkt Inkrement Planning, das sich über drei Tage erstreckte.

Konkrete Erfahrungen

Heißt es doch im Agilen Manifest: „Individuals and interactions over processes and tools“. Dies bedeutet eigentlich, dass doch das wesentliche Augenmerk auf den Menschen und seine Interaktionen gerichtet werden soll und dann erst im zweiten Schritt auf Prozesse und Werkzeuge. Allerdings habe ich in den letzten drei Monaten gelernt, dass beim Arbeiten mit verteilten Teams zunächst gewisse Prozesse und Strukturen geschaffen werden müssen. Erst dann haben Menschen die Möglichkeit unmissverständlich zu kommunizieren und reibungslos zusammen zu arbeiten!

Photo by Todd Quackenbush on Unsplash

Konkret erfolgte die Kommunikation innerhalb der meisten Meetings zunächst mit Hilfe von Skype for Business. Auch JIRA, Confluence und Bitbucket konnten für unsere tägliche Arbeit genutzt werden. Darüber hinaus bedienten wir uns für gewöhnlich verschiedener Powerpoint Präsentationen und nutzten die „Bildschirm teilen“ Funktionalität von Skype for Business, um Informationen auszutauschen.

Schnell haben wir festgestellt, dass wir mit den bisher genutzten Werkzeugen an den Grenzen des Machbaren waren. Gerade das effektive Gestalten unserer Scrum-Zeremonien war nur mit viel zeitlichem Aufwand und vielen Work-Arounds möglich.

Konkrete Probleme

Ein Problem, das wird zum Beispiel hatten, war das Schätzen von User Stories: Zunächst hatten alle Mitglieder des Entwicklungsteams, per Chat-Funktion von Skype, ihren Schätzwert an den Scrum Master gesendet. Die Ergebnisse wurden dann mit dem Team geteilt. Wir waren uns alle schnell einig, dass es eine elegantere Lösung für das Problem geben musste. Das Team hat dann ein Online-Tool für Planning Poker gefunden und erfolgreich eingeführt.

Ein weiteres Problem waren die Retrospektiven. Hier nutzte das Team zunächst die Retrospektiven Schablone von Confluence. Das Entwicklungsteam wurde reihum befragt, was im Sprint gut gelaufen ist und was weniger gut gelaufen ist. Die Aussagen wurden in der Schablone festgehalten. Auch hier waren sich alle einig, dass man die Retrospektiven verbessern musste. Wir haben mehrere Online Tools für Retrospektiven evaluiert und uns dann für eine recht einfache Variante entschieden. Jeder hatte die Möglichkeit verdeckt zu notieren, was das Team ändern sollte, was es beibehalten sollte und welche Praktiken es in Zukunft ausprobieren sollte. Im nächsten Schritt konnte jeder sein Anliegen kurz erläutern. Das Team hat dann mit Hilfe des Dot-Votings die zwei bis drei wichtigsten Themen identifiziert. Im Anschluss wurden die Themen diskutiert und Action Items daraus abgeleitet.

Was außerdem jedes Mal viel Zeit in Anspruch genommen hat, war das Abfragen der Zufriedenheit aller Teammitglieder zu verschiedenen Themen: Ist der Sprint ausreichend ausgefüllt? Sind zu viele Stories im Sprint? Passt das Sprint-Ziel noch? Wir haben das Abfragen gegen ein Confidence Vote ausgetauscht. Ein weiteres Online Tool hat uns die Arbeit abgenommen. Ein einfaches Fist-Of-Five in die Kamera war keine Option, da sich leider lange nicht jeder über die Video-Chat-Funktion sehen konnte. So haben wir letztendlich viel Zeit durch ausschweifende Erörterungen und Diskussion gespart. Themen wurden nur noch mal intensiver diskutiert, falls der Durchschnitt aller abgegeben Werte einen bestimmten Schwellenwert unterschritten hat.

Video Kommunikation

Das Thema Kamera und Video-Chat hat mich bis zuletzt getrieben. Die Fachliteratur und Gespräche mit anderen Agile Coaches haben mir bestätigt, dass es unumgänglich ist, sich im täglichen Arbeitsleben, bei Meetings und Ähnlichem zu sehen. Neben Intonation gehören auch Gestik und Mimik der einzelnen Teammitglieder zu einer unmissverständlichen Kommunikation. Es hat mich viel Überzeugungsarbeit und Anstrengungen gekostet, aber beim letzten Sprint-Wechsel waren dann wirklich alle in der Lage ihre Kamera zu nutzen. Leider machen es Firmenrichtlinien in vielen Unternehmen schwer, unterschiedliche Werkzeuge zu nutzen. In diesem Fall musste wirklich jeder über ein Web-Formular explizit der Nutzung der Kamera-Funktion zustimmen.

Was habe ich gelernt?

Photo by Element5 Digital on Unsplash

Was ich zwar im Hintergrund wusste aber zunächst nicht präsent hatte, sind die kulturellen Unterschiede innerhalb des Teams. Es ist nicht nur die Zeitverschiebung und die Sprache, die das gemeinsame Arbeiten zu einer größeren Herausforderung und damit so spannend machen, sondern es ist auch der kulturelle Hintergrund jedes Einzelnen. Ich hatte zwar schon Erfahrung mit Teams, in denen nicht alle die gleiche Muttersprache sprachen, aber mein aktuelles Team besteht aus Menschen mit vielen verschiedenen Herkunftsländern.

Umso wichtiger ist es, dass man versucht sich untereinander näher kennen zulernen. Das klappt natürlich auch Remote. Dennoch habe ich festgestellt, dass mein Besuch Vorort beim Team in Deutschland oder das Zusammentreffen des gesamten Teams beim Produkt Inkrement Planning deutlich dazu beigetragen haben, dass Team enger zusammen zu schweißen.

Mir war zuvor gar nicht bewusst wie viele verschiedene Online-Tools im agilen Kontext existieren. Die meisten die wir uns angeschaut haben, haben einem die Arbeit erleichtert und waren einfach zu nutzen. Nicht alle kosten etwas oder sind furchtbar teuer.

Sicher ist es zunächst einfacher mit Teams zu arbeiten, die nicht örtlich verteilt sind, da der Hebel, den man als Agile Coach hat, länger ist als bei einem Remote arbeitendem Team. Dennoch haben wir viele Probleme schnell durch offene Kommunikation und Team-Anstrengungen lösen können. Meine Erfahrung zeigt, dass ein verteiltes Team erstmal mehr Zeit investieren muss und so zu Beginn auch langsamer ist als ein örtlich zusammenarbeitendes Team. Dennoch zeigt meine Erfahrung auch, dass ein verteiltes Team, wenn es in der „Performing“ Phase angekommen ist, genauso produktiv ist wie ein örtliches Team.

Also keine Angst vor verteilten Teams!

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Agile Series: Messen statt Schätzen mit No Estimation

Agile Series: Messen statt Schätzen mit No Estimation

Mit No Estimation können Sie in agilen Projekten messen, wieviele User Stories Sie und Ihr Team in einem Sprint schaffen ...
Agilität braucht gute Führung

Agilität braucht gute Führung

Die agile Führungskraft ermöglicht, dass er sich entwickeln und seine Arbeit bestmöglich erledigen kann. Wie es im agilen Manifest steht: ...
MVP-Vorgehen am Beispiel

MVP-Vorgehen am Beispiel

Wie entwickeln Sie erfolgreiche Produkte mit dem MVP-Vorgehen? Ein ausführliches Beispiel für minimum viable product ...