Das andere Ende der Leitung: Kommunikation in verteilten Teams

Remote-Arbeit ist heute gang und gäbe - auch in Scrum-Umgebungen. Ich bin selbst Teil mehrerer Remote-Konstellationen: Aktuell betreue ich als Interim ScrumMaster im Rahmen eines Kundenprojekts ein verteiltes Team. Es gehört zu meiner Aufgabe, Remote-Kollegen bestmöglich in das Team zu integrieren. Darüber hinaus gehöre ich als Consultant zum verteilten Team von Boris Gloger Consulting und tausche mich regelmäßig mit meinen Kollegen zu aktuellen Fragen und Problemstellungen aus; ich erlebe also die andere Seite, jene des Teammitgliedes. Zwei unterschiedliche Perspektiven mit interessanten Erfahrungen, aus denen ich viele Schlüsse über die Arbeit in verteilten Teams ziehen kann. Ich will hier nicht auf die allgemeinen Rahmenbedingungen verteilter Teams eingehen. Ein Blick in die Praxis beweist, dass sie in vielen Fällen nicht vorhanden sind. Ich möchte nur die wichtigsten zwei Rahmenbedingungen kurz zusammenfassen:

  • Sollte ihr Geschäftsmodell auf der Verwertung geistigen Eigentums basieren (hierzu zählt neben Bildern und Text – also auch Code –, auch das gesprochene Wort), sollten sie eine Due Dilligence im Bezug auf die Urheberrechtsbestimmungen Ihres Kommunikationstools durchführen.
  • Verteilte Teams brauchen Kommunikationsinfrastrukturen am Stand der Zeit. Jede Stunde, die ein Remote-Mitarbeiter am anderen Ende einer schlechten Telefonverbindung sitzt, ist vernichtetes Geld. Weil es sich bei remote angeschlossenen Mitarbeitern hierzulande oft um extern zugekaufte Arbeitskräfte handelt, erhält man oft sehr schnell eine gute Aufstellung darüber, wie viel Geld pro Stunde durch mangelhafte Infrastruktur verloren geht. Das ist übrigens ein gutes Argument in der nächsten Diskussion mit dem Verantwortlichen der zuständigen IT- oder Einkaufs-Abteilung. Für fehlende administrative Zugangsberechtigungen gilt übrigens dasselbe.

Die Remote-Aufgaben des ScrumMasters

Wie kann ein ScrumMaster nun die Remote-Kollegen einbinden? Oft höre ich, dass die Position des ScrumMasters nicht remote besetzt werden darf. Für meinen beruflichen Schwerpunkt als Interim ScrumMaster, der meist in existierende Organisationen kommt, ist das grundsätzlich richtig; aber nicht bedingungslos. Als Remote-Einzelkämpfer ist man oft schlechter ins Team integriert. Sei es, weil es sich um externe Arbeitskräfte handelt, die später zum Team stoßen, weil die persönliche Anbindung anders ist als im unmittelbaren Kreis des Teams, oder weil es bei der technischen Verbindung hakt. Es gibt viele Gründe, wieso Remote-Kollegen sich scheuen, Verbindungsprobleme auszusprechen oder es schlichtweg aufgeben. Aus den Augen heißt in dem Fall aber nicht aus dem Sinn. Um sich ein eigenes Bild zu verschaffen, sollte man sich auch einmal an das andere Ende der Leitung setzen, sobald man Remote-Kollegen hat, die diesen Platz besetzen.Wurden die Rahmenbedingungen für die Arbeit in einem verteilten Team durch die Organisation geschaffen, können wir damit beginnen, unser Team aufzusetzen. Auch verteilte Teams durchlaufen die klassischen Teambuilding-Phasen, es sind aber noch zusätzliche Erfolgsfaktoren zu beachten. Beginnen wir mit dem, was da sein muss, bevor es losgeht: das Vertrauen. Vertrauen wir in die Ehrlichkeit der Remote-Kollegen? Oder geht es uns in erster Linie um das Vertrauen in ihre fachliche Qualifikation? Ist Kontrolle nicht besser? Das eine gegen das andere aufzuwiegen, ist nicht nötig - aus zwei Gründen:

  • Die agile Technik degradiert Vertrauen nicht zu einem einseitigen Geschenk. Durch Peer-Working kann gegebenes Vertrauen laufend bestätigt werden oder eben nicht. Ja, wir machen Code-Reviews, „Kontrolle“ sollte dabei aber kein Gegensatz zu Vertrauen sein.
  • Und egal warum, verlorenes Vertrauen ist so oder so ein kritischer Erfolgsfaktor.

Beachten Sie als ScrumMaster vor allem auch die Kunst, aneinander vorbei zu reden. Man benötigt keinen Abschluss in Kommunikationswissenschaften, um zu erkennen, dass Menschen Sprache unterschiedlich nutzen und interpretieren. Das kann nicht zuletzt eine Frage des Kulturkreises oder der Generation sein, Stichwort „Digital Natives“. Remote-Kommunikation verliert an Gestik, Mimik, manchmal auch Tonalität. Achten Sie beim Forming eines Remote-Teams also noch stärker darauf, dass der Empfänger morgen noch weiß, wie es der Sender gemeint hat.Hoch entwickelte Teams können davon ungeachtet auch komplett remote problemlos kommunizieren. Meine Erfahrung als Berater zeigt mir aber, dass persönlicher Austausch in unserem Kulturkreis immer noch ein Grundbedürfnis jedes Teams ist. Sorgen Sie also dafür, dass sich die Teammitglieder in regelmäßigen Abständen persönlich treffen!Der erste wichtige Schritt zur Arbeit in verteilten Teams ist gesetzt: die Kommunikation funktioniert. In einem zweiten Schritt können wir nun überlegen, wie Scrum mit der Problematik umgeht.Fortsetzung folgt

Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Team
bgloger-redakteur
September 30, 2015

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen