Projektmanagement Implementierung von Nexus Scaled Scrum Jasmina Muhic, Senior Project Manager Braincourt GmbH Braincourt GmbH, Fasanenweg 11, 70771 Leinfelden-Echterdingen, T +49 711 75 85 80 0, F +49 711 75 85 80 80, info@braincourt.com Niederlassungen Düsseldorf München
Inhaltsverzeichnis 1 Einführung in das Thema... 3 2 Nexus Rahmenwerk... 3 2.1 Rollen... 4 2.2 Artefakte... 4 2.3 Events... 5 3 Umsetzung... 5 4 Fazit... 6 5 Ansprechpartner... 7 6 Literaturverzeichnis... 7 Seite 2
1 Einführung in das Thema Scrum ist ein Rahmenwerk für die agile Entwicklung von Produkten. Das Scrum- Team besteht aus Entwicklern, die funktionsübergreifende Rollen haben. Das Team setzt wiederum Anforderungen um, die in der Form von User Stories beschrieben sind. Die Liste der umzusetzenden User Stories wird Product Backlog genannt. Innerhalb des Product Backlog wird in Sprints abgearbeitet, die ein bis vier Wochen dauern können. Am Anfang des Sprints findet ein Sprint Planning statt, während des Sprints hält das Team täglich 15-minütige Daily Scrums ab. Am Ende des Sprints wird eine Review (Demonstration der im Sprint fertiggestellten User Stories), sowie eine Sprint Retrospektive, in der das Team die Zusammenarbeit und Vorgehensweisen analysiert und Verbesserungsvorschläge definiert, durchgeführt. Diese Meetings werden Scrum Events genannt. Scrum wurde ursprünglich für Teams von drei bis neun Entwicklern konzipiert. Größere Entwicklungsprojekte benötigen aber ein Rahmenwerk, welche die Koordination mehrerer Teams, die am selben Produkt arbeiten, optimiert. Große Projekte sind gekennzeichnet durch eine hohe Komplexität und Abhängigkeiten zwischen den parallel agierenden Entwicklungsteams. Dies führt zu Schnittstellenproblemen, sowie Verzögerungen und Produktivitätsverlusten. Daraufhin wurde 2015 Nexus von Scrum.org etabliert. Nexus beschäftigt sich mit effizienten Praktiken für die Zusammenarbeit mehrerer Scrum Teams. Es ist ein Rahmenwerk zur Entwicklung und Erhaltung von skalierten Produkt- und Softwareentwicklungsinitiativen. Der Begriff Nexus stammt aus dem Lateinischen und bedeutet Verbindung, Verknüpfung oder Zusammenhang. 2 Nexus Rahmenwerk Das Nexus Rahmenwerk beruht auf ursprünglichen Scrum Prinzipien und Werten, führt aber zusätzliche teamübergreifende Rollen, Artefakte und Events ein. Das Ziel des Frameworks ist es, mit mehreren parallel agierenden und zeitlich synchronisierten Scrum Teams ein gemeinsames integriertes Ergebnis zum Sprintende zu produzieren. Nexus wird in folgender Graphik mit allen Rollen, Events und Artefakten dargestellt: Nexus baut auf Scrum auf, übernimmt viele Elemente und führt zusätzlich weitere Elemente ein um die Integration von Scrum Teams erfolgreich zu gestalten Seite 3
Abbildung 1: Scrum.org; Nexus Rahmenwerk 1 2.1 Rollen Das Nexus Integration Team wird als neue Rolle eingeführt und übernimmt die Verantwortung für die Koordination, das Coaching und die Führung in der Anwendung von Nexus und Scrum. Das Nexus Integration Team besteht aus einem Product Owner, einem Scrum Master und Nexus Integration Teammitgliedern. Die Nexus Integration Teammitglieder können auch zu einzelnen Scrum Teams gehören, wobei die Arbeit für das Integrationsteam und das Beseitigen von Integrationsproblemen immer Vorrang hat. Da die Nexus Teams an einem Product Backlog arbeiten, gibt es auch nur einen Product Owner, der das letzte Wort bezüglich der Inhalte hat. Der Nexus Scrum Master kann in einem oder mehreren Scrum Teams innerhalb des Nexus tätig sein. Das Nexus Integration Team übernimmt die Verantwortung für die Koordination, das Coaching und die Führung in der Anwendung von Nexus und Scrum 2.2 Artefakte Alle Scrum Teams arbeiten am gleichen und einzigen Product Backlog. Beim Backlog Refinement Meeting werden die User Stories überarbeitet und für das Sprint Planning vorbereitet. Darauf folgt eine Visualisierung darüber, welche Items von welchen Teams innerhalb eines Sprints erledigt werden können um dabei Abhängigkeiten zwischen diesen Teams zu identifizieren. Ein neues Artefakt, das Nexus Sprint Backlog, wurde eingeführt, um während des Sprints die Transparenz über alle Zusammenhänge der User Stories zu erhöhen. Es beinhaltet alle Elemente aus allen Team Sprint Backlogs. Das integrierte Inkrement ist die Summe der gesamten integrierten Arbeit des Nexus Frameworks. Dieses Artefakt muss benutzbar und Release-fähig sein. 1 Scrum.org: Nexus Guide Seite 4
2.3 Events Nexus Events erweitern reguläre Scrum Events. Sie werden um sie herum gebaut oder ersetzen diese (im Falle des Sprint Reviews). In ihrer Modifikation dienen sie sowohl allen Scrum Teams im Nexus als auch jedem einzelnen Team. Das Nexus Sprint Planning ist ein teamübergreifendes Event mit dem Ziel, Abhängigkeiten und Voraussetzungen frühzeitig zu erkennen und die Umsetzung durch die Teams besser zu planen. Teilnehmer an allen Nexus Events ist das Integration Team, sowie geeignete Repräsentanten jedes Scrum Teams. Die einzelnen Team Sprint Plannings finden im Anschluss statt. Das Ergebnis des Nexus Sprint Plannings ist ein übergeordnetes Nexus Sprint Ziel, sowie eine Reihe von einzelnen Sprint Zielen für jedes Team. Beim Nexus Daily Scrum werden teamübergreifende Themen besprochen und potentielle Integrationsprobleme adressiert (z.b. wann und wie erfolgt das Zusammenführen von Inkrementen oder welche Änderungen wurden vorgenommen, die andere Teams und das Inkrement beeinflussen könnten). Das Nexus Review ersetzt einzelne Sprint Reviews, da das Nexus Ziel ein integriertes Inkrement ist, das dem Product Owner vorgestellt wird. Die Nexus Retrospektive dient der Optimierung der Zusammenarbeit aller Scrum Teams im Nexus. Einzelne Teams führen weiterhin eigene Retrospektiven durch, alle teamübergreifende Probleme und Lösungen werden jedoch mit dem Nexus Integration Team abgestimmt um eine ganzheitliche Optimierung zu sichern. Dazu gibt es Ergänzungen aus den Team Retrospektiven zur Nexus Retrospektive, sowie umgekehrt Feedback über neu vereinbarte Spielregeln für alle Teams. Nexus führt teamübergreifende Events ein: Nexus Sprint Planning, Nexus Daily Scrum und Nexus Review. 3 Umsetzung Vor der Einführung von Nexus sollten die Teams schon einfaches Scrum verstehen und leben. Durch Inspect and Adapt -Zyklen werden die teamübergreifenden Probleme und somit der Bedarf nach neuen Rollen und Events für alle Teams offensichtlich. Dadurch werden die bevorstehenden Veränderungen meist besser akzeptiert. Voraussetzung für die Nexus- Einführung ist vorherige solide Scrum Anwendung im gegebenen Umfeld. Das Nexus Framework kann zuerst mit einigen Teams pilotiert und dem spezifischen Umfeld angepasst werden. Alle Anpassungen können jeweils zu Sprintbeginn als Experiment eingeführt werden und bei der Nexus Retrospektive bewertet und ggf. angepasst werden. In größeren Organisationen sollte danach genügend Zeit für finale Abstimmung, Kommunikationsplanerstellung und Rollout eingeplant werden. Neben dem Product Owner und Scrum Master ist es wichtig Integrationsteammitglieder zu ernennen. Für diese Rolle sind Architekten am besten geeignet, da sie den besten Überblick über das ganze System haben. Es ist ebenfalls möglich Seite 5
erfahrenere Entwickler aus jedem Team auf Teilzeit mit ins Integrationsteam einzubeziehen, die mit detailliertem Wissen über Teilsysteme einen Beitrag leisten können. Der wichtigste Grundstein ist das gemeinsame Product Backlog, das von funktionsübergreifenden Teams bearbeitet werden sollte. Bei der Entwicklung komplexer Systeme gibt es oft stark spezialisierte Teams. Ein Austausch von Domänenwissen zwischen den Teams sollte helfen die Abhängigkeiten zu minimieren, die Arbeitsbelastung besser zu balancieren und insgesamt die Backlogabarbeitung zu beschleunigen. Die Häufigkeit, Dauer und Teilnehmer der Backlog Refinement Meetings basieren auf den vorhandenen Abhängigkeiten - je größer die Komplexität und die Abhängigkeiten sind, umso mehr müssen die Product Backlog Items überarbeitet werden. Häufig können Anforderungen überlappen und auch die Art und Weise, in der sie umgesetzt werden, kann sich gegenseitig beeinflussen. Die Product Backlog Items müssen zuerst soweit heruntergebrochen werden damit bestimmt werden kann, welche Teams sie umsetzen können. Danach ist es möglich Abhängigkeiten zwischen den Teams zu erkennen, diese team-, aber auch sprintübergreifend zu visualisieren und die Reihenfolge entsprechend anzupassen, dass Abhängigkeiten beseitigt oder zumindest minimiert werden. Während des Sprints integrieren alle Teams ihre Arbeit so oft wie möglich in eine gemeinsame Umgebung um sicherzustellen, dass die Integration erfolgreich durchgeführt werden kann. Falls es zu Integrationsproblemen kommt, werden diese in den Nexus Daily Scrums besprochen und eine Problemlösung definiert. Der erarbeitete Plan wird zum Input für einzelne Team Daily Scrums. Am Ende des Sprints wird das integrierte Inkrement demonstriert. Da es um das komplette und insofern ein großes Inkrement geht, können meistens nicht alle Details inspiziert werden. In diesem Fall können zusätzliche (Zwischen-)Reviews vereinbart werden, vor allem, wenn für bestimmte Product Backlog Items ein detailliertes Feedback vom Product Owner essentiell ist. 4 Fazit Das Nexus Framework ist ein Skalierungs-Framework das einfach anwendbar zu sein scheint - alle Prinzipien und Regeln sollen Kommunikation und Zusammenarbeit zwischen den Teams verstärken, mit dem Ziel erfolgreicher Integration und der kontinuierlichen Verbesserung des ganzen Teams. Es ist jedoch kein detailliertes Rezept für agile Skalierung. Es ist wichtig, Nexus Scaled Scrum an das Umfeld in welchem es angewandt wird, anzupassen. Deswegen ist es umso wichtiger, dass die Scrum Werte richtig verstanden und umgesetzt werden. Das Team des Nexus Scrum Masters muss stark unterstützt werden. Seite 6
5 Ansprechpartner Jasmina Muhic Senior Project Manager Braincourt GmbH Fasanenweg 11 70771 Leinfelden-Echterdingen jasmina.muhic@braincourt.com Telefon: +49 711 75 85 80 0 6 Literaturverzeichnis Bezeichnung 1 Autor, Buchtitel, Verlagsangaben Schwaber, Ken & Scrum.org (2015); Scrum.org: Nexus Guide Version 1.1 www.scrum.org Seite 7