Nexus strukturiert hier schon vorsichtiger: Es sollten maximal 9 Teams mit 90 Leuten sein – Im Idealfall sogar weniger. Es wird nicht benannt, wo die Teams herkommen und eine Skalierung des Nexus auf Nexus+ mit mehreren hundert Personen sollte sehr, sehr gut überlegt werden und kommt auch nur selten zum Einsatz.
Kernelement bei Nexus ist das Nexus Integration Team (NIT). Das NIT löst Probleme auf skalierter Ebene in einem separatem Daily, welches vor den eigentlichen Team Dailies stattfindet. Die Faustregel lautet, dass erst das Gesamtsystem optimiert werden soll, bevor es an die Subsysteme der Teams geht. Ebenfalls ist das NIT darauf bedacht, Dependencies zu identifizieren und nach Möglichkeit zu beseitigen. Das wird vor allem durch das Nexus Sprint Planning Board visualisiert. Dies ist kein Kanban, sondern dient ausschließlich der Verfolgung von Dependencies. Weitere Aufgaben sind der Coaching Aspekt, der den Knowledge Transfer begünstigt sowie das Overall End-to-End Testing. Dies sollen die Teams selbst machen und es wird lediglich aufgepasst, dass dies passiert. Im NIT befinden sich die für die aktuelle Situation kompetentesten Leute. Das bedeutet im Umkehrschluss, dass jeden Tag neben dem PO andere Personen vor Ort sein könnten.
In SAFe werden diese Kompetenzen durch den ART Sync einmal in der Woche angesprochen bzw. gibt es ein separates System Team für das Overall End-to-End Testing. Die Etablierung dieser Institutionen obliegt dem Chief Scrum Master, der Release Train Engineer genannt wird. Die Teams selbst können natürlich jederzeit ihre Dependencies untereinander koordinieren. Visualisiert werden diese durch das ART Planning Board. Kernelemente bei SAFe sind im weiteren Sinne die vier Core Values (Alignment, Transparency, Respect for People, Relentless Improvement) von denen sich Handlungen ableiten lassen.
Communities of Practice (CoPs) werden in Nexus nicht direkt genannt. Sie werden aber berücksichtigt und es wird ihnen implizit Raum gegeben. Bei SAFe werden sie von Anfang an befürwortet und vor allem im Advanced Scrum Master Kurs detaillierter eingesetzt.
Zum Ende kommt der interessanteste Aspekt von Nexus – Descaling! Ganz genau, Nexus befürwortet ab einer gewissen Größe keine weitere Skalierung, sondern das Gegenteil: Ein Team soll aus dem Nexus wieder herausgenommen werden. Dies ist abgeleitet vom „Gesetz des abnehmenden Ertrags“, denn Value wächst nicht proportional mit jedem Team, sondern wird immer teurer. Daher kann man durchaus das Experiment wagen und ein zusätzliches Team hinzufügen. Man sollte dann aber auch den Mut besitzen, dieses gegebenenfalls wieder abzuziehen. Skalieren muss sinnvoll sein und das ist das Schöne am Nexus.
