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
Vorteile
Nachteile
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