Als Steward für das Scaled Professional Scrum mit Nexus Training habe ich vor einiger Zeit an einer Podiumsdiskussion von Scrum.org über die Skalierung von Scrum mit dem Nexus Rahmenwerk teilgenommen.
Bei dieser Diskussion konnten Yuval Yeret, Ravi Verma, Magdalena Firlit, Patricia Kong und ich nicht alle Zuschauerfragen beantworten, deshalb möchte ich das jetzt nachholen.
Und los geht’s!
Frage 1: „Was können zwei Teams tun, die voneinander abhängen, um ihre Arbeit zu bewältigen?“
Die Voraussetzung für eine erfolgreiche Skalierung von Scrum ist, dass die Teams weiterhin in der Lage sind, bis zum Ende des Sprints ein integriertes Inkrement bereitzustellen.
Dazu sollte es für zwei Teams genügen, den Fortschritt der Integration der Arbeit transparent zu machen und die Kommunikation zwischen den Teams zu fördern. Eine Möglichkeit dafür ist es, dass die Teams sich täglich vor ihren Team Daily Scrums zu einem teamübergreifenden Daily Scrum treffen, um dort etwaige Integrationsprobleme transparent zu machen, welche dann in den Teams gelöst werden können. Ferner kann die Kommunikation zwischen den Teams gefördert werden, wenn diese etwa Teile der Scrum Events gemeinsam bestreiten.
Kommunikation und Austausch sind bei der Skalierung von Scrum ein Garant für Erfolg, da ein Großteil der Abhängigkeiten in der Softwareentwicklung auf Wissenslücken zurückzuführen ist.
Frage 2: „Wie können Abhängigkeiten minimiert werden?“
Das Nexus Rahmenwerk hilft Scrum Teams maßgeblich bei der Reduzierung von teamübergreifenden Abhängigkeiten.
Im verpflichtenden, teamübergreifenden Refinement des Product Backlogs kommen die Scrum Teams zusammen und zerlegen das Product Backlog, sodass Abhängigkeiten zwischen den Product-Backlog-Einträgen und den Scrum Teams sichtbar werden. Sobald die Abhängigkeiten sichtbar sind, können sie von den Teams eliminiert werden, beispielsweise indem die Product-Backlog-Einträge zerkleinert oder neu aufgeteilt werden. Um langfristig Abhängigkeiten zu vermeiden, haben sich Entwicklungspraktiken wie Pair- und Mobprogramming, Inner Sourcing oder die Rotation von Teammitgliedern bewährt.
Erfolgreiche Nexus-Implementierungen zeichnet aus, dass die Minimierung von Abhängigkeiten zum Arbeitsalltag der Teams gehört.
Frage 3: „Wie können die Scrum Teams ihre Arbeit am Ende eines Sprints zu einem Inkrement integrieren?“
Je mehr Scrum Teams an einer gemeinsamen Codebasis arbeiten, desto mehr Integrationskonflikte kann es geben.
Nur durch häufiges Committen der Codeänderungen wird sichergestellt, dass diese Änderungen erfolgreich integriert werden können. Denn je mehr Code auf einmal committet wird, desto größer ist die Wahrscheinlichkeit, dass ein Konflikt auftritt. Um häufiger zu committen, hilft kontinuierliche Integration sowie die Entwicklungspraktik, dass das Check-in oder der Code-push automatisch zu einem Build und automatisierten Tests führt.
Je höher der Grad an Automatisierung ist, desto einfacher gestaltet sich die Integration, wenn die Codebasis wächst.
Frage 4: „Wie arbeitet das Nexus Integration Team in der Praxis?“
Das Nexus Integration Team ist dafür verantwortlich, dass mindestens einmal pro Sprint ein fertiges Integrated Inkrement erzeugt wird.
Wie das Nexus Integration Team das sicherstellt, hängt von der aktuellen Situation ab. Wichtig dabei ist aber, dass das Nexus Integration Team bei der Lösung von Problemen auf „Bottom-up”-Erkenntnisse innerhalb des Nexus zurückgreift und die Scrum Teams durch Coaching oder Mentoring dabei unterstützt, die Integrationsprobleme eigenständig zu lösen. Und nur im Notfall sollte sich das Nexus Integration Team aktiv an Lösungen beteiligen. Damit soll verhindert werden, dass das Nexus Integration Team selbst zum Flaschenhals der Integration der Arbeit der Scrum Teams wird.
Das Nexus Integration Team hilft den Scrum Teams sich darauf zu fokussieren, gemeinsam ein wertvolles und nützliches Inkrement herzustellen.
Frage 5: „Im neuen Nexus Guide wurden die 2 Teile des Nexus Sprint Planning und die 3 Teile der Nexus Sprint Retrospektive entfernt. Gibt es dafür einen bestimmten Grund?“
Der Nexus als Ganzes hat gegenüber den einzelnen Scrum Teams immer Vorrang.
Das Nexus Sprint Planning dient dem Zweck, die Aktivitäten aller Scrum Teams innerhalb eines Nexus für einen einzelnen Sprint zu koordinieren. Der Zweck der Nexus Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität über den gesamten Nexus hinweg zu planen. Wir sehen also, dass es bei beiden Events darum geht, „Bottom-up”-Erkenntnisse zu nutzen, um die Produktentwicklung zu koordinieren oder den Nexus zu verbessern. Wie das geschehen soll, ist von Produkt zu Produkt und von Nexus Implementierung zu Nexus Implementierung verschieden und sollte deshalb nicht in einem Guide beschrieben werden.
Natürlich bleibt das zweiteilige Sprint Planning oder das „Sandwich“-Format für die Nexus Sprint Retrospektive weiterhin eine gute Möglichkeit, dieses Event zu gestalten.
Frage 6: „Wie lautet die Time Box für die einzelnen Nexus Events?“
Timeboxing ist eine wichtige Praktik in Scrum, um den Fokus auf die zu erreichenden Ergebnisse zu lenken und somit Verschwendung und Risiko zu minimieren.
Wenn mehrere Scrum Teams gemeinsam ein Produktinkrement entwickeln, befinden sich die Teams manchmal in unterschiedlichen Ländern, Kontinenten oder Zeitzonen. Deshalb gibt der Nexus Guide keine explizite Zeitangabe mehr, wie lange die Events dauern sollen. Im Guide ist nur festgehalten: Die Dauer der Nexus Events richtet sich nach der Länge der entsprechenden Events im Scrum Guide. Sie sind zusätzlich zu den zugehörigen Scrum Events zeitlich beschränkt.
Wichtig: Das heißt nicht, dass es keine Time Boxen mehr gibt, sondern nur, dass der Nexus sie selbst setzen muss.
Frage 7: „Wie unterscheidet sich die Product-Owner-Rolle in Nexus und in SAFe?“
Die Verantwortlichkeit des Product Owners im Scrum Guide unterscheidet sich tatsächlich sehr von der Product-Owner-Rolle in SAFe.
Im Scrum Rahmenwerk ist der Product Owner ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Der Product Owner in SAFe ist für das Team-Backlog verantwortlich und dieses enthält nur die Anforderungen an ein Team. Im SAFe kann ein Product Owner diese Aufgabe nur für bis zu zwei Teams übernehmen. Im Scrum Guide sind der Anzahl der Teams, die an einem Produkt arbeiten und für welche dann auch nur ein Product Owner verantwortlich ist, keine Grenzen gesetzt.
Wahrscheinlich korreliert die Verantwortung des Product Owners in einem Nexus mit mindestens drei Scrum Teams eher mit der Product-Management-Rolle in SAFe.
Frage 8: „Können die Teams im Nexus auch nach Kanban arbeiten?“
Was unterscheidet Scrum von Kanban?
Scrum Teams arbeiten in Sprints. Diese Time Boxen ermöglichen Konsistenz und regelmäßige Überprüfung und Anpassung. Bei Kanban ist das nicht zwingend nötig. Jedes Team, welches Teil des Nexus ist, muss aber eine Kadenz einhalten. Das gilt auch für Kanban Teams. Nur wenn diese auch an den Nexus Events teilnehmen und diesen Rhythmus in ihre Arbeitsweise integrieren, sollten sie Teil eines Nexus sein.
Es spricht nichts dagegen, dass Scrum Teams auch nach der Kanban Methode arbeiten.
Frage 9: „Wie kann die Velocity der einzelnen Scrum Teams verwendet werden, um Vorhersagen für den Nexus zu treffen?“
Die Velocity ist eine interne Teamgröße und für jedes Team verschieden.
Dies gilt auch für die Scrum Teams innerhalb eines Nexus. Eine Standardisierung der Velocity über Teamgrenzen hinweg ist deshalb nicht sinnvoll. Sollen Vorhersagen für den Nexus aufgrund der Velocity getroffen werden, muss dazu auch der ganze Nexus als Entwicklungseinheit betrachtet werden. Beispielsweise kann dazu die Velocity auf dem Level von Features oder Epics betrachtet werden.
Feature-Velocity ermöglicht Vorhersagen für den Nexus.
Frage 10: „Nexus oder SAFe: Nach welchen Kriterien sollten Organisationen entscheiden, welches Skalierungsrahmenwerk gewählt werden sollte?“
Wichtiger als die Anzahl der Teams, Rollen und Artefakte ist es, bei der Entscheidung darauf zu achten, ob das Skalierungsrahmenwerk die Werte des Unternehmens widerspiegelt.
Für Organisationen, die traditioneller geprägt sind, denen Zentralisierung bei der Skalierung wichtig ist, und die auf vordefinierte Praktiken zurückgreifen wollen, um gewohnte Prozessstandards weiterhin einzuhalten, könnte SAFe die richtige Wahl darstellen.
Unternehmen, die einzigartig sind, Produkte und Teams organisch skalieren wollen, nur auf einen minimalen Rahmen zurückgreifen möchten, um Empirie zu ermöglichen, und eigene Praktiken hinzufügen wollen, um anpassungsfähig zu bleiben, sind wahrscheinlich besser mit Nexus bedient.
Am Ende sollte das Skalierungsrahmenwerk das Werteverständnis der Organisation widerspiegeln.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Scrum zu skalieren, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.