Eigentlich hatte ich ursprünglich einen Blogpost zu den Challenges der heutigen Teamarbeit verfasst. Nun trafen uns – kurz vor dem geplanten Veröffentlichungsdatum - die Auswirkungen des COVID-19 Virus mit voller Wucht. Eines gleich vorneweg: wir maßen uns nicht an, in diesem Blogpost medizinischen Ratschläge zu verbreiten, dies überlassen wir natürlich den Experten in dieser Domäne. Wir wollen vermitteln, mit welchen Methoden man auch unter schwierigen Voraussetzungen in einem räumlich verteilten Team effizient arbeiten kann.
Wie es der Zufall so will, gibt es einige Parallelen zwischen den Herausforderungen unserer heutigen Teamarbeit und den Auswirkungen der aktuellen Krise auf die Arbeitswelt der Knowledge-Worker, zu denen auch wir uns zählen. Eine allgemein vertretene Empfehlung ist, Kontakte mit anderen Menschen auf das Nötigste zu reduzieren, um die rasante Verbreitung des Virus so gut als möglich einzubremsen, Stichwort #FlattenTheCurve und #SocialDistancing. Dies betrifft neben dem Privatleben natürlich auch den Arbeitsplatz, an dem die meisten Menschen viel Zeit verbringen.
Speziell im IT-Bereich liegt nun „Teleworking“ als DIE Lösung für die vom umsichtigen Arbeitgeber ermöglichte Isolation der MitarbeiterInnen auf der Hand. Doch ist es ausreichend, einfach den Laptop mit nach Hause zu nehmen und sich mittels VPN ins Büro zu verbinden? Natürlich nicht!
Selbst ohne die aktuell neu hinzugekommenen Herausforderungen führen fragmentierte Arbeitszeiten durch Teilzeit, etc., mit der Zeit ganz automatisch anwachsende Ansammlungen von vielen parallel laufenden Projekten, Teams und Teammitgliedern in einem projektgetriebenen Unternehmen wie dem unseren früher oder später zu Komplexitäten.
Wir wollen dies zum Anlass nehmen und in den folgenden Zeilen einen Einblick geben, wie wir mit diesen Herausforderungen in unseren Entwicklungsteams umgehen. Gleich vorneweg: es macht Sinn, sich gängige Praktiken von (Full-) Remote Teams abzuschauen.
Optimize for Single Player Mode
Der Begriff „Optimize für Single Player Mode“ wurde in einem Talk von Andreas Klinger, der sich intensiv mit global verteilten Remote Teams auseinandersetzt, geprägt. Gemeint ist damit, dass jedes Teammitglied zeitlich und örtlich unabhängig vom Rest des Teams produktiv sein können soll. In der Praxis bedeutet das: wenn ich als Developer gerade als einziger arbeite, während der Rest meines Teams am anderen Ende der Welt aufgrund der Zeitverschiebung schläft, so möchte ich das von mir entwickelte Feature sofort und selbstständig ins Produktivsystem deployen können.
Ein Schlüsselfaktor, um dieses Ziel zu erreichen, ist ein möglichst hoher Grad an Automatisierung. Dazu zählt in erster Linie eine automatisierte Build-Pipeline, in der Testing von Funktionen und Codequalität, Codeoptimierungen (Linter, …), Build und Deployment ohne jegliche manuellen Eingriffe ablaufen.
Wir versuchen bei möglichst vielen unserer Produkte und Projekte solche Build-Pipelines aufzubauen, da diese auch z.B. im Hinblick auf Code-Qualität viele Vorteile bieten.
Single Point of Truth
Ein weiterer wichtiger Aspekt ist das Wissensmanagement. Je weniger gemeinsame Zeit im Team bleibt, um miteinander zu reden, desto wichtiger ist eine strukturierte Dokumentation. Bei unseren Projekten beginnt dies mit einem standardisierten Projekthandbuch, welches quasi das Inhaltsverzeichnis – „Wo finde ich was?“ - eines jeden Projekts darstellt. Die Struktur dieses Projekthandbuches basiert auf der Vorgehensweise in PRINCE2, dem von uns primär eingesetzten Framework für Projektmanagement.
Hier finden sich alle relevanten Informationen (entweder als Teil des Handbuchs selbst oder in Form eines Verweises auf andere Tools/Dokumente), sodass jedes Teammitglied sofort weiß, wo Informationen zu finden sind, falls grad niemand in Reichweite sein sollte, um eine direkte Frage zu stellen.
Natürlich werden nicht alle Informationen direkt im Handbuch gepflegt. Backlogs beispielsweise werden bei uns in Azure DevOps Projekten verwaltet, kleinere Tasks managen wir auch gerne im Planner.
Dass der Source Code in einem Projekt-spezifischen GIT-Repository verwaltet wird, muss man wohl nicht extra erwähnen.
Asynchrone (Non-Email-) Kommunikation
In Projekten verwenden wir Microsoft Teams als internes Kommunikationstool. Ein zentraler Vorteil ist, dass Informationen nicht in einzelnen Mailboxen versanden, sondern in einem Channel für alle sichtbar gemacht werden. Es kann also jedes Team-Mitglied mit- oder nachlesen was gerade passiert – sei es der Kollege im HomeOffice, ein Teilzeit-Mitarbeiter, jemand der gerade vom zweiwöchigen Urlaub zurückkommt oder der Projektleiter, der wieder mal den ganzen Vormittag in Telkos verbracht hat. Damit dies funktionieren kann, muss ein Team natürlich so diszipliniert sein und wichtige Themen explizit schriftlich im Channel diskutieren oder zumindest nachträglich in selbigem dokumentieren.
Der asynchrone Aspekt hilft uns zum Beispiel bei den zu Beginn angesprochenen ungleichmäßig verteilten gemeinsamen Projektzeiten im Team (Vollzeit vs. Teilzeit, …). Zugleich ist es aber auch immer wieder notwendig, sich explizit Freiräume zu schaffen, indem man mal eine Zeit lang nicht erreichbar ist, alle Notifications abdreht, um sich voll und ganz auf die Umsetzung eines komplexen Features konzentrieren zu können.
Quelle: https://blog.remote.com/why-you-should-be-doing-async-work/
Es gilt natürlich: direkte Face2Face-Kommunikation (Bonuspunkte gibt’s für ein ergänzendes Whiteboard) ist und bleibt die effizienteste Form der Kommunikation - auf die wir wohl allerdings in nächster Zeit weitgehend verzichten müssen.
All hail Teams
Neben den oben erwähnten Aspekten verwenden wir Teams auch, um mittels Videokonferenzen Daily Standups mit Kollegen im HomeOffice abzuhalten, uns regelmäßig mit unseren Kunden abzustimmen oder auch, um durch Screen Sharing schneller und einfacher Inhalte zu vermitteln, die bei einem herkömmlichen Telefonat mühsam umschrieben werden müssten.
Für Interessierte bietet mein ACP-Kollege Christian Decker hier ein kleines Tutorial, wie man virtuelle Meetings mit Teams abhält: Mein erstes virtuelles Meeting mit Microsoft Teams. Microsoft Teams kann übrigens auch in einer kostenlosen Variante von jedermann genutzt werden.
Abgesehen vom reinen Kommunikationstool verwenden wir Teams und seine vielfältigen Integrationsmöglichkeiten aber auch als Information-Hub im Projekt, indem wir wichtige Websites, SharePoint Document Libraries, Azure DevOps Boards/Dashboards und vieles mehr in die Team-Channels integrieren, um die Wege um an Informationen zu gelangen möglichst kurz zu halten.
Nicht zu unterschätzen ist auch der Einfluss des Giphy-Plugins, das auch in herausfordernden Projektphasen den Spaß zwischendurch nicht zu kurz kommen lässt. 😊
Recap
Vor einiger Zeit bin ich im Internet (Quelle nicht mehr auffindbar) über folgende Aussage gestolpert: „Als Information Worker ist die Frage nicht mehr ob du remote arbeitest, sondern wie viel“. Ich kann diesem Satz einiges abgewinnen, und wie ich hoffentlich vermitteln konnte, sehe ich in vielen Ansätzen das Potential, mit den kleinen und auch wie aktuell sehr großen Herausforderungen der heutigen Zeit besser zurechtzukommen. Abschließend kann man sagen, dass auch wir uns in einer stetigen Lernphase befinden und uns durch Ausprobieren und Experimentieren mit jedem Projekt ein kleines bisschen weiterentwickeln.
Zum Abschluss noch ein paar Tipps zum Thema Remote Arbeit vom großartigen @shanselman:
https://twitter.com/shanselman/status/1237532666662019072
Referenzen:
Share this
Software Architekt – digitaler Rockstar der Softwareentwicklung
Die besten Passwörter sind die, die ich nicht wissen muss!
