#33 - Wie agil ist SAFe? SAFe or Sorry mit Alexander Dudley und Kay Schulz-Langer

00:00:07: Und da hilft aber dann nach meiner Erfahrung definitiv nicht einfach das Aufsetzen von irgendeinem gearteten Framework, sondern sich dann erstmal noch mal die Frage zu stellen, dann überlegen wir uns mal, wo wollen wir denn... Wo soll die Reise überhaupt hingehen? Und da SAFe ja natürlich auch ganz stark Governance und strategische Entscheidungen mit einbezieht, empfiehlt sich das natürlich dann oft.

00:00:26: In der heutigen Episode spreche ich mit den beiden agilen Coaches Alex und Kay von der Prosma GmbH über agile Transformationen im Allgemeinen und das Rahmenwerk SAFe im Speziellen. SAFe or sorry, das ist hier die Frage. Kai, Alex, herzlich willkommen im dno Podcast.

00:00:45: Hi, Andreas!

00:00:46: Hallo, Andreas.

00:00:47: Sag mal, was sind aus eurer Sicht die Kernelemente, die das SAFeFramework auszeichnen? Oder vielleicht auch, ja, was ist denn SAFe überhaupt für den einen oder anderen, der sich vielleicht verirrt hat?

00:00:59: lacht) Der es noch nicht gehört hat... Ja, also ich glaube, Scrum, Kanban da... einfach in der Annahme, da müssen wir nicht (lacht) bei Adam und Eva anfangen, das kennen wir ja. Wir sprechen über Skalierung. Also, da geht es um je nach je nach Schwelle der Teamgröße, sage ich mal, mehrere Scrum Teams oder agilen Teams und wie wir sie sozusagen in einer Organisation gesamtheitlich integrieren. Ja, das ganz grob zu zu SAFe. Und da gibt es, wie gesagt, neben SAFe noch ein paar andere. Genau. Und SAFe hat seine Besonderheiten.

00:01:51: Die da wären?

00:01:53: Es wäre einerseits, ich glaube so im Kern, das sogenannte PI. Planning Intervall, wie es heute heißt. Das ist im Prinzip Sprint in Groß. (lacht) Ja? Es gibt sozusagen auf Basisebene den Sprint weiterhin oder die Iteration, wie es dort heißt, und dann übergeordnet ein PI. Und weil häufig halt nicht auf Sprintebene oder Iterationsebene alles geschafft wird und halt die Abhängigkeiten mit mehreren Teams bestehen, noch das PI obendrüber.

00:02:34: Ergänzend vielleicht noch dazu... Organisiert um Wert. Weil Organise around Value steht halt bei SAFe da so extrem im Mittelpunkt und wird halt hochgehalten. Natürlich sollte das halt auch in vielen anderen Umgebungen passieren, sich immer um den Wert zu organisieren. Letzten Endes liegt SAFe da aber halt auch permanent den Finger in die Wunde. Und mit den entsprechenden Kompetenzen und Werten, wo SAFe ja auch noch mal Eigene hat, sage ich jetzt mal, oder etwas Abweichende zu den ganzen grundlegenden Dingen nach Lean Thinking und dem Agile Manifesto, worauf die natürlich auch ganz stark setzen, das dann halt noch mal hervorgehoben wird.

00:03:20: Also hohe Value Orientierung. Das ist jetzt so ein typischer Beratersatz. Der könnte auch in jedem anderen Framework drin stehen. Die Frage ist ja, also, wenn wir über Kernelemente sprechen, wie schafft das SAFe vielleicht sogar besser als andere, aber da können wir gerne im Anschluss noch drüber sprechen. Wie operationalisiert SAFe diesen permanenten Fokus auf Value?

00:03:40: Ja, das geschieht ja im Prinzip auf dieser Ebene des PIs. Da, wo ein sogenannter Agile Release Train (ART), wird häufig zusammengefasst, also der Zusammenschluss von mehreren Scrum- oder agilen Teams besteht und halt eben dieses Produkt darstellt. Insgesamt. Ganzheitlich. Und das ist halt noch mal eine wesentliche Kernkomponente dabei.

00:04:07: Was würdet ihr denn vielleicht sagen, was SAFe von anderen skalierten Rahmenwerken unterscheidet? Weil bisher habe ich viele Dinge gehört, wo ich sage, "Komm ey, gekauft, gekauft, gekauft... Kaufe ich aber auch mit jedem anderen Framework ein." Also vielleicht in der Unterschiedsbildung zu anderen skalierten Rahmenwerken. Was sticht da hervor? Außer dem PI Planning! (lacht)

00:04:28: Da müssen wir echt über den Begriff Framework halt sprechen. Also, wenn man Scrum wirklich als Framework bezeichnen möchte und den Scrum Guide mal durchgelesen hat - die zehn Seiten - und einmal auf die Scaled Agile Framework Webseite gegangen ist und gesehen hat, wie ausführlich das ist. Es ist überhaupt nicht miteinander vergleichbar. Das ist der wesentliche Unterschied auch zu beispielsweise LeSS schon, der nächste, ich sag mal, in der Größenordnung, dass SAFe eigentlich kein Framework mehr ist. Da gibt es eher, manche sagen dazu TOM, also Target Operating Model, wo wirklich, ich sage mal, der gesamtheitliche Aspekt, die Organisation betrachtet wird. Das heißt bei SAFe Business Agility. Und dazu gibt es halt die ganze Erklärung, die dann auch auf der Webseite zu finden ist.

00:05:32: Ich denke mir, was SAFe dazu halt tatsächlich ausmacht, ist das, was viele auch als unagil oder nicht agil bezeichnen - was ich auch unterschreiben kann - ist aber letzten Endes, da muss ich mir die Frage stellen, was bedeutet denn Agilität für mich an der Stelle? Und ich kenne es halt aus dem Beratungsalltag, dass letzten Endes halt SAFe weniger auf diesen Pragmatismus setzt an der Stelle. Also, es müssen bestimmte Dinge halt innerhalb des Business Operating Modells erfüllt werden, um im Grunde genommen dann diese grundsätzlichen Ziele, die SAFe halt mit sich bringt, wie das Thema, was Alex eben angesprochen hat, Business Agility, überhaupt zu erfüllen. Und wenn ich das erst gar nicht haben will, weil es gibt ja unterschiedliche Ausbaustufen bei SAFe, wie zum Beispiel Essential. Bei Essential erreiche ich keine Business Agilität. Da muss ich mir tatsächlich die Frage stellen, brauche ich überhaupt SAFe? Brauche ich überhaupt diesen ganzen Overhead auch an der Stelle oder eignen sich an der Stelle dann halt, wenn ich nicht 4599 Leute einbinden will, sondern vielleicht nur 288 oder whatever. Also, es ist sehr stark abhängig auch von der Organisationsgröße.

00:06:57: Und fast so wichtig wie die anderen Kernelemente, die wir angesprochen haben, ist das ganze Thema Schulung. Also, wer einmal auf eine Roadmap oder ähnliches gestoßen ist von SAFe, sieht man okay, da gibt es auch dieses ganze Rahmenwerk von und Schulungen und Zertifizierungsmethodik dahinter.

00:07:19: Also, womit ihr mich mal eher erreicht, ist das ja andere skalierte Rahmenwerke deutlich offener oder, ich sag mal, mehr Interpretationsspielraum vielleicht an der einen oder anderen Stelle bieten, also nicht so reguliert ist wie SAFe es vielleicht ist. Auch in der Ausführlichkeit, auch in der sprachlichen Ausführlichkeit. Und da bin ich immer so ein bisschen hin und hergerissen. Auf der einen Seite denke ich mir, super. Weil das ist zumindest ein Startpunkt. Also, es gibt hier eine ganz klare Definition davon, wie Dinge zu sein haben, aber auch wie wir Dinge nennen. Also, ich kriege oft in den SAFe Implementierungen mit, da findet dann wirklich so ein, ja... die sehr hardcore SAFe Vertreter die sagen, das heißt so in dem Rahmenwerk. Die anderen Pragmatiker sagen eher, ja, aber bei uns macht diese... wir nennen es doch so aus unserer Historie und können wir das nicht anpassen? Und dann sagen die Fanatiker, nein, das heißt... Ja, also das beobachte ich. Also, auf der einen Seite finde ich es super, dass es so eine sehr klare Guidance gibt, die sehr tief und sehr detailliert ist. Auf der anderen Seite denke ich mir und höre ich meine innere Stimme, meinen inneren Rebellen quasi tanzen. Der sagt, das ist doch total überreguliert, so ein bürokratischer Blödsinn. Wie sind da eure Erfahrungen? Wie sehr hilft es Leuten vielleicht wirklich? Oder wie oft erlebt ihr auch, dass Leute da anfangen, ja, so die Freigeister vielleicht eher so ein bisschen auf die Barrikaden gehen?

00:08:50: Also, ich glaube, das sind tatsächlich viele, die haben genau die gleiche innere Stimme wie du beschreibst. Aber wenn es um die Implementierung und wie wir es hinbekommen geht, dann stoßen die halt an, ich sag mal, ein weiteres Element außerhalb deiner Organisation, nämlich eine Regierung oder Regularien letztendlich, die halt auch gewisse Auflagen an deine Organisation stellt und wie du das hinbekommen solltest. Und das ist die Kunst. (lacht) Und das unterscheidet unserer Ansicht nach, wo eignet sich SAFe einzusetzen und wo nicht.

00:09:38: Könnte man denn umgedreht sagen... Also, ich drehe es jetzt mal um und sage, andere Rahmenwerke lassen einem viel mehr Raum zu lernen. Also vielleicht die Dinge für sich selber zu erkennen, die SAFe so ein bisschen im Sinne einer Übermutti schon vorgedacht hat. (lacht) Ja, wo SAFe sagt, so sollte die Welt... also, so sollte es irgendwie alles für dich funktionieren. Könnte man damit sagen, SAFe verhindert eigentlich Lernen und diese empirische Erfahrung, auf die auch Scrum ja sehr stark setzt und sagt, ey, guck dir an, was rauskommt und passt dein Vorgehen immer wieder an?

00:10:16: Ja. Nein. Jein. (lacht) Also, ich denke mir, du hast es eben schon ganz schön beschrieben, also Lernen / Continuous Learning braucht ja Zeit. Also, ich brauche ja im Grunde genommen bei jedem pragmatischen Ansatz, den ich versuche, nehmen wir einfach Scrum oder Scrum@Scale und ich wende das an. Aufgrund der Freiheiten, die ich da habe, an der Stelle und mit dem Mindset, mich dann halt auch kontinuierlich weiterzuentwickeln, ist das natürlich gut. Aber auf der anderen Seite, das braucht natürlich Zeit. Und das habe ich bei SAFe mit der Übermutti quasi an der Stelle, die halt schon einen etwas klareren Rahmen da gibt, habe ich, glaube ich, den spürbaren Erfolg, dass das mit diesen Regeln entsprechend auch schneller gehen kann. Was aber nicht heißt, dass ich mich natürlich nicht anpassen sollte und halt aus meinen Fehlern letzten Endes auch lerne. Also, es muss ja nicht heißen, dass so wie wenn ich dogmatisch SAFe einsetze, dass das dann auch auf jeden Fall zu 100 % funktioniert. Wir müssen Kulturen berücksichtigen. Das ist auch ein spannendes Thema dabei, wo ich halt auch noch nicht... Also, da habe ich halt auch in einem internationalen Konzern, die SAFe eingesetzt haben, so meine Schwierigkeiten erlebt. Also, da ging es halt um Mitarbeiter, die aus Indien kamen oder Externe, die aus Indien kamen, unterschiedliche Kasten usw., die dann eine Rolle spielen, wo wir dann mit der Rollenverantwortlichkeit dann ein Riesenthema haben. Wenn der Product Owner zum Beispiel aus einer niedrigeren Kaste kommt als der Developer, dann haben wir ein Riesenthema und solche Geschichten. Und das sind natürlich auch alles Dinge, die sollten letzten Endes halt auch dort Einzug finden. Und da gibt SAFe ja auch die Zeit unter anderem im Rahmen von diesem Inspect and Adapt, also diese Iteration und Planning Week, wo auch das PI Planning stattfindet, da ist ja ganz konkret halt auch ein Tag oder ein halber Tag dafür vorgesehen, dass man sich letzten Endes kontinuierlich auch weiter fortbildet in den Schwerpunkten, wo man gerade dran arbeitet.

00:12:26: Ja, ich würde so wie Kai sagt, jein. (lacht) Einerseits dadurch, dass das Framework an sich, wenn man alles liest, schon einiges an Hand und Fuß hat. Das ist echt durchdacht und da ist an einigen Sachen etwas dran. Einerseits ist dadurch etwas an Lernen verhindert. Allerdings gleichzeitig, wenn man es eben pragmatisch angeht und auch wirklich... Ich meine, auf den ersten Blick steht unten rechts Continuous Learning Culture. Und wenn man es wirklich einhält und nicht dogmatisch vorgeht, dann ist da trotzdem ein gewisser Raum für Interpretation vorhanden, wo man sagen kann, ja, dann machen wir es in unserer Organisation so, wie wir es benötigen. Wir müssen nicht unbedingt ein Dreigestirn des ARTs haben mit Release Train Engineer, Product Manager und Systemarchitekt, sondern wir werden gegebenenfalls durch zwei Rollen zusammengefasst in einer Person, weil das diese Person ausüben kann aufgrund seiner Erfahrung zum Beispiel.

00:13:37: Auch damit würdet ihr mich erreichen, dann zu sagen, ab einer gewissen Größe einer Organisation, die vielleicht auch noch sehr heterogen ist vom nicht nur fachlichen, vielleicht sogar auch kulturellen Background, aber auch - wenn man mal so ein Buzzword einführen will - so was agiles Mindset angeht, habe ich natürlich mit einem Vorgehen wie SAFe oder mit so einem Modell deutlich schnellere Erfolge und kann so mal die ein oder andere Abkürzung nehmen. Und jetzt mache ich mal eine Metapher, die vielleicht hinkt, aber mal gucken, wie weit sie uns trägt und funktioniert. Es ist also ein bisschen wie wenn ich einem kleinen Kind Fahrradfahren beibringe, da kann ich ihm Stützräder dranschrauben. Und dann irgendwann nehme ich die ab und dann... Oder passiert es dann, dass sie eigentlich dann immer wieder mit Stützrädern weiterfahren? Und die Frage, die ich daraus ableite, Continuous Learning als Slogan auf dem Poster, super! Haken dran. Ja, genauso wie Creating Value. Kaufen wir alles. Wollen wir alle alles haben. Die Frage ist, brechen die Leute dann auch wirklich, also jetzt wirklich einen Ausbruch aus diesen Routinen und Strukturen, die sie vorgibt? Passiert es oder ist es dann relativ schnell so ein goldener Käfig und diese wirkliche, ich sag jetzt mal, wirklich agile Entwicklung in Anführungszeichen, die findet dann gar nicht statt? Also wie sehr ist der Rahmen, den SAFe setzt, dann irgendwann vielleicht auch so eine Art goldener Käfig?

00:15:05: So in meiner Erfahrung war es schon fast so, wie du es beschreibst. Und um bei der Metapher zu bleiben, finde ich echt gut, weil ich weiß, ich habe jetzt junge Kinder und da hat man neulich im letzten Jahrzehnt gelernt, okay, man macht es doch nicht mit den Stützrädern und es gibt Laufrad und dann lernen die schneller das Gleichgewicht zu halten. Und ich glaube, es ist tatsächlich genauso. Das hängt ein bisschen davon ab, in welchem Alter ist jetzt das Kind oder die Person, die jetzt Fahrradfahren lernt? Und wenn man organisch wächst, dann würde ich sagen, dann eignet sich SAFe eigentlich gar nicht. Allerdings, wenn du eigentlich schon Erwachsene bist und noch gar nicht Fahrradfahren gelernt hast und jetzt aber anfängst, wenn du gar nicht die Gelegenheit hattest, das in einer organischen Art und Weise zu tun, dann bräuchtest du vielleicht Stützräder. Und genau so ist auch die Erfahrung, dass die Unternehmen, die es seit jeher praktizieren, die kommen halt von der anderen Richtung. Sie sind eigentlich schon groß und haben eigentlich gewisse Prozesse, Strukturen, alles und müssen sich halt irgendwie doch in die Agilität transformieren. Und dann kann SAFe doch ganz schön hilfreich sein.

00:16:33: Was ist denn? Wie sind denn eure Erfahrungen? Bei welchen Firmen schlägt SAFe aufgrund der mit all den Vor- und Nachteilen, die wir jetzt bis hierhin schon mal haben, besonders gut an? Also, seht ihr da irgendwelche Muster, dass es vielleicht besser funktioniert in Organisationen, die XY oder in Branchen, die eher ABC machen?

00:16:56: Ja, total. Also eine Sache ist eher die Größe und eben ihre Geschichte. Ich habe ein recht interessantes Interview letztens gesehen zwischen Tucker Carlson und Pavel Durov. Das ist - für die, die ihn vielleicht nicht kennen - der Gründer von der Instant Messaging App Telegram. Und in diesem Interview geht er auf ein paar Unterschiede zwischen Telegram und Twitter (heute X) ein. Und Pavel hat Telegram 2013, meine ich, gegründet und die haben jetzt heute knapp 1 Milliarde Nutzer und sind aber insgesamt heute 20 Personen. Und auf das hat er es hochskaliert. Und der Pavel auch als Gründer ist der alleinige Produktmanager. Und alle anderen sind Softwareentwickler. So, und jetzt, ich sag mal, das ist ein Beweis, dass man eskalieren kann, ohne dass SAFe oder Ähnliches irgendwie notwendig sein wird und trotzdem ein Produkt entsteht. Twitter wiederum oder X, vielleicht ein bisschen älter, hatte zu Höchstzeiten irgendwie über 7000 Mitarbeiter. Und jetzt, nachdem Elon da war - warum jetzt so viele gegangen sind, das ist eine andere Frage - jetzt sind es um die 1000 Mitarbeiter. Und zwar würde auch Elon wahrscheinlich nie SAFe einsetzen, aber je nach Struktur, wäre aber vielleicht SAFe ein naheliegender Ansatz für Twitter. Aber für uns ist wirklich, also, in unserer Erfahrung ein wesentlicher Faktor einerseits die Regularien, die ich schon angesprochen habe, aber auch insgesamt Hardware. Wir haben viele Kunden in Automotive und Maschinenbau und Deutschland ist halt echt, merken wir, von der Industrie geprägt. Und das bedeutet halt Hardware. Und in der Mehrheit der Fälle liefert halt SAFe vergleichsweise schnelle Ergebnisse. Wenn es darum geht, Scrum oder agile Teams insgesamt in eine klassische Matrixorganisation zu integrieren. Da reichen mir halt die Hände und Füße nicht, zu sagen, wie oft das schon mal der Fall war und echt vergleichsweise gut und schnell geklappt hat.

00:19:32: Und wenn tatsächlich dann diese Unternehmen dann SAFe nutzen, gerade dann halt diese hardwarelastigen Unternehmen, stellt man auch verhältnismäßig schnell fest, was noch nicht richtig implementiert wurde bzw. wo die Herausforderung ist. Und da merkt man, also das ist meine Erfahrung, da wo ich es gesehen habe, da entstehen dann die Probleme, wenn es dann so in die Lieferung geht der Produkte, also in die Umsetzung der Produkte. Sprich wenn dann halt nicht mehr über reine Development Value Streams gesprochen wird, sondern da kommen jetzt halt, da kommt jetzt der operative Part dazu und die müssen halt an einem Strang ziehen. Die müssen sich letzten Endes crossfunktional aufstellen, sodass tatsächlich dann halt die Entwicklung autark passieren kann und dann auch letzten Endes dann in die Produktion übergehen kann. Und das sind halt die Herausforderungen, wo wir sehen, das funktioniert in der Software schon echt gut. Aber tatsächlich halt bei der Entwicklung von physikalischen Produkten ist das noch immer ein Riesenthema.

00:20:38: Es ist auch in sich eine Hürde genug, sage ich mal, Hardware agil zu entwickeln. Kann man sich natürlich vorstellen. Wie wir es aus globalen weiten Märkten... Jetzt noch die Lieferketten, die sich im Laufe Jahrzehnten aufgebaut haben.

00:20:54: Absolut, ja.

00:20:55: Wie soll man das jetzt agil entwickeln? Wie soll man am Ende einer Iteration, eine Software ist eine Sache, aber das ganze Produkt als System zu liefern und das ist halt das, was wir häufig sehen. Das erlaubt SAFe, klassisches Projektmanagement obendrüber zu stülpen.

00:21:17: Ich als SAFe SPC müsste dir jetzt sagen, ja, da haben wir natürlich auch eine Lösung für! Also, da nutzt du halt einfach Minimum Viable Product oder Crappy Product, das mithilfe von Stereolithographie teilen usw. und so fort. Dann kriegst du dann halt auch möglichst iterativ schon erste lieferbare Ergebnisse. Aber sind wir doch ehrlich, das ist doch Bullshit, also... (lacht)

00:21:41: Da spricht man plötzlich dann von vertikaler Integration. Also, mache ich doch Make anstatt Buy und das ist in sich eine Disruption von Organisation genug.

00:21:54: Wie würde denn so ein, ich weiß nicht, wie gut uns das sprachlich gelingt, aber wir probieren es mal... Finde ich auch interessant, diesen Ansatz zu sagen, es ist aufgrund einfach des bestehenden Businessmodells und vielleicht sogar auch der Organisation, ist SAFe dann ein besonders guter Match, wenn ich eher hardwarelastige Companies habe. Also, ein Hardwareanteil, ein Softwareanteil, wenn wir das jetzt mal beides zusammenbringen. Wie würde sich das denn unter einem gemeinsamen SAFe-Dach vertragen? Also gibt es dann, wenn ich jetzt so ganz unten anfange und so mit dem auch typischen agilen Slogan "Wir brauchen crossfunktionale Teams"... Oder habe ich dann trotzdem immer noch Hardware unter dem SAFe-Dach? Es gibt eine Hardware Organisation, es gibt eine Software Organisation und die führe ich in SAFe zusammen oder wie kann ich mir das vorstellen?

00:22:52: Ja, also SAFe unterstreicht ja auch das ganze Thema Systems Thinking. Also, es wird häufiger durch Systems Thinking dort geregelt. Aber wer, ich sage mal, im klassischen Ingenieurwesen unterwegs war, kennt das Systems Engineering. Und da wird ja immer das System in Hardware / Mechanik unterschieden zwischen wirklich mechanischen Teilen und elektronisch oder elektrischen Teilen und Software. Und Software ist vielleicht geklärt für sich, ja? Aber Hardware und Mechanik... Es ist immer die Integration. Wie integriere ich jetzt das gemeinsam? Und wenn ich Abhängigkeiten außerhalb meiner Organisation durch eine Lieferkette, weil ich halt nicht alles selber herstelle, muss man gucken, wie dieser Verbund-Release zusammenkommt. Und da muss halt meine ganze Lieferkette eigentlich komplett mitspielen, um das eigentlich in einer Timebox stattfinden zu lassen und nicht klassisch requirements-getrieben.

00:24:02: Wie sind denn eure Erfahrungen? Also, oft werden ja solche Entscheidungen.. Was sind eure Erfahrungen? Warum entscheiden sich Unternehmen... Jetzt nehmen wir gerne mal die, weil ich finde das, glaube ich, so als mentales Modell ganz gut, haben eine gewisse Größe. Denn die Größe bedingt, dass es eine gewisse Heterogenität vielleicht hat, sowohl kulturell, fachlich. Und ich habe es eher mit dem Unternehmen zu tun, das ein Hardwareanteil hat. Wie kommen solche Unternehmen dann zu einer Entscheidung oder was sind für die überhaupt Trigger, zu sagen Leute, wir sind gar nicht mehr lieferfähig, wir sind nicht mehr wettbewerbsfähig. Oder was sind genau die Schmerzpunkte, die dann dazu führen, entweder sehr offen zu euch zu kommen oder vielleicht sogar eine Entscheidung herbeizuführen, wir setzen SAFe ein. Und mit was kommen die Kunden da zu euch? Eher sehr offen und sagen, folgende Probleme... Sagt uns mal, was wir tun könnten. Oder kommen die eher zu euch und sagen, die Entscheidung für SAFe ist gefallen. Wir wissen zwar nicht, was es ist, aber hört sich gut an, wir wollen das machen.

00:25:07: Also, in den meisten Fällen trifft eher das zweite zu. Wir haben es aber jetzt halt auch schon andersrum erlebt, dass die... oder anders, wir werden in bestimmte Rollen oftmals beauftragt, zum Beispiel als Release Train Engineer oder als Scrum Master und oftmals befinden die sich gerade erst in so einem Findungsstatus. Die haben da halt vielleicht eine Beratung gehabt, die dann empfohlen hat, einen ersten Agile Release Train aufzusetzen. Die haben auch vielleicht schon die ersten Teams organisiert usw und so fort. Die haben aber noch gar nicht gestartet. Die wollen jetzt erst halt konkret mit der ersten Inspect und Adapt starten mit allem was dazugehört, Trainings aufsetzen etc. pp. Dann stellt sich oftmals die Frage, okay, warum? Was ist denn jetzt der Schwerpunkt? Warum wollt ihr jetzt skalieren? Warum habt ihr euch jetzt für SAFe entschieden? Und oftmals stellt sich dann heraus, okay, wir haben an einer ganz anderen Stelle ein Problem und wir sollten erstmal über sowas wie ein Mission Statement sprechen und so, bevor wir uns darüber unterhalten, wie wir letzten Endes den alten Bums... Weil das ist ja dann oftmals was gemacht wird, ne? Ich ich will mich im Endeffekt halt nicht großartig verändern, was meine eigentliche Produktstruktur angeht. Aber ich muss es anders organisieren, weil ich einfach viel zu lahm geworden bin. Und da hilft aber dann halt meiner Meinung / nach meiner Erfahrung definitiv nicht einfach das Aufsetzen von irgendeinem gearteten Framework, sondern sich dann erstmal noch mal die Frage zu stellen, gucken wir uns den Berg noch mal - einen Schritt zurück machen - schauen uns den Berg noch mal ganz an. Und dann überlegen wir uns mal, wo soll die Reise überhaupt hingehen? Und da SAFe ja natürlich auch ganz stark als Governance und strategische Entscheidungen miteinbezieht, empfiehlt sich das natürlich dann oft.

00:26:59: Aber letzten Endes ist das ist oftmals unklar oder wird mit der Zeit dann auch sogar unklar. Also ich habe es halt auch erlebt bei einem Unternehmen, die mit round about 5.000 Leuten in dieser Transformation steckten und nach anderthalb Jahren nicht das Ergebnis erhalten haben, was sie sich eigentlich versprochen haben. Haben sich dann aber auch tatsächlich das in die Hand genommen und haben sich noch mal diese Grundfragen gestellt. Kostet natürlich auch wieder Zeit und viel Geld. Letzten Endes hat es aber dazu geführt, dass sie dann halt ihr eigentliches Produktziel noch mal deutlich verfeinert haben und auch noch mal einen anderen Markt dann letzten Endes für sich entdeckt haben, wo es dann halt besser gegriffen hat.

00:27:42: Wie würdet ihr denn die Reife einer Entscheidung, also, Entscheidung in dem Fall pro SAFe, vielleicht ein bisschen abstrakter gesagt, es ist ja ein agiles Rahmenwerk. Jetzt könnte man ja sagen, in so einem Design Thinking Verständnis, so ein Rahmenwerk ist ja eigentlich nur eine Lösung. Aber welches Problem wollen wir eigentlich gerade lösen? Das geht ja so ein bisschen in die Richtung, was du gerade ansprichst. Haben wir überhaupt ein klares Bild? Und das erfordert ja teilweise - es schließt sich so ein bisschen der Kreis zu SAFe - ein extrem gutes systemisches Verständnis, welches Problem haben wir denn hier eigentlich gerade, das wir jetzt versuchen zu lösen? Also, was ich oft sehe - ich beantworte die Frage mal selber, die ich jetzt euch gleich stelle - dass Entscheider sehr schnell auf Lösungen springen. Aber das Problem eigentlich gar nicht genau verstanden haben. Wenn ihr das mal so auf einer Skala 1 bis 10 bewerten würdet und sagen, ja, zehn ist wirklich, die haben das Problem wirklich... also den Nagel auf den Kopf getroffen. Und SAFe ist auch irgendwie eine gute Lösung dafür. Versus, da hat irgendjemand irgendwas entschieden. Und eigentlich ist gar nicht klar, welches Problem wir gerade versuchen zu lösen. Deswegen könnte es passieren, dass Klammer auf, Klammer zu, dass 5000 Leute nach anderthalb Jahren eigentlich wieder eine Rolle rückwärts machen und sich die Fragen stellen, die wir uns eigentlich vor zwei Jahren hätten stellen sollen. Das wäre dann eher eine Eins. Also, wo bewegt ihr euch jetzt so rein gefühlt mal auf dieser Skala 1 bis 10.

00:29:17: Drei.

00:29:19: Ich wollte genau die gleiche Zahl sagen. (lacht) Genau. Also häufig, wenn wir in die Diskussion mit unseren Kunden gehen, sprechen wir über bestimmte Probleme, die sie vorfinden, wo auch etwas daran ist, die wir auch angehen. Aber natürlich stellen wir im Laufe der Zeit fest... Kennst du die Methodik Five why? Bestimmt. Wenn du ein bisschen tiefer denkst, sind es doch andere, ganz andere Probleme. Letztendlich die, die existieren, die wir irgendwie ansprechen müssen.

00:29:56: Jetzt hätte ich noch mal eine weitere weiterführende Frage. Jetzt könnte man ja sagen... Oder Annahme... Was ich auch mitunter erlebe. Diese, nennen wir sie mal, fehlende Klarheit über das, was eigentlich das Problem ist, hat ja auch mitunter sehr oft damit zu tun, dass ich eigentlich gar nicht verstanden habe, was meine Strategie ist. Wohin will ich? Also schließt sich ja so ein bisschen der Kreis. Eine Strategie ist ja auch nur eine Antwort auf meine Herausforderung, Probleme, Trends, die ich am Markt irgendwie sehe und erkenne. Das heißt, wenn das nicht klar ist, ist die Wahrscheinlichkeit, dass das, was in meinem Strategie Deck drin steht, dass es da gar keinen Zusammenhang gibt. Also wie sehr würdet ihr mir zustimmen oder auch dem widersprechen, zu sagen, dass eine gute SAFe-Implementierung nur dann wirklich wirksam ist, wenn ich eine extrem gute Klarheit in der Strategie habe?

00:30:50: Total!

00:30:51: Total!

00:30:52: Das ist auch eine wesentliche Komponente, wann SAFe Sinn macht, ist, wenn dieses Geschäftsmodell, wie du es strategisch sozusagen beobachtest und handhabst, wie langfristig ist das Modell? Wie ist die Lebensdauer davon? Wenn sie länger ist, längerfristig ist, dann umso mehr macht es auch Sinn. Zwar sagt auch SAFe, "Reorganise!", also neu organisieren, wenn ein neues Produkt oder das Geschäftsmodell irgendwie verändert wird, aber in den Größenordnungen von SAFe und die Anzahl an Beteiligten entsprechend, um so größer die Herausforderung.

00:31:40: Ich würde dem Ganzen auch tatsächlich sogar noch einen draufsetzen. Ich hatte das letztens, da wurde ich von unserem Marketingkollegen gefragt. Der brauchte eine passende Metapher zu einem ähnlichen Thema. Und da hatte ich gesagt, eine Strategie ohne Vision ist im Grunde genommen wie ein Auto ohne Motor. Und deswegen, also, das ist tatsächlich auch das, was wir halt dann in Verbindung damit vorfinden. Also, Strategie gibt es vielleicht manchmal, aber ob jetzt wirklich die Vision, die dahinter steckt, überhaupt so passt noch. Das ist dann auch tatsächlich dann halt eine Situation, die oftmals auftritt. Dass dann Vision passt gar nicht mehr zu der Strategie und letzten Endes alles weitere, was darauf aufbaut, bringt halt eine Menge Herausforderungen mit sich.

00:32:25: Ja und dann stehst du da, hast was im wahrsten Sinne des Wortes, also, ich bleib bei dem Beispiel, was du eben genannt hast, 5000 Leute, hast die Leute kirre gemacht, hast das Ding angeschoben und dann ist halt die Frage jetzt wieder die Metapher von vorhin, Fahrradfahren mit Stützrädern. Also, die Frage ist ja, wie agil bist du dann wirklich im Sinne von, okay, wir sind eigentlich in einer laufenden Anpassung. Das könnte man ja sagen. Braucht man vielleicht ja als organisatorische Kompetenz. Wohingegen vielleicht ja auch immer noch allgemein das Verständnis da ist, so dieses, ich glaub von Kurt Lewin stammt dieses Organisationsmodell, dass du es quasi immer auf aufweicht, in eine neue Struktur bringst und dann wieder einfrierst und dann damit weiter machst, statt in, wirklich also auch auf einer organisatorischen strategischen Ebene, in einem permanenten Inspect and Adapt drin bist. Weil sich halt nun mal die Welt sehr, sehr schnell dreht und laufend verändert. Gut. Vielleicht noch zum Abschluss. Was sagt ihr? Oder was würdet ihr denn empfehlen, wenn ich in der Situation bin, dass ich mich, dass ich SAFe in die engere Auswahl gezogen habe und / oder - scheint ja mitunter auch so zu sein, dass an Stellen darüber entschieden wird, wo eigentlich gar nicht genau verstanden wird, was es eigentlich ist, aber es hört sich gut an - wie gehe ich am besten damit um? Was sind so ganz pragmatische Do's und Don'ts auf dem Weg für eine Entscheidung zu SAFe oder in die Arbeit mit SAFe?

00:33:59: Ja, also wir bei der Prosma - ganz unabhängig von SAFe - schon lange sprechen häufig von einer sogenannten Produktorganisation. Also einer Organisation, in der sich alles um ein Produkt organisiert. Das ist das zehnte SAFe Prinzip "Organise around Value" , hatte ich vorhin angesprochen. Sich um Value zu organisieren. Und ein Produkt ist ja ein Vehikel, um Wert zu liefern am Ende des Tages. Also, das ist auch der Punkt, das steht auch in der Implementation Roadmap, der am häufigsten umgangen wird. Und letztendlich auch der Zuschnitt von Agile Release Trains gegebenenfalls Trends gibt. Du kennst auch bestimmt Conway's Law. Bzw. First Conway's Law. Das ist genau dieses Thema an der Stelle. Also, das sind auf jeden Fall ein paar Do's. Ich finde interessant, das kennen nicht so viele, obwohl sie sich mit dem beschäftigen, Weighted Shortest Job First Ansatz zur Priorisierung von Backlog. Was nichts anderes ist im Prinzip wie ein Scrum auf Scrum Basis. Bank for your Buck gibt es zumindest im amerikanischen Kontext sozusagen. Wenn jemand... Also, Story Points ist das Eine, wenn man sogar auch noch die Value Points bei User Stories schätzt und Wertmaximierung, also den größten Wert für den wenigsten Einsatz oder Komplexität eigentlich, dann ergibt sich meine Priorisierung und das ist nicht nur auf Scrum Ebene, letztendlich auf der ART Ebene der Ansatz zur Priorisierung des Beitrags und Features.

00:35:46: Und was vor allem halt eine ganz klare Empfehlung ist, weil das oftmals auch oder das wird von SAFe nicht so stark berücksichtigt ist die Einbindung von HR, People Development, People and Culture. Diese ganzen Bereiche, die werden zwar in den Operational Value Streams miteinbezogen, aber viel zu wenig. Und gerade weil wir halt - du hattest das ganz zu Beginn halt und wir haben immer wieder über den Continuous Improvement oder Continuous Learning Ansatz gesprochen - und da braucht es halt einfach da an der Stelle halt auch explizit Menschen, die sich darum kümmern, dass da halt auch das Rädchen am Laufen bleibt. Und das wird tatsächlich halt nach meiner Erfahrung immer herunterpriorisiert.

00:36:36: Was wären so typische Fallen, in die ich tapsen kann?

00:36:39: Also, das ist für uns meistens... Es gibt ja die ART Ebene und wie gesagt darüber die Solution Ebene, denn da wird dann... Also, eine ART ist um die 50 bis 125 Personen für maximal fünf Teams und Solution ist ein Zusammenschluss von mehreren ARTs (Agil Release Trains). Und da wird es meistens richtig interessant. (lacht) Aber auch bei der Wertstromanalyse würden wir eher vermeiden. Meistens auf der ART Ebene funktioniert es halbwegs gut, sodass unsere Erfahrung auch echt positiv an der Stelle ist. Aber bei der Solution wird es schwierig.

00:37:21: Kannst du das noch mal erklären? Das habe ich nicht verstanden. Also, was sollte ich konkret vermeiden an der Stelle?

00:37:27: Solutions.

00:37:29: Okay.

00:37:31: Genau. Mehrmals Gedanken machen, bevor Solutions gegründet werden.

00:37:36: Ja.

00:37:38: Aber das hat natürlich auch einen Grund. Und das wäre so das nächste, die nächste Falle, wo du reintappen könntest. Das ist im Grunde genommen, wir hatten das eben mit dem Wording von irgendwelchen Rollenbezeichnungen oder sonst wie. Ganz genau gucken, welche Verantwortung hinter den bezeichneten Rollen steht. Weil darum geht es ja. Es geht ja darum, dass wir - nennen wir ihn mal jetzt Solution Manager oder Solution Architect - was muss denn der machen? Und wenn ich da halt - das ist das, was wir halt oftmals feststellen, weswegen das dann auch oftmals an der Stelle dann halt scheitert ist, dass im Endeffekt die Leute, die da drin sitzen, diesen Hut aufgesetzt bekommen haben, weil sie schon in der alten Welt, sage ich mal, in einer ähnlichen Rolle unterwegs waren und wenig fokussiert jetzt auf diese Neuausrichtung, was ihre Verantwortung angeht arbeiten und da entstehen dann halt so diese Schwierigkeiten. Deswegen hilft es da dann halt auch immer tatsächlich, sich entweder halt an das Rahmenwerk mit den entsprechenden Rollen und Verantwortlichkeiten zu orientieren oder zumindest sich hinzusetzen und dann halt noch mal das niederzuschreiben. Unser Business Owner muss dieses und jenes können und nicht das, was noch da vorher gemacht wurde. Thema disziplinarische und fachliche Führung ist auch so eine Sache, die da mit reinspielt. Ja, genau. Also das wäre halt tatsächlich auch noch mal so ein Punkt.

00:39:04: Oder ein weiterer Don't wäre für mich das Thema Dual Operating System. Also, das ist, um es kurz zu halten, nichts anderes wie eine Matrix Organisation. Und ich glaube, wir sind uns einig, seien wir ehrlich, unsere Erfahrung hat gezeigt, dass es eigentlich niemand braucht. Also, SAFe sorgt ja für die zusätzliche Stabilität usw., aber das hat eigentlich zu einer Richtungsabhängigkeit, also da, wo Menschen in zu vielen Richtungen gezogen an der Stelle durch dieses Dual Operating System oder Matrixorganisation. Und diese Stabilität, die braucht eigentlich niemand. Dass es eher dazu dient, eher die Führungskräfte, die in diesen bestehenden Positionen sind, an Bord zu bekommen.

00:39:54: Was ich interessant finde, dass sowohl in den Do's als auch Don'ts findet sich ja im Kern die Frage, wie denke ich eigentlich über mein Produkt und was ist eigentlich mein Produkt? Und wo gehe ich dann auf eine Solution Ebene, was ja vielleicht auch wiederum nur ein weiteres Wort ist, die ich nur schwer beantworten kann, wenn ich wirklich sage, wie definiere ich mein Produkt? Weil das ist ja - das erlebe ich sehr oft - das hört sich so super trivial an und dann fängst du an, darüber zu sprechen und dann sagst du - noch schlimmer - schreib es doch mal auf. Dann wird es auf einmal schwer. Also für Berater ein gefundenes Fressen, weil du kommst mit einer Frage und hast zwei Tage Arbeit mit zehn Führungskräften. Aber diesen, ja, einfachen Fragen nachzugehen und zu sagen, was genau ist mein Produkt und wie definiere ich das und wie lange halte ich es auch aus - nur mal so als Gedankenübung - diese Durchgängigkeit. Weil wir biegen ja immer wieder ab und da wollen wir noch eine Abteilung. Weil wir einfach immer wieder aus diesem sehr abgeteilten, funktionalen Denken, wo es nur um Effizienz, um Optimierung, lokale Optimierung und gar nicht um Crossfunktionalität, gemeinsames Lernen, Value Creation, das taucht da ja alles gar nicht auf.

00:41:18: Das ist mir eben nur aufgefallen, weil ich die Dinge so nebeneinander geschrieben habe, dass das Du da genau so eine Einflugshöhe hast, wo du sagen kannst, erklär mal, was dein Produkt ist und fang nicht an, zu früh auf diesen, ja, man könnte ja auch weiterführend sagen, fang nicht an, zu früh in der Methode zu denken, sondern rede erstmal über Inhalt. Geh da mal so ein paar Gedankenübungen einfach durch, bevor direkt die Bagger anrollen, um 5.000 Leute in irgendwelchen komischen Rollen schulen lässt und 37 Berater rumspringen hast. Die freuen sich ja aber. Ich würde mal ein kurzes Schleifchen dran machen und zusammenfassen und dann mal schauen, ob ich was Wichtiges vergessen habe. Was ich vor allem gehört habe und auch ganz klar heute gelernt habe, weil das hätte ich vor einer Stunde noch nicht so gesehen, zu sagen, wann ist SAFe denn gut geeignet unter der Voraussetzung, dass ich eine gewisse Größe in meiner Organisation habe, vielleicht auch eine gewisse Komplexität, Heterogenität, Vielfalt in Verbindung mit der Aussicht auf schnellen Erfolg? Ja, dann bringt mir eine eine SAFe-Implementierung mit einem sehr klaren, gut dokumentierten Rahmenwerk einen, man könnte sagen, so ein Head Start, eine einfache Rampe, auf der ich schon mal deutlich höher abspringen kann, als wenn ich sage, jetzt vertraue ich mal drauf, dass 5.000 Leute lernen irgendwie, wie agiles Arbeiten wirklich funktioniert. Verstanden?

00:42:49: Dann ist es besonders geeignet für Unternehmen, die vielleicht - das bedingt sich ja gegenseitig so ein bisschen - vielleicht einen Hardwareanteil in ihrem Business haben, also wo es immer um Hardware, Software, elektronische Bauteile etc. geht. Und zum Abschluss Do's and Don'ts. Da habe ich mir notiert... Erstens ein ganz großes Do, dieses vom Produkt ausdenken, das produktzentrische Denken überhaupt mal zu durchlaufen. Vielleicht noch zweitens in Verbindung mit Weighted Shortest Job first. Also alles, was du genannt hast, findest du immer auch im dno Blog. Weighted Shortest Job First. So einfach auch mal als ein sehr methodisches Herangehen für eine gute Priorisierung. Man könnte ja sagen, es ist eigentlich Ausdruck von Strategie, dass ich auch weiß, was ich will. Das kann ich ja nicht nur auf einer Featureebene, sondern immer auf einer Portfolio, auf einer Company Ebene machen und sagen, was ist jetzt wirklich wichtig? Und dass ich, fand ich auch sehr interessant, ein drittes klares Do. Von Anfang an HR miteinbinde. Damit ich nicht nachher da stehe in der riesigen Transformation, organisatorisch, persönlich wie Führungskräfte, wie gehe ich mit Verantwortung, Delegation usw um und auf einmal da stehe und gar nicht mehr weiß, was hier eigentlich um mich herum passiert, weil die Leute nicht mehr mitkommen.

00:44:10: Auf der Don't Ebene. Lass es lieber sein, zu früh über Solutions zu sprechen, ohne zu verstehen, was eigentlich überhaupt mein Produkt ist, wie ich Dinge priorisieren will, was meine Strategie ist. Dass ich sehr klar, das fand ich auch gut, mal nicht nur sage, ich bin jetzt Release Train Engineer oder wie auch immer die Rolle heißt, sondern eher mal darüber spreche, was ist denn eigentlich die Verantwortung? Und bin ich in einer Position oder - da sind wir auch wieder beim Stichwort Einbindung von HR - habe ich hier die richtigen Leute auf der richtigen Rolle und denken die auch wirklich rollenbasiert und nicht stellenbasiert? Da stellst den an die Stelle und da steht er und bewegt sich nicht mehr weg. Und der dritte Punkt, wobei der auch sicher noch mal einen eigenen Podcast wert wäre, die Finger davon lassen von dualen Operating Systemen. Wobei ich glaube ich ein bisschen verstehe, woher du kommst, weil das, glaube ich, immer so eine leichte Ausfahrt sein kann, zu sagen, habe ich nicht genau verstanden, weiß ich gerade nicht, wie ich mit umgehen will - das machen wir dual! (lacht) Ja? Statt von vornherein zu sagen, nee, jetzt sind wir hier gerade an einem kritischen Punkt, lass uns das jetzt wirklich mal zu Ende denken. Habe ich was vergessen oder etwas, was wir unbedingt in diese Zusammenfassung noch aufnehmen sollten?

00:45:31: Naja, das passt schon. Ich finde, das passt schon ganz gut. Trifft es auch schon sehr gut. Es gibt natürlich noch ein paar andere Punkte, die aber - das haben wir jetzt halt auch noch mal kürzlich gesagt, also... SAFe ist ja keine Raketenwissenschaft für sich. Es bringt halt ziemlich viel Struktur und Prozesse mit sich, die einem helfen, gerade halt größeren Organisationen, wie du es eben zusammengefasst hast, das halt auch zu organisieren besser. Aber letzten Endes so Themen wie Servant Leadership oder Themen Technical Agility... Das sind halt ganz wichtige Attribute, die aber jetzt nicht in SAFe neu sind, die sowieso gelebt werden müssten. Gerade das Thema Leadership halt mit seinen ganzen Facetten.

00:46:17: Ja, sehr schön.

00:46:19: Aber ansonsten hast du es sehr gut zusammengefasst. Danke dafür.

00:46:22: Das freut mich. Habe ich anscheinend gut zugehört. Ich bedanke mich, dass ihr hier wart und freue mich auf eine Fortsetzung. Dankeschön.

00:46:29: Danke auch.

00:46:30: Dankeschön.

00:46:32: Schön, dass du bis zum Ende dabei warst. Wenn dir die Episode gefallen hat, dann freuen wir uns über deine Bewertung. Wenn du darüber hinaus Fragen, Anregungen für interessante Themen oder Gesprächspartner hast, dann besuchen uns gerne unter DNode Podcast. Bis zum nächsten Mal.