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. Im vierten Teil stellen wir nun Large Scaled Scrum von Bas Vodde und Craig Lairman vor.
More with LeSS.
„More with LeSS“ – Dieses Oxymoron haben sich Bas Vodde und Craig Lairman mit ihrer Variante eines Scaled Agile Framework auf die Fahnen geschrieben. „Large Scale Scrum“ verspricht durch Verringerung von Komplexität sowohl Produktivität, als auch das Verantwortungsgefühl für Arbeitsergebnisse und Zusammenarbeit zu steigern. Gerade dieses Gefühl kann durch komplizierte Prozesse und lange Ketten von Verantwortlichen verloren gehen und als hoher Synchronisationsbedarf und Integrationsschwierigkeiten zurückkehren. Um genau dem entgegenzuwirken, orientiert sich die Organisation des Large Scale Scrum am ursprünglichen Scrum und versucht weiterhin die Prinzipien der unkomplizierten Zusammenarbeit eines kleinen, kundennahen Entwicklungsteams auf mittlere und große Organisationseinheiten zu übertragen. Dabei soll sich jedes Element für den erfahrenen Scrum-Anwender vertraut anfühlen. Deshalb finden sich, wie es im klassischen Scrum auch der Fall ist, ein zentrales Artefakt der Zusammenarbeit, das sogenannte Product Backlog: Eine vom Product Owner (PO) verwaltete Liste von Items, die anhand der Kundenwünsche befüllt wird. LeSS baut auf eine starke Produkt-Orientierung auf. Deshalb beschränkt sich das Framework auf einen einzigen Product Backlog und nur ein PO, dessen Hauptaufgabe es ist, die Items des Backlogs zu priorisieren und die Verbindung nach außen zu den Kunden sicherzustellen.
Am Anfang jeder Iteration steht das „Sprint Planing 1“, in dem jedes Team Items der höchsten Priorität aus dem Product Backlog wählt, die es im kommenden Sprint bearbeiten will, sodass die am höchsten priorisierten Items sich gleichmäßig auf die Teams verteilen. Im nachfolgenden „Sprint Planning 2“ stimmt sich jedes Team über ein gemeinsames Vorgehen für die Bearbeitung der gewählten Features ab und startet anschließend in den Sprint. Über diesen hinweg stimmen sich die Mitglieder der einzelnen Teams selbstorganisiert und eigenverantwortlich mit den Mitgliedern der anderen Teams zur Integration der Bestandteile des Sprint-Inkrements ab. Hierbei sieht LeSS keine designierten „Koordinatoren“ vor, sondern legt die Verantwortung zur Integration in die Hände der Teams. Über eine kontinuierliche Integration während des Sprints wird die Integration selbst zu einem Artefakt der Koordination und Kommunikation zwischen den Teams. Abhängig von den Dependancy der Sprint Backlogs können Teams einen Sprint auch gemeinsam durchführen. In diesem Fall findet das „Sprint Planning 2“ Team übergreifend statt. In den Daily Scrums der einzelnen Teams nehmen Representanten der anderen Teams, sogenannte Scouts, teil, um ihre Kollegen über die Entwicklungen während des Sprints auf den Laufenden zu halten.
Während der Sprints finden Refinement Meetings statt. Das Product Backlog Refinement (PBR) wird in unterschiedlichen Modi durchgeführt. Wichtig ist dabei der direkte Kontakt zu den Stakeholdern. Es gibt Overall PBRs an denen Repräsentanten aller Teams teilnehmen oder teaminterne PBRs, in der Regel mit nur einem Team. Stakeholder sind dabei möglichst direkt vertreten oder werden durch Product Owner vertreten.
Die natürliche Grenze zwischen LeSS und LeSS Hudge ist die Größe des Backlogs. Sobald ein Backlog nicht mehr von einem PO verwaltet werden kann wird es Zeit das Vorgehen an zu passen. LeSS sieht diese Grenze bei ungefähr 8 Teams erreicht. Sobald also diese magische Zahl erreicht wurde, schaltet LeSS Hudge eine Requirements Area (RA) zwischen dem Product Backlog und den Teams. Eine RA stellt eine Sammlung von Anforderungen dar, die einem bestimmten Teil des Produkts aus Kundensicht entspricht. Aus diesen RA werden Area Product Backlogs gebildet, die von einem Area Product Owner (APO) verwaltet werden. Der PO zusammen mit den APOs bilden das Product Owner Team. Somit funktioniert jede RA wie das normale LeSS Framework mit dem Unterschied, dass die Teams auf einem spezielleren Gebiet unterwegs sind und ihre APOs ein bisschen stärker eingeschränkt in ihren Produktkompetenzen sind.
Nun, nachdem Sie eine grobe Vorstellung von LeSS haben, können Sie sich auf den Abschluss unserer Blogserie freuen: SAFe, das versucht Agilität selbst noch auf Konzerngröße zu skalieren.