Was ist das Nexus Framework?
Das Nexus Framework ist eine einfache Möglichkeit, ein Scrum-Projekt mit 3 bis 9 Entwicklungsteams zu skalieren. Lesen Sie diesen Blog, um zu verstehen, was das bedeutet.
Mehrere Entwicklungsteams
Die meisten Organisationen, die mit Scrum beginnen, fangen klein an. Ein Scrum Team mit einem Scrum Master, Product Owner und dem Entwicklungsteam. Was aber, wenn Ihr Projekt oder Produkt ein so großes Product Backlog hat, dass mehrere Entwicklungsteams daran arbeiten müssen? Das Nexus Framework bietet eine Antwort darauf.
Scrum schreibt vor, dass es pro Produkt oder Projekt ein Product Backlog gibt. Dieses Backlog wird von einem Product Owner verwaltet.
Sie können jedoch mit mehreren Entwicklungsteams an diesem Product Backlog arbeiten.
Dies erfordert natürlich Koordination. Sie müssen sicherstellen, dass alle Teams an einem integrierten Inkrement arbeiten. Die Arbeit der einzelnen Teams muss daher in ein Sprint-Ergebnis integriert werden. Außerdem müssen Abhängigkeiten schnell erkannt und beseitigt werden.
Nexus Framework
Eine Möglichkeit zur Skalierung von Scrum ist das Nexus Framework.
Das Nexus Framework ist für 3 bis 9 Entwicklungsteams geeignet. Diese Teams arbeiten intern nach der „normalen“ Scrum-Methode. Darauf wird dann das Nexus Framework aufgesetzt. Dieser Rahmen basiert darauf, dass die Teilnehmer viel Initiative ergreifen. Die Teilnehmer müssen sich, wie bei Scrum, über die Ziele des Rahmens im Klaren sein.
Bestandteile des Nexus Framework
Das Nexus Framework hat im Vergleich zum Scrum Guide eine Reihe von zusätzlichen Komponenten.
Rollen
Wie bereits erwähnt, gibt es nur einen Nexus Product Owner. Diese Rolle ähnelt der des Product Owners im Scrum Framework. Die normalen Zuständigkeiten dieser Rolle gelten auch für Nexus. Der Product Owner ist also dafür verantwortlich, den Wert des Nexus Product Backlogs zu maximieren.
Das Nexus-Integrationsteam ist für die Integration und Bearbeitung von Abhängigkeiten zuständig. Dieses Team besteht aus dem Nexus Product Owner, einem Scrum Master und einem oder mehreren Teammitgliedern. Der Scrum Master kann auch ein Scrum Master eines der Scrum Teams sein und ist für den Prozess wie in Scrum verantwortlich. Die Mitglieder des Nexus-Integrationsteams können auch Mitglied eines Entwicklungsteams sein. Die Integrationsarbeit hat dann Vorrang vor der Arbeit in einem der Scrum Teams. Diese Teammitglieder müssen Erfahrung in der Arbeit mit Scrum haben, da sie auch eine Coaching-Funktion für die Entwicklungsteams haben.
Meetings
Alle Meetings innerhalb von Nexus folgen den Timeboxen, wie sie im Scrum Framework beschrieben sind.
Zu Beginn eines Sprints findet das Nexus Sprint Planning Meeting statt. An dieser Sitzung nehmen Vertreter aller Entwicklungsteams und des Nexus-Integrationsteams teil.
Während dieses Meetings bespricht der Nexus Product Owner die Items, die er gerne im nächsten Sprint sehen würde. Ein Nexus Sprint Goal wird eingerichtet, damit das Ziel aller Scrum Teams während des Sprints klar ist.
Dann führt jedes einzelne Scrum Team sein eigenes Sprint Planning durch und erstellt sein eigenes Sprint Backlog.
Einmal am Tag findet das Nexus Daily Scrum statt. Vertreter aller Entwicklungsteams treffen sich, um die Fortschritte beim Erreichen des Nexus-Sprint-Ziels zu besprechen und neue Abhängigkeiten zu identifizieren und zu diskutieren.
Während dieses Meetings werden drei Fragen beantwortet:
- Wurde die Arbeit des Vortages erfolgreich integriert, wenn nicht, warum nicht?
- Welche neuen Abhängigkeiten wurden festgestellt?
- Welche Informationen müssen zwischen den Nexus-Teams ausgetauscht werden?
Dies ist auch der Zeitpunkt, um den Nexus Sprint Backlog zu aktualisieren.
Die Teilnehmer am Nexus Daily Scrum nehmen die Erkenntnisse dann in die einzelnen Daily Scrums pro Entwicklungsteam mit.
Ein wesentlicher Unterschied zum Scrum Framework besteht darin, dass beim Nexus Framework während des Nexus Sprint Review keine Einzelergebnisse pro Scrum Team besprochen werden. Während der Nexus Sprint Review wird das integrierte Inkrement den Stakeholdern vorgeführt. Zu diesem integrierten Ergebnis wird dann auch eine Rückmeldung erbeten. Es ist vielleicht unnötig zu erwähnen, dass es keine einzelnen Sprint Reviews pro Entwicklungsteam gibt.
Die Nexus Sprint Retrospektive ist in drei Teile gegliedert. Zunächst kommen Vertreter aller einzelnen Teams zusammen und besprechen, was während des gesamten Sprints und der Integration gut gelaufen ist und was nicht.
Dann halten alle Scrum Teams ihre eigene, separate Sprint Retrospektive ab. Hier wird die Funktionsweise des eigenen Scrum Teams (nach den Regeln des Scrum Guide) besprochen und Probleme, die im ersten Teil identifiziert wurden, werden diskutiert. Vertreter jedes Teams kommen dann erneut zusammen, um die Ergebnisse und Aktionspunkte der einzelnen Sprint Retrospektiven zu besprechen.
Artefakte
Wie von Scrum vorgeschrieben, gibt es ein gemeinsames Product Backlog. Die Items in diesem Backlog müssen so verfeinert werden, dass die Abhängigkeiten so weit wie möglich identifiziert werden. Und wo möglich eliminiert. Darüber hinaus muss für jeden Punkt klar sein, welches Entwicklungsteam an der Story arbeiten wird. Zu diesem Zweck müssen die Stories so klein wie möglich gehalten werden.
Alle von den einzelnen Scrum Teams für den Sprint ausgewählten Items werden in einem gemeinsamen Nexus Sprint Backlog festgehalten. Dieses Backlog dient der Verfolgung des gesamten Fortschritts aller Scrum Teams und wird mindestens einmal am Tag aktualisiert.
Das Ergebnis des Nexus Sprint ist ein integriertes Inkrement. Die Arbeit aller einzelnen Entwicklungsteams wird in ein potenziell veröffentlichungsfähiges Teilprodukt integriert.
Alle Arbeiten innerhalb von Nexus unterliegen einer Definition of Done. Hier wird beschrieben, welche Qualitätsanforderungen erfüllt werden müssen, um ein integriertes Inkrement zu gewährleisten. Einzelne Scrum Teams können für ihre eigene Arbeit eine strengere Definition of Done erstellen. Sie sollte mindestens die Nexus Definition of Done enthalten.
