---

Was sind Koordination und Planung mehrerer Teams? Das könnte Sie überraschen!

Scrum of Scrum

Nach dem letzten Kapitel fragen Sie sich vermutlich, wie verschiedene Teams effizient zusammenarbeiten können.

Eine berechtigte Frage, die wir ebenfalls beantworten möchten.

Scrum-of-Scrum-Treffen

Sie ähneln den Daily Scrums. Im Mittelpunkt stehen jedoch ganze Teams statt einzelner Mitglieder.

Scrum of Scrums ist eine optionale Koordinationspraxis, kein formelles Scrum-Event. Tägliche 15 Minuten oder bei höherem Bedarf 30 bis 60 Minuten sind Beispiele. Die Teams sollten die Nützlichkeit prüfen.

Beispiele für Koordinationsfragen

• Was hat das Team gestern getan?
• Was plant das Team heute?
• Gibt es Hindernisse, die den Fortschritt bremsen oder blockieren?

Die Antworten sollen Stories und Abhängigkeiten mit Auswirkungen auf andere Teams abdecken.

Im historischen Muster können Chief Scrum Product Owner und Lead Scrum Master gemeinsam moderieren. Das sind optionale Organisationstitel, keine zusätzlichen Scrum-Verantwortlichkeiten. Alternativ moderiert einer von ihnen, oder sie wechseln sich ab.

Gemeinsame Sprint Reviews

Gemeinsame Reviews sind nicht verpflichtend, können aber hilfreich sein. Der Zweck muss erfüllt werden: Teams eines Produkts prüfen das integrierte Ergebnis mit Stakeholdern. Zusätzliche lokale Treffen sind keine Pflichtverdoppelung.

Teilnehmen können Teamvertreter, der verantwortliche Product Owner und Stakeholder zur gemeinsamen Ergebnisprüfung.

Teams können ihre Vertreter nach Wunsch wechseln. Ein benannter Moderator, etwa der optionale Lead Scrum Master, unterstützt die Wirksamkeit.

Alle Teams können ihre lieferfähigen Inkremente dem Product Owner, unterstützenden Produktkontakten und relevanten Stakeholdern zeigen.

Damit erfüllen gemeinsame Reviews zwei Zwecke:

1. Alle kennen den aktuellen Gesamtstand.
2. Alle erhalten Feedback und können es in der nächsten Planung berücksichtigen.

Gemeinsame Sprint Retrospektiven

Auch gemeinsame Retrospektiven sind optional, aber möglicherweise sehr hilfreich.

Sie ersetzen die nötige Retrospektive jedes Teams nicht.

Teamvertreter nehmen teil; die Teams dürfen ihre Vertreter nach Ermessen wechseln.

Ein Koordinator wie der optionale Lead Scrum Master kann moderieren. Ziel ist, Verbesserungen der Scrum-Nutzung in der größeren Projektorganisation zu finden und umzusetzen.

Probleme, die mehrere Teams benötigen (mehr dazu unter Mehrere Scrum Teams), sollen hervorgehoben werden. Lösungswege müssen geplant, terminiert und nachverfolgt werden.

Mehrteamplanung: Das globale Scrum Product Backlog

Teams eines Produkts teilen Product Goal und Backlog unter einem verantwortlichen Product Owner. Hier heißt die gemeinsame Ansicht Global Scrum Product Backlog. Teams und Kontakte helfen bei der Verfeinerung; die Verantwortung bleibt unverändert.

Teamspezifische Backlogs

Bei Bedarf können Stories des globalen Backlogs in teamspezifischere Stories aufgeteilt werden.

Details bleiben in Arbeitsansichten und nach Auswahl im Sprint Backlog des Teams. Sie verweisen auf das gemeinsame Backlog und werden nicht unabhängig priorisierte Product Backlogs. Die Verweise zeigen die Rolle der Stories im Gesamtbild und den gelieferten Kundennutzen.

Sprint-Terminplanung

Es gibt zwei Möglichkeiten, die Arbeit verteilter Teams abzustimmen.

• Synchrone Sprints
• Asynchrone Sprints

Bei synchronen Sprints beginnen und enden alle am selben Tag.

Dieser meist bevorzugte Ansatz erleichtert Kommunikation und Koordination.

Synchrone Sprints

Asynchrone Sprints beginnen und enden dagegen an unterschiedlichen Tagen. Dann müssen nicht alle Teamrituale am selben Tag stattfinden. So können Product Owner und unterstützende Kontakte auch an Planung, Review und Retrospektive anderer Teams teilnehmen und auf Wunsch helfen.

Bei gegenseitigen Dienstleistungen entsteht ein weiterer Vorteil.

Asynchrone Sprints

Im gezeigten Beispiel muss Team A als Lieferant seine Arbeit in Team B als übergeordnetes Team integrieren. Ein früheres Sprint-Ende von A erlaubt B, diese Ergebnisse vor dem eigenen Abschluss aufzunehmen.

Aufwandsschätzungen

Gemeinsame Fibonacci-Punkte oder T-Shirt-Größen können bei geteilter Planung helfen. Sie sind nicht vorgeschrieben, und Punkte oder Velocity verschiedener Teams sind nicht automatisch vergleichbar.

Ist eine gemeinsame Konvention hilfreich, wird sie im gemeinsamen Backlog konsistent angewandt; Entwickler behalten die Schätzverantwortung.

Komponententeams brauchen besondere Aufmerksamkeit. Da sie Dienste für Feature-Stories liefern, müssen ihre Planung und Schätzung die nötige Unterstützung und Klarheit erhalten.