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 TeamsJeff Sutherland: Hyperproductive Distributed Teams

Agile Toolbox
Scrum
Scrum-Begriffe
Team
bgloger-redakteur
June 14, 2012

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