DevOps ist keine IT-Philosophie, es ist eine Unternehmensphilosophie

„Unsere IT-Organisation führt jetzt DevOps ein“: famous last words. DevOps kommt aus der IT-Ecke, benutzt IT-Begriffe und -Denkweisen. Es ist also naheliegend, es als ein IT-Thema anzusehen.

Zugleich ist diese enge Auslegung eines der heikelsten Themen, die uns in unserer Arbeit regelmäßig begegnet.

Sei es in Schulungen oder in er begleitenden Beratung, die größten Schwierigkeiten zeigen sich erstaunlicherweise nicht in jenen Organisationsteilen, in denen DevOps eingeführt wird. Sondern an den Nahtstellen, wo die agile, DevOps einsetzende Organisation auf jene Unternehmensteile trifft, die sich eben nicht (oder noch nicht) umgestellt haben; seien es benachbarte Entwicklungsorganisation, das Controlling, die Unternehmensleitung, die Personalverwaltung oder gar der Kunde.

In einer Umfrage, die wir unter etlichen hundert IT-Verantwortlichen durchgeführt haben, zeigte sich das gleiche Bild: die größte Überraschung, so teilten viele mit, waren die Spannungen, die sich plötzlich außerhalb der IT auftaten.

Das ist ein derart überraschendes Resultat, daß ich es nochmal wiederholen möchte: die größten Schwierigkeiten mit einer DevOps-Transformation zeigen sich oft gar nicht innerhalb der IT-Organisation, sondern außerhalb davon.

Das klingt vielleicht wie eine schlechte Nachricht, aber eigentlich ist es ein gutes Zeichen: DevOps wirkt! Es führt zu so tiefgreifenden Änderungen darin, wie die IT-Organisation nach außen wirkt, daß andere Bereiche nicht einfach bei der Tagesordnung bleiben können. Sie müssen sich mit diesem Wandel auseinadersetzen: ein hervorragendes Zeichen dafür, wie groß der Unterschied tatsächlich ist.

Ob das nun heißt, daß Euner Controlling nun ein DevOps-Controlling werden muß, ist vielleicht die falsche Frage. Das Wichtige ist, daß Organisation und Prozesse zu den Veränderungen innerhalb der DevOps-Organisation passen.

Wenn auf der einen Seite die Budgetprozesse weiterhin davon ausgehen, zwei-Jahres-Pläne zu verfassen und diese dann systematisch abzuarbeiten, während auf der anderen Seite eine agile Organisation selbstbewußt darauf pocht, den maximalen Kundennutzen erst unterwegs zu erkennen und ihm Rechnung zu tragen — na dann muß es ja in Streit enden, unabhängig davon, wer überhaupt Recht hat!

DevOps demaskiert technische Schulden

Eins der großen Themen von DevOps ist Sichtbarkeit: Sichtbarmachen vorn Arbeit, von Zusammenhängen, von Abläufen.

Das ist sicherlich eine gute Sache, kann aber manchmal einen, sagen wir, beunruhigenden Nebeneffekt haben: DevOps Einführungen machen eben auch Dinge sichtbar, die nicht so schön anzuschauen sind.

Das mag verschiedenste Ebenen betreffen: von verbreiteten Schwächen der Unternehmenskultur bis hin zu unsauberem Handwerk einzelner Entwickler.

Konkret ist mir eine Situation in Erinnerung, in der ein Unternehmen continuous integration einführen wollte. An sich keine allzu große Sache, sollte man meinen. Sicherlich muß man etwas Energie hineinstecken, bis alles rund läuft, aber im Regelfall ist diese Umsetzung eher überschaubar.

Nicht so in einem bestimmten Team: dessen Produkt widersetzte sich standhaft allen Versuchen, die builds zu automatisieren.

Zug um Zug stellte sich nämlich heraus, daß sehr viele implizite Annahmen getroffen wurden: über die Art, builds anzustoßen; über Pfade, Nutzer und Rechte; über die Art, wie Parameter übermittelt wurden (auf der Kommandozeile, in Umgebungsvariablen oder in Dateien). Und nicht nur, daß diese Annahmen implizit waren und nun den Automationsentwicklern ohne Vorwarnung um die Ohren flogen, sondern jeder Entwickler hatte seine eigenen Vorlieben (…die sich bei manchen auch noch über die Zeit änderten).

Bald setzte ein allgemeines Grummeln über DevOps im Allgemeinen und Automation im Speziellen ein: kostet wohl doch mehr als von Automationsverfechtern gern angegeben!

Aber die Kosten entstanden natürlich im Wesentlichen nicht aus den Mühen der Build-Automation: sondern daraus, daß nun die technischen Schulden wieder beglichen wurden, die sich über einenm langen Zeitraum aufgebaut hatten.

(Ich weiß übrigens nicht, wie’s in dieser Geschichte ausgegangen ist — ich schied bald darauf aus dem Projekt aus).

Diese Geschichte ist insofern sehr erzählenswert, als sie einem oft beobachteten Muster folgt: die agilen / DevOpslichen Ansätze führen zu mehr Sichtbarkeit — und nicht alles, was man zu sehen bekommt, gefällt einem auch.

Die technischen Schulden waren natürlich schon vorher da, aber jetzt sind sie sichtbar, fühlbar, und müssen behandelt werden.

Vermutlich bringt jegliche Transformation solche Effekte mit sich, aber Agile mit seinem Fokus auf klare Konturen ist da vielleicht besonders… intensiv; im Guten wie im Schlechten.

Folge 52: DevOps in Small Companies with Jonathan Hall [EN]

In this episode our guest is Jonathan Hall of Tiny DevOps. We invited him because he specialises in a very interesting and little-talked-about niche: DevOps for small companies.

DevOps is usually viewed in the context of large organisations. But what does DevOps look like in small organisations? Does DevOps make sense in this context? Is it even feasible?

Shownotes:

Find Jonathan at: https://jhall.io
He writes daily posts at: https://jhall.io/daily/

Folge 49: Gesetze der Zusammenarbeit

Wir haben in dieser Folge Heiko Bartlog zu Gast. Wir sprechen über seinen Blog mit der Liste zum Thema „Die Gesetze der Zusammenarbeit“. Heiko hat eine tolle Sammlung an bekannten und weniger bekannten Gesetzmäßigkeiten zusammengestellt, die Phänomene in der Organisation und Zusammenarbeit beschreiben. In unserem Podcast haben wir bereits Conways Law und auch das Phasenmodell von Tuckman behandelt. Hier folgt nun eine lockere Besprechung weiterer „Gesetze“ wie die von Parkinson und von Hofstadter. Weitere Themen sind der Ringelmann-Effekt, das soziale Faulenzen und die 85/15-Regel von Deming. Interessant sind auch der Sleeper- und Dr. Michael.J. Fox-Effekt.

Shownotes:

[https://bartlog.de/blog/gesetze-zusammenarbeit]
(Blog: Gesetze der Zusammenarbeit)

Folge 48: DevOps und OKR

In dieser Folge haben wir André Claassen zu Gast. Wir sprechen über OKR (Objectives & Key Results) und die Verbindung zu DevOps. Was sind OKRs und wie kann man sie im DevOps-Umfeld nutzen. Sind OKRs nur etwas für größere Unternehmen oder kann man sie auch in kleineren Organisationen oder sogar Start-Ups nutzen? Wofür werden OKRs überhaupt eingesetzt?

Shownotes:

Buchempfehlung: Outcome over Output von Josh Seiden
Präsentation Roadmaps are Dead
Podcast Ziele setzen, Ziele erreichen mit OKR
Webseite von André Claassen

Folge 47: DevOps in Embedded Software [EN]

In this episode we’re joined by medical devices specialist Jeff Gable, whose mission it is to „drag embedded development kicking and screaming into the 21st century“.

He tells us about the specific issues when applying DevOps principles to embedded systems, from the technical to the cultural.

Shownotes:

Jeff’s Website

Folge 46: gridscales Weg zu Team Topologies

Eine weitere Folge zum Thema Team Topologies. Wir haben Felix Kronlage-Dammers zu Gast. Mit ihm sprechen wir über seine Sicht auf das Buch Team Topologies und wie er das in seiner Praxis als COO bei gridscale anwenden konnte. Er skizziert unter anderem seine Herausforderungen und wie er die Ideen und Konzepte aus Team Topologies nutzen konnte, um einen verteilten Monolithen zu beherrschen. Natürlich beschreibt Felix auch, wie DevOps bei gridscale technisch und organisatorisch gestaltet ist. Er erzählt, was Winston Wolf aus Pulp Fiction mit gridscale und was Spotify mit Team Topologies zu tun hat. Zum Schluss erklären wir die Verbindung von Felix und Luca zu Dierks DevOps Mastermind Klub!

Shownotes:

Blogpost – Phoenix Project Online
Buch Empfehlung – An Elegant Puzzle: Systems of Engineering Management
Felix Blog
Felix bei Twitter
gridscale
DevOps Mastermind Klub

Folge 45: Serverless mit Paul Swail [EN]

Our guest today is Paul Swail, an expert on serverless architectures. We discussed the architectural and organisational aspects of serverless:

• what serverless is
• why serverless is the future
• how it provides value to both users and development teams
• which tasks it’s suited or unsuited for
• how to get started with serverless

Shownotes:

Serverless Framework: https://serverless.com

Paul’s Twitter: https://twitter.com/paulswail

Paul’s website and free 5-part email course: https://serverlessfirst.com