---

Wie lässt sich Scrum für verteilte und große Projekte skalieren? Die Antwort könnte Sie überraschen!

Das bisher beschriebene Scrum Framework funktioniert am besten mit einem Scrum Team an einem Standort. In der Praxis kann ein einzelnes Team ein Projekt jedoch häufig nicht vollständig umsetzen, oder seine Mitglieder sind auf mehrere Standorte verteilt.

Reicht ein Team nicht für die Produktbedürfnisse aus, kann die Organisation weitere Teams erwägen. Geografische Verteilung allein verlangt das nicht. Mehr Menschen können zudem die Koordinationskosten erhöhen. Oft beobachten wir auch Teams an weit entfernten Standorten oder auf unterschiedlichen Kontinenten.

Es gibt zahlreiche Gründe für die Verteilung von Teams:

• Technische Gründe: Das Wissen für einzelne Softwarekomponenten ist am Hauptsitz nicht verfügbar,
• Fachliche Gründe: Bestimmte Fähigkeiten fehlen vor Ort. Testautomatisierung, Oberflächengestaltung oder die Einbindung fremder Software können externe Fachleute erfordern,
• Größenbedingte Gründe: Für eine Lieferung im vorgegebenen Zeitraum werden mehr Personen benötigt, als sinnvoll in ein Scrum Team passen. Mehrere geschlossene Teams können dann besser sein als die unbegrenzte Vergrößerung eines Teams,
• Geschäftliche Gründe: Günstigere Standorte oder kontinuierliche Arbeit mit Ingenieuren verschiedener Zeitzonen können einen überzeugenden wirtschaftlichen Nutzen bieten.

Da Kommunikation ein fester Teil von Scrum ist, müssen alle Mitglieder die Herausforderungen verteilter Zusammenarbeit angehen. Alle sollten Zugang zu Audio- und Videokonferenzen sowie Bildschirmfreigabe haben.

Übliche Projektmanagementwerkzeuge unterstützen gesunden, kontinuierlichen Austausch: Product Backlogs, Sprint Backlogs, Störungslisten und Plattformen für Wissen und Neuigkeiten.

Projektorganisation: mehrere Teams

Die einfachste Erweiterung von Scrum für größere Projekte ist die Erhöhung der Teamzahl am gleichen Standort.

Müssen mehrere Teams zusammenarbeiten, sollte ihre Anzahl schrittweise wachsen.

Was bedeutet das für Sie?

Mehrere Teams an einem Standort

Schrittweises Wachstum ist meist leichter zu bewältigen als der gleichzeitige Start von zehn Teams. Beginnen Sie mit einem Scrum Team und ergänzen Sie nach erfolgreichen Sprints ein oder zwei weitere. Wenn diese Teams (mehr über Mehrere Scrum Teams) gut zusammenarbeiten, können weitere Teams zur verteilten Projektorganisation hinzukommen.

Die Teamzahl erhöhen

Zwei typische Wege zur Bildung neuer Scrum Teams sind:

• Ein bestehendes Team aufteilen und bei Bedarf neue Mitglieder ergänzen,
• Ein neues Team aus Ingenieuren aufbauen, die bisher nicht am Projekt beteiligt waren.

Die Aufteilung nutzt das Wissen und die Erfahrung bestehender Teammitglieder.

Neue Teams sind dadurch meist schon bei ihrer Entstehung teilweise produktiv. Nachteilig ist, dass ein vollständig eingespieltes Team geteilt wurde. Das kann die Motivation beeinträchtigen. Besonders gilt dies ohne vorherige Ankündigung und Begründung durch die Führung, wenn die Mitglieder mental und technisch unvorbereitet sind.

Bei völlig neuen Teams können bestehende Teams ihre Struktur und Sprints beibehalten. Koordination, Einarbeitung und Integration verlangen weiterhin Aufmerksamkeit. Der Wissensaufbau und das Hochfahren der neuen Teams dauern jedoch länger.

Unabhängig vom gewählten Weg gelten folgende Grundsätze:

• Mit wenigen Scrum-Teams beginnen,
• Die Teamzahl schrittweise erhöhen,
• Während Veränderung und Wachstum Arbeitskontinuität und reibungslose Lieferung von Software und Geschäftswert sichern,
• Bei wesentlichen Produktivitäts- oder Kontinuitätsproblemen zuerst diese lösen, statt weitere Teams hinzuzufügen.

Projektorganisation: verteilte Teams

Die größte Komplexität entsteht bei mehreren Standorten. Kommunikationsbarrieren, schwierige Arbeitsabstimmung und unterschiedliche Vorstellungen gemeinsamer Projektnormen sind nur einige Beispiele.

Mehrere Teams an mehreren Standorten

Wer diese Herausforderungen nicht löst, muss mit schweren Folgen rechnen.

Unternehmen verschwenden Milliarden Dollar an IT-Budget, weil ihnen Fähigkeiten fehlen in Organisationsführung und Skalierter Scrum-Expertise.

Vier wichtige Empfehlungen helfen:

• Stellen Sie sicher, dass neue Mitglieder im Scrum Framework geschult werden als Scaled Scrum Expert,
• Führen Sie neue Mitglieder angemessen ins Projekt ein, damit sie technische und geschäftliche Ziele verstehen und Entscheidungen für einen höheren Wertbeitrag treffen können,
• Vereinbaren Sie Projektnormen. Wie ein einzelnes Team Regeln für Kommunikation, Planung und Ausführung besitzt, benötigt auch eine Mehrteamorganisation gemeinsame Regeln für Zusammenarbeit, Problemlösung und Wertlieferung.
• Lassen Sie neue Mitglieder zumindest vorübergehend mit erfahrenen Projektmitgliedern arbeiten. Standortbesuche und Lernen bei der Arbeit sind dafür möglich und erwünscht. So wird Wissen übertragen und ein persönlicher Dialog in beide Richtungen zwischen Teams und Standorten aufgebaut.

Virtuelle Teams

Auch die Mitglieder eines einzelnen Scrum Teams können über mehrere Standorte verteilt sein. Dies wird „virtuelles Team“ genannt.

Die Hauptaufgabe ist reibungslose Kommunikation. Alle vorgeschriebenen Scrum Events bleiben notwendig, obwohl nicht alle im gleichen Raum sind.

Virtuelle Teams

Mitglieder an einem Standort können bei Bedarf gemeinsam arbeiten, sofern entfernte Mitglieder vollständig teilnehmen können. Sie nutzen stärker Kommunikations- und Kooperationswerkzeuge und verbinden sich etwa aus einem gemeinsamen Besprechungsraum per Video mit dem übrigen Team.

Scrum-Product-Owner-Team

Wie mehrfach erläutert, ist regelmäßige Kommunikation zwischen Product Owner und Scrum Team entscheidend für erfolgreiche Lieferung.

Teams an verschiedenen Standorten benötigen wirksamen Zugang zu Produktentscheidungen. Für ein Produkt teilen sie einen Product Owner, ein Produkt-Ziel und ein Product Backlog. Der Product Owner kann unterstützende Arbeit delegieren, bleibt aber ergebnisverantwortlich. Ein gesonderter verantwortlicher Product Owner je Team ist nicht erforderlich.

Diese Ausgabe beschreibt ein „Scrum Product Owner Team“ und einen „Chief Scrum Product Owner“ als organisatorisches Kooperationsmuster. Delegierte und Produktspezialisten können unterstützen, sind aber keine zusätzlichen Scrum-Ergebnisverantwortlichkeiten und ersetzen nicht den einen Product Owner für ein Produkt.

Mit dieser Unterstützung konzentriert sich der verantwortliche Product Owner darauf, dass:

• Das richtige Produkt für die Kundenbedürfnisse entsteht,
• Product Owner und Delegierte wirksam zusammenarbeiten und den Teams bei der Schaffung von Geschäfts- und Technikwert helfen.

Der Product Owner bleibt für wirksames Backlog-Management verantwortlich. Andere Kompetenzen und Stakeholder können die Anforderungsarbeit unterstützen. Dazu gehören Vertreter des Business Case, relevante Stakeholder sowie Unternehmens- und Technologiearchitekten.

Bei einem gemeinsamen Produkt arbeiten alle aus einem geordneten Backlog auf ein gemeinsames Produkt-Ziel hin. Jedes Team liefert bestimmte Stories; manche erfordern jedoch Beiträge und Ergebnisse mehrerer Teams.

Komponenten- und Feature-Teams

Arbeit kann verteilt werden, indem Teams bestimmte Softwarekomponenten oder Funktionen verantworten. Deshalb heißen sie „Komponententeam“ oder „Feature-Team“.

Komponententeams

Jedes Team setzt ausschließlich bestimmte Komponenten des Gesamtsystems um. Für eine User Story muss die Arbeit meist in kleinere Teile je Komponente zerlegt werden. Abhängigkeiten machen kontinuierliche Integration zu einem unverzichtbaren Bestandteil erfolgreicher Lieferung.

Scrum-Product-Owner-Team

Sie können die Lieferung einer vollständigen Funktion im Sprint erschweren. Zusammenarbeit und Integration müssen das lösen: Teams am selben Produkt brauchen ein integriertes, nutzbares Inkrement gemäß ihrer gemeinsamen Definition of Done.

Dadurch wachsen Losgrößen und Durchlaufzeiten der laufenden, noch nicht integrierten Arbeit. Das ist ungünstig, da Scrum-Teams lieferbare Inkremente in kleinen Losen und mit kurzen Durchlaufzeiten anstreben sollten.

Komponententeams erleichtern dagegen den Aufbau von Architektur- und Designwissen für einzelne Komponenten. Das kann für Komponenten mit Forschungs- und Innovationsbedarf besonders wertvoll sein.

Ihre Mitglieder spezialisieren sich jedoch nur auf Teile des gesamten Systems. Dabei können Gesamtüberblick und Verständnis für den geschäftlichen Zweck der Funktionen verloren gehen.

Kunden bezahlen uns nicht für Komponenten, sondern für Funktionen, mit denen sie ihr Geschäft betreiben. Ohne konsequenten Funktionsfokus können Gesamtoptimierung und Integration mehr Zeit benötigen. Entscheidungen für die Optimierung einzelner Komponenten schaffen möglicherweise unsichtbare Engpässe für die Leistung der Gesamtlösung.

Komponententeams

Feature-Teams

Sie verantworten die vollständige Umsetzung von User Stories aus dem Product Backlog. Teams werden nicht mehr nach Komponenten getrennt. Jedes liefert eine vollständig funktionierende Funktion und den zugehörigen Geschäftswert.

Feature-Teams

Die Mitglieder besitzen funktionsübergreifende Fähigkeiten und handeln möglichst autonom für schnelle Lieferung. Das Team bewahrt Systemwissen, wodurch die Integration seiner Funktionen leichter wird.

Allerdings kann tieferes Komponentenwissen schwieriger aufzubauen sein. Ein autonomes, schnell lieferndes Team zu entwickeln braucht Zeit, weil funktionsübergreifende Zusammenarbeit nicht einfach entsteht. Dennoch erledigen solche leistungsstarken Teams in den meisten Organisationen die Arbeit – vermutlich auch in Ihrer.

Wie wählen wir zwischen Komponenten- und Feature-Teams?

In der Praxis verwenden die meisten großen Organisationen sowohl spezielle Komponenten- als auch Feature-Teams.

Komponenten- und Feature-Teams

Team C im Diagramm ist ein Komponententeam. Es liefert geplante und angeforderte Infrastrukturleistungen für andere Teams, die als Feature-Teams arbeiten. Team C setzt keine vollständigen User Stories direkt um, sondern liefert die dafür von Feature-Teams benötigten Voraussetzungen.

Dadurch benötigen Feature-Teams weniger Personen mit tiefem Wissen über diese Komponenten.

Der Scrum Master in verteilten Projekten

In verteilten Projekten ist seine Rolle noch wichtiger:

• Die Abstimmung der Teams auf Scrum-Werte verlangt mehr Aufwand,
• Die Vereinbarung von Team- und Projektnormen für zahlreiche Teams dauert länger,
• Außerdem entstehen durch mehr Abhängigkeiten zwischen Teams und Ergebnissen zusätzliche Hindernisse.

Der Scrum Master muss erreichbar und wirksam sein. Räumliche Nähe kann helfen, ist aber keine Scrum-Pflicht. Auch Unterstützung aus der Ferne ist möglich. Verteilte Strukturen müssen ihm ermöglichen:

• Die Beseitigung von Hindernissen für den Teamfortschritt zu unterstützen,
• Wirksame Arbeitsvereinbarungen im Team zu fördern und
• Die Anwendung des Scrum Frameworks zu verbessern.

Manche Organisationen nutzen einen Lead oder Primary Scrum Master für teamübergreifendes Coaching und Koordination. Das ist ein optionales Muster, keine vorgeschriebene Hierarchie und kein Ersatz für die Ergebnisverantwortlichkeiten jedes Teams.

Jedes Scrum Team behält die Scrum-Master-Ergebnisverantwortlichkeit und benötigt wirksame Unterstützung für Events, Selbstmanagement und Verbesserung.