Nach dem kurzen Ausflug in die agilen Methoden im Projektmanagement wenden wir uns nun wieder den agilen Methoden in der Softwareentwicklung zu. Das typische Beispiel für die Anwendung von SCRUM ist ein Onlineshop: man erstellt eine Website, die man Sprint für Sprint erweitert. Im Kleinen funktioniert dies sehr gut und hat sich als effiziente, erfolgreiche Methode weltweit etabliert. Stellen wir uns aber nun ein großes Versandhandelsunternehmen vor, das von Grund auf einen neuen Online Shop entwickelt möchte. Dazu braucht es Frontend Server, Backend Server, Graphical User Interface Design, Schnittstellen zu Warehouse Systemen, die Kopplung zu verschiedensten Bezahl-Systemen, ein komplexes User Management und weitere Verbindungen zu zahlreichen anderen internen Tools. Häufig wird im Webshop ein Recommender System verbaut, das einem Kunden weitere Produkte anzeigt, die andere Kunden auch gekauft haben. Ein einzelnes SCRUM Team kann dies nicht bewältigen, auch kein erfahrenes. Aus diesem Grund haben sich verschiedene Ansätze zum Skalieren der agilen Methoden gebildet, die bereits in vielen großen Unternehmen eingesetzt werden.

Aus klein mach groß

Ein SCRUM Team hat typischerweise einen Scrum Master, einen Product Owner und einige Entwickler, überschreitet aber selten die Anzahl von 9 Teammitgliedern. Das Framework ist darauf ausgelegt, dass das gesamte Team am selben Standort arbeitet, noch besser aber im selben Büro sitzt. In der heutigen Zeit ist dies für größere Entwicklungsvorhaben, wie beispielsweise der oben erwähnte Online Shop, aber kaum noch möglich. Solche großen Softwareprojekte können aus vielen einzelnen Teams bestehen, die möglicherweise auf verschiedene Kontinente verteilt sind, aber alle am selben Produkt arbeiten. Die Herausforderung ist dabei, dass alle Teams auf dieselbe Vision hinarbeiten, Abhängigkeiten zwischen Teams erkannt und in die Planung mit einbezogen werden. Um auch große Projekte auf agile Weise zu bewerkstelligen, wurden Frameworks entwickelt, die diese Probleme lösen. Bekannte Beispiele für die sogenannten „Scaling Agile Frameworks“ sind das Spotify Modell, SAFe, Large Scale Scrum, oder Nexus. Diese Frameworks nehmen die Prinzipien und Werte der agilen Arbeitswelt und skalieren sie auf verschiedenste Art.

LeSS is More – Large Scale Scrum

Um zu verstehen, wie Scaling Agile funktioniert, schauen wir uns einmal Large Scale Scrum, kurz LeSS, etwas genauer an. Im LeSS gibt es, wie auch in SCRUM, genau einen Product Owner, einen Product Backlog und ein Potentially Shippable Product Increment. Nun gibt es aber nicht nur ein Entwicklungsteam, sondern sehr viele Teams, von denen jedes Team einen eigenen Scrum Master hat. All diese Teams arbeiten immer im selben Sprint-Zyklus, nicht versetzt.

Ein Sprint beginnt mit dem „Sprint Planning 1“, in dem der Product Owner mit allen Scrum Mastern (und ggf. einzelnen Teammitgliedern) zusammenkommt. Dort werden die Backlog Items auf die Teams aufgeteilt. In einem zweiten Sprint Planning, führt jedes agile Team für sich selbst die Planung wie im gewöhnlichen SCRUM durch. Es können aber auch einige Teams ein gemeinsames Planning durchführen, wenn deren Backlog Items eng zusammenhängen. Am Ende eines Sprints gibt es sowohl eine Retrospektive auf Team-Level als auch eine gemeinsame mit allen Teams. In einer gemeinsamen Sprint Review wird der Sprint schlussendlich abgeschlossen.

Dieser Prozess ist auch in der Grafik nochmal übersichtlich dargestellt. Durch einen einzelnen Product Owner und einen Product Backlog wird sichergestellt, dass am Ende ein in sich funktionierendes Produkt entsteht. Regelmäßige gemeinsame Events sorgen dafür, dass die Teams im kontinuierlichen Austausch miteinander stehen. Durch Continuous Integration gibt es jederzeit ein auslieferbares Produkt und der Kunde kann stets Feedback zur Verbesserung geben. Obwohl viele an der Entwicklung beteiligt sind, kann schnell und ohne großen Änderungsprozess auf den Kunden reagiert werden. Die Kernelemente der agilen Arbeitsweise werden entsprechend eingehalten, sowohl bei 9 Entwicklern als auch bei 90.

Large Scale Scrum (LeSS) für komplexe Projekte (Abbildung gemäß The LeSS Company B.V.)

Scaling Agile in der Praxis

Skalierte agile Methoden werden auch in der Praxis immer wichtiger. Laut des 13. Jährlichen State of Agile Report verwenden 30% der Befragten das SAFe Framework und nicht SCRUM. Mittlerweile werden aber nicht mehr nur Teams auf agile umgestellt, sondern gleich das ganze IT-Department. Ein bekanntes Beispiel dafür ist BMW, bei dem agile Methoden auf die gesamte IT-Organisation angewendet werden. Ziel ist es, Hierarchien abzuflachen und „Verantwortlichkeiten zu dezentralisieren“, indem Prozesse verändert und Silos aufgebrochen werden. Aber auch die Bahn-Tochter DB Systel hat sich einer Transformation hin zur Agilität unterzogen, hat eigene Rollen wie den Agility Master definiert und strebt das selbstorganisierte Arbeiten von ca. 500 Teams an. Als letztes Beispiel ist in dieser Stelle DATEV zu nennen, wo großen Wert auf den Austausch zwischen den Mitarbeitern gelegt wird. Das Lernen voneinander und das Weiterentwickeln jedes Mitarbeiters wird an erster Stelle gesehen. All diese Unternehmen haben bei ihrer Transformation mit Agilen Coaches zusammengearbeitet, die nicht nur auf prozessualer, sondern auch auf emotionaler Ebene arbeiten. Agile Coaches helfen den Mitarbeitern beim Verändern ihres Mindsets, trainieren Agilität und agile Methodiken und etablieren im Unternehmen eine Kultur des Lernens. Nicht umsonst ist der erste Punkt im Agile Manifesto „Individuals and Interactions over Processes and Tools“.

Fazit

Nicht immer ist SCRUM für ein Entwicklungsvorhaben geeignet. Große Projekte lassen sich nur mit sogenannten Scaling Agile Frameworks realisieren. Diese Frameworks sind ausgelegt auf hunderte von Teams und tausende von Projektmitarbeitern. Mit Hilfe dieser Frameworks lassen sich aber auch ganze Organisationen nach agilen Prinzipien und Werten neu strukturieren. Scaling Agile ist in der Praxis bereits weit verbreitet und wird von immer mehr Unternehmen adaptiert. Aber gerade durch die große Anzahl an Beteiligten ist der menschliche Faktor auf keinen Fall zu vergessen.