Das Scaled Agile Framework und typische Herausforderungen bei der Implementierung (mit Dr. Thorsten Janning)

Veröffentlicht am 26. August 2020

Behandelte Themen

Einführung von Matthias Rauer

Komplexität der Einführung agiler Prozesse

Wer im Unternehmen beauftragt die Hilfe bei der Skalierung?

Welche konkrete Rolle spielt das Management bei einer SAFe-Einführung?

Wie kann man sich ein Einführungsprojekt mit Kegon vorstellen?

Stolperfallen bei der Agilen Skalierung nach SAFe

Braucht SAFe Software-Unterstützung?

Möglichkeiten des Austauschs zu SAFe (Tools4AgileTems, BarCamps)

Transkription des Podcasts

Mit: Matthias Rauer von Seibert Media und Thorsten Janning von der Kegon AG

Matthias:

Hallo und Willkommen zum nächsten Podcast von Seibert Media. Auch in dieser Folge geht es um die Skalierung von agiler Zusammenarbeit in der Software-Entwicklung und heute konkret um die Implementierung des Scaled Agile Frameworks in Organisationen. Als Gast Experte ist weiterhin Dr. Thorsten Janning von Kegon aus Wiesbaden dabei, der im ersten Teil dieses Interviews bereits eine kleine Einführung zu Scaled Agile und SAFe gegeben hat und daran wollen wir jetzt direkt anknüpfen. 

Hallo nochmal Thorsten, schön dass du dir die Zeit nimmst.

Thorsten:

Ja, ich freue mich, bei euch zu sein. 

Matthias:

Ich bin Matthias Rauer. Und nun also Implementierung von SAFe. Aus eigener Erfahrung bei Seibert Media wissen wir, dass die Einführung agiler Prozesse schon auf Team-Ebene eine durchaus komplexe Herausforderung sein kann, bis das funktioniert. Und ob es denn je funktioniert, steht auch in den Sternen. Es gibt genug Beispiele von Teams, die nach ein paar Versuchen, und wenn es dann mal brannte, wieder auf ihre alten Prozesse zurückgekommen sind. Ich vermute, dass die Komplexität nochmal deutlich zunimmt, wenn es darum geht, Agile in einer ganzen Organisation, mit hunderten oder tausenden Leuten und vielleicht mit hunderten von Teams einzuführen, oder?

Thorsten:

Na ja, um dem vielleicht näher zu kommen, muss man vielleicht mal kurz reflektieren, warum ist es bei euch in diesem, bei der Scrum-Einführung eventuell schon schwierig. Und meine Erfahrung sagt, das sind oft persönliche Verhaltensreflexe. Man hat einfach gelernt, in einer gewissen Art und Weise zu arbeiten und dann merkt man, boah, das wird jetzt irgendwie anders und ich bin gar nicht mehr der gefragte Experte, sondern ich muss mehr dann irgendwie mit anderen teilen, ja. Es ist kein Asset mehr, irgendwie nur Know How Monopol zu haben, sondern möglichst Know How geteilt zu haben. Das sind alles Dinge, gerade wenn es schwierig wird, wo man dann oft in Reflexe mit denen man ja Erfolg gelernt hat, wieder zurückfällt. Das ist ja das Blöde eigentlich oder das Schwierige bei der Einführung eines Scrums. Und wenn wir jetzt eine größere, komplexere Organisation haben, dann haben wir eben tatsächlich nicht nur mit diesen persönlichen Reflexen zu tun, sondern haben systemische Reflexe.

Ja, das heißt, wir haben einerseits immer noch die persönlichen Reflexe aller Leute in den Teams, aller Leute in Führungsverantwortung, die halt gelernt haben, in einer bestimmten Art und Weise Erfolg durch Führung, durch Anweisung und all solche Dinge zu tun und es sind auch Reflexe im System, also im systemischen Teil der Organisation, ja. Also was, wie gehen wir mit Fehlern um, wie honorieren wir eigentlich, dass Leute mehrere Dinge gleichzeitig ausprobieren, oder ja, was halten wir für zielgerichtetes oder erfolgreiches Arbeiten. Was bedeutet es, Verantwortung zu übernehmen. Das ist alles mit Reflexen verbunden und wenn wir hier über so eine agile Transformation sprechen, dann ist es eine kulturelle Transformation. Und da wir diese vielen Reflexe überwinden müssen, ist es tatsächlich eine ganze Ecke komplexer und es hilft aber tatsächlich ein bisschen mit diesem systemischen Blick da einmal drauf zuschauen und zu verstehen, das ist jetzt nicht Blödheit oder das ist keine Bosheit, das nicht zu tun, sondern das sind einfach diese gewohnten Erfolgsrezepte, die gerade, wenn es schwierig wird, immer wieder hochkommen.

Matthias:

Und Systeme haben manchmal die Eigenschaft, sich gegen Veränderungen zu wehren. 

Thorsten:

Klar. Klar, ja. Und ich meine, das ist dieser Teil, dieser Reflexe. Wir haben natürlich auch rein sachliche Komplexität noch. Also wenn wir so eine agile Transformation machen, dann ist eine der großen Herausforderungen erstmal, wie ist eigentlich der Zuschnitt von Teams und Agile Release Trains. Teams und Tribes. Also das alleine ist schon eine, also die schwierigste intellektuelle Aufgabe in so einer Transformation. Nämlich zu überlegen, wie müssen die Kommunikations-Strukturen sein, damit wir tatsächlich das am besten machen und es geht ja auch immer darum, Komplexität zu reduzieren. Also wie viel kann ich im Team machen, dass wir wenig Abhängigkeiten haben und so etwas. 

Ja dann müssen wir über die Reihenfolge der Transformation nachdenken. Also was ist der erste Teil, was sind die ersten Teams, was ist der erste Agile Release Train. Auch da muss man überlegen, wo sind die Voraussetzungen gut. Das ist eine planerische Herausforderung. Und dann kommen natürlich noch Themen dazu, die wir auch in der agilen Ebene der Teams nicht haben, also, wie gehen wir mit Budgetierung-Zyklen um, was bedeutete das fürs HR, was bedeutet das für Karrierepfade, Fachkarrieren, was bedeutet das für eine Aufbauorganisation, wenn wir so etwas in der ganzen Organisation machen. Das sind natürlich alles Themen, die wir beim agilen Team nicht haben und die früher oder später bei der großen Transformation auf uns zukommen. 

Matthias:

Wer kommt denn wegen so einem Projekt typischerweise auf euch zu, um Hilfe bei der Skalierung solcher Prozesse zu erhalten? Also von wem im Unternehmen geht denn so eine Initiative aus. Es ist vermutlich nicht der Vorstandsvorsitzende, der bei dir anruft und sagt, Herr Janning, wir wollen SAFe einführen. 

Thorsten:

Das ist tatsächlich etwas unterschiedlich und hat sich aber auch im Laufe der Zeit verschoben. Also es ist vielleicht tatsächlich nicht immer der Vorstandsvorsitzende, aber es ist inzwischen durchaus häufig, dass ein Vorstand auf uns zukommt. Oft ist es ein Vorstand, der die Aufgabe der Digitalisierung hat oder sich für digitales Geschäft aufzustellen. Es ist oft Vorstandsebene, beispielsweise wenn Branchen sich gerade umbauen. Gerade im Bereich Automotive im Moment passiert wahnsinnig viel. Und da sind es tatsächlich Entscheidungen auf Vorstandsebene große Dinge zu tun. Und wenn es nicht die Vorstände selbst sind, die dann bei uns anrufen, dann haben die im Prinzip solche Enterprise Agile Coaches für diese Aufgabe für sich als Stab eigentlich definiert und das sind wirklich gut ausgebildete Leute, die dann die Aufgabe aus der Organisation heraus dann auch annehmen und die dann uns quasi dann als Hilfestellung engagieren. 

Matthias:

Ah, da können wir vielleicht direkt anknüpfen. Bei so einem großen Veränderungsprojekt spielt immer irgendwie das Management eine Rolle. Welche konkrete Rolle spielt das denn bei einer SAFe-Einführung? Reicht das zum Beispiel, wenn das Management das Wohlwollen abnickt. Oder muss da der Vorstand selbst Aktivitäten entfalten, was sind denn deine Erfahrungen?

Thorsten:

Also, wenn wir das Management anschauen, dann gibt es da so einen alten Reflex, der ist ähnlich, wie du es beschreibst. Also, ich beauftrage dann mal die agile Transformation und dann hole ich die in einem halben Jahr ab, oder in einem Jahr, wenn es halt eine große ist. Und es ist tatsächlich so, dass das nicht so wirklich gut funktioniert und warum funktioniert es nicht? Wir haben vorhin über systemisch gesprochen und über all die Dinge, die da kommen. Wenn wir Transformation mal nach Kotter betrachten, dann sind da eigentlich zwei Punkte ganz am Anfang von ihm beschrieben und die heißen also wir brauchen einen “Sense of Urgency”, also es muss tatsächlich irgendein Bedürfnis da sein und das muss durch das Management verkörpert sein und dann muss dieses Bedürfnis vom Management auch klargemacht werden. Und das ist nicht eine Beauftragung, sondern dieses Bedürfnis muss in die Organisation immer wieder hinein kommuniziert werden. Also, warum ist das so dringlich, dass wir es tun. 

Und da zweite ist, “Build a guiding coalition’. Ja, und wenn wir von außen als Berater das tun würden, dann würde das System sich von innen nie verändern. Das heißt, also diese Guiding coalition muss immer aus internen Führungskräften bestehen, die auf der Basis dieses Sense of Urgency tatsächlich eine Veränderung betreiben, aktiv betreiben. Und das ist die theoretische Basis und das bedeutet, dass eben das Management quasi der Product Owner für das Transformations-Team ist und da aktiv arbeitet. Das ist dafür tatsächlich in den Stabsbereichen, wie im HR, wesentliche Kapazitäten freigemacht werden, wie denn dann die notwendigen Rollen-Definitionen aussehen und dass man das eventuell auch bezüglich der Mitarbeitermitbestimmung dann auch entsprechend regelt. All solche Fleißarbeiten müssen natürlich aufgesetzt werden und das muss von innen kommen. Das muss aus der internen Organisation, aus der Führungsstruktur kommen, das können wir als Externer nur begleiten. 

Matthias:

Das ist vielleicht, gibt das schon einen Einblick darin, wie ihr eure Projekte so durchführt. Ich frage mich, oder habe mich gefragt, wie ich mir so ein Einführungsprojekt mit Kegon vorstellen kann. Läufst du da vielleicht noch mit zwei drei deiner Kollegen wochenlang 24/7 in dem Unternehmen rum und ziehst sozusagen die Fäden oder verfolgt ihr einen anderen Ansatz?

Thorsten:

Also da sind wir vielleicht auch nicht typisch für die ganze Szene. Also, also wenn wir Mitbewerber sehen, gerade große Mitbewerber, die agile Transformationen nach SAFe machen, die kommen tatsächlich genauso, wie du beschreibst oft mit einem Team von fünf Leuten, die dann tatsächlich für ein halbes Jahr dann vier Tage mindestens vor Ort sind und möglichst operative Rollen übernehmen und damit einfach auch viel Umsatz machen. Aus der Erkenntnis, wie ich es eben mit dem Kotter beschrieben habe, haben wir unseren Ansatz grundsätzlich anders definiert. Das heißt, wir versuchen von Beginn an die wesentlichen operativen Rollen in der agilen Ablauforganisation wie wir sie nach SAFe bauen, Release Train Engineer, Produktmanager, dass die von vornherein durch interne Leute besetzt sind und dass wir diese Leute nur in ihre Arbeit hinein coachen, so dass wir dann, wenn wir selbst am Anfang vorne stehen, schon nach wenigen Monaten dann quasi succesive zurückgehen können und damit dann auch der Transformation auch wieder raus. 

Das heißt also, mein Arbeitsalltag sieht so aus, dass ich im Prinzip nicht mehr als ein oder zwei Tage pro Woche pro Transformation investiere. Das heißt, dass ich auch eigentlich immer zwei Transformationen parallel laufen habe und dann im Prinzip dann immer nur schrittweise zurück gehe, um dann nachher nur noch einmal alle Vierteljahre zu schauen, also hast du noch Fragen, hast du noch Bedarf und dann sind wir auch raus. 

Matthias:

Also das Ziel, sozusagen aus deiner Sicht besteht vor allem in der Befähigung der internen Leute. 

Thorsten:

Ja, klar. Ja, ich muss ja das System in anderen Zustand versetzen und das geht nur, wenn die Leute im System das für sich auch akzeptieren und verkörpern. 

Matthias. 

Ja. Erzähl doch mal ein bisschen was aus deiner Beraterpraxis. Welche Fehler und welche häufig zu beobachtenden Stolperfallen lauern denn bei der Agilen Skalierung nach SAFe. Was tritt denn vielleicht besonders häufig auf, was solche Vorhaben an den Rand des Scheiterns bringt, oder zum Scheitern bringt?

Thorsten:

Also es ist tatsächlich so, dass, du hast vorhin einmal gefragt, wie werden wir beauftragt. Also es ist inzwischen eine typische Situation, dass Unternehmen eine SAFe Transformation angefangen haben und irgendwann merken, das läuft irgendwie Scheisse, ja. Und wenn wir in solche Kunden-Kontexte kommen, dann ist das häufig, dass dort agile Fassaden gebaut worden sind. Das heißt, es werden Dinge gemacht, es wird ein PI-Planning gemacht, es werden die Scrum-Meetings gemacht, aber die eigentlichen Prinzipien werden nicht gelebt. Ja, das heißt, man hat im Prinzip zwei Systeme parallel implementiert. Alle klassischen Projektmanagement-Mechanismen sind weiter geblieben, alle Reporting-Mechanismen sind geblieben, alle Linienstellen sind geblieben, das heißt also, es sind verschiedene Systeme wie eigentlich Entscheidungen getroffen werden, parallel implementiert worden und eins davon ist diese agile Fassade und die kann da nicht zur Wirkung kommen. Und das ist eigentlich das Häufigste, was man so eigentlich so sieht. 

Was anderes, was auch immer vorkommt, ist man meldet zu früh Erfolg. Wir haben das erste PI-Planning gemacht, shacka, aber ich habe noch kein Stück Software geliefert. Das heißt, also diese ganzen Fleissarbeiten, dann auch in Continuous Delivery zu kommen und also was mit dem SAFe dann zwar mit Dev Ops auch beschrieben wird, aber wo ich aber tatsächlich ganz andere technische Fähigkeiten, Tools einsetzen muss und das ist ja verdammt viel Fleissarbeit und technische Kompetenz. Das wird von vielen SAFe-Beratern halt etwas vernachlässigt und nur wenn ich Software liefere oder wenn ich meine Produkte liefere, dann kommt Wirkung, ja. Und das heißt, also viele sind mit diesem ganzen Planungs- und Priorisierungs-Kram dann sowas von zufrieden, dass sie eben vergessen, agil zu liefern. Das ist der zweite Aspekt. 

Matthias:

Jetzt, wo wir gerade über Software sprechen, lass uns mal kurz dabei bleiben. Scrum in einem Team funktioniert im Zweifel ganz ohne digitale Tools. Ein Board, viele Papierkärtchen da drauf, die da hin- und hergeschoben werden, im Zweifel reicht das für ein einzelnes Team schon, um sich soweit für die tägliche Arbeit zu organisieren. Auf der Ebene, über die wir hier sprechen, mit Team of Teams und Agile Release Trains und dutzenden oder hunderten von Teams geht das natürlich nicht mehr. SAFe braucht Software-Unterstützung, richtig?

Thorsten:

Ich will es mal in zwei Teilen beantworten. Ich persönlich bin auch im SAFe ein großer Freund von physischen Tools. Also dass wir im PI-Planning an den Wänden arbeiten und dass wir da gemeinsam Fäden ziehen und solche Dinge und das funktioniert auch tatsächlich gut, wenn wir in unserem Agile Release Train co-located arbeiten und so, dann hat das ganz große Wirkung, dass wir tatsächlich auch miteinander arbeiten, miteinander ringen und diese physischen Tools zwingen uns quasi dazu, ja. 

Wenn wir mit elektronischen Tools arbeiten, dann ist immer die Gefahr nochmal größer, dass man doch wieder diesen Reflex des Scheuklappen-Aufsetzens mit seinem Computer und eben nicht in die Kommunikation zu gehen, geht. Trotzdem ist es so, und da hast du natürlich Recht, in den meisten SAFe-Implementierungen müssen wir mit Tools arbeiten, weil wir zwei Parameter eigentlich fast immer haben. Entweder unsere Organisation ist eben nicht co-located, sondern es ist eine verteilte Organisation, Corona jetzt auch mal im Extremen, ja. Also beispielsweise, wir haben jetzt ja die letzten vier fünf Monate fast nur virtuell gearbeitet, auch in den ganzen SAFe-Implementierungen und wir beobachten, dass PI-Plannings, die voll verteilt sind, also wo nicht irgendwie zwanzig Leute in einem Raum sind und der Rest irgendwie zugeschaltet, sondern wo jeder dieselbe Arbeitsbedingung hat, das ist dann fast sogar noch besser funktioniert, in der Kollaboration, wenn wir die entsprechende Infrastruktur dahin setzen, was die Tools und Whiteboards und solche Dinge angeht. 

Und das zweite ist, was wir an Dokumentationspflichten haben, aus regulatorischen Anforderungen. Das heißt, ja und auch da brauchen wir unbedingt Tools und auch das ist keine Seltenheit. Für einen Webshop ist es nicht so wichtig, aber wenn wir Röntgengeräte entwicklen oder autonom fahrende Fahrzeuge, dann haben wir, oder auch im Finanzwesen, dann haben wir wirklich regulatorische Anforderungen bezüglich der Prozess-Dokumentation der Prozess-Nachvollziehbarkeit und da helfen uns die Tools natürlich wahnsinnig. Und wenn wir es dann auch so richtig tun, wie ich das mit dem Corona beschrieben habe, dann müssen sie sogar gar kein Hindernis sein. Bloss, auch da sage ich immer, lass uns die Tools nicht als Tool einführen, sondern lass uns erst ein Kommunikations-Design machen. Und dann überlegen, wie stützen die Tools eigentlich die notwendige Kommunikation, die wir haben und dann wird es glaube ich ganz gut.

Matthias:

Das ist eben eine ewige Reibung, aber diese gibt es, seit es Ältere gibt.

Thorsten:

Genau, genau, ja. Aber ich glaube der Fehler, der da oft gemacht wird ist, wir müssen jetzt ein Tool einführen, ja. Aber wir müssen immer von der Kommunikation ausgehen und sagen, wie hilft uns das Tool bei der Kommunikation. Ja und dann wird es besser, ja, und dann wird es kein Hindernis.

Matthias:

Und dann kommt Agile Hive ins Spiel, das Kegon gemeinsam mit uns entwickelt, um den Namen auch mal ins Spiel gebracht zu haben. Thorsten, abschließende Frage, wenn ich jetzt als Hörer nach Informations-Möglichkeiten zu SAFe über Podcast und Vorträge und oder Artikel hinaus suche, und mich vielleicht gern mit anderen Interessierten austauschen möchte, vielleicht Erfahrungen teilen oder mit anderen besprechen möchte. Welche Möglichkeiten des Austauschs gibt es denn da, die du empfehlen würdest? Da gibt es doch sicher auch irgendwelche physischen Events?

Thorsten:

Ja, also es gibt inzwischen eigentlich flächendeckend weltweit SAFe Meetup Strukturen. Da war jetzt zum Beispiel auch der schöne Effekt, durch Corona, dass wir globale Meetups zusammengeführt haben und beispielsweise mit Dean Leffingwell dann global diskutiert haben in den Meetup Sessions. Aber natürlich physisch nochmal bestimmte Themen sich immer herzunehmen, das funktioniert gut. Auch im Rhein-Main Gebiet haben wir das. 

Dann haben wir sehr gute Erfahrungen gemacht, indem wir BarCamps organisieren. Also BarCamps für bestimmte Rollen. RTE BarCamps, Product Management BarCamps, wo wir mit 40, 50 Leuten, die eigentlich eine Un-Konferenz machen und quasi nur Themen diskutieren, die die Menschen aus ihrer Praxis mitbringen und extrem gutes Feedback. 

Und dann gibt es natürlich Konferenzen, wie die SAFe-Summits, wie eure Tools4AgileTeams, die extrem cooles Austausch-Forum sind, wo ich immer sage, die Vorträge sind zwar auch nett, aber eigentlich ist es gut, die Leute zu treffen. Das heißt, auch da haben wir natürlich die entsprechenden Konferenz-Strukturen und das ist sehr hilfreich. Wir müssen jetzt mal sehen, wie es halt mit den Corona-Abstandsregeln und solchen Dingen da geht, was die physische Präsenz angeht, ja. 

Matthias:

Aber die BarCamps finden normalerweise bei euch in Wiesbaden physisch statt?

Thorsten:

Entweder in Wiesbaden oder wir machen das mit den Kollegen von Wibas in Darmstadt. Dass wir das gemeinsam organisieren, aber das sind in der Regel physische Events. Wir haben es jetzt auch im Frühjahr dann virtuell gemacht. Hat auch funktioniert. Trotzdem freue ich mich auch, ich habe jetzt demnächst auch wieder das erste physische Training, Implementing SAFe Klasse. Also dass wir lernen, irgendwie damit umzugehen. Und insofern Un-Konferenzen leben eben auch davon, dass man sich eben zufällig beim Kaffeetrinken irgendwo trifft und anfängt da was zu diskutieren. Und das kriegen wir virtuell halt nur schwierig simuliert. 

Matthias:

Genau. Okay, also wenn ihr euch mit anderen Leuten zu Scaled Agile austauschen möchtet, schaut bei Kegon vorbei oder in Darmstadt bei den Kollegen von Wibas oder eben auch bei unserer Konferenz Tools4AgileTeams, die findet dieses Jahr am 3. und 4. Dezember 2020 statt und so Gott will als Hybrid-Event mit physischem und Remote Anteil. Aber wir werden alle sehen, was die Wochen und Monate bringen.

Thorsten Janning, ganz herzlichen Dank, dass du dir die Zeit genommen hast. 

Thorsten:

Es hat ganz viel Spaß gemacht! 

Matthias:

Mir auch, vielen Dank! Und euch wieder vielen Dank fürs Zuhören. Ich hoffe, wir hören uns beim nächsten Mal dann wieder. Dann wollen wir uns unter anderem eingehender über die Rolle von Software bei der SAFe-Implementierung unterhalten. Bis dahin, macht es gut, Tschüß!