Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Diesmal zu Gast Georgia König und wir haben uns über das Thema DevOps unterhalten. Bei DevOps denken viele zuerst so an eine Liegende 8 und dann an eine CI/CD Pipeline, aber Georgia sieht das Ganze etwas anders und macht finde ich eine sehr spannende Perspektive auf das Thema DevOps auf. Ich konnte bei dem Interview viel lernen und bin schon gespannt auf euer Feedback. Schreibt es mir doch gerne
an [email protected]. Viel Spaß bei der Folge. Hallo Georgia, schön, dass du hier bist. Danke, danke fürs Einladen, fürs Mehrfach Einladen.
Fürs Mehrfach Einladen, ja wir haben ja schon ein paar Anläufe jetzt gebraucht, wir waren irgendwie krank und auf Konferenz und das schön im Wechsel, aber heute sind wir hier und das freut mich umso mehr, weil wir haben ein Thema, das haben wir hier im Podcast noch gar nicht so stark beleuchtet und das finde ich extrem spannend, weil es ein top aktuelles Thema
ist und zwar DevOps. Ich sage einfach mal DevOps und ja, ich habe mich ja im Vorfeld auch ein bisschen mit dir beschäftigt und du wurdest mir auch als Empfehlung zugetragen, dass du da durchaus die eine oder andere Erfahrung hast und deswegen möchte ich mit dir einfach mal darüber sprechen, weil DevOps hat natürlich auch ganz viel mit Testen und Qualität zu tun und aber vielleicht fangen wir einfach mal einen Schritt weiter vorne an. Was ist eigentlich DevOps?
Was ich auf diese Frage eigentlich am meisten antworte, ist DevOps ist der, ich sage mal, der Versuch und der verzweifelte Ruf der IT oder der Informatikbranche nach, es muss besser funktionieren, als es gerade tut. Also DevOps ist für mich, man könnte sagen, ein Schlachtruf von ITlern, für ITler, die sagen, so wie wir es bisher gemacht haben,
das machen wir alle bis zur Rente nicht mehr mit. Es muss besser werden und dieses Besser, sind die Praktiken, Werte, Tools, Software, Werkzeuge, die unter diesem riesigen Schirm von DevOps zusammengeführt werden. Aber wenn ich sage, DevOps ist ein Schlachtruf, das kann man nicht so gut verkaufen deswegen. Naja, aber so fasse ich DevOps auf, ja. Okay, aber jetzt ist ja schon Agilität seit 20 Jahren unser Heilsbringer, der alle Probleme lösen soll. Hat es das?
Vielleicht nicht so ganz, aber es hat schon ein bisschen eine andere Arbeitswelt mit sich gebracht und was ist denn da jetzt, was ist denn an diesem Schlachtruf anders als an dem letzten?
Ich will jetzt nicht für eine gesamte Informatiker-Community sprechen, das kann ich gar nicht, aber ich würde sagen, dass die, wenn man es runterbrechen möchte, die große Unterscheidung zwischen Agilität und DevOps darin besteht, dass tatsächlich DevOps von Betroffenen selbst gefordert und entwickelt und immer und immer wieder überdacht wurde.
Also ich sage mal, die DevOps-Evangelisten waren tatsächlich Personen, die aus diesem Feld gekommen sind und gesagt haben, das muss einfach irgendwie anders laufen, wir müssen uns austauschen, es muss bessere Möglichkeiten geben, wir müssen Lösungen finden und diese Lösungen teilen. Also sozusagen, wenn wir jetzt bei dem Bild von dem Schlachtruf bleiben, tatsächlich Leute an der Front, die gemerkt haben, das mache ich so bis zur Rente nicht weiter, das geht nicht,
es muss irgendwie anders. Ich habe aber technische Möglichkeiten, die ein, ich habe aber andere technische Lösungen, ich habe andere technische Einblicke und vor allem habe ich Zugang zu den entsprechenden Systemen und deswegen ist DevOps, würde ich behaupten, anders gewachsen als zum Beispiel die agile Bewegung. Weil das sind auch, und ich sage das mit aller Liebe, das sind auch alles kleine Hacker-Kinder, die auch wollen, dass es nicht
nur gute Ideen sind, sondern dass es auch funktioniert. Und dass es was Konkretes ist, was man konkret programmieren, umsetzen, implementieren, automatisieren kann. Und ja, ich weiß nicht, ob ich das jetzt gut zusammengefasst habe, aber so sehe ich DevOps von
der agilen Bewegung nochmal abgegrenzt. Also ich finde das einen ganz schönen Ansatz, aber da möchte ich nochmal kurz auch mit reinhaken, weil ich denke, also für mich ist DevOps schon etwas sehr Praktisches auch und vielleicht sogar eine praktische Implementierung
von all der Agilität, was das gerne hätte sein wollen. Ich meine, das waren ja auch ursprünglich mal, agil entstand ja auch viel aus der Software heraus, von Programmierern erdacht, aber ist natürlich mittlerweile übernommen worden von einer Herrscher an agilen Coaches und Scrum-Mastern, die zum Teil mit Software-Systemen auch gar nichts zu tun haben und da vielleicht anders wirken als Prozessbegleiter oder sowas, aber die Praktikabilität vielleicht nicht mehr so da ist. Und ja, da finde
ich ja schön, wenn wir jetzt in DevOps noch ein bisschen tiefer einsteigen. Also es ist ein Schlachtruf, Dinge anders zu machen, besser zu machen. Was denn zum Beispiel? Also es gibt ein wunderbares Dokument, das eigentlich, wenn man zusammenfassen soll, eigentlich einfach nur sagt, wir brauchen DevOps, also wir als Community von Personen, die in der IT arbeiten, wir brauchen DevOps aus drei Gründen. Erstens wegen den menschlichen
Kosten, die derzeit entstehen in der Informatik. Wir haben eine massive Burnout-Rate, wir haben eine massive Suizidalität-Rate, weil es ja auch so viele Männer in der Informatik gibt. Wir haben diese Kosten, wir haben Personen, die unter ihrem Job leiden. Das sind die, klar, die menschlichen
Kosten. Dafür brauchen wir etwas, was es besser macht und wir nennen es DevOps. Wir haben die ökonomischen Kosten, also zum Beispiel die ganzen, ich kann jetzt keine konkreten Zahlen nennen, aber die Geldbeträge, die jährlich verloren werden, weil Software ineffizient entwickelt wird, weil Projekte sofort wieder eingestampft werden, weil das Falsche entwickelt wird, weil am Kunden vorbei entwickelt wird, weil wir tolle Software haben, die aber nie beim
Endkunden landet. Also sozusagen die ökonomischen Kosten, dafür brauchen wir DevOps, damit es nicht weiterhin, ich sag mal, Geld in Flammen aufgeht, weil jemand das Projekt falsch plant, übertrieben gesagt. Und wir brauchen, wir brauchen DevOps, weil wir als Informatik, als Branche, wir sind ja noch eine sehr junge Branche, wir haben noch sehr viele Kinderkrankheiten, die andere Domänen, wie zum Beispiel die Medizin, schon längst überwunden haben, weil die Medizin viel älter
ist. Und wir als Branche, um ernst genommen zu werden, brauchen DevOps, um einen Standard zu etablieren und ernst genommen zu werden, sag ich jetzt mal. Also übertrieben gesagt, wir brauchen DevOps, um die menschlichen Kosten zu mindern, wir brauchen DevOps, um die ökonomischen Kosten zu
mindern, die da verschwendet werden, sag ich mal. Und wir brauchen DevOps, um uns als Branche zu etablieren und rauszukommen von diesen ganzen Bildern, wie das Kellerkind, das Hackerkind, der Informatiker, der keine Ahnung von Zahlen hat, was auch immer da für Bilder existieren. >> Okay, verstehe. Ist ja ein hehres Ziel, das finde ich auch gut, aber mit dem pragmatischen Ansatz. Aber wie sieht denn das dann konkret aus? Was steckt denn da so drinnen?
>> Das ist eine sehr, sehr gute Frage. Also, wenn ich, ich sollte vielleicht ein bisschen ausholen. Also, ich habe in den vergangenen Jahren immer mal wieder DevOps in verschiedenen Kontexten gelehrt. Das war zum Beispiel, ich habe Vorlesungen über DevOps gehalten oder ich habe
Artikel über DevOps geschrieben. Und da ist die Frage natürlich immer, wie breche ich DevOps runter, und mache es konkret und gebe den Leuten wirklich was Konkretes an die Hand, damit die sagen, ah, hehres Ziel, große, tolle Ideen, aber was bedeutet das jetzt konkret auf dem Blatt Papier, was muss ich als Student wissen und verstanden haben, damit die Frau König mich bestehen lässt? So Zeug. Und was ich da gemacht habe, war, in meiner Bachelor-Thesis habe ich verschiedene
didaktische Konzepte ausgearbeitet, wie man DevOps vermitteln kann. Und eins davon, das war jetzt eine sehr lange Antwort auf eine recht kurze Frage, eins davon ist das CALMS Akronym. Und das CALMS Akronym steht einfach nur für Culture, Automation, Measurement, Lean und Sharing. Und es gibt diese ganz berühmte, tatsächlich, Tasse, wo einfach nur draufsteht,
"Stay Calm and Do DevOps", aber "Stay CALMS and Do DevOps". Und das ist eine Möglichkeit, dieses CALMS Akronym ist eine Möglichkeit, um DevOps zu konkretisieren und sich zu fragen, welche Kultur unterstützt unsere Ziele, die wir mit DevOps erreichen wollen? Welche Automatisierungskonzepte unterstützen unser Ziel? Was müssen wir monitoren oder measuren? Also, welche Zahlen brauchen wir, um die guten Entscheidungen zu treffen und die schlechten
Entscheidungen zu lassen? Was müssen wir teilen, also Sharing, also wie müssen wir Wissen verbreiten und Zugang verbreiten, um wieder unsere Ziele zu erreichen? Und das letzte, Lean, was ich am interessantesten finde, ist, auf was müssen wir uns beschränken und sagen, das ist unser, also darauf beschränken wir uns, damit machen wir, damit erreichen wir das, was wir erreichen wollen,
mit dem minimalen Aufwand, aber dem maximalen Ergebnis. Genau. Deswegen empfehle ich sehr, sehr oft das CALMS Akronym, auch in, zum Beispiel in einem Workshop, dass ich die Teilnehmer bitte, ihr habt jetzt verstanden, was das C und das A und das M und das L und so weiter,
wofür das steht, was fällt euch dazu ein und was können wir explizit davon nutzen? Also, was müssen wir messen, was müssen wir automatisieren, was müssen wir teilen, was müssen wir reduzieren und welche Kultur müssen wir schaffen, um DevOps von seinen Herrenzielen in unseren Alltag zu kriegen? Also, das finde ich eigentlich ein sehr schönes Modell. Auf welchen Scope nimmt man denn dann da? Also, ich meine, wer soll denn daran teilnehmen,
wenn wir da mitwirken? Also, ich als, ich habe beide Perspektiven. Ich habe einmal die Perspektive, dass ich in der Theorie natürlich alles vorschlagen kann und meinen Studenten alles empfehlen kann und sagen kann, ha, jetzt erst mal wochenlang nichts anderes als DevOps-Workshops
und wochenlange Optimierungsüberlegungen anstellen. Aber auf der anderen Seite, wenn ich im Beraterumfeld tätig bin, kommen oft Kunden auf mich zu, die bereits unter den, ich sag mal, Developer-Pains leiden, die kaum Zeit haben, die überfordert sind, die überfrachtet werden, deren Projekte kurz vorm Aus sind. Und mit denen kann ich dann nicht erst mal zwei Wochen alles stillstehen lassen und sagen, oh, wir treffen uns jetzt in einem Raum
und überlegen uns, welche Werte wir verteilen. Und bei denen ist es sozusagen, wir brauchen jetzt was. Und was ich da, was ich da immer und immer und immer wieder empfehle, ist eben, überlegt euch, was könnt ihr in einer recht kurzen Zeit tun, die euch in den nächsten Tagen und Wochen euer berufliches Leben erleichtern. Also was könnte man in einer Stunde automatisieren, einfach damit es weg ist. Welche Meetings könnte man in einer Stunde absagen, weil sie unserem Ziel nicht dienen,
damit wir uns nur auf das Wichtige fokussieren. Welche Dokumentation müsstet ihr lesen können, zu welchem Wissen müsstet ihr Zugang haben können, damit dieses eine Problem nicht ständig auftaucht. Also sozusagen wirklich, was kann jetzt passieren, solange wir in dieser großen, größeren Gruppe sind, was kann jetzt passieren, was der Richard von morgen und der Richard von nächste Woche und der Richard von nächsten Monat sich denkt, oh, Gott sei Dank, habe ich mich da
mal darum gekümmert. Ich habe DevOps gemacht. Also, aber natürlich, meinen Studenten empfehle ich dann erstmal, ach, macht erstmal eine User Story und eine Case Study und guckt euch das erstmal an und macht fünf Vorschläge und revidiert das alles und es dauert Wochen. Naja, die müssen es ja auch lernen. Ja, ich glaube, es ist total wichtig, gerade in bestehenden Projekten. Also ich sehe sehr häufig auch die Zermürbung der Projektmitarbeiter
oder die schon resigniert haben oder sowas. Da muss man ja schnell ein Ergebnis für die auch bringen. Also die müssen ja merken, das bringt was, weil sonst ist es wieder nur ein Berater, der da war und wieder irgendwas erzählt hat, der ein neues Akronym mitgebracht und jetzt habe ich schon wieder eins. Das kann ich mir auch noch wo hinkleben, aber es muss ja wirklich was Praktisches
rauskommen. Und ich glaube, da ist es schon wichtig, auch wirklich zu denken, was kann ich, was kann ich denn, was kann ich Gutes tun für morgen, für nächste Woche oder für nächstes Monat, damit mir und den anderen die Arbeit erleichtert wird. Oh, ich habe auch so Angst, dass das der erste Kommentar sein wird. Oh, schon wieder so ein DevOps-Berater, der Ideen bringt, aber nichts Konkretes. Aber das ist eine private, private
Krise von mir. Nein, also da ist auch wieder klar, diese Frage taucht auch oft auf, woran merke ich denn, dass ich DevOps mache, beziehungsweise woran merke ich, dass DevOps einen Impact hat,
wie man so schön auf Neudeutsch sagt. Und da empfehle ich, oder also empfehle ich, weil es in der DevOps-Literatur gängig ist, deswegen sage ich lieber, die DevOps-Literatur empfiehlt das, sich erst mal nur vor dieser ganzen Überforderung erst mal nur auf vier Kennzahlen zu beschränken, die einem relativ solide Aussage darüber geben, wie man denn gerade im DevOps-Game so abschneidet und ob die eigenen Verbesserungsmaßnahmen, die man tun möchte oder die man anstrebt,
ob die tatsächlich einen Einfluss haben. Und es sind die berühmt-berüchtigten Dora-Metrics. Und Dora ist das, war damals, existiert meines Wissens nach nicht mehr, Dora war das DevOps Assessment and Research, nee, Dora Research and Assessment Institute. Und die haben sehr viel geforscht zum Thema, was bedeutet, man könnte sagen, kompetentes DevOps oder produktives DevOps.
Und die haben das erst mal runtergebrochen auf diese vier Metriken, die relativ solide eine Aussage darüber treffen und das wäre die Lead Time for Changes, die Deployment Frequency, die Mean Time to Failure oder Between Failures und die Change Failure Rate. Und die wichtigste oder die interessanteste ist dann meistens, wie oft deployen wir eigentlich? Ah, okay, wir deployen einmal im Jahr. Warum? Ja, weil unsere Vorbereitungszeit für so ein Deployment
sind sechs Monate, deswegen können wir nicht öfter deployen. Okay, das wäre doch schon mal ein etwas konstruktiverer Ansatz, zu sagen, was müsste denn passieren, damit unsere
Vorbereitungszeit auf ein Deployment nicht mehr sechs Monate, sondern ein Monat ist. Also ich greife diese Zahlen jetzt vielleicht ein bisschen plakativ, aber also wie könnten wir unsere Vorbereitungszeit auf das jeweilige Deployment verkürzen, damit wir unsere Deployment Frequenz, Deployment Frequency erhöhen können und sagen können, wow, wir releasen Software jetzt nicht mehr so und so oft, sondern doppelt so oft, weil wir machen jetzt DevOps. Wir hatten eine Beraterin
da. Nein. Weil das Schöne daran ist, wenn man sich auf diese vier relativ leicht zu verstehenden Metriken konzentriert, manche Dinge werden einfach leiser. Also es ist auch gleichzeitig eine Einladung an das Projektteam, zu sagen, ihr müsst nicht alle Zahlen haben und ihr müsst auch nicht alle Kennzahlen wissen und ihr müsst nicht überall schrauben, das sind viel zu viele Nebenschauplätze. Fokussiert euch erst mal auf diese vier Zahlen. Findet die erst mal
raus. Das ist ja meistens schon Schritt eins. Also gibt's die Technik Magic Dashboard. Also wenn du ein magisches Dashboard hättest und da würden alle Zahlen draufstehen, die du jemals kennen wollen würdest oder kennen müsstest, wie würde dieses aussehen? Also da kann eine DevOps Intervention, kann einfach schon darin bestehen. Findet raus, wie eure Zahlen gerade sind. Schaut euch diese Zahlen an. Seid erst mal schockiert und zwei Tage später geht's los mit der Arbeit und
dann machen wir was daran. So ein bisschen wie beim Abnehmen. Trau dich auf die Waage, guckt dir die Zahl an, seid zwei Tage traurig, das ist voll okay und dann geht's los. Ja, das finde ich einen spannenden Ansatz. Das auch mal auf so einen Metriken her zu reduzieren auf, wie du das sagst, also ich meine die vier Metriken, die sind ja auch schon aus dem Namen her gut verständlich. Also man hat eine Idee, was dahinter steckt. Bei manchen Metriken
sitzt man ja im Projekt so davor und wundert sich, was ist eigentlich jetzt da gemeint. Und das finde ich natürlich schon auch einen interessanten Ansatz. Jetzt hat man bei DevOps sehr häufig so das Bild, also das erste Bild, was mir dazu einfällt, ist diese liegende Acht, wo man dann immer so einen Haufen Prozessphasen da so drauf hat. Wo ist denn da für dich jetzt, also du erzählst uns jetzt gerade einen anderen Zugang zu DevOps als dieses Bild oder vielleicht steckt das da
mit drinnen. Wo ist denn da für dich der Zusammenhang? Ja, klar, dieser DevOps-Achter, der ist natürlich auch viel weit verbreitet, vor allem, ich finde, bei Softwareherstellern, die dann ganz toll zeigen, wie ihr jeweiliges Tool, welchen Teil von dieser DevOps-Acht oder vom DevOps-Phasenmodell abbilden. Ich weiß nicht, warum das für mich nie so der Zugang war. Also,
ich weiß nicht. Natürlich kann man diesen DevOps-Achter benutzen, um zu zeigen, hier geht die Planung los, dann wird programmiert, dann wird getestet, dann wird deployed, dann wird released, dann wird und so weiter und so weiter, wie man die dann unterteilen will. Und dann geht alles wieder zurück ins Projekt. Aber das ist für jemand, der im Projekt gerade sitzt und sich wünscht, gewisse Development-Pains nicht mehr zu empfinden, seine Burnout-Rate runterzuschieben und nicht mehr
Geld zu verbrennen mit sinnlosen Meetings, nicht ganz so hilfreich, würde ich behaupten. Und vielleicht habe ich es deswegen nicht so als Zugang gewählt zu DevOps-Beratung oder DevOps-Didaktik, wie ich es ganz gern nennen würde. Aber ja, klar. Es ist ganz spannend, dass du das gerade sagst, weil ich jetzt, wo ich so darüber nachdenke, dieses Bild kenne ich eigentlich häufig aus irgendwelchen Marketingbroschüren,
die ich irgendwo sehe. Ich sage auch nicht, dass das nicht hilfreich ist, um zu zeigen, guck mal, das muss getan werden, das muss getan werden, das muss getan werden. Aber ja, und jetzt? Aber ja, der DevOps-Achter, ein anderer Klassiker. Aber ich empfehle lieber, also, was heißt ich
empfehle? Der DevOps-Achter ist natürlich eine Möglichkeit, um klarzustellen, dass man an alles denkt oder sicherzustellen, dass man an alle Phasen denkt, aber sagt eben nicht viel darüber aus, was mache ich jetzt in meinem täglichen Alltag, um unsere faszinierende Welt der IT
besser zu navigieren. Ich meine, vielleicht ist das auch eine Art Checkliste. Wenn du sagst, man guckt sich in seinem Workshop mal an, wo haben wir den Pain eigentlich gerade, dass wir irgendwo leiden, entweder monetär oder menschlich oder in irgendeiner Variante, dann kann man natürlich diese Elemente der acht durchgehen und sagen, wie sieht es da aus, wie sieht es da aus, wie sieht es da aus, wie sieht es da aus, um das vielleicht auch zu
identifizieren an einer gewissen Phase hin. Und vielleicht auch, wenn ich jetzt natürlich schaue, DevOps heißt ja nicht nur Dev, sondern eben auch Ops, also da vielleicht auch mal den Blick über den Tellerrand zu wagen, was gibt es denn da beim Deployment, beim Betrieb auch noch für ein Pain, den ich habe. Gut, dass du das jetzt erwähnst, weil ein anderes didaktisches Bild, was ich immer
und immer und immer wieder verwende, ist die Wall of Confusion. Und die Wall of Confusion, also die Wand der Verwirrung zwischen Entwicklung und Betrieb, soll ja eigentlich auch das erreichen, also soll deutlich machen, in jedem Prozess in dieser DevOps 8 gibt es ein davor und ein danach. Und wenn die nicht miteinander reden, dann muss man sich nicht wundern, dass es nicht so schnell
und sexy läuft, wie es vielleicht könnte, wie es vielleicht ein Optimum wäre. Aber ja, die Wall of Confusion soll auch klar machen, egal was du arbeitest, also egal an welchem Teil des DevOps 8, dass du arbeitest, es wird einen Menschen geben, der vor dir und nach dir mit deiner Arbeit arbeiten muss. Und wenn du deinen Code einfach so rüberschmeißt, ohne ihn zu testen, leidet der Tester. Wenn der Tester einfach nur sagt, ja, alles grün, funktioniert alles und
gibt es weiter, leidet der Betriebsmitarbeiter. Und wenn der Betriebsmitarbeiter sagt, wisst ihr was, ihr könnt mich mal, ich gehe nach Hause, dann leidet die gesamte Firma, weil der Kunde das Endprodukt nicht benutzen kann. Und wer weiß, wie lange das noch gut funktioniert. Ja, ja. Also ich liebe es auch zu zeigen und aufzuzeigen, dass egal an welchem Punkt du bist in dieser
Wertschöpfungskette von Software, du machst das nicht in einem Vakuum. Nur weil du am Ende des Tages einen Laptop zumachst, heißt das nicht, dass nicht andere davon profitieren würden oder darunter leiden, dass du eventuell ein bisschen mehr dich damit beschäftigst. Und da kommen wir vielleicht auch wieder zu diesem Community-Aspekt von DevOps, das DevOps eben so deutlich gemacht hat, wenn wir die Betriebsmitarbeiter schlecht behandeln, leiden die Entwickler darunter. Und
wenn die Entwickler schlecht behandelt werden, dann hilft es dem Betrieb auch nicht. Also das ist ein weniger dieses "Wir hier und ihr dort" und "Wir sehen uns vielleicht in der Weihnachtsfeier einmal im Jahr und das war's". Nein, wir müssen zusammenkommen. Wir arbeiten an derselben Software,
wir sind zwei Seiten derselben Münze. Genau. Ja, das finde ich total spannend, weil das ist ja, ich meine, da stecken ja ganz viele Dinge drinnen, die wir ja mit Agilität schon erreichen wollten und vielleicht auch zum Teil getan haben, aber es geht natürlich hier schon noch mal einen Schritt
weiter. Das höre ich auch raus, das finde ich auch total wichtig. Und ich denke, das Thema Kommunikation und auch mal die Wertschätzung für die anderen, die da vor mir sind und die nach mir sind und das eben auch quasi in deren Sinne auch zu arbeiten und zu wirken, das ist natürlich schon etwas, was ich total wertvoll finde für den ganzen Prozess, der dann immer wieder laufend
sich auch wiederholt. Also das ist ein schönes Bild, gefällt mir sehr gut. Wenn ich jetzt Projektmitarbeiter bin und da unter dieser Last ächze und was würdest du mir denn raten, wie kann ich denn das Thema bei mir mal in die Gänge bringen, ohne vielleicht jetzt gleich mal einen halbjährigen Coaching-Betreuungs-Beratungsauftrag auszulösen, über den ich gar keine Budgethoheit habe, aber einfach um das Thema loszutreten bei uns im Haus? Ja, das ist auch
wieder eine unglaublich gute Frage. Was ich in der Vergangenheit häufiger gemacht habe, war, ich habe einen einzelnen Vortrag gegeben und habe in diesem, keine Ahnung, einstündigen Workshop oder Vortrag, habe ich eben so ein paar Konzepte von DevOps versucht mitzugeben und zu visualisieren und habe dann jeden einzelnen Teilnehmer, der dann da war, eingeladen, mitzuschreiben und sich halt
eben für einzelne Punkte zu überlegen, wie würde ich das in meinem Arbeitsalltag ändern. Also zum Beispiel das S in "Calms for Sharing", wo gebe ich Wissen nicht weiter, was aber anderen in meinem, die auch im selben Boot wie ich sitzen, weiterhelfen würden. Und dass die Leute sich dann einfach mal fragen, wo könnte ich mehr diese Konzepte berücksichtigen, damit alle davon profitieren.
Weil wenn es alle machen, kommt es ja wieder zurück auf den Einzelnen und dann kamen öfter mal solche Reaktionen ein paar Wochen später von dem jeweiligen Workshop zum Beispiel, hey, ich habe gemerkt, dass ich diese und diese jene Sache verbessert habe, die erschienen mir recht klein, aber andere Personen, die damit arbeiten müssen, für die war das plötzlich, also ich habe denen sozusagen einen Stressor weggenommen. Aber mir war gar nicht bewusst,
dass meine Handlung hier so viel Potenzial hatte, andere Leute zu stressen oder eben nicht. Also ich würde behaupten, eine der ersten Schritte ist, den Impuls mitzunehmen, was ich an dieser
Wertschöpfungskette mache, hat einen Effekt auf die Person davor und danach, immer. Und sich selbst dann eben fragen, wo könnte ich eine bessere Kultur leben, wo könnte ich bessere Zahlen erfassen und nutzen für meine Entscheidungen, wo könnte ich Monitoring betreiben, das sinnvoll ist, wie könnte ich die Ergebnisse, die ich sammle, das Wissen, das ich finde, besser verteilen und auch zugänglicher machen und wie könnte ich vielleicht auch einfach mal Dinge, die nicht
relevant sind, auch einfach mal wirklich wegstreichen und wirklich sagen, okay, nein. Also ja, und deswegen lade ich dann meine Teilnehmer auch oft ein, zu sagen, jetzt passt euch mal an die eigene Nase und fragt euch, ist es wirklich wichtig, musst du das jetzt machen, ist das relevant, hast du dieses Wissen gut mitgegeben, sind die Zahlen, die du für deine Entscheidungen nutzt, wirklich die besten, wichtigsten Zahlen und bist du manchmal vielleicht
auch ein bisschen unkollegial? Und natürlich ist das so ein klassisches, ja, der Berater schiebt uns immer die Schuld zu. Ja, das stimmt. Aber es gibt diesen wunderbaren Satz, den ich da auch immer wieder zitieren, nämlich "Kluge Menschen können so gut wie jedes Problem lösen, wenn sie
verstanden haben, was das Problem ist, aber meistens wissen sie es nicht." Ja, das finde ich noch eine schöne Inspiration dazu, weil die fehlende Klarheit ist oft das Thema, dass man gar nicht weiß, was man tun könnte oder so, also dass man quasi auch gar keine Klarheit darüber hat.
Ja, und manchmal ist es, also gerade, das ist jetzt vielleicht auch wieder so ein bisschen der Human Cost in der IT, aber was ich ja auch oft erlebt habe, also ich komme ursprünglich eigentlich aus der Didaktik, aus der Lehre und jetzt bin ich in der Informatik und was ich oft merke, ist dieses, wenn du mich, also, okay, es wird so oft erwartet, dass das Gegenüber sofort weiß, was gemeint ist, sofort das Tool verstanden hat, sofort drin ist, sofort das alles weiß und
wenn die Person es nicht weiß, dann hat sie es mit einer Google-Suche, hat sie sich das dann selber nebenbei beigebracht, während sie Kaffee trinkt. Also, manchmal sollte die Informatik als Gesamtheit sich vielleicht daran erinnern, dass man lernt nicht alles sofort. Man weiß nicht immer,
was Sache ist. Manchmal braucht man mehr Anleitung und mehr Erklärung, manchmal muss man mehr Ressourcen aufbringen für gute Schulung, gute Lehre, für gute Anleitung und, also, ich habe es oft erlebt, dass ich in der Informatik dann auch einfach ganz offen gesagt habe, nö, ich habe keine Ahnung, wovon du gerade redest, könntest du mir das bitte mal erklären, wirklich? Und die Reaktion dann oft war, hey, wieso verstehst du das nicht? Bring dir das bei. Und damit war die
Interaktion dann beendet. Und das ist halt kein so toller Nährboden für Austausch, für Offenheit, für hey, ich verstehe gerade nicht, wie ich das hier zu tun habe, könntest du mir das bitte besser erklären? Ich will jetzt nicht so weit gehen und sagen, das ist ein typisches Informatikproblem, ich werde das haben viele Domänen, aber dass wir offener und ehrlicher damit sind, hey,
ich brauche mehr Anleitung, ich brauche mehr Erklärung, sag mal was. Man sollte ja auch in der Lage sein, zu seinem direkten Vorgesetzten zu gehen und zu sagen, du hast mir jetzt eine Aufgabe gegeben, wann ist für dich diese Aufgabe beendet? Was ist für dich jetzt die Definition of Done? Oder welches Maß an Verbesserung in Zahlen würde dir spiegeln, dass es eine Verbesserung gegeben hat? Oder welche Kosten müssten wir konkret einsparen, damit du das als gut empfindest?
Also, da sind wir wieder beim Thema Monitoring Measurement, aber eben auch beim Thema, wie können wir eine Kultur schaffen, in der so eine Frage überhaupt erst gestellt werden kann? Ja, also ich finde, damit deckt man ja dann häufig auch was auf. Also das ist ja häufig, dass gerade wenn es um so Metriken und sowas geht, man sagt, wann ist denn für dich gut, was ist denn das Ziel? Dass da dann ja auch, oh, da weiß ich gar nicht, puh, müssen wir erst mal
schauen. Also, dass man sich da nicht so rantraut. Also, das finde ich einen schönen Impuls, dass man da auch für mehr Klarheit und mehr Offenheit fördert. Und ich persönlich habe in den Projekten, auch als externer Berater oder als Projektmitarbeiter, ist eigentlich immer sehr gute Erfahrung gemacht, einfach auch so ein As-is-ing zu machen. Wenn ich was nicht verstehe, dann zu sagen, keine Ahnung, wovon ihr hier redet, holt mich mal mit rein. Und Gott sei Dank in einem
Umfeld, wo das immer auch dann mehr gewertschätzt wurde und dann auch mir geholfen wurde. Und dann weiß ich, bevor ich da herumdruckse und selber mich dann heimlich auf die Suche mache, nach Informationen, die mir vielleicht noch fehlen. Ja, da waren jetzt total viele Impulse und Themen drinnen. Ich fand das einen total schönen und spannenden, mal einen anderen Blick auf DevOps, außer den Marketingfolien vielleicht. Warte mal, ist immer ein schöner Zugang,
fand ich jetzt sehr erfrischend. Und Georgia, ich danke dir sehr, dass du hier im Podcast warst, zu Gast nach mehreren Anläufen, wie wir es jetzt geschafft haben. Und wir werden deine Kontaktdaten natürlich auch in die Show Notes mitpacken. Vielleicht der eine oder andere hat dann noch eine Rückfrage an dich. Das hat sich hier ganz gut bewährt. Und ja, ich sage herzlich Dankeschön und hoffentlich bis bald. Danke, danke für's haben und mehrfach einladen. Ciao. Ciao. Ciao. Ciao. [Musik]