„Kennst du ,Projekt Phoenix’? Mein Chef hat es mir empfohlen. Vielleicht sagt dir das was?“ fragt mich meine Tochter Nadine und schaut mich dabei gespannt an. Ich kenne diesen Blick nur zu gut. Da scheint sie etwas richtig umzutreiben.
„Und ob mir das was sagt“, antworte ich und halte ihr das – typischer Zufall – in Reichweite liegende Buch mit dem schwarzen Cover vor die Nase. „Darin geht es um DevOps. Es ist der Roman zum Thema. Geschrieben von den Vordenkern der DevOps-Bewegung Gene Kim, Kevin Behr und George Spafford.“
Lachend füge ich hinzu: „Du weißt doch. Übertrieben technisch-akademische Beschreibungen liegen mir ja so gar nicht. Da kommen Dinge, die Spaß machen sollen, auf einmal unheimlich staubtrocken rüber. Aber dieses Buch ist anders. Und ich sehe Parallelen zu meiner aktuellen Situation.“
„Leihst du es mir mal für eine Woche?“
Ich stutze. Meiner Tochter kann ich schlecht was abschlagen. Aber dieses Buch fesselt mich doch gerade sehr. „Gerade jetzt, wo es wirklich spannend wird? Bitte besorge es Dir selbst,“ sage ich mit einem aufmunternden Lächeln. „Es wird dich nämlich viel länger als eine Woche in seinen Bann ziehen!“
Dann erzähle ich ihr ein bisschen.
‚Projekt Phoenix‘ ‚ handelt von Bill, einem IT-Manager, der plötzlich vor einem scheinbar unlösbaren Problem steht. Er soll „Phönix“ wieder auf die Beine bringen. Sein CEO setzt ihm eine Frist von 90 Tagen. Die Drohung – „sonst wird Deine gesamte Abteilung dichtgemacht“ – steht im Raum. Der IT-Spezialist findet sich im Chaos wieder und versucht zu retten, was er kann. Und Bill findet eine Lösung, die das beschreibt, was wir heute DevOps nennen und das seit geraumer Zeit unseren Arbeitsalltag bestimmt. Doch dazu später.
Nadine hat sich kurz darauf das englische Original gekauft und mir begeistert berichtet, dass es ihr gefällt. Ich bin schon gespannt auf unseren Austausch!
Beim Lesen von „Projekt Phoenix“ hatte ich manchmal richtig Herzklopfen. Woran das lag? Ich fand mich in Situationen wieder, die mir allzu bekannt vorkamen. So saß ich manchmal da und ärgerte mich über mich, dass ich die Problemstellung, die in diesem Buch so glasklar beschrieben wurden, damals in meinem eigenen Umfeld nicht erkannt hatte.
Es begann vor knapp zwei Jahren.
Früher war alles ganz einfach …
Als IT-Projektmanagerin war ich gewohnt, immer nur ein Projekt nach dem anderen zu betreuen – jeweils von der Definition aller Anforderungen bis zur Übergabe in den Betrieb. Das waren abwechslungsreiche Themen. Unter anderem ging es um das Partnerportal, um CO2-Berechnungen sowie um die Erstellung strategischer Marktprognosen. Zu dieser Zeit zog ich „vogelwild“ von einem spannenden Projekt zum nächsten und musste mich herzlich wenig um die nachfolgenden Prozesse im Betrieb kümmern.
Mitte 2020, mein aktuelles, agiles Projekt war kurz vorher erfolgreich in Betrieb gegangen, kam die überraschende Frage: „Kannst du nicht zu deiner einen Applikation aus der Strategie noch zwei weitere aus der Kommunikation übernehmen?“ Ich sollte nun dafür sorgen, dass bestehende Applikationen laufen und wenn nötig Weiterentwicklungen erfahren. Eine reine Neuentwicklung, bis dato mein Lieblingsthema, stand hier nicht mehr im Fokus.
Was sollte ich sagen? Ich hatte gerade Angebote für zwei neue schöne agile Entwicklungsprojekte in anderen Abteilungen. Und nun müsste ich mich mit dieser neuen Aufgabe anfreunden und bereits laufende Anwendungen betreuen?
Genau das fragte sich auch der Bill aus dem Roman. Er musste unter dem Druck der Ereignisse ins kalte Wasser springen. Sollte auch ich das tun? Die mir angetragene Herausforderung, drei Applikationen im Betrieb zu übernehmen, war auf alle Fälle neu und spannend. Und ich brauchte nicht mein gegenwärtiges Umfeld, in dem ich mich sehr wohlfühlte, verlassen. So entschied ich mich: Ich probiere das jetzt einfach mal aus und wage den Sprung aus meinem gewohnten Entwicklerumfeld in eine DevOps-Umgebung. Was darunter genau verstanden wird, lerne ich bis heute.
Eine effizientere Form der Zusammenarbeit
DevOps – was die Bereiche Development und Operations begrifflich zusammenfasst – ist agiles Arbeiten weitergedacht. Die Weiterführung der agilen Entwicklung in den Bereich Operation. Auf einmal ist für die Entwickler nicht mehr nach Fertigstellung einer Software Schluss, sondern sie sind auch für einen reibungslosen Übergang in den Betrieb verantwortlich. In meinem Team gab es damit plötzlich auch Kollegen mit Betriebserfahrung.
Die Zeiten ändern sich
Auf einmal war ich also für drei Applikationen und mehrere Fachbereiche der BMW Group zuständig. Jetzt hatte ich statt eines großen Entwicklerteams gleich mehrere kleine Teams plus unsere Betriebskollegen zu betreuen. Es ging auch nicht mehr darum, eine Software zum Laufen zu bringen – vielmehr sollten Applikationen optimiert und an neue fachliche und regulatorische Vorgaben angepasst werden. Ganz ehrlich: In dieser betriebsseitigen Ecke der Softwarenentwicklung wollte ich eigentlich nie landen.
Warum? Da gab es diese typischen Klischees und Vorurteile. Im Betrieb würde alles ganz bedächtig vorgehen, sehr gesetzt, ein bisschen beamtenmäßig vielleicht, eben uncool für uns aus der Entwicklung, die wir – das gebe ich offen zu – gerne mal die Stars spielen und uns viel auf unsere Kreativität zugute halten. Was soll ich sagen? Ich wurde vom Gegenteil überzeugt. Seit 2020 habe ich sogar eine ganze Menge dazugelernt. Denn ob ich wollte oder nicht – die mir gestellten Aufgaben waren am besten in einem DevOps-Umfeld zu lösen. Darin fand ich mich jetzt wieder. Und ich fühle mich wohl dabei!
DevOps reißt Mauern ein
Früher haben wir aus der Entwicklung unsere fertige Applikation nur „über den Zaun“ zu werfen brauchen. Was danach kam war Sache des Betriebs und ging uns nichts mehr an. Wir hatten ja bereits das nächste spannende Projekt in der Timeline. Aber die Zeiten ändern sich. Anwendungen sind komplexer geworden, müssen in kürzeren Intervallen an Umgebungen und Anforderungen angepasst werden. Updates werden immer schneller verlangt. Automatisierung von Prozessen, wie Tests oder Einspielung von Änderungen auf Produktion ist ein Muss. Teams brauchen ein ganz spezielles Know-how, müssen sich aber auch untereinander vertreten können. Das erfordert ein Umdenken. Und dazu befähigt uns DevOps. Hier kennen wir keine Zäune mehr.
Wenn man es genau nimmt, war es kein Zaun, sondern eine regelrechte Mauer, die Entwicklung und Betrieb bis vor gar nicht allzu langer Zeit trennte. DevOps reißt sie nieder. Als Verantwortliche schaue ich hier nicht mehr einfach nur nach vorn – jetzt geht mein Blick auch verantwortungsvoll nach links und recht. Betriebliche Aspekte sind immer präsent. Überhaupt ist Verantwortung einer der Kernwerte von DevOps-Teams. Der vielfach zu beobachtende Tunnelblick in der Entwicklung steht vor einem Perspektivwechsel. Auf einmal müssen sich auch die Entwickler betriebswirtschaftlichen Fragen stellen: Ist das Produkt zukunftsfähig? Wie sieht es mit den Kosten aus? Kann man es gut warten? Gleichzeitig tauchen die „Betriebler“ in die Welt der Entwicklung ein. Es ist, wie wenn sich die Finger zweier Hände verschränken, die vorher jede ihr eigenes Rad gedreht haben.
In DevOps ändert sich die Arbeit auf beiden Seiten. Die „Betriebler“ sind jetzt viel früher in der Softwareentwicklung eingebunden und die Entwickler haben immer noch mit der Applikation zu tun, wenn ihre kreative Software schon seit langen produktiv gegangen ist. Ich sehe es auch bei uns im Konzern: Es tut auf beiden Seiten am Anfang weh und erzeugt Reibung. Doch wir haben jetzt die Chance, eine Umgebung zu schaffen, in der jeder eine übergreifende Verantwortung wahrzunehmen hat.
Ich erinnere mich sehr gut noch an die Zeit, als wir freitags angefangen haben, die Software auf Produktion zu bringen – und das dann das ganze Wochenende gedauert hat. Heute brauchen wir dafür nur wenige Stunden. Ich will sicher nichts beschönigen. Noch funktioniert nicht alles reibungslos. Es passiert noch immer, dass schnell mal eine Änderung eingespielt wird und anschließend nichts mehr geht. IN einem großen ist nicht nur das DevOps Team involviert. Da laufen komplexe Prozesse ab, in denen unterschiedliche externe Parteien eingebunden sind. Alle müssen sich einspielen. Da knirscht es schon mal im Getriebe. In solchen Situationen sind Führungsfähigkeiten gefragt, die unter anderem durch Working Out Loud vermittelt werden.
Und wieder ist da Working Out Loud drin!
Meine Entscheidung für DevOps-Projekte ist ganz wesentlich auch von meinem Engagement für Working Out Lod (WOL) getrieben. Mir war schnell klar, wie die WOL-Kernelemente mit denen des DevOps-Konzepts korrelieren. Diese sind:
Offenheit & Großzügigkeit (WOL) – Kultur des Vertrauens und der Zusammenarbeit (DevOps)
Die entscheidende Voraussetzung für eine neue Kultur des Vertrauens und der Zusammenarbeit ist das Mindset, die innere Einstellung. Genauso unerlässlich ist das Vertrauen innerhalb des eigenen Teams und der extern an den DevOps-Prozessen beteiligten Teams. Das geht nur mit Offenheit und Großzügigkeit.
Schauen wir noch mal zurück auf die Zeit vor DevOps: Da wurde vom Fachbereich wieder ein größeres, verbessertes Feature angefordert und die Entwicklung musste sich etwas einfallen lassen. Dazu gesellt sich im ungünstigsten Moment vielleicht noch ein Produktionsproblem, das am besten gestern gelöst werden sollte. Oh, wie ich mich an dieses Gefühl der Machtlosigkeit erinnere. Wir standen massiv unter Druck und dann passierten Fehler. Diese wurden mit Versagen gleichgesetzt. So ist es nur verständlich, dass wir Fehler eher versteckten, statt sie offen anzusprechen.
Bei DevOps funktioniert Zusammenarbeit nur, indem die Fehlerkultur auf ein neues Niveau geführt wird. Ist es nicht so, dass die wirklichen Ursachen von Fehlern meist tiefer liegen als im persönlichen Versagen? Statt uns in Schuldzuweisungen zu verlieren, gehen wir gemeinsam auf Fehlersuche. Erfolge werden ebenfalls zusammen errungen und dürfen gefeiert werden. Neue Ideen werden gezielt eingefordert und anschließend honoriert.
Arbeit sichtbar machen (WOL) – Arbeit sichtbar machen (DevOps)
Indem wir bei DevOps Software schnell ausliefern, machen wir die Arbeit sichtbar. Wenn wir automatische Tests einführen und an vielen Stellen Qualität sichern, verhindern wir, dass mögliche Fehler bis zum Kunden gelangen. Sollte das doch einmal geschehen, sind wir sofort in der Lage, diese zu beheben.
Wie haben wir es bisher gemacht? Was war richtig – was wollen wir ändern? Solche Fragen werden bei DevOps laufend gestellt. Altes darf gern hinterfragt werden. Mit DevOps werden Informationen und Wissen aus den Verstecken herausgeholt, in denen wenige Know-how-Träger sie gehortet haben. So kommt es nicht mehr zu informativen Engstellen – es gibt keinen Wissensstau in unnötigen „Flaschenhälsen“ mehr. Dafür wird Arbeit im Team belohnt und der Einzelne gefördert. Damit einher geht eine neue Kultur des achtsamen Führens.
Zielgerichtetes Vorgehen (WOL) – Hohe Kundenorientierung (DevOps)
Bei DevOPs möchten wir langfristige Ziele erreichen. Dafür brauchen beständige Teams, die Verantwortung für die Umsetzung des Ziels übernehmen. Es geht nicht mehr darum wie oben beschrieben, dass die Teams nach jedem Release neue Aufgaben übernehmen. Nein, sie bleiben zusammen und können so länger und schneller voneinander lernen, sich verbessern – mit dem Ziel hoher Kundenzufriedenheit.
Und die Moral von der Geschicht’?
Zugegeben, DevOps verlangt uns einiges ab. Entwickler fühlen sich anfangs vielleicht ausgebremst, der Betrieb womöglich überfordert von den rasent-quirligen Prozessen der Softwareleute. Erstere müssen nun mit mehr Verantwortung auf ihren Schultern klarkommen, der Bereich Betrieb wird ins kalte Wasser der Agilität geworfen. Das erfordert Überzeugungsarbeit. Es gibt neue Abläufe. Auch das eine oder andere Feuer muss gelöscht werden. Wir alle sammeln Erfahrungen. Eine davon lautet: Wenn du Erfolg willst, dann binde den Betrieb so früh wie möglich in die Entwicklung ein.
Und was heißt das für mich?
Für mich hat sich jedenfalls herausgestellt, dass das DevOps-Umfeld genauso fordernd und erfüllend sein kann wie das reine agile Projektgeschäft, in dem ich früher tätig war.
