Leider (oder auch zum Glück) leben und arbeiten wir nicht in der „Optimalwelt“ von SCRUM, dass wir mit einer soliden Teamgröße von ca. 7 Teammitgliedern autark an einem Projekt arbeiten können. Insbesondere in größeren Unternehmen ist die bereichsübergreifende Zusammenarbeit oftmals erforderlich. Insofern sich SCRUM in Ihrem Unternehmen durchgesetzt hat, stellt sich dann oftmals die Frage, wie verschiedene SCRUM Teams zusammenarbeiten können. Hierfür liefert das sog. SCRUM on SCRUM eine Antwort.
Ziele des SCRUM on SCRUM
SCRUM on SCRUM erweitert das Framework mit weiteren Ideen, wie eine optimale Zusammenarbeit zwischen verschiedenen Teams sichergestellt werden kann:
Das tägliche stattfindende Daily Meeting wird dabei weiterhin innerhalb eines SCRUM Teams durchgeführt. Hinzu kommt ein weiteres Abstimmungsmeeting zwischen den Teams. Hierfür treffen sich verschiedene Mitglieder (dies kann je nach Bedarf variieren) beider SCRUM Teams zusammen und tauschen sich ähnlich des Daily Stand Ups miteinander aus. Dies kann ebenso täglich erfolgen aber auch in der Frequenz reduziert werden – je nach Bedarf.
Beschreibung und Vorgehen
Während mein Daily Stand Up die drei Fragen: Was habe ich gestern gemacht?, Was mache ich heute? und Gab es irgendwelche Probleme? beantwortet werden, sollten diese beim SCRUM on SCRUM ein wenig variiert werden. Denkbar sind die folgenden Fragen:
- Was haben beide Teams seit dem letzten SCRUM on SCRUM erreicht?
- Was soll bis zum nächsten Meeting erreicht werden?
- Gibt es Hindernisse innerhalb oder zwischen den Teams?
- Gibt es Abhängigkeiten in den Aufgaben zwischen den Teams?
Wichtig dabei ist, dass jedes SCRUM Team weiterhin für sich arbeiten kann und seine SCRUM Meetings, Rollen und Artefakte beherzigt. Das bedeutet bspw., dass jedes Team weiterhin sein eigenes Sprint Backlog hat und seinen eigenen Sprint durchführt. Sinnvoll kann eine Änderung bei dem Product Backlog sein. Hier kann es durchaus sinnvoll sein, alle gewünschten Produkteigenschaften über die Teams hinweg zu sammeln, somit ist auch sichergestellt, dass bspw. es nicht zu einer Doppelentwicklung kommt. Dieses Product-Backlog kann dann in Team Backlogs gegliedert werden.
Beim autarken SCRUM Ansatz würde der Product Owner gemäß der Wertigkeit die User Stories priorisieren. Beim SCRUM on SCRUM kann es dazu kommen, dass Abhängigkeiten berücksichtigt werden müssen und ggf. User Stories umgesetzt werden müssen – da das andere Team die Vorarbeiten benötigt – bevor andere, höherwertigere User Stories umgesetzt werden.
Die Retrospektive würde ich aus meiner Erfahrung heraus weiterhin innerhalb des jeweiligen SCRUM Teams durchführen, da ansonsten das Meeting einerseits zu lange wird und ggf. auch die Offenheit nicht gegeben ist. Das Sprint-Review kann und sollte gemeinsam mit den Stakeholdern durchgeführt werden.