DevOps von innen nach außen

Alle wollen DevOps! Neue Dinge in einer Organisation einzuführen, ist aber immer eine Herausforderung.

Es ist ein Abenteuer, und auf eurer Reise werdet ihr eine bunt zusammengewürfelte Gruppe von Begleitern haben. Anhand der Figuren aus Alles steht Kopf schauen wir uns diese Charaktere an – und wie ihr aus jedem einen großartigen Reisebegleiter machen könnt!

Der DevOps-Umweg

Bevor wir loslegen können, sollten wir wohl kurz über dieses DevOps-Ding sprechen. Über die Definition von DevOps wird viel gestritten. Für diesen Blogbeitrag sagen wir: DevOps ist eine Reihe von Praktiken, die Automatisierung, eine ganzheitliche Sicht auf Anwendungen sowie Geschwindigkeit bei Softwareentwicklung und Deployment fördern. Es geht also darum, Software zu entwickeln, sie an Kunden auszuliefern und sicherzustellen, dass sie auch nach der Auslieferung weiter funktioniert.

Wir glauben, dass DevOps und Continuous Delivery für die Branche genauso wichtig werden wie Agile. Entwickler werden Organisationen, die kein Continuous Delivery und DevOps betreiben, mit ratlosem Unverständnis betrachten. Schauen wir uns also die Charaktere an, denen ihr auf eurem Weg zu moderner Softwareentwicklung begegnen könntet.

Willkommen in der Schaltzentrale

Im Film Alles steht Kopf befinden wir uns im Kopf eines Mädchens namens Riley. Die Grundemotionen Wut, Ekel, Angst, Freude und Kummer teilen sich ein Kontrollpult. Die Kombination dieser unterschiedlichen Perspektiven prägt Rileys Persönlichkeit und Verhalten. Diese Emotionen sind natürlich stark vereinfacht, haben aber vielen Menschen geholfen, besser zu verstehen, wie Emotionen funktionieren. Versuchen wir also, diese Vereinfachung auf den DevOps-Übergang in einer Technologieorganisation anzuwenden.

Freude

In Freudes Welt ist alles großartig. Freude ist ein Early Adopter, tüftelt ständig und kann Dinge meist besser anfangen als zu Ende bringen. Es ist wichtig, Freude dabeizuhaben – wir brauchen die Alles ist großartig-Mentalität. Aber wir müssen auch daran denken, dass anders nicht automatisch besser ist.

Wir müssen unsere Entscheidungen kontinuierlich hinterfragen, statt einfach einem leuchtenden Ziel hinterherzulaufen. In jedem Veränderungsprozess ist es wichtig, dass wir jederzeit wissen, warum wir tun, was wir tun, und wie das zum übergeordneten Ziel passt. Wir wollen bestimmte Probleme lösen und greifen nicht einfach zu einer Tasche voller neuer Tools, nur um etwas zu tun.

Menschen mit den Eigenschaften von Freude neigen dazu, Technology Apologists zu sein. Sie sind sehr beeindruckt davon, dass ein Tool funktioniert oder überhaupt existiert, achten aber nicht unbedingt auf dessen mangelnde Reife oder Benutzerfreundlichkeit. Der Begriff Technology Apologist wurde von Alan Cooper in seinem Buch The inmates are running the asylum geprägt.

Es kann schwierig sein, Freude auf Kurs zu halten und nach den etablierten Prozessen arbeiten zu lassen. Freude kann als Frühwarnsystem für kommende Probleme dienen. Sorgt dafür, dass es so einfach ist, Dinge richtig zu machen, dass Freude gar nicht anders kann, als für die Verbesserung, die ihr gerade eingefallen ist, ein Jira-Ticket zu erstellen.

Lieblingszitate eures Freude-Charakters:

• „So machen sie es bei Facebook.“

• „Ich habe dieses neue Tool gefunden.“

• „Ich habe auf HackerNews gelesen …“

• „Oh ja, das funktioniert noch nicht ganz, aber […]“

Freudes Lieblingstools:

• Etwas, das sie selbst aus einem Repository mit Code kompiliert hat, der in einer angesagten Sprache wie Rust oder Go geschrieben wurde.

• Alternativ: Vim.

Etwas, das sie selbst aus einem Repository mit Code kompiliert hat, der in einer angesagten Sprache wie Rust oder Go geschrieben wurde.

Alternativ: Vim.

Wut

Wut kriegt den Scheiß erledigt! Ihr könnt sicher sein: Wenn etwas kaputt ist, werdet ihr es von Wut hören. Wenn Wuts Kollegen sich nicht ganz an den Coding Style halten oder in Meetings Zeit verschwenden, bleibt das nicht unerwähnt. Wut ist sehr produktiv, aber mit Wut unterwegs zu sein, kann ein holpriger Weg sein. Die Produktivität sinkt meist, wenn regelmäßig ein wütender Entwickler an eurem Schreibtisch steht.

Ein Weg, mit Wut umzugehen, besteht darin, sicherzustellen, dass ihr mit Wut auf einer Linie seid und Wut keine unrealistischen Erwartungen an den Reifegrad dessen hat, womit sie arbeitet. Ebenso wichtig ist, Wut nicht alle Entscheidungen treffen zu lassen. Sonst flattert ihr wie ein Glühwürmchen umher, um den Brand du jour zu löschen.

Ihr müsst jedoch bedenken: Wut entsteht nicht aus dem Nichts. Findet die Ursache heraus und geht sie an. Findet heraus, was Wut antreibt, und sie wird ein starker Verbündeter sein. Wut schafft verdammt viel!

Lieblingszitate eures Wut-Charakters:

• „Die Pipeline ist kaputt.“

• „Wer hat meinen Build kaputtgemacht?“

• „Ich werde nicht länger auf die IT warten – ich kaufe mir meinen eigenen Server.“

Wuts Lieblingstools:

• Die Druck-Taste

• Outlook

• Zu eurem Schreibtisch gehen

Ekel

Ekel erfüllt einen sehr wichtigen Zweck: Er schützt uns davor, uns zu vergiften. Eine gewisse Skepsis gegenüber neuen Tools oder Prozessen ist eine gesunde Eigenschaft. Da viele Change Agents eher zu Freude neigen, empfinden wir Ekel als sehr rückwärtsgewandt. Sie sind zu zögerlich, als dass wir sinnvoll mit ihnen arbeiten könnten. Doch in vielerlei Hinsicht ist Ekel das Barometer für Erfolg. Denkt daran: Was heute Status quo ist, war irgendwann einmal neu und ekelhaft.

Solange wir Ekel nicht überzeugen können, entwickelt sich der Übergang zu DevOps nicht in eine genussvolle Richtung. Und da DevOps etwas ist, das wir obendrauf streuen, sollte es genussvoll sein. Das, worauf wir hinarbeiten, sollte attraktiver sein als der Status quo.

Wir müssen die Ursachen für Ekels Skepsis entschlüsseln und die giftigen Teile entfernen. Oder sie so lange kochen, bis sie nicht mehr wiederzuerkennen sind. Nehmt für Ekel kleine Verbesserungen vor. Erstellt einen Git-Alias oder ein kleines Skript, das etwas von den Schwierigkeiten nimmt.

Es tut mir leid, das sagen zu müssen, aber vielleicht kommt ihr an den Punkt, an dem ihr Screenshots macht und sie in ein Word-Dokument oder eine PowerPoint-Präsentation einfügt.

Lieblingszitate eures Ekel-Charakters:

• „Das sieht verdächtig nach einem Tool aus den 90ern aus.“

• „Dieses neue Setup sieht sehr komplex aus.“

• „Nur weil es anderswo funktioniert, heißt das nicht, dass es hier funktioniert.“

• „Ich bin mir nicht sicher, ob es dem Unternehmen Mehrwert bringt, wenn ich Git lerne. Das ist etwas für Leute wie dich.“

Ekels Lieblingstools:

• Die von der IT-Abteilung genehmigte IDE

• SharePoint

Angst

Angst ist wichtig. Angst schützt uns davor, verletzt zu werden. Unserer Erfahrung nach konzentriert sich Angst auf den kurzfristig sichersten Weg. Für viele Unternehmen mag es am sichersten sein, weiterhin mit SVN zu arbeiten. Weiterzuarbeiten wie bisher. Langfristig schadet das jedoch dem Unternehmen. Angst betrachtet die Dinge aus der Perspektive von „Ops“. Wir haben etwas, das weiterlaufen muss. Das ist der wichtigste Teil von allem, was wir tun, denn wie können wir unseren Kunden sonst Mehrwert bieten? Für Angst steht Stabilität über allem.

Im Umgang mit Angst ist es wichtig, nichts Unerwartetes zu tun. Stellt sicher, dass ihr eine klare und transparente Roadmap mit Zeitplan habt. Seid ehrlich, wenn ihr wisst, dass es in der nächsten Zeit holprig wird. So kann sich Angst darauf vorbereiten.

Bindet Angst nach Möglichkeit in den Veränderungsprozess ein. Und wenn ihr euch dann maximal darüber ärgert, dass Angst ein pedantischer Nervtöter ist, denkt daran: Alles, was Angst entdeckt und anspricht, ist deutlich günstiger als die Behebung dessen, was bereits in Produktion gegangen ist.

Lieblingszitate eures Angst-Charakters:

• „Ich glaube nicht, dass das funktionieren wird.“

• „Es funktioniert jetzt, warum sollten wir das ändern?“

• „Ich bin mir nicht sicher, ob die Wahl eines Open-Source-Tools wirklich eine gute Idee ist.“

• „Woher wissen wir, dass […]?“

Angsts Lieblingstool:

• Excel

• Visual Studio 2010

• Ein vierzehnseitiges Word-Dokument, das einen Installationsprozess beschreibt

Traurigkeit

Traurigkeit gibt Freude Kontext und ermöglicht Reflexion. Erst wenn wir beides annehmen und zu einem ausgewogenen Ganzen verbinden, werden wir eine erfolgreiche DevOps-Organisation.

Traurigkeit ist das notwendige Gegenstück zur Technologie-Apologetin Freude. Sie sorgt dafür, dass wir nicht vergessen, warum die letzte Umstellung gescheitert ist. Für Freude wirkt sie vielleicht wie eine unerquicklich negative Stimme. Doch das ist nicht der Zweck von Traurigkeit.

Wie Traurigkeit sagt: „Weinen hilft mir, langsamer zu werden und mich in der Schwere der Probleme des Lebens zu verlieren.“ Und genau so fühlt es sich an. Aber wenn wir uns nicht ein wenig damit beschäftigen, wenn wir unsere Retrospektiven nicht ehrlich durchgehen und uns sowohl an Schmerzen als auch an Erfolge erinnern – wie sollen wir uns dann verbessern? Wie sollen wir erfolgreich sein? Traurigkeit vermittelt uns all die wichtigen Erkenntnisse, die wir brauchen, um es beim nächsten Mal besser zu machen.

Im Kern bin ich Freude. Ich fange Dinge an, lasse mich ablenken und beginne etwas Neues. Manchmal vergesse ich, dass es auch eine Realität gibt, die Liebe und Aufmerksamkeit braucht. Ich muss sehr darauf achten, Traurigkeit nicht einfach in den Kreidekreis zu stellen und zu sagen: „Störe meinen Fortschritt nicht.“

Es nervt mich, wenn ich (schon wieder) diese großartige Idee habe und sie jemandem präsentiere, der sich als faktenorientierter, realistischer und besonnener Typ entpuppt. Aber es hilft mir zu erkennen, welche Ideen wichtig sind und welche Ideen besser genau das bleiben sollten: Ideen.

Respektiert und würdigt also Traurigkeit – sie enthält viel Wahrheit.

Lieblingszitate eures Traurigkeit-Charakters:

• „Bei der letzten Umstellung haben wir vergessen …“

• „Denkt daran, dass alle mit ins Boot geholt werden müssen.“

• „Als wir das letzte Mal das Tool gewechselt haben, gab es großen Ärger, weil …“

• „Mit dem neuen Tool ist das Problem immer noch da, nur an einer anderen Stelle im Prozess.“

Traurigkeitens Lieblingstool:

• Die Erinnerung daran, was zuvor schon versucht wurde. Die geballte Summe der Schwierigkeiten bei Umstellungen – vom ersten Tag des Unternehmens bis heute.

• Ein Kaffeebecher von einem Tool-Anbieter, den es längst nicht mehr gibt

Bing Bong

Bing Bong ist Rileys imaginärer Freund. Da er nicht mehr relevant ist, opfert er sich für Rileys psychische Gesundheit.

So gesehen ist er ein Beispiel für eine Codebasis oder einen Tool-Stack, der einmal war. Er war wichtig und zu einem bestimmten Zeitpunkt der kritischste Teil der Arbeitsweise des Unternehmens. Wir sollten unsere Entscheidungen auf den Erkenntnissen basieren, die wir gewonnen haben, als Bing Bong der König unserer Straßen war. Wir sollten aber nicht versuchen, ihn künstlich zu erhalten oder Einschränkungen beizubehalten, die durch unsere frühere Arbeitsweise entstanden sind.

Wenn wir erkennen, dass der Tool-Stack, den wir über die Jahre mühsam zusammengestellt haben, uns erst dorthin gebracht hat, wo wir heute stehen, sollten wir ihn guten Gewissens verabschieden und zu DevOps übergehen können. Zu dieser Erkenntnis zu gelangen, ist schwierig – besonders in Unternehmen, deren Codebasen bereits erste Codezeilen hatten, bevor Unternehmen wie Uber oder Tesla überhaupt gegründet wurden.

Wir müssen all die Entscheidungen anerkennen, die damals richtig waren und uns in die Situation gebracht haben, in der wir heute stecken. Und wir müssen anerkennen, dass wir durch Veränderungen viel weiter kommen können.

Der Weg zu DevOps

Wenn ihr euch auf dem Weg zu Continuous Delivery und DevOps befindet und Sparring braucht oder gerade herausfinden wollt, wie ihr anfangen könnt, sprecht uns an. Wir haben viel Erfahrung darin, auf diesen Wegen ein wertvoller Begleiter zu sein.

Wenn ihr euch selbst oder einen eurer Kollegen in einer dieser Figuren wiedererkennt, teilt uns bitte euer Lieblingszitat von ihnen mit.

Wir wünschen euch viel Erfolg und beste psychische Gesundheit.

Alle Bilder in diesem Blogbeitrag stammen aus dem Film Alles steht Kopf. Copyright: ©2015 Disney/Pixar.