Wie man ein agiles Vorgehen in einem Unternehmen etabliert, wird in vielen Beiträgen detailliert beschrieben. Aber wie geht eine agile Organisation mit Remote-Teams und genau einem Standort vor, um verteiltes Arbeiten zu ermöglichen und verteilte Mitarbeiter bestens zu integrieren? Warum ist es für ein Unternehmen grundsätzlich sinnvoll, sich mit dem Thema zu beschäftigen? Welche Hürden gibt es und wie überwindet man sie effektiv? Und wer eignet sich eigentlich als Remote-Arbeitgeber bzw. -Mitarbeiter? Dazu ein paar Erfahrungen und Gedanken.
Bild: Pixabay unter CC0-Lizenz
In den vorherigen Teilen haben wir die Fragen nach dem Warum und dem Wer im Hinblick auf Remote-Arbeit diskutiert. Nun beschäftigen wir uns damit, wie man vorgehen kann, um die eigentliche Einführung von Remote erfolgreich zu gestalten.
Jason Fired und David Heinemeier Hansson (REMOTE: Office Not Required) raten zu einem iterativen Vorgehen (wie wir es aus dem agilen Umfeld ja schon kennen):
A great place to start is to allow your current employees to begin working remotely.
Immer wieder weisen sie darauf hin, dass Remote-Arbeit keine Alles-oder-Nichts-Entscheidung sein muss. Solche und ähnliche Tipps finden sich zuhauf im Internet und helfen, sich einen Überblick zu verschaffen. Hier ist eine kleine Auswahl guter Quellen:
- REMOTE: Office Not Required (siehe oben)
- Work Together Anywhere - Buch und Talk von Lisette Sutherland
- Think globally, code locally: the secret to remote teams - so arbeitet Atlassian mit verteilten Teams
- Embrace Remote Work Ultimate Guide - hübsch aufbereiteter Guide von Trello
- Can you be remotely agile? - Gedanken der Agile Alliance
- Travel Restrictions and Offshore Development - schon etwas älter, aber nicht minder interessant
Wie alles begann
Bild: Pixabay unter CC0-Lizenz
Als Ende 2014 der Entschluss zum Umzug ins 250 Kilometer entfernte Reutlingen fiel, war Remote-Arbeit bei //SEIBERT/MEDIA nicht allzu weit verbreitet. Lediglich ein Kollege im Marketing, der sich hauptsächlich um unseren Blog kümmert, arbeitete schon damals von Potsdam aus. Ob das auch für ein klassisches Scrum-Team funktionieren würde, konnte keiner sagen. Wir entschlossen uns zu einem agilen Vorgehen – inkrementell in kleinen Schritten.
Da das Thema verteiltes Arbeiten im Unternehmen teils durchaus kritisch betrachtet wurde, nahmen wir uns vor, den gesamten Evaluierungsprozess so transparent wie möglich zu gestalten. Dafür starteten wir eine AgileOrg-Story, in der wir Informationen sammelten und Dinge ausprobierten. Am Ende gab es kein Veto gegen ein dreimonatiges Experiment. (Den Rest der Geschichte beschreibt dieser Artikel: Funktioniert verteiltes Arbeiten? Nun, es kommt darauf an!) Nach drei Jahren bin ich immer noch Remote und habe mittlerweile sechs "verteilte" Kollegen aus allen Fachteams.
Viele kleine Schritte
Bild: Shamia Casiano unter Pexels License
Remote beginnt, sobald ein Mitarbeiter nicht im Teambüro sitzt, um zu arbeiten. Home-Office ist in vielen modernen Unternehmen möglich und eine einfach Möglichkeit, Remote-Luft zu schnuppern. Ohne großen Aufwand kann man auch damit beginnen, sich für einen gewissen Zeitraum in einem anderen Team "einzunisten". Das kostet erst einmal kein Geld und hält das Risiko möglichst gering, zudem fördert es den Austausch zwischen den Teams.
Wenn schon ein (halber) Tag Remote größere Vorbereitungen und Absprachen notwendig macht, ist das einer der ersten Punkte, die angegangen werden sollten. In meinem Fall war das beispielsweise die Umstellung vom analogen zum digitale Scrum-Board. Vor der Umstellung hatten wir alle Aufgaben auf Papier ausgedruckt und an ein großes Whiteboard gehängt. Wenn nun ein Kollege Home-Office machen wollte, musste er sich am Abend davor auf einen Task hängen bzw. vorab sagen, woran er arbeiten würde. Mit einem digitalen Board gibt es weiterhin eine "Single Source of Truth" - mit dem Unterschied, dass diese von überall eingesehen und geändert werden kann.
Klappt es mit einem Tag, kann man durchaus zwei, drei Tage oder eine ganze Woche Remote arbeiten. Dann zeigen sich meist sofort weitere Schmerzpunkte. Denn ein Tag lässt sich sehr gut vorab planen und besprechen. Bei mehreren Tagen am Stück werden die vorhandenen Kommunikationskanäle immer wichtiger. E-Mail, Chat, Video müssen funktionieren und alle Team-Mitglieder sollten sich darauf einstellen. Beim Standup oder in anderen Meetings muss das Team daran denken, Remote-Kollegen rechtzeitig zuzuschalten. Der Chat muss aktiv genutzt werden, um Fragen via Remote beantworten zu können. Entscheidungen und Erkenntnisse müssen auffindbar im Wiki oder in Jira liegen.
Schwächen in der technischen Infrastruktur und vor allem beim Zugriff auf wichtige Systeme werden durch solche Experimente schnell ersichtlich. Per VPN kann man sich bei uns in alle großen Systeme einklinken und dennoch gab es am Anfang immer wieder kleinere Anwendungen, die nur innerhalb des Büros erreichbar waren. Hier hilft ein guter Draht zur IT bzw. eine Vorabsprache mit einem Kollegen aus diesem Team. Mittlerweile arbeiten übrigens auch die Kollegen im Büro via VPN – die Arbeit von Remote-Mitarbeitern war hierfür ein guter Beta-Test.
Feel the pain
Bild: Pixabay unter CC0-Lizenz
In meinem Team bin ich der einzige Remote-Mitarbeiter. Das birgt die Gefahr, dass die Kollegen vor Ort überhaupt nicht einschätzen können, mit welchen Hürden ich im Exil teils zu kämpfen habe. Um bei den Bürokollegen Verständnis zu schaffen, aber auch, um sie an den Vorteilen der Remote-Tätigkeit teilhaben zu lassen, kann es durchaus sinnvoll sein, Einzelpersonen oder gar ein ganzes Team zeitweise verteilt arbeiten zu lassen. Da geht es nicht nur um eine eintägige Home-Office-Session, sondern auch um mehrere Tage. Dieses Vorgehen hat bei unserer Remote-Einführung dazu geführt, dass sich alle mit dem Thema beschäftigt haben und tolle Impulse entstehen konnten.
Außerdem haben wir darauf geachtet, möglichst viele unserer Erkenntnisse im Unternehmen zu teilen. Anhand von Blog-Artikeln und kurzen Status-Updates konnte jeder Kollege den aktuellen Stand nachvollziehen. Auch das schafft Akzeptanz und Verständnis und zusätzlich Neugierde auf unsere Lösungen: Immer wieder kamen Kollegen auf mich zu und fragten nach bestimmten Vorgehensweisen oder der technischen Infrastruktur.
Absprache ist alles
Bevor es ernst wird, sollten auf jeden Fall die Rahmenbedingungen geklärt werden. Das betrifft nicht nur eigene Team, sondern auch andere Fachteams wie Personal oder interne IT.
In meinem Fall haben wir beispielsweise festgelegt, in welchen Intervallen ich für ein, zwei Tage direkt vor Ort im Büro bin. Wir halten einen Zeitraum von vier bis sechs Wochen für die optimale Zeitspanne. Ich versuche dabei, immer zum Ende eines Sprints da zu sein, um persönlich an der Retrospektive teilnehmen zu können.
Auch für die Zeit, in der ich zu Hause arbeite, gebe ich durch ein kurzes "Hallo" bzw. "Tschüss" im Chat zu erkennen, ob ich gerade erreichbar bin oder nicht. Das gilt andersherum ebenso. Und auch meine Kollegen außerhalb des Team müssen abgeholt werden: Gerade am Anfang gab es oft Hemmungen, mit mir in Kontakt zu treten, weil die Kanäle nicht klar oder die Tools nicht eingerichtet waren. Mittlerweile sind Video-Calls im Unternehmen Normalität, was auch damit zusammenhängt, dass wir inzwischen drei Standorte haben (auch eine Form von Remote-Arbeit).
Bild: SpaceX unter CC0-Lizenz
Während und nach der Einführung ist es hilfreich, Schmerzpunkte immer wieder anzusprechen und direkt zu justieren (Inspect & Adapt). Größere Themen können in einer Retrospektive oder einem eigenen Meeting bearbeitet werden. Wichtig ist auch hier, immer flexibel und pragmatisch heranzugehen: Es muss nicht direkt die riesige Remote-Station mit großen Bildschirmen sein, für den Anfang reicht bereits ein Laptop.
Das Schöne an diesem Vorgehen ist, dass es jederzeit unterbrochen (sofern der Umzugstermin nicht allzu nah ist) und ohne großen Aufwand ganz gestoppt werden kann. Doch auch wenn das Remote-Experiment als solches scheitern sollte, werden alle Teammitglieder von den Veränderungen profitieren. Ist das Experiment jedoch erfolgreich, sind die größten Fallgruben bereits zugeschüttet, bevor es wirklich ernst wird.
Damit ist die Trilogie zur agilen Remote-Transition abgeschlossen. Wer sich für den Alltag nach der Einführung interessiert, den möchte ich auf die Blog-Posts in der Reihe Mein Remote-Sprint verweisen.
Weiterführende Infos
Alle Artikel der Reihe zur Remote-Transition
Funktioniert verteiltes Arbeiten? Nun, es kommt darauf an!
Vom Kick-off zum Finish – Tools für verteilte und agile Teams
Der neue Meeting-Raum von Google: Hardware für bessere verteilte Meetings
Mehr über die Creative-Commons-Lizenz erfahren
