Mein aktuelles Buchprojekt We Run on Agile basiert in großen Teilen auf dem Expertenwissen, den Ratschlägen und den Praxiserfahrungen von Kollegen "aus der Szene", die mir in unseren Gesprächen wertvollen Input liefern. So habe ich mich bereits mit Dr. Thorsten Janning, Michael Frey, Marcus Raitner und Sylvius Gerber unterhalten.
Einen weiteren erfahrenen Ansprechpartner in Sachen Scaled Agile habe ich in Burkhard Schmidt gefunden, seines Zeichens Coach für die Einführung skalierter agiler Methoden (SPC), SAFe-Lean-Portfoliomanager, Lean-Agile-Trainer und Gründer der bschmidt.com consulting GmbH.
Das vollständige Interview finden Sie in unserer Infothek. An dieser Stelle will ich einige wichtige Aspekte zusammenfassen.
Die strategischen Ziele, die hinter der Entwicklung stehen
In seiner Laufbahn hat Burkhard vor allem mit Konzernen zusammengearbeitet und dabei unterschiedliche Skalierungsansätze ausprobiert. Wann begeben sich Organisationen seiner Erfahrung nach auf die Suche nach Lösungen zur Erweiterung agiler Entwicklungsmethoden? Und welche Wirkung kann das Scaled Agile Framework dabei entfalten?
Viele große Unternehmen seien klassisch in Silos und relativ abgeschottete Organisationseinheiten strukturiert, sagt Burkhard. Und hier suchten Führungskräfte oder Projektmanager irgendwann nach Möglichkeiten, Projekte über solche Silos hinweg gut zu strukturieren und umzusetzen.
Dabei sei das SAFe-Framework der Unternehmensrealität nahe gekommen, "weil es einerseits durch die skalierten Strukturen so ein bisschen die Konzern-Strukturen aufnimmt." Aber bei SAFe ginge es andererseits nicht allein darum, Projekte im Rahmen einer Lieferkette durchzuführen und auszuliefern,
"[...] sondern auch darum, zu überlegen, was das unternehmerische strategische Ziel dahinter ist. [...] In Konzernen ist man da oft so ein bisschen abgekoppelt, und SAFe ist eine Methode, um auch aus unternehmerischer Sicht mal wirklich reales Feedback zu bekommen."
Dabei sei das PI-Planning der Markenkern von SAFe. Hier gehe – im Gegensatz zu anderen Skalierungsmodellen – kein Release-Manager durch die Teams, um einzusammeln, was fertig ist, und zu sehen, wo Abhängigkeiten bestehen. Stattdessen würde die Zielsetzung schon zu Beginn klargestellt:
"Am Anfang einer Iteration überlegen wir uns, was wir erreichen wollen und wo unsere Abhängigkeiten mit den Teams sind. Dadurch schaffen wir ein Alignment, und das erleichtert es dann auch dem Release Train Engineer, die Teams viel leichter auf der Linie zu halten und Risiken, Abhängigkeiten und Impediments besser zu managen, als wenn er von den einzelnen Teams immer nur etwas zugeworfen bekommt."
Skalierung als Bottom-up- oder Top-down-Ansatz
Auf meine Nachfrage zu den grundsätzlichen Unterschieden zwischen den Frameworks LeSS und SAFe, hebt Burkhard hervor, von wo die Skalierung ausgeht. LeSS sei eher ein Bottom-up-Ansatz, bei dem die Skalierung von unten nach oben relativ organisch erfolge: Ein agiles Team entwickelt ein wachsendes Produkt, mit dem Wachstum des Produkts werden mehr autonome Teams involviert, und daraus entstünde irgendwann der Wunsch nach einem gemeinschaftlichen Produktmanagement oder einer gemeinschaftlichen Abstimmung.
Dagegen folge SAFe eher einem Top-down-Ansatz:
"Wir haben hier eine Unternehmensstrategie. Da wollen wir hin, das ist unsere Vision. Hier haben wir unsere Value-Streams, das sind unsere Large Solutions, unsere Release Trains, und ihr als Team seid verantwortlich, als Puzzlestück das und das zu liefern. Weil wir damit Geld verdienen wollen. Und ihr seid auch dafür verantwortlich zu überlegen, was man noch additiv gewinnen kann [...]. Denn ihr kennt das Produkt am besten. Und ihr kennt vielleicht auch den Kunden am besten."
In einem großen Unternehmen oder Konzern sei dieser Blickwinkel oft sinnvoll, findet Burkhard, denn der Ansatz erleichtere es, die Akzeptanz quer durch alle Bereiche, aber insbesondere auch auf der mittleren Management-Ebene zu steigern und Angst vor Veränderung abzubauen.
Es gäbe gewiss zu jedem Framework Pros und Contras, doch das SAFe-Modell habe den Vorteil, dass es Unternehmen in die Lage versetzt, erstens ihre Liefer- und Wertschöpfungsketten zu verifizieren und zweitens gut und schnell Software zu entwickeln, für die die Kunden bereit sind, Geld zu zahlen.
Herausforderungen bei der Agile-Skalierung
Die skalierte agile Software-Entwicklung ist jedoch auch mit Herausforderungen verbunden, wie Burkhard aus seiner Erfahrung schildert. Eine Hürde könne hier schon durch die Infrastruktur entstehen. Die Teams würden einfach nicht wirklich agil arbeiten können, wenn zum Beispiel keine geeignete Testumgebung gegeben sei, um Änderungen kontinuierlich zu deployen:
"Das heißt, die haben oft gar keine Chance, außer zu ihrem klassischen Release-Termin alle drei Monate ihr Zeug zusammenzuschieben und dann auf einer Umgebung zu testen. Dann arbeite ich aber nicht agil, dann brauche die gar nicht zu motivieren."
Auf der Management-Ebene sei das Hauptproblem dagegen die schon angesprochene Change-Angst vor der Veränderung. Gerade im mittleren Management träfe man auf viele gewachsene Persönlichkeiten aus dem Unternehmen heraus:
"Die sind seit 20 Jahren, 30 Jahren da. Und die hoffen halt einfach, dass die Sau an ihnen vorbeigetrieben wird und dass sie auch die überleben. Und dann kommt der Coach und sagt: Pass mal auf, Überraschung, wir machen jetzt alles anders. Das ist sehr schwierig."
Und wie kann ein Berater, Release Train Engineer oder ein SPC hier aktiv unterstützen, um eine solche Angst vor Neuerungen abzubauen und für mehr Offenheit zu werben? Viele Einzelgespräche, Überzeugungsarbeit, das sei ein Rezept. Und dabei könne SAFe mit seinen Referenzen gut helfen:
"Leute, überlegt mal, seit wann es dieses Framework gibt. Und wer es alles benutzt. Wenn es Mist wäre, würde es nicht mehr bestehen."
Auf Teamebene sei es wiederum eine Herausforderung, überhaupt echte Agilität zu etablieren. In Konzernen träfe man immer wieder auf Teams, die glauben, dass sie agil arbeiten, es aber nicht tun. Hier müsse man ansetzen. Und in der Praxis ließe sich dann auch schnell aufzeigen, dass kleine Schritte bereits viel verändern können.
Reaktion und Anpassung
Zum Schluss beantwortet Burkhard die häufig gestellte Frage nach der Prozesstreue und Stringenz im Hinblick auf SAFe bei der Agile-Skalierung. Ist SAFe mit seinen umfangreichen Prozessempfehlungen nicht ein bisschen wie alter Wein in neuen Schläuchen? Gelegentlich ist ja die Rede von Agile im Wasserfall-Mantel. Wie eng sollte man das Framework denn nun auslegen? Wie nah am vorgesehen Prozess sollte man bleiben? Hier hat mein Gesprächspartner ein schönes Bild zur Hand:
"Mit so einem Framework ist es wie mit einem goldenen Käfig. Es ist ein bisschen wie Kinder zu haben. Am Anfang schnürt man den Käfig sehr eng, denn es gibt ja auch Sicherheit, bis die laufen können oder flügge sind und ein bisschen fliegen können. Und dann kann man dieses Frame immer weiter, immer toleranter setzen. Und so kann ich reagieren und anpassen: Wo mache ich es eng? Wo lasse ich viel mehr laufen? [...] Da kann man eigentlich ziemlich gut eine Lösung finden, von der man sagt: Pass mal auf, das ist eigentlich auch ein guter Schritt nach vorne."
Noch einmal vielen Dank an Burkhard Schmidt für das spannende Gespräch! Das gesamte Interview können Sie wie gesagt in unserer Infothek nachlesen.
SAFe mit Atlassian-Tools: Agile Hive jetzt kennenlernen!
Wollen Sie mehr über die Software-gestützte Umsetzung von SAFe wissen? Eine Lösung dafür heißt Agile Hive. Gerne diskutieren mit Ihnen über Ihre Anforderungen an ein unternehmensweites agiles Produktentwicklungs- und Produktmanagement und demonstrieren Ihnen die Funktionen der Software in einer persönlichen Session. Melden Sie sich bei uns! In unserer Infothek finden Sie Details zu unseren Agile-Hive-Einführungsprojekten.
Weiterführende Infos
Agile Hive 3.0 – SAFe ganz einfach!
SAFe, Skalierung von Agilität und Agile Hive – Interview mit Dr. Thorsten Janning von KEGON
LeSS versus SAFe: Agile-Skalierung bei BMW – ein Interview mit Marcus Raitner
SAFe in Jira versus SAFe in Jira mit Agile Hive
