Kommentierte Links (XCVI)

Bild: Unsplash / Fabio Bracht - Lizenz

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.

Christopher Berry: What Is A Garbage Can Product Roadmap?

Zu den provokantesten Beschreibungen der Abläufe in Grossunternehmen gehört das Garbage Can Model von Cohen, March und Olsen, das davon ausgeht, dass alle Untereinheiten ununterbrochen und unabgestimmt Probleme und Lösungsansätze produzieren, die sie irgendwann unabgestimmt wieder aufgeben um sich neuen Themen zuzuwenden. Als Folge entstehen überall "Müllhaufen" von Problemen, potentiellen Lösungen und Entscheidungsbedarfen. Verstörenderweise beschreibt dieses Modell die Realität in vielen Unternehmen sehr gut. Christoper Berry versucht sich darauf aufbauend an einer weiterführenden Frage: wir kann in einer solchen Umgebung Planung stattfinden, und wie liessen sich derartige Planungen in einer Roadmap abbilden? Das Ergebnis ist eines das sich gut auf das Produktmanagement in (mehr oder weniger) agil arbeitenden Grossorganisationen übertragen lässt.

Aakash Gupta: The History of Product Management

Um es vorwegzunehmen - die Geschichte des Produktmanagements ist relativ kurz. Genau das ist auch der Ausgangspunkt von Aakash Guptas Überlegungen: seit wann gibt es dieses Tätigkeitsfeld überhaupt, und durch welche Entwicklungsstufen ist es gegangen um dort anzukommen wo es heute ist? Von den Anfängen bei Procter & Gamble und bei Hewlett Packard in den 30er und 40er Jahren bis hin zu den Produktmanagement-Ausbildungen der Gegenwart zeigt er auf, wie es nach und nach dazu gekommen ist, dass aus vorher über die ganze Organisation verteilten Verantwortlichkeiten der heutige Beruf geworden ist. Dabei macht er auch die Rolle deutlich, die die agilen Frameworks dabei gespielt haben, inbesondere Scrum, dessen Product Owner-Rolle eine der ersten gewesen ist, die das Wort Produkt bewusst als Namensbestandteil und Haupt-Tätigkeitsfeld hatte.

Johannes Klingebiel: The five Levels of Hype

Sowohl in der IT als auch in der agilen Community sind Hypes durchaus verbreitet, sei es in Form der neuesten Programmiersprache, des neuesten Methoden-Frameworks oder sonstiger Moden. Bei genauerer Betrachtung wird der Begriff des Hype aber eher undifferenziert gebraucht, oft mit der ungefähren (und uneingestandenen) Bedeutung "etwas Neues, das ich nicht mag". Johannes Klingebiel versucht Struktur in das Ganze zu bringen, indem er fünf Stufen definiert, über die sich Hypes immer stärker von der Realität entkoppeln können: Werbe-Botschaften, überzogene Erwartungen, utopische Verheissungen, magisches Denken und Sektenhaftigkeit (hier als handliches Übersichts-PDF herunterladbar). Legt man diese Skala neben die verbreiteten Entwickler- und Agile-Hypes lässt sich zum Glück feststellen, dass die sich alle noch auf den unteren Stufen befinden.

Luca Minudel, Michael Kelley Harris: Transcending the CapEx – OpEx dichotomy

Dass Anwendungsentwicklung und Anwendungsbetrieb unterschiedliche Aufgaben sind, die unterschiedliche Tätigkeiten erfordern, dürfte jedem klar sein, der schon einmal im IT-Umfeld gearbeitet hat. Weniger bekannt ist, dass in vielen Firmen diese Aufgaben auch unterschiedliche Budget-Posten haben: CapEx (Capital Expenditure) für Anwendungsentwicklung und OpEx (Operating Expenses) für den Betrieb. Dass diese Trennung in Zeiten von DevOps und kontinuierlicher Weiterentwicklung nicht mehr sinnvoll ist belegen Luca Minudel und Michael Kelley Harris anhand von nachvollziehbaren Beispielen (um ein banales zu nennen: ein Bugfix der die Funktionalität verändert). Sich mit den von ihnen gemachten Gedanken zu beschäftigen kann man jedem der in grossen Organisationen agil arbeiten will nur empfehlen, wenn er nicht riskieren will, dass er irgendwann sinnvolle oder notwendige Dinge wegen aufgebrauchten Einzelbudgets nicht mehr machen darf.

Bryan Finster: Scaled Agile DevOps Maturity Framework

Wenn ich es richtig überblicke ist das hier ein Aprilscherz gewesen, und zwar ein durchaus gelungener. Viele Scrum Master und Agile Coaches denen ich Bryan Finsters Scaled Agile DevOps Maturity Framework (abgekürzt SAD MF) vorgestellt habe waren sich zuerst unsicher - ist das hier ernst gemeint oder ist das ein Witz? Dass es überhaupt zu derartigen Unsicherheiten kommen kann zeigt deutlich auf, wie nahe an der Selbst-Persiflage die bekannten agilen Skalierungsframeworks (v.a. SAFe) mit ihrem Slang-Begriffen, ihren Erfolgsversprechen und ihren kaum getarnten Wasserfall- und Command & Control-Elementen mittlerweile sind. Für alle denen die so verpackte Kritik noch nicht beissend genug ist gibt es nebenbei noch einen Seitenhieb auf den Agil-Industriellen Komplex: wem es nicht ausreicht zertifizierter SAD Practitioner oder SAD Fellow zu werden, der kann selbst in den Zertifizierungsverkauf einsteigen - als Scaled Agile Dev Ops Accredited Facilitator, oder SAD AF.¹

Beyang Liu: A dev's thoughts on developer productivity

Wenn es um die Bedingungen geht in denen Software-Entwickler produktiv arbeiten können wird in vielen Firmen über die Entwickler gesprochen, selten mit ihnen und fast nie geht die Unterhaltung von ihnen aus. Beyang Liu versucht dagegenzuhalten indem er aus seiner Perspektive (er ist Software-Entwickler) zusammenfasst was ihn produktiv macht und was nicht. Zu den Themen die er dabei behandelt gehören die Einbettung seines persönlichen Arbeitsrhythmus in die Iterations-Zyklen, unterbrechungsfreie Konzentrationsphasen, Kontextwechsel und Klarheit über Standards und Ziele. Darüber hinaus zeigt er auf, dass Team-Produktivität mehr ist als die Summe der Produktivität aller Entwickler, da diese sich ergänzen und unterstützen können. Zuletzt äussert er eine Erkenntnis die man sich auch bei manchem anderen wünschen würde: wenn die Entwickler nicht selbst ihre Produktivität thematisieren wird es jemand anders tun - oft indem er über sie redet statt mit ihnen.

Oleg Mykolaichenko: Engineering Management During Wartime

IT-Anwendungen auf eine Produktions-Umgebung zu bringen und dort zu betreiben ist in westlichen Ländern vor allem eine Frage funktionierender Software und funktionierender Prozesse. Dass auch ganz andere, extreme Herausforderungen dazukommen können zeigt diese Zusammenfassung eines Vortrags von Oleg Mykolaichenko auf den unkrainischen DevOps Day 2022. Business Continuity Planning, Incident Management und Disaster Recovery bekamen in seiner Firma eine ganz andere Bedeutung als sie plötzlich in einem Krieg stattfinden mussten, durchgeführt von Menschen in der von Russland angegriffenen Stadt Kiew. Zu den verstörendsten Elementen gehören Bots die regelmässig überprüfen ob die Mitarbeiter am Leben und unverletzt sind und Vorkehrungen die explizit darauf ausgerichtet sind nicht nur den Ausfall von Infrastrukturen sondern auch den Tod von Managern zu kompensieren. Eine sowohl faszinierende als auch beängstigende Fallstudie.

Charity Majors: The Hierarchy Is Bullshit (And Bad For Business)

Charity Majors hat es richtig erkannt: die eigentliche Funktion von Hierarchien ist es, Informationsflüsse und Zusammenhänge vereinfacht darzustellen, um dadurch in der Lage zu sein grosse Vorhaben zu planen und umzusetzen. Sobald hierarchische Positionen aber mit mehr Gehalt, mehr Prestige oder anderen Belohnungen aufgeladen werden, wird es dazu kommen, dass sie aus den falschen Gründen angestrebt werden. Ihr Artikel ist eine bemerkenswerte Mischung aus Analyse, Rant und Inspiration zum besser machen, letzteres mit der interessanten Idee von "formal power as a service function", einer neuen Dimension von Servant Leadership.


¹Für alle die gerade rätseln: hinter Sad MF und Sad AF verbergen sich in der US-amerikanischen Umgangssprache wüste Beschimpfungen