Hallo, Marcus. Im Vorfeld hast du angedeutet, dass man euch bei BMW nicht direkt als SAFe-Jünger bezeichnen kann – auch dich nicht. Habe ich das richtig verstanden? 

Ja genau, aber mittlerweile gibt es natürlich auch bei BMW viele SAFe-Jünger. 

Würdest du also sagen, man kann eine Entwicklungskurve beobachten? 

Ja, auf jeden Fall. Einiges habe ich auch schon in verschiedenen Videos erzählt, die im Internet verfügbar sind, das ist kein Geheimnis. Also, wir haben den Teams nichts Konkretes vorgeschrieben. Wir haben in diesem Transformationsprozess nur gesagt: Wir machen agile Produktentwicklung. Das war der Ausgangspunkt. Wir haben gesagt, wir haben IT-Produkte und wollen verschiedene Systeme zu einem Produkt bündeln. Und dieses Produkt wird agil entwickelt. So weit, so gut. Aber nach welchem Modus die Verantwortlichen das umsetzen, ob sie Scrum oder Kanban verwenden, oder ob das Produkt so groß ist, dass es ein eigenes Skalierungs-Framework braucht – und wenn ja, welches –, haben wir völlig offen gelassen. Die meisten Bereiche sind so groß, dass sie eins brauchen. 

Und wie haben sie sich entschieden?

Es gibt jetzt Bereiche, die sich irgendwie beholfen haben, es gibt Bereiche, die verwenden LeSS, und es gibt Bereiche, die nutzen eher SAFe.

Das ist interessant. Ich habe nämlich einige nur von LeSS erzählen gehört und dann angenommen, dass BMW doch in die andere Richtung abgebogen ist.

Genau, wir sind tatsächlich an einer Kreuzung sehr stark in die andere Richtung abgebogen, und zwar beim autonomen Fahren. 

Inwiefern?

Vor einigen Jahren hat Craig Larman persönlich hier bei uns das ganze Team vom autonomen Fahren trainiert. Damals war der Ansatz, das Ganze nach einem richtig großen LeSS aufzubauen. Das haben wir auch gemacht. Mittlerweile schaut es schon wieder ein bisschen anders aus. Wir haben die “reine Lehre” Craig Larmans in einigen Teilen wieder etwas zurückgenommen. Die reine Lehre halte ich auch fast nicht für anwendbar, nachdem ich damals selbst im Training dabei war.

Beschreib doch mal. Ich will ja ein Buch schreiben für Leute, die da gerade erst reinkommen. Was ist denn die reine Lehre im LeSS und worin liegen die Schwierigkeiten bei der Anwendung in einem großen Konzern wie BMW?

Na ja, es ist ja so, dass nur ganz wenig Struktur vorgegeben wird. Es geht im Wesentlichen darum, Scrum in größerem Maßstab anzuwenden, eigentlich die typische Scrum-Lehre, nur größer, mit möglichst wenig festgelegten Rollen und möglichst wenig Framework – LeSS steht für so wenig Framework wie möglich. SAFe im Gegensatz ist so viel Framework wie möglich.

Genau.

Und das, glaube ich, funktioniert mit den Gegebenheiten im Konzern oder in unserer Produktstruktur vielleicht nicht. Also ich denke, das funktioniert, wenn du einfach ein sehr großes Softwareprodukt entwickelst, aber nicht, wenn du einen “Bauchladen” mit 50 verschiedenen IT-Systemen bei dir nun als “ein Produkt” bezeichnest. Das führt dazu, dass der eine sich hier auskennt und der andere dort. Den Begriff des Feature-Teams in dem Sinne, dass jeder im Team sich im ganzen Produkt einbringen kann, finde ich in der Theorie zwar ein super Ziel – aber wenn ich mir unsere Produkte anschaue, dann ist das bei uns einfach nicht der Fall. Bei so vielen unterschiedlichen IT-Systemen kann nicht jeder überall was machen. Wir haben zwar durchaus ähnliche Fachprozesse, sonst hätten wir die Systeme nicht gebündelt, aber technisch und zum Teil auch fachlich kann nicht jeder jeden Detailprozess in der Tiefe kennen. Deswegen haut dieses Feature-Team bei uns so nicht hin.

Einige von den Leuten, die ich bisher interviewt habe, sagten so etwas wie: “SAFe ist so eine Brückentechnologie; die sorgt dafür, dass der starre Konzern mit seinem traditionellen Organisationsmodell und seinen Denkstrukturen quasi abgeholt wird, um in Richtung agiler Zusammenarbeit gehen zu können.” Und zwar auch auf einer sehr großen Skala.

Ja, da ist was dran. 

Und deswegen sei es gut, dass alles so kodifiziert ist und es alle diese Rollen gibt und man sich für jede einzelne Rolle eine eigene Schulung aussuchen kann. Und es sei auch gut, dass es so teuer ist. Könnte ich dann quasi mit SAFe zu LeSS kommen?

Nein, glaube ich nicht. Genau das, was du jetzt als Vorteil schilderst, nämlich diese Anschlussfähigkeit, war für mich immer der Grund, SAFe abzulehnen. 

Kannst du genauer erläutern, was du meinst?

Ja, denn was meiner Meinung nach passieren wird, ist, dass die Rollen einfach umgelabelt werden. Vorher waren es Wasserfall-Prozesse, jetzt sind es SAFe-Prozesse, und jeder findet dort seine Rolle wieder. Jeder findet irgendwie sein Kästchen ...

... und macht genauso weiter wie bisher.

Genau! Und du wirst nie weiterkommen. Daher war meine Philosophie: Wenn du in Richtung Agilität einen großen Sprung machen willst, dann musst du mit LeSS anfangen. Damit schaffst du ein verstörendes Moment, und genau das wollte ich. Deshalb haben wir teilweise auch unser Management da durchgeschleust, das nach drei Tagen LeSS-Training völlig ernüchtert rauskam und meinte: “Alles Mist bei uns!” So bringst du die Leute zum Nachdenken, wie man vielleicht wenigstens doch ein Stückchen in diese Richtung gehen könnte.

Und hat es geklappt?

Teilweise schon. Wir haben jetzt wirklich Abteilungsleiter, die sagen: “Wir machen nun keine zwei Releases im Jahr mehr, sondern ich will 50 Deployments am Tag.” Jetzt müssen sich die Leute was überlegen. Würde der Chef statt zwei Releases nun vier Releases machen, dann kannst du das immer noch manuell hinbekommen, kannst es also immer noch irgendwie so wie vorher machen. Aber wenn er sagt, er will 50 Mal am Tag deployen, dann musst du das halt automatisieren, dann musst du dir was einfallen lassen. Dann hast du keine Wahl mehr. Mittlerweile haben sich schon Einige in die Richtung bewegt – auch wenn wir noch lange nicht dort sind, wo wir sein müssten oder wo wir sein wollten oder wo ich sein wollte. 

Ist dein Blick da jetzt sehr stark auf die Softwareentwicklung gerichtet?

Ja.

Und im Business? Spielt es da für euch eine Rolle, wie das Marketing, der Vertrieb, die Channels sich organisieren oder ist das dort ganz weit weg und da gibt es überhaupt kein Agile?

Doch, doch, die lassen sich natürlich von dem, was wir da angezündet haben, inspirieren und ich war auch schon sowohl im Marketing also auch bei unserer Revision und vielen anderen Stellen eingeladen, um zum Thema “Wie können wir unsere Arbeit agiler gestalten?” etwas zu sagen.

Meinst du, dass sie das auch ernsthaft wollen oder ist es eher, weil das eben gerade modern ist und man es ja auch mal versuchen könnte?

Nein, sie wollen das auch. Klar waren da auch Einige dabei, weil es ein Stück weit modern ist, das gebe ich schon zu, aber im Großen wollen die anderen Abteilungen das schon. Man kann sagen, es strahlt von der IT ausgehend auf alle Prozesse aus, weil natürlich alle Prozesse von der IT unterstützt werden; sie bildet sozusagen eine Schnittstelle und deswegen verbreitet sich auch das Gedankengut weiter. 

Und SAFe gibt es dann intern auch oder nur im sehr kleinen Rahmen? Und lassen sich Grabenkämpfe oder so etwas beobachten?

Nein, da gibt es keine größeren Grabenkämpfe. Die einen machen gerne SAFe, die lieben ihr PI-Planning am Anfang eines Quartals, was auch durchaus sinnvoll ist.

Du bist bei BMW aktiv. Dann würde mich jetzt doch mal eine andere Sache interessieren: Da gibt es ja diesen amerikanischen Tesla-Autohersteller …

Habe schon davon gehört, ja. 

… der eine Marktkapitalisierung hat, in die alle deutschen Autohersteller und noch eine Bank mit reinpassen. Erzähl doch mal ein bisschen. Ich bin totaler Laie, das mag jetzt auch sehr pauschal klingen, aber wenn ich jetzt am Markt erklären sollte, warum Tesla so erfolgreich ist, dann würde ich sagen: “Na ja, die haben kein Auto gebaut, sondern eine Software oder einen Computer, und da sind auch vier Räder dran.” Also: Schaut ihr euch viel von Tesla an und sagt: “Wenn wir jetzt nicht unsere 50 Deployments am Tag hinkriegen, dann werden die uns einfach auffressen, weil die deployen sogar live in die Autos, während die noch fahren!” Wie ist denn das Verhältnis, wie wirkt sich das auf die tägliche Arbeit aus?

Also, das ist unterschiedlich. Es gibt schon Leute, die nehmen die Bedrohung sehr ernst, aber auch einige, bei denen es eher nicht als so bedrohlich wahrgenommen wird, weil man sich da eher auf die Hardware-Eigenschaften konzentriert. Du musst sehen, dass wir als Automobilhersteller ja ganz lange Hardware hergestellt haben. Wir haben über 100 Jahre Hardware hergestellt, und so sind wir geprägt. Und insofern konzentriert man sich bei neuen Konkurrenten auch relativ schnell auf die Hardware oder die Frage “Wie fährt sich das Ding?”, also die Fahreigenschaften. Dann kann man sich natürlich auch schnell über die Spaltmaße lustig machen …

Genau, die Spaltmaße beim Tesla. Ich habe einen Kollegen, der einen Tesla bestellt hat, den er irgendwann in den nächsten zwei Wochen entgegennehmen wird. Der weiß schon genau, was alles Mist sein wird und wo er hingucken muss, um dann zu sagen: “Den nehme ich nicht, gebt mir einen anderen.”

Ja, genau.

Das kann man also irgendwie wieder stornieren. Es gibt ja wohl so eine richtige Community, die sich gegenseitig erklärt, was an den Teslas alles schlecht verbaut ist.

Sowas ist halt nicht premium. Sowas ist nicht unser Anspruch. Wir sind eher so geprägt: Unser ehemaliger CEO von Kuenheim soll mal über den Hof gegangen sein und hat sich die 7er angeschaut, die alle nebeneinanderstanden, also noch im Werk. Dabei hat er festgestellt, dass die Kofferraumdeckel unterschiedlich hoch sind. “Das geht nicht, das kann nicht sein! Das ist nicht premium. Die müssen in einer Linie sein, bitte.” Das war seine Ansage. Und seitdem werden tatsächlich Federn verbaut, die abhängig vom Gewicht des Autos sind, und das Gewicht der Autos ist abhängig von den Sonderausstattungen. Das heißt, du hast da quasi in deiner Stückliste einen Regelkreis drin. Da legst du je nach Sonderausstattung die entsprechenden Federn fest. Und das nur, damit die Autos auf dem Hof am Kofferraumdeckel die gleiche Höhe haben, ja? Also, ich sage nur Spaltmaß-Fixierung … Obwohl das dem Kunden tatsächlich egal sein dürfte – der hat ja nicht mal eben zwei oder drei 7er zu stehen. 

… in unterschiedlicher Ausstattung.

Genau. Daran sieht man aber gut, dass man eben schon ein bisschen verliebt in die Hardware ist.

Steht ihr euch da mit eurer Komplexität auch ein bisschen selbst im Weg?

Nun, man baut über 100 Jahre lang Hardware, und dann kommt in den letzten 20 Jahren nach und nach Software rein. Das heißt: Du hast da mal ein Steuergerät, du hast dort mal ein Steuergerät, dann noch eins und am Ende hast du quasi ein Geflecht aus 30, 40 Steuergeräten im Auto. Dort ist überall eine Software drin – und die Steuergeräte stammen, weil so ein Automobilhersteller ja nichts selbst macht, von unterschiedlichen Lieferanten. 

Das macht Tesla aber auch so, die machen ja auch nichts selbst.

Die Software schon.

Okay – aber die Steuergeräte in den Sachen, die sie zukaufen, sind alle aus fremder Hand.

Die Architektur ist bei Tesla grundsätzlich anders. Es mag schon sein, dass da ein paar Steuergeräte sind, aber es gibt eine zentrale Recheneinheit, einen zentralen Computer drinnen. Das ist es, worauf ich hinaus will.

Die kaufen sozusagen von vornherein nur Sachen ein, die sie auch mit ihrer Software verbinden können.

Genau. Das ist quasi so, als würdest du in einen PC ein Diskettenlaufwerk schrauben. Natürlich hat das Diskettenlaufwerk auch einen kleinen Controller, aber da ist das Interface spezifiziert, und die Software updatest du ja nie. Doch was du mit dem Diskettenlaufwerk machen kannst, machst du über die Schnittstelle.

Aber das ist ja nicht wirklich patentiert. Also, ihr könntet ja auch ein ganz neues Auto planen und sagen: “So, wir fangen jetzt mal mit der Software an.”

Ja, aber dazu musst du eben wie ein Softwarehersteller denken, nicht wie ein Hardwarehersteller. Das ist das ganze Problem. Aus so einem Hardwarehersteller wird nur relativ schwer ein Softwarehersteller. Du musst dafür ja die Denkweise auf den Kopf stellen.

Von außen betrachtet, würde ich sagen: Wenn ihr das nicht schafft, werdet ihr am Markt untergehen. Denkt ihr das intern ebenfalls, oder sagt ihr: “Nein, am Ende brauchen die Leute vier Räder und alles muss gut verarbeitet sein”, und die Software ist eher zweitrangig?

Es gibt die, die so denken, und die, die es anders sehen. Wer die Oberhand behält, werden wir sehen. Es ist schwierig – und wir reden hier nur vom Fach Auto und noch nicht von den Services drumherum und dem Auto als Element in einer großen Softwareplattform. Der vernetzte Mobilitätsdienst – das ist ja nochmal eine Stufe weiter gedacht, die kommt dann erst als Nächstes. Das ist schon komplex. 

Nehmen wir mal an, du würdest den Marcus von vor 15 Jahren bei BMW beraten. Er würde sagen: “Hey, ich müsste eigentlich mehr agil machen, skalierte Agilität ist bei uns auf jeden Fall ein Thema, weil wir so riesengroß sind.” Was würdest du dir rückwirkend raten?

Darum bin ich so ein LeSS-Fan: erstmal klein anfangen und aus dem Kleinen ins Große kommen und zunächst die Verkrustungen und auch die Abhängigkeiten in der Organisation lösen. Das ein weiteres Problem von SAFe: Du wirst relativ schnell relativ groß und du verwaltest nur nicht die Abhängigkeiten. Ich will die Abhängigkeiten aber loswerden. Ich will also Architekturen wählen, die die Abhängigkeiten, die Systeme entkoppeln.

Da musst du mit LeSS aber ziemlich weit oben ansetzen, damit es funktioniert, oder? SAFe ohne “von oben” geht ja auch nicht.

Ja, du brauchst natürlich schon eine Top-down-Strategie, das stimmt. Aber diese Strategie müsste meiner Meinung nach beinhalten, dass du klein beginnst, dass du also vom Kleinen ins Große lernst. Denn wenn du das zu schnell in zu großem Maßstab machst, hast du Probleme: Dann wird es einfach zu schnell industrialisiert. Dann industrialisierst du Scrum sozusagen zu Tode. 

Manche Leute sagen: “Du kannst Scheiße nicht skalieren.” Also musst du erstmal gucken, dass du sozusagen deinen Hof kehrst und deine Teams und deine Grundstrukturen, mit denen du dann wachsen willst, sauber hast …

… und die Systeme, die Architekturen. Das sind ja alles riesige monolithische Architekturen, wo alles mit allem zusammenhängt. Wir bauen in den Systemen Point-to-Point-Schnittstellen, und zwar immer wieder. Da ist nichts mit APIs oder so was. Wenn ich von System B bestimmte Daten brauche, baue ich eine Extraschnittstelle für genau diese Daten. Da gibt es keine APIs, um darauf zuzugreifen. Darum ist das alles so miteinander verflochten, wie in einem großen Spaghettiknäuel.

Also, das habe ich verstanden: Ich soll klein anfangen und dann erstmal gucken, dass ich die Abhängigkeiten reduziere. Gibt es ein paar Dinge, bei denen du rückwirkend denkst: “Das habe ich falsch gemacht” oder “Da bin ich von der falschen Hypothese ausgegangen, die sich nicht bestätigt hat”? Wo du anderen sagen würdest: “In diese Stolperfallen tapp mal lieber nicht rein”?

Klein zu starten, ist schon mal gut, und ich war dann angetan von unserer großen Strategie, die ganze IT 100 Prozent agil aufzustellen. So ein Top-down-Commitment vom CIO, zu sagen: “Wir machen alles agil, wir machen überall agile Produktentwicklung” – das ist erst einmal super, es gibt ein Riesenschwung, führt aber automatisch auch zu einer gewissen Erwartungshaltung an die Organisation. Das heißt, du musst das auch relativ schnell umsetzen, und da beißt sich sozusagen das Klein-Anfangen und Lernen mit der Anspruchshaltung von oben, und dann wird es doch relativ schnell relativ groß – und endet in Prozessen, in Rahmenwerken, in Vorschriften, die alle gut gemeint sind, aber die du wahrscheinlich nicht entwickelt hättest, wenn alles organisch gewachsen wäre. Das hätte dann aber 10 oder 20 Jahre gedauert und nicht ein Jahr. Jedenfalls: Diese Ungeduld würde ich viel stärker bekämpfen.

Und man muss es aushalten können, dass das eben so lange dauert, wie es dauert. Manche Dinge gehen vielleicht schnell und einige Dinge dauern eben sehr, sehr lange.

Genau! Gerade wenn man so große plakative Strategien wählt, dann geht das auch mit Ungeduld einher. Und das ist schwierig. 

Agilität bedeutet, besser auf Überraschungen vorbereitet und anpassbarer zu sein. Nun haben wir mit COVID-19 im März so eine unglaubliche Veränderung im Markt erlebt, wie sie zumindest in meiner geschäftlichen Schaffenszeit bisher nicht dagewesen ist. Wie agil war ein Großkonzern wie BMW als Arbeitgeber in der Lage, darauf zu reagieren? Bist du nachträglich eher positiv überrascht, dass alle sich gut angepasst haben, oder dachtest du: “Hätten wir uns in den letzten zehn Jahren mal lieber besser aufgestellt, dann hätten wir viel besser und schneller reagieren können”?

Ohne das, was wir in der IT in den letzten drei, vier Jahre an Agilität vorbereitet haben, hätten wir jetzt nicht so gut reagieren können. So ist bei uns beispielsweise auch die Infrastruktur der IT agil aufgestellt. Und dort konnte man relativ schnell auf diese Veränderungen reagieren. Wir haben zum Beispiel überhaupt kein Problem gehabt, die Leute ins Home-Office zu kriegen. Natürlich war unter anderem ein massiver Ausbau an VPN-Verbindungen notwendig. Aber die Kolleginnen und Kollegen waren da richtig kreativ. Und wir haben es geschafft, irgendwie den Betrieb vor allem auch in der Fahrzeugentwicklung aufrechtzuerhalten. Produziert wurde ja nicht, insofern war die Produktion nicht so wichtig: keine Lieferketten, keine Produktion und auch keine Kunden, weil keine Autohäuser … Aber in der Fahrzeugentwicklung hat man trotzdem weitergearbeitet, denn CAD-Entwicklung geht natürlich. Das funktioniert aber nur, wenn du die VPN-Verbindung und die benötigten Bandbreiten hast. Und das hat die Infrastruktur wirklich super hingekriegt.

Wenn du in der Branche hörst, was andere Automobilhersteller so tun: Gibt es Dinge in Bezug auf Agilität und Scaled Agile, auf die du ein bisschen neidisch bist? Bei denen du sagst: “Das kriegen die gut hin, da könnten wir uns eine Scheibe von abschneiden”?

Gut, Tesla haben wir schon genannt. Mit dieser grundlegenden Architektur in die Richtung zu gehen – das wäre etwas, wo man auf jeden Fall hinmuss. Andere gehen auch offensiv damit um – VW beispielsweise mit ihrem eigenen Betriebssystem, mit der grundsätzlichen Strategie, das Auto quasi als ein Smartphone auf Rädern entwickeln zu wollen. Solche klaren strategischen Ausrichtungen finde ich hilfreich.

Wenn du ein Buch über Skalierung von Agilität liest, welche Inhalte wünschst du dir? Was möchtest du aus so einem Buch lernen können?

Beispiele und Prinzipien wären gut. Mit konkreten Frameworks, konkreten Hilfestellungen wäre ich vorsichtig. Darum mag ich vielleicht LeSS auch so gerne, weil es von den Prinzipien herkommt und dann alles ganz einfach erscheint. Aber wie gesagt, gute Beispiele wären sehr hilfreich. 

Und wenn du jetzt mal versuchst, mit der Brille eines kompletten Anfängers da drauf zu schauen, ändert sich die Antwort dann?

Vielleicht würde es helfen, wenn man nicht nur einen Zielzustand beschreibt, also skalierte Agilität in voller Schönheit darstellt, sondern auch, wie man vom Kleinen ins Große wächst, nach dem Motto: “Wir fangen mal so an, und der nächste Schritt ist dann dieser, und dann wird es groß, und dann sind wir beim vollen Modell, wenn wir es wirklich von klein auf aufgebaut haben.” Das könnte ganz gut helfen.

Gibt es zu LeSS eine Art Klassiker wie “LeSS für Anfänger” oder etwas in der Art?

Wenn, dann habe ich es nicht gelesen. Mir fällt keins ein. Ich finde das Online-Material gut, das es dazu gibt, und auch das Training ist erstmal besser als jedes Buch. Das Training kann nicht durch ein Buch ersetzt werden. 

Der letzte Themenkomplex, über den ich gerne noch mit dir sprechen möchte, ist Atlassian-Software und Agile-Skalierung. Beschreib doch bitte mal konkret die Rolle von Atlassian-Software bei BMW. Ist es eher tangierend oder essenziell? Wie seid ihr operativ mit dieser Zusammenarbeit umgegangen?

Essenziell. Ja, das gehört schon zu unserem Kern. Jira und Confluence werden für jedes Produkt, jedes Team auf jeder Ebene verwendet. Wir haben vermutlich eine der größten Jira- und Confluence-Installationen in Deutschland.

Und wie äußert sich das im Unternehmen? Wenn du zum Beispiel mit dem Marketing oder anderen Compliance-Leuten sprichst, arbeiten sie auch schon damit oder ist das dann eher noch so, dass es dorthin ausstrahlt und gerade erst anfängt?

Es strahlt schon dahin aus. Alle, die mit der IT zusammenarbeiten, und das sind viele, oder die was von der IT wollen, werden diese Tools benutzen. Keine Anforderungen ohne Issue. Und Dokumentation findet komplett in Confluence statt. Keine Word-Files mehr. 

Wie seid ihr dahingekommen?

Wir haben eine zentrale Installation bereitgestellt. Dabei hat uns die Produktorientierung geholfen, weil bisher ja immer alles so projekthaft war. Das Projekt hat sich sein Projektlaufwerk zusammengesucht, seine Dokumente erzeugt, dann war es fertig und wurde abgelegt. Teilweise haben die Teams auch ihre Jira-Instanzen installiert, wenn sie sie gebraucht haben, und nach dem Projekt wieder abgebaut. Das ist natürlich nicht wertschöpfend. Wir haben schließlich eine zentrale Instanz hingestellt und gesagt: “So, bitte, bedient euch!” Und zwar an jeden gerichtet. Das ist auch kostenfrei für die einzelnen Stellen.

Da gibt es keine Verrechnungen, oder?

Genau, wir betreiben eine zentrale Instanz. 

Und wie sieht es mit der Performance aus? Wenn ihr solche Riesensysteme mit so vielen Usern habt, ist das ja nicht so ganz trivial.

Das ist immer wieder ein Problem gewesen, jedenfalls in den letzten Jahren. In der Cloud geht es mittlerweile eigentlich ganz gut, denke ich.  

Das muss ja eine eigene Cloud sein, denn Atlassian hört momentan bei 10.000 Usern auf.

Richtig, eine eigene Cloud. Die waren da kreativ, ja. 

Und da hat COVID-19 und Home-Office keinen Unterschied gemacht?

Ja, das war kein Problem.

Gibt es noch irgendetwas, das du der Welt mitteilen möchtest?

Nur das vielleicht: Fangt nicht mit SAFe an. Das ist zumindest meine persönliche Meinung. 

Vielen Dank für das Gespräch, Marcus!