Kurz vor der Corona Krise hat einer unserer Kunden angefragt, ob er ein weiteres Softwareentwicklungs-Team bekommen kann, um das Going Online seines MVP zu beschleunigen. Zu diesem Zeitpunkt hat noch keiner von uns mit den Auswirkungen des Coronavirus auf unsere Arbeit gerechnet. Wir haben ein Team von Entwicklern zusammengestellt, Scrum-Master und Product Owner des bestehenden Teams hatten genug Kapazität, um ein weiteres Team zu betreuen. Ich hatte Lust aus dem bestehenden Team zu wechseln, um dem neuen Team beim technischen Onboarding im Projekt zu helfen und eine leichtere Einführung in die Fachlichkeit zu ermöglichen. Das alles konnten wir innerhalb von einer Woche auf die Beine stellen. Doch an dem Wochenende vor unserem Start wurden die Empfehlungen zum Social Distancing seitens der Politik und unseres Managements ausgesprochen. Wir waren also in der besonderen Position, das Teambuilding nicht wie gewohnt mit einem Kick-Off-Workshop persönlich und vor Ort abzuhalten.

Die Befürchtung der Entfremdung bei der Remote-Arbeit

Das Vorurteil besagt, dass alle Entwickler Lust haben, Remote-Work auszuprobieren und das Management aus mangelndem Vertrauen dagegen ist. Allerdings trifft das auf die meisten Entwickler, die ich kenne, nicht zu. Bei uns hat das Management zum Glück keinerlei Bedenken gegen die Heimarbeit, zumal wir im Moment ja auch gar nicht die Wahl haben. Das oben genannte Vorurteil, zu Hause würde nicht gearbeitet werden, widerspricht auch einem agilen Mindset, bei dem die Verantwortung bei den Mitarbeitern liegt.

Aus meiner Erfahrung wollen Entwickler Probleme gerne live zusammen lösen. Hier spielt zum einen der Wunsch nach sozialer Interaktion eine Rolle, sich mit den Teammitgliedern persönlich zu unterhalten und kein Code-Monkey zu sein, der nach Vorgaben Programmcode generiert. Zum anderen werden bei der zwischenmenschlichen Interaktion zwischen den Kollegen nicht nur die projektrelevanten Informationen, die man zufällig an der Kaffeemaschine aufschnappt, sondern auch private Dinge, die man mit den Kollegen teilt, vermisst. Diese machen die Arbeitszeit angenehmer und fördern zudem Verständnis bei Konflikten.

Produktivität von verteilten Teams durch asynchrone Kommunikation

Aber nicht nur die fehlende soziale Nähe stört viele Softwareentwickler. Sie sind deshalb Entwickler, weil sie insbesondere gerne programmieren und weniger gerne planen. Sie wollen also produktiv sein, ohne sich im Vorhinein zu viel mit Abhängigkeiten und Arbeitsorganisation auseinandersetzen zu müssen. Im Büro funktioniert das bis zu einem gewissen Grad gut, solange die Leute, von denen die Arbeit abhängt, kurzfristig erreichbar sind. Am einfachsten ist es, wenn diese einfach im Büro nebenan sitzen. In der Heimarbeit passiert als erste gegensteuernde Maßnahme aber oft das Gegenteil, um die fehlende räumliche Nähe auszugleichen: Mehr Meetings, um die Kommunikationsbrücken zu schlagen. Allerdings kommt der “Produktivitätsboost”, den man bei Remote Work erreichen kann, durch fokussierte Arbeit, bei der man nicht gestört wird. Diese wird dadurch ermöglicht, dass eben niemand mal eben zu einem an den Arbeitsplatz kommen und ihn aus der Arbeit reißen kann – abgesehen von den Kindern, um die man sich zu Hause kümmern muss. Diese fokussierte Arbeit benötigt allerdings Planung, da sie nur funktioniert, wenn sie nicht durch Abhängigkeiten blockiert wird.

Um Remote Work möglichst produktiv zu gestalten, müssen Entwickler dementsprechend dazu in die Lage versetzt werden, sich alle Informationen, die sie zum Bearbeiten der Aufgaben benötigen, holen zu können. Dabei sollten sie allerdings nicht auf synchrone Kommunikation angewiesen sein, da diese erfordert, dass andere Teammitglieder wiederum aus ihrer fokussierten Arbeit gerissen werden.

Als synchrone Kommunikation bezeichnet man die Kommunikation, an der alle Teilnehmer gleichzeitig teilnehmen. Asynchrone Kommunikation kommt hingegen zum Einsatz, wenn die Teilnehmer zeitlich versetzt kommunizieren können. In unserem Projekt setzen wir beispielsweise die folgenden Kommunikationsmittel ein:

• Synchron: Videokonferenzen (Google Hangout)
• Synchron und asynchron gemischt: Chat-Programm (Rocket-Chat)
• Asynchron: E-Mail, Ticket-System (Atlassian Jira), Dokumenten-Management-System (Atlassian Confluence), Google Drive

Diese Kommunikationsarten betreffen allerdings nicht nur die fachlichen Informationen, die Entwickler zur Umsetzung benötigen, sondern auch das technische Wissen. Was mache ich, wenn ich noch nicht so viel Erfahrung in der eingesetzten Technologie habe oder mal nicht weiter komme? Das ist etwas, was sich nicht immer planen lässt.

Unser Lösungsansatz: Mob-Programming

In dem neuen Team gab es große Unterschiede in den Vorkenntnissen im Bezug auf die eingesetzten Technologien. Dadurch, dass das Team so kurzfristig starten sollte, mussten wir in dieser Hinsicht einige Kompromisse eingehen. Dadurch konnten wir die Aufgaben nicht von Anfang an parallel im Alleingang bearbeiten.

Uns blieb also nur das Remote Mob-Programming im Google Hangout. Mob-Programming bezeichnet das Programmieren in einer ganzen Gruppe. Eine Vorstufe davon, das Pair-Programming, ist etwas bekannter. Dazu teilt eine Person ihren Bildschirm. In der Theorie hat diese die Rolle des Schreibers. Der Rest diskutiert die Lösungsmöglichkeiten und steuert den Schreiber. Bei uns war der Schreiber allerdings am Anfang immer an den Entscheidungen beteiligt, weil die Unterschiede im Know-how noch zu groß war, als dass der Rest ohne den Schreiber entscheiden wollte. Durch die Remote-Arbeit war es einfach, das ganze Team vor einem Bildschirm zu versammeln und wir konnten Wissen optimal verteilen. Das Team ist dadurch sehr produktiv gestartet.

Ein weiterer Vorteil durch das Remote Mob-Programming war, dass Reviews weniger wichtig und weniger aufwändig wurden. Wir haben sie allerdings dennoch durchgeführt, sobald mindestens eine Person nicht am Mob-Programming teilgenommen hat. Doch auch wenn Reviews durchgeführt worden sind, wurden die Feedbackzyklen kürzer. Sobald die andere Person den Code geprüft hat, konnte jeder, der an dem Mob beteiligt war, etwaige Rückfragen beantworten und Anpassungen vornehmen. Dadurch wurde die Zeit zur Fertigstellung reduziert.

Ein nicht zu verachtender Nebeneffekt des Mob-Programmings ist auch, dass wir als Menschen direkt zusammengearbeitet haben. Wir konnten zwischendurch Witze machen, zusammen lachen und uns persönlich kennenlernen. Dadurch gab es eine soziale Komponente zwischen allen und nicht nur zwischen denjenigen, die sich normalerweise im Büro bevorzugt zum Pair-Programming zusammen finden.

Obwohl wir von Anfang an auf das Mob-Programming angewiesen waren, konnte sich dennoch jeder bei Bedarf vom Mob abkapseln und mal eine Stunde fokussiert arbeiten. Dies war nicht nur nötig, um die Produktivität von Anfang an hoch zu halten, sondern auch, weil das andauernde miteinander Reden und über Lösungen diskutieren sowohl kognitiv als auch auditiv ziemlich anstrengend werden kann.

Es ist allerdings noch zu früh zu bewerten, wie schwerwiegend die Auswirkungen davon sein werden, dass die soziale Kommunikation im Remote-Team anders abläuft. Als kleines Morgenritual hat es sich ergeben, dass wir uns morgens immer zum gemeinsamen Kaffee im gleichen Google Hangout treffen. Das gibt mir immer das Gefühl, tatsächlich im Team zu starten und die Anwesenheit der anderen wahrzunehmen. Zusätzlich sucht unser Scrum-Master uns regelmäßig Online Spiele wie skribbl.io (Montagsmaler) raus, damit wir auch mal zusammen abseits der Arbeit abschalten.

Ein weiterer Vorteil für uns ist es, dass es keine Hürde für Remote-Arbeit gibt. Normalerweise können wir bei der tarent jederzeit, wenn es mit dem Team abgesprochen ist, von zu Hause arbeiten. Bei Teammeetings ist es aber dann meistens so, dass man sich remote zu einem Meeting dazu schaltet, bei dem der Rest zusammen in einem Konferenzraum sitzt. Dies sorgt durch die Verzögerung der Videoübertragung für ein Kommunikationsgefälle. Jetzt haben alle die gleiche Latenz, sodass dieses Gefälle wieder aufgehoben wird.

Die nächste Herausforderung: Asynchrone Kommunikation fördern

Wir konnten die ersten Herausforderungen des Teambuildings bereits erfolgreich in Angriff nehmen. Dennoch begegnen wir jetzt langsam den Problemen, die auch Entwicklungsteams haben, die zuvor on-site zusammengearbeitet haben. Unser Vorteil ist derzeit, dass noch keine Prozesse eingefahren sind, die sich auf eine Kommunikation vor Ort verlassen.

Unser größtes Optimierungspotential liegt meines Erachtens im Moment darin, die Kommunikation auf Asynchronität umzustellen. Wie oben beschrieben ist das die Voraussetzung dafür, dass die Remote Arbeit besonders produktiv wird. Im Moment erfolgt die meiste Kommunikation bei uns noch im Daily, über gemeinsames Mob-Programming oder den Chat. Innerhalb der nächsten Sprints werden wir wahrscheinlich etwas darauf hinarbeiten, dass es Phasen gibt, in denen einzelne Leute fokussiert und parallel an eigenen Aufgaben arbeiten können.

Dabei gibt es aber zwei verschiedene Arten an Informationen, die asynchron im Team verteilt werden müssen. Zum einen die Informationen, bei denen klar ist, dass sie zur Erledigung einer Aufgabe wichtig sind. Diese sollen in unserem Ticketsystem an den einzelnen Aufgaben dokumentiert werden, was auch super funktioniert.

Die andere Art betrifft die Informationen, die grundsätzlich für jedes Teammitglied relevant sind, aber keiner Aufgabe direkt zugeordnet werden können. Solche Informationen beziehen sich zum Beispiel auf grundlegende Änderungen in der IT-Architektur, den fachlichen Anforderungen oder im Arbeitsablauf. Solche Informationen landen bei uns derzeit im Chat oder im Daily. Das Problem bei den Dailys ist, dass man ganz gerne vergisst, wichtige Informationen dort zu teilen. Das Problem mit der Arbeit mit dem Chat ist meines Erachtens noch größer: Dadurch, dass der Chat ein vergleichsweise synchrones Kommunikationsmittel ist, werden dort viele Nachrichten hin- und hergeschrieben, die schnell an Aktualität oder Wichtigkeit verlieren. Das sorgt dafür, dass wichtige Nachrichten darin untergehen. Eine mögliche Alternative wäre ein dedizierter Chat-Kanal für wichtige Entscheidungen. Allerdings haben wir schon recht viele verschiedene Kanäle, was die Kommunikation nicht übersichtlicher werden lässt. Eine andere Möglichkeit bieten hier E-Mails oder das Nutzen von Confluence. Wofür wir uns entscheiden, werden wir bei der nächsten Retrospektive besprechen.

Mob-Programming ist eine gute erste Maßnahme in Remoteteams

Das Aufgleisen des Teams hat erstaunlich gut geklappt und ich kann mir vorstellen, dass bei neuen Teams das Werkzeug des Remote Mob-Programmings wieder zum Einsatz kommen wird, selbst wenn ein persönliches Treffen möglich ist. Dabei wird das Wissen gut verteilt und dadurch, dass alle remote arbeiten, gibt es kein Kommunikationsgefälle. Alternativ könnten wir uns in Zukunft zum Mob-Programming in einem Konferenzraum treffen.

Zusätzlich nutzen wir gerade die Situation, um unser Vorgehen im Hinblick auf asynchrone Kommunikation zu verbessern. Diese hätte in der klassischen Zusammenarbeit die gleichen Vorteile, dass eine selbstständigere Bearbeitung der Aufgaben erfolgen kann.

Hast Du auch neue Erfahrungen als Entwicklungs-Team in der Remote-Arbeit gemacht oder hast Du das Gefühl, dass Dein Team als verteiltes Team nicht so produktiv ist wie es sein könnte? Dann freue ich mich, wenn wir darüber sprechen und Tipps austauschen. Schreib mir doch einfach eine Mail an f.vosberg@tarent.de.