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 Entwicklungsteams. 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 Integration 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 Experten muss nicht fix festgelegt werden, so dass der Scrum Master und die Experten durchaus auch Mitglieder eines Entwicklungsteams sein kann. Eine wechselnde Besetzung des NIT 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 Mitglied im NIT. Die Items werden im Refinement zuerst auf Hinsicht der Abhängigkeiten geschnitten  und dann in den Teams solange verfeinert, bis sie den Status „Ready“ erlangen. In einem allgemeinen Nexus Sprint Planning werden sie an die Teams so verteilt, dass möglichst geringe Abhängigkeiten zwischen den Teams entstehen. In einem zweiten teaminternen 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 Daily 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 Antworten abbrechen

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