Martin: Wenn du als Agile Coach Kunden begegnest, die mit SAFe umgehen, welche Erfahrungen machst du da, was für Absichten haben die Kunden, wie nutzen die SAFe und wie bewertest du das?

Sylvius: Das Kunden-Klientel, das SAFe als Skalierungsmethodik einsetzt oder sich dafür interessiert oder überhaupt diese Begriffe verwendet, sind meiner Erfahrung nach hauptsächlich größere Firmen. Also sehr große Mittelständler, Konzerne. Ich komme aus einer anderen Richtung, und meine Vermutung im Hinblick auf das Muster wäre, dass es sich dabei fast immer um Organisationen handelt, die es gewohnt sind, sehr stark mit Strukturen zu arbeiten. Die Abteilungsstrukturen haben, die bestimmte Prozessvorgehen für Arbeitsweisen nutzen, bei denen Rollen und Zuständigkeiten wichtig sind oder die damit sozusagen gute Erfahrungen gemacht haben, dass sie solche Dinge einführen. Daher ist meine Vermutung, dass es hier auf den ersten Blick ein Match gibt. Also diese Klientel, die sehr stark mit Strukturen und Ähnlichem arbeitet, ist auch die Klientel, die aus irgendeinem Grund SAFe nutzt bzw. interessant findet.

Ich hatte früher einmal bei uns intern gesagt: SAFE, das ist so etwas wie Agile im Wasserfall-Mantel. Du kannst also dein sequentielles deterministisches Denken behalten, aber wir nennen das agil.

Ja, das ist zumindest der Eindruck, der dann vielleicht auf beiden Seiten entsteht, also bei den Kunden und vielleicht auch bei Coaches wie mir. Ehrlicherweise würde ich sagen, dass das wahrscheinlich nicht die Urspungsintention war, als Dean Leffingwell den Ansatz ins Leben gerufen hat. Und es gab ja auch andere Leute, die SAFe damals propagiert oder selbst trainiert haben. Zum Beispiel hat Jeff Sutherland das auch eine ganze Zeitlang kombiniert und quasi SAFe-Trainings als Ergänzung zu seinen eigenen Scrum-Trainings gegeben. Ich habe ihn einmal gefragt: Warum machst du das denn eigentlich Jeff? irgendwie wirkt das doch ein bisschen hölzern und unagil - SAFe als Methode... Er hat gesagt: Ja, es ist aber ein guter Start für die Leute. Es gibt ja quasi sowas wie eine Startkonfiguration. All die Dinge, die man eigentlich mit der Zeit erst lernt, die Dinge, die nicht so direkt in Scrum definiert sind, die man aber eigentlich kennen müsste, um Scrum gut nutzen zu können, die Dinge, die eigentlich nur der erfahrene Coach und Trainer kennt und sie dann den Kunden beibringt - das bringt SAFe in einer ähnlichen Art und Weise schon mit und bietet eine gewisse Sicherheit im Prozess und in den Rollen. Und deshalb hat Jeff Sutherland, bevor er dann sein eigenes Skalierungsmodell entwickelt hat, eben auch selber SAFe-Trainings gegeben. Das fand ich ganz spannend.

Das entspricht auch der Erfahrung, die wir gemacht haben - dass SAFe nämlich eine Art Brücke ist. Es gibt ja Kunden, wo du denkst: Freunde, das wird nichts mit euch; ihr seid so intransparent, ihr seid so hochpolitisch, ihr seid so hierarchisch aufgestellt; die ganzen Grundsatzfaktoren, die man für Scrum braucht, könnt ihr gar nicht leben... Und in so einer Umgebung habe ich das Gefühl, dass SAFe den Kunden hilft, eine Struktur zu erhalten, weil sie diese in ihrem bestehenden deterministischen Top-down-Denken so ausrollen können. Okay, das ist vielleicht erstmal nichts Positives, aber wenigstens ein Ansatz, denn in den einzelnen Teams soll ja nun Scrum gemacht werden und sie sollen dann auch eine Kaskadierung haben und Transparenz. Und es gibt dieses PI, das ja auch schon ganz viel Transparenz schafft und so weiter. Deshalb sehe ich das zumindest als Brücke in die richtige Richtung. Wie siehst du das?

Das ist eine positive Seite und das wird sicherlich auch eine Intention von Dean Leffingwell gewesen sein. Letztendlich hat er mit vielen Sachen ja nicht das Rad neu erfunden. Er hat es eigentlich nur zusammengestellt und in eine marktgerechte Verpackung gewickelt. Es gab und gibt ja viele, viele Leute, die so ein bisschen wie der Ochs vorm Berge stehen, wenn es um agiles Arbeiten und die ganzen Wahlmöglichkeiten geht: Welches agile Vorgehensmodell nutzen wir jetzt? Wie heißen denn nun die Rollen? Wie wollen wir es skalieren? Und so weiter.

Dean Leffingwell hat einfach diese Marktlücke gesehen und genutzt und hat gesagt, okay, ich konfektioniere ich euch das vor. Ich gebe euch quasi Templates und eine Übersicht an die Hand, die euch den Start ermöglicht. Ihr habt nicht mehr die Qual der Wahl, sondern auf Basis meiner Erfahrung und der Erfahrung anderer Personen, die an diesem Skalierungsmodell oder diesem SAFe-Ansatz mitgearbeitet haben, biete ich euch einen Vorschlag, wie man mit vielen Teams gemeinsam an einem Produkt arbeiten kann. Da steckt aber auch schon eine mögliche Kehrseite drin: Du nimmst dem Kunden das Denken und die eigene Erfahrung ab und damit auch den Erkenntnisgewinn. Es gehört ja zum Weg des agilen Arbeitens, dass du dir viele Dinge erarbeiten musst. Du musst manchmal auch Fehler machen, um zu verstehen, warum das ein Fehler war, damit du ihn in Zukunft nicht mehr machst.

Wenn dir aber diese Chance genommen wird, eigene Fehler zu begehen oder zu eigenen Erkenntnissen zu kommen, und wenn du nur etwas Vorkonfektioniertes nimmst, dann wirst du die eigentlichen Wirkprinzipien im Hintergrund und das Zusammenspiel der einzelnen Komponenten sehr wahrscheinlich nicht vollends durchdringen können. Und damit bist du auch immer limitiert. Du wirst also wahrscheinlich ohne fremde Hilfe oder ohne Erweiterungen dieses SAFe-Frameworks keine eigene Fortentwicklung durchführen können, weil du aus dir selbst heraus diese methodische Entwicklung nicht hinbekommst und immer auf dieses “SAFe-Konsortium” angewiesen bist. 

Mich erinnert das gerade an einen Arzt: Da stellt sich ein Herr vor, ziemlich beleibt, er hat Probleme mit den Knien, er fühlt sich schlapp und hat das Gefühl, dass das auf seine körperliche Konstellation zurückzuführen ist. Helfen Sie mir mal, Doktor! Und dann kannst du dem Herrn sagen: Gut, stellen Sie Ihre Ernährung um, machen Sie Sport, arbeiten Sie diszipliniert an diesen Dingen. Das ist eine langfristige und sehr nachhaltige Strategie. Dann geht der Patient nach Hause, macht das und es geht im super. Und ein Jahr später kommt er wieder in die Praxis, um sich für die Tipps zu bedanken: Jetzt gehe es ihm viel besser, er sieht auch schon ganz anders aus und er ist richtig gut drauf.

Dann gibt es aber auch viele Leute, die das nicht hinkriegen. Die gehen nicht nach Hause und fangen an, ihre Ernährung umzustellen und Sport zu treiben. Für diese Patienten wiederum hat die großartige Pharmaindustrie Pillen entwickelt. Wenn die Leute diese Pillen einwerfen, geht es ihnen vielleicht nicht super, aber möglicherweise steigt zumindest ihre Lebenserwartung um zehn oder fünfzehn Jahre, obwohl sie ihre Ernährung nicht umstellen und auch keinen Sport machen. Die Pillen machen keinen neugeborenen Menschen, aber sie bekämpfen ein paar Symptome, und das hat schon eine gewisse Wirkung. Es gibt sozusagen eine unglaublich große Industrie, die darauf basiert, dass Leute eigentlich wissen, was das Richtige ist, aber trotzdem nicht in der Lage sind, es zu machen.

Du hast mich da gerade auf eine Idee gebracht. Eigentlich hast du gerade vom agilen Placeboeffekt gesprochen. SAFe ist quasi das agile Placebo. Du denkst du bist agil, aber eigentlich bist du es nicht.

Ich hätte eher gesagt, es ist zumindest eine Medizin. Sie sorgt dafür, dass du erstmal keine Knie- und Rückenschmerzen hast. Du kannst dich an etwas festhalten. Das ist so strukturiert, wie du es kennst. Du kannst dein Gefühl behalten, von oben durchzuregieren, obwohl du weißt, dass es nicht das Richtige ist. Aber irgendwie bist du so in diesen Strukturen gefangen, dass du die Kontrolle noch behalten musst.

Darin steckt ja eine Metapher. Das finde ich spannend, weil mich das auf Ideen bringt, auf die ich bei so einem Gespräch normalerweise nicht gekommen wäre. Das ist der agile Placeboeffekt: Du nimmst also eine Pille und bist dann zumindest agiler als vorher, aber eigentlich hat der Arzt dich verarscht, weil in der Pille nur Zucker war. Und das andere ist der agile Jojo-Effekt. Das ist etwas, was man als Coach, der solche Organisationen länger betreut, sehr oft wahrnimmt: Anfänglich gibt es schon positive Effekte und auch eine Motivation der Leute. Und jetzt fangen wir an, agil zu arbeiten. Und die nächste Stufe könnte sein, dass wir uns von SAFe lösen und was eigenes machen. Aber meiner Erfahrung nach tritt dann oft wirklich eine Art Jojo-Effekt ein. Irgendwann schlägt das Imperium zurück. Das heißt: Die Entwicklung geht nicht mehr in eine agilere Richtung, sondern es gibt wieder eine Rückwärtsentwicklung.

Meine These ist, dass dieser Start mit den eher strukturierten, prozessorientierten Vorgehensweisen wie SAFe eine solche Entwicklung sogar fördern kann, weil man nie diese Initialzündung hatte, dass sich die Leute ein bisschen freier, ein bisschen eigenverantwortlicher mit ihrer Arbeitsweise auseinandersetzen mussten, weil ja alles vorkonfektioniert war.

Was mir bei deinem Beispiel noch eingefallen ist: Ich habe tatsächlich mal eine Weile für einen Hersteller von Nahrungsergänzungsmitteln gearbeitet. Die hatten auch tatsächlich ein Programm zur Gewichtsreduktion. Das war allerdings immer kombiniert. Zum einen war dieses Mittel verschreibungspflichtig. Du hast es also nur in der Apotheke bekommen und nur, wenn du zusammen mit einem Arzt eine Art Abnehmprogramm gestartet hast. Und hier war das Mittel nur ein Teil dieser Therapie. Das sind solche Eiweißkonzentrate als Mahlzeiten-Ersatz, und der Unterschied zu Anderen war, dass sie dir nicht nur das Mittel verkauft haben, was nebenbei der Denkfehler ist. Die haben von vornherein gesagt: Du musst auch Sport machen, sonst wird das nichts werden, und du musst auch auf deine Ernährung achten. Und in dieser Kombination war mein damaliger Arbeitgeber sehr erfolgreich. Ja, du kriegst von uns dieses Mittel, aber das ist nur eine Komponente, nur ein Baustein, und nur mit diesem Mittel allein wirst du auf Dauer keine wesentliche Gewichtsreduktion erreichen können.

Nehmen wir mal einen Kunden, ein großes Unternehmen. Mit SAFe und Agile haben die sich auf Führungsebene noch nicht groß beschäftigt, aber es gibt da ein paar agile Teams, die wirklich sehr erfolgreich sind - richtige Leuchttürme! Das ist cool, das soll auf die ganze Organisation skaliert werden, und das soll mit SAFe passieren, weil es der marktführende Ansatz ist. Aber nun sagst du: Probiert es aus, aber es wird nichts werden, weil es eigentlich nur ein Placebo ist. Was soll ich denn machen jetzt?

Ich will dir eine ehrliche Antwort geben, die zweigeteilt ist. Ich habe dir ja im Vorfeld, als wir den Termin vereinbart haben, schon geschrieben, was ich über SAFe denke beziehungsweise wie ich zu SAFe gekommen bin. Meine Meinung ist nicht nur kritisch oder ablehnend. Ich habe Dean Leffingwell bei einer Keynote auf den Scrum Days 2013 kennengelernt und gesehen, wo er SAFe meiner Erinnerung nach erstmals in Deutschland vorgestellt hat. Da war das Ganze auch noch relativ neu. Das war die Version 1.0 oder eins Punkt irgendwas - jedenfalls noch ganz am Anfang.

Ich fand das damals eigentlich eine geile Idee, und zwar aus einem ähnlichen Grund wie Jeff Sutherland: Weil es eine Lücke schließt, weil es Zusatzinformationen gibt, die viele Firmen - gerade Großfirmen - sich ansonsten aus irgendeinem Grund nicht selbst zusammengesucht haben. SAFe gibt dir eine Art Starterpaket - nicht nur zu Scrum, sondern auch zum Umfeld: Wie kann die Zusammenarbeit mit andere Leuten funktionieren? Wie erstellt man eigentlich so ein Portfolio? Wie sieht ein Backlog-Prozess aus? Wie arbeitet man mit mehreren Teams zusammen? Scrum of Scrums war damals ja nicht wirklich eine gute Alternative, wenn du mit mehreren Teams zusammenarbeiten wolltest.

Insofern war meine Sicht auf SAFe erstmal positiv, und selbst jetzt, ein paar Jahre später, würde ich sagen, dass da eigentlich vieles drinsteckt, was ich sinnvoll und nicht per se schlecht finde. Insofern kann ich verstehen, dass ihr diesen Menschen mit eurer Agile Hive-Software etwas an die Hand geben und sie unterstützen wollt. Aber jetzt kommt die Krux - hinter der aber ein allgemeines Problem steckt, das meiner Erfahrung nach tatsächlich sehr oft bei eher größeren Firmen vorkommt. Die treiben Cherrypicking.

Die machen gar kein richtiges SAFe.

Richtig. Darauf wollte ich hinaus. Wir kennen ja das alte Problem von Scrum, wenn Teams “Scrum but…” machen. Das könnte man jetzt auf “SAFe but…”. Das habe ich in der Praxis oft erlebt. Es werden einzelne Versatzstücke von SAFe genommen. Die Gründe sind ganz unterschiedlich. Die einen sagen: Wir haben gerade dieses Problem und wir denken, dass wir das mit jener Komponente von SAFe lösen können, und der Rest ist für uns momentan nicht so relevant.

Andere sagen sich: Hm, ja, das wäre jetzt irgendwie viel zu schwierig und das können wir bei unseren Rahmenbedingungen auch nicht in Gänze einführen, aber die, die und die Sachen können wir eigentlich relativ einfach umsetzen, also machen wir nur diesen Teil und den Rest lassen wir weg - und lügen uns in die Tasche, dass wir den Rest später auch noch nachziehen, was dann nie passiert. Und das ist wie gesagt das Äquivalent zu “Scrum but…”, also “SAFe but…” sozusagen. Die ursprünglich in Teilen oder in Gänze gute Idee und Vorleistung von Dean Leffingwell und den Leuten hinter SAFe wird durch dieses Cherrypicking-Verhalten der Kunden konterkariert.

Gehört das eigentlich zu deinem Beratungsportfolio, Kunden dabei zu helfen, so etwas zu identifizieren? Du beobachtest die Dinge und stellst fest: Hier versucht ihr ja offenbar, XY umzusetzen, aber das macht ihr in Wirklichkeit gar nicht! Und wie ist es mit SAFe - bist du raus, wenn ein Kunde das machen will?

Teils, teils. Früher war das für uns immer eine Art Indiz: Für einen bestimmten Typ von Kunden, die SAFe gut finden oder eher SAFe-afin sind, sind wir wahrscheinlich nicht die richtigen Berater oder Coaches. Da war der Match quasi nie perfekt. Heute würde ich wahrscheinlich einen Schritt weitergehen und eher sagen, dass wir uns von bestimmten Methoden-Präferenzen gelöst haben. Wir sind keine Leute, die jetzt unbedingt immer Scrum machen müssen oder die totalen Design-Thinking-Addicts sind oder irgendwie so etwas. Sondern wir sind inzwischen eine Stufe weitergegangen: Worauf es uns einheitlich ankommt, ist eher das agile Mindset, also sozusagen dieser klassische Konflikt “Doing Agile versus Being Agile”.

Das ist das Spannungsfeld, in dem wir uns bewegen - wobei wir mit den Kunden mehr in Richtung “Being Agile” gehen wollen. Die Kunden, über die wir hier gerade reden, die vielleicht auch solches Methoden-Cherrypicking betreiben, und zwar nicht nur bei SAFe - das sind eher Leute, die in SAFe oder ähnlichen Methodiken reine Werkzeuge sehen und das teils auch so sagen. Die nehmen sich aus dem Methoden-Baukasten halt einzelne Komponenten, wie sie sie gerade brauchen. 

Dahinter steckt eine sehr mechanistische Denkweise, und das ist ein Punkt, wo wir versuchen anzusetzen - und zwar unabhängig von SAFe. Die können sich auch irgendeine andere Methodik wie beispielsweise LeSS oder Scrum of Scrums oder Nexus ausgesucht haben. Hier geht es um das echte Coaching: Wir versuchen mit dem Kunden an einem Verständnis davon zu arbeiten, was er da eigentlich tut und welche Auswirkungen das hat. Also wird er jemals von dem “Doing Agile” zu dem “Being Agile” kommen? Will er das überhaupt? Genau in diesem Spannungsfeld bewegen wir uns eigentlich hauptsächlich.

Aber zurück zu deiner Frage, was wäre, wenn wir jetzt bei so einer SAFe-Implementierung feststellen würden, dass es da Cherrypicking gab und nur einzelne Komponenten ausgewählt wurden. Übrigens sind diese Einzelteile meiner Erfahrung nach dann meistens nicht mal richtig umgesetzt. Es wird also nicht nur in einzelne Sachen runtergebrochen, sondern diese werden dann auch noch fachlich schlecht adaptiert, weil sie vielleicht von vornherein nicht richtig verstanden worden sind. Dort würden wir dann reingehen und versuchen, mit dem Kunden daran zu arbeiten, dass er das überhaupt versteht und auch annehmen kann. Also dass er versteht, dass es vielleicht nicht von Vorteil für ihn ist, was er da getan hat, und dann im nächsten Schritt daran arbeiten, was für ihn eine bessere Alternative wäre. Es geht dann darum, diese Komponenten von SAFe oder einer anderen Methode richtig zu verstehen, sie besser anzuwenden oder in der Methodik vielleicht tatsächlich weiterzugehen und damit eben langsam von “Doing Agile” zu “Being Agile” zu kommen.

Wie ist denn eigentlich die Situation in der Agile-Community? Gibt es da gewisse Lager? Oder sind da ganz viele SAFe Gold Partner und so etwas, die gleichzeitig total coole Leute und ganz normale Mitglieder der Gemeinschaft sind?

Ich will es mal so sagen: Personen, die zumindest wahrnehmbar sehr stark in diesem SAFe-Umfeld tätig sind und auch von den Kunden wahrgenommen werden und gebucht werden, sind oft eher prozessorientiert unterwegs und nicht so sehr in dieser Agile-Coach-Welt, wo es tatsächlich eher um das Mindset geht, um Emotionen und Teambuildung und solche Aspekte. Sicherlich gibt es da Überschneidungen in Personen und auch in Firmen, aber ich würde schon sagen, dass da zwei verschiedene Lager sind, ohne dass das vielleicht bewusst gewollt ist.

Das heißt aber auch, dass du nicht besonders interessiert daran bist, dich in diesem SAFe-Lager zu positionieren, oder?

Ich würde es nicht an SAFe festmachen. SAFe ist sicherlich ein großer Vertreter. Aber was hier für mich eine Rolle spielt, ist nicht das Thema Skalierung und der Skalierungsansatz, sondern eher die Nachfrageseite. Also welche Kunden fragen nach Skalierungs-Frameworks und -Vorgehensweisen. Das ist oftmals eine Klientel, bei der man das Gefühl hat, dass sie das Pferd von hinten aufzäumen wollen beziehungsweise bestimmte Punkte überspringen. Wir arbeiten tatsächlich gerne mit Kunden zusammen, die durchdringen wollen, was eigentlich das mentale Modell ist, das hinter Agile steckt und das Agile ausmacht.

Ich habe aber auch in anderen Umgebungen gearbeitet, mit vielen Kunden, die SAFe im Einsatz hatten. Ich war bei SAFe-Veranstaltungen, obwohl ich kein SAFe-Coach bin. Und diese Organisationen waren teils auf einem anderen Trip unterwegs. Die wollten sich gar nicht um ihre Kultur, um ihr Mindset kümmern, sondern einfach nur vorhandene Rituale oder Prozesse oder Rollenmodelle gegen etwas Anderes austauschen. Die eine Blaupause wegnehmen und dafür die andere Blaupause ausrollen. Das alte Organigramm gegen das neue Organigramm austauschen. Und das ist also eher der Grund, warum ich da nicht so stark engagiert bin. Wie gesagt, ich habe es vorhin schon erwähnt: Als das Ganze neu aufkam, hat mich das sehr wohl interessiert. Ich habe eine ganze Zeit SAFe aktiv verfolgt und hatte da eigentlich auch keine negative Meinung. Doch als das Ganze langsam wirklich zum Geschäftsmodell wurde und man auch gesehen hat, wie es dann auch vom Kunden genutzt wird, habe ich ein bisschen das Interesse daran verloren, selbst in diesem Bereich beratend tätig zu werden.

Wenn du SAFe mit LeSS, Nexus oder anderen Ansätzen vergleichst, würdest du dann dich für eine bestimmte Stoßrichtung aussprechen und diese empfehlen?

Dann würde ich sagen, dass ich wahrscheinlich eher dem LeSS-Lager angehöre, aus verschiedenen Gründen.

Warum ist das so?

Die Grundidee bei LeSS ist, über Prinzipien und Werte zu skalieren. Die haben natürlich ein Framework und ein Vorgehensmodell, die haben bestimmte Zusammenkünfte, aber die legen nicht den absoluten Fokus darauf und stellen das nicht so krass in den Vordergrund, wie es zum Beispiel bei einem Vorgehen wie SAFe wäre. Stattdessen versuchen sie sehr stark, die agilen Werte und Prinzipien in den Vordergrund zu stellen, beziehungsweise auch ganz explizit die Werte von Scrum. Das heißt, dass sich dieser ganze Werteansatz dahinter eher um “Being Agile” und nicht so stark um “Doing Agile” dreht. Und das ist dann wahrscheinlich auch ein Match zwischen denen, die es anbieten, und den Kunden, die das nachfragen.

Eine Sache an dem Gesamtproblem haben wir noch nicht genannt, aber sie spielt beim Kunden sicherlich eine Rolle. Der Kunde kommt und will eine allgemeine Beratung zum Thema Skalierung, wenn er mit mehreren Teams zusammenarbeiten oder seine vorhandenen Teams organisieren will. Dann fragt der Kunde irgendwann auch nach dem Spotify-Modell, wo der erfahrene Coach sagt: Das gibt es gar nicht! Sagt Spotify selbst: Es gab nie ein Spotify-Modell, das ist irgendwie ein Missverständnis. Und das ist eigentlich das, was mich bei dieser ganzen Thematik umtreibt. Ich würde grundsätzlich erstmal die Frage stellen, ob Skalierung notwendig ist. 

Als studierter Historiker habe ich mich auch stark mit der Entstehung, mit den Anfängen der agilen Methoden auseinandergesetzt. Zum Beispiel habe ich damals die auch auf Deutsch erschienen Bücher über Extreme Programming gelesen. Um im Ursprungsband, also in der allerersten Ausgabe, die damals erschienen ist, stand drin, dass das eine Ein-Team-Methode ist. In dem Buch steht, dass du auch immer darüber nachdenken solltest, ob du dein Produkt wirklich mit mehreren Teams oder mit vielen Leuten entwickeln musst oder ob es nicht auch möglich wäre, nur mit einem Team das gleiche Produkt zu entwickeln. 

Und das ist sozusagen eher ein Ansatz, den wir fahren, weil wir sehr oft festgestellt haben, dass wenige Leute, die wirklich motiviert sind und was drauf haben, mehr schaffen können als viele Leute, die aus irgendeinem Grund nicht so erfahren oder nicht so motiviert sind oder nicht das Handwerkszeug an der Hand haben, um gut zu arbeiten. Man sollte grundsätzlich fragen: Muss Skalierung wirklich sein? Musst du mit mehreren Teams und mit 500 Leuten arbeiten oder geht es nicht auch mit wenigen Menschen, also mit ein oder zwei Teams. Und wenn du diese Frage stellst und dich damit beschäftigst und einen Kunden hast, der mit dir offen über die Dinge redet, dann kann es sein, dass du irgendwann zu dem Schluss kommst, dass wir gar keine Skalierung brauchen - unabhängig davon, welche Methode toll wäre.

Okay, das ist natürlich ein bisschen schwierig für einen Konzernkunden, der in seinem Bereich gerade 400 Leute beschäftigt und dann zu dem Ergebnis kommt, dass es auch mit 13 geht. Dann ist das für einige der restlichen Leute vielleicht nicht so hübsch…

Ja, willkommen in meiner Welt. Also das ist das, was uns täglich entgegenschwappt. Wir möchten niemanden vor den Kopf stoßen, aber wir wollen diese Erkenntnis auch nicht nicht zulassen.

Verstehe ich.

Bringt einem auch nicht nur Freunde ein, das muss man ehrlicherweise sagen. Irgendwann habe ich mal gesagt: Wir bei Veränderungskraft sind eigentlich die Agile Armee Fraktion. Wir würden sogar von uns sagen, dass wir eine der wenigen Firmen sind, die diese Dinge, die damals mal geschrieben worden sind in diesen Büchern, tatsächlich ernstnehmen und versuchen, sie anzuwenden. Manch andere reden nur davon. Wir versuchen es zumindest, das umzusetzen. Mal mit mehr, mal mit weniger Erfolg und mit dem Effekt, den wir nicht intendiert haben, aber der dann halt erfahrungsgemäß eintritt, dass wir nicht nur Freunde haben. Und ehrlicherweise muss man sagen, dass wir nicht nur bei Kunden nicht nur Freunde haben, sondern mitunter auch mal eine Außenseiterposition in der agilen Szene einnehmen.

Okay, verstehe ich. Spannend übrigens, dass es Spotify gar nicht gab. Ich kenne auch die Autoren von LeSS noch nicht.

Craig Larman und Bas Vodde.

Danke! Glaubst du, dass SAFe das Rennen zwischen diesen Frameworks bereits gemacht hat? Irgendwann kam mal Microsoft und schnell waren alle anderen Betriebssysteme weit abgeschlagen. Inzwischen gibt es wieder mehr Macs und auch Linux und Chromebox und so weiter, aber ich habe den Eindruck, dass SAFe diesen speziellen Markt bereits überrollt hat.

Kurze Antwort: Ja. Bei Microsoft hat sich das dann ja - wie du richtig gesagt hast -  irgendwann geändert, und Apple ist auch nicht mehr die unumstrittene Nummer eins. Es gibt jedenfalls auch andere geniale Smartphones. Aber in unserem Bereich würde ich schon sagen, dass SAFe der Marktführer bei den Skalierungs-Vorgehensmodellen ist. Es gibt aber noch einen zweiten Platzhirsch, den ich schon genannt habe. Wie gesagt: Eigentlich gibt es den gar nicht, und das kann man auch nachlesen oder die Leute von Spotify selbst fragen, zum Beispiel Henrik Kniberg, der das damals mit ausgearbeitet und vorgestellt hat, diesen Artikel, durch den das Missverständnis entstanden ist, es gäbe ein Spotify-Modell. Trotzdem ist das eine Art Hidden Champion, weil es verschiedene Beratungshäuser gibt, die das wirkungsvoll anbieten - gerade auch große, bekannte, alteingesessene Beratungshäuser, die nicht aus dem agilen Kontext kamen, so mit schottischem Nachnamen oder drei Buchstaben als Kürzel. Du weißt schon, was ich meine.

Und diese großen Beratungshäuser, die bei Konzernen und großen Banken und Versicherungen unterwegs waren, haben aus irgendeinem Grund das Thema “Spotify-Modell” entdeckt und verkaufen das ihren Kunden. Die denken auch, dass es dieses Spotify-Modell wirklich gibt. Von SAFe haben die meiner Erfahrung nach allerdings noch nie was gehört. Das müsste man, wenn es um Marktführerschaft geht, vielleicht auf dem Schirm haben. Aber in den Bereichen, in denen wir und ihr arbeiten, also in der Agile-Szene und der Software-Entwicklung - da ist SAFe sicherlich die bekannteste Methode, die bei den Kunden den größten Verbreitungsgrad hat.

Ich will mich ja jetzt mit Literatur beschäftigen und Literatur produzieren. Ich habe dir jetzt zugehört, ich kenne deine Skepsis, aber ich will das trotzdem fragen: Was soll ich denn lesen? Was lesen Menschen, die sich mit Scaling Agile oder SAFe oder LeSS oder DAD oder dem Spotify-Modell beschäftigen wollen?

Es kommt darauf an, was du erreichen willst.

Hinkehr und Abkehr, ich nehme alles.

Zu SAFe gibt es zum Beispiel von dem Christoph Mathis ein Buch, das beim dpunkt.verlag veröffentlicht wurde. Wibas hat in Teilen auch mal etwas veröffentlicht, die haben so eine eigene Bibel herausgebracht, wo sie auch ein eigenes Skalierungmodell vorgestellt haben, das sich an Sachen wie SAFe und Co. orientiert hat. Da gibt es also Einiges. Aber mir sind dieses Mindset und die Werte sehr wichtig, und wenn du versuchst, über Methodik oder Prozesse zu skalieren, ist das endlich. Den eigentlichen Effekt, den du mit Skalierung erreichen willst, wirst du nicht erzielen, weil das ziemlich haarig ist - irgendwann knirscht es. Wenn man diesen Mindset-Aspekt mit hereinnehmen wollte oder du dich dafür interessierst, würde ich tatsächlich eher das LeSS-Buch empfehlen, das es seit einiger Zeit auch in deutscher Übersetzung gibt. Das hat der Björn Jensen damals mit übersetzt.

Und wie heißt das? LeSS?

Large-Scale Scrum. Die Autoren sind die Erfinder von LeSS, also Bas Vodde und Craig Larman. Und darüber hinaus würde ich mich noch mit zwei, drei weiteren Titeln auseinandersetzen. Da ist eben eines dieser ursprünglichen Werke zu Extreme Programming, die damals veröffentlicht worden sind. Der erste Band stammt von Kent Beck und heißt Extreme Programming: das Manifest. Gibt es antiquarisch auch noch auf Deutsch für ein paar Euro. Und auch Tobias Mayer hat sich damit auseinandergesetzt und ein Buch namens hat The People’s Scrum geschrieben. Ich hatte damals sogar bei der deutschen Übersetzung geholfen. Tobias veröffentlicht bis heute, allerdings nicht viel in Buchform, sondern eher Blog-Artikel, Beiträge bei LinkedIn oder Videos, und er hat sich eben auch mit dem Thema Skalierung auseinandergesetzt. 

Den haben wir mal in England bei einer Veranstaltung getroffen und dort hat er schön erklärt, dass Skalierung in der Ursprungsbedeutung eigentlich etwas ganz anderes bedeutet. Er meinte, dass der Begriff im ökologischen Kontext, also konkret beim Gärtnern genutzt würde, wenn es darum geht, einen Baum zu beschneiden. Das ist Skalierung. Also genau das Gegenteil: Es wird nicht mehr, sondern man reduziert etwas.

Okay, cool.

Ich muss allerdings sagen, dass es meines Wissens keine Bücher von neutralen Dritten gibt. Also fast alles Genannte kommt von den jeweiligen Erfindern der Skalierungsmethoden. Es gibt nicht jemanden wie dich oder mich, der dann gesagt hat: Okay, Skalierung - ich bin kein Vertreter einer bestimmten Methode, sondern habe mich mit dem Thema im Ganzen auseinandergesetzt, habe das einmal beleuchtet, stelle verschiedene Methoden vor, betrachte das Für und Wider, gebe ein paar Tricks und Tricks. So jemand neutrales Drittes, der nicht selbst eine Skalierungsmethode erfunden hat oder vermarkten will, ist mir tatsächlich nicht bekannt.

Vielleicht kann ich das ja ändern. Wobei wir ja auch nicht ganz neutral sind. Wir haben gesagt, dass wir einen Jira-Aufsatz vermarkten wollen, und der soll agile Skalierung ermöglichen. Und weil SAFe so verbreitet ist, schneiden wir das eben auf SAFe zu. Wir hätten auch was Anderes machen können, aber das Schöne an SAFe ist ja, dass es - wie du schon sagtest - so sklavisch und prozessual ist. Da gibt sozusagen ganz eindeutige Anweisungen an jemanden, der eine Software herstellt, und das macht uns das Leben natürlich einfacher.

Die Abfolge ist klar strukturiert. Deshalb wisst ihr, was ihr an Templates und an Features bauen müsst und welche Funktionen es für den Rhythmus der Event-Abfolge braucht.

Das ist quasi das leichteste Opfer für uns gewesen.

Aber eigentlich kannst du dir auch eine andere Skalierungsmethode als Kandidaten ausgucken…

Haben wir. Wir haben Kunden, die benutzen unsere Software, um LeSS zu machen.

Es ist ja immer ein ähnliches Prinzip bei den Skalierungsmethoden. Du musst irgendwie ein Portfolio aufbauen und managen. Dann brichst du es runter in kleinere Teile. Dann arbeitest du mit diesen Teilen. Dann hast du so etwas wie einen Sprint-Rhythmus, egal wie lang der ist und wie der heißt, aber du hast immer ein Zeitintervall, in dem konkret etwas getan wird und wo Leute zusammenkommen. Dann gibt es so etwas wie Backlog-Grooming. Das ist, würde ich sagen, bei allen Skalierungsmethoden eine ähnliche Denk-oder Handlungsweise. Nur die Events heißen teilweise unterschiedlich, der Rhythmus ist vielleicht ein bisschen anders und der Ablauf bezüglich der Events oder Rollen ist verschieden. 

Aber letztendlich geht es immer darum, etwas Großes erstmal zu manifestieren in Form eines großen Backlogs oder eines Portfolios, und nun bricht man das in kleinere Teile herunter, und dann wird etwas abgekippt, wo etwas gearbeitet wird, und dann kommt man wieder zusammen mit mehreren Teams, um zu gucken, was daraus geworden ist. Das ist eine Art V-Modell - vom Großen ins Kleine und dann wieder nach oben. Aber so ist es im Prinzip bei den meisten Skalierungs-Vorgehensmodellen.

Aus unserer Erfahrung kann ich klar sagen, dass uns das mit der Struktur aus SAFe an einigen Stellen sehr geholfen hat. Zum Beispiel haben wir irgendwann angefangen, synchronisierte Scrum-Dependencies einzuführen. Das ist ja eine Grundvoraussetzung dafür, dass du ein PI-Planning machen kannst und auch ein PI-Review. Die ganzen Teams müssen zu den gleichen Zeiten ihre Sprints anfangen und beenden. Und diese eigentlich einfache Umstellung, dafür zu sorgen, dass alle gleichzeitig starten und enden, hat einen enormen positiven Effekt bei uns gehabt, weil wir zu gleichen Zeiten gleichartige Aktivitäten innerhalb der Teams hatten. Das hat dann auch eine Bereitschaft generiert, sich auch zum Beispiel gerade um Bugfixes und APIs und solche Sachen zu kümmern.

Wie gesagt: SAFe ist nicht per se schlecht, gar nicht.

Sylvius, herzlichen Dank, dass du dir die Zeit genommen hast!