Was haben Teamentwicklung und Scrum of Scrums gemein? Sie beschäftigen sich mit dem Wachstum und der Optimierung von Teams. Grundsätzlich gilt: bevor ich agile Methoden skaliere, sollte das Team optimal entwickelt sein. Wann ein Team optimal entwickelt ist, siehst du hier oder in unserem Blogartikel.
Was ist Scrum of Scrums?
Scrum of Scrums ist eine Möglichkeit, Scrum über viele Teams und ggf. Trains hinweg zu skalieren. Andere Methoden sind beispielsweise SAFe, LeSS oder Nexus.
Scrum of Scrums ist insbesondere dann sehr erfolgreich, wenn alle Scrum-Teammitglieder auf ein gemeinsames Ziel hinarbeiten, einander vertrauen, sich respektieren und an einem Strang ziehen. Das bedarf zuvor einer Teamentwicklung.
Den Satz
„Klein genug, um flink zu bleiben und groß genug, um wichtige Aufgaben in einem Sprint zu erledigen”
kennst du vielleicht. Wann ist also der richtige Zeitpunkt für die Skalierung? Wie ist die optimale Teamgröße und was muss man bei der Teamentwicklung bedenken? Gibt es dafür eine Teamentwicklung Empfehlung?
Bevor wir tiefer gehen, ein kurzer Hinweis. Vor kurzem hatten wir in einem Webinar 11 internationale agile Experten zu Gast – zu einer Frage: Wie skaliert man agile Methoden richtig?
Herausgekommen ist diese fantastische Video-Aufzeichnung (englisch), die z.B. auf folgende Fragen eingeht:
- Sollte man lieber bottom-up oder top Down starten?
- Wie schafft man es, Führungskräfte auf eine gemeinsame Vision zu einigen?
- Wie wählt man das richtige agile Framework – und warum ist das eigentlich gar nicht so wichtig?
Meine wärmste Empfehlung: Schaut mal rein! Es dauert zwar relativ lange, aber es lohnt sich jede Minute.
Zuerst die Geschichte zu Scrum of Scrums
Jeff Sutherland und Ken Schwaber waren auf der Suche nach einer Methode, die es möglich macht mit mehreren Teams agil zu arbeiten. Wichtig hierbei war, das nicht jeder für sich arbeitet, sondern dass alle abgestimmt zusammen arbeiten. Es war ein Meilenstein in der agilen Entwicklung. Hierüber schrieb Jeff Sutherland auch das Buch „Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies“, welches 2001 erschien.
Scrum of Scrums und die Skalierbarkeit agiler Methoden setzen sich seither mehr und mehr durch. Man kann aber sagen, dass die COVID-19 Pandemie wohl den größten Schub für die agile Entwicklung gegeben hat – zumindest für die Anwendung in anderen Bereichen als der Softwareentwicklung. Grundsätzlich kann man agile Methoden immer anwenden, wenn Anforderungen und Technologien komplex sind. Die Stacey-Matrix und das Cynefin Framework helfen dir bei der Einordnung. Im Scrum@Scale Guide findest du alle Informationen zur Skalierung.
Als Tipp: Du solltest erst skalieren, wenn dein einzelnes Team gut zusammenarbeitet und funktioniert. Wenn du bereits auf der Ebene einzelner Teams mit Scrum Probleme hast, solltest du auch nicht skalieren. Meine Teamentwicklung Empehlung hier: Entwickle zuerst das Team und nimm dich dessen Problemen an, bevor du mit der Skalierung beginnst.
Übrigens, ein kurzer Hinweis im Kontext agile Transformation: Willst du sicher gehen, dass ihr aktuell die richtigen Prioritäten in eurer agilen Transformation setzt?
Dann mach unseren Reifegrad-Check für eure agile Transformation – dauert nur 3 Minuten. Du bekommst sogar einen Benchmark auf Basis der über dreihundert anderen Teilnehmer*innen. Siehe Button 
Zweck von Scrum of Scrums
Scrum of Scrum ist die erste logische Erweiterung von Scrum, wenn es von der Agilität im Team Richtung Agilität eines ganzen Unternehmens geht. Eine entscheidende Voraussetzung für die Skalierung ist die richtige Teamzusammensetzung. Folgende Fragen sollten beantwortet werden:
- Wer arbeitet in welcher Position im Team?
- Wer arbeitet mit wem zusammen?
- Wer harmoniert zusammen besonders gut?
- Wer hat welche Rolle?
Wir haben herausgefunden, dass die Rollenklarheit eine sehr entscheidende Rolle spielt. By the way: Wenn du wissen möchtest mit welchen Hebeln du Innovationen in einem Team schaffen kannst, schau dir dieses Video an. Teams benötigen auch immer ausreichend Zeit und Raum, um sich weiterzuentwickeln. Hier kannst du dir auch Tuckman´s Phasenmodell zur Teamentwicklung zu Gemüte führen:
- Forming (Einstiegs- und Findungsphase),
- Storming (Auseinandersetzungs- und Streitphase)
- Norming (Regelungs- und Übereinkommens Phase)
- Performing (Arbeits- und Leistungsphase).
Quelle: Tuckman’s Phasenmodell zur Teamentwicklung
Das Ziel ist es kleinere, flinke und autonome Teams zu koordinieren, die voll auf die Kundenbedürfnisse und -wünsche ausgerichtet sind. Das Thema Customer Centricity kannst du dir hier auch gerne detaillierter ansehen. Daher solltest du jederzeit ziemlich früh in die Customer Journey deines Kunden einsteigen. Sei einfach mal dein Kunde und beginne einen Perspektivwechsel. In der Praxis müssen sich Kund*innen leider immer noch ziemlich oft den Prozessen des zusammenarbeitenden Unternehmens anpassen. Vor allem in öffentlichen Behörden, aber auch in einigen größeren Unternehmen oder Konzernen. Das ist allerdings nicht der Gedanke von Scrum.
„Wachstum“ ist nicht gleich „Skalierung“
Dominic Price schreibt in „Unlearning these five fallacies will make you more innovative“ über die 5 Trugschlüsse, von denen du dich lösen solltest, um innovativer zu werden.
- „Wachstum“ ist nicht gleich „Skalierung“
- „Transformation“ ist nicht gleich „Evolution“
- „Stören“ ist nicht gleich „gestört“
- „Anwesenheitszeit“ ist nicht gleich „Initiative“
- „Outputs“ sind nicht gleich „Outcomes“
Zusammenfassend bedeutet das: Effizienz ist gut, Effektivität ist besser. Achte stets auf die Effektivität.
Aus der Erfahrung können wir sagen: je mehr Menschen am gleichen Problem arbeiten, desto schwieriger wird es, zu einer Lösung zu kommen. Gerade wenn es crossfunktionale, autonome Teammitglieder sind. Die Lösung für größer werdende Teams ist jedoch die Skalierung. Der Scrum-Leitfaden bietet eine Grundlage für Teams und Unternehmen, die in diesem Bereich Unterstützung benötigen. Eine Skalierung von Scrum über einzelne Teams hinaus erfordert jedoch einen anderen Ansatz. Die Scrum of Scrums-Technik (SoS-Technik).
Quelle: RFC Professionals
Aufbau und Ablauf von Scrum of Scrums
Scrum of Scrums-Teamstruktur
Kommunikation ist das A und O in der agilen Welt und der Schlüssel zum Erfolg. Kommunikationswege können je größer das Team ist schnell leiden. Informationen kommen falsch oder gar nicht an. Das beeinflusst über kurz oder lang auch das Vertrauen im Team, es fehlt die Nähe und es wird herausfordernder ein gemeinsames Ziel zu verfolgen.
Ziel ist es, das Team so zu entwickeln, dass alle Hindernisse beseitigt werden (Scrum Master) und es im Flow arbeitet. In der Theorie besteht ein “perfektes Team” mit optimaler Performance laut den Untersuchungen von Hackman und Vidmar aus 4,6 Personen. Zu kleine Teams könnten nicht ausreichend sein, um ein Problem zu lösen. Bei zu großen Teams wiederum leiden persönliche Beziehungen und die Flinkheit im Bezug auf die Handlungsfähigkeit und die Interessen des Kunden.
In manchen Fällen erfordert es eine Teilung des Team. Aber Achtung, es gibt hier einiges zu beachten. Man greift in ein bereits etabliertes System ein. Kompetenzen zwischen den Teams sollten ausgewogen verteilt sein, funktionierende Schnittstellen müssen neu definiert und Aufgaben neu verteilt bzw. definiert werden. Unerwartete Abhängigkeiten und neu auftretende Engpässe können hier den Prozess insgesamt verzögern. Auch hier ist es wichtig offen zu kommunizieren und dem Team Zeit und Raum einzuräumen. Geduld und an den richtigen Stellen zu justieren ist ebenfalls sehr wichtig.
Die Scrum-of-Scrums-Technik erfordert eine Koordination, wenn mehrere Teams gebildet sind. Das folgende Schaubild zeigt eine Möglichkeit:
Quelle: Atlassian
Weitere Rollen im Scrum of Scrums
Der Chief Product Owner: Der Chief Product Owner ist für die übergeordnete Vision des Produkts verantwortlich. Er priorisiert das Product Backlog und ist die Schnittstelle und das Sprachrohr zum Kunden.
Der Scrum of Scrums Master: Er trägt permanent zu einer höheren Effizienz von Scrum of Scrums bei. Er fokussiert sich auf Fortschritte und Hindernisse, die für andere Teams sichtbar sind, befähigt und unterstützt das Team bei der Erfüllung ihrer Aufgaben. Er wird auch Servant Leader genannt.
Scrum of Scrums Meeting
Die Teammitglieder bestimmen eine Person, die im Namen des Scrum-Teams am Scrum of Scrums-Meeting teilnimmt. Je nachdem wo der Fokus innerhalb des Projektes liegt, kann das Team immer einen anderen Vertreter bestimmen. In der Regel wird derjenige bestimmt, der am nächsten am Thema dran ist. Geht es um User Experience sollte ein Vertreter gesendet werden, der sich damit auskennt. Liegt der Schwerpunkt beim Testen, sollte der Vertreter aus dem Bereich Testing kommen. In manchen Fällen, wenn das SOS-Team zu klein werden sollte, kann es empfehlenswert sein, zwei Vertreter pro Team am Treffen teilnehmen zu lassen. Oft begleitet dann der Scrum Master die vom Team bestimmte Person. Wenn die Arbeit der Scrum of Scrums Meetings in einem Meeting auf einer höheren Ebene koordiniert wird, nennt man das Scrum of Scrum of Scrums Meeting.
Häufigkeit und Timebox von Scrum of Scrum Meetings
Das Team bestimmt die Häufigkeit des Scrum of Scrum Meetings. Der Einfachheit halber hält man sich an die Vorgaben des Dailys, welches täglich stattfindet und in der Regel max.15 Minuten dauert.
Je nach Größe und Anzahl der Teams handelt es sich aber sehr oft um längere Meetings, die nicht so häufig stattfinden. Beispielsweise 2 bis 3 mal die Woche. Anders als im Daily werden im Scrum of Scrums Meeting auftretende Probleme wenn möglich direkt gelöst oder zumindest thematisiert. Probleme, die in diesem Meeting auftauchen sind ganz wesentliche Probleme und können schnell mehr als 100 Personen betreffen.
Agenda für ein Meeting
Quelle: Unsplash
Eine gute Agenda für ein Scrum of Scrums Meeting ist der Agenda eines Daily Scrums sehr ähnlich. Da das Scrum of Scrums Meeting in der Praxis nicht jeden Tag stattfindet und da jede Person ihr ganzes Team im Meeting vertritt, werden die Fragen etwas abgewandelt beantwortet:
- Was hat dein Team geschafft, seit wir uns das letzte Mal gesehen haben?
- Was wird dein Team bis zum nächsten Meeting erledigt haben?
- Gibt es Hindernisse, die die Arbeit des Teams erschweren?
- Könnte irgendetwas, was dein Team tut, einem anderen Team im Wege stehen?
Die letzte Frage beschäftigt sich hierbei sehr stark mit dem Prozess und den möglichen Auswirkungen auf andere Teams. Sich mit dieser Frage zu beschäftigen kann sehr hilfreich sein. Sie bedenkt im Vorfeld mehrere Szenarien, um eine reibungslose Zusammenarbeit zu gestalten. Hierbei wird das Silodenken quasi aufgelöst. Die Antwort auf die letzte Frage ist besonders wichtig, denn die Erkenntnisse müssen zwingend von den Vertretern an die eigenen Teams weitergegeben werden.
Neben der Beantwortung der Fragen bietet das Meeting auch die Zeit und den Raum sämtliche Themen, Probleme oder Herausforderungen, die zuvor aufgekommen sind zu besprechen und diese in Angriff zu nehmen. In dem Meeting wird der Fortschritt dokumentiert und ein gemeinsames Verständnis geschaffen. Lösungen und Maßnahmen werden festgehalten, um sie nachhalten zu können.
Um im Meeting auf einer sachlichen und neutralen Ebene zu bleiben, werden in Diskussionen keine Namen genannt. Auch die Länge der Themen wird klar von der Wichtigkeit der Themen abgegrenzt. Ziel ist es einen objektiven Blick aus der Metaebene zu gestalten, aber dennoch die Perspektiven zu wechseln.
Fazit
Scrum of Scrums ist also eine gute Möglichkeit für die Skalierung, wenn du bereits mit Scrum arbeitest und dich in Richtung Unternehmensagilität entwickeln möchtest. Wenn du mehr über die Scrum Master Performance Evaluation lernen möchtest, schaue dir gerne auch noch diesen Artikel an.
Scrum of Scrums und SAFe – zwei unterschiedliche Konzepte
Scrum of Scrums, SAFe und LeSS sind allesamt unterschiedliche Frameworks zur agilen Skalierung, mit unterschiedlichen Ansätzen zur Implementierung von Leadership und zum Aufbau einer Roadmap. Wenn du mehr über die anderen Konzepte erfahren möchten, empfehle ich dir, unsere Blogbeiträge zu SAFe und LeSS zu lesen.
