Scaled Agile Frameworks- Teil 5 Scrum@Scale – Das modulare Framework

Zwischen der Entstehung des Manifests für agile Softwareentwicklung 2001 und heute hat das Thema Agilität kaum an Aktualität verloren. Nach wie vor wird an dem Problem der Umsetzung des Manifests gearbeitet. Vor allem 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 [Sutherland, Jeff; „Agile Can Scale Inventing and ReinventingSCRUM in Five Companies, in: Cutter IT Journal, Hrsg; Karen Fine Coburn, Ausgabe 14, Nr. 12, 2001.] eine Möglichkeit vor, Prozesse für agile Softwareentwicklung 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. In diesem Teil stellen wir nun Jeff Sutherlands Framework Scrum@Scale vor.

Scrum@Scale – Das modulare Framework

Jeff Sutherland versucht in seinem Framework eine agil arbeitende Organisation als ein komplexes, adaptives System, das heißt als selbstähnliches Kollektiv von interagierenden adaptiven Akteuren, zu designen. Das Framework will durch die Adaption der komplexen, adaptiven Systemtheorie aus der Biologie eine frei skalierbare Unternehmensarchitektur schaffen, in dem ein mit Hilfe des Frameworks konzipiertes Organisationselement als neuer Knotenpunkt eingesetzte werden kann. Das ermöglicht es untergeordnete Elemente unter ein übergeordnetes Element einzugliedern. Auf diese Weise lässt sich eine Organisation nach dem selben Schema beliebig erweitern.

Stark vereinfacht bedeutet das, dass 4 bis 5 Scrum Teams eine Scrum of Scrum Einheit (SoS) bilden. Die Koordination der Teams wird über eine teamübergreifende Version der Scrum Events (Daily und Retro) auf SoS-Ebene gewährleistet. Die Teams eines SoS in ihrer Gesamtheit sollten dabei fähig sein ein valides, auslieferbares Inkrement zu entwickeln. Die Product Owner (PO) der Teams in Zusammenarbeit mit einem Chief Product Owner (CPO) bilden dabei ein paralleles, nach Scrum arbeitendes Team, das die Backlogs synchronisiert und eine konsistente Produktvision sicherstellt. So bilden sich zwei ineinandergreifende Arbeitskreisläufe. Das SoS arbeitet an der Umsetzung der Entwicklung und im Scrum Master Cycle an der eigenen Produktivität. Dies geschieht auf Teamebene mit Hilfe ihres Scrum Masters auf klassischer Scrumbasis und auf SoS-Ebene in den teamübergreifenden Events. Der Product Owner Cycle ist mit der Arbeit an der Produktvision und dem Befüllen, Ausarbeiten und Priorisieren des Backlogs betraut. Hier arbeitet das Team mit dem Product Owner ihres Teams zusammen an einem gemeinsamen Verständnis des Produkts. Während, diese gleichzeitig in ihrem PO-Team unter der Leitung des CPOs. (Abb.1), sicherstellen, dass die einzelnen Teams in dieselbe Richtung arbeiten.

Will man das Prinzip weiter skalieren, werden wieder 4 bis 5 SoS Einheiten zu einem SoSoS mit einem eigenen Scrum Master Cycle und einem eigenen Product Owner Cycle mit einem Chief Chief PO zusammengefasst, die zusammen wieder das bekannte Set an skalierten Scrum Events durchführen. Um eine gemeinsame Entwicklungsrichtung zu gewährleisten, fügt das Framework zwei Leadership Teams ein: Das sogenannte Executive Action Team (EAT), um die Aufgaben eines Scrums Masters für die gesamte Organisation zu übernehmen. Sowie das Executive Meta Scrum Team (EMS), das ein organisationsweites Backlog pflegt, dessen Items die Organisationsentwicklung und strategische Belange koordinieren. Dieses Team hat also nur indirekt eine Auswirkung auf die Produktentwicklung und entwickelt die Organisation als Ganzes weiter. Zusammen gestalten die beiden Teams ein agiles Referenzmodell aus, das auch auf der Leadership-Ebene vorbildhaft gelebt werden muss. Das heißt, dass auch die Leadership Teams nach dem Scrum Guide und ihren eigenen Vorgaben arbeiten.

Auf diese Weise ergibt sich eine an organische Moleküle erinnernde Organisationsstruktur (Abb.2). Diese bildet sich um die beiden Leadership Teams herum, die gemeinsam an der Abarbeitung der Aufgaben im organisationsweiten Backlog arbeiten. Dabei wird gleichzeitig, im Sinne des Scrum Guides und des Referenzmodell der Leadershipebene, an einer methodischen Verbesserung gearbeitet. Nun nachdem sie auch eine grobe Vorstellung von Scrum@Scale haben, können sie sich auf den Abschluss unserer Blog Serie freuen, mit SAFe, das versucht Agilität auf durch einen detaillierten Prozess auf Konzerngröße zu skalieren.

Schreibe einen Kommentar Antworten abbrechen

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