NEXUS™

Blitzschnellen Zugriff auf die verschiedenen Themen, die Sie interessieren
Ziele, Nutzen Nexus™
NEXUS™ Zusammenfassung, Grundlagen und Wissenstest
Unterschiede FAST und NEXUS™

Ziele, Nutzen Nexus™

Nexus™ gibt als schlankes Scrum-Addon-Framwork Regeln zur Synchronisation von 3-9 Scrum Teams, die gemeinsam an einem Produkt arbeiten, vor. Dabei steht stets ein gemeinsames integriertes (Zwischen-)Ergebnis im Fokus. Zur Erreichung legt Nexus™ großen Wert auf die Indentifikation und Reduktion von Abhängigkeiten in der Entwicklung und damit zwischen den Teams. Als schlanke Scrum-Erweiterung besteht ein Hauptnutzen in der schnell möglichen Umsetzung bei Scrum-erfahrenen Teams. Neben den Benefits bezogen auf das zu entwickelnde Produkt will Nexus™ den vorherigen Lernaufwand gering halten.

NEXUS™ Zusammenfassung, Grundlagen und Wissenstest

(Scaling Scrum with) Nexus™

1.) Einleitung Nexus™ (Scaling Scrum)

Nexus™ (Scaling Scrum) ist ein einfaches Framework um 3-9 Scrum Teams, welche an einem identischen Produkt arbeiten, zu synchronisieren und zu organisieren. Dabei werden die Teams aus dem Kern (“Nexus”) der Gesamtgruppe heraus gesteuert. Nexus™ wurde 2015, also deutlich später als andere Scaled Agile Frameworks wie z.B. SAFe, entwickelt als Ken Schwabers Antwort auf die Frage nach den Skalierungsmöglichkeiten im Scrum-Universum. Es bietet allerdings z.B. keinen Ansatz im Vergleich zu SAFe (“Full SAFe”) oder LeSS (“LeSS Huge”), um die gesamte Unternehmung agil zu gestalten (“Business Agility”)

Um Nexus™ als “Skalierungs-Addon” zu Scrum verstehen zu können und mit seinen Details vertraut zu werden, haben wir eine Zusammenfassung erstellt. Dabei geht es im Wesentlichen um die Ergänzungen zu Scrum durch Nexus™, weniger um Scrum selbst.

2.) Zusammenfassung Nexus™

Einführung

Scrum ist gedacht für Projekte, in denen das Entwicklungsteam drei bis neun Personen umfasst. Sobald ein Projekt größer wird, liefert Scrum keine Empfehlungen, wie diese Projekte aufgebaut bzw. in der Umsetzung skaliert bzw. organisiert werden können. Als Antwort hat Scrum.org bzw. Ken Schwaber das Nexus™ Framework entwickelt (Jeff Sutherland, der Co-Creator von Scrum hat mit Scrum@Scale einen eigenen Ansatz zur agilen Skalierung entworfen). Das Nexus™ Framework zeigt auf, wie drei bis neun Entwicklungsteams zusammenarbeiten können. Dabei baut Nexus™ auf Scrum auf, ist also praktisch als “Addon” zu verstehen und gewollt schmal und “einfach” gehalten.
Nexus™ kann kostenfrei eingesetzt werden, mehrsprachige Guides, Webinare, Blogbeiträge sowie andere erklärende Ressourcen findet man auf der offiziellen Webseite. Darüber hinaus kann man korrespondierende Posts und Fragen im Scrum-Forum einsehen/stellen.
Dabei ist generell zu beachten: Wie beim Scrum Ur-Framework sind die Nexus™ Rollen, Artefakte, Events und Regeln unveränderlich. Falls man nur einen Teil des Frameworks einsetzt oder dieses anpasst, entspricht das Ergebnis nicht mehr Nexus™.

Der Ansatz von Nexus™

Das Nexus™ Framework ist ein Prozess-Rahmenwerk für 3 bis 9 nach Scrum arbeitenden Entwicklungsteams. Diese Teams erzeugen arbeitsteilig gemeinsam ein integriertes Produkt/Software. Der Fokus von Nexus™ dabei ist

  • Abhängigkeiten zwischen den parallel schaffenden Teams zu minimieren sowie

  • Integrationsprobleme von den Teilergebnissen zu reduzieren.

Analog zu LeSS stand Schlichtheit und Einfachheit für Nexus™ im Fokus der Entwicklung. Säulen sind der agile Ansatz Scrum sowie das Manifest für Agile Softwareentwicklung inklusive der entsprechenden Prinzipien. Diese Basis ergänzt das Nexus™-Framework um zusätzliche Rollen, Ereignisse, Ergebnistypen und Regeln. Die Erweiterung wiederum erlaubt das parallele Wirken von bis zu 9 Scrum Teams an einem gemeinsamen Produkt.

Der Begriff “Nexus” (dt.: Neutrum) steht für „Eine Beziehung oder Verbindung zwischen Personen oder Dingen“. In diesem Geist soll das Nexus™ Framework für TransparenzOrientierung und Koordination bei einer verteilten Entwicklung sorgen. Die aktuelle Version der Dokumentation ist aus dem Jahr 2021.

Das Nexus™ Framework

Da das Nexus Framework auf Scrum aufsetzt, werden viele Teile aus Scrum übernommen (bis auf 2 Ausnahmen) bzw. als gegeben angesehen. Hinzukommen einige weitere Elemente, welche die integrativen Aspekte zwischen den Scrum-Teams berücksichtigen.

Diese ergänzenden/ersetzenden Elemente sind:

  • die Rolle „Nexus™ Integration Team“ (zusätzlich zu den einzelnen Scrum-Teams)

  • das Artefakt „Nexus™ Sprint Backlog“ (ergänzt die Scrum-Sprint Backlogs der Teams)

  • das Artefakt „Nexus™ Sprint Goal“ (ersetzt die Scrum-Sprint Goals der Teams)

  • das Event „Nexus™ Sprint Planning“ (erweitert bzw. ersetzt das Sprint Planning der Scrum-Teams)

  • das Event „Nexus™ Daily Scrum“ (das zusätzliche Daily Scrum des Nexus Integration Teams)

  • das Event „Nexus™ Sprint Review“ (ersetzt die einzelnen Sprint Reviews der Scrum-Teams)

  • das Event „Nexus™ Sprint Retrospective (erweitert bzw. ersetzt die Sprint Retrospectives der Scrum Teams).

Die Nexus™ Rollen

Abgeleitet von den 3-9 Scrum-Teams im Nexus™-Framework sind auch die Rollen im Wesentlichen die des Scrum-Frameworks. Da ein Haupt-Fokus auf der Integration (der Teilergebnisse der Teams) liegt, führt Nexus™ lediglich die zusätzliche Rolle des Integration-Teams ein.

Das Nexus™ Integration-Team (NIT) hat also die Verantwortung, dass in jedem Sprint ein integriertes Inkrement erstellt wird. Es coacht, koordiniert und stellt die korrekte Ausführung der parallelen Entwicklungsarbeiten nach Scrum sicher. Ebenso ist es für alle Integrationsprobleme und teamübergreifende Aufgabenstellungen zuständig.

Beispielhafte Aufgaben des NIT :

  • Einführung, Schulung und der reibungslose Betrieb eines Versionierungs- und  Release-Tools

  • Formulierung der Definition of Done

  • Sicherstellen einer effizienten, gemeinsamen Backlog Umgebung.

  • Coaching in Engineering-Fragen (z.B.: Peer Programming, Test Driven Development).

  • Hilfestellung bei der Koordination der Teams

  • Abhängigkeiten im Sprint sichtbar machen

Das Nexus Integration Team ist ebenfalls ein Scrum Team und besteht aus

  • Product Owner (u.a. verantwortlich für das gemeinsame Product Backlog)

  • Scrum Master

  • einem oder mehreren Teammitgliedern

Der Scrum Master und die Teammitglieder können auch (zusätzlich) in anderen Scrum Teams dieses Nexus™ arbeiten. In diesem Fall haben aber die Aufgaben im Nexus™ Integration Team Vorrang. Die Teammitglieder des Nexus™ Integration Teams könnten sich auch, je nach den aktuellen Bedürfnissen, während der Zeit ändern.

Die Nexus™ Artefakte und Commitments

Nexus™ Product Backlog
(Commitment: Nexus™ Product Goal) 

Das Nexus™ Product Backlog ersetzt alle Product Backlogs der Teams, da Nexus™ das gemeinsame Arbeiten an einem Produkt in den Mittelpunkt stellt. Die Teams müssen das gemeinsame Product Backlog so weit verstehen, dass Abhängigkeiten festgestellt und minimiert werden können. Das Product Backlog wird durch den Product-Owner (des NIT) erstellt und verantwortet. Das Nexus™ Product Goal beschreibt einen zukünftigen Zustand des Produkts und dient dem Nexus™ als langfristiges Ziel.

Nexus™ Sprint Backlog
(Commitment: Nexus™ Sprint Goal) 

Neben den Sprint Backlogs der einzelnen Scrum Teams im Nexus™ gibt es noch das Nexus™ Sprint Backlog. Dieses Nexus™ Sprint Backlog ist die Summe aller daraus abgeleiteten Sprint Backlogs der Teams in diesem Sprint. Es dient dazu, die Abhängigkeiten unter den Scrum Teams aufzuzeigen. Das Nexus™ Sprint Goal ersetzt die Sprint Goals der einzelnen Scrum-Teams und wird in jedem Nexus™ Sprint Planning für den jeweiligen Sprint definiert. Es ist das Ziel des gesamten Nexus™ mit allen Scrum Teams.

Integrated Increment
(Commitment: Definition of Done) 

Das Integrated Increment repräsentiert die aktuelle Summe aller integrierten Arbeit, die von einem Nexus für ein Produkt‐Ziel fertiggestellt wurde. Das Integrated Increment wird im Nexus Sprint Review überprüft, kann aber auch vor dem Ende des Sprints an Stakeholder/innen geliefert werden. Dabei ist wie bei Scrum die Definition of Done die qualitative Messlatte, auf die sich alle Teams geeinigt haben. Die Grundanforderung wird so beschrieben:

”Das Increment ist nur dann fertig, wenn es integriert, wertvoll und nutzbar ist.”

Die Teams für sich dürfen eine eigene, aber abgeleitete Definition of Done definieren. Diese muss die gemeinsamen Qualitätsregeln aber übertreffen.

Die Nexus™ Events

Der Sprint 

Analog zu Scrum nur mit Fokus auf gemeinsames Inkrement

Teamübergreifendes Refinement 

Das Product-Backlog ist so zu refinen, das Abhängigkeiten transparent, teamübergreifend identifiziert und beseitigt oder minimiert sind. Ein solches Refinement ist u.a. die Basis für ein effizientes Sprint Planning und auch deshalb ein andauernder Vorgang. Sind Abhängigkeiten für Items beseitigt ist in diesem Kontext auch die Zuordnung zu den Teams eindeutig bzw. offensichtlich, welches Team die einzelnen Items liefern wird.

Nexus™ Sprint Planning 

Das Nexus™ Sprint Planning erfolgt in zwei Schritten:
1.) Treffen des gesamten Nexus™ Integration Teams im Nexus™ Planning. Dort wird das Nexus Sprint Goal definiert sowie alle in diesem Sprint abzuarbeitenden Product Backlog Items (User Storys) ausgewählt. Alle Abhängigkeiten zwischen diesen Items werden identifiziert und dokumentiert.

2.) Nach inhaltlichem Abschluss des Nexus™ Sprint Plannings trifft sich jedes Scrum Team zu seinem eigenen Sprint Planning. In diesen Sprint Plannings werden die Items bzw. Storys in Tasks und ggf. Sub-Tasks untergliedert und in die Scrum-Team-interne Organisation verplant. Sobald alle Sprint Plannings der Scrum Teams beendet sind, ist auch das Nexus Sprint Planning formal beendet.

Je nach Größe des Projektes (Menge Teams/Mitglieder) können die Inhalte der Sprint-Plannings auch in das Nexus Sprint Planning integriert werden.

Nexus™ Daily Scrum 

An dem Nexus™ Daily Scrum nehmen außer dem Product Owner und einem Scrum Master geeignete Repräsentanten aus den Scrum Teams teil. Der Fokus dieses Events liegt dabei auf der Identifikation und Klärung von Integrationsproblemen und damit auf dem integrierten Inkrement.
Zitat Nexus™ Guide:

…Wurde die Arbeit von gestern erfolgreich integriert? Falls nein, warum nicht? Welche neuen Abhängigkeiten wurden identifiziert? Welche Informationen müssen zwischen Teams im Nexus geteilt werden?…

Die Vertreter der Scrum-Teams nehmen die Ergebnisse dieses Events mit in deren separate Daily Scrums, die dementsprechend direkt im Anschluss stattfinden sollten.

Nexus™ Sprint Review 

Da bei Nexus™ das integrierte Inkrement im Fokus steht und man alle involvierten Scrum-Teams als ganzes Team versteht, wird die separate Betrachtung der Sprintergebnisse der einzelnen Teams unbedeutend. Demnach ersetzt das Nexus™ Sprint Review alle Scrum-Sprint Reviews innerhalb eines Sprints, wobei der behandelte Inhalt aber identisch bleibt (dieser aber immer im Kontext des integrierten Inkrementes steht).

Nexus™ Sprint Retrospektive 

Wie in Scrum ist bei Nexus™ die Retrospektive die Möglichkeit, sich und den gelaufenen Sprint kritisch zu hinterfragen und Verbesserungen anzustoßen. Die Nexus™ Sprint Retrospective in drei Schritte aufgeteilt.

  1. Treffen geeigneter Repräsentanten aus den Scrum Teams mit dem Product Owner und dem Scrum Master, um übergreifende Probleme zu identifizieren.

  2. Im zweiten Schritt führt jedes Scrum Team seine Sprint Retrospektive durch. Dabei bringt der Repräsentant die relevanten, übergreifen Themen vom ersten Schritt mit in dieses Event.

  3. Die Repräsentanten treffen sich abermals mit dem Product Owner und dem Scrum Master, um die relevanten Ergebnisse und Beschlüsse der Sprint Retrospektiven aus dem zweiten Schritt zusammenzufassen und zu kommunizieren.

Je nach Größe des Projektes (Menge Teams/Mitglieder) können die Inhalte der Scrum-Sprint Retrospektive auch in die Nexus™ Sprint Retrospektive integriert werden.

Wie kann man Nexus™ einsetzen?

Nexus™ möchte agile Skalierung ermöglichen, indem es Informationen und Aufgaben zwischen 3-9 Scrum Entwicklungsteams verteilt. Dies geschieht entlang von 3 Ebenen:

  • Fachliches und technisches Wissen

  • Anforderungen und Randbedingungen

  • Software- und Testergebnistypen

Nexus “zwingt” die Scrum-Teams also, das “große ganze” Produkt im Fokus zu behalten, sich und Ihre Arbeit unter dem Aspekt der Integrationsfähigkeit auszurichten und sich nicht ausschließlich auf ein (unabhängiges) Teilergebnis zu fokussieren. Das Framework sieht zudem eine gemeinsame Entwicklungsumgebung vor, in der alle Beteiligten ihre Resultate integrieren sollen. Dadurch will Nexus eine Minimierung von Abhängigkeiten zwischen den(Teil-)Ergebnissen erzielen, eine der Hauptintentionen. Die gemeinsame Entwicklungsebene ist auch ein impliziter Grund für eine starke Fokussierung auf die Softwareentwicklung, wobei Nexus™ auch für die Entwicklung von Produkten jeglicher Art einsetzbar sein soll (was unter diesen Aspekten vielleicht nicht immer einfach sein dürfte) .

Der Prozess des Nexus™ Frameworks durchläuft die nachfolgenden Schritte:

  • Refinement des (gemeinsamen) Product Backlogs

  • Durchführung des Nexus™ Sprint Plannings

  • darin: Erstellung Nexus™ Sprint Backlog und die Sprint Backlogs der einzelnen Scrum Teams

  • Durchführung der Nexus™ Daily Scrums und der Daily Scrums der Teams

  • Refinement des Product Backlogs

  • Durchführung des Nexus™ Sprint Reviews

  • darin: Vorstellung des integrierten Inkrements,

  • Durchführung der Nexus™ Sprint Retrospektive und Sprint Abschluss

  • Start des nächsten Sprints mit der Durchführung des Nexus™ Sprint Plannings.

Anpassungen & Adaptionen dieses Vorgehens haben immer zur Konsequenz, dass man den Rahmen des Nexus™ Frameworks verlässt (wenig Spielraum in der Ausgestaltung)

Vor- und Nachteile von Nexus™

Fazit

Absolvieren Einzelteams in der Unternehmung bereits kleine Entwicklungsprojekte nach Scrum und soll das agile arbeitsteilige Vorgehen auf mittlere Vorhaben skaliert werden, dann kann das Nexus™-Framework ein sinnhaftes Addon mit Mehrwert im Bereich Integration und Reduktion von Abhängigkeiten sein, besonders im Vergleich zu Scrum of Scrums. Während diese Technik sich aber weiter vertikal zu Scrum of Scrum of Scrums skalieren lässt, bietet Nexus™ hier aktuell keine weitere Skalierungsebene.

Auch hier “springt” Nexus™ offenbar bewusst kürzer, in dem die Skalierbarkeit “geboxed” wird, um Sie besser mit klaren und strikten Regelwerken auszustatten. Dies birgt für solche passenden Projekt-Situationen sicherlich einen Qualitäts- und Geschwindigkeitsgewinn und macht Nexus™ zur besten Wahl, impliziert aber ebenfalls, dass Nexus nur für eine begrenzte Art von Projekten wirklich sinnhaft ist. Ggf. war das auch der Grund für den zweiten Scrum-Vater Jeff Sutherland, mit Scrum@Scale einen separaten eigenen Ansatz zu entwickeln.

Die Einsatzmöglichkeiten werden durch den impliziten Softwareentwicklungsfokus und die fehlende Erweiterungsoption Richtung Business Agility weiter eingeschränkt, sodass Nexus™ für Unternehmen in Ihrer Agile-Evolution in den wenigsten Fällen dauerhaft ausreichen wird. Hier bieten SAFe und LeSS einen umfassenderen und zukunftsfähigeren Ansatz, “gemeinsamer Nenner” sind aber immer auch dort die Scrum-Teams. Weder Nexus™, noch die weiterführenden Frameworks zeigen Möglichkeiten der Co-Existenz bzw. der Integration auf. Ist also bekannt, dass Nexus™ für die Zukunft einem Unternehmen nicht ausreicht, dann eignet sich das Framework auch nicht als sinnhafter kleiner/einfacher Iterationsschritt.

3.) Wissenstest (Fragen & Antworten)

Unterschiede FAST und NEXUS™

Generell

  • Nexus versteht sich als Scrum-Ausbaustufe, sozusagen als Addon zu Scrum, wenn bei einer Produktentwicklung 3-9 Scrum Teams beteiligt sind. Es ist dadurch schlank, einfach zu adaptieren, bietet aber keinen universellen Einsatz für jegliche Art von Produktentwicklung. Die Einbindung umliegender relevanter (nicht IT-)Organisationseinheiten in eine solche Entwicklung wird dabei nicht reflektiert. Der breitere, an SAFe angelehnte Aufbau von FAST bietet hierbei mehr integrative Ansätze von solche Produktarten. FAST kann deshalb als ganzheitlicher Ansatz angesehen werden.

  • FAST realisiert, ähnlich wie SAFe, einen “managementaffineren” Approach im Umgang mit Agilität in der Produktentwicklung, indem es sich um Themen wie Reporting, Vision, Risikomanagement, Budgetcontrol usw. explizit kümmert und besonders im der Evolution in die Agilität die Managementebenen besser einbezieht. Nexus blendet diese Themen komplet aus und legt die in die Selbstbestimmtheit/Selbstorganisation der Teams.

  • Nexus™ ist wie Scrum mit einer starren Perspektive auf das Produkt ausgestattet. FAST bringt eine stärkere Kundenorientierung innerhalb der Frameworks mit. Kundenorientierung realisiert Nexus höchstens implizit durch die Skills des PO’s, adressiert diese aber nicht konkret.

Bereich Big Picture (High Level) & Co.

  • Nexus hat die Evolution Richtung Business Agility nicht im Fokus und bleibt deshalb bewusst “schlank”. Beim “Nexus™ Framework Poster” von einem “großen” Bild zu sprechen wäre deshalb auch übertrieben. Erfahrene Scrum-Nutzer finden sich schnell ein und können die wenigen Erweiterungen schnell adaptieren. FAST ist dort deutlich breiter aufgestellt (im Vergleich zu SAFe aber noch schlank) und möchte den Anwender auch Richtung Business-Agility ein gewisses Stück begleiten, allerdings wird durch die Nähe zu SAFe ein Umstieg ab einer gewissen Dimension empfohlen und ist auch einfachst möglich (durch viele SAFe Parallelen). Auch die offenere Ausrichtung der Projekt- bzw. Produktarten bei FAST erfordern zwangsläufig ein größeres Big-Picture. FAST ist demnach universeller einsetzbar und begleitet den Anwender deutlich länger in seiner agilen Entwicklung, als dies Nexus vermag.

  • Nexus™ stellt, wie Scrum, den Kundennutzen des Produktes (gelenkt durch den Product Owner) in den Vordergrund des Frameworks, ergänzt durch eine effizientere Integration. Abgeleitet von SAFe steht bei FAST der Business Value im Vordergrund, also eine mehr ökonomisch geprägte Sicht.

Bereich Core Values

  • Nexus™ bezieht sich stärker auf das zu erstellende (Software-)Produkt und fokussiert sich auf das orchestrieren der beteiligten Teams, um den Wert des Gesamtergebnisses (integriertes Inkrement) in diesen Punkten zu verbessern. Dies korrespondiert zum Alignment und zur Transparency in FAST. Weitere Core Values werden von Scrum bzw. der Selbstbestimmtheit der Scrum Teams maximal implizit übernommen. FAST adressiert hingegen z.B. explizit den Business-Value über Built-In Quality und Program Execution als Fokus. FAST kann zudem für kleine und riesige Projekte eingesetzt werden.

    • FAST: Alignment, Built-In Quality, Transparency, Program Execution

    • Nexus™: Minimierung von Abhängigkeiten, Reduktion von Integrationsproblemen

Bereich Core Elements

  • Rhythmus & Takt bzw. anpassen der Sprintintervalle: Nexus™ geht bei der Organisation der Sprints davon aus, dass sich alle beteiligten Teams der Nexus-Sprintregelung (“Takt”) unterwerfen. Besonders bei der Einbindung externer Teams dürfte dies in der Praxis nur schwerlich so umzusetzen sein. Nexus liefert hier keinerlei praxisnaheren Ansätze - im Gegensatz zu FAST: Hier ist die Orchestrierung der beteiligten Teams in einen Rhythmus das wesentlich Core Element. Neben der Relevanz werden darüber hinaus Methoden dargestellt, wie ein gemeinsamer “Rhythm” bei unterschiedlichen Situationen hergestellt werden kann.

  • Valuestreams (FAST): Bei FAST werden die Ziele und der Scope über “Slice the Elephant” (Capabilities bzw. Components) geschnitten und in 1-n Valuestreams verortet. In der Praxis kann man davon ausgehen, das Valuestreams in der Regel mit den Hauptaufgaben einzelner Teams in Nexus™ korrespondieren. Da Valuestreams aber nicht auf einzelne Teams beschränkt sind, ist bei FAST die Idee in der Aufteilung eine andere.

  • Season Planning (FAST) und weitere Zeiteinheiten: Während Nexus™ - wie Scrum - nur Sprints als planbare Zeiteinheit kennt arbeitet FAST mit Seasons, Years und Epochen. Besonders die Seasons und das damit verbundene Seasonplanning hilft dabei, sich auch für einen größeren Zeitraum mit konkreten Zielen/Goals zu fokussieren. Ggf. ist der naheliegende Vergleich zum-Meilensteindenken aus dem Wasserfall ein weiteres Argument für diese Art der Planung. Innerhalb des Season Plannings selbst ist die Betrachtung & Verplanung der realistischen Kapazität der Teams und -mitglieder ein elementarer Faktor - Nexus impliziert diesen Punkt (wie weitere Aspekte) in die Selbstbestimmheit der Teams innerhalb des Sprint Plannings.

….still growing