Scaled Agile Frameworks- Teil 3 NEXUS- ein Agiles Exoskelett

Zwischen der Entstehung des Agilen Manifests 2001 und heute hat das Thema Agilität nichts an Aktualität eingebüßt. Ja, sogar noch zugenommen. Nach wie vor wird an dem Problem der Umsetzung dieses Manifests gearbeitet. Im Besonderen, wie ein agiles Konzept in einem größeren Maßstab verwirklicht werden kann. Bereits in der Frühphase 2001 stellte Jeff Sutherland mit Scrum of Scrums eine Möglichkeit vor, agile Prozesse zu skalieren.  Bis heute wurde eine Vielzahl an Frameworks erdacht. Grund genug in dieser kleinen Blogserie die wichtigsten Vertreter der Scaled-Agile-Frameworks-Welt vorzustellen. Nach einem kurzen Überblick der gängigsten Frameworks widmen wir uns nun im zweiten Teil ganz und gar der bereits erwähnten elementarsten Idee Agilität zu skalierendem Scrum of Scrum Meeting. 

NEXUS- ein Agiles Exoskelett

Der Leitfaden für Nexus ist ein 15 seitiges Dokument, zieht man Deckblatt, Inhaltsverzeichnis und das Kapitel, das die Änderungen über die Zeit dokumentiert, ab bleiben noch 11 Seiten übrig. Auf das wesentliche beschränkt beschreibt Ken Schwaber ein Exoskelett für seines agilen Vorgehensmodells.

Nexus hat zwei Schwerpunkte: Zum einen die häufige Integration der Inkremente und zum zweiten Identifizierung und Minimierung der Abhängigkeiten zwischen den interdisziplinären selbstorganisierten Entwicklung Teams. Die Probleme der Integration versucht Schwaber durch die Einrichtung des Nexus Integration Teams, kurz auch NIT genannt, zu lösen. Dieses Team hat die Aufgabe die Integrierbarkeit der Inkremente zu gewährleisten, das heißt es beschäftigt sich in erster Linie mit Integrationsproblemen und versucht diese so früh wie möglich in Angriff zu nehmen und z. B. mit Hilfe von Richtlinien aufzulösen.  Das NIT setzt sich aus dem Product Owner, einem Scrum Master und Experten für die Architektur des Systems zusammen. Der Kader an Expertenmuss nicht fix festgelegt werden, so dass der Scrum Master und die Experten durch aus auch Mitglieder eines Entwicklungsteams sein kann. Eine wechselnde Besetzung des NIT, um stets den Herausforderungen ist möglich.  Jedoch gilt, dass die Arbeit im NIT Priorität hat. Die Haupttätigkeit des NIT ist, die Entwicklungsteams hinsichtlich der geltenden Entwicklungsrichtlinien zu coachen und zu unterstützen.

Ein Nexus arbeitet an einem einzigen Product Backlog. Wie im Scrum Guide beschrieben, verfügt ein Product Backlog über einen einzigen Product Owner, der das letzte Wort bezüglich seines Inhaltes hat. Dieser ist wie bereits erwähnt Mitgliedim NIT ist. Die Items werden im Refinement zuerst auf Hinsicht der Abhängigkeiten geschnitten werden und dann in den Teams solange verfeinert werden bis sie den Status „Ready“ erlangen und dann in einem allgemeinen Nexus Sprint Planning an die Teams so verteilt werden, dass möglichst geringe Abhängigkeiten zwischen den Teams entstehen. In einem zweiten Team internen Sprint Planning plant danach jedes Team ihr individuelles Vorgehen. Im Gegensatz zu Scrum ist das Refinement in diesem Vorgehen offizieller Bestandteil.

Alle an Teams verteilten Items werden zusätzlich in einem  Nexus Sprint Backlog geführt in dem die im den Plannings nicht auflösbaren Abhängigkeiten visualisiert und dokumentiert werden.   Zur Koordination verwendet Nexus die klassischen Scrum Events, es wird täglich ein Daily auf Nexus Ebene durch Repräsentanten jedes Ebenenteams und des NITs durchgeführt, so wie ein Dailys auf Teamebene. Review finden stehst auf Nexus Ebene mit allen Teams statt, um das integrierte Inkrement zu überprüfen

Nachdem wir die Frameworks der beiden SCRUM Erfinder nun grob vorgestellt haben. Widmen wir uns im nächsten Blogbeitrag dem Framework, das als natürlichste Skalierung von SCRUM gilt LeSS, Large Scaled Scrum von  Bas Vodde und Craig Lairman.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


sechs + = 12