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

Folge 44: Teamwork makes the dream work

Wir haben Rolf Katzenberger zu Gast und sprechen über das Thema Teams. Als Einstieg dazu nutzen wir das Tuckman Phasenmodell der Teamentwicklung und gehen auf die einzelnen Phasen ein. Wir klären, ob es überhaupt Phasen sind, die quasi zwangsläufig aufeinander folgen (müssen) oder ob es nicht vielmehr bestimmte Zustände sind („Stages“ versus „States“). Wir diskutieren alternative Ansätze wie Host Leadership oder New Authority und wir klären, was ein Maulwurfshügel mit Coaching zu tun hat.

Shownotes:

Webseite „Richtig ist, was funktioniert.“

Webseite „Focus on People, Spaces, Time. Workshop Facilitation Reduced to the Max.“