Bei der Skalierung von Scrum balancieren wir Kosten und Aufwand mit Nutzen und Vorteilen. Kosten und Aufwand werden durch zusätzliche Teams verursacht. Nutzen und Vorteile entstehen dadurch, mehr potentiellen Wert in gleicher Zeit zu liefern.
Scrum-Praktiker wissen, dass die Skalierung von Scrum mehr ist als nur eine Rechenaufgabe. Der gesunde Menschenverstand sagt uns, wenn Teams gemeinsam an einer einzigen Initiative arbeiten, wird es unvermeidlich zu Integrationskonflikten kommen. Diese Konflikte entstehen durch Abhängigkeiten. Wir wissen, dass es Disziplin und Mühe kostet, Abhängigkeiten transparent zu machen und sie zu beseitigen. Dieser Aufwand wird relativiert, wenn am Ende jedes Sprints ein integrated Increment ausgeliefert werden kann. Nur die Auslieferung wird Wert für die Organisation schaffen.
Das kontinuierliche Eliminieren von Abhängigkeiten und das Integrieren der gesamten Arbeit ist eine bewusste Praxis. Sie ist das Herzstück von Nexus. Im Kern hilft das Nexus Rahmenwerk dabei, mehreren Teams ihre Arbeit kontinuierlich zu einem Produkt zu integrieren.
Scrum-Anwender finden sich im Nexus Rahmenwerk wieder, da es Scrum nur minimal erweitert. Organisationen, die sich dafür entscheiden, Scrum mit Nexus zu skalieren, sind bestrebt, ihren Nutzern kontinuierlich Wert zu liefern. Sie verschwenden keine Sprints, Mitarbeiter in neuen Rollen zu schulen, neue Prozesse oder Arbeitsweisen einzuführen, neue Infrastrukturen einzurichten oder darauf zu warten, Unterstützung von externen Beratern zu erhalten.
Dieser Artikel bietet Anwendern, welche bereits mit Scrum vertraut sind, eine Übersicht über das Nexus Rahmenwerk.
Das Nexus-Rahmenwerk erklärt
Wir besprechen das Rahmenwerk Schritt für Schritt. Dabei erklären wir wie die Elemente die es ermöglichen teamübergreifend Abhängigkeiten zu identifizieren und zu beseitigen. Wir starten dabei links mit dem Product Backlog.
Die Arbeit an einem Produkt erfordert ein Product Backlog. Es ist die einzige Quelle an Arbeit, die durch die Scrum Teams erledigt wird. Um diese Arbeit transparent zu machen, ist das Refinement eine hilfreiche Praxis in Scrum. Bei skalierten Scrum ist teamübergreifendes Refinement hingegen vorgeschrieben.
1. Teamübergreifendes Refinement macht das Product Backlog transparent
In der teamübergreifenden Verfeinerung wird das Product Backlog zerlegt. Das geschieht soweit bis feststeht, welches Team die Arbeit übernehmen kann und ob es Abhängigkeiten zwischen den Einträgen gibt. Dieser Grad an Transparenz ist nötig, um Abhängigkeiten im Vorfeld zu eliminieren. Es werden Vorhersagen getroffen, welches Team höchstwahrscheinlich an welchen Product-Backlog-Einträgen in den kommenden Sprints arbeiten wird. Teamübergreifende Verfeinerung vereinfacht die Planung der nächsten Sprints.
Repräsentanten aus jedem Scrum Team nehmen daran teil. Sie werden dabei nicht aufgrund ihrer Rolle ausgewählt, sondern situativ basierend auf der zu verfeinernden Arbeit. Wie oft sich die Repräsentanten zum teamübergreifende Refinement treffen, bestimmt der Grad der Ungewissheit innerhalb des Product Backlogs. Da die Verfeinerung ein fortlaufender Prozess ist, wird kein Zeitrahmen vorgeschrieben. Typischerweise setzten die Scrum-Teams die Verfeinerung in ihren Teams fort, damit die Product-Backlog-Einträge für die Auswahl in einem Nexus Sprint Planning Event bereit sind.
2. Nexus Sprint Planning koordiniert Aktivitäten für den Sprint
Das Nexus Sprint Planning leitet den Sprint ein. Innerhalb dieses Events wird die Arbeit und alle dazu nötigen Aktivitäten, die für diesen Sprint nötig sind, koordiniert. Idealerweise nehmen alle Mitglieder des Nexus am Nexus Sprint Planning teil.
Das Event beginnt damit, dass Repräsentanten der Scrum Teams und der Product Owner einen Blick auf das verfeinerte Product Backlog werfen und ein Ziel für den Sprint festhalten.
3. Nexus-Sprint-Ziel ermöglicht Fokus über Teamgrenzen hinweg
Dieses Ziel stellt ein übergreifendes Ziel für alle Teams in diesem Sprint dar. Es schafft Kohärenz und Fokus für den Nexus. Zudem ermutigt es die Scrum Teams, zusammen statt an getrennten Initiativen zu arbeiten.
Der Product Owner stellt das Nexus-Sprint-Ziel vor, um den Zweck des Sprints zu klären. Gemeinsam wählen die Scrum-Teams die Product-Backlog-Einträge mit der höchsten Priorität aus, die, wenn sie fertiggestellt werden, das Nexus-Sprint-Ziel realisieren. Der laufende Refinement-Prozess sollte bereits Abhängigkeiten für die ausgewählten Product-Backlog-Einträge identifiziert und weitestgehend eliminiert haben.
Nach der initialen Auswahl der Product-Backlog-Einträge fahren die einzelnen Scrum Teams mit ihrer Sprint Planung fort.
Das Nexus Sprint Planning dient als Container für die Sprint Plannings der einzelnen Scrum Teams. Es ist dann abgeschlossen, wenn ein grober Plan, wie das Nexus-Sprint-Ziel erreicht werden kann, und einen detaillierteren Plan für die ersten Tage des Sprints, erstellt wurde.
Dieser übergreifende Plan wird im Nexus Sprint Backlog festgehalten.
4. Nexus Sprint Backlog ist ein Echtzeitbild der Abhängigkeiten
Er besteht aus den Einträgen des Product Backlogs, welche die Developer im Nexus für notwendig halten, um das Nexus-Sprint-Ziel zu erreichen. Dieses neue Artefakt macht die gesamte prognostizierte Arbeit der Teams und alle Abhängigkeiten zwischen ihnen sichtbar.
Das Nexus Sprint Backlog hilft dabei, die Arbeit über Teamgrenzen hinweg zu koordinieren. Sollte beispielsweise Scrum Team A von Scrum Team B abhängen, um einen Product-Backlog-Eintrag zu erledigen und Scrum Team A keine Fortschritte bei der Abarbeitung machen, dann würde dieses im Nexus Sprint Backlog sichtbar.
Dieses Backlog ermöglicht den Teams während des Sprints zusammenzuarbeiten. Er kann als die Aggregation der Sprint Backlogs der Scrum Teams gesehen werden. Er hilft dem Nexus, für die Abhängigkeiten während des Sprints verantwortlich zu bleiben. Das Nexus Sprint Backlog stellt ein Echtzeitbild des Arbeitsflusses während des Sprints dar und muss täglich aktualisiert werden. Diese Aktualisierung sollte im Nexus Daily Scrum erfolgen.
5. Nexus Daily Scrum macht Integrationsprobleme sichtbar
Developer der Teams und das Nexus Integrationsteam treffen sich vor dem Daily Scrum, um den Fortschritt gegenüber der Erreichung des Nexus-Sprint-Ziels zu überprüfen. Sie überprüfen den aktuellen Stand des integrated Increment (die gemeinsam bis jetzt fertiggestellte Arbeit eines Nexus), indem sie alle Integrationsprobleme und neu entstehenden Abhängigkeiten transparent machen.
Die Repräsentanten nutzen diese Informationen als Input für das Daily Scrum ihres Teams. Die Rolle des Nexus-Integrationsteams dabei ist es, den Teams zu helfen, ihre Integrations- und Abhängigkeitsprobleme und die Notwendigkeit von Maßnahmen auf der Teamebene zu identifizieren.
Natürlich ist dies nicht die einzige Zeit, in der teamübergreifende Kommunikation stattfindet. Das Nexus Daily Scrum stellt die minimale Gelegenheit und eine gemeinsame Zeit dar, um das Nexus Sprint Backlog zu aktualisieren.
6. Nur ein integrated Increment schafft die nötige Transparenz für Empirie
Ein Product-Backlog-Eintrag erfüllt nur dann die Definition of Done, wenn dieser vollständig in das Produkt integriert wurden. Erst dann ist ein neues Inkrement des Produkts erstellt.
Nur die Integration in das Produkt schafft die nötige Transparenz, welche die Empirie antreibt. Spätestens am Ende des Sprints muss ein nutzbares Inkrement erstellt sein. Im Idealfall findet die Integration und Auslieferung häufiger statt.
Die Integration der Arbeit sollte vor allen anderen zu erledigenden Arbeiten kommen. Sollte es zu Integrationsproblemen kommen, müssen diese zuerst behoben werden, bevor weitere Product-Backlog-Einträge umgesetzt und in das Produkt integriert werden können.
7. Nexus Sprint Review um das integrated Increment zu überprüfen
Das Nexus Sprint Review ersetzt die Sprint Reviews der Scrum Teams, um eine ganzheitliche Sicht auf das Ergebnis des Sprints zu liefern. Das Ziel ist es, Feedback von Stakeholdern zum Inkrement zu erhalten und Produktverbesserungen zu identifizieren. Da es sich bei diesem Event um eine sehr große Veranstaltung handeln kann, sollte der Fokus auf den High-Level-Ergebnissen liegen. Sollte es nötig sein, einen detaillierten Output zu inspizieren, so kann der Product Owner und Stakeholder jederzeit bestimmte Teile des Produkts während des Sprints überprüfen. Wie bei Scrum dienen die Ergebnisse des Nexus-Sprint-Reviews als Input, um das Product Backlog anzupassen.
Das Sprint Review findet am Ende eines Sprints statt. Im Anschluss haben die Scrum Teams genügend Informationen, um die Sprint Retrospektive durchzuführen.
8. Nexus Sprint Retrospektive ermöglicht nexusweite Verbesserung
Es gibt zahlreiche Möglichkeiten, die Nexus Sprint Retrospektive durchzuführen. Ein gängiger Weg ist:
Als Input für die Scrum Team Retrospektiven identifizieren Repräsentanten Probleme, die mehrere Teams betreffen. Im Nachgang führt jedes Scrum Team seine eigene Sprint Retrospektive durch. Die teamübergreifenden Probleme können hierfür als Grundlage dienen. Nach der Team-Retrospektive kommen die Repräsentanten erneut zusammen, um die Verbesserungen zu visualisieren. Das hilft den Teams während des Sprints verantwortlich für die Umsetzung zu bleiben.
Unabhängig davon, wie ein Nexus seine Sprint Retrospektive durchführt, muss sie dem Leitprinzip treu bleiben: Der Nexus nutzt „Bottom‐up”‐Erkenntnisse, um Probleme zu beheben, die den Nexus als Ganzes behindern.
9. Nexus Integration Team übernimmt die Verantwortung für die Integration
Das Nexus Integrations Team ist das am meisten missverstandene Element des Rahmenwerks. Das Nexus Integrations Team ist weder ein separates Team noch soll es die Integrationsarbeit erledigen.
Es bietet die Fokussierung auf die Verantwortung, die Arbeit der einzelnen Teams zu integrieren, um infolgedessen ein nutzbares Inkrement zu erstellen. Ist niemand dafür verantwortlich, führt dies zu Verzögerungen bei der Integration und minimiert die Transparenz. Ohne diese Transparenz ist empirisches Arbeiten nicht möglich.
Die Mitglieder des Nexus Integrations Team kommen aus den Scrum-Teams. Die Zusammensetzung kann sich im Laufe der Zeit ändern, je nach den aktuellen Integrationsanforderungen und Prioritäten. Ihre Arbeit im Nexus Integrations Team hat Vorrang.
Product Owner und ein Scrum Master sind ständige Mitglieder im Team. Die restlichen Mitglieder sind Personen mit den notwendigen Fähigkeiten und Kenntnissen, um die Probleme zu lösen, mit denen der Nexus zur Zeit konfrontiert ist.
Anstatt Probleme direkt zu lösen, nutzt das Nexus Integrations Team die Fähigkeiten und Wissen der Mitglieder der Scrum Teams, um optimale Lösungen für identifizierte Probleme zu erreichen. Zu den üblichen Aktivitäten, die das Nexus Integrations Team durchführt, gehören Coaching, Beratung und die Schaffung eines Bewusstseins für Abhängigkeiten und teamübergreifende Probleme. Nur in Notfallsituationen springen Mitglieder des Nexus Integrations Teams ein, um den Teams bei der Lösung kritischer Probleme zu helfen.
Zusammenfassend lässt sich sagen, dass das Nexus Integrations Team die zentrale Anlaufstelle für die Integration des Nexus darstellt.
Nexus erweitert Scrum und erhält dessen Wettbewerbsvorteil
Das Nexus Rahmenwerk erweitert das Scrum Rahmenwerk, um das Nexus Integrations Team, das Nexus Sprint Backlog, teamübergreifendes Refinement, und das Nexus Daily Scrum.
Nexus stellt somit eine minimale, aber ausreichende Erweiterung zu Scrum dar. Diese Erweiterung ermöglicht es, dass Teams am Ende des Sprints in der Lage sind ein integrated Increment zu liefern.
Die Transparenz, welche durch ein integrated Increment entsteht, ist der entscheidende Wettbewerbsvorteil von Nexus. Nur dadurch bleiben Organisationen in der Lage, jederzeit auf Veränderungen empirisch zu reagieren.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Skaliertes Scrum, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.