Wer schon mal in Projekten mit räumlich verteiltem Setup gearbeitet hat, kennt das vermutlich: Remote-Meetings laufen immer gleich ab: Menschen treffen sich in unterschiedlichen Städten oder Länden in Videokonferenzräumen (bestenfalls) oder jeder sitzt an seinem Rechner mit Headset (schlimmstenfalls) und macht nebenbei etwas anderes. Die Beteiligung ist eher gering. Manchmal unterhalten sich die Teilnehmer eines Standorts untereinander und die anderen hören zu (bestenfalls). Auch beliebt: einzelne Standorte schalten ihre Mikrofone aus und unterhalten sich zeitgleich (schlimmstenfalls) oder zwei Teilnehmer in unterschiedlichen Standorten führen einen Dialog und der Rest dämmert langsam weg.

Mein Kollege Martin und ich sind zurzeit in so einem Projekt. Fünf Teams verteilt auf drei Länder. Dabei ist die Ausstattung eigentlich gut, es gibt Multi-Point-Videoconferencing, Skype for Business für Desktopsharing oder als Video-Notlösung ist auch vorhanden. Und trotzdem lässt sich das beschriebene Verhalten bei uns in nahezu jedem Remote-Meeting beobachten.

Challenge accepted!

Anfang des Jahres wurde Martin und mir die Leitung einer projektinternen Arbeitsgruppe angetragen. Das Ziel (ist hier eigentlich nur bedingt relevant): Ausarbeiten einer neuen, gemeinsamen Teststrategie (die alte war etwas angestaubt und erbrachte nicht den nötigen Grad an Sicherheit). Das wichtige an dieser Aufgabe ist das „gemeinsam“ – dazu muss man wissen, das wir beide Teil eines zentralen Architekturteams (ich vermeide das Wort „Elfenbeinturm“ bewusst, denn über Sinn oder Unsinn eines solchen Setups soll jetzt hier nicht diskutiert werden) sind, das in der Vergangenheit immer wieder zu Konflikten mit den Developmentteams geführt hat (und immer noch führt).

In der Vorbereitung der Arbeitsgruppe stand für uns schnell fest, dass es nicht darauf hinauslaufen durfte, dass die zentrale Architektur eine Teststrategie vorgibt, wenn diese tatsächlich erfolgreich gelebt werden soll. Wir mussten also alle Teilnehmer der Workgroup dazu animieren, sich gleichermaßen einzubringen um am Ende hinter dem Erarbeiteten zu stehen. Gleichzeitig war es uns wichtig, das Thema strategisch aufzuarbeiten und zu motivieren, statt die Teilnehmer, die viele gute Ideen im Kopf hatten, einfach loslaufen zu lassen.

Schnell war uns klar, dass das extrem schwierig werden würde, wenn wir versuchen, das Ganze in den typischen, lethargischen Remote-Meetings zu erarbeiten. Aus verschiedenen Gründen war es auch keine Option, an einem Standort zusammenzukommen und das Thema geballt zu bearbeiten.

Mit den Gewohnheiten brechen

Also haben wir uns einen Roten Faden für die Moderation zurechtgelegt (dafür noch kurzerhand ein zufällig zeitgleich stattfindendes SoftSkill-Training gehijackt – danke, Kim!) und eine Workshop-Reihe, mit dem Ziel ausgearbeitet, Maßnahmen zu beschließen, um die bisherige Teststrategie schrittweise zu verbessern. Der Clou dabei: Die Umsetzung der erarbeiteten Maßnahmen haben wir anschließend als UserStories in das Product Backlog einfließen lassen und so eine planbare und transparente Abarbeitung ermöglicht. Agile FTW! Aber das nur am Rande ?

Der wesentliche Unterschied unserer Workshops zu den typischen Meetings: Wir wollten die Teilnehmer die Inhalte in kleinen Gruppen erarbeiten lassen (wem das jetzt nicht sonderlich revolutionär erscheint, der erinnere sich bitte an das verteilte Setup) und trotzdem eine Durchmischung der einzelnen Standorte erreichen. In der Spitze haben wir dazu für einen dreistündigen Workshop fünf Meetingräume blockiert!

Drei solcher Workshops haben wir durchgeführt, haben Zieldefinition, Gap- und 5-WHY-Root-Cause-Analyse, Bewertung und Priorisierung mit Hilfe einer HeatMap gemacht, bis wir am Ende die UserStories hatten, mit denen wir dann gestartet sind. Das Ergebnis konnte sich sehen lassen: Alle Beteiligen hatten einen Plan, was getan werden musste, um die Teststrategie zu verändern. Und noch besser: Alle wussten warum und hatten den Plan selbst gestaltet.

Und was haben wir gelernt?

Die Vor- und Nachbereitung der Workshops hat Martin und mich einige Zeit gekostet und die Moderationen der Sessions waren ziemlich anstrengend. Doch am Ende steht die Erkenntnis: Remote-Meetings müssen nicht nach Schema F ablaufen. Man kann ihnen mit etwas Mut und Planung durchaus echten Workshopcharakter verleihen. Aber vor allem sind die Ergebnisse besser und – ebenfalls nicht ganz unwichtig – vom gesamten Team akzeptiert.

^{Beitragsbild: „A Teliris VirtualLife high resolution telepresence system in use (Courtesy of: Teliris)“ (resized) von Fuelrefuel, CC BY-SA 3.0, http://bit.ly/2aIlOy0}