Sehr zum Leidwesen meiner Frau bin ich kein guter Heimwerker. Trotzdem faszinieren mich Werkzeuge. Hübsch aufgereiht in unglaublicher Vielfalt preisen sie ihre unbestreitbare Nützlichkeit im Baumarkt an. Und gelegentlich verleiten sie mich zum Kauf für den Fall, dass ich irgendwann Verwendung dafür hätte. Dieser Fall tritt freilich nie ein oder oder wenn er eintritt, habe ich das Werkzeug längst vergessen (meine Frau behauptet zwar auch, das ließe sich durch Ordnung im Werkzeugkeller vermeiden, aber das ist eine andere Geschichte).
So ähnlich verhält es sich mit der Vielfalt an agilen Frameworks wie das Scaled Agile Framework (SAFe), LeSS, Nexus oder das Spotify-Modell. Die gibt es zwar nicht im Baumarkt, aber jede Beratungsfirma hat derlei im Angebot. Und auch hier werden Kunden zum Kauf eines Modells und den darin enthaltenen Werkzeugen und Praktiken verleitet. Nicht selten ist das dann allerdings eher ein vorsorglicher und theoretisch motivierter Kauf so wie bei mir im Baumarkt. Man hat nicht wirklich alle Probleme verstanden, für die diese Modelle Lösungen bereithalten, aber sie sehen sehr praktisch und nützlich aus.
Alle diese Frameworks enthalten gute Lösungen, die aber zu den Problemen der Organisation passen müssen. Diese Probleme müssen aber zuallererst verstanden und im praktischen Alltag vorhanden sein. Darum plädiere ich stets dafür die agile Transformation groß zu denken, klein zu starten und auf dem Weg schnell zu lernen. Wer klein startet, beispielsweise mit einem oder zwei Scrum-Teams, und dann die Aktivitäten nach und nach ausweitet kommt unweigerlich an diesen Problemen vorbei und versteht dann auch die Lösungen, welche die verschiedenen Frameworks dafür bereithalten.
Zuerst tritt auf dieser Reise typischerweise das Problem auf, wie die Arbeit mehrerer Teams an einem gemeinsamen Produkt koordiniert werden kann. Die naheliegende und sehr klassische Lösung ist es, hierarchisch das Produkt in Komponenten zu zerlegen, an denen dann ein dediziertes Team arbeitet. Die Koordination erfolgt dann meist durch den Product-Owner, der dafür sorgen muss, dass je Sprint ein stimmiges Ganzes entsteht. In diesem Ansatz wird der Product-Owner schnell zum Engpass und seine eigentlich Arbeit an der Zukunft des Produkts und mit den Stakeholdern wird teilweise verdrängt durch die Arbeit der Koordination dieser Komponententeams.
Ähnlich schwer wiegt das Problem, dass diese Teams global gesehen aus Gründen der Auslastung nicht immer an den für das Produkt wichtigsten Dingen arbeiten. Die Arbeit wird nur selten gleichmäßig über alle Komponenten des Produkts verteilt sein und daher wird das Team für beispielsweise die Komponente der Nutzerverwaltung an Dingen arbeiten, die eigentlich im Moment, global betrachtet, keine Priorität haben, weil der Fokus auf der Überarbeitung des Shops liegt. Dabei kann das Team für die Nutzerverwaltung aber leider nicht helfen, weil es eine andere Komponente ist.
Diese Probleme lösen dann Featureteams, deren Wirkungsbereich sich eben nicht auf eine Komponente des Produkts beschränkt, sondern die vielmehr in der Lage sind, eine Anpassung, ein Feature, über alle Komponenten hinweg Ende-zu-Ende umzusetzen. Auch diese Teams müssen sich koordinieren, aber dafür reicht in der Regel ein gemeinsames Sprint-Planning und ein regelmäßiges Scrum of Scrums während des Sprints. Dieses Modell erfordert allerdings eine höhere Reife der Teams, die natürlich mehr über das gesamte Produkt wissen müssen, um darin Anpassung vornehmen zu können. Das höhere Maß an Ownership, nämlich in Bezug auf das ganze Produkt und nicht nur zu einer Komponente, führt zu einem höheren Grad der Selbstorganisation und entlastet den Product-Owner von koordinativen Aufgaben.
Es kommt also bereits bei dieser elementaren Form der Skalierung, mehrere Teams an einem Produkt, ganz wesentlich darauf an, wie die Arbeit aufgeteilt wird. Wer hier die vertraute Aufteilung in Komponenten wählt und dazu in der Methodenkiste von SAFe ein „Program Increment Planning“ (PI-Planning) findet, löst zwar vordergründig das Problem der Verwaltung von Abhängigkeiten, packt es aber eben nicht an Wurzel an.
Wenn nun nicht nur ein Produkt, sondern mehrere Produkte in einem Portfolio in ihrer jeweiligen Weise agil arbeiten stellt sich abermals die Frage nach Koordination und gemeinsamer Ausrichtung, nun allerdings auf höherer, strategischer Ebene. Hier könnten dann beispielsweise Objectives and Key-Results zum Einsatz kommen, um einerseits den Produkten eine gemeinsame strategische Ausrichtung zu geben ohne sie andererseits zu sehr in ihrer Autonomie zu beschränken. Auch in SAFe finden sich hierzu Antworten auf der Portfolio-Ebene (und auch in Form des PI-Plannings) und in gewisser Weise sind die Tribes im Spotify-Modell auch eine Lösung für dieses Problem. Viele Wege führen nach Rom. Entscheidend ist aber, dass nach der Lösung ausgehend von einem praktisch auftretenden Problem gesucht wird und nicht vorsorglich oder aus theoretischer Faszination für die Methodik auf bunten Folien.
Wenn schließlich viele Teams agil arbeiten über mehrere Produkte hinweg, drängt die Frage nach gemeinsamen Standards beispielsweise für den Betrieb der Produkte, für die Architektur, für Continuous Integration / Continuous Deployment oder für Security, um nur die naheliegenden zu nennen. Die primäre Organisationsstruktur orientiert sich richtigerweise an den Produkten, denn die Mitarbeiter sollen sich primär ihrem Produkt und der Wertschöpfung beim Kunden zugehörig fühlen (idealerweise in einem Featureteam, weil sie sich sonst primär der Komponente zugehörig fühlen). Spezialistensilos in der Organisation für diese querschnittlichen Aspekte sind also in diesem Sinne keine gute Lösung. Hier kommen nun quer zur primären Produktorganisation Communities of Practice, Chapters oder Gilden je nach bevorzugtem Framework ins Spiel. Ihre Aufgabe ist immer dieselbe: Eine gemeinsame Expertise (IT-Betrieb, Security, Architektur, etc.) auszubauen, zu professionalisieren und auch zu standardisieren.
Diese Liste von typischen Problemen und die angebotenen Lösungen in agilen Frameworks ließe sich noch länger fortsetzen. Es geht mir aber gar nicht darum, das Thema erschöpfend zu behandeln oder gar eine Art Meta-Modell der agilen Frameworks zu erstellen. Alle Frameworks enthalten gute Lösungen. So wie es eben im Baumarkt gute Werkzeuge gibt. Um diese erfolgreich anwenden zu können, muss man aber das richtige Problem haben und dieses Problem richtig verstanden haben. Zudem haben alle Lösungen auch Neben- und Wechselwirkungen und manchmal brauchen diese Lösungen auch bestimmte Voraussetzungen zur erfolgreichen Anwendung.
It is no longer sufficient to have one person learning for the organization, a Ford or a Sloan or a Watson or a Gates. […] The organizations that will truly excel in the future will be the organizations that discover how to tap people’s […] capacity to learn at all levels in an organization.
Peter Senge, The Fifth Discipline
Die fixe Idee, einfach ein erprobtes Modell auszuwählen und auszurollen wird daher nicht mit Erfolg gekrönt sein, sondern hat das Potential, das gewählte agile Framework und das Konzept von Agilität im Allgemeinen zu verbrennen. Sinnvoller erscheint es mir, sich nach und nach, gleichsam vom Kleinen ins Große, gemeinsam das Problemverständnis zu erarbeiten und davon ausgehend Lösungen zu finden – in den bekannten Frameworks und darüberhinaus. Entscheidend dafür ist eine angstfreie Lernkultur und die aus dem Lean Management stammende fundamentale agile Praktik der kontinuierlichen Verbesserung, beispielsweise in Form von Retrospektiven in Scrum. Das ist das tragfähige Fundament einer lebendigen agilen Organisation. Es ist gar nicht nötig, mit dem besten Framework zu starten; ein guter Anfang reicht völlig, solange auf dem Weg konsequent gemeinsam gelernt wird.
Photo by Natalino D’Amato on Unsplash
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
