Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Teams – co-located, distributed, dispersed

Co-located, distributed and dispersed? The good the bad and the ugly?

Wer würde es bei der Zusammenstellung eines Scrum Teams nicht vorziehen, alle Teammitglieder auf einem Flur anzusiedeln? Im besten Fall nicht länger als eine Schulbuslänge entfernt und erst recht ohne Kommunikationskiller namens Treppe. Und so sehr auch darauf hingewiesen wird, dass sich regelmäßige Besuche für die persönliche Zusammenarbeit garantiert auszahlen, sieht die Realität in den Unternehmen doch oft anders aus. Nichtsdestotrotz können auch verteilte oder zerstreute Teams die Vorteile von agiler Entwicklung nutzen. Laut Jeff Sutherland gibt es sogar verteilte Teams, die produktiver sind als ihre co-located Kollegen, da die geographische Distanz die Teams dazu veranlasst, häufiger das Gesamtbild, die Vision, das große Ganze zu betrachten, um das gemeinsame Ziel und nicht die Distanz zu fokussieren.

Doch welche Möglichkeiten gibt es überhaupt, unterschiedliche Teammitglieder oder ganze Teams für die Scrum-Welt aufzustellen?

Neben co-located teams unterscheidet man grundsätzlich zwischen distributed und dispersed teams.

distributed (verteilt)
dispersed (zerstreut)
Von distributed teams spricht man, wenn mehr als ein Team an einem Produkt arbeitet, die einzelnen Teams in sich jedoch an einem Standort zusammenarbeiten können. Z.B. Ein Team in Deutschland und ein Team in Indien. Von dispersed teams hingegen spricht man, wenn ein Team in sich aus Mitgliedern von unterschiedlichen Standorten besteht. Z.B. ein Mitglied aus Deutschland, eins aus den USA, eins aus Indien und ein weiteres aus China.
Voraussetzungen
  • notwendiges Wissen ist an dem Standort / im Team vorhanden oder kann aufgebaut werden
  • Überschneidung der Arbeitszeit notwendig
  • alternative Kommunikationsmittel stehen zur Verfügung
Vorteile
  • vereinfacht teaminterne Kommunikation
  • Zeitzonenunterschiede fallen nicht so stark ins Gewicht
  • Scrum-Meetings können mit herkömmlichen Methoden durchgeführt werden
  • kulturelle Unterschiede müssen nur in den Skalierungs-Meetings berücksichtigt werden
  • häufige Interaktion hilft kulturelle Unterschiede zu verstehen, gemeinsame Arbeitskultur zu entwickeln
  • Mitglieder des PO-Standorts können Informationen schnell beschaffen und weitergeben
  • Gleichbehandlung der Standorte – kein oder weniger hier/dort-Denken
  • Kommunikation zwischen den Teams wird zum einen durch Teamzugehörigkeit und zum anderen durch Standortzugehörigkeit erhöht
Nachteile
  • möglicherweise kein PO vor Ort, unterschiedliches Verständnis der Anforderungen
  • Teams treffen ggf. unterschiedliche Entscheidungen aus unterschiedlichen Gründen – wenig Austausch
  • Zusammengehörigkeitsgefühl entsteht nicht länderübergreifend
  • Kommunikation nur „unpersönlich“ möglich
  • Koordination und Organisationaufwand steigt
  • Diskussionen bzw. Ergebnisse, die an den einzelnen Standorten durchgeführt werden gelangen zu den Teammitgliedern an den anderen Standorten

Wie bei jedem anderen Team erfordert es harte Arbeit von allen Beteiligten, bis die Teams ihr Potenzial nutzen und ständig ausbauen können. Und wie so oft gibt es keine one fits all Lösung. Jedoch sollte man sich die Frage stellen, wie bewusst die Entscheidung für die eine oder andere Aufteilung gefallen ist. Das Ausprobieren unterschiedlicher Konstellationen führt zumindest dazu, dass das Team die Vor- und Nachteile selbst einschätzen und ggf. flexibel damit umgehen kann. Vielleicht macht es sogar Sinn, die Zusamenstellung innerhalb des Projekts zu verändern – je nach Anforderungen aus dem Produkt oder Ergebnissen der Retros.Und im Zweifel: ask the team(s).

Wie sind eure Erfahrungen?

 

Literatur:

Cohn, Mike: Agile Softwareentwicklung: Mit Scrum zum Erfolg!

Eckstein, Jutta: Agile Softwareentwicklung mit verteilten Teams

Jeff Sutherland: Hyperproductive Distributed Teams