Scaled Agile: Nexus Integration Teams

Bild: Pexels / Yan Krukow - Lizenz

Lange Zeit war die Scrum-Welt einfach, zumindest wenn es um die Rollen ging. Es gab den Scrum Master, es gab den Product Owner und es gab das Entwicklungsteam. Mehr war nicht nötig, schliesslich müssen laut Scrum Guide in einem Scrum Team alle Qualifikationen vorhanden sein die nötig sind um ein Produkt zu entwickleln und zu integrieren. Wer auch immer es ist (Tester, Architekt, UX-Designer, Data Scientist, etc.) er gehört in das Entwicklungsteam. Punkt.

Seit 2015 ist die Sache aber nicht mehr ganz so klar, denn mit dem Nexus-Framework von Ken Schwaber und Scrum.org gibt es erstmals einen Skalierungsansatz der von einem der Verfasser von Scrum stammt, der damit also "quasi-offiziell" ist. Und in dem taucht auf einmal etwas Neues auf, das Integrations-Scrum Team (offiziell "Nexus Integration Team"), das dafür verantwortlich ist, dass die Ergebnisse der anderen Scrum Teams am Sprintende integriert werden.

Für Menschen die Erfahrungen im klassischen IT-Projektmanagement haben kann diese Rolle auf den ersten Blick bekannt erscheinen, da sie eine ähnliche Aufgabe wie die klassischen "Integratoren" hat. Deren Aufgabe ist es, den fertig entwickelten Feature- oder Komponenten-Code anderer Teams zu übernehmen, in den Master Branch zu integrieren und durch Regressionstests abzusichern. Auf den zweiten Blick arbeitet das Nexus Integration Team anders: es übernimmt diese Arbeit nicht selbst.

Die in Scrum grundlegende Regel, dass in einem Team alle Qualifikationen vorhanden sein müssen die nötig sind um ein Produkt zu entwickleln und zu integrieren gilt auch in Nexus weiter, hier wird aber das in skalierten Vorhaben häufige Phänomen berücksichtigt, dass die einzelnen Teams unterschiedlich erfahren sind. Das Integration Team soll das ausgleichen indem es die anderen Teams bei Bedarf schult, coacht oder anleitet.

Besonders das letzte kann zu dem Antipattern führen, dass sich bestehende Management- oder Koordinations-Einheiten wie z.B. die Architekten, das Test-Management oder das Release-Management zu einem Integration Team erklären (oder sich in ihm erneut herausbilden) und aus dieser Position heraus die Selbstorganisation der Scrum Teams untergraben. Um dem vorzubeugen hat auch das Integration Team einen Scrum Master, der ggf. gegensteuern soll.

Ein weiterer Mechanismus der dieser Fehlentwicklung vorbeugen soll ist die Möglichkeit, dass die Mitglieder des Integration Teams immer dann wenn sie dort gerade nichts zu tun haben in einem der anderen Scrum Teams mitarbeiten können. Dadurch wird verhindert, dass sich ein unbeschäftigter Integrationshelfer Arbeit sucht und bei sich behält die eigentlich in eines der anderen Teams gehört hätte und von da an dort fehlt und extern angefordert werden muss.

Ähnlich wir Scrum selbst dürfte auch Nexus kontinuierlich weiterentwickelt werden, man kann also davon ausgehen, dass auch das Nexus Integration Team basierend auf Umsetzungserfahrungen noch optimiert werden wird. Für eine erste Version ist es aber ein interessanter und brauchbarer Ansatz, der vielen grösseren Scrum-Projekten weiterhelfen dürfte.