Debatte: DevOps - Am Ende geht es vor allem um Kultur, mit Johannes Knauf (Metamorphant) und Andreas Einzmann (Motionpixxl) (Deutsch)

Boris (00:00):

Hallo und willkommen zu unserem neuen Podcast bei mir sind Andreas und Johannes, ich bin Boris von der Firma "Eficode". Wir unterhalten uns heute über die Frage, ob DevOps für die tatsächlich existierenden Probleme da draußen eine Lösung ist oder ob DevOps einfach nur die die nächste halbe Sau ist, die gerade durch das digitale Dorf gejagt wird. Wir haben uns vorgenommen statt einer Vorstellungsrunde, sagt jeder einfach kurz seinen Namen. In einem Satz, was er tut und dann, wie er zum Ersten Mal mit DevOps in Verbindung geraten ist. Johannes, magst du anfangen?

Johannes (00:35):

Ich fange gleich mal an. Genau. Ich bin Johannes Knauf von der Metamorphant GmbH. Ich bin Consultant, meistens bei großen und mittelgroßen Unternehmen unterwegs, im Bereich DevOps im weiteren Sinne, Architektur. Aber manchmal sind es auch ganz organisatorische Themen, also wie werden Teams geschnitten und ähnliches. Aber da kommen wir bestimmt später noch dazu mit DevOps im engeren Sinne das erste Mal in Kontakt gekommen bin ich, glaube ich, vor fünf Jahren, als ich meinen Kunden gewechselt habe. Und dort bin ich zu einem Kunden gekommen, da bin ich auch immer noch aktiv, ist Mobilitäts Dienstleister im süddeutschen Raum und es ist eine fantastische Firma. Ich habe einen fantastischen Chef, fantastische Kollegen und dort leben wir DevOps wirklich tagein, tagaus mit Herzblut. Für uns heißt das an der Stelle halt vor allen Dingen, wirklich Verantwortung zu übernehmen, von Anfang bis Ende, für unsere Services und in den Projekten, die ich davor hatte, war das oft so, dass man zwar vielleicht das eine oder andere Tool, was man jetzt vielleicht in die Ecke "DevOps" stecken würde, benutzt hat. Aber diese vollumfängliche Verantwortungsübernahme als autonomes Team, das war für mich neu und das begeistert mich bis heute. Magst du vielleicht weitermachen, Boris?

Boris (02:03):

Ich weiß gar nicht, wann ich zum Ersten Mal das Wort "DevOps" gehört habe. Aber ich weiß noch, dass war vor vielen, vielen Jahren, da war ich in einer Firma angestellt, die hatte einen Online Supermarkt und unser externer Berater meinte mal irgendwann beim Mittagessen: „Sag mal Boris, du sagst ja immer, du wärst Full Stack Developer aber das stimmt doch gar nicht. Full Stack Developer die nennen sich nur junge Node.js Entwickler, die auch so ein bisschen Datenbank können. Du bist ein DevOps!“. Lustigerweise habe ich dann nach einem halben Jahr später auch einen neuen Job gesucht und habe mich das erste Mal nach DevOps Jobs umgeschaut und festgestellt, das was ich so mein Leben lang war, die letzten 10-15 Jahre oder vorher schon gelebt habe, dass man die komplette Verantwortung übernimmt, über seinen Code, über seine Infrastruktur und die ganze Firma danach ausgerichtet ist, dass jeder auch diese Verantwortung tragen kann, dass das einen coolen Namen hat und dass ich eigentlich ganz gefragt war.

Andreas (03:00):

Mein Name ist Andreas Einzmann von der Firma "Motionpixxl", meine eigene Firma. Mein Schwerpunkt ist tatsächlich Consulting, und zwar agile Transformation. Das mache ich schon die letzten 10-12 Jahre als, Agile Coach Scrum Master Product Owner. Also ich komme mehr aus der Business Ecke, Methoden Ecke. Ich habe DevOps kennengelernt, in diversen Projekten, in ganz verschiedenen Ausprägungen und es wurde immer unterschiedlich gelebt. Deswegen freue ich mich heute auf das Gespräch mit euch, um mal zu sehen, wie ihr das seht. Natürlich das Interessante ist, weil ich bekennender Agilist bin. DevOps benutzt auch Werte, die wir auch im Agile Kontext benutzen, die ganzen Grundwerte von Scrum oder ganz wichtig einfach, dass das so gelebt wird und wie du sagtest Eigenverantwortung. Ganz wichtig das leben wir auch im agilen Kontext. Aktuell bin ich bei einem großen Konzern, wo ich eine agile Transition begleite. Das soll zum hybriden Konzern aufgebaut werden, mit allen Problemen. Ich sehe bei DevOps genau das, dass wir hier diese wichtigen Schnittstellen haben, aus der Entwicklung und in den Betrieb, also Operations. Das finde ich spannend an DevOps und deswegen kenne ich ein wenig von DevOps, aber nicht in der Tiefe.

Johannes (04:27):

Ja, schön, dass du dabei bist, Andreas, wir hatten dich ja ursprünglich eingeladen, genau deswegen, weil du auch ein bisschen stärker aus der Business Ecke kommst. Ich erinnere mich noch Boris, als wir das erste Mal so überlegt haben: „Mensch, wir würden gerne ein Podcast zusammen machen, aber viele Themen rund um DevOps sind in Sachen Podcast auch schon ziemlich ausgelutscht und es wiederholt sich da viel, was man so hört und welche Frage ist noch gar nicht beantwortet?“, da sind wir recht schnell draufgekommen auf diesen Aspekt. Mensch, das Business für das ist DevOps oft gar kein Thema. Ich habe noch nie einen Fachbereich gehabt, der zu mir kommt und sagt: „Ja, wir haben ja das neue Projekt aber bitte achtet darauf, dass besonders toll zu machen und nach DevOps Prinzipien.“, ist mir noch nie untergekommen. Deswegen jetzt mal gleich die Frage an dich: Bevor du so in der agilen Ecke warst, ist es für dich ein Thema gewesen, wenn du als Stakeholder mit Teams interagiert hast?

Andreas (05:27):

Ja, es ist immer ein Thema gewesen und zwar genau aus dieser Projektsicht. Im Grunde hast du ja mehrere Phasen, wie das auch in DevOps beschrieben ist. Du entwickelst etwas und musst es dann in den Betrieb übergeben. Das hieß damals nicht DevOps, das hieß einfach Operations oder Betrieb und da gab es ja immer Friktionen. Das war ja genau das und wenn ich DevOps richtig verstanden habe, wie gesagt wird immer anders gelebt, ist es ja genau das, das eine gute Verbindung zwischen der Entwicklung und Operations besteht. Deswegen auch der Name DevOps natürlich. Das ist ganz wichtig und das schafft immer Probleme. Habe ich auch aktuell tatsächlich. Ich betreue mehrere Produkte als Methoden-Coach und da sind wir gerade in einer Phase, dass es an die Linie übergeben werden muss, sprich in den Betrieb. Wie wird das gemacht und wie wird das gelebt? Das muss erst mal aufgebaut werden. Da fehlt so das gegenseitige Verständnis und DevOps, glaube ich, ein gutes Mittel dafür, dass man sich besser versteht und dass man besser zusammenarbeitet.

Johannes (06:27):

Andreas, Du hast jetzt gerade erzählt, wie das für dich sich gerade im aktuellen Projekt darstellt. Boris: Wie sieht es bei dir aus? Wie handhabt ihr solche Fragestellungen in euren Projekten?

Boris (06:40):

Na ja, das ist bei uns ein bisschen anders, weil die Kunden kommen zu uns, weil sie diese Friktion, die Andreas grade angesprochen hat, schon spüren und dann dafür eine Lösung brauchen. Man kann meistens schlecht verheimlichen, dass  diese Friktion, diese Probleme immer zwischen den gleichen Schnittstellen sind, was auch daran liegt, dass diese sehr andere Denkweise haben. Du hast da die, die sehr, ich sag mal konservierende Haltung des Betriebs, der an SLA's gemessen wird und möglichst keine Inzidenz auf der einen Seite. Da hast du dann die Idee, diese Feature getriebene Denkweise der Entwicklung auf der anderen Seite, die halt auch wirklich Features raushauen wollen, das Produkt geil finden. Und es gibt halt mal irgendwann so ein Crash, dass geht halt nicht ganz zusammen. Da ja da ein Unterschied zwischen Dev und Ops ist, kommen dann natürlich die Firmen auch zu uns und sagen: „Hey, ihr macht doch DevOps! Wollt ihr uns nicht mal helfen?“. Dementsprechend haben wir da einen ganz anderen Aufhänger und wir haben meistens die gleiche Problemstellung und kommen dann gleich mit Lösungen.

Andreas (07:42):

Vielleicht kann ich da ergänzen, also das kann ich nur unterschreiben und im Grunde ist es weniger, dass man genaue Prozesse aussetzen muss, sondern es ist auch ein kultureller Wechsel wichtig, also dass die Denkweise angeglichen wird. Das ist eigentlich die größte Herausforderung. Vielleicht mal zwei Worte aus agilen Transition. Das wird auch immer unterschätzt. Man arbeitet jetzt in Scrum und ist sofort agil. Nein, das Mindset muss geändert werden und das ist ein kultureller Wechsel. Das ist bei DevOps natürlich auch. Du hast im Grunde zwei Parteien, ich nenne es mal Parteien, aber die müssen erst mal Zusammenarbeitsmodelle entwickeln und das muss gemeinsam entwickelt werden. Ich glaube, da liegt die große Stärke, dass man zusammen redet.

Boris (08:22):

Ja, und dann gibt es da noch die dritte Partei, das wäre dann Security, die ja immer so ein bisschen zwischen den ganzen Stühlen steht und die wird noch mal anders gemessen. Security wird ja gemessen an wie schnell kommt jemand rein ins Haus? Da gibt es ja kein: "Es kommt keiner rein". Die Frage ist halt nur, wie schnell und dann diese diese drei verschiedene Denkweisen zu vereinen in einem neuen Team, das ist halt die Herausforderung.

Johannes (08:44):

Da sagst du was, genau. Bisher haben wir immer gesprochen von zwei Sichten und das deckt sich nicht so ganz mit dem, wie ich das lebe. Deswegen die Frage: Wie sieht für euch denn so ein Zielbild aus? Bei uns ist das eigentlich in der Regel immer wirklich so, dass wir nachher ein Team haben. Dieses interdisziplinäre Team vereint alle Kompetenz, die dafür nötig ist. Jetzt gibt es natürlich dann noch Bezo's "Zwei Pizza Regel". Ich frage mich immer, welche Pizza der meint. Er weiß nicht, wie viel ich esse. Aber, bei uns ist das Team ziemlich klein. Aber normalerweise so eine gute Teamgröße, keine Ahnung, liegt irgendwo zwischen zwischen 3 und 10. Alles was drüber ist es meistens dann schon. Da kommt dann wieder neue Friktion rein. In den Projekten, wo ich bin oder in den Produkten, sollte man eigentlich eher sagen. Das sind keine Projekte, das sind lang lebende Teams, die wirklich dauerhaft etwas auch weiterentwickeln und langfristig denken. Aber in diesen Teams, da ist es eben in der Regel dann so, wenn es zu groß wird. Wenn das Team also weiter wachsen müsste, um mit den Anforderungen klarzukommen, dann machen wir ein Split. Aber wir machen eben keinen Split nach Dev vs. Ops, sondern wir schauen, dass ein anderes Team, ein Teil-Team, ein Teilprodukt zuliefern kann, was komplett Self Service von dem Empfangen Team benutzt werden kann. So läuft das bei uns aktuell. Wie macht ihr das?

Andreas (10:12):

Ja absolut richtig. Teamgröße, sehe ich genauso. Ich würd noch mal ein Layer höher gehen. Eigentlich, ich will jetzt nicht esoterisch werden, aber du brauchst eine gemeinsame Vision und da muss es halt Menschen geben, auch in den verschiedenen Gruppen die Division treiben und man muss sich gegenseitig abstimmen. Wo wollen wir eigentlich gemeinsam hin? Und wirklich, dieser Schwerpunkt immer auf dieses Gemeinsame und nicht: „Wir machen das und ihr macht das!“. Und was ich in den Konzernen festgestellt habe da herrscht noch großes "Silodenken", „Ach, das ist ja Operations und wir machen die coolen“. Da muss es halt jemanden geben, der genau das treibt, das der die Teams zusammenführt und wir sind auch produktgetrieben. Tatsächlich, ich bin auf der Seite der Product Organisation im aktuellen Projekt. Das sind nämlich genau diese Friktionen, die haben jetzt 20 Jahre ihr Ding gemacht im Betrieb und wollen eigentlich gar nicht mit uns reden und das versuchen wir aktuell gerade aufzubrechen. Durch eine Gemeinsamkeit gibt es natürlich tausend Möglichkeiten. Vision ist schon mal eine gute Idee, dass man gemeinsam das Produkt weiterentwickelt oder launch oder betreibt, dass das nicht einfach übergeben wird und Tschüss, sondern das geht immer noch weiter. Genau diese Weiterentwicklung, was du eben gesagt hast. 

Boris (11:25):

Ja, ich würde sagen, das Zielbild ist auf jeden Fall ein Team zu haben, das die komplette Verantwortlichkeit übernehmen kann. Wie man dann da hinkommt, da gibt es ja verschiedene Wege und man gewinnt ja nichts, wenn man sagt: „Wir haben jetzt im Team alle Ressourcen, wir haben hier den Designer und wir haben den Ops-Guy und wir haben den coolen Entwickler“. Wenn ihr dann immer noch innerhalb vom Team in Silo sind, das heißt, man muss die Leute zusammenbringen und dann aber auch dafür sorgen, dass die sich gegenseitig ersetzen können und ihre Denkweise annehmen können. Ich glaube, Andreas meinte vorhin was von Mindset oder Kultur, das jeweils von der anderen Seite zu übernehmen. Damit das funktionieren kann, muss das halt eigentlich von oben vorgelebt werden. Ich habe neulich einen schönen Artikel gelesen von einem Schweizer Wirtschaftswissenschaftler, der das Thema "Kultur" mal näher analysiert hat und er meinte: „Sobald die Führungsspitze die gemeinsame Kultur nicht vorlebt, geht's schief“. Das heißt, man muss von unten bei den Teams ansetzen und von oben muss das Management auch mitmachen. 

Andreas (12:27):

Ja, sehe ich genauso. Du hast halt mehrere Ebenen, wobei ich das mittlere Management als fast größten Störfaktor empfinde in diversen Projekten, weil die es gewohnt sind, ihren Kram zu machen mit ihren Leuten, da ist sehr viel Liniendenken. Die wollen eigentlich ihren Claim abstecken und sich schützen und wirklich ganz starre Silos aufbauen. Wo Kommunikation dann auch nur über diesen Silo gesteuert wird, haben wir auch aktuell gerade, was ganz schwierig ist. Und wie gesagt, ich bin Agile-Coach und das versuche ich gerade aufzubrechen. Das ist wirklich dieses mittlere Management, also Board haben wir abgeholt. Wir haben Asign auch für die ganzen Themen, dass das so gelebt wird, alles gut. Aber jetzt hast du die Mitte. Also die Teams haben uns verstanden. Das ist auch ein großer Erfolg grade, aber das mittlere Management ist noch ein bisschen schwieriger. Das sind die… ich will nicht gemein sein, aber die alten weißen Männer und Frauen natürlich.

Boris (13:21):

Also als jemand, der traditionell als alter weißer Mann, im mittleren Management sitzt, muss ich mal kurz sagen. Das war schon ein Schock für mich, als ich irgendwann mal begriffen hab, so, die Sachen, die ich gerade versuche hier einzuführen, die werden mich meinen Job kosten. Also sowohl Agile als auch DevOps hat irgendwie schon so letztendlich zum Ziel, dass das mittlere Management massivst auszudünnen. Ich glaube ein wichtiger Punkt ist, wenn man eine Firma dahingehend transformiert, den Leuten auch zu sagen: „Guck mal, wir machen hier was und am Ende wirst du wahrscheinlich nicht mehr den gleichen Job machen. Du musst dich umgucken innerhalb der Firma, außerhalb“. Da muss halt auch die Firma die Möglichkeiten bieten, dem mittleren Management zu sagen, was sie dann tun können. Also auch wiederum eine Frage der Kultur, des Mindset.

Andreas (14:08):

Ja, das sind genau die Themen, die wir auch aktuell gerade angehen im aktuellen Projekt, dass wir versuchen, das mittlere Management vernünftig zu coachen. Wir haben es sogar im aktuellen Projekt, so dass das mittlere Management CPO ist, jetzt eine bestimmte Rolle, Chief, Product Owner und sogar disziplinarische Vorgesetzter. Also im Grunde übernimmst du die Altersstruktur, klebst ein neues Label drauf und denkst dann, dann schaffst du es irgendwie so, du schaffst es das Mindset zu ändern und das, das geht natürlich gar nicht, das funktioniert nicht. Noch mal eins, was du gesagt hast. Da entstehen viele Ängste und da musst du natürlich sehr intensiv dran arbeiten, dieser Kontrollverlust, Machtverlust. Das sind, glaube ich, die größten Ängste. Und da muss man natürlich eine Vorteilskommunikation benutzen, dass verstanden wird. Pass auf! „Dadurch wird alles einfacher. Klar gibts du ein bisschen Kontrolle ab. Aber wir sind auch viel effizienter dadurch und der Outcome ist besser und es wird alles viel einfacher“. Ich habe vorhin gesagt, Friktion wird auch viel weniger, weil wir mehr zusammenarbeiten und wir verstehen uns besser. Die Ergebnisse sind auch besser gemeinsam einfach.

Boris (15:17):

Wobei das Thema "Kontrolle" auch eine Illusion ist. Ich meine, es war ja keiner jemals in Kontrolle, wenn ich mir anschaue, was so eine mitteldeutsche Firma für eine Menge an Software einsetzt und für Schnittstellen hat: Interne, Externe. Das ist ja so wahnsinnig komplex und ich sage halt immer: „DevOps und Agile geben oder verringern die Komplexität, aber dafür wird es komplizierter“. Aber dass das kompliziert ist, kann man halt so ein bisschen besser kontrollieren. Man muss aber dazu an anderer Stelle auch ganz massiv die Kontrolle aufgeben.

Andreas (15:49):

Genau, wenn du dann noch den Lean-Ansatz mit einbringst, dann bist du auf einem guten Weg. Also ich finde, es gibt so ein paar Punkte. Die Grundwerte erst mal ganz wichtig als Leitplanken für alles, für DevOps und Agile natürlich und dann noch immer den Lean-Gedanken mitführen. Auch ganz wichtig. Ich kann auch alles kompliziert machen, aber das versuche ich zu vermeiden. Es gibt natürlich viele, die das auch als Mittel einsetzen, um ihren Claim abzustecken. „Das ist so kompliziert, das verstehst du nicht“, „Achso, okay, dann lassen wir das!“. Also das Zusammenwachsen wird ja dann blockiert, sogar teilweise mit Absicht. So meine Erfahrung.

Johannes (16:26):

Das finde ich sehr interessant, was ihr erzählt, weil es total anders ist, als was ich erlebe. Ich überleg gerade, wieso das bei uns genau das Gegenteil ist. Ich glaube, es ist die Personalauswahl. Bei dem Kunden, wo ich gerade bin, ist es so, dass ich das mittlere Management als einen absoluten Key Enabler für diese Transformation erlebt habe. Ich denke, es liegt an der Art von Leuten, die die ausgesucht haben. Klar, das ist auch wieder von oben getrieben gewesen. Aber das sind Leute, die machen diese Rolle, weil sie jemand machen muss. Die machen die nicht unbedingt gerne, sondern eigentlich freuen die sich darauf, wenn das alles einfach reibungsfrei funktioniert und sie endlich mehr kreative, produktive Beiträge liefern können und eine neue Rolle einnehmen können. Da ist eine Begeisterung da in diese Richtung zu gehen.

Boris (17:19):

Also ich glaube, es hängt auch schon stark an der Sorte "Firma". Ich war ja 10 Jahre in Berlin und das mittlere Management in Berlin besteht meistens eher aus so Leuten, die auch wieder mal Lust hätten zu coden und die wahrscheinlich so eine Transformation eher unterstützen. Wenn ich mir dann so einen so einen riesigen süddeutschen Konzern angucke, der 10.000 Mitarbeiter hat, von denen eine nennenswerte Anzahl die Jahre bis zur Rente abtickert, ist das natürlich eine ganz andere Motivation.

Andreas (17:49):

Das sehe ich genauso. Es kommt auf die Branche an. Ich habe ja viel auch in Automotive gearbeitet und jetzt Non Food und ganz divers und es kommt auch wirklich drauf an: Ist die Firma Inhaber geführt? Wie lange besteht diese Firma? Wie tief sind diese Prozesse und Handlungsweisen eingeschliffen? Ganz wichtig. Wie du sagtest, wenn ich noch 5 Jahre bis zur Rente habe, wieso soll ich mich verändern? Da ist ja kein Veränderungswillen da. Wo wo ist das Incentive eigentlich? Also ich werde ja nicht mehr befördert? Oder habe Lust noch was neues zu machen. Was Ich glaube halt, viele haben keine Lust etwas Neues anzufangen. Sie haben Angst noch was lernen zu müssen, haben Angst, Macht und Kontrolle abzugeben. Das sind glaube ich diese größten Punkte und haben vielleicht auch Angst, dass sie da nicht mehr mitkommen. Das ist glaube ich auch auch so ein Thema, dass sie nicht die Skills dafür haben, für die neue Welt.

Boris (18:42):

Es ist auch ganz interessant, da die meisten ITler ursprünglich mal diesen Job angefangen haben, weil sie es mochten, dass sie jeden Tag was Neues lernen müssen und dass sie so ein bisschen geistig fit bleiben und dann kommt halt doch 20 Jahre später bei vielen der Punkt, wo sie merken: „Ja, das heißt aber auch ich muss mich umorientieren, wenn ich jetzt hier die ganzen Cloud-Dinger lernen muss, da kann ich ja meine ganzen Server, mein ganzes Serverwissen gar nicht mehr nutzen, das ist richtig doof!“. Ich glaube diese Umstellung von Server auf Cloud, hat das auch noch mal beschleunigt. Das Leute so viel Neues lernen müssen, dass einfach die Bereitschaft gesunken ist.

Andreas (19:19):

Das glaube ich auch, tatsächlich. Ich hatte auch ein Projekt, wo wir auf Cloud umgestellt haben, sogar mehrere, genau. Was meint ihr, was es da für Widerstände gab, dass ich jetzt nicht mehr das Rechenzentrum betreiben darf? Das ist ja genau dieser Claim, den ich beschützen will. Ich habe das aufgebaut, das ist mein Baby und das müsste ich ja abgeben. Also ich gebe Macht und Kontrolle ab. Dann können das andere irgendwie machen und ich bin ersetzbar. Ich glaube, diese Angst davor, ersetzbar zu sein. Es ist auch so eine große Angst. Einfach. Ja bitte.

Johannes (19:49):

Ist euch was aufgefallen in der Diskussion? Wir sind jetzt doch wieder recht stark in die IT-Sicht gegangen. Wir sind jetzt doch...nicht?!...siehst du das anders, Andreas?

Andreas (20:00):

Ja, Sehe ich ganz anders, tatsächlich. Es geht darum, eigentlich immer. Die Frage die darüber schwebt: Wie wollen wir zusammenarbeiten? Das ist die eigentliche Frage, dieser Cultural Change, das ist das Entscheidende. Das hat überhaupt nix mit IT zu tun. Aktuell betreue ich drei, vier Produkte und die sind so mega Cross-funktional und das IT Dev ein ganz, ganz kleiner Teil. Da haben wir genau diese Themen: Wie ist das Mindset? Bist du bereit, dich zu verändern? Gehst du diesen kulturellen Wechsel mit? Das ist genau das. Ich glaube nicht, dass es mit der IT erst mal zu tun hat. Auch bei DevOps glaube ich, dass dieser Cultural Change das Schwierigste ist und das ist aber auch das Entscheidende.

Boris (20:41):

Würde ich eigentlich auch sagen. Bei der IT kommen öfter mal Probleme, weil das so der Filter ist, wo alles durch muss, aber eigentlich treten dadurch nur die allgemeinen Probleme der Firma auf.

Andreas (20:54):

Genau. Ich glaube auch, weil das ist nämlich genau und da stehen wir auch wenn es um die Übergabe geht, genau diese Schnittstelle von der Entwicklung, sei es Agile Wasserfall, das ist erst erstmal egal in dem Betrieb "in Run", da tauchen dann wirklich diese Probleme auf. Das kann ich nur befürworten, was du gesagt hast oder halte ich für richtig.

Boris (21:16):

Es gibt ja diese schöne "Theory of Constrainst", dass man immer den kleinsten bottleneck zuerst anfassen muss und danach den nächsten und nach dem den nächsten danach. Und ich denke schon, dass man an vielen Punkten von unten nach oben geht. Bevor die Designer in den Druck kommen, dass sie jetzt von heute auf morgen dauernd liefern müssen, weil sie es vorher gewohnt waren, alle halbe Jahr zu liefern oder bei der IT nicht hinterher kam, zum Beispiel, wird wahrscheinlich mehr Zeit vergehen, bis die Änderungen ganz unten bei den Server-Jungs eintritt oder bei den Entwicklern. Aber an sich ist die die benötigte Änderung im Mindset, die gleiche.

Andreas (21:51):

Ich glaube ja auch, dass eine agile Transition das alles treibt, da haben wir das Thema, wenn du das Scrum benutzt, als Methode, hast du zwei Wochen Sprints. Das ist natürlich klar, dass der Betrieb dann viel mehr Stress hat, als wenn wir Releases alle halbe Jahre haben, dann arbeitest du ja nicht auf so ein riesen Ziel hin. Ein neues Release im halben Jahr, sondern du bist permanent dabei, permanent dabei zu deployen. Das ist natürlich auch eine Forderung, wenn du Agile richtig lebst, heißt das, wir wollen Features direkt deployen, also CICD.

Johannes (22:25):

Da muss ich aber radikal widersprechen! Das mag für den Betrieb vielleicht erstmal so wirken, dass das mehr Stress ist aber ist es überhaupt nicht. Am Ende ist ja genau das der Witz, dass wenn man wirklich sagt: „Okay, wir releasen öfter. Vielleicht sogar untertägig, vielleicht sogar zigfach untertägig“. Das ist das, wo man ja dann letzten Endes in so einer Transformation hinkommt. Das ist eigentlich viel weniger schmerzhaft, weil es alles nur lauter winzige kleine Änderungen sind, die dann in Richtung Produktion gehen. Diese, diese Big Bang Changes, die all diese fiesen Probleme verursachen, sind auf einmal weg. Da hast du dann auf einmal keine Wochenenden, wo man gemeinsam im Rechenzentrum übernachtet. Ich meine nichts dagegen. Es ist ein tolles Gemeinschaftserlebnis, so was. Aber ich mache es halt doch lieber freiwillig, als weil ich muss.

Andreas (23:18):

Johannes, ich gebe dir völlig recht, dass ist ja genau so wie ich auch denke. Ich wollte nur die Perspektive aufzeigen, wie gedacht wird von der anderen Seite jetzt vom Betrieb. Die meinen, dass wäre mehr Stress, wenn ich andauernd Release. Wenn die es aber machen, dann sehen die alle sofort: „Nee, das ist ja alles viel einfacher und ich arbeite nicht auf einen großen Milestone hin, wo ich dann meine Wochenende in der Firma verbringen muss“. Das sehe ich auch so. Ich finde das ja ein großer Vorteil, wenn man permanent released, auch untertägig. Ganz klar, logisch.

Johannes (23:52):

Ich erinnere mich da noch an den Anfang, wo wir angefangen haben, diese Prinzipien zu leben, da war es so, da hatten wir also ein riesen Gewurschtel von Projekten, die alle mit den kompliziertesten Dependencies zusammengehangen haben, wo Deployment immer ein wahnsinns Akt war und alle immer gestöhnt haben: "Aah, Deployment, oh weh!“. Irgendwann hat jemand die Maxime ausgegeben, die kommt glaube ich auch nicht da aus dem Laden, sondern die hat irgendjemand anderes mal gesagt: „ if it hurts, do it more often“. Die haben ja dann an vielen verschiedenen Stellen so gelebt und gesagt: „Ok, klar, tut weh, aber wir machen das jetzt so lange, bis wir den Prozess so perfektioniert haben, dass der einfach nicht mehr weh tut“. Ja, das ist halt die Frage, wie kriegt man die Leute dazu, daran zu glauben, zu wissen, okay, wenn jemand das schon mal erlebt hat und weiß, es gibt dieses Licht am Ende des Tunnels, dann ist es einfach. Aber, wie machst du es jemandem glaubhaft, der das noch nie gesehen hat?

Andreas (24:55):

Ich mache das immer so, dass ich Best Cases skizziere und erkläre, was ein guter Weg ist, wenn du dein Projekt Feature Driven gestaltest, ist es halt eine super Idee, wenn du ein Feature schnell ausliefern kannst. Du bist nicht release-gebunden und der Kunde am Ende hat einen großen Nutzen davon. Also wirklich dieses Thema auch Customer Centricity hast du da drin, auch bei DevOps. Also du entwickelst etwas und stellst das sehr schnell online, dass der Kunde einen Nutzen davon hat. So mache ich das immer und ansonsten gebe ich dir völlig recht. „When it hurts, do it more often“. Durch Erleben wird man sehen, dass es einfach gut ist. Ganz klar. Du kannst so viel erzählen, wie ich eben gesagt habe. Aber die Menschen, die daran arbeiten, müssen das erleben, damit sie es auch verstehen. Ganz klar.

Boris (25:41):

Dieses klassische: „kein Release am Freitag“. Ist ja irgendwie von Schmerz getrieben. Also das heißt ja, die Leute hatten alle zu oft den Freitagabend statt zu Hause bei der Familie irgendwie in der Firma verbracht und sagen dann jetzt: „Kein Release mehr am Freitag“. Mein Ansatz besteht immer darin, diesen Schmerz zu analysieren und zu fragen Was müsste denn passieren, damit du mit gutem Gefühl sagen kannst: „Ich mache ein Release am Freitag“, und dann kommt man relativ automatisch dahin, dass die Leute sagen: „Na ja, ich brauche halt die Sicherheit zu wissen, was passiert. Also ich brauche Monitoring mehr Alerting. Ich brauche mehr Kontrolle, wenn ich meine Features selbst planen kann“. Da kommt dann relativ schnell ein Punkt, wo man sagen kann, die Leute übernehmen sehr gerne die Verantwortung. Wenn Sie aber auf der anderen Seite auch die...dass... jetzt fällt mir kein deutsches Wort ein, das ein Enablement haben, um die komplette Verantwortung zu übernehmen, wenn es nicht irgendwo eine Stelle gibt, wo man beten muss oder irgendwie warten muss, oder wenn man von Anfang bis Ende die Kontrolle hat, dann machen es Leute auch gerne.

Andreas (26:46):

Das Wort, was du suchtest ist "Mandat", glaube ich, dass die wirklich die Verantwortung übertragen bekommen. Das haben wir natürlich auch und das muss auch erst mal gelernt werden, dass ich verantwortlich bin für das, was ich tue. Da sind wir wieder bei diesem kulturellen Wechsel, tatsächlich dem "Mind Change". Das ist nicht einfach, weil die meisten kennen das natürlich nicht. Die fragen immer oben nach: „Soll man das jetzt wirklich machen?“, und „Brauchen wir Erlaubnis und Improvement?“. Das ist natürlich schlecht und deswegen muss man allen die Sicherheit geben. Da machst du natürlich auch viel über Testing. Auch ganz wichtig, dass das Test Management sauber aufgebaut ist, dann bist du ja sehr sicher, wenn du was Deployst.

Boris (27:24):

Ja, bei meinem allerersten Job habe ich ziemlich viel SQL gemacht, da war ich sehr Backend lastig, sehr Datenbank lastig und mein allererster change auf der Datenbank, da kam dann der CTO stellte sich hinter mich und meinte: „Bist du dir sicher, wenn das kaputt geht, bleibst du hier, bis es wieder läuft?“. Also am Ende habe ich das nochmal zwei Stunden lang angeschaut, die drei Zeilen und ich war mir sehr sehr sicher. Aber es hat was mit mir gemacht und irgendwie 5-6 Jahre später habe ich das mal in der Firma gesagt zum Entwickler: „So bist du dir sicher, dass du das Ding hier lesen willst. Du bleibst hier, bis es läuft, wenn es schiefgeht...“, und er guckt mich an und meinte nur so: „Bist du irre?“. Das Problem war halt, dass dieser Entwickler so viele Hürden hatte zwischen dem, was er tun konnte und dem, was am Ende beim Kunden ankam, dass er um Himmelswillen niemals die Verantwortung übernommen hätte.

Andreas (28:19):

Da sind wir eigentlich schon beim Thema "Leadership". An der Stelle. Wie kann ich auf einen Entwickler zugehen und ihn so verunsichern? Also das geht natürlich auch nicht. Wir haben da noch ein ganz anderes Thema: Wie führe ich meine Entwickler? So würde ich meine Entwickler nie führen. Wenn du das machst, dann siehst du halt Angst. Im Grunde. Also du verstärkst da Angst „Aah, bin ich mir da wirklich sicher?!“. Man ist sich natürlich nie sicher und dann erzeugst du natürlich keinen Mut bei den Entwicklern oder bei demjenigen, der etwas deployen will. Das ist wirklich ein Leadership Thema für mich an der Stelle, ganz klar. Im Grunde hast du dann auch schon das Thema "Fehlerkultur". Sind Fehler erlaubt? Was passiert, wenn Fehler passieren und so weiter. Das hast du dann auch.

Boris (29:01):

Ja, da würde ich aber so ein bisschen widersprechen. Ich würde sagen, dass was der CTO bei mir gemacht hat. War okay, weil ich wusste, ich hatte die Möglichkeiten, im Zweifelsfall den Rollback selbst zu machen. Ich hatte live Zugang, überall. Ich hatte das komplette Enablement, alles zu tun, um einen selbst gemachten Fehler zu erkennen, zu analysieren und am Ende auch zu korrigieren, auch wenn es keinen gab. Von daher war die Frage okay. In diesem anderen Kontext, wo ich das gefragt habe, vielleicht ernst oder auch nicht so ernst. Das war schon so ein bisschen fies, das gebe ich zu.

Andreas (29:37):

Ja, was erreichst du damit? Du verunsichert die Menschen und das willst du ja gar nicht. Sie sollen ja selbstsicher sein im Grunde, dass sie alles getan haben, um jetzt dieses Deployment auszuführen. Da willst du hin. Das kannst du mit Tools machen, das kannst du mit Erfahrung machen und dann gibt es auch keine Zweifel.

Boris (29:56):

Na ja, der war ja nicht unsicher. Er hat es einfach einfach rigoros abgelehnt. Er wusste, es ist absolut unmöglich. Also das war so, als hätte ich ihn gefragt: „Und, gehst du Morgen fliegen?“

Andreas (30:05):

Äh, ja!

Boris (30:08):

ja, aber das ist das Thema. Fehlerkultur ist ein schönes Stichwort, finde ich. Man muss sich auch freimachen von diesem Gefühl, dass man so alle halbe Jahr das komplett fehlerfrei.....

Boris (30:22):

Tja, und hier brach der Podcast ab. Die nächsten 40 Minuten liegen leider irgendwo im digitalen Nirwana und bei unserem Podcast Service Provider. Wir würden uns nur allzu gerne mal mit besagtem Service Provider unterhalten. Zum Beispiel wie man mit der Box Mythologien den Kunden zufriedener stellt, die man mit unserer DevOps Plattform "Eficode Root", Fehler eher erkennt. Aber am Ende ist das alles egal. Wir hatten jede Menge Spaß bei der Aufnahme und auch wenn es schade ist, möchten wir euch nicht das Ergebnis vorenthalten und hoffen, ihr habt ebenso viel Spaß beim Anhören wie wir bei der Aufnahme. Wir sehen uns beim nächsten Mal.