Martin: Lass uns über SAFe sprechen. Kannst du frei raus ein bisschen was von deiner Erfahrung erzählen? Was hast du für positive und negative Erfahrungen gemacht? Was hältst du für besonders diskussionswürdig?

Burkhard: Ich arbeite schon sehr lange als Projektleiter und etwa seit 2011 in der agilen Produktentwicklung und hier überwiegend für Konzerne. Dort ist man sehr schnell auch in Projekten drin, die noch klassisch in Silos aufgebaut sind. Und dann suchst du einfach nach Strukturen und nach Überlegungen und nach Lösungen, wie man seine Projekte siloübergreifend gut strukturieren und umsetzen kann. Und da gibt es halt verschiedene Methoden.

Scrum of Scrum, LeSS haben wir probiert. Aber das SAFe-Framework war für mich eigentlich von der Vorgehensweise und von der Lösung am besten geeignet, weil es durch die skalierten Strukturen so ein bisschen die Konzern-Strukturen aufnimmt. Es wirft die Frage auf: Warum mache ich das eigentlich, dieses Projekt? Es geht also nicht einfach darum, das Projekt in der Lieferkette zu vervollständigen, sondern auch zu überlegen, was das unternehmerische strategische Ziel dahinter ist. Das ist in Konzernen oft so ein bisschen abgekoppelt. Und auf der anderen Seite ist es auch eine Methode, um aus unternehmerischer Sicht mal wirklich reales Feedback zu bekommen. Habe ich meine strategische Planung, meine Leitplanken eigentlich gut gesetzt? Wie und was kann mein agiles Team als One Team oder ART Solution für mich realisieren? Wie kommuniziere ich Meilensteine? Wie kommuniziere ich Budgets und finanzielle Vorhaben? Das fand ich eigentlich sehr interessant.

Von der IT-Seite und der Lieferketten-Seite her denke ich, dass es eine Vorgehensweise ist, die sowohl agilen Projekten und auch klassischen Projekten gut tut, weil diese Aufteilung im PI wie ein roter Faden ist, der für manche agile Teams eigentlich sehr hilfreich ist, damit sie sich nicht nach jedem Inkrement verlieren. Sie wissen: Ich möchte ja ein Produkt liefern, ich möchte ja ein Nutzen erzeugen, ich möchte Kunden gewinnen, ich möchte Geld verdienen und nicht irgendwie rumspielen. Das ist die eine Seite.

Und auf der anderen Seite gibt das Framework auch klassischen Projekten die Möglichkeit, durch die kleinen Iterationen, durch die Feedback-Loops immer wieder auch ihre Vorgehensweise zu verifizieren. Sind zum Beispiel meine Anforderungen wirklich richtig formuliert? Und von hier aus glaube ich, dass beide Ansätze auch einen Synergie-Effekt erreichen.

Der wesentliche Vorteil aus einer Konzernsicht ist, wie es läuft. Man hat in den Silos oder auch in den einzelnen Teams innerhalb eines Silos irgendwelche Teilprodukte eine Wertschöpfung. Hier wird oft autonom, gemeinschaftlich oder vielleicht auch agil gearbeitet, und da funktioniert das für sich auch. Aber man hat keine Synergien, man denkt nicht lean. Wie kann man Einheitlichkeit erreichen, Synergien heben? Das ist der eine Punkt.

Der zweite Punkt: Es gibt dann irgend so einen armen Release-Manager, der in wöchentlichen Meetings einsammelt, was gerade fertig ist, wo Risiken und wo Abhängigkeiten sind. Das SAFe-Modell mit dem PI-Planning als Markenkern von SAFe dreht es um: Am Anfang einer Interation überlegen wir uns mit den Teams, was wir erreichen werden, wo unsere Abhängigkeiten. Man erreicht dadurch auch ein Alignment. Und das erleichtert es dann dem Release Train Engineer, die Teams auf Linie zu halten und Risiken, Abhängigkeiten und Impediments zu managen, statt von den einzelnen Teams immer nur was zugeworfen zu bekommen. Von daher finde ich dieses Framework wirklich gut.

Kannst du deine Erfahrung mit LeSS und Scrum of Scrum auch noch einmal erläutern und erklären, warum ihr von dort aus dann woanders hingewechselt seid?

LeSS haben wir nur rudimentär eingesetzt, weil es einfach nicht so eine Akzeptanz gefunden hat. Ich denke, dass der Unterschied vor allem darin liegt, dass man nicht diese PI-Struktur hat, wo man sagt: Okay, das sind jetzt die Dinge, die wir im nächsten PI erreichen wollen. Das fand ich ein bisschen strukturloser. Der Unterschied zwischen LeSS und SAFe ist einfach, dass der LeSS-Ansatz eher Bottom-up ist, also nach dem Motto: Ich habe jetzt hier ein agiles Team, mit dem ich anfange, ein Produkt zu entwickeln. Dann wachse ich, dann habe ich auf einmal mehrere Teams, die für sich autonom sind. Und jetzt möchte ich aus diesen Teams heraus eigentlich eine Lösung finden. Und die stellen dann fest, dass es vielleicht doch mal ganz cool wäre, wenn man ein gemeinschaftliches Produktmanagement hätte oder wenn wir Dinge gemeinschaftlich abstimmen würden. Also es ist eher so von Bottom-up gezogen.

Und SAFe ist eher ein 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 Trains, und ihr seid als Puzzlestück verantwortlich, dies und jenes zu liefern. Weil wir damit Geld verdienen wollen. Und ihr seid auch dafür verantwortlich zu überlegen, was man noch additiv gewinnen kann: Wo sind vielleicht auch Consulting-Leistungen, Produktleistungen? Denn ihr kennt das Produkt und den Kunden am besten.

Das ist eben ein anderer Blickwinkel. Und ich glaube, dass es im Konzernumfeld leichter ist, aus diesem SAFe-Umfeld heraus vorzugehen - auch hinsichtlich Akzeptanz der Leute. Das Wesentliche bei der Einführung dieser Frameworks ist diese, insbesondere auf Mittel-Management Ebene zu beobachtende Angst vor Statusverlust, vor Veränderung, vor Verlust an Freiheiten. Muss ich meinen Arbeitsplatz verlegen, wenn Teams zusammengelegt werden? Muss ich mich auf einmal mit zehn anderen Teams abstimmen in meinen Train? Darf ich es nicht mehr so machen, wie ich es will? Das war doch gut!

Solche Geschichten sind schon ein Problem sind, und das hast du natürlich bei einem LeSS-Ansatz auch. Wir haben es in zwei Projekten probiert, und da bist du bei vielen Dingen einfach am Totdiskutieren, weil die Leute ein bisschen die gemeinschaftlichen Schwierigkeiten haben, so eine gemeinschaftliche Vision zu entwickeln und die halt umzusetzen.

Du bist Gründer, ich bin ebenfalls Gründer von Firmen - wir kennen das: Du hast eine Vision, du willst irgendwas erreichen. Und dein engstes Netzwerk, deine Leute, mit denen du schon ewig zusammenarbeitest, ebenfalls. Aber du wirst bei deinen 150 Leuten auch ein paar haben, die nur einfach von neun bis fünf einen Job haben wollen. Und das ist auch fair. Aber die erreichst du halt nicht so gut über einen Bottom-up-Ansatz, weil die sagen: Was willst du eigentlich? Ich will doch nur arbeiten. Die erreicht man glaube ich eher, wenn man so eine Vision entwickelt und verteilt.

Weil es dann schon eine Struktur gibt, in die sie sich einfügen können. Die sagen: Ah, okay, hier ist quasi eine neue Passform und wenn ich mir die angucke, ist die gar nicht so schlimm.

Genau. Aber wenn du eine klassische Führungsstruktur hättest, schauen diese Leute sich das Framework an und sagen: Ah, guck mal, Teamleiter und Abteilungsleiter gibt es da gar nicht. Wo bin ich auf einmal? Für die ist es erstmal ein bisschen schwierig. Aber ich denke, dass das eine Frage des Coachings ist. Man muss zusammen überlegen: Okay, da findest sozusagen auch du deine Perspektive. Auch du findest da einen Job. Das ist ein bisschen die Schwierigkeit, warum es da oft Probleme gibt. Aber sonst klappt das ganz gut.

Wo bist du denn normalerweise aktiv? Also eher in diesem technischen Bereich, in dem du den Teams dabei hilfst, in der Softwareentwicklung voranzukommen und das abzustimmen? Oder eher in der persönlichen Abstimmung mit den Leuten: Wie ist deine Perspektive, wie kommst du mit Anderen zurecht, wo sind deine Stärken?

Meine großen Erfahrungswerte bestehen in der tatsächlichen Umsetzung der Lieferkette, also im Job des Release Train Engineers, und auch in den Erfahrungen, die ich bei der Bildung und Leitung von Transformationteams auf Managementebene gewonnen habe. Auch mit diesen Managern arbeite ich sofort agil, weil es viele Vorteile gibt. Da gilt ja quasi das Motto: Ach, die liefern ja nichts, die haben alle zwei Wochen eine neue Idee und das ist ja alles so intransparent und so unkoordiniert. Und dann machen wir es mit denen auch. Wir machen ein Jira-Board auf, wir überlegen uns, was die Transformation-Features sind, was die Stories und so weiter. Wir überlegen Szenarien, und dann schieben wir die in Zwei-Wochen- oder Drei-Wochen-Sprints, machen Retros, Reviews.

In einem Projekt haben wir alle Manager der Lieferkette zusammengezogen - also von der Anforderung bis hin zum Test und zum Release -, ein Transformationsteam gebildet und mit denen erstmal Scrum-Basics gemacht. Stories, Features definiert. Akzeptanzkriterien definiert. Und die haben wir dann im Prinzip durchgeschoben.

Und dann kommen schon auch Coaching-Fragen auf. Das ist aber nicht so der wesentliche Faktor. Ich glaube, dass es immer auf den Zusammenhang ankommt. Jemand, der vorher der Abteilungsleiter der Fachseite war, ist jetzt auf einmal Product Owner. Was bedeutet das für ihn? Und da hilft schon einmal ein Training, auch ein SAFe-Training. Und dann weiß er: Er ist jetzt sozusagen der Key-Accounter seines Trains, seines Teams. Er ist dafür verantwortlich, das Geld in der Lieferkette einzusammeln, neue Features im Konzern einzuholen oder auch mit den Kunden zu sprechen. Was sind die Stärken und Schwächen seiner? Was können sie überhaupt leisten, damit sie überhaupt nicht in die Verlegenheit kommen, irgendetwas leisten zu müssen, was sie nicht liefern können. Und umgekehrt: Was sind die Stärken des Produkts?

Der Nachteil ist natürlich, dass man sich aus Konzernsicht auf einmal viel stärker an so ein Produkt bindet. Vorher war das eher die Aufgabe der Fachseite, also zum Beispiel der IT. Jetzt wird es aber auf einmal fokussiert auf ein Produkt oder auf eine Kette an Produkten. Das ist glaube ich für die der stärkste Change.

Ein Beispiel sind die Tester. In Test und Release wirklich eine Struktur reinzubekommen, ist wirklich eine Herausforderung. Die Entwickler entwickeln irgendwas und bei großen Konzernen hast du ja auch noch externe Entwicklungsteams. Da ist es dann oft noch so: Wenn der Tester den Fehler nicht findet, ist er selber schuld. Stattdessen müssten erstmal die Entwicklungsteams in die Verantwortung genommen werden: Fertig ist es nur, wenn es läuft. Und gleichzeitig müssen aber auch die Tester mitgenommen werden, die jetzt eher Quality-Consultants sind, die am Anfang schon mit dabei sein müssen.

Denn faktisch ist es ja so, dass, wenn die Test-Abteilung zum Beispiel bei Automationen nicht ihre Anforderungen mit eintütet, sei es als Enabler oder als Akzeptanzkriterium zum Feature, wird es nicht entwickelt. Dann gibt es keine Story. Dann gibt es keine Unique ID auf der Seite, um das nachher abzufragen. Umgekehrt wissen die Tester meistens am besten, wo im Zusammenhang aller Applikationen die Schwachstellen sind. Und wie was entlang der gesamten Kette am besten oder am schlechtesten läuft. Die müssen also am Anfang mit reinkommen und sagen: Das sind die richtigen Testdaten oder darauf müsst ihr achten oder wenn ihr da an dem System was verändert, dann verändert sich auch drei Systeme weiter noch was. Das ist das, wo die Tester unglaublich viel Wissen mit einbringen können, was sonst verloren geht.

Das heißt: Man verkürzt dadurch auch die Lieferketten. Und ich finde, auch das geht im SAFe-Modell viel besser als in anderen. In LeSS ist es ja zum Beispiel so, dass du eigentlich so ein Feature-Team in deinen Teams brauchst, um dann wirklich gut strukturiert zusammenzuarbeiten zu können. Bei SAFe ist dagegen der Train eigentlich dein virtuelles Feature-Team. Und ob da jetzt innen drin noch einzelne Komponenten-Teams sind, die du so langsam umformst, oder externe Teams oder Meilensteine, also Wasserfall-Teams - das ist eigentlich Wurst. Das ist einfach eine Sache des Stream-Teams mit Product Manager, Architect, Release Train Engineer, wie sie da ihren Train steuern und dann daraus wirklich Features erstellen und umsetzen.

Du hast hast vorhin gesagt, dass dir an SAFe diese Transparenz bis nach oben zur Geschäftsstrategie gefällt, die im Konzern sonst nicht so deutlich ist. Hinterfragen die Mitarbeiter die Strategie denn auch von unten nach oben und weisen darauf hin, wenn zum Beispiel die Eckpfeiler irgendwie vielleicht falsch positioniert sind? Oder ist das etwas, was im Konzern weiterhin eher nicht so gern gesehen wird und vielleicht eher unterm Teppich bleibt?

Ich glaube, das hängt vor allem vom agiler Reifegrad ab. Oder vielleicht eher vom unternehmerischen Reifegrad. Dadurch, dass du überhaupt erstmal so einen Kanal und einen Dialog öffnest, können sich Meinungen bilden oder Meinungen transparenter werden. Und wenn die Leute auf der horizontalen Ebene mit ihren Dailys und Retros animiert werden, auch mal Stellung zu beziehen oder auch mal eine Meinung zu äußern, dann werden sie es auch vertikal entlang der Trains machen. Und meiner Erfahrung nach wird das tatsächlich auch geäußert: Pass mal auf, das klappt so gar nicht mit dem, was ihr euch da überlegt! Denn das kann man ja auch gut durch Kennzahlen operationalisieren.

Auf der anderen Seite ist es so, dass man auch als Manager auf Dauer offener wird und sagt, man legt es um. Anfänglich ist das aber nicht der Fall. Anfänglich ist es tatsächlich so, dass zum Beispiel in einem Portfoliomanagement-Team viele Product Owner oder Product Manager denken: Okay, das Epic, das da jetzt auf Management-Ebene eingereicht wird, ist gesetzt. Das bekomme ich. Das muss ich in meinem PI umsetzen. Es ist eine Herausforderung zu verstehen, dass sie das ja selbst beeinflussen. Mit meinen Teams, mit meinem Train kann ich auf die Roadmap Einfluss nehmen und definieren, was ich wirklich erreichen kann! Und das ist sozusagen eine skaliert-agile Reife, die entstehen muss.

Wie hast du selbst SAFe gelernt? Wie hast du dir das Wissen angeeignet und was würdest du jemandem empfehlen, der mehr über SAFe wissen will?

Ich bin 2015 erstmalig mit SAFe in Kontakt gekommen. Da habe ich glaube ich einen Artikel gesehen und war dann in London auf einem Training. Das war zur Zeit des Versionssprungs von 3.5 auf 4. Dann habe ich das eine Zeit lang nicht weiter verfolgt und kam 2016 erneut dazu, als ich wieder so ein Cross-Silo-Projekt hatte, das sich dafür eignete. Ich war nochmal in Köln auf einem SPC-Training und habe schließlich auch die Zertifizierung abgelegt.

Was bei den ganzen SAFe-Training auffällig ist: Die erklären dir keine Agilität. Man sollte also im Vorfeld schon ein bisschen wissen und Erfahrung im agilen Arbeiten mitbringen. Scrum, Product Owner, das Schneiden von Features - das wird alles nicht groß erläutert. In den neuen Trainings mit Version 5 wird es ein bisschen besser. Aber man muss halt schon etwas Scrum-Erfahrung haben, sich dafür interessieren, in die Skalierung reinzugehen, und vielleicht auch schon mal Erfahrung aus dem Lean-Umfeld gesammelt haben.

Und bei mir war es so, dass ich mir sagte: Ach Mensch, jetzt habe ich ganz viele wirklich coole Projekte für meine Organisation oder für andere Konzerne realisiert, jetzt wäre es doch mal an der Zeit, Coach zu werden. Aber das ist nicht einfach ein Karriereschritt, sondern ein ganz anderer Beruf.

Also Scrum Master, als Release Train Engineer, als Projektleiter hast du die Aufgabe, dein Produkt zu verbessern, das Produkt zu verkaufen. Als SPC im skalierten Umfeld oder als agiler Coach im normalen agilen Umfeld besteht deine Aufgabe halt darin, die Lieferprozesse zu optimieren, die Zusammenarbeit der Teams zu verbessern. Das ist dein Produkt. Und das ist ebenfalls eine Beschaffungskette, eine Lieferkette. Da brauchst du auch ein Team, brauchst auch Anforderungen. Musst auch Kennzahlen für dich ermitteln. Aber es ist ein ganz anderer Akzent.

Du hast viel in Konzernen gearbeitet. Hast du aber auch mal mit kleineren Unternehmen SAFe gemacht? Wie groß sollte man denn sein, um SAFe sinnvoll nutzen zu können?

Es gibt ja so eine allgemeine Best Practice, dass man etwa vier Teams braucht. Ich glaube aber, dass es gar nicht so sehr darauf ankommt. Die Methode an sich, mit einem PI zu arbeiten und vorher ein Meeting zu halten, in dem ich Abhängigkeiten und Funktionen beschreibe, lässt sich auch mit weniger Teams machen, schon mit zwei oder drei.

Der Aufwand muss ja nicht so groß sein. Bei drei Teams sind die meisten Beteiligten sowieso alle vor Ort und man muss schonmal nicht reisen. Diese Auseinandersetzung mit den wichtigen Fragen ist sicher sinnvoll: Wer macht von diesem Teil eigentlich was? Splitten wir es auf, macht das jemand alleine? Wo sind Abhängigkeiten? Was sind für unsere nächsten vier oder fünf Intervalle eigentlich unsere jeweiligen Lieferziele? Das finde ich einfach sinnvoll. Damit hat man einen roten Faden. Und wenn man nun zwei oder drei Teams hat, braucht man auch kein großes Organisations-Tamtam drumherum machen, würde ich mal sagen.

Das heißt, du würdest auch, wenn du dein Unternehmen auf zehn und dann auf hundert und auf tausend Mitarbeiter hochskalieren würdest, von Anfang an quasi mit SAFe arbeiten - dann halt etwas pragmatischer, je kleiner ihr seid.

Ja, auf jeden Fall. Bei einem großen Projekt waren wir im Großraumbüro, in dem Flur des Großraumbüros war unsere PI-Wand. Und jeden Morgen mussten die Teams und die Leute daran vorbeilaufen und überlegen, wo wir gerade sind. Da gab es einfach einen roten Faden der Teams. Die Vision war immer wieder klar vor Augen. Und ich glaube, das brauchen auch kleine Teams und Unternehmen.

Es gibt ja auch Bestätigung. Ich finde, das Coolste an der agilen Vorgehensweise gegenüber dem Wasserfallmodell ist, dass man durch diese inkrementellen Produkte und durch diese kleinen Liefer-Iterationen immer diesen roten Faden hat, immer darin bestätigt wird, dass wir etwas Sinnvolles, Nützliches, Gutes machen, dass wir vielleicht sogar schon Geld verdienen. Und damit kann ich mich als Mitarbeiter identifizieren. Und so einen Identifikationsfaktor, der über den Fun-Faktor hinausgeht, brauchen gerade kleine Unternehmen, junge Unternehmen mit jungen Mitarbeitern. Die wollen ja auch etwas erreichen.

Lass uns mal über Misserfolge sprechen. Was sind denn häufige Probleme und Stolperfallen, die du bei du den Teams und Managern gesehen hast, die du bisher betreut hast?

Auf Team-Ebene oder auf Train-Ebene hast du häufig das Problem, dass die im Konzern-Umfeld nicht wirklich agil arbeiten können, weil sie einfach keine ausreichende Menge an Testumgebung haben. 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, das Wichtigste und Dringendste zuerst zu entwickeln, weil sie es sowieso nicht testen und verifizieren können. Das ist ein wichtiger Punkt.

Teams sollten entkoppelt voneinander entwickeln und jederzeit deployen können. Das coolste Produkt ist nicht nur das, das den höchsten Kundennutzen hat, sondern das, das eine akzeptierte Qualität hat und das ich jederzeit deployen kann und das dokumentiert ist und das jederzeit Nutzen bringen kann, weil ich es jederzeit verändern kann. Und das muss halt die Infrastruktur auch liefern.

Auf Management-Ebene ist es wie gesagt eher die Change-Angst vor Veränderung das Problem. Das hast du oft gerade im Middle-Management. Das sind halt gewachsene Persönlichkeiten aus dem Unternehmen heraus. Die sind seit 20 Jahren, 30 Jahren da. Die haben da studiert und sind Team-Manager und Abteilungsleiter, die kennen nur das. Aber die kennen halt auch den 25. Veränderungsprozess, der an ihnen vorbeiläuft. Und die hoffen einfach, dass die Sau auch dieses Mal an ihnen vorbeigetrieben wird und das sie auch die überleben. Und dann kommt der Coach und sagt: Pass mal auf, Überraschung, wir machen jetzt alles anders!

Gibt es da einen Trick, den du anderen Coaches mitgeben kannst?

Das ist echt schwierig. Es sind vor allem viele Einzelgespräche. Wie ich sagte: Gerade in Konzernen hast du Teams, die glauben, sie arbeiten agil, tun es aber gar nicht. Sie arbeiten vielleicht iterativ, sie haben da also Phasen, in denen sie ihr Konzept schreiben. Dann übergeben sie das irgendwann an einen externen Dienstleister, der dann irgendwas entwickelt, und dann testen sie es. Das ist ja nicht agil. Agil bedeutet ja, dass wir eng zusammen das Ergebnis hier auch verifizieren können. Das ist also schon mal der erste Move, den die machen müssen. Und der zweite ist einfach Überzeugungsarbeit durch meine Praxis. Dass man auch durch kleine Schritte schnell aufzeigen kann, dass sich was verändert. Das ist glaube ich für mich so ein Spot, der immer zieht.

Und ansonsten habe ich überlegt, in diesem Jahr nochmal eine nebenberufliche Weiterbildung als systemischer Coach zu machen, weil ich finde, dass dieser systematische End-to-End-Ansatz mir gut liegt. Das passt auch in dieses Umfeld rein, wirklich nochmal ein paar psychologische Methoden so zu lernen, um die Leute noch ein bisschen mehr zu überzeugen. Ja, das ist einfach Überzeugungsarbeit. Auch da hilft SAFe ganz gut. Ich sage immer: 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!

Ich kann einfach googeln und finde zu SAFe tausend Sachen, und das gibt ja auch Sicherheit. Und es gibt Trainings, die standardisiert sind, auch im Marktwert. Wenn ich jetzt wachsen möchte oder auf einmal drei Coaches oder RTEs brauche, dann kann ich die auch schnell bereitstellen, wenn ich mich an die Standards halte.

Ein letzter Satz dazu: So ein Framework ist wie so ein goldener Käfig, wenn man Kinder hat. Ja, am Anfang schnürt man den Käfig sehr klein, denn es gibt ja auch Sicherheit, bis sie laufen oder flügge sind und ein bisschen fliegen können. Und dann kann man dieses Frame immer weiter, immer toleranter setzen. Wo mache ich es eng, wo lasse ich viel mehr laufen? Da kann man eigentlich ziemlich gut eine Lösung finden, wo man sagt, das ist eigentlich auch ein guter Schritt nach vorne.