Funktioniert verteiltes Arbeiten? Nun, es kommt darauf an!

Seit etwas mehr als einem Jahr arbeite ich nun für //SEIBERT/MEDIA von zu Hause aus in ca. 250 Kilometern Entfernung. Kann agile Software-Entwicklung so funktionieren? Lässt sich der Scrum-Prozess trotz Entfernung einhalten? Verliere ich den Anschluss ans Team? Zum heutigen Zeitpunkt sage ich: Ja, es kann funktionieren!

Wie alles begann

Ende März 2015 zog es mich von Wiesbaden zurück ins Schwabenland, nachdem ich seit 2012 bei //SEIBERT/MEDIA als studentische Hilfskraft gearbeitet hatte. In einem Scrum-Team arbeite ich als Entwickler und bin dort an der Confluence-basierten Intranet-Suite Linchpin beteiligt.

Als klar war, dass ich umziehen würde, haben wir gemeinsam überlegt, ob und wie wir uns ein verteiltes Team vorstellen können. Die AgileOrg war hier die erste Anlaufstelle für eine Evaluation, und im Review stimmten meine Kollegen diesem Experiment zu. Nach drei Monaten wollten wir ein Fazit ziehen und bei negativem Ausgang würden sich unsere Wege leider trennen. So ist es glücklicherweise nicht gekommen.

Virtuelle Meetings

Im Scrum-Prozess gibt es jede Menge Meetings. Und natürlich nehme an allen teil: Daily Scrum, Sprint Planning, Backlog Grooming, Review und Retrospektive sind feste Bestandteile unserer Zusammenarbeit. Hier entsteht das erste Problem, da zu allen Meetings ein Rechner mitgenommen werden muss. Mittlerweile haben wir in vielen Meeting-Räumen fest installierte Webcams und große Monitore; das erleichtert Meetings enorm.

Die Videochat-Lösungen haben alle ihre Schwächen. Wir haben vieles ausprobiert: join.me, Skype, TeamViewer, Hangouts und natürlich das hausintern etablierte HipChat von Atlassian. Nach mehreren Versuchen verwenden wir derzeit Hangouts oder Hipchat. HipChat wird bei uns als Chat-Client genutzt und jeder Mitarbeiter ist darüber erreichbar. Leider konnte man zunächst nicht mit mehreren Personen gleichzeitig per Video sprechen. (Inzwischen ist das möglich.) Hangouts hatte diese Möglichkeit schon lange, und so sind wir dort „hängengeblieben“.

Doch nicht nur Software-seitig gibt es Optimierungsbedarf, auch die Hardware muss stimmen. Im Laptop verbaute Kameras und Mikrofone sind für eine Person direkt vor dem Monitor ausgelegt, darum haben wir eine externe Webcam und ein Raummikrofon installiert. In großen Runden wird ansonsten schnell die Rauschunterdrückung eingeschaltet.

Kommunikationshürden

Wie viele Informationen – quasi nebenbei – im Büro gestreut werden, fällt erst auf, wenn man nicht mehr vor Ort ist. Das betrifft nich nur den Flurfunk, sondern auch wichtige Infos zu Aufgaben und Zwischenständen. Hier musste sich im Team ein Paradigmenwechsel vollziehen.

Der erste Schritt war die Umstellung des analogen Papier-Boards auf ein Scrum-Board in JIRA. So ist der aktuelle Status von überall einzusehen. Desweiteren müssen alle Aufgaben mit ausreichend Informationen versehen und auch Änderungen dort dokumentiert werden. Diskussionen muss das Team ins virtuelle Ticket verlagern, um die Ergebnisse nachvollziehbar zu machen. Größere konzeptionelle Fragen werden in Confluence aufbereitet und zur Disposition gestellt. Für kurze Anmerkungen und Fragen nutzen wir einen eigenen Raum in HipChat, dort findet die Kommunikation im Tagesgeschäft statt.

War noch was? Ach ja, der Flurfunk. Der lässt sich natürlich nicht eins zu eins virtuell abbilden, aber in unserem internen Microblog im Confluence-Intranet werden viele wichtige und auch nicht so wichtige Mitteilungen in einer Timeline gepostet. Natürlich ist Kommunikation keine Einbahnstraße; auch ich muss mich im Team und im Unternehmen immer wieder ins Gedächtnis rufen, sei es in HipChat oder im Microblog.

Code-Qualität

Ob Remote oder vor Ort – die Qualität des Codes muss stimmen. Extreme-Programming-Techniken sind ein wichtiger Schritt zu besserer Software und in einem Scrum-Team eigentlich etabliert. Mit einem Remote-Kollegen wird das jedoch teilweise schwieriger. Beispielsweise ist Pair-Programming über eine große Distanz hinweg nicht ganz so einfach, wie mit seinem Stuhl zum Kollegen nebenan zu rollen. Software-Unterstützung gibt es zuhauf (zum Beispiel remotepairprogramming.com, xpairtise), doch auch hier ist die technische Seite nur ein Teil des Problems: Man muss eben immer wieder daran denken.

Code-Verwaltung mit Git ist mittlerweile Standard und quasi die Voraussetzung für ein verteiltes Entwicklerteam. Um die Qualität und den Wissenstransfer zu gewährleisten, arbeiten wir seit längerem nach dem Gitflow und mit Pull-Requests. Auch hier bedienen wir uns wieder aus dem Atlassian-Stack und nutzen Bitbucket für unsere Code-Verwaltung. Unsere Branches werden auf einem Bamboo-Build-Server (natürlich auch von Atlassian) getestet und gebaut. Eine gut organisierte IT-Abteilung ist ein nicht zu unterschätzender Faktor, denn alle Systeme sollten zwar sicher, aber von überall erreichbar sein. Mit unserem VPN ist beides gewährleistet.

Remote ist nicht Persönlich

Auf Dauer reicht virtuelle Kommunikation allein nicht aus. Hin und wieder muss ein Team persönlich und live vor Ort miteinander sprechen und sich begegnen. Wir haben uns auf einen Turnus alle vier bis sechs Wochen geeinigt, an denen ich ein bis zwei Tage im Büro in Wiesbaden arbeite.

An diesen Tage müssen alle Informationen des letzte Monats, die untergegangen sind, aufgesogen werden. Steve McConnell sagte in seinem Artikel Travel Restrictions and Offshore Development mal:

„The half-life of trust is about 6 weeks.“

Und das kann ich bestätigen. Darum sind die Besuche im Unternehmen so wichtig, denn dort kann Vertrauen wieder erneuert werden. Das machen meine Kollegen aus anderen Abteilungen (Marketing und Sales) genauso. Selbst meine Kollegin Uta, die uns in den USA repräsentiert, kommt regelmäßig aus San Diego nach Wiesbaden.

Fazit

Abschließend lässt sich sagen, dass Remote-Arbeiten viele Vorteile, aber auch Nachteile hat. Ich genieße die Ruhe zu Hause und kann meinen Tagesablauf freier gestalten, als es im Büro möglich wäre. Andererseits fehlen die persönlichen Kontakte zu Kollegen, und selbst kurze Gespräche bei einer Tasse Kaffee fallen weg.

Für mich als Entwickler ist es vom Arbeitsablauf her fast egal, von wo ich arbeite – im Büro, zu Hause oder am Strand. Diese Freiheit setzt jedoch ein hohes Maß an gegenseitigem Vertrauen und Verantwortung voraus. Beide Seiten müssen sich auf diese Form der Arbeit einstellen, und nur dann kann es funktionieren.

Artikelbild auf der Startseite: Home Office von Dylan unter CC-Lizenz

Weiterführende Infos

Acht Vorteile eines Enterprise-Gruppenchats für verteilte Teams
Vom Kick-off zum Finish – Tools für verteilte und agile Teams
Das verteilte Präsenzteam – ein Widerspruch?
Tools4AgileTeams 2014: „Agilität in verteilten und heterogenen Umgebungen“ – Keynote von Kurt Jäger

Artikel teilen:Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someonePrint this page