Scrum of Scrums. Mit mehreren Scrum-Teams zusammenarbeiten.
Was ist Scrum of Scrums? Und wie lässt sich Scrum in großen Projekten mit mehreren Teams umsetzen?
Ein wesentliches Merkmal von Scrum ist die vorgeschlagene Größe des Entwicklungsteams: Um effizient zu kommunizieren, sollen höchstens neun Personen zusammenarbeiten. Was ist aber, wenn die Organisation groß ist und mehrere Abteilungen an einem Produkt entwickeln? Wenn 20, 50 oder 100 Leute parallel arbeiten und die beteiligten Personen sich nicht nur über Büros und Stockwerke verteilen, sondern auch in anderen Gebäuden oder sogar Ländern sitzen? Wie können Sie die Anforderungen managen und gleichzeitig die Kommunikation zwischen den Scrum-Teams sicherstellen?
Was ist Scrum of Scrums?
Gemäß den agilen Prinzipien schlägt Scrum ein tägliches Treffen von Angesicht zu Angesicht vor – das sogenannte Daily Scrum. Dieses Treffen findet natürlich immer noch in jedem einzelnen Team statt. Ob von Angesicht zu Angesicht noch möglich ist, ist dann abhängig von der Organisation. Damit sich die verschiedenen Scrum-Teams untereinander abstimmen können, kommt das sogenannte Scrum of Scrums zum Einsatz: Jedes Team stellt eine oder mehrere Personen bereit, die sich zusätzlich treffen und über den Stand ihres Teams berichten.
Lesen Sie hier, um mehr über die agilen Prinzipien zu erfahren »
Eine kurze Definition von Scrum of Scrums:
Wenn ein Scrum-Team zu groß wird, bilden Sie mehrere Teams. Die Scrum-Teams arbeiten mit ihren eigenen Team und Sprint Backlogs und halten ihre eigenen Daily Scrum-Meetings. Um sich abzustimmen, findet ein Scrum of Scrums-Meeting zwischen den Teams statt.
Wer trifft sich in einem Scrum of Scrums?
Wer genau sich in einem Scrum of Scrums-Meeting trifft, ist nicht festgelegt. Abhängig vom Thema können die Teams unterschiedliche Experten schicken. Zum Beispiel erscheint zum einen Scrum of Scrums-Meeting ein UX-Experte und zum nächsten ein Tester. Wie viele die Teams zu diesen Treffen schicken, ist ebenfalls nicht vorgeschrieben. Es gilt aber auch hier die Regel: Nicht mehr als 9 Personen dürfen es am Ende insgesamt sein.
Die Scrum of Scrums können auch auf höheren Ebenen weitergehen. Theoretisch werden diese Treffen Scrum of Scrum of Scrums genannt, aber das wird in der Regel nicht getan. Die Treffen können nicht nur teamübergreifend sein, sondern ebenfalls spezialisiert stattfinden, z.B. zwischen den Product Ownern.
Wie oft treffen Sie sich?
Die Häufigkeit der Scrum of Scrums-Meetings hängt von Ihrem Unternehmen ab. Laut Theorie sollten im Anschluss zu den Daily Scrums die Scrum of Scrum-Treffen stattfinden – hier spricht man auch vom kurzen Scrum of Scrums, da etwa 15 Minuten dafür eingeplant werden sollten. Oft stellen jedoch die Scrum-Teams fest, dass sie sich so häufig gar nicht abstimmen müssen. Oder je weiter höher diese Treffen stattfinden, desto weniger oft sind sie notwendig bzw. überhaupt realisierbar. Für viele große Organisationen hat sich daher eine Frequenz von 2-3x die Woche bewährt. Manche setzen dort eine längere Dauer als eine Stunde an, um Probleme ausführlicher diskutieren zu können. Dann ist auch die Rede vom langen Scrum of Scrums.
Was besprechen Sie?
In einem Scrum of Scrums besprechen Sie ähnliche Fragen wie im Daily Scrum. Da Sie sich jedoch meistens nicht täglich treffen und das eigene Team repräsentieren müssen, werden die 3 Standard-Fragen anders formuliert und um eine ergänzt:
- Was hat das Team seit dem letzten Scrum of Scrums geschafft?
- Was wird das Team bis zum nächsten Treffen erledigen?
- Gibt es Hindernisse, die der Arbeit des Teams im Weg stehen?
- Könnte irgendetwas, was das eigene Team tut, ein anderes Team behindern?
Die Themen – insbesondere Probleme – lassen sich außerdem in einem Scrum of Scrums-Backlog festhalten.
Scrum of Scrums zusammengefasst
- Treffen zwischen Mitgliedern der einzelnen Teams
- Täglich oder mit größeren Zeitabständen (z.B. mehrmals die Woche)
- Keine Festlegung, wer aus den Teams sich trifft
- Kann auf höheren Ebenen durchgeführt werden (Scrum of Scrum of Scrums)
- Dauer eines Treffens: etwa 15 Minuten bis 1 Stunde
- Beantwortung von 4 Fragen, die den Stand des Teams betreffen
So arbeiten Sie agil in der Praxis
Erfahren Sie hier mehr zu Agilität
mit objectiF RPM »
Und wie führen Sie die anderen Scrum-Meetings durch?
Die Daily Scrums finden in jedem Scrum-Team statt.
Sprint Reviews sollten mit allen Mitgliedern jedes Teams durchgeführt werden.
Aus organisatorischen Gründen kann dies mehrstufig erfolgen.
Sprint Retrospektiven führen Sie mit den Teams oder wie ein Scrum of Scrums durch.
Wie gelingt die Umsetzung von Anforderungen mit mehreren Scrum-Teams?
Domänen/Produkt Backlog
Wie auch bei Scrum im kleineren Rahmen sammeln Sie die Anforderungen an das Produkt in einem zentralen Produkt Backlog. Wenn es pro Fachbereich ein Backlog gibt, dann werden diese auch manchmal Domänen Backlogs genannt. In dem Produkt bzw. Domänen Backlog landen alle Anforderungen auf dem höchsten fachlichen Niveau – sogenannte Features. Dort hinzu kommen Epics: Verfeinerungen, die Sie von Features abgeleitet haben, aber noch zu umfangreich sind, um sie als Anforderungen direkt zu implementieren. Wenn Sie bereits User Storys ableiten konnten, dann fügen Sie diese ebenfalls diesem Produkt Backlog hinzu.
Release Backlog
Anschließend verteilen Sie die Features, Epics und User Storys auf Ihre Releases. Ein Feature sollte vollständig in einem Release realisiert werden können, während sich eine User Story in einem Sprint implementieren lassen sollte.
Team Backlogs
Jetzt gilt es eine große Herausforderung zu bewältigen: Wenn Sie die Anforderungen des Releases sofort auf ein Sprint Backlog verteilen – Wie stellen Sie sicher, dass die Teams nicht aus Versehen an den gleichen User Storys arbeiten? Natürlich lässt sich alles kommunizieren, doch die Gefahr dafür ist groß. Vor allem, wenn sich die Scrum-Teams in andere Länder verteilen und die Absprache schwerer fällt. Daher hat es sich bewährt, die Anforderungen der Release Backlogs auf Ihre Scrum-Teams zu verteilen. Dadurch entstehen unterschiedliche Team Backlogs und die Verantwortlichkeiten sind klar geregelt.
Sprint Backlog
Jedes Scrum-Team plant dann basierend auf seinem Team Backlog das eigene Sprint Backlog. Gibt es Abhängigkeiten zu Anforderungen anderer Teams, wirkt sich dies auf die Priorisierung aus: Zum Beispiel würde eine Anforderung gemäß ihres Geschäftswerts eigentlich weiter unten auf der Liste stehen. Da ein anderes Team aber von der Umsetzung abhängig ist, rückt sie weiter nach oben. Am Ende des Sprints liefert jedes Scrum-Team einen Teil des Produktinkrements. Das zu entwickelnde System wächst somit inkrementell durch die Ergebnisse der einzelnen Teams.
Product Owner
- Muss erhöhte Arbeitsbelastung bewerkstelligen
- Muss in allen Meetings anwesend sein
Scrum Master
- Muss teamübergreifende Problemstellungen lösen
- Muss Abhängigkeiten zu anderen Teams lösen
Entwicklungsteam
- Muss weniger selbst-organisiert arbeiten
- Ist groß oder verteilt und muss trotzdem effizient kommunizieren
Sprint Planning
- Ziel muss unter Beachtung der anderen Teams festgelegt werden
Sprint Backlog
- Elektronische Kommunikationswege müssen eingesetzt werden
Produktinkrement
- Abhängigkeiten zu anderen Teams müssen gelöst werden
Daily Scrum
- Teammitglieder verteilen sich; Kommunikation von Angesicht zu Angesicht nicht mehr möglich
Sprint Review
- Es muss geklärt werden, ob das Gesamtprodukt oder nur das Teamprodukt betrachtet wird
Sprint Retrospektive
- Zusammenarbeit ist notwendig, um Probleme zu lösen
Mit Scrum-Teams arbeiten
In einer großen Organisation und mit einer Vielzahl an Scrum-Teams arbeiten Sie mit Tausenden von Anforderungen. Sie müssen das Produkt bzw. Domänen Backlog planen, Features auf Epics hinunterbrechen und dann in User Storys verfeinern, um so Release Backlogs zu erstellen. Anschließend verteilen Sie die Anforderungen auf die Teams. Wie erstellen Sie schnell und einfach die verschiedenen Backlogs und einen Projektplan mit den Releases und Sprints der einzelnen Scrum-Teams? Wie wissen die Entwicklungsteams, welche Anforderungen abhängig voneinander sind oder in welchen Bearbeitungszuständen sie sich befinden? Wie erkennen Sie den aktuellen Status des Teams, um darauf basierend Prognosen treffen zu können? Und was passiert, wenn Sie dem Projekt weitere Teams zuordnen wollen? Setzen Sie ein Tool ein, mit dem Sie auch bei einer hohen Anzahl an Anforderungen stets den Überblick behalten und das Ihnen Zustände sowie Abhängigkeiten transparent macht; welches Ihnen Key Performance Indikatoren wie eine Earned Value Analyse der Team-Sprints liefert und in dem Sie mit wenigen Klicks neue Scrum-Teams dem Projekt hinzufügen können.