Was ist Nexus?

Was ist Nexus?

In der Praxis arbeiten einige Unternehmen mit Teilen aus dem Nexus-Framework, ohne es wirklich zu merken. Warum? Ein Scrum Team ist nicht mehr der Regelfall. Viele Unternehmen haben mittlerweile mehrere Scrum Teams implementiert und suchen sich zu Beginn eigene Lösungen, wie Teams miteinander kommunizieren oder planen sollen. Nexus ist ein Framework wie Scrum und kommt von scrum.org. Anders als viele denken, konzentriert sich Nexus rein auf die Produktentwicklung und nicht auf die Unternehmensentwicklung. Doch was ist Nexus? Wie funktioniert das Framework? Gibt es Alternativen? Diesen Fragen gehe ich heute nach.

Was ist Nexus?

Als Nexus wird eine gemeinsame Entwicklungseinheit beschrieben, die an einem komplexen Produkt arbeitet. Entwicklungseinheiten bilden unsere Scrum Teams, die aus Scrum Master, Product Owner und einem Team aus Entwicklern bestehen. Im Nexus versuchen wir Antworten darauf zu geben, wie wir es schaffen, mit 3 bis 9 Teams organisiert und strukturiert ein integriertes Inkrement zu erzeugen. Viele, die mit Scrum arbeiten, haben schon von Nexus gehört.

Da wir über eine skalierte Produktentwicklung mit 3 bis 9 Teams sprechen, denken viele, dass es hier im Vergleich einige neue Inhalte gibt. Ich behaupte, dass die meisten Unternehmen, die mit Scrum gearbeitet haben, falls notwendig in Nexus übergehen. Das bedeutet, dass einige Inhalte und Rollen bereits klar sind. In Nexus geht es stark um das Verständnis und die Bereitschaft, mehrere Ressourcen gemeinsam entwickeln zu lassen. Viele „neue“ Inhalte (Rollen, Artefakte, Events) kommen deswegen nicht hinzu.

Inhalte von Nexus: Rollen und Events

Kann ich also „einfach“ mit Nexus loslegen, wenn ich schon einige Scrum-Erfahrung habe? Nein. Zwar finden wir bereits bekannte Inhalte vor, trotzdem gibt es Neues, dass wir wissen und vor allem verstehen müssen. Zu unseren bekannten Rollen kommt das Nexus Integration Team (NIT) hinzu. Das besteht aus Product Owner, Scrum Master und weiteren Teammitgliedern (etwa Repräsentanten aus den Entwicklungsteams). Verantwortlich für das integrierte Inkrement achtet das NIT darauf, dass die einzelnen Teams an den richtigen Aufgaben arbeiten und dass ihr Output integriert werden kann in ein „komplettes“ Inkrement am Ende eines Sprints. Dafür versucht das NIT schon im bekannten Refinement, dass Product Backlog so vorzubereiten, dass Priorisierung, Abhängigkeiten, Zuteilung und Inhalte klar sind.

Die wichtigsten Aktivitäten für Nexus finden wir meiner Meinung nach in den Events wieder. Haben wir mehrere Teams, die an einem Produkt arbeiten, müssen diese gemeinsam planen und am Ende des Sprints auch gemeinsam mit den Stakeholdern klären, was im Sprint erstellt wurde. Alle Teammitglieder kommen zusammen und picken sich die Aufgaben aus dem Product Backlog, um wie eben beschrieben am Ende des Sprints mit den anderen Teams ein gemeinsames Inkrement liefern zu können. Dabei arbeiten die Teams in gleichen Sprintlängen, sodass eine Synchronisation zu jeder Zeit möglich ist. Genau in diesen gemeinsamen Events liegt meist die Herausforderung. Manche Organisationen gestatten es nicht, dem gesamten Nexus für das gleiche Event Zeit zur Verfügung zu stellen. Aber genau das ist das Wichtige in den Skalierungsansätzen: Gemeinsames Planen, Überprüfen und Anpassen. Hierbei brauchen wir wieder einmal das klare Verständnis dafür, was benötigt wird, um regelmäßig qualitativ hochwertigen Output zu liefern.

Alternativen zu Nexus: Andere Skalierungsmodelle

Neben Nexus gibt es noch andere Frameworks und Methoden, die sich auf eine skalierte Lösungsentwicklung konzentrieren. Da wäre z. B. LESS (Large Scale Scrum) oder das bekannte SAFe (Scaled Agile Framework). Beide Vorgehensweisen gestalten sich umfänglicher als Nexus, da sie auch Antworten auf eine Unternehmensentwicklung geben möchten.

LESS erscheint mir persönlich als das agilste Framework. Wir bleiben dabei in unseren Scrum-Rollen und versuchen, viel durch selbstorganisierte Teams zu regeln. Verantwortung wird klar nach unten übertragen, um schneller Entscheidungen treffen zu können. Dabei sagt das Framework ganz klar: Um mit LESS arbeiten zu können, brauchen wir viel Erfahrung im agilen Bereich.

SAFe hingegen benötigt einige Rollen mehr und bildet in seiner kompletten Ansicht insgesamt drei Ebenen ab: Essential, Large und Portfolio SAFe. Nutzen können wir es bei der agilen Entwicklung von Lösungen (Services, Systemen oder Produkten) und/oder für die Unternehmensentwicklung – je nachdem, wie wir das Framework anpassen und welche Ebene wir benutzen. Wichtig ist zu wissen, dass wir ein Unternehmen auf Portfoliolevel nur komplett verändern können, wenn wir unser Portfoliolevel von SAFe mit einbeziehen.

Viele Vorgehensweisen der Frameworks ähneln sich jedoch. Das Mindset und Verständnis für agiles Arbeiten muss vorhanden sein, um früher Erfolge erkennen zu können. Bei Nexus haben wir das gemeinsame Durchführen von Events kennengelernt. Ähnlich finden wir es bei SAFe. Das sogenannte PI (Program Increment) Planning umfasst alle Teams und Rollen, die an der Bereitstellung der Lösung beteiligt sind. Nur wird hierbei nicht nur ein Sprint geplant, sondern direkt mehrere. Schauen Sie sich zu diesem Thema gern auf unserem YouTube Channel um. Dort finden sie einige interessante Videos zu SAFe und Nexus.

Fazit: Nexus als idealer Einstieg ins Skalieren

Auf dem Markt gibt es die verschiedensten Modelle und Antworten auf Skalierungsmöglichkeiten in der agilen Welt. Nexus ist für mich der simpelste Einstieg, wenn wir bereits Erfahrungen im Bereich Scrum haben. Dabei müssen wir genau wissen, dass wir mit Nexus eine reine Produktentwicklung betrachten und nicht direkt ein gesamtes Unternehmen umstrukturieren wollen. Mit Nexus haben wir mehrere Scrum Teams, die gemeinsam an einer Lösung arbeiten. Dabei können wir schon einmal testen, wie die Akzeptanz und das Verständnis für eine Skalierungsform aussehen.

Merken wir, dass es funktioniert und wir in Richtung Unternehmensentwicklung fortfahren möchten, ist SAFe eine gute Wahl. Teams kennen sich schon in der Zusammenarbeit und dem gemeinsamen Planen von Sprints aus und können so reibungsloser ins SAFe Framework übergehen. Dafür müssen wir ihnen als Unternehmen Zeit geben. Es dauert, bis wir erfahrene Scrum Teams haben und es dauert, bis wir mit Nexus arbeiten und komplexe Produkte liefern können. Auch eine gesamte Unternehmensentwicklung braucht Zeit.

Interessiert Sie eine der genannten Lösungen ganz besonders? Dann sprechen Sie uns an oder besuchen sie gerne ein Training. Wir beraten Sie auf dem richtigen Weg zum Skalierungsframework!