Erfolgreiche Zusammenarbeit durch Agile Scaling

Für erfolgreiche und agile Zusammenarbeit in einem großen Team gehört viel Organisation dazu. Ansonsten finden Meetings kein Ende, jedes Teammitglied erhält Unmengen an Informationen und das Teamlead verliert den Überblick. Wie kann also bei einem großen Projekt oder bei der Zusammenführung von zwei Scrum Teams der agile Prozess bewahrt werden? Wir haben uns an Agile Scaling Frameworks orientiert und unser gemeinsames Arbeitsverständnis und die Zusammenarbeit von vormals zwei getrennten Teams durch gezielte Kommunikation vorangetrieben.

Wenn wir uns über Agile Scaling Gedanken machen ist es ja normalerweise so: Man hat ein größeres Projekt und die maximale Teamgröße für ein Scrum Team von neun Entwicklern wird überschritten. Die Folgen: Dailies schafft man plötzlich nicht mehr in 15 Minuten, das Team hat einen höheren Aufwand seine Arbeiten zu koordinieren und sich abzustimmen und kurze Kommunikationswege (und zwar so, dass es alle mitkriegen) sind passé. Kurz gesagt: Einer der Haupt-Erfolgsfaktoren von Scrum geht verloren. Wie splitte ich also mein Team, um wieder effektiv arbeiten zu können und wie stelle ich sicher, dass die neuen Teams noch genug Abstimmung haben (da sie ja immer noch am selben Produkt arbeiten)?

Für meinen Fall war die Sachlage etwas anders, die Fragestellung aber dieselbe: Zwei Scrum Teams, die an ähnlichen Dingen arbeiten, aus der Historie heraus aber komplett getrennt waren, sollen sich besser abstimmen und zu einem Projekt zusammengeführt werden. Beide Scrum Teams waren bis dahin cross-functional, mit je einem Scrum Master und einem Product Owner. Das eine Team (Team A: 6 Entwickler) arbeitet an einem Webportal, das andere Team (Team B: 8 Entwickler) an der zugehörigen App. Technologisch keine Überschneidungen, Feature-seitig aber starke Abhängigkeiten, z. B. setzt ein Feature der App eine Implementierung im Webportal voraus.

Keine leichte Aufgabe und viele Fragestellungen: Wie können wir bessere Synergie-Effekte zwischen den beiden Teams erzielen, z. B. muss der Product Owner dieselben Features immer zweimal vorstellen, einmal für Team A und einmal für Team B? Wie erkennen wir Abhängigkeiten zwischen den beiden Teams frühzeitig? Wieviel Abstimmung brauchen wir überhaupt, die Meetings sollen ja nach wie vor effektiv sein und einige Features sind NUR für die App oder NUR für das Webportal vorgesehen? Sollten wir die cross-functional Teams aufbrechen, da hauptsächlich die beiden Backend-Teams sich abstimmen müssen? Wie bekommt man dieselben Informationen in beide Teams transportiert? Und und und...

Agile Scaling sollte hier der Schlüssel zum Erfolg werden und einen Teil der Antworten liefern. Natürlich nicht alle, denn alle Agile Scaling Frameworks sind – wie Scrum – eben nur Frameworks und keine genaue Anleitung zur Ausgestaltung.

Ein gemeinsamer Product Owner und Scrum Master

Alle Agile Scaling Frameworks haben eine zentrale Sache gemeinsam: Ein gemeinsamer Product Owner. Dies war auch der erste Schritt, den wir gegangen sind: Einen gemeinsamer Product Owner und ein gemeinsamer Scrum Master für beide Teams. Dies hatte schon einmal den positiven Effekt, dass nun keine Abstimmung mehr nötig war auf Product Owner Ebene und die Backlogs der beiden Teams richtig priorisiert werden konnten, nämlich auf die Abhängigkeiten der beiden Teams abgestimmt. Weiterhin konnte ich als Scrum Master die Arbeitsweisen beider Teams kennenlernen und so auch die Probleme, die in der Abstimmung beider Teams existierten, leichter identifizieren.

Aber dieser erste Schritt war noch nicht genug. Und so folgte der zweite: Die Synchronisierung des Sprint-Zyklus. Hier haben wir uns an das Agile Scaling Framework "LESS" angelehnt. Nicht zuletzt deshalb, weil es einfach anzuwenden ist und für unsere Zwecke völlig ausreichend.

Aber nun zum gemeinsamen Sprint-Zyklus: Bisher hatten beide Teams um eine Woche versetzt in einem zweiwöchigen Sprint-Zyklus gearbeitet. Dies sollte den Vorteil haben, dass das Webportal die Features fertig stellen konnte und erst dann das App Team damit begonnen hatte, um somit Abhängigkeiten frühzeitig aufzulösen. In der Theorie gut, in der Praxis – einem sehr agilen Umfeld – nicht praktikabel: Im Planning Meeting der App kamen immer wieder Abhängigkeiten zum Vorschein, die das Webportal dann erst drei Wochen später hätte liefern können (da der Sprint des Webportals bereits in vollem Gange war).

Ein besseres Arbeitsverständnis durch konstruktive Zusammenarbeit

Die Synchronisierung des Sprint-Zyklus hatte einige Vorteile: Für Product Owner, Scrum Master und Stakeholder gibt es nun nur noch ein Review und Planning Meeting alle zwei Wochen. Parallel entwickelte Features können dann direkt auf beiden Plattformen (App und Webportal) gezeigt werden. Weiterhin können die Teams gegenseitig ihren Gesamt-Fortschritt sehen. Im gemeinsamen Planning kann sofort auf Abhängigkeiten eingegangen werden und somit beide Sprints mit dem optimalen Business-Value für den Kunden gestartet werden. Das gemeinsame Planning trägt außerdem dazu bei, dass beide Teams wissen, woran das jeweils andere Team arbeitet. So herrscht ein besseres Verständnis für die Needs des anderen Teams und eine bessere Zusammenarbeit beider Teams insgesamt.

Damit das gemeinsame Planning Meeting nicht ausufert und effektiv bleibt, muss dem Refinement mehr Bedeutung zugemessen werden. Es sollte gut vorbereitet sein und die Features vom Team geschätzt werden. Das Features erst im Planning vorgestellt und geschätzt werden, sollte die (leider nicht immer vermeidbare) Ausnahme sein. Außerdem sollte das Sprint Backlog vor dem Planning optimal vorbereitet sein (also auf die Velocity angepasst und priorisiert). Im besten Fall muss das Team dann nur noch sein Commitment geben oder kleinere Anpassungen vornehmen.

Direkter Austausch und übergreifende Retrospektive

Für team-übergreifende Abstimmungen während des Sprints haben wir bisher nur einen Regel-Termin eingeführt. Dieser findet wöchentlich statt und ist eine Mischung aus Status Meeting und internem Refinement der Backend-Entwickler. Der Product Owner nimmt nur teil, wenn das Team ihn bittet dabei zu sein, um bei Anforderungen zu helfen. Im Meeting wird der Fortschritt beider Sprints erläutert, aktuelle Probleme diskutiert, Lösungen zu aktuellen Features entworfen, und zukünftige Features auf Abhängigkeiten untersucht. Außerdem dient das Meeting dem Wissenstransfer, da wir häufiger das Konzept des "Leading Teams" einsetzen. Bei diesem Konzept geht es darum, dass es oft keinen Sinn macht, dass beide Teams sich von Anfang an in ein Thema einarbeiten. Dann kann es schon mal sein, dass das eine Team einen Proof of Concept macht und seine Erfahrungen dann mit dem anderen Team teilt. Dabei muss nicht immer dasselbe Team das "Leading Team" sein, sondern abhängig von Kapazitäten lässt sich dies flexibel gestalten.

Für sonstige Abstimmungen beider Teams während des Sprints war es uns wichtig die direkte Kommunikation beizubehalten. Sollten wir merken, dass dies nicht gut funktioniert oder wir eine "geregeltere" Abstimmung brauchen, könnte man über ein Scrum of Scrums nachdenken (ein Daily aus Vertretern beider Teams) oder das Observer-Konzept, welches wir auch in manchen Phasen des Projektes schon eingesetzt haben. Hier nimmt ein Vertreter des einen Teams einfach als "Beobachter" am Daily des anderen Teams teil und kann so die Informationen in sein Team transportieren.

Gemäß dem Framework LESS haben wir ebenfalls eine übergreifende Retrospektive eingeführt. Allerdings vorerst nicht nach jedem Sprint, sondern alle zwei Monate. Diese dient dazu die teamübergreifenden Prozesse zu inspizieren und zu verbessern. Beide Teams nehmen daran teil. Hier kam zum Beispiel heraus, dass man über ein gemeinsames Refinement nachdenken sollte.

Unser Résumé: Das Agile Scaling Framework LESS in unserem Projekt einzuführen hat eindeutig große Verbesserungen in der Kommunikation und Zusammenarbeit beider Teams, sowie der Arbeitsorganisation des Projekts gebracht. Einige Dinge gilt es aber noch zu verbessern, wie z.B. die Einführung eines gemeinsamen Refinements. Es bleibt also spannend und getreu dem Scrum-Motto "Inspect & Adapt" arbeiten wir weiter an unseren Prozessen, um so das Bestmögliche für unseren Kunden herauszuholen.