Dierk, Falko und Luca diskutieren ihre Beobachtungen aus der Beratungs- und Trainingspraxis und versuchen daraus Erwartungen und Vorhersagen für die Zukunft von DevOps abzuleiten.
In dieser Episode des DevOps Podcasts werden verschiedene Aspekte von DevOps beleuchtet, einschließlich der Herausforderungen, die durch Stagnation in Transformationsprozessen, die Integration von KI und die Notwendigkeit der Anpassung an sich ändernde Technologien und Praktiken entstehen. Es wird diskutiert, wie DevOps immer vielfältiger wird und wie dieser Wandel sich auf Unternehmen auswirkt, mit einem besonderen Fokus auf Wertstromorientierung, Feedback-Schleifen und die Integration von Best Practices wie SRE (Site Reliability Engineering).
Inhalt
- Definition und Bedeutung von DevOps
- Der Einfluss von Team Topologies auf DevOps
- Die Rolle und Bedeutung des State of DevOps Reports
- Herausforderungen und Chancen in der Evolution von DevOps
- Die Integration von Site Reliability Engineering in DevOps
- Stagnation und Herausforderungen in DevOps-Transformationsprozessen
- Die Zukunft von DevOps und die Rolle von KI und Remote Work
- Agiles Arbeiten und Skalierungsframeworks in DevOps
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps – Auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des DevOps Podcasts
Auf die Ohren und ins Hirn, gestaltet und produziert von Luca Ingianni,
Dierk Söllner und Falko Werner. Wir sind DevOps-Trainer und Coaches
mit langjähriger Erfahrung. DevOps umfasst für uns kulturelle,
organisatorische und technische Aspekte. Mein Name ist Dirk Söllner,
ich begrüße alle Zuhörenden und natürlich auch Luca und Falko.
Hallo. Hi.
Wir freuen uns heute auf das Thema die Zukunft von Def Ops. Zu Gast haben wir
da wieder mal niemanden. Wir drei werden heute nochmals
Gedanken aus der Folge 55.
Fortsetzen. Da hatten wir ja schon mal ein bisschen dieses Thema gestreift,
ein bisschen andiskutiert. Werden wir heute nochmal fortsetzen, weil wir nämlich zu dieser Folge
55 einige Rückmeldungen erhalten haben.
Mittlerweile erleben wir drei das häufiger, dass wir in unseren Schulungen zu Def Ops
auf diesen Podcast angesprochen werden, respektive, dass wir in unseren Schulungen
auf den Podcast verweisen können. Und da haben wir, wie gesagt, einige Rückmeldungen
erhalten, dass die Zukunft von Def Ops ja nochmal ein bisschen vertieft werden könnte.
Das tun wir heute gerne. Und wir wollen ganz kurz zu Beginn das machen, was wir mit unseren Gästen
immer machen. Denn wir fragen unsere Gäste ja immer zu Beginn nach ihren Sichten auf Def Ops, nach ihrer
persönlichen Definition. Also wie definiert unsere, wir definieren unsere Gäste Def Ops.
Und ich würde da oder nicht, ich würde, ich tue eins.
Ich verweise immer gerne auf die Definition von Tobias Weinmann aus der Folge 7, also ist schon ein
bisschen her.
Ich würde sagen, dass ich meine Gäste Def Ops damals als nachhaltige Geschwindigkeit unter
Berücksichtigung der drei Wege von Jim Kim definiert.
Natürlich gibt es verschiedene Ausprägungen und die haben sich auch aktualisiert.
Aber für mich ist der Text nach wie vor der Aufbau hoch performanter IT-Organisation, dass wir
müssen in der IT aus meiner Sicht schneller und hochwertiger werden und schneller allein
reicht nicht, wenn wir eben keine Qualität liefern und hochwertig allein reicht nicht, wenn
wir immer nur zu spät liefern oder Teile zu spät liefern.
Das heißt.
Aus meiner Sicht liefert Def Ops viel hilfreiche Ansätze, um beides zu verbinden, also sicherzustellen,
dass wir schneller und hochwertiger liefern.
Luca, was ist deine Definition?
Oh Mann, nicht schon wieder.
Ich war doch schon erst in der vergangenen Folge über BDD dran.
Insofern auch im Interesse der Kürze.
Liebe Hörer, wenn euch meine Definition interessiert, dann hört euch doch einfach die Folge über BDD an.
Die ist ohnehin hörenswert.
Da ist auch eine Definition drin.
So cool.
So kann man auch auf die eigenen.
Alte Folgen hinweisen, wobei so alt ist die ja noch nicht.
Nee, die kam ja raus zum Zeitpunkt der Aufnahme am vergangenen Wochenende.
Ja, perfekt.
Falko.
Ja, wir haben ja alle schon unsere Definitionen in dem Podcast an verschiedenen Stellen breitgetreten.
Aber eine, die noch nicht vorgeschlagen worden ist, ist eine, die Luca und ich uns zusammen für die Def Ops Days in Magdeburg dieses Jahr überlegt haben.
Und zwar in dem Fall auf Englisch.
At its core, Def Ops is empowering organizations to drive value for all stakeholders.
Mit einem Hinweis, dass zu all stakeholders jeder betroffen ist.
Das heißt, der Entwickler, das Unternehmen, die Unternehmenseigner, die Kunden.
Und insofern ist das für mich eigentlich ein Weiterdenken des Agilitätsbegriffs.
Ob man das nur in einem skalierten Umfeld macht.
Ob man das nur in einem Enterprise-Umfeld wirklich mit vielen, vielen Teams macht.
In einem kleinen Team eine App, eine kleine Web-Anwendung oder ähnliches.
Wenn man dabei den Kundenfokus im Blick behält.
Das heißt, schnell Kundenanforderungen nach den Vorstellungen des Kunden, also mit hoher Qualität, auch liefern zu können.
Dazu hilft Automatisierung.
Dazu hilft Verschiedenes, zum Beispiel Wertstromanalyse.
Value-Stream-Mapping und andere Dinge.
Und insofern würde ich zurück an Dirk geben und hoffen, dass das eine gute Beschreibung ist.
Ja, das sollen andere entscheiden, ob das gut war.
Auch das ist ja ein Punkt, dass Def Ops ja auch sehr vielfältig ist.
Und insofern gibt es auch vielfältige Sichten darauf.
Gut, dann lasst uns mal inhaltlich starten oder weitermachen.
Und wenn wir über die Zukunft von Def Ops reden, dann ist es ja hilfreich,
auch mal ganz kurz ein bisschen in die Vergangenheit zu gucken und vielleicht auch sich andere Quellen zunutze zu machen,
die auch über State of Def Ops reden.
Also insofern State of Def Ops Report ist ja etwas, was wir auch in unseren Schulungen häufiger nutzen,
was immer einen ganz guten Blick auf den jeweiligen Status von Def Ops bringt.
State of Def Ops Report kommt einmal im Jahr raus, ist von Gene Kim ursprünglich mal sozusagen aufgebaut worden.
Mittlerweile.
Das heißt, es ist eine feststehende Institution.
Und wenn man da mal zurückschaut, 2016 haben sie auf Punkte geschaut, wie Versionsverwaltung ist, die vorhanden ist,
Monitoring im Einsatz, wie sieht es beim Teamwork aus?
Also haben da zum Beispiel solche Erkenntnisse gewonnen.
Sie haben 2017 so ein bisschen geschaut, wo können wir hochperformante und nicht zu hoch performante IT-Organisationen vergleichen.
2018, 2019 ging es weiter.
2020 haben sie Plattformen so ein bisschen rausgehoben.
Und 2022, das wäre der aktuelle, der ist gerade am Laufen.
Das heißt, den aktuellen State of Def Ops Report gibt es eben noch nicht.
Die Umfrage, die Ausweitung läuft gerade, sodass wir uns auf den State of Def Ops Report 2021 kurz stürzen.
Also wie gesagt, wir machen das kurz, weil wir ja in die Zukunft gucken wollen.
Aber wie gesagt, ich denke, dass man auch mit Blick in die Vergangenheit ein bisschen was in Zukunft erzählen kann.
Und wenn man sich das State of Def Ops Report 2021 anschaut,
ist es so, dass nach wie vor noch viele Unternehmen gegen kulturelle Blockaden kämpfen.
Also Aussagen, die wir auch immer wieder hören, das haben wir schon immer so gemacht oder warum sollen wir etwas ändern?
Läuft doch. Also solche Punkte sind aus unserer Sicht, aus meiner Sicht, Indikator für kulturelle Blockaden.
Und wenn man sich den Report anschaut, zeigt er, dass man einfach, dass es dort hilfreich ist, eine Top-Down-Unterstützung, der Bottom-Up-Transformation zu haben.
Also im Prinzip das.
Um abzusichern, was Def Ops bedeutet, also eine Veränderung.
Und da reicht es nicht aus, Top-Down vorzugehen, sondern ein Punkt, den ich für wichtig empfinde, hilfreich ist es, Top-Down-Unterstützung bei einer Bottom-Up-Transformation.
Und wenn man das in die Zukunft jetzt mal transformiert, glaube ich, muss dann noch sehr viel mehr Wissen, sage ich mal, auch in die Top-Ebenen gebracht werden.
Also Top, wenn ich Top-Down vorgehe, muss ich auch Wissen in die Top-Ebenen bringen.
Und ich muss viel mehr Bottom-Up unterstützen, indem ich ausbilde, indem ich einfach auch dort Experimente unterstütze, indem ich das absichere oder unterstütze, dass es von unten nach oben kommt.
Luca, Falko, passt das für euch so?
Ja, ich denke, dass es sinnvoll ist, bei Transformationen zumindest an Stellen anzufangen, wo es Freiwillige gibt, die Interesse haben, die ein Verständnis dafür haben, um dann im Unternehmen aus den Erfahrungen profitieren zu können.
Das sind Ansätze, die wir mit verschiedenen Kunden auch so in der Form umsetzen.
Und ab einem bestimmten Zeitpunkt, wenn es über Teamgrenzen oder Bereichsgrenzen hinausgeht, kommt man ohne Top-Down-Unterstützung nicht voran.
Und an der Stelle kommt man entweder auf eine Blockade und bleibt irgendwo stecken.
Oder man kriegt dann Top-Down-Unterstützung.
Oder, wenn man es schafft, schon vorher Management-Unterstützung.
Von den Entscheidern, von der Geschäftsführung und anderen Top-Down-Unterstützern zu bekommen und sie frühzeitig ins Boot zu holen, hat man noch ein paar andere Vorteile.
Deswegen ist es sinnvoll, das beides zu kombinieren und immer auch den Support, die Unterstützung aus den Entscheidungsebenen im Unternehmen mit einzubinden.
Zweiter Punkt, der in dem State-of-Dev-Obs-Report angesprochen wird, ist das Thema Teamverständnis und klare Regelungen sind hilfreich.
Und insbesondere wird im Dev-Obs-Report darauf abgehoben, dass der Ansatz von Team-Topologies dort sehr viel bewirkt hat und sehr hilfreich ist.
Da können wir, wenn wir jetzt wieder hier unsere eigenen Folgen bewerben, auf die Folgen 42, 43 und 46 verweisen.
Das heißt, wir haben im letzten Jahr schon Team-Topologies auch hier im Podcast bearbeitet.
Und das ist einfach wichtig. Und auch das ist wieder, wenn man in die Zukunft guckt, wichtig.
Dass so ein Teamverständnis ausgeprägt wird, dass klare Regelungen ausgeprägt werden.
Das heißt, es reicht einfach nicht aus, sozusagen wir machen Dev-Obs, sondern dass man wirklich dort Regelungen schafft,
die dafür, die sicherstellen, dass Dev-Obs zum Beispiel zusammenarbeiten in der einfachsten Form.
Wir haben nachher noch ein paar andere Themen, weil Dev-Obs ist ja viel vielfältiger,
aber wirklich klare Regelungen und klare organisatorische Regelungen sind enorm hilfreich und enorm wichtig.
Luca?
Team-Topologies ist doch dein Steckenpferd, oder?
Ja, das ist mein Steckenpferd. Und ich möchte da auch auf eine Sache hinweisen, die sehr wichtig ist,
einerseits für Team-Topologien, aber auch ganz allgemein für Dev-Obs.
Nämlich, wenn man Team-Topologies liest, dann weisen sie auch darauf hin, dass es vollkommen gewöhnlich und erwartbar ist,
dass sich Team-Strukturen und damit einhergehend natürlich auch Produktarchitekturen wandeln im Laufe der Zeit.
Die sind einer stetigen Veränderung unterworfen. Das ist vollkommen normal.
Und das ist eine ganz gute Neuigkeit, finde ich, weil man ist nicht gezwungen, es aufs erste Mal richtig zu machen,
sondern man macht halt mal einen Versuch und man wird natürlich Schwächen feststellen bei dem,
was man sich da so zusammengereimt hat. Ja gut, dann geht man halt her und macht es besser.
Also ein iterativer, agiler, wertgetriebener Ansatz ist nicht nur auf der Produktebene hilfreich und sinnvoll,
sondern natürlich auch auf der Organisationsebene.
Und das ist mir, glaube ich, ganz wichtig, darauf hinzuweisen. Ich glaube, dass das Bewusstsein dafür auch wächst,
dass das ist das, was ich auch im Dialog immer wieder mal erlebe mit den Kunden,
dass so eine DevOps-Einführung ist halt nicht irgendwie, du gehst her und stülpst der Organisation was Neues über
und dann bist du irgendwie fertig und reitest in den Sonnenuntergang,
sondern das ist der Startschuss für eine neue Art des Zusammenwirkens, des Zusammenarbeitens,
in der Wandel eine Konstante ist in einem gewissen Sinne.
Und das völlig positiv gemeint. Wir lernen ständig mit und nutzen das, was wir lernen.
Ja, wenn man das dann wieder in die Zukunft projiziert, wir reden über die Zukunft von DevOps,
ist eigentlich der Punkt.
Dass das quasi die Zukunft ist. Also fortwährend lernen, fortwährend Erfahrungen machen,
fortwährend Organisationen anpassen und so weiter.
Ja, auch vielleicht wegzukommen von den sehr großen Schwungweisen,
einmal alle zwei, drei, vier Jahre stattfindenden Change-Prozesse,
hin zu einem kleinen, in kontinuierlichen Ansatz ablaufenden Veränderungsprozess.
Damit man einerseits nicht die Überlastung hat, was natürlich bei Team Topologies auch so,
ein Thema ist, kognitive Last zu reduzieren.
Nicht nochmal zusätzliche Last durch Veränderungsprozesse, große Change, Reorganisationen
und andere Vorgehensweisen zu produzieren, sondern halt an den Stellen zu optimieren
und das immer wieder zu tun, zum Beispiel durch Retrospektiven oder Inspect and Adapt Workshops
oder ähnliche Vorgehensweisen, um eben nicht die Notwendigkeit auch zu haben
für solche großen Umstellungen, Umstrukturierungen.
Ja, in kleinen Schritten vorwärts gehen, ne?
Ja, okay.
Dann lasst uns noch den dritten Punkt kurz rausnehmen aus dem Set of DevOps Report,
den ich quasi so ausgelesen habe.
Ich habe den mal zusammengefasst oder übersetzt mit dem Thema
Automation und Cloud sind allein nicht DevOps.
Ja, natürlich kann ich Dinge automatisieren, dann kann ich auch sagen,
ich mache DevOps, aber das allein reicht.
Das heißt, der State of DevOps Report hat quasi rausgefunden,
dass hochentwickelte Unternehmen im DevOps,
im DevOps-Kontext besser automatisieren als andere
und das hochentwickelte Unternehmen im DevOps-Kontext auch die Cloud sinnvoller nutzen.
Also das heißt, natürlich kann ich Cloud-Angebote nutzen
und dann kann ich auch sagen, ich mache DevOps, lassen wir mal,
oder ich lasse es mal unkommentiert, aber eben der State of DevOps Report zeigt,
wenn ich Automation und Cloud wirklich gut nutze, sehr gut nutze, sinnvoll nutze,
dann bin ich auch erfolgreicher im DevOps-Kontext.
Also reicht es nicht, sich bei Microsoft in der Azure Cloud
die DevOps-Produktportfolios zu nutzen, die dann Azure DevOps heißen
und dann ist man fertig, ne?
Nein, nein, nein.
Du hast vergessen, den Ironie-Modus anzuschalten
oder auf den Ironie-Modus hinzuweisen.
Ja, das hört man mit meiner verstopften Nase gerade nicht.
Ja, ist okay.
Okay, dann lasst uns mal wechseln oder weitergehen.
Das war jetzt ja sozusagen der weltweite Blick, State of DevOps.
Und wir haben ja auch ein paar Kunden und da können wir auch ein bisschen berichten,
was unsere Kunden so erleben oder was wir bei unseren Kunden erleben.
Und ich würde sagen, Luca, hast du noch eine Idee von deinen Kunden,
was deine Sicht da ist, was deine Erfahrungen sind?
Ja, also wenn ich jetzt wieder so die Rückschau gehe,
als ich angefangen habe, das Thema DevOps in andere Unternehmen reinzutragen,
da war noch viel weniger Verständnis dafür da,
was das bedeutet, warum das wertvoll ist, was das überhaupt ist.
Das Witzige ist wahrscheinlich, das ist heutzutage immer noch nicht anders,
weil ihr wisst ja, wie es läuft, wenn man zehn Leute nach ihrer DevOps-Definition fragt,
kriegt man 20 Antworten.
Aber ich glaube, das Verständnis davon, dass das ein wichtiges Thema ist,
egal wie man es jetzt eigentlich fasst und wo man die Grenzen zieht,
das ist schon gewachsen.
Aber nichtsdestotrotz gibt es, glaube ich, immer noch einen verbreiteten Zweifel,
ob das etwas ist, was wertvoll ist für meine Organisation,
ob das etwas ist, was zu meiner Organisation passt.
Insbesondere auch, weil ich zunehmend beobachte, dass man erkennt,
dass man an die Grenzen der IT-Organisation stößt, beziehungsweise sie durchbricht.
Deswegen möchte ich da so ein bisschen auf deine DevOps-Definition von der Eingangsfrage hinweisen.
Dirk, die ich vor wahrscheinlich zwei Jahren noch voll unterschrieben hätte und wo ich jetzt,
gerade als ich dir zugehört habe, gefragt habe, hoch performante IT-Organisationen,
ob das denn noch reicht oder ob man nicht sagen muss, eigentlich gehört da viel mehr dazu.
Eigentlich müssen wir auch,
IT-Fremde, um es jetzt mal so auszudrücken, Kollegen mit einbinden,
sei das jetzt das Controlling oder sei das das Produktmanagement oder sei das, wer du möchtest.
Wenn du die Arbeitsweisen, die Verhaltensweisen und schlussendlich das Aussehen und Verhalten
deiner IT-Organisation änderst, wird das notgedrungen ausstrahlen
auf den ganzen Rest der Organisation und auf die Art und Weise, wie du Produkte schaffst.
Und das ist etwas, was ich zunehmend beobachte, dass das erkannt wird.
Häufig sozusagen im negativen Sinne, dass die Leute sagen,
also ich würde mich ja so gerne transformieren,
aber ich knall die ganze Zeit irgendwo vor eine Wand.
Mein Controller sagt, nö, so machen wir das nicht oder sowas.
Das nämlich zunehmend als Thema war,
dass man die Grenzen der klassischen IT-Abteilungen sprengt.
Sprengt oder sprengen müsste, also dass man quasi die Überzeugung,
dass DevOps hilfreich ist, das ist ja erstmal eine Philosophie,
es ist ja nicht irgendein Framework, es ist eine Philosophie,
es verändert an vielen Stellen Dinge und dass man das eben über die IT hinausbringt,
also das würde ich jetzt auch sagen, das ist auch aus meiner Sicht eine Wahrnehmung
und wenn man jetzt wiederum auf die IT guckt,
wir sagen ja mit DevOps versuchen wir Entwicklung und Betrieb zusammenzubringen.
Ich habe einige Kunden, die stellen immer noch fest, dass Ausschreibungen,
also große IT-Ausschreibungen genau das immer noch trennen.
Also da gibt es eine Ausschreibung für die Entwicklung und eine Ausschreibung für den Betrieb.
Ja, siehst du.
Ja, und insofern, das ist genau der Punkt.
Da ist irgendein Management, da gibt es irgendeine Juristik,
Juristische Abteilung, Kontrolling, Einkauf, wie auch immer,
die denken noch in alten Aspekten und sind wahrscheinlich auch schwierig zu überzeugen,
weil die IT kommt jetzt, hey, lass uns DevOps machen.
Ja, warum soll man DevOps machen?
Also das ist, also wenn wir auch in Zukunft wieder gucken, ein wichtiger Punkt,
quasi den Nutzen von DevOps, das Konzept von DevOps und eben auch die Vorteile für das Unternehmen,
aber auch die Konsequenzen von DevOps wirklich aus der IT hinauszutragen in die restliche Welt,
weil die restliche Welt ist ja da.
Und die haben auch ihre Aufgaben und haben auch ihre Ziele, die sie erreichen müssen.
Ja, letztendlich muss man von Kunde zu Kunde denken.
Also vom Kunden mit der Anforderung zurück über die ganzen Prozesse, Fachbereiche, Entwicklung, Architektur,
was auch immer so dazwischensteckt, bis man die Kundenanforderung wieder realisiert,
dem Kunden als Feature, als neues Produkt anbieten kann.
Und da hilft natürlich DevOps mit der Automatisierung.
Ja, aber das finde ich auch spannend.
Dass du das so gesagt hast, weil ich glaube, an der Stelle sind auch zunehmend IT-Organisationen
und insbesondere deren Leitung in der Pflicht, anderen Unternehmensteilen das wirklich zu erklären,
inwieweit die da auch einen Beitrag haben, einen Einfluss haben.
Weil ich könnte mir gut vorstellen, dass zum Beispiel ein Personaler nicht ganz zu Unrecht sagt,
was habe ich mit dem Kunden und dem Produkt zu tun?
Ich erbringe hier eine rein interne Funktion.
Macht ihr mal euer Ding.
Aber ich mache weiter meins.
Und natürlich sind diese Leute weder dumm noch gemein noch sonst irgendwas,
aber ich finde, sie haben durchaus ein Recht darauf,
dass man ihnen erklärt, inwieweit notwendig ist,
dass sie auch einen Beitrag leisten, indem sie vielleicht ihre Herangehensweisen ändern,
ihre Sichtweisen ändern.
Zum Beispiel, so wie du gesagt hast, Dirk, Projektausschreibungen anders fassen.
Ja, die Kundenkommunikation letztendlich auch mit einzubeziehen.
Das ist bei vielen Unternehmen halt die Schwierigkeit, die dann halt sagen,
okay, wir haben halt aus der öffentlichen Hand,
aus irgendwelchen anderen jahrzehntelangen eingeschwungenen Prozessen mit unserem Kunden
klassische Projektvorgehensweisen.
Und da steht halt eine Entwicklung, die wird halt dann ausgeschrieben.
Und wenn das dann soweit ist, dann ist das Produkt da.
Und dann geben wir es vielleicht auch ganz bewusst, ganz gerne an ein anderes Unternehmen,
mit dem wir halt gute Erfahrungen im Ops-Bereich haben.
Dass man dadurch natürlich gewisse Dinge verliert,
nämlich Kommunikationsprozesse, Feedback-Schleifen und anderes,
die dann auch der Wertschöpfung, in der Wertschöpfung, in der Wertschöpfungskette fehlen.
Das muss man natürlich an der Stelle dann erstmal bewusst machen.
Ja, ich finde auch, das ist ein ganz wichtiger Punkt, den ihr eben angesprochen habt.
Das ist eben immer noch dieses Projektdenken.
Und wir hatten ja über Team-to-Producties gesprochen.
Also ist ja eher eine Produktorganisation.
Und wenn ich natürlich Unternehmen habe, die auch in der Zusammenarbeit voll auf Projekte ausgerichtet sind.
Das ist ja auch da quasi.
Den Tanker muss der auch da sein.
Da musst du ja auch wirklich umorientieren in Richtung Produkte, Produktteams, Produktorganisationen.
Also auch da sehe ich diese Schwierigkeiten.
Und wir reden ja über die Zukunft.
Mir ist da nicht bange, weil ich eben sehe, dass die beteiligten Experten dort offen sind.
Also in den Trainings haben wir ja häufig, also ich kann es ja nur von mir sagen,
habe ich häufig die Experten, die Experten, die Fachexperten.
Und die sind da häufig offen.
Das heißt, die sagen, dass sie den Sinn verstanden haben,
dass sie die Konsequenzen verstanden haben
und versuchen, das in kleinen, kleinen Schritten umzusetzen.
Aber natürlich kommt man nicht aus den großen Punkten raus, aus der, aus einer Projektdenke.
Da muss man wirklich organisatorisch ran.
Also insofern, in die Zukunft geblickt, glaube ich, müssen wir es hinbekommen,
dass wir das Expertenwissen für IT auch organisatorisch umsetzen.
Ich möchte aber auf der Stelle einhaken, weil wo ich uns so zuhöre,
fällt mir da gerade irgendwie ganz gewaltig was auf.
Weil wir reden da jetzt irgendwie ganz gelassen davon.
Ja, Projektdenken ist böse.
Und Produktdenken ist gut.
Und ich frage mich, inwieweit in vielen Organisationen überhaupt klar ist,
was wir damit meinen.
Zum Beispiel, wenn wir mit diesen Begriffen um uns schmeißen.
Das ist, glaube ich, genau die Krux.
Wir gehen hier ganz lässig mit so einem Jargon um,
das vielleicht anderen gar nicht geläufig ist.
Und die vielleicht vollkommen nachvollziehbar finden,
wovon wir reden, wenn es ihnen nur mal jemand erklärt.
Was meinen wir denn eigentlich mit diesem Unterschied
zwischen Projekt- und Produktdenken, Dirk?
Naja, ich meine, das ist ja eine meiner,
meiner Lieblingsfolien von unserer Grundlagenschulung.
Nämlich genau von Aktivitäten orientiert zur Teamorientierung.
Und da kommen wir wieder auf den anderen Punkt zurück,
zu der Veränderung, die wir eben angesprochen haben.
Das heißt ja zum Beispiel, dass ich wegkomme von Spezialisten.
Dass ich hinkomme zu T-Shirt.
Und insofern ist es hilfreich,
wenn man diese Menschen in der Schulung sitzen hat,
weil da hast du ja die Spezialisten.
Und dann sagst du denen, wir brauchen euch nicht mehr.
Und das muss man natürlich erklären.
Weil wir brauchen die Spezialisten ja schon noch.
Aber ich glaube, Falko hat ja noch viel mehr Projekterfahrung.
Ob das so viel mehr ist, weiß ich nicht.
Aber ich möchte gerne an der Stelle
zwischen eher kürzeren Projekten,
die ein, zwei Jahre oder ähnliches laufen,
die für die Zeit ein Team zusammenstellen,
das dann hinterher wieder aufgelöst wird,
wo das Ergebnis dann an ein anderes Team übergeben wird,
das dann den Betrieb macht,
hin zu dem Produktdenken mit einem Produktlebenszyklus,
von der Initiierung, von dem Entwicklungsprozess
über einen Reifeprozess hin zu einem Betrieb,
das letztendlich von einem Team langfristig begleitet wird,
wo sich vielleicht das Team über die Zeit so ein Stück entwickelt,
auch vielleicht anders ausrichtet.
Vielleicht auch das eine oder andere Teammitglied wechselt
in ein anderes Unternehmen oder andere Bereiche.
Aber von dem Gedanken her am Produkt bleibt
und damit auch am Kunden bleibt
und somit auch eine Erfahrung aufbaut,
die ein Projektteam bei der Übergabe in den Betrieb
dem Betrieb nicht mitgeben kann.
Dass das einfach in den Köpfen mit dem Produkt gewachsenes Wissen
eben auch am Produkt bleibt
und das Expertentum halt nicht in einer Tätigkeit,
wie du es gerade beschrieben hast,
so ein Datenbankmanagement-Team oder IT-Betrieb,
oder Security-Team hat,
sondern dass man halt ein produktfokussiertes Experten-Team hat
mit einem Kundenbezug,
wo man letztendlich auch die Kundenbindung immer weiter treiben kann.
Das ist für mich der Kernaspekt dieser Produktdenke,
die man nutzen kann im DevOps-Umfeld,
weil eben Produkte für gewöhnlich eine längere Laufzeit haben.
Wenn ich mir anschaue, welche großen Mainframe-Systeme
da teilweise immer noch bei vielen Unternehmen laufen,
dann weiß ich, dass das nicht so einfach ist.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das ist ein sehr guter Punkt.
Das sind ja dann eher Jahrzehnte als Jahre oder Monate.
Im Gegenzug sind Projekte halt eher Monate bis maximal zwei, drei Jahre.
Das ist auch ein interessanter Punkt, den du da gerade ansprichst,
auch mit lange währenden, zum Beispiel Mainframe-Systemen oder sowas.
Ich weiß nicht, wie es euch geht,
aber das ist etwas, was ich zunehmend beobachte auch in den Gesprächen,
dass Organisationen sich auch dessen bewusst werden,
dass sie noch über längere Frist oder vielleicht sogar sehr langfristig
noch zweigleisig fahren müssen,
dass sie eine in Anführungszeichen moderne Produktentwicklung,
von neuen Produkten haben, die auf die eine Weise funktioniert,
die den einen Produktbegriff hat und dass sie zum anderen
aber auch noch gewachsene Strukturen, Mainframes, was auch immer haben,
die sie noch auf lange Sicht pflegen müssen
und die vielleicht ganz andere Rhythmen erfordern,
die vielleicht auch andere Strukturen erfordern.
Man denke an Conway’s Law.
Wenn ich eine Mainframe-Applikation habe und die hat eine Architektur,
dann kann ich da nicht irgendwelche beliebigen anderen Teams aufpropfen.
Das endet ja in Tränen.
Ja.
Ist das auch etwas, was ihr beobachtet?
Ja, das kann man machen.
Aber hat man…
Natürlich größere Schwierigkeiten.
Das ist wie immer.
Man kann vieles machen.
Man sollte aber nicht alles, was man kann, auch tun.
Aber einfach auch so dieses Bewusstsein so,
wir können gar nicht unsere ganze Organisation hier so peng neu ausrichten,
sondern wir müssen das scheibchenweise machen
und es wird vielleicht sogar einige Scheiben der alten Organisation geben,
die noch sehr lange Bestand haben werden
und wir müssen uns was einfallen lassen, wie wir damit umgehen.
Ja, das hört man im CIO-Bereich halt häufig.
Da gibt es ja diese multimodalen IT-Umgebungen,
die modal halt mit unterschiedlichen Geschwindigkeiten arbeiten.
Klassische rechenzentrumgetriebene Produkte,
die man halt schon lange selbst hostet
und vielleicht auch neuere, eher cloudartig ausgerichtete,
vielleicht auch wirklich mit einem Cloud-Anbieter zusammenarbeitende Infrastrukturen,
die dann außer Haus betrieben und bereitgestellt werden,
sind natürlich dann Aspekte, die man dabei bewerben muss.
Das ist der Aspekt der unterschiedlichen Plattformen,
die wir halt auch in den State-of-Devops,
in den State-of-Devops-Reports sehen.
Dirk, magst du dazu noch was sagen?
Ja, weil ich dort auf meine Definition wiederkomme,
weil multimodal oder bimodal,
was ja vor Jahren hochgehypt wurde durch ein paar Berichte auch von BMW und so weiter,
auch durch Unternehmensberatungen,
klassische Bekannte, die das als Idee verkauft haben,
hat immer für mich das Geschmäckle dabei,
dass schnell gut ist.
Also die einen sind schnell und die anderen sind langsam.
Der wird schon langsam sein.
Deswegen multimodal, wenn ich das mache oder bimodal,
dann, ich habe bei der Meinung da auch ein bisschen geändert.
Wichtig ist aber, dass man klar macht,
schnell muss nicht immer gut sein.
Beziehungsweise andersherum, ich habe Gründe,
weswegen ich vielleicht in bestimmten Umgebungen gefühlt langsamer bin,
aber trotzdem eine gute Qualität liefere.
Und für die Schnellen heißt es wirklich auch Qualität liefern.
Ganz wichtig.
Ich würde sogar so weit gehen zu sagen,
schnell ist eine Konsequenz von gut.
Wenn ich die Sachen gut mache,
dann werde ich in der Konsequenz daraus schneller werden.
Ich muss nicht noch mehr Schleifen drehen.
Ich muss keine Schaden auswetzen.
Da gibt es diesen Spruch, den ich, glaube ich, gehört habe bei den US Marines,
die immer sagen, slow is smooth and smooth is fast.
Was heißt das auf Deutsch?
Langsam ist geschmeidig und geschmeidig ist schnell.
Gut, das muss ich sacken lassen.
Ja, aber es ist letztendlich ja ein Thema,
dass man in der DevOps-Welt mit zum Beispiel groß angehäuften,
technischen oder anderen Schulden,
das sind ja nicht finanzielle,
können ja aber auch organisatorische oder soziale oder Wissensschulden sein,
dass die Mitarbeiter letztendlich in einem Unternehmen unterwegs sind,
bei dem viel auf die Zukunft projiziert wird,
auch Aufgaben in die Zukunft projiziert werden auf dem Weg,
die dann letztendlich als Hürde in der Zukunft im Weg stehen.
Also wenn man schnell sein will,
dann muss man entsprechend auch gut arbeiten,
damit man in Zukunft auch weiter schnell,
schneller sein kann.
Nachhaltige Geschwindigkeit, ne Dirk?
Also ich finde, was wir gerade zu tun ist,
wir philosophieren ein bisschen.
Und ich würde dieses Philosophieren mal so ein bisschen nutzen,
um auch wieder in die Zukunft zu gucken.
Ich habe ja immer wieder gesagt,
dass für mich DevOps eine Philosophie ist,
es ist ja kein Framework.
Das macht es auf der einen Seite vielleicht ein bisschen einfacher,
weil man nicht ein Framework einführen muss
und sich dabei die Finger vielleicht verbrennt
und auch vielleicht zu sehr durch das Framework eingeengt wird.
Natürlich auch mit der Herausforderung,
diese Philosophie immer wieder zu erklären.
Und was ich eben dabei positiv finde,
ist, dass durch diese Akzeptanz von DevOps,
dass eben auch die Philosophie immer stärker weiter verbreitet wird.
Das heißt eben Frameworks in anderen Frameworks wie IT4, wie SAVE,
da sind weiterhin DevOps-Ansätze mit drin,
DevOps-Ansätze werden eingebaut.
Das heißt also, die Gedanken, die Philosophie von DevOps,
die werden quasi damit auch in die Menge oder in die Breite getrieben,
weil eben andere Frameworks erkannt haben,
das ist hilfreich, das ist akzeptiert.
Und insofern wird dadurch auch DevOps quasi wirklich in die Breite verteilt.
Und das erleben wir auch, das hatten wir eben schon gesagt,
wir erleben immer wieder IT-Mitarbeiter, die das verstehen.
Wenn du auf erfahrene IT-Mitarbeiter schaust,
dann sagen sie, dass sie das schon früher gemacht haben.
Also früher haben schon DevOps zusammengearbeitet.
Und das kann man natürlich bei entsprechender Motivation
auch wiederum nutzen und einbringen.
Also insofern, was ich eben in Zukunft blickend positiv finde, ist,
es gibt eine ganze Reihe von Best Practices aus der Praxis,
die fließen in die Philosophie ein.
Also die müssen nicht in einem Framework niedergeschrieben werden,
sondern die fließen in die Philosophie ein.
Und ein schönes Beispiel haben wir ja vorhin schon angesprochen,
das ist Team Topologies.
Also in die Zukunft blickend, sage ich mal, was ich schön finde,
ist, das ist eine Philosophie und die lebt, die erweitert sich,
die wird besser durch viele Beispiele aus der Praxis
und das stimmt mich auch hoffnungsfroh für die Zukunft.
Ich finde, das hast du toll gesagt.
Und ich finde es immer wahnsinnig ermutigend,
wenn alte Hasen dann in den Trainings drin sitzen und sagen,
ja, das haben wir doch früher auch schon so gemacht.
Ich finde, das ist eine ausgezeichnete Neuigkeit,
weil das heißt, so blöd können diese ganzen Ideen ja alle gar nicht sein.
Und es ist ja auch so, also DevOps, wenn man ehrlich ist,
enthält ja gar nicht wirklich was Neues, noch nie Dagewesenes.
Das integriert Teile von Agile, die von sich aus schon eine gute Idee waren.
Und übrigens auch die agile Idee natürlich ist bestimmt viel älter,
als das agile Manifest, das 2001 verfasst wurde,
sondern das ist das, was in meinem Ingenieurstudium
mir meine Professoren immer als ingenieurmäßiges Vorgehen verkauft haben.
Insofern, ich glaube, das ist, wie gesagt, das ist eine ganz tolle Nachricht.
Und wie wir, glaube ich, auch schon beobachtet haben,
in diesem Sinne hat DevOps auch einen gewissen Siegeszug angetreten.
Der Begriff hat sich einfach verfestigt.
Viele andere Frameworks wollen jetzt auch ein Stück vom Kuchen haben.
SAFe spricht auch über DevOps.
ITIL 4 spricht auch über DevOps.
Erstens über den Begriff, aber zweitens natürlich auch über die Inhalte
und Herangehensweisen, zum Teil haben sie die auch selber gefunden,
sehr zu Recht, weil sie machen ja Sinn.
Wo wir gerade so mit Abkürzungen um uns geworfen haben,
mit SAFe und ITIL, in unserer IT-Blase,
da kann man einfach voraussetzen, dass das bekannt ist.
Was ich aber immer sehr schön finde, das ist ja so ein bisschen ironisch,
das sind die ganzen tollen Abkürzungen, die wir in der IT immer haben.
Und wenn ich jetzt von DevOps spreche und wir in die Zukunft blicken wollen,
was machen wir denn mit?
No-Ops, DevSecOps, DevTestOps, BizDevOps, DevDevBuffBuff,
also diese ganzen Begrifflichkeiten, die man da kombiniert,
das ist ja auch eine Herausforderung aus meiner Sicht,
diese ganzen angrenzenden Themen oder auch beinhaltenden Themen rein zu integrieren,
in die Philosophie reinzubringen.
Was ist da eure Erfahrung?
Ja, das ist ein heißes Eisen.
Das haben wir, glaube ich, schon ein paar Mal angesprochen jetzt.
Es geht wirklich darum, dass da auch Bewusstsein wächst.
Ich meine, wir sprechen immer von DevOps, so als ob es nur Dev und Ops betreffe,
aber das ist ja gar nicht wahr, sondern DevSecOps ist momentan ein Thema,
das in aller Munde ist, sehr zu Recht natürlich,
wobei ich persönlich mich dann immer so ein bisschen wundere, warum man das raushebt.
Ich bin ja ein alter Softwarequalitäter.
Ich persönlich bin immer sehr begeistert von DevTestOps.
Insofern, ich glaube, da wächst einfach vieles zusammen, was zusammengehört.
BizDevOps, DevTestOps, DevSecOps, was du möchtest,
alles, was halt in den Wertstrom rein muss,
alles, was dazu beiträgt an Aktivitäten und Sichtweisen,
um Wert für den Kunden bereitzustellen.
Und das ist natürlich ganz, ganz vieles.
Genau. Letztendlich bildet das doch die verschiedenen Walls of Confusion,
also die letztendlich Silo-Grenzen, die ein Unternehmen hat, ab.
Die können von Unternehmen zu Unternehmen unterschiedlich sein.
Und viele agile Teams, die Testen im Team verankern,
haben natürlich DevTestOps mit im Blick.
Das ist ein Video, was häufig ein bisschen weiter entfernt ist
von der reinen Entwicklung und auch vom reinen Betrieb.
In verschiedenen Organisations-Aufbauorganisationen
ist halt die IT-Security, da ist sicherlich auch Datenschutz dabei.
Wenn man sich mal den Prozess anschaut,
so klassische Wasserfall-Prozessstufen,
sind das ja auch irgendwo Walls of Confusion,
wo Übergaben von verschiedenen aufgabenorientierten Teams
zu anderen aufgabenorientierten Teams fällig sind.
Und letztendlich ist es eine Abbildung
der verschiedenen Walls of Confusion, die man hat,
die man versuchen sollte abzubauen.
Nicht unbedingt immer mit dem Ansatz auf die Wall of Confusion
irgendjemanden als Rolle draufzusetzen,
der dann die Transformation macht,
also zwischen Dev und Ops den DevOps-Engineer,
der halt dann die gebauten Pakete nochmal, keine Ahnung,
überprüft und betriebsfähig macht.
Oder den Product Owner zwischen Business und Entwicklung.
Das kann man unbedingt mit einer Rolle machen.
Man kann die Teams auch so organisieren,
dass die Kommunikationsprozesse das abbilden
und dass sie cross-funktional aufgebaut sind,
ohne dass man dafür extra Rollen schafft.
Aber letztendlich ist ja das Ziel, wie Luca gesagt hat,
den Wertstrom vielleicht auch eine Wertschleife mit dem Gedanken,
dass man halt auch Feedback am Ende wieder einsammelt,
um den Wert auch weiter zu steigern.
Also eine selbstverstärkende Rückkopplung,
bei der man letztendlich aus dem Feedback vom Kunden
wieder gute Ideen, gute Gedanken für eine Weiterentwicklung des Produkts hat.
Und solche Schleifen aufzubauen sind natürlich sehr hilfreich.
Ja, da sagst du auch was Wahres.
Das ist jetzt etwas, was ich vielleicht nicht so sehr in der Debatte wahrnehme,
aber etwas, von dem ich mir wünschen würde,
dass es etwas präsenter wäre.
Das beobachte ich nämlich oft bei Kunden,
dass sie, wenn sie ihre Prozesse verbessern,
ihre Automatisierung verbessern,
sich sehr stark auf die Vorwärtsrichtung fokussieren,
auf den Wert Strom, der irgendwie immer stromabwärts geht.
auf den Wert Strom, der irgendwie immer stromabwärts geht.
auf den Wert Strom, der irgendwie immer stromabwärts geht.
In Richtung Kunde.
Und unangenehmerweise häufig so ein bisschen vergessen,
dass die Rückwärtsrichtung ja ebenso wichtig ist,
die Rückkopplungsrichtung.
Darum, das ist momentan mein persönliches Steckenpferd
in Bezug auf DevOps und verwandte Themen,
Rückkopplungsschleifen zu stärken.
Das hat ja schon Gene Kim damals in den drei Wegen definiert,
wenn man überlegt, man hat den ersten Weg,
das ist der Wert Strom,
das ist letztendlich der Fokus,
überhaupt einen kontinuierlichen Entwicklungsprozess,
Betriebsprozess, neue Features
in einem regelmäßigen Rücken,
Rhythmus vielleicht sogar automatisierbar auf den Weg zu bringen
und dann die Stufe 2 zu nehmen
und zwar die Feedbackschleifen aufzubauen
und die vielleicht natürlich auch in kleinen Feedbackschleifen
über Continuous Delivery Pipelines,
wo dann halt Testergebnisse, Feedback für die Entwickler liefern
und anderes.
Aber eben auch die gesamte Schleife
von der Kundenanforderung wieder zurück zum Kunden
und dann wieder zur nächsten Anforderung.
Was häufig die längste Feedbackschleife
in einem gut geölten Continuous Delivery getriebenen
Entwicklungsprozess ist.
Ja, das ist interessant, dass du das sagst,
weil Jane Kim hat das wann?
2011 formuliert, die drei Wege.
Und es zeigt sich, wie schwer es ist,
diese an sich relativ einfache und einleuchtende Maxime
halt auch tatsächlich umzusetzen.
Genauso wie übrigens auch,
und das beobachte ich ja auch immer wieder,
es wahnsinnig schwer ist,
sich von dem klassischen Rollendenken,
von dem klassischen Silo-Denken zu lösen,
selbst bei allerbesten Absichten.
Ganz plötzlich rutscht man also versehentlich
wieder zurück in Silos hinein
und in Zuständigkeiten hinein
und so weiter.
Ich glaube, in der Hauptsache
ist es auch eine Art Ermutigung,
auf sich selber aufzupassen und zu schauen,
treffe ich da die richtigen Entscheidungen,
laufe ich da in die richtige Richtung?
Einfach, weil es doch irgendwie unangenehm leicht ist,
da wegzurutschen,
obwohl man es eigentlich besser wissen sollte.
Und wenn man jetzt wieder das Thema Zukunft
von DevOps fokussiert,
finde ich es gut, was ihr beide gesagt habt,
das Thema Value Stream, also Wertorientierung.
Weil auch das, glaube ich,
wird immer mehr im Mund gehen.
Das, glaube ich, wird hilfreich sein, näher an die Kunden ranzukommen.
Und auch all das, was ich tue, wo wir Probleme sehen in Silos, in getrennten Aktivitäten, in unterbrochenen oder nicht vorhandenen Feedback-Schleifen,
dass man eben wirklich unabhängig von irgendwelchen Frameworks, von irgendwelchen Rollen, von Funktionen, von Bereichen,
sich immer mehr anschaut oder immer häufiger, intensiver anschaut, wo sind wirklich diese Wertströme.
Und da, glaube ich, ist aus meiner Sicht auch viel Potenzial, vieles von dem auch anzugehen,
was wir vorhin auch im Podcast bis jetzt schon auch als Schwierigkeit benannt haben.
Also ich glaube, dass Wertstromorientierung, wir haben sie auch, das haben wir in ITIL, wir haben es in SAVE,
also diese Wertstromorientierung findet sich eben dort immer häufiger wieder.
Und ich glaube, dass man mit diesem Ansatz auch diese verschiedenen Bereiche mit Testen, mit Security, mit Kunden und so weiter,
also alles sehr gut hat.
Sehr viel einfacher und auch vielleicht pragmatischer in so ein Thema hochperformante Organisationen einbringen kann.
An der Stelle würde ich letztendlich darauf hinaus wollen, dass man sagt, Wertstrom,
Waste Remapping, Waste Remanagement sind Techniken, die sich aus der Produktentwicklung ergeben haben,
die auch viele produzierende Unternehmen schon lange im Einsatz haben, die Lean Management wirklich greifbar machen.
Und aus meiner Sicht ist das eine Richtung.
Die viele Unternehmen noch zu gehen haben, vor allem in dem IT-Umfeld und aus meiner Sicht ist es auch ein Stück Professionalisierung der IT,
die da mit dranhängt, die ein großer Treiber hinter dem DevOps-Thema letztendlich ist und hoffentlich auch dazu beiträgt,
dass Unternehmen dann Kapazitäten, die sie vielleicht in nicht ganz so performanten IT-Prozessen gebunden haben,
frei bekommen, um eher…
Kunden getrieben, eher automatisiert, eher auch vielleicht schneller und oder besser,
zumindest nicht mehr in der Richtung technische Schulden aufbauen, sondern eher abbauen, umsetzen können.
Mir gefiel gerade ein Wort, das der Dirk verwendet hat, nämlich das Wort pragmatisch.
Und als ich das gehört habe, dachte ich so ein bisschen an das Thema SRE, Site Reliability Engineering,
das ja zunehmend an Fahrt gewinnt.
Das ist jetzt natürlich ein Thema, das nicht erst 2022 aufgeploppt ist, aber nichtsdestotrotz.
DevOps ist ja angetreten mit dem Anspruch,
wir vereinen Entwicklung und Betrieb und lassen das alles von einem Team verantworten.
Und es hat sich gezeigt, manchmal ist das einfach nicht der pragmatische Ansatz,
weil es macht halt vielleicht durchaus Sinn, dass man Fachleute für den Betrieb hat,
für den fortwählenden, stabilen, reibungslosen Betrieb von großen IT-Infrastrukturen
und dass man die deswegen mit Fug und Recht halt vielleicht doch auslagert und als was Separates betrachtet,
aber dass man natürlich trotzdem erstens ihnen dieselben, ich sag jetzt mal, Denkweisen und Hilfsmittel an die Hand gibt,
wie Entwicklungsteams oder DevOps-Teams und dass man zweitens trotzdem dieses Hand-in-Hand-Arbeiten nicht vernachlässigt,
sondern es nur ein bisschen auf andere Füße stellt.
Man sagt, okay, das sind tatsächlich zwei verschiedene Gewerke, aber natürlich müssen die miteinander zu tun haben.
Und insofern, auch da ist SRE etwas für mich, was mich lange beschäftigt hat.
Bei DevOps, da habe ich mich immer gefragt, wie macht man das denn in langlaufenden Produkten,
dass man zunächst quasi null Betrieb hat und 100% Entwicklung, ist ja noch nichts da, was du betreiben kannst,
und zu irgendeinem Punkt schwenkt das um und dann habe ich, ich weiß nicht, 90% oder 95% Betrieb
und dann habe ich 5% oder 10% Entwicklung, die sich dann im Wesentlichen auf Bugfixing reduzieren.
Aber gleichzeitig fordere ich stabile Teams, nicht sich wandelnde Teams.
Wie passt das denn? Jemand, der gerne Entwickler ist, möchte der gerne Betrieb machen.
Solche Leute gibt es auch, aber im Großen und Ganzen, Schuster, bleib bei deinem Leisten.
Und insofern finde ich SRE da einen wunderbaren Baustein, um diesen Widerspruch so ein bisschen aufzulösen und zu sagen,
ja, es gibt.
Diese andere Blickrichtung, aber dieselben Werkzeuge, dieselben Denkweisen, die finden da auch ihre Anwendung.
Darum ist das aus meiner Sicht irgendwie eine sehr hilfreiche Entwicklung, oder wie seht ihr das?
Also ich finde das auch sehr hilfreich.
Für mich ist das auch wieder ein Beispiel, dass die DevOps-Philosophie erweitert wird um Best Practices,
also für mich ist SRE genauso ein Best Practice und das ist ein Indikator für mich,
dass eben diese beiden Bereiche zusammenwachsen.
Also selbst wenn sie irgendwie sozusagen getrennt werden,
inhaltlich oder getrennt bleiben, inhaltlich wachsen sie zusammen,
weil einfach ein Austausch stattfindet, also ein konzeptioneller, ein inhaltlicher Austausch.
Genau, jeder kann sich auf das fokussieren, was er gut kann und was ihm liegt,
aber gleichzeitig ist die Gemeinsamkeit des Zieles bleibt erhalten.
Jetzt würde ich gerne noch ein bisschen Salz in die Wunde streuen, die wir vorhin hatten,
nämlich das Thema stagnierende DevOps-Transitionen.
Ich glaube, da haben wir vorhin immer so ein bisschen das so gestreift,
also wir wollen ja nicht nur hier eine rosa, heile Welt rüberbringen.
Also es gibt, glaube ich, und das stelle ich eben auch fest, viele stagnierende DevOps-Transitionen.
Ich merke das dann, wenn man in Workshops sitzt und da kommt ein Ergebnis raus
und dann gibt es keinen Folge-Workshop.
Ja, dann ziehen sich zurück die Unternehmen, die machen irgendetwas,
aber man hat das Gefühl, dass sie in so einer Art, ja, bei den Sackgassen sind oder wo auch immer sind,
dass sie nicht vorwärts kommen.
Was denkt ihr? Also lebt ihr das auch?
Ja, das ist das, was wir machen.
Und vor allen Dingen, wenn es so wäre,
dass Stagnation festzustellen ist, was hat das für die Zukunft von DevOps für Auswirkungen?
Ja, also das ist auch etwas, was ich beobachte,
dass man mit großem Elan da irgendwie Initiativen startet
und die treffen dann halt irgendwann mal auf die Mühsalde-Ebene
und dann geht es irgendwie nicht so richtig weiter.
Dann hat man schon so ein bisschen Automatisierung eingeführt irgendwie
und dann hat man schon, weiß nicht, so agile Teams aufgestellt,
aber so richtig rund läuft das auch nicht.
Und vielfach hört man dann, also wir hatten uns da irgendwie,
mehr davon versprochen.
In der Tat höre ich ja auch eine zunehmende Diskussion darüber,
dass das Agile ja doch gar nicht so toll ist,
weil, ja, wir haben es probiert und es ist eigentlich voll nervig bloß
und dann hast du die ganze Zeit irgendwie Daily Stand-Ups
und am Ende kommt nichts bei rum.
Und mein persönlicher Eindruck ist,
dass das einfach dem geschuldet ist,
dass das ein so tiefgreifender Wandel ist,
dass ich zum Beispiel einen ganz anderen Ansatz des Risikomanagements wähle
als im klassischen Projektgeschäft vielleicht,
wo ich versuche durch sehr strikte Festlegungen,
durch sehr strikte Planung,
Risiken zu managen und die agile Welt sagt halt,
wir machen das, indem wir elastisch sind,
indem wir Feedback einholen,
indem wir uns auf beobachtete Situationen
jederzeit neu einstellen können.
Und wenn du diesen Schritt halt nicht vollständig gehst,
sondern so zwischen den Stühlen sitzen bleibst,
ja, dann ist es halt irgendwie ungemütlich.
Und das ist etwas, was ich zunehmend beobachte,
eben diese so halben Transitionen,
die dann ganz häufig auch gemessen an dem Aufwand,
den man da betrieben hat,
organisatorisch, technisch und auch emotional,
halt ganz ehrlich,
nicht ein bisschen wenig bringen.
Also wenn ich da drin säße,
würde ich auch sagen,
na ja, also war das jetzt echt alles.
Aber wann ist denn eine Transition eine halbe
und wann eine ganze?
Letztendlich geht es doch darum,
dass es einen Schwung gibt,
den man kontinuierlich halten kann,
der eine Weiterentwicklung,
wie kann man glaube ich auch definiert,
evolutionäres Change Management betreibt.
Also wirklich in kleinen Schritten kontinuierlich da dran bleibt,
auch die Veränderungen aufrechtzuerhalten.
Was für mich,
was für mich natürlich eine häufige Aufgabe ist,
die man zum Beispiel,
wenn man agil zum Beispiel Scrum getrieben arbeitet,
dann auch der Scrum Master den Teammitgliedern einimpfen muss.
Dass letztendlich Unternehmen häufig solchen Antrieb brauchen,
wenn sie in klassischen Vorgehensweisen unterwegs sind,
ist eine Erfahrung, die ich gesehen habe.
Und die Unternehmen,
wo ich einen relativ langsamen Entwicklungsprozess
oder gegebenenfalls auch sowas,
wie ihr als gestoppt oder irgendwie nicht weiterkommend gerade beschrieben habt,
haben aus meiner Sicht auch diesen Drive
aus den nicht besetzten Scrum Master Rollen heraus
nicht im Unternehmen etabliert bekommen.
Vielleicht ist das ein Aspekt,
dass man auch diese Ende-zu-Ende
und vollständig implementierte Scrum Vorgehensweise
oder Kanban Vorgehensweise als Grundlage braucht,
damit es diesen kontinuierlichen evolutionären Change Prozess,
Veränderungsprozess auch dauerhaft weiter treiben kann.
Wie seht ihr das?
Ich denke, da sagst du was sehr Wahres.
Denn es braucht eben tatsächlich diesen Treiber,
der muss jetzt auch nicht zwingend von außen kommen,
aber ganz häufig erlebt man das halt,
dass die Leute dann sagen,
naja, wir haben jetzt, keine Ahnung, Agile eingeführt,
uns bringt gar nicht so viel
und dann bleiben sie an der Stelle irgendwie stehen.
Statt dass sie dann den naheliegenden nächsten Schritt gehen würden,
zu sagen, Moment, was ist da los?
Warum fühlt sich das nicht so an,
wie wir uns das vorgestellt haben?
Denn ganz so,
ganz häufig findet man halt so eine Art von Cargo Cult Agile,
dass man alle Zeremonien eingeführt hat,
dass man die auch irgendwie macht,
aber dass man am Ende halt nicht weit genug gegangen ist.
Und das finde ich auch wahnsinnig verständlich und nachvollziehbar,
weil man bohrt da halt ein ganz schön dickes Brett.
Das ist ein sehr tiefgreifender Wandel,
ein sehr tiefgreifender, auch kultureller Wandel,
auch emotionaler Wandel für den Einzelnen.
Und ich finde es wahnsinnig verständlich,
dass einem da irgendwie unterwegs die Puste ausgeht
oder dir ein Mut ausgeht oder sowas.
Oder dass man es einfach unterschätzt hat,
auch schlicht und ergreifend.
Naja, aber ist doch schon,
da war ja so ein paar Steine ab,
die kriegen wir doch locker hin.
Wir machen eine Schulung und dann läuft das.
Genau.
Und das ist eben das, was ich beobachte,
dass ganz häufig,
und da hauen wir wieder in dieselbe Kerbe,
die Falco vorhin genannt hat von Rückkopplungsschleifen,
dass es da niemanden gibt,
der einfach mal sagt,
aha, was ist da los?
Zum Ende der Episoden unserer Podcast-Folgen
kommt ja auch immer mal die Frage,
also zumindest stelle ich die immer sehr gerne,
hast du noch irgendwas nicht gesagt?
Also haben wir mit unseren Fragen bei unseren Gästen
noch irgendwas nicht,
die haben wir noch nicht abgedeckt.
Und wenn ich jetzt nochmal ein bisschen
wieder auf den Titel gucke,
Zukunft von DevOps,
würde ich gerne unsere jetzige Diskussion
auch ein bisschen dahin bringen,
was sehen wir denn sozusagen in der Zukunft?
Und ich glaube,
dass DevOps auch immer vielfältiger wird.
Und das fällt mir,
ist mir sofort eingefallen,
als Luca eben vor den Schwierigkeiten,
oder wir eigentlich alle
vor den Schwierigkeiten gesprochen haben,
es wird vielfältiger
und damit wird es nicht einfacher.
Also es wird vielfältiger,
das ganze Thema,
ich sage mal,
Remote Work mal reinzubringen,
KIs reinzubringen und so weiter,
Serverless,
also es gibt ganz viele Dinge,
die darauf einwirken auf DevOps,
oder die einen Einfluss auf DevOps haben.
Vielleicht können wir das nochmal ganz kurz
ein bisschen beleuchten zum Abschluss.
Was denkt ihr dazu?
Ja, ein Aspekt,
den verschiedene Unternehmen,
vor allem größere haben,
ist, wie organisieren sie sich
in einer agilen Vorgehensweise,
die ein Produkt- und Kundenfokus haben,
wenn dann dann 10, 20, 100 Teams daran beteiligt sind,
wenn dann dann 10, 20, 100 Teams daran beteiligt sind,
wenn dann da auf einmal 1.000 Leute
an einem großen Produkt,
an einer Plattform arbeiten,
die dann eben für wirklich
Tausende, Hunderttausende Kunden gedacht ist,
wie organisiert man sich da?
Das ist ein großer Aspekt.
Und da kommen natürlich Skalierungsframeworks ins Spiel,
in erster Linie
von der Marktverteilung her,
ist Safe da groß im Wachstum,
ist für mich auch ein guter Einstieg
für Organisationen,
die aus einer klassischen Welt kommen
und dann in agilen,
agiles Arbeiten
in größeren Teamstrukturen vorangehen,
kann sich natürlich weiterentwickeln.
Da sehe ich dann andere,
zum Beispiel Less oder
je nachdem, was es für Teams sind,
haben wir auch eine kleine Schulung zugebaut,
wenn ich mich da nicht so falsch erinnere,
DevOps skalieren,
wo wir die DevOps-Sicht
in den verschiedenen Frameworks auch immer beleuchten,
finde ich ganz hilfreich,
vor allem dann, wenn man noch in der Entscheidungsphase ist,
was ist denn das richtige Framework,
wo starten wir dann?
Oder,
wenn man sich inspirieren lassen will,
wir kommen irgendwie jetzt gerade nicht weiter,
wir haben jetzt alles das,
was Framework X uns liefert,
implementiert,
stecken gerade irgendwie fest,
könnten jetzt irgendwo mal einen Anstoß brauchen,
wäre aus meiner Sicht ein guter Punkt,
sich da in die Richtung zu entwickeln.
KI, Luca,
was sagst du zu KI?
Um Gottes Willen.
Es würde uns erst mal Intelligenz
bei den Menschen helfen, ne?
Bei mir auf jeden Fall.
Auf jeden Fall.
Nee, aber,
also, ja, ich sehe jetzt KI gar nicht so sehr
als Hilfsmittel für DevOps,
auch wenn ich mir das sogar auch vorstellen kann,
gerade wenn es um Monitoring geht,
dass man da auch automatisierte Systeme hat,
die einfach, ich sag jetzt mal,
das gewöhnliche Verhalten eurer Organisation beobachten
und einfach mal die Hand heben,
wenn sie eine Veränderung sehen.
Selbst wenn sie die selber vielleicht gar nicht einschätzen können,
aber die einfach sagen,
normalerweise passiert doch immer diese Sache,
warum passiert die jetzt nicht?
Was ist da los?
Aber vor allen Dingen,
auch andersherum gesehen,
wenn ich jetzt KI als Bestandteil neuer Produkte sehe,
was bedeutet das denn für die Arbeitsweisen?
Was bedeutet das für die Zusammenarbeit?
Jetzt ganz stumpf auf vielleicht technischer Ebene,
wie binde ich ein KI-System in meine automatischen Tests ein
oder in mein Continuous Integration ein,
aber auch bis hoch zur organisatorischen Ebene
oder vielleicht sogar bis zur kulturellen Ebene?
Es macht halt alles noch vielfältiger,
noch komplexer.
Genauso auch solche Techniken wie Serverless,
wie Orchestrierung,
Orchestrierung auf der einen Seite
und andererseits aber auch das,
was wir auch schon gesagt haben,
nämlich die zunehmende Realisierung,
dass wir Mainframes oder andere gewachsene Legacy-Applikationen
einfach noch auf lange Sicht weiter betreiben müssen und wollen.
Also es wird einfach irgendwie, glaube ich,
vielschichtiger und komplexer
und ich behaupte,
dass es unter solchen Umständen besonders hilfreich ist,
sich zurückzubesinnen auf zugrunde liegende Prinzipien,
zum Beispiel auf die drei Wege von Gene Kim.
Wenn du die nimmst und sagst,
okay, was bedeutet das denn für mich?
Dann kriegst du auch einen Dreh dran,
was das zum Beispiel bedeutet,
wenn du jetzt eine KI-Komponente in dein Produkt einbaust
oder was weiß ich was.
Also ich glaube,
man braucht eine zunehmende kulturelle Reife,
sage ich mal,
um der zunehmenden Komplexität Herr zu werden.
Oder, Dirk?
Ja, vielleicht auch eine Entmystifizierung.
Ich habe also jetzt besonders auf dieses Wort geachtet,
dass ich mich dabei nicht verhaspele,
weil das ist das,
was ich bei dir eben so ein bisschen rausgehört habe
und positiv empfunden habe.
Also nochmal eine,
eine,
eine Wertorientierung,
eine Orientierung an Prinzipien,
weg von irgendwelchen Frameworks,
weg von Dogmatismus,
von wegen, das muss so sein,
das haben wir immer so gemacht,
weil wir ansonsten diese Vielfältigkeit
gar nicht integrieren können,
weil wir ja auch mit schnelleren,
mit agileren Frameworks
oder mit agilen Vorgehen,
fange ich ja selber schon vor,
mit agilen Vorgehen,
Vielfältigkeit ja unterstützen,
aber vielleicht bin ich da auch manchmal
auch auf dem falschen Weg.
Also insofern Entmystifizierung
von klassischen,
von agilen,
ähm, Frameworks,
einfach schauen auf Prinzipien,
auf zum Beispiel das,
was Gene Kim gesagt hat,
um neue Aspekte wie Remote Work,
wie KI,
was es auch immer so gibt,
um das quasi einzubinden.
Und das wäre auch mein Schlusswort für das,
äh, für die heutige Folge.
Also ich glaube,
dass es so die Zukunft von DevOps ist,
so ein bisschen entmystifizieren,
pragmatischer werden,
ähm, und immer zu schauen,
wo schaffen wir Wert?
Wie kriegen wir unsere Prinzipien
umgesetzt?
Alle, alle zeigen gerade aufeinander
und keiner möchte jetzt den nächsten, äh,
Nee, alle zeigen auf dich.
Richtig, Falco, du bist dran.
Also ich, ich sehe es letztendlich, ähm, so,
ich bin ja auch gerade am reden, ähm,
passt ja auch.
Zurück zum Thema Zukunft von DevOps.
Letztendlich sind aus meiner Sicht
die nächsten Schritte wirklich die
Ende-zu-Ende-Sicht zu realisieren,
teamübergreifend, unternehmensweit, ähm,
den Gedanken zu fassen,
also von der, also der erste Weg von Gene Kim,
ne, den engen Blick rein Entwicklung und Betrieb
zusammenzubringen, zu über, nicht zu übergehen,
sondern halt weiterzudenken und wirklich den gesamten
ersten Weg abzubilden, Ende-zu-Ende zu denken,
dann dabei auch den Kunden, den Kunden im Fokus
zu behalten, das heißt, ähm, zweiter Weg Feedback
schleifen mit eingebundenem Feedback von Kunden
und, ähm, als nächstes wäre ja dann der dritte Weg, ne?
Ähm, wenn wir in Zukunft denken, dann wirklich Unternehmen zu haben,
die an einer Stelle lernen und andere Stellen im Unternehmen,
vielleicht auch Kunden und andere davon profitieren,
wo dann auch Dokumentation, Wissensmanagement und ähnliches
einen größeren Fokus bekommen wird.
Soweit meine Einschätzung.
Luca.
Ja, ich glaube, dem ist nichts hinzuzufügen.
Weg von, weg von Frameworks, weg von Dogmatismus hin zu Pragmatismus,
äh, ganz so, wie der Dirk das schon wunderbar gesagt hat.
Also, das ist, glaube ich, der einzige Weg, um der zunehmenden Vielfalt auch,
ne, wie gesagt, dem, dass, dass wir eigentlich die IT-Organisation hinter uns lassen
und uns auf den Gesa-, auf das gesamte Unternehmen begeben.
Das ist das Einzige, was hilft, dass man, dass man sich wirklich vergegenwärtigt,
wo wollen wir eigentlich hin?
Und dann ergibt sich häufig die, die Antwort auf die Frage,
was machen wir denn jetzt, äh, wesentlich leichter.
Ja, so, und, äh, wenn ich jetzt, äh, wir haben ja gerade eben so erzählt,
dass alle auf Falco gezeigt haben.
Also, natürlich gucken wir uns in die Augen hier auf den Bildschirm,
wenn wir diesen Podcast aufnehmen.
Und vielleicht sollten wir ja irgendwann mal auch, äh, das Video mitlaufen lassen.
Also, ähm, könnt ihr ja auch mal, ähm, kurz Rückmeldung geben.
Ähm, natürlich wird es immer den Podcast in einer, ich sag mal, nur Audio-Version geben.
Aber vielleicht machen wir auch noch mal wieder ein Streaming, äh,
dass wir ein Video mit aufnehmen.
Gucken wir mal.
Hatten wir, glaube ich, letztes Jahr irgendwann so ein-, zweimal auch mal gemacht.
Haben wir mal probiert, ja.
Auch, okay.
Sogar, sogar Live-Aufnahmen dann, das war ganz cool.
Ja, ja, bei, bei YouTube.
Also, insofern, ähm, wir haben unseren Spaß gehabt.
Ähm, ich, äh,
leite jetzt mal den, den Abgesang hier ein.
Wir haben unseren Spaß gehabt.
Und vielleicht kann man den Spaß aber nächstes Mal auch transportieren,
indem wir das Video zeigen, wie dann, ähm,
Falco da sitzt und nichts zu sagen weiß, weil alle auf ihn zeigen.
Oder umgekehrt, wer weiß.
Also, ich sage mal danke an meine beiden Kollegen hier
und freue mich über diese Folge und freue mich auf die nächste Folge.
Auf Wiedersehen.
Macht’s gut.
Macht’s gut.
Ciao.