Mit dem Nexus Framework wird ein Scrum Projekt durch den Einsatz von mehreren Entwicklungsteams erweitert; von 3 bis maximal 9 Teams innerhalb eines einzigen Projekts. Innerhalb jedes Entwicklungsteams wird Scrum auf traditionelle Weise eingesetzt. Das Nexus Framework ergänzt den Arbeitsprozess in dieser Hinsicht. Wichtig bei dieser Arbeitsweise ist, dass die Mitglieder des Scrum Teams Initiative zeigen. In diesem Artikel wird näher erläutert, wie dieser Prozess funktioniert.
Nicht ein, sondern mehrere Teams aus Entwicklern
Oft beginnen Unternehmen mit einem kleinen Setup, wenn sie mit Scrum arbeiten. Ein Scrum Team besteht aus einem Product Owner, einem Scrum Master und den Entwicklern. Wenn das Projekt jedoch viele Aktivitäten umfasst und das Product Backlog mit Aufgaben überfüllt ist, müssen mehrere Entwicklungsteams eingesetzt werden. Die Lösung ist dann im Nexus Framework zu finden.
Aus dem Scrum Guide geht hervor, dass nur ein Product Backlog pro Projekt existieren sollte, wobei die Pflege und Kategorisierung des Product Backlogs in der Verantwortung eines Product Owners liegt. Wenn mehrere Entwicklungsteams an einem Projekt arbeiten sollen, können diese Teams mit demselben Product Backlog und einem klaren Produktziel verbunden werden. Dann ist es wichtig, die Zusammenarbeit der verschiedenen Teams richtig zu koordinieren. Die Arbeit jedes einzelnen Teams sollte zum Endziel des Sprints beitragen. Achten Sie außerdem genau auf eventuelle Probleme.
Komponente
Zusätzlich zu allen im Scrum Guide beschriebenen Komponenten von Scrum verwendet das Nexus Framework weitere Komponenten.
Artefakte
In Scrum gibt es nur ein Product Backlog. Im Backlog wird die Arbeit vermerkt, die zur Erreichung des Produktziels erforderlich ist. Die Aufgaben werden so detailliert wie möglich beschrieben, sodass für jeden klar ist, welches Entwicklungsteam an der Aufgabe arbeiten wird.
Dann wählt jedes Scrum Team eine Anzahl von Punkten aus, an denen es im nächsten Sprint arbeiten wird. Alle Elemente aus allen Teams werden im Nexus Sprint Backlog gesammelt. Auf diese Weise kann der gemeinsame Fortschritt verfolgt und aktualisiert werden, sodass der vollständige Überblick erhalten bleibt.
Schließlich werden alle Arbeiten zu einem funktionierenden Teilprodukt zusammengeführt. Dies wird als integriertes Inkrement bezeichnet. Alle Teile müssen der vordefinierten Definition of Done entsprechen. Dies sind die Qualitätsanforderungen, die ein Teilprodukt erfüllen muss, bevor es in das integrierte Inkrement aufgenommen werden kann. Jedes einzelne Scrum Team kann seine eigene Defintion of Done definieren. Die Bedingung ist, dass sie mindestens die Nexus Definition of Done enthält.
Meetings
Im Nexus Framework werden alle Meetings, sowohl die Anzahl als auch die Reihenfolge, aus dem Scrum Framework übernommen.
Zunächst trifft sich das Team zum Nexus Sprint Planning. Bei diesem Meeting treffen sich die Vertreter aller Entwicklungsteams und des Nexus Integration Teams. In der Besprechung teilt der Product Owner den Teams mit, welche Aufgaben im nächsten Sprint zuerst in Angriff genommen werden sollen. Anschließend wird ein Nexus Sprintziel erstellt, sodass alle Teams ein klares Verständnis für das Ziel haben. Danach erstellt jedes Scrum Team sein eigenes Sprint Planning und Sprint Backlog.
Nach dem Start des Sprints findet das Nexus Daily Scrum jeden Tag zu einer festen Zeit statt. Alle Vertreter treffen sich, um den Fortschritt der Arbeit zu besprechen, wobei das Sprintziel im Auge behalten wird.
Dieses Meeting beinhaltet immer diese drei Fragen:
- Welche Informationen sollten an die Nexus Teams weitergegeben werden?
- Wurde die Arbeit der letzten 24 Stunden erfolgreich bearbeitet?
- Welche neuen Abhängigkeiten haben sich gezeigt?
In diesem Meeting wird auch das Nexus Sprint Backlog aktualisiert. Die Vertreter geben diese Informationen dann an ihre eigenen Entwickler weiter: Jedes Team organisiert auch sein eigenes Daily Scrum.
In dem Nexus Sprint Review Meeting gibt es einen großen Unterschied gegenüber der Sprint Review, wie wir sie aus dem Scrum Framework kennen. Im Nexus Framework werden keine Einzelergebnisse diskutiert, sondern nur das integrierte Inkrement den Stakeholdern zur Rückmeldung vorgelegt. Daher wird in den einzelnen Entwicklungsteams keine individuelle Sprint Review organisiert.
Zusammenfassend lässt sich sagen, dass die Nexus Sprint Retrospektive in drei Teilen behandelt wird. In der ersten Sitzung kommen alle Vertreter zusammen, um zu besprechen, welche Dinge im vergangenen Sprint gut gelaufen sind und welche nicht.
Möchten Sie mehr über die Sprint Retrospektive im Scrum Framework erfahren? Dann schauen Sie sich unser Animationsvideo an.
In Phase zwei planen alle einzelnen Scrum Teams ihre eigene Sprint Retrospektive, in der die Leistung der eigenen Teammitglieder bewertet wird. Danach, in Phase drei, treffen sich alle Vertreter erneut, um die Ergebnisse und Aktionspunkte der einzelnen Sitzungen durchzugehen.
Zuständigkeitsbereiche
In diesem Framework wird ein Nexus Product Owner benannt. Dieser hat die gleichen Aufgaben wie ein traditioneller Product Owner aus dem Scrum Framework. Überlegen Sie, wie Sie den Wert des Nexus Product Backlogs maximieren können.
Das Nexus Integrationsteam ist für die Integration und Bearbeitung von Abhängigkeiten verantwortlich. Zu diesem Team gehören der Scrum Master, der Product Owner und verschiedene Teammitglieder. Teammitglieder können auch Mitglieder eines Entwicklungsteams sein; unter der Bedingung, dass die Aufgaben im Nexus Integrationsteam immer Vorrang haben. Darüber hinaus kann der Scrum Master auch in einem anderen Scrum Team arbeiten. Wie in Scrum ist diese Person auch im Nexus Framework für den Prozess verantwortlich.
