Dienstag, 14. Oktober 2025

Flooding the Zone (II)

Bild: Wikimedia Commons / Katsushika Hokusai - Public Domain

Noch einmal einige Gedanken zum Flooding the Zone, also zu einem derartigen Überladen einer Diskussion mit Themen, dass es nicht mehr möglich ist, sich auf eines davon zu konzentrieren um es auszudiskutieren oder zu einer Massnahme oder Lösung zu kommen. In sehr vielen Fällen ist dieses Phänomen ein Ausdruck einer destuktiven Einstellung, es gibt aber auch Fälle, in denen es stattfindet ohne dass eine negative Absicht dahintersteht.


Eine häufige Ursache dafür ist, dass ein Gesprächsteilnehmer seit langem keine Möglichkeit mehr gehabt hat, seine Einwände oder Bedenken vorzubringen (weil das von anderen unterbunden wurde, weil er nicht in die dafür geeigneten Termine eingeladen wurde, weil er erst seine Introvertiertheit überwinden musste - es kann viele Gründe dafür geben). Ihn dann darum zu bitten kann einen Dammbruch zur Folge haben, der erstmal alles an die Oberfläche bringt was sich aufgestaut hat. 


Eine anderer Grund kann sein, dass der Gesprächsteilnehmer die Erfahrung gemacht hat, dass er im Durchschnitt nur ein- oder zweimal pro Meeting zu Wort kommt, z.B. weil die strukturell mit Themen überladen sind oder mit zu vielen Teilnehmern stattfinden. In derartigen Fällen hat er einen starken Anreiz, sofort alles vorzubringen, was irgendwann im Gespräch wichtig werden könnte, da er nicht sicher sein kann, ein zweites mal die Gelegenheit dazu zu haben.


Eine dritte mögliche Ursache ist, dass durch solche Momente Probleme der Unternehmenskultur sichtbar werden. Wenn z.B. dem ersten, der ein konfliktlastiges Thema anspricht, sein Standpunkt am meisten geglaubt wird, dann kann das einen Wettlauf zum Mikrofon mit anschliessendem thematischem Rundumschlag zur Folge haben. Das ist im übrigen auch dann das Ergebnis, wenn dieses Kulturproblem gar nicht existiert, es aber irrigerweise unterstellt wird.


Abhängig davon, welche dieser Konstellationen gegeben ist (was sich allerdings nicht immer einfach herausfinden lässt) sind verschiedene Herangehensweisen sinnvoll, um das Flooding the Zone in den Griff zu bekommen. Sinnvoll ist in jedem Fall eine vorher gemeinsam Agenda, bei der den einzelnen Themen realistische Zeiträume zugeordnet sind (womit auch klar ist, worüber nicht geredet wird). Mit Berufung darauf lassen sich zeitlich oder inhaltlich ausufernde Beiträge einfacher abmoderieren.


Ebenfalls hilfreich ist es, wegmoderierte Themen öffentlich sichtbar zu "parken", z.B. auf einer Wand mit entsprechend beschrifteten Post Its oder Moderationskarten. Dadurch wird denjenigen, die sie eingebracht haben, die Sorge genommen, dass sie unter den Tisch fallen könnten. Ggf. kann am Ende des Termins sogar schon festgelegt werden, wann diese Themen stattdessen behandelt werden, auch in welchem Umfang und mit welcher Reihenfolge.


Das meiste Fingerspitzengefühl ist nötig, wenn das Flooding the Zone auf eine problematische Unternehmenskultur zurückgeht. Ein einigermassen erfolgsversprechendes Mittel in derartigen Fällen ist es, die nicht in der Agenda vorgesehenen Debatten konsequent aus der Ergebnis-Dokumentation herauszuhalten, wodurch ein derartiges Verhalten seinen Mehrwert verliert. Um so wichtiger ist in solchen Fällen der Verweis auf einen späteren Zeitpunkt für die Besprechung.


Erfahrungsgemäss kann diese Art, mit zeitlich und inhaltlich ausufernden Wortbeiträgen umzugehen, nach und nach zu einer Verbesserung führen, selbst wenn es zu Beginn eine Zeit lang zu Unzufriedenheit und Widerspruch kommt. Man muss sich dabei aber bewusst machen, dass ein derartiges Verhalten in der Regel über eine längere Zeit entstanden ist, und es dadurch auch entsprechend dauern kann, bis es wieder verschwunden ist.

Freitag, 10. Oktober 2025

Ein Bild sagt mehr als 1000 Worte (LII)

Grafik:Forrest Brazeal - CC BY-NC-ND 4.0

Montag, 6. Oktober 2025

Tech Debts VS More Features

Nachdem ich dieses Video in den letzten Monaten immer wieder zugeschickt bekommen habe, ist es höchste Zeit, es auch hier einzubinden. Keine Ahnung ob KI-generiert oder nicht, den Urhebern ist damit ein kleines Kunstwerk gelungen.



Und falls der Inhalt irgendjemandem zu weit hergeholt vorkommen sollte - es lohnt sich, das Video jemandem zu zeigen, der in einer grossen IT-Organisation arbeitet. Mit grosser Wahrscheinlichkeit wird er sagen, dass ihm das Ganze sehr bekannt vorkommt.

Freitag, 3. Oktober 2025

Prescott's Pickle Principle

Bild: CCnull /  Tim Reckmann - CC BY 2.0

Nachdem es hier schon länger keine Besprechung eines "Management-Gesetzes" mehr gab, ist hier ein besonders schönes: Prescott's Pickle Principle, geprägt 1985 vom Informatiker und Unternehmensberater Gerald M. Weinberg in seinem Buch The Secrets of Consulting, in dem er zahreiche derartiger halb ernstgemeinter Gesetzmässigkeiten gesammelt und z.T. mit selbst erfundenen Ursprungsgeschichten versehen hat. Ein derartiges, nach dem fiktiven Lebensmittelhändler Prescott benanntes Gesetz lautet:


Cucumbers get more pickled than brine gets cucumbered.
Gerald M. Weinberg: The Secrets of Consulting; S. 72


Die zugrundeliegende Idee ist gewissermassen aus der Mengenlehre abgeleitet: die Flüssigkeit in einer Gurke (Cucumber) ist so viel weniger als die im umgebenden Essigglas, dass im Endprodukt der Essiggurke vor allem der Geschmack von Essig (Brine) übrigbleibt, und nur wenig Gurkengeschmack. Dieses Phänomen übertrug Weinberg als ein plastisches Bild auf die Tätigkeit, mit der er beruflich grossteils beschäftigt war - das Change Management.

 

Übertragen auf Veränderungsprozesse beschrieb er damit das häufige Phänomen, dass Personen, die in eine Organisation geholt werden um neue Impulse einzubringen, sich nach und nach durch Kompromisse, Sachzwänge, Unternehmenspolitik und andere Faktoren an den ursprünglich vorherrschenden Zustand anpassen, bis sie irgendwann zu einem Teil von ihm geworden sind und aufgrunddessen keine Veränderungsimpulse mehr setzen können. Sachlicher ausgedrückt:


A small system that tries to change a big system through long and continued contact is more likely to be changed itself
Gerald M. Weinberg: The Secrets of Consulting; S. 73


Diese Betrachtungsweise mag zunächst pessimistisch oder sogar defätistisch wirken, da man sie so verstehen kann, dass am Ende alle Veränderungsvorhaben zum Scheitern verurteilt sind. Das allerdings würde weit an Weinbergs Interntion vorbeigehen, der genau die gegenteilige Aussage treffen wollte: Veränderungen sind möglich, allerdings nur dann, wenn man sich der Mechanismen von Prescott's Pickle Principle bewusst ist und ihnen entgegenwirkt.

 

Die Analogie der Gurke im Essigwasser wurde in The Secrets of Consulting nämlich noch weiter getrieben - genau wie die harte Schale einer Gurke eine Zeit lang das Eindringen des Essigs verhindert, kann ein Change Agent (oder wie auch immer das auf deutsch heisst) sich eine Zeit lang dagegen wehren, von dem ihn umgebenden sozialen System assimiliert zu werden. In dieser Zeit kann er Wirkung entfalten, er sollte aber in der Lage sein zu erkennen, ab wann das nicht mehr der Fall ist und dann wieder gehen.

 

Wie alles an derartigen "Gesetzmässigkeiten" ist auch dieser Schluss mit Vorsicht zu betrachten und sollte vor allem im Kontext von Weinbergs Einsätzen in grossen, veränderungs-aversen Organisationen gesehen werden. In diesem Rahmen hat er aber eine gewisse Gültigkeit und erklärt damit auch, warum viele Konzerne, Behörden und sonstige Grossorganisationen in einem Zustand der "Dauerberatung" befinden, und ständig neue Unternehmensberater beauftragen, ohne dass das irgendwann ein Ende findet.

 

 Die Pointe in Weinbergs Buch besteht übrigens daraus, dass der Lebensmittelhändler Prescott den Verkauf von Essiggurken so stark verinnerlicht hatte, dass er in seinem nächsten Geschäft, einem italienischen Restaurant, die Pizza damit belegte. Damit entspricht er dem Antipattern eines Change Agents, der nicht nur zum Teil des ursprünglichen Problems wurde, sondern das auch noch als scheinbare Lösung weiterverbreitete. Eine Mahnung, wie man im schlimmsten Fall selbst enden könnte.

Dienstag, 30. September 2025

Kommentierte Links (CXXXI)

Grafik: Pixabay / Brian Penny - Lizenz
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Gregor Hohpe: Transformation Gremlins

Um einem Missverständnis vorzubeugen: die "Transformation Gremlins", über die Gregor Hohpe hier schreibt, sind nicht etwa Verwandte der Konzern-Trolle, sondern beziehen sich auf das in den 70ern gebaute Auto AMC Gremlin, aus dem Hohpe eine ganze Produkt(anti)kategorie ableitet - die der Produkte, die entstehen, wenn man versucht ein bestehendes Produkt halbherzig und mit möglichst wenig Aufwand an völlig andere Kundenbedürfnisse anzupassen.

Tim Ottinger: Why is working faster not working?

Ein neuer Take auf ein klassisches Thema: das der Arbeitsfluss-Optimierung, bzw. der negativen Folgen die entstehen wenn man nicht etwa die Engpässe beseitigt, sondern an anderen Stellen des Systems mehr Arbeit anordnet. Tim Ottingers wenig überraschende Erkenntnis: geschieht das vor einem Engpass entsteht Stau, geschieht das nach einem Engpass entsteht Leerlauf. Eigentlich Common Sense, aber in grossen Organisationen erstaunlich wenig verbreitet.

John Cutler: Vertical vs. Horizontal Org Coupling

Was bekommt man, wenn man das Ausmass der Steuerung eines Teams durch das Management mit den Abhängigkeiten zu anderen Teams ins Verhältnis setzt? Im Fall von Jahn Cutler eine Matrix aus vier Feldern, die jeweils eine bestimmte, häufig auftretende Ausprägung von Produkt- oder Feature-Teams beschreiben. Wichtig dabei ist, dass keines der Felder besser oder schlechter ist als das andere, es sind vielmehr Typen zwischen denen viele Teams mit der Zeit hin- und herwechseln können.

Kent Beck: Programming Deflation

Kent Beck gehört zu den wenigen Menschen, deren Artikel über den Einfluss von künstlicher Intelligenz auf den Beruf des Software-Entwicklers ich freiwillig lese. Ganz unabhängig von den sonst vorherrschenden Jubel- oder Untergangs-Szenarien beschreibt er einige der gerade stattfindenden Dynamiken - was gerade leichter verfügbar wird, was knapper wird und wie Entwickler sich angesichts dieser Entwicklungen positionieren sollten.

Jamil Zaki: Every Team Needs a Super Facilitator

Auf den ersten Blick ein typisch amerikanischer Management-Magazin-Artikel, voller Superlative und Heldengeschichten. Auf den zweiten Blick dagegen ein differenziert geschriebener Artikel über ein interessantes Phänomen. Unter Verweis auf die Arbeit verschiedener Forscher identifiziert Jamil Zaki die (inoffizielle) Rolle des "Super Facilitators" der sein Team dadurch stärkt, dass er so mit den anderen Mitgliedern interagiert, dass diese ihre jeweilen Stärken optimal einbringen können.

Donnerstag, 25. September 2025

BIC Limit

Zu den wichtigsten Kompetenzen eines Agile Coach, Scrum Master, Agile Consultant oder ähnlicher Rollen gehört es, die Idee agilen Arbeitens so zu erklären, dass sie auch von Menschen für gut befunden wird, die sich wenig mit dem Thema beschäftigt haben. Ein Patentrezept gibt es dafür natürlich nicht, aber einen Ansatz mit dem ich immer wieder sehr gute Erfahrungen gemacht habe: das Buzzwords in Conversation Limit, kurz BIC Limit.


Zur Erklärung: selbst für die Management-Sprache sind die agilen Frameworks mit sehr vielen so genannten Buzzwords überladen, also ungewöhnlich klingenden Begriffen oder Phrasen, die Sachverhalte kurz und prägnant wiedergeben sowie bei der Zielgruppe Interesse und Wiedererkennen hervorrufen sollen. Beispiele dafür sind Agil(e) und Framework selbst, aber auch leichtgewichtig, crossfunktional, iterativ-incrementell und viele weitere mehr. 


Das Problem von Buzzwords: um ihren prägnanten Charakter zu behalten, müssen sie zwangsläufig auf Details, Genauigkeit und Kontext und Klarheit verzichten. Das macht auch Sinn, kommt aber mit einem Preis - um sie im Sinn der ursprünglichen Intention voll zu verstehen, benötigt man entsprechendes Vorwissen. Hat man das nicht, klingen Buzzwords schnell wie leere Worthülsen, was eine im Umfeld agiler Frameworks durchaus häufige Aussenwahrnehmung ist.


Gleichzeitig können Buzzwords durch ihre minimalistische Natur sehr schnell zum Gegenstand von Interpretationen, Missverständnissen und Umdeutungen werden, ohne dass das zwangsläufig auffällt. Servant Leadership zum Beispiel kann auf derartig viele verschiedene Weisen verstanden werden, dass selbst innerhalb einzelner Unternehmen die Bedeutungen und Anwendungen so weit auseinanderlaufen, dass kaum noch Gemeinsamkeiten bestehen.


Beides, sowohl die (ohne Vorwissen scheinbar gegebene) Inhaltslosigkeit als auch die mitunter willkürlich und erratisch wirkenden Deutungen und Missverständnisse, tragen dazu bei, dass Buzzwords von vielen Menschen misstrauisch betrachtet oder sogar rundheraus abgelehnt werden. Und damit kommen wir zu einem Problem bei der Vermittlung agiler Arbeitsweisen - die Benutzung zu vieler Buzzwords kann hier eher schaden als helfen.


Das BIC Limit ist ein Weg um derartige negative Effekte zu begrenzen. Wenige Buzzwords, dafür aber auch weniger Misstrauen und weniger Ablehnung. Welche Begrenzungsmenge sinnvoll ist kann jeder für sich entscheiden, ich selber halte aber ein BIIC Limit von Eins für sinnvoll. Das heisst: Agil, Framework, leichtgewichtig, crossfunktional, iterativ-incrementell und ähnliche Begriffe benutze ich nach Möglichkeit in einem beruflichen Gespräch nur einmal.


Natürlich kann es dabei vorkommen, dass ein Konzept mehr als einmal thematisiert werden muss, allerdings ist das ab dem zweiten mal auch ohne Buzzword möglich. Agil bedeutet für mich zum Beispiel, in kurzen Zyklen Reaktions- und Lieferfähig zu sein. Das lässt sich auch genau so sagen, und es ist für die meisten Menschen auch sehr gut nachvollziehbar, was damit gemeint ist, und was nicht. Mein Erfahrungswert: Gespräche werden so besser.


Zuletzt noch eine kurze Meta-Betrachtung - ja, mir ist bewusst, dass ein BIC Limit ebenfalls ein Buzzword ist. Ironie der Geschichte.

Montag, 22. September 2025

Der 'agile Jobmarkt' als Teil des IT-Jobmarktes

Wer im Augenblick auf agilen Meetups oder Konferenzen unterwegs ist, findet die dort versammelten Scrum Master, Agile Coaches und Agile Consultants oft in einer pessimistischen Stimmung vor, wie man beispielhaft an der oben zu sehenden Session der letzten Agile Cologne sehen kann. Diese Stimmung ist erst einmal so wie sie ist, wie immer lohnt es sich aber auch hier, den Sachverhalt im grossen Kontext zu betrachten, da sich dann einiges relativiert.

 

Um mit der wichtigsten Differenzierung zu beginnen - wenn agile Methodiker darüber sprechen, dass "Agile tot ist", meinen sie in der Regel nicht, dass schnelle Reaktions- und Lieferfähigkeit in der Software-Industrie nicht mehr wichtig sind (in Krisen ist sogar das Gegenteil der Fall). Was sie meistens tatsächlich meinen ist, dass der "agile Jobmarkt", also der für Scrum Master, Agile Coaches/Consultants und ähnliche Rollen, zu verschwinden droht.1 Und selbst das ist so nicht ganz richtig.


Wenn man das (durchaus reale) Schrumpfen des agilen Jobmarkts betrachtet, sollte man sich zunächst bewusst machen, dass er trotz des Übergreifens agiler Vorgehensweisen in andere Bereiche im Wesentlichen noch immer ein Teil des IT-Jobmarktes ist, und der ist bedingt durch die Rezession als Ganzer in der Krise. Es ist für die Betroffenen zwar nur ein schwacher Trost, aber (agilen und nicht-agilen) Entwicklern, Testern, Architekten und IT-Managern geht es gerade auch nicht besser.

 

Aus dieser vergleichbaren Situation anderer IT-Berufe ergeben sich aber besondere Folgen für die agilen Methodiker. Eine davon, die fast immer übersehen wird: in Zeiten eines schwierigen Arbeitsmarktes sind die Entwicklungsteams tendenziell weniger rebellisch als zu Fachkräftemangel-Zeiten, in dem sie schnell andere Jobs hätten. Und wenn Widerstände gegen kurze Lieferzyklen, hohe Transparenz und häufige Kommunikation zurückgehen, dann bedeutet das auch, dass es weniger Bedarf für agile Coaching gibt.

 

Ebenfalls zu beachten ist, dass während wirtschaftlicher Krisen sparsam mit Budgets umgegangen wird. In Folge dessen werden weniger Projekte neu gestartet und weniger neue Mitarbeiter eingestellt, was wiederum erneute Auswirkungen auf den Bedarf nach agilen Methodikern hat - es gibt weniger Trainings, Schulungen und Teambuilding-Workshops die gehalten werden müssen, und es gibt weniger Teams die durch ihe Storming-Phase begleitet werden müssen.

 

Zuletzt gibt es in vielen Firmen die Tendenz, (vorrübergehend) Dysfunktionen in den Entwicklungsteams in Kauf zu nehmen, wenn sich dadurch Geld einsparen lässt. Eine typische Ausprägung dieses Phänomens ist es, Rollen ohne unmittelbare eigene Wertschöpfung zu streichen oder mehreren Teams gleichzeitig zuzuordnen. Das betrifft häufig Scrum Master und Agile Coaches/Consultants, aber z.B. auch UX Designer, Product Owner, Architekten und weitere "Meta-Rollen".

 

Um die zentrale Botschaft zu wiederholen: für viele agile Methodiker mag es sich zur Zeit anfühlen, als würde die "Nachfrage nach agilem Arbeiten" zurückgehen. Das ist aber eine Verwechselung, was zurückgeht ist lediglich die Anzahl der Scrum Master-, Agile Coach- und Agile Consultant-Jobs. Und selbst die verschwinden auch nicht wesentlich stärker als der Branchenschnitt, bzw. ähnlich abstrakte Stabs- Koordinations- und Management-Jobs.

 

Was im Umkehrschluss angenommen werden kann: sobald die Wirtschaft wieder anzieht, neue Vorhaben gestartet und neue Mitarbeiter eingestellt werden, wird das auch zu einer Verbesserung auf dem "agilen Jobmarkt" führen, sei es weil der Fachkräftemangel wieder zu rebellischeren Teams führt, weil es wieder mehr zu begleitende Storming-Phasen gibt oder weil wieder eigesehen wird, dass es Sinn macht, jemanden zu haben, der regelmässig aus dem Hamsterrad heraustreten kann.



1Diese etwas unglückliche Gleichsetzung ist dann nochmal ein problematisches Thema für sich selbst

Donnerstag, 18. September 2025

DevOps is for Product Engineers, too

Ich gestehe, als Lesley Cordero ihren Vortrag damit begann, dass sie soziotechnische Systeme auf ihre einzelnen Teile herunterbrechen möchte, war ich schon angetan. Und als sich herausstellte, dass sie dabei über die Dichotomie von Produktentwicklung und Platform Engineering spricht, war ich überzeugt, dass es sich lohnt, bis zum Ende dabeizubleiben.



Inhaltlich geht es um eine Vielzahl von Aspekten, vom Organisationsaufbau über Architektur-Paradigmen und Führungsstile bis hin zu autonomen Teams und robustem Systemdesign. Ein guter Rundumschlag, in dem auch ganz nebenbei der Unterschied zwischen Platform Engineering und DevOps erklärt wird.

Dienstag, 16. September 2025

Fast- and slow-thinking Teams

Heute gibt es einmal mehr ein Praxisbeispiel, diesesmal von Airtable, einem KI Startup aus dem Silicon Valley. Wie alle Startups muss auch dieses hier agil im eigentlichen Sinn sein, also in der Lage, schnell auf sich ändernde Kundenwünsche und Marktbedingungen zu reagieren. Anders als man denken könnte sind dort aber nicht alle Teams mit dem Ziel einer schnellen Reaktionsfähigkeit aufgesetzt, wie Firmengründer Howie Liu in Lenny's Podcast erklärt.


Es gibt bei Airtable zwei verschiedene Arten von Teams, deren jeweiliges Organisationsmodell an die zwei Arten des Denkens aus Daniel Kahnemans Bestseller Thinking, Fast and Slow angelehnt ist - auf der einen Seite die Fast-thinking Teams, die schnell, proaktiv, intuitiv und experimentgetrieben vorgehen sollen und auf der anderen Seite die Slow-thinking Teams, die abwägend, analytisch, strukturiert und sorgfältig arbeiten.


Wichtig für das Verständnis dieses Ansatzes ist, dass keine der beiden Team-Kategorien grundsätzlich besser oder schlechter ist als die jeweils andere (weder Kahnemann noch Liu sehen in dem Konzept des "langsamen Denkens" etwas Negatives), beide haben in ihrem jeweiligen Kontext ihre Vorzüge. Und diese unterschiedlichen Kontexte (und die Zuordnung der Kategorien zu ihnen) sind es auch, die die Idee der Fast- and slow-thinking Teams so interessant machen.


Fast-thinking Teams werden dort eingesetzt, wo neue Features und Produkte entwickelt werden, was besonders auf dem Markt für KI-Produkte hochgradig anspruchsvoll ist. Ein geradezu rasender technischer Fortschritt, ständige Innovationen, starker Wettbewerb und volatile Kundenbedürfnisse machen schnelles Agieren und Reagieren nötig, weshalb in diesem Bereich eine iterativ-incrementelle Auslieferung von Features im Wochenrhythmus vorgesehen ist.


Slow-thinking Teams sind dagegen dort angesiedelt, wo die Infrastruktur entwickelt wird, die die Basis dafür bildet, dass die von den Fast-thinking Teams entwickelten Features von einer rapide wachsenden Nutzerbasis in hoher Frequenz genutzt werden können. Hier stehen eher Verlässlichkeit, Skalierbarkeit, Resilienz und Berechenbarkeit im Focus, wodurch die Entwicklungsschritte hier deutlich langsamer, dafür aber mit grösserer Sorgfalt und Planung erfolgen.


Dieses bewusste gleichzeitige Aufsetzen von zwei verschiedenen und komplementären Vorgehensmodellen ist in modernen Tech-Unternehmen eher selten, viel häufiger wird versucht, alles nach einem gleichen Muster zu organisieren, dass dann im Einzelfall unpassend ist. Der Denkanstoss, den sich viele mitnehmen können, ist, dass Uneinheitlichkeit durchaus Sinn machen kann. Die kann dann in Form von Fast- and Slow-thinking Teams auftreten, ggf. aber auch ganz anders.

Donnerstag, 11. September 2025

Ein Bild sagt mehr als 1000 Worte (LI)

 

Montag, 8. September 2025

The Cult of the agile Amateur (II)

Kommen wir noch einmal zurück zum Cult of the agile Amateur, also zu dem Phänomen, dass ein Grossteil der Agile Coaches, Scrum Master und Agile Consultants nur eine eher schmale Datenbasis zur Untermauerung ihrer Konzepte vorweisen kann und stattdessen sein Vorgehen vor allem auf Buchwissen, starke Meinungen (eigene und andere), subjektive Erfahrungen, unvalidierte Hypothesen, anekdotische Evidenz und ähnliche nicht-empirische Ansätze aufbaut.


Dieser Zustand hat sich mittlerweile in grossen Teilen verflüchtigt oder wenigstens abgeschwächt, da zumindest die grossen agilen Frameworks (Scrum, Kanban und SAFe) mittlerweile auf eine Anwendungsdauer von mehreren Jahrzehnten und eine Anwenderbasis von tausenden verschiedener Organisationen zurückblicken können, die auch in zahllosen Studien, Konferenzvorträgen, Fachartikeln und Erfahrungsberichten dokumentiert wurden.


Unabhängig davon gibt es aber weiterhin ein Phänomen, auf das der Name des Cult of the agile Amateur zutreffend ist: die Überzeugung, dass man den Job des Scrum Masters, Agile Coaches oder Agile Consultant nicht nur ohne technisches, fachliches und betriebswissenschaftliches Vorwissen ergreifen kann, sondern dass es auch dauerhaft unbedenklich möglich ist (oder sogar erstrebenswert ist), ihn ohne derartige Kenntnisse auszuüben.


Egal ob auf Konferenzen, auf Meetups oder in den Unternehmen selbst - regelmässig kann man hier agilen Methodikern begegnen, die nicht nur offen gestehen, die genannten Wissensgebiete nicht einmal in Ansätzen durchdrungen zu haben, sondern die es sogar als für ihre Berufsausübung als förderlich ansehen, diesen Zustand beizubehalten, um sich ausschliesslich auf die menschlichen und zwischenmenschlichen Aspekte ihrer Arbeit konzentrieren zu können.


Das mag zwar auf den ersten Blick irgendwie rational wirken, schliesslich gibt es für diese Wissensgebiete bereits Spezialisten, deren Berufs sich explizit um diese dreht. Was aber bei einer solchen Betrachtung vergessen wird, ist, dass technische, fachliche und betriebswissenschaftliche Aspekte sich in einem agilen Arbeitsmodus ändern müssen, und dass das jemandem in einem eher traditionellen Arbeitsmodus sozialisiert wurde nicht immer von alleine klar wird.


Egal ob es sich um continuous Integration, modulare Architektur, outcome-orientierte Anforderungen, Minimum Viable Products oder incrementelle Auslieferung handelt - im Vergleich zu klassischen Prozessen sind diese Ideen so anders und ungewohnt, dass oft grössere Erklär- und Überzeugungsarbeiten zu leisten sind, bevor sich darauf eingelassen wird. Und um diese leisten zu können, braucht es zumindest ein Grundverständnis in diesen Bereichen.


Das heisst natürlich nicht, dass man das alles von Beginn an können muss. Es heisst aber, das man bereit sein muss, sich in diese Wissensgebiete einzuarbeiten und sie sich anzueignen. Und die Bereitschaft dazu sinkt, wenn einem von den Anhängern des Cult of the agile Amateur eingeredet wird, dass das unnötig oder sogar nicht zielführend wäre. Wer daher auf Konferenzen, Meetups oder in Unternehmen derartige Aussagen hört, tut sich und Anderen einen Gefallen, wenn er ihnen wiederspricht.

Donnerstag, 4. September 2025

Agile Bang for the Buck

Bild: Unsplash / Ibrahim Boran - Lizenz

Reden wir über Geld. Genauer gesagt, reden wir über das Geld, das eine eine Firma ihren Agile Coaches, Scrum Mastern und sonstigen agilen Methodenmenschen bezahlt, und reden wir über den Gegenwert, den die Organisation dafür zurückbekommt. Denn eines sollte eigentlich allen klar sein - nur wenn der Gegenwert dem Wert der Gehälter entspricht oder ihn übertrifft, werden diese Rollen langfristig in einem Unternehmen bestehen bleiben.


Relativ einfach ist es bei dem ersten Teil: abhängig von verschiedenen Faktoren1 ermitteln Portale wie Stepstone oder Kununu Gehälter, die irgendwo zwischen 50.000 € und 80.000 € liegen. Zu denen kommen allerdings noch die freiberuflichen Agile Coaches und Scrum Master, deren Tagessätze meistens zwischen 500 € und 800 € liegen, was sich bei 200 Tagen pro Jahr auf 100.000 € bis 160.000 € addiert und den Kosten-Durchschnitt entsprechend hebt.2


Insgesamt liegen dieser Durchschnitt vermutlich sogar noch höher. In grossen Konzernen, in denen es oft eine regelmässige de facto-Beförderungsgarantie gibt, können Scrum Master & Co mit der Zeit Gehälter von 150.000 und mehr erreichen, was sich wegen der meist dauerhaften Betriebszugehörigkeit aber kaum in den oben genannten Recruiting- und Ehemaligen-Portalen wiederspiegelt, wodurch deren Durchschnittswerte zu niedrig sein dürften.


Schwieriger wird es bei der Ermittlung des Gegenwerts, den eine Organisation für die Schaffung eigener agiler Methodenrollen zurückbekommt. Potentiell ist dieser immens, schliesslich können höhere Effizienz und Effektivität, weniger Bürokratie und Verschwendung und besserer Product Market-Fit schon bei kleinen Teams in sechs- oder manchmal sogar siebenstellige Beträge gehen. Da Agile Coaches und Scrum Master nur indirekt darauf einwirken, ist das allerdings kaum bezifferbar.


Was eher möglich ist, ist die Bewertung der Entwicklung, die ein Team nach dem Hinzufügen oder Entfernen eines agilen Methodikers nimmt. Auch das mit Vorsicht, da schnell Korrelation für Kausalität gehalten werden kann, aber mit steigender Aussagekraft, wenn mehr Teams in diese Betrachtungen einbezogen werden. Und das Beste - eine derartige Bewertung kann auf Basis bereits und anerkannter etablierter Metriken erfolgen.


Der Klassiker darunter sind die Effizienz-Metriken, die auch aus dem Lean Management bekannt sind, vor allem Lead Time und Cycle Time. Mit ihnen wird gemessen, wie schnell Arbeits- oder Wertschöpfungs-Pakete die Wertschöpfungskette von der Idee bis zur Auslieferung durchlaufen. Der Anspruch: mit einem Agile Coach oder Scrum Master im Team sollten diese Durchlaufzeiten sich mit der Zeit oder im Vergleich zu anderen Teams reduzieren.


Eine andere Möglichkeit sind aus dem DevOps-Bereich kommende Messgrössen, wie die Deployment-Häufigkeit, die durchschnittliche Menge des pro Deployments veränderten Code, die Durchschnittszeit einer Fehlerkorrektur oder des Zurücknehmens einer fehlerhaften Änderung oder ganz einfach der Betriebskosten. Um hier Wirkung zu erzielen ist eher die Spezialform eines Technical Coach nötig, der dann aber zu bedeutenden Verbesserungen führen kann und sollte.


Als letztes (zumindest in dieser kurzen Aufzählung) kommen Nutzungs- bzw. Akzeptanzmetriken dazu. Wie sind Verkaufszahlen, Nutzungs-, Absprung- und Konversionsraten, wie entwickeln sich die Anwender-Zufriedenheit und die Menge der Support-Calls, etc. Auch hier ist der Anspruch, dass sich diese Zahlen nach dem Hizufügen eines Agile Coach oder Scrum Master zum Team verbessern sollten, sowohl mit der Zeit als auch im Vergleich zu anderen Teams.


Um es zusammenzufassen: es ist zwar kaum möglich, den Mehrwert eines agilen Methodenmenschen separat zu beziffern, was dagegen oft geht ist aber eine Messung der besseren oder schnelleren Wertschöpfung oder der geringeren Bürokratie- oder Verspätungskosten eines gecoachten Teams. Und dann gilt die Faustregel, dass der so erzeugte oder eingesparte Wert mindestens den Ausgaben für den jeweiligen Agile Coach oder Scrum Master entsprechen sollten (siehe oben), damit der sich rentiert.


Um am Ende einen häufigen Einwand gegen eine solche Betrachtung aufzugreifen - ja es kann sein, dass der agile Methodiker alles richtig macht, dass aber keiner auf ihn hört, und es damit nicht an ihm liegt, dass sich nichts verbessert. Aus einer wirtschaftlichen Betrachtung heraus ist das aber kein starkes Argument. Denn wenn eine Ausgabe keinen entsprechenden Gegenwert erzeugt, dann ist sie in Frage zu stellen - unabhängig von Schuldfragen, allein aufgrund ökonomischer Sachzwänge.

 

Nachtrag:

Ein Feedback zu diesem Artikel hat einen weiteren Aspekt aufgeworfen: ein zusätzlicher betriebswirtschaftlicher Mehrwert, der durch Agile Coaching oder Scrum Mastering erzeugt werden kann ist, dass selbstorganisierte Team weniger Management brauchen - wodurch Manager von der Gehaltsliste verschwinden. Auch ein valider Punkt.


1Z.B. ob eine Aufschlüsselung in Junior, Senior, etc. erfolgt oder nicht
2Das ist die "Kosten-Perspektive", der beauftragenden Unternehmen. Viele Freiberufler sind nicht lückenlos beauftragt und verdienen entsprechend weniger

Montag, 1. September 2025

Kommentierte Links (CXXX)

Grafik: Pixabay / Brian Penny - Lizenz
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Martin Eriksson: Strategy into Action - Organising Teams to Execute at Pace

Ratgeber zum optimalen Aufsetzen einer Entwicklungsorganisation gibt es viele, dieser hier von Martin Eriksson ist aber aus einem bestimmten Grund besser als viele andere: statt detaillierte Anleitungen zu geben (die dann in vielen Umsetzungsfällen nicht passen werden) gibt er dem Leser einige Prinzipien mit, deren Befolgung viel bewirken kann - Vergegenwärtigung des Unterschieds zwischen Aufbau- und Ablauforganisation, crossfunktionale, mit Handlungsvollmacht versehene Teams, eine Systemarchitektur die dem Teamschnitt entspricht (und ihn definiert) und kontinuierliche Arbeit am Abbau von Abhängigkeiten.

Rudolf Gysi: Was ist der Zeitgeist in deiner Organisation?

Mal wieder ein nützliches Werkzeug, diesesmal die "Zeitgeist Empathy Map" von Rudolf Gysi. Benutzen kann man sie um festzuhalten, welche Themen eine Organisation gerade bewegen, sei es auf betriebswirtschaftlicher, technischer, sozialer oder sonstiger Ebene. Das Ganze natürlich nicht als Selbstzweck, sondern um aufzuzeigen wo gerade ein akuter Klärungs- oder Handlungsbedarf besteht, den man als nächstes angehen sollte.

Jessica Wolfe: Beyond Story Points - Estimating with Time, Complexity, and Risk

Ich halte das seit einigen Jahren in der agilen Community um sich greifende Story Point-Bashing zwar für übertrieben, muss aber eingestehen, dass das Konzept für viele Anwender zu abstrakt zu sein scheint. Für derartige Fälle hat Jessica Wolfe eine gute Alternative entworfen - die drei klassischen Story Point-Teildimensionen Aufwand, Komplexität und Ungewissheit lassen sich auch separat schätzen und festhalten. Für sich genommen ist jede von ihnen deutlich konkreter.

Chris Belknap: You Say You’re Agile? Show Me Your Release Frequency

Dieser Text erinnert mich an den Nokia Test, der um 2010 herum populär war, und in dem (unter anderem) ermittelt wurde, wie regelmässig ein Team fertige Software an seinen Kunden ausliefert. Chris Belknap fügt dieser Metrik noch weitere Dimensionen hinzu, klärt auf warum sie wichtig ist und gibt Ratschläge zu ihrer Optimierung. Ganz im Sinn der legendären Formulierung aus dem agilen Manifest: Working software is the primary measure of progress.

Paulo Caroli: Team OKRs in Action

Als letztes ein Longread. In grosser Sorgfalt und Ausführlichkeit führt Paulo Caroli aus, was Objectives and Key Results (OKRs) sind, wie sie auf Teamebene eingesetzt werden können und wie sie die Arbeit des Teams mit übergreifenden Zielen verbinden können. Insgesamt eine gute Umsetzungsvariante, die sich zum Ausprobieren im eigenen Team anbietet.

Freitag, 29. August 2025

Where Did Cringey Corporate Jargon Come From?

Ich gestehe: nachdem ich den Grossteil meines Berufslebens in Konzernen verbracht habe, ist mir an vielen Stellen gar nicht mehr bewusst, wie merkwürdig die Sprache ist, die dort mit der Zeit entstanden und normal geworden ist. Dabei sind ihre z.T. speziallen Redewendungen nicht zufällig entstanden, wie die Linguistin Erica Brozovsky hier erklärt.



Dass dieses Video sich vor allem mit der englischen Variante der "Konzernsprache" beschäftigt, heisst übrigens nicht, dass es die im Deutschen nicht auch gäbe. In weiten Teilen ist sie sogar identisch, denn Konzern-Deutsch ist vor allem eines: Denglisch.

Montag, 25. August 2025

Additive und subtraktive Veränderung

Manche Dinge ändern sich über die Zeit erstaunlich wenig. Vor genau 10 Jahren habe ich darüber geschrieben, dass (vor allem grosse) Unternehmen Prozessverbesserungen in erster Linie dadurch angehen, dass sie ihnen neue Regeln, Rollen und Liefergegenstände hinzufügen wollen - in vielen Fällen mit dem Ergebnis, dass sich alles eher verschlechtert als verbessert. Dieses kuriose Verhalten lässt sich nahezu überall beobachten - und mittlerweile auch erklären.


Im Artikel People systematically overlook subtractive changes veröffentlicht 2024 im Nature-Magazin haben die schwedischen und amerikanischen Wissenschaftler Joshua Juvrud, Laurence Myers und Pär Nyström  das Phänomen beschrieben, dass die meisten Menschen Verbesserungen vor allem durch das Hinzufügen von etwas (additive Veränderung) bewirken wollen, selbst wenn das Weglassen von etwas (subtraktive Veränderung) zu deutlich besseren Ergebnisse führen würde.


Dabei beobachteten die erwähnten Forscher in ihren Untersuchungen nicht etwa, dass subtraktive Veränderungen kategorisch ausgeschlossen wurden. Vielmehr war es so, dass additive Veränderung den meisten untersuchten Menschen als die spontan naheliegendere Option erschien und unreflektiert gewählt wurde, während subtraktive Veränderung erst dann erwogen wurde, wenn additive Veränderungen ergebnislos, unmöglich oder offensichtlich unsinnig waren.


Dieses grundlegende Vernachlässigen subtraktiver Veränderungen (das so genannte Subtraction Neglect) war dabei abhängig von unterschiedlichen Faktoren unterschiedlich stark ausgeprägt. Zu ihnen gehörten neben der Art der Aufgabe auch Alter, sozialer Hintergrund und nationale, bzw. kulturelle Zugehörigkeit. Die zentrale Erkenntnis hierbei war, dass der Subtraction Neglect wenn nicht sogar durch Sozialisation erworben, dann zumindest deutlich von ihr geprägt ist.


Und das bringt uns zurück zu den grossen Organisationen, die ihre Prozesse durch ständiges Hinzufügen weiterer Regeln, Rollen und Liefergegenstände immer stärker überladen und sie so verschlechtern, statt sie zu verbessern. Ausgehend von der erwähnten Forschung kann zunächst mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das in weiten Teilen auf das Phänomen des Subtraction Neglect zurückzuführen ist, es also unbewusste Ursachen hat.


Gleichzeitig ermöglicht die Beeinflussung der Subtraction Neglect durch soziale Prägung aber auch ein Gegensteuern. Alleine das Bewusstmachen der subtraktiven Veränderung als möglicher Massnahme kann bereits zu einer besseren Optionenabwägung führen und eine Empfehlung sie anzuwenden kann das nochmal verstärken. Und wird dadurch sogar noch ein Erfolg erzielt, kann sich sogar die Grundeinstellung ändern, auch das geht aus der erwähnten Forschung hervor.

Freitag, 22. August 2025

Deine Muda: Den Schuldigen suchen

Zwölfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Suchen nach einem Schuldigen.


Dass immer dann, wenn irgendetwas schief gelaufen ist, zuerst nach einem Schuldigen gesucht wird, ist ein verbreitetes Phänomen. Wie konnte das passieren? Wer hat da nicht aufgepasst? Wessen Aufgabe wäre es gewesen das zu verhindern? Wer wäre verantwortlich gewesen für einen Prozess der das verhindert? Solche und ähnliche Fragen sind absolute Klassiker, wenn es um die Aufarbeitung geht, und sie alle haben eines gemeinsam: sie sind nicht besonders zielführend.


Zunächst führen sie immer wieder zu einem erstaunlichen Forschungs- und Exegese-Aufwand, um rückwirkend aus irgendeiner Vorschrift oder Abmachung ableiten zu können, wer sich theoretisch oder nach "gesundem Menschenverstand" hätte verantwortlich fühlen müssen, oder wer irgendwann mal eine Zusage gemacht oder eine Aufgabe übernommen hat, aus der sich die Verantwortung für das mittlerweile eingetretene Missgeschick ableiten liesse.

 

Umgekehrt ergeben sich aus ihnen ähnlich grosse Aufwände, mit denen alle, die für die Schuld in Frage kommen, belegen wollen, dass sie selbst in keinem Fall verantwortlich sind. Auch von ihnen werden alle möglichen Vorschriften, Abmachungen, Protokolle, Pläne, Zuständigkeitsbeschreibungen und sonstigen Dokumente gewälzt werden um mit deren Hilfe nachweisen zu können, zum jeweiligen Zeitpunkt nicht informiert, verfügbar oder zuständig gewesen zu sein.

 

Und damit endet es nicht. Sind einer oder mehrere Schuldige gefunden worden, werden sie erfahrungsgemäss erhebliche weitere Aufwände in Distanzierungen, Absicherungen und ähnliche Tätigkeiten stecken, um beim nächsten mal nicht mehr Schuld zu sein. Und sollte die Schuldzuordnung unklar gewesen sein, fliessen häufig erhebliche weitere Aufwände inzusätzliche Regeln, Dokumentations-Pflichten und weitere Massnahmen, um das nächste mal die Schuld klarer zuweisen zu können.

 

Nichts davon erzeugt einen Mehrwert, alles davon verbraucht Zeit und Energie. Es ist Muda in Reinform. 


Um eine Alternative aufzuzeigen: statt den Schuldigen zu suchen könnte man überlegen, wie man Prozesse sicherer oder unbürokratischer gestaltet, Kommunikation einfacher und direkter möglich macht, Qualitätssicherungs-Massnahmen einführt die nicht nur aus Dokumentations-Pflichten bestehen und vieles mehr. Das wären Schritte, die zwar auch Aufwand verursachen, aber einen der sich auszahlt und nicht bloss alle Beteiligten frustriert.

Dienstag, 19. August 2025

Das wichtigste Meeting in Scrum

Bild: Unsplash / Austin Distel -

Für viele Scrum Master oder Scrum Teams ist die Frage nach dem wichtigsten Scrum-Meeting schnell beantwortet: die meisten werden schnell die Retrospektive nennen, die in der Regel als das Inspect & Adapt-Event schlechthin gesehen wird. Ein nennenswerte Minderheit dürfte eher zum Daily Scrum tendieren, in dem auf tagesaktueller Basis der Arbeitsfortschritt besprochen wird. Ich dagegen würde ein drittes Meeting als das wichtigste bezeichnen: das Sprint Review.


Um zu verstehen wie ich dazu komme besinnen wir uns kurz auf etwas Grundlegendes: der einzige Existenz-Zweck eines Scrum Teams ist die Lieferung von benutzbarem Mehrwert für ein Markt- oder Kundensegment. Alle anderen üblicherweise angestrebten Ziele (schlanke Prozesse, schnelle Reaktionsfähigkeit, technische Exzellenz, psychologische Sicherheit, etc.) sind nur Mittel um dieses Haupt-Ziel zu erreichen denn nur dieses Hauptziel sichert das wirtschaftliche Überleben.


Die Überprüfung, ob auf dieses Hauptziel noch immer hingearbeitet wird könnte nun theoretisch in jedem der Scrum Meetings stattfinden. Im Planning sollten nur wertstiftende Sprintziele eingeplant werden, im Daily sollte sichergestellt werden, dass nur auf dieses Ziel hingearbeitet wird, in der Retrospektive kann daran gearbeitet werden, all das nochmals zu optimieren. Eines aber ist in all diesen Meetings nicht möglich: zu überprüfen, ob wirklich Wert geschaffen wird.


Der Grund dafür ist einfach: in allen Regel-Meetings (mit der einen Ausnahme des Sprint Reviews) sind die meisten Scrum Teams unter sich. Ob tatsächlich etwas Wertschöpfendes geplant und geschaffen wird, sehen sie dort nur aus ihrer subjektiven Perspektive - und schlimmstenfalls ist die verfälscht, durch Group Think, Betriebsblindheit, Confirmation Biases und andere Antipattern. Derartige Teams bauen ihr Produkt de facto nur noch für sich, und oft genug an ihrer Zielgruppe vorbei.


Um es dazu nicht kommen zu lassen hilft nur eines: die eigene Filterblase regelmässig platzen lassen und den Kontakt mit der echten Welt da draussen suchen. Nur echte Kunden (und wenn die nicht greifbar sind dann wenigstens echte Kundenservice- oder Vertriebsmitarbeiter) können wirklich sagen, ob eine Nutzungs- und/oder Kaufbereitschaft für das erstellte Produkt besteht. Und diese echten Kunden oder Kundenvertreter trifft das Scrum Team eben im Sprint Review, das darum das wichtigste Meeting ist.


Das heisst natürlich nicht, dass die anderen Scrum Meetings unwichtig sind, im Gegenteil. Jedes von ihnen erfüllt einen bestimmten und entscheidenden Zweck. Aber in Relation zum Sprint Review und seiner für die Validierungs des Existenzwecks des Team elementaren Funktion treten sie alle ein Stück in den Hintergrund. So zumindest meine Meinung, die ich schon seit Jahren und in jeder sich bietenden Diskussion gerne verteidige.


Der Vollständigkeit halber sei natürlich erwähnt, dass es in Scrum theoretisch auch noch andere Möglichkeiten gibt, durch Zielgruppen- oder Stakeholder-Einbindung aus der eigenen Filterblase herauszukommen. Mehr dazu hier. Aber nach über 10 Jahren in zig Unternehmen traue ich mir die Aussage zu, dass das nur in sehr, sehr wenigen Teams stattfindet. Warum auch immer.

Freitag, 15. August 2025

Ein Bild sagt mehr als 1000 Worte (L)

Grafik: Forrest Brazeal - CC BY-NC-ND 4.0

Sehr wohltuend an der gerade laufenden Marktbereinigung: es hat schon länger niemand mehr den Gartner Hype Cycle auf irgendetwas Agiles angewandt.

Dienstag, 12. August 2025

The AI Build Trap

An sich klingt es erst einmal wie etwas Positives: mit Hilfe der immer besseren und intuitiveren KI-Tools ist es heute so einfach wie nie, Software zu erstellen. Sei es als Programmier-Unterstützung, wie im Fall des Github Copilot, oder als ein Programm, dass einem den Grossteil der Arbeit abnimmt, wie Lovable - es gibt eine ganze Reihe von Möglichkeiten, die eigene Produktivität in bisher ungeahnte Höhen zu schrauben. Und doch steckt auch ein Risiko dahinter.


Vereinfacht gesagt: wenn es auf einmal so einfach ist, neue Programme und Features zu erstellen, wird das auch mit grösserer Bereitwilligkeit getan werden als bisher. Statt aufgrund der begrenzten Kapazität der IT-Abteilungen nur die wirklich wichtigsten Anforderungen umzusetzen, kann jetzt jeder Kundenwunsch, jede einzelne Stakeholder-Anforderung und jede Entwickler-Idee in Produktion gebracht werden. Und das ist bei weitem nicht so positiv, wie es klingen mag.


Die offensichtlichste Folge eines derartigen bereitwilligen Umsetzens aller Wünsche ist die Entstehung von Bloatware, also von Anwendungen, die derartig mit Funktionen überladen sind (von denen viele nur eine sehr kleine oder ggf. sogar lediglich eine hypothetische Anwendergruppe haben) dass sie unübersichtlich werden, schlecht zu bedienen sind, hohe Ladezeiten haben und viel Speicherplatz einnehmen. Mit anderen Worten - es wird ein aus Kundensicht schlechtes Produkt.


Und auch unterhalb der Benutzeroberfläche führt das massenhafte Erzeugen von Funktionalitäten (und damit von Code) zu Problemen. Auch hier ist die Unübersichtlichkeit ein zentrales Problem. Je grösser die Codebase wird, desto schwieriger wird es zu sagen, an welcher Stelle was passiert. Die Überprüfung der KI-Ergebnisse durch einen Menschen (deren Verzicht einem Kontrollverlust gleichkäme) wird immer schwieriger und irgendwann sogar unmöglich.

 

Diese Phänomene erinnern nicht ohne Grund an die Build Trap (sinngemäss die Produktivitäts-Falle), die 2019 von Melissa Perri in ihrem gleich benannten Buch beschrieben wurde. Auch ihr selbst ist diese Parallele aufgefallen, und sie hat sie in mehreren Social Media-Posts thematisiert. Von ihr stammt auch die Erweiterung des ursprünglichen Begriffs zu dem der AI Build Trap, der damit als zusätzliche und spezifische Ausprägung dieses Antipatterns beschrieben ist.


Um auch hier zu einem konstruktiven Ausblick zu kommen: in die AI-Produktivitäts-Falle zu geraten, ist zum Glück kein Naturgesetz, man kann (und sollte) es auf verschiedene Weisen verhindern. Zum einen, indem man durch kleine, schnell veröffentlichte Incremente überprüft, ob es für die neuen Funktionen überhaupt Bedarf oder Akzeptanz gibt, zum anderen indem intern regelmässig sichergestellt wird, dass der Code von Menschen verstanden wird und ggf. verändert werden kann.


Das kann sich natürlich wie eine Entschleunigung der gerade erst gewonnenen Programmier-Höchsgeschwindigkeit anfühlen - und es ist auch eine. Trotzdem ist es sinnvoll, sich darauf einzulassen, wenn man nicht riskieren will, sich in der Build Trap wiederzufinden, und Produkte gebaut zu haben, die vom  Kunden nicht gewollt und von den eigenen Entwicklern nicht verstanden werden.

Donnerstag, 7. August 2025

Interview with an Senior DevOps Engineer 2025

Dieses Video von Kai Lentit hat mich diese Woche mehr als einmal zum Lachen gebracht. Nicht nur wegen der Rolle, in die erschlüpft (irgendwas zwischen Super Mario und Albert Einstein), sondern vor allem wegen der hohen Dichte von DevOps-bezogenen Gags. Etwas Schönes für die IT-Nerds.



Witzig ist das auf gleich zwei Ebenen: zum einen, weil es die durch die DevOps-Community wabernden Buzzword-Wolken treffend persifliert, zum anderen weil in dem ganzen Wortsalat einige sehr scharfe Abrechnungen mit häufigen Umsetzungs-Fehlern versteckt sind. "DevOps is a mindset - you build it, you run it. Now you're bad at building and running it." Soll tatsächlich so vorkommen.

Montag, 4. August 2025

Vibe Coding-Prototypen statt Anforderungsdokumente

Über die Folgen des Einsatzes künstlicher Intelligenz in der Softwareentwicklung konnte man in den letzten Jahres einiges lesen, das meiste allerdings mit wenig Realitätsbezug. Das heisst aber nicht, dass es keine sinnvollen Anwendungsfälle gäbe, im Gegenteil. Nach und nach werden sie erkannt, ausprobiert, bewertet und veröffentlicht, so wie in diesem Fall: dem Einsatz von Vibe Coding-Prototypen statt Anforderungsdokumenten bei Google.



Zum Kontext: Anforderungsdokumente (oder Product Requirements Documents/PRDs) sind in der Softwareentwicklung bisher ein notwendiges Übel. Sie sind abstrakt, können missverstanden werden und sind aufwändig in der Erstellung und Aktualisierung. Allerdings müssen Anforderungen irgendwo festgehalten werden, Inhalt, Intention und Kontext sind meistens zum umfangreich um ohne derartige Unterstützung im Gedächtnis zu bleiben.


Madhu Garu, der für Gemini zuständige Produktmanager bei Google, beschreibt im oben eingebetteten Post ein alternatives Vorgehen: anstelle eines Anforderungsdokuments präsentiert ein Produktmanager seinem Team einen digitalen Prototypen, also ein noch unfertiges, nicht integriertes und ggf. fehlerhaftes Stück Software, das aber die gewünschte Funktion bereits in einer so guten Form enthält, dass ein Entwicklungsteam sie nachbauen kann.


Dass Produktmanager oft nicht selbst programmieren können wird dabei umgangen, indem der Prototyp durch Vibe Coding erstellt wird, also dadurch, dass er einem KI-Programm beschrieben wird, das ihn dann programmiert (mehr dazu hier). Die Anforderung wird durch den Prototypen deutlich plastischer als durch eine blosse Beschreibung in textform, und (und jetzt wird es interessant) ist im Vergleich zu einem Anfoderungsdokument oft schneller zu erstellen.


Garu geht in den Kommentaren unter seinem Post noch auf weitere Aspekte des Vorgehens bei Google ein: so wird es auch dort nicht überall eingesetzt, bzw. vorgeschrieben, sondern nur dort, wo der Produktmanager es beherrscht und für sinnvoll hält, ob weitere Teams es übernehmen entscheiden sie selbst, Vibe Coding-Prototypen werden nicht auf Produktion deployed und für grössere oder abstraktere Themen ist weiterhin die Schriftform Standard.


Insgesamt eine spannender Erfahrungsbericht von einem Unternehmen, das schon mehrfach bewiesen hat, agile Entwicklungspraktiken zu beherrschen. Sowohl die Art des Einsatzes als auch die Art der Einführung dürften erkennbar dazu beitragen, dass die Kommunikation effektiver, das Feeback schneller und die Lieferzyklen kürzer werden. Eine empfehlenswerte Inspiration also, die man auch im eigenen Unternehmen bei Gelegenheit ausprobieren sollte.

Donnerstag, 31. Juli 2025

Kommentierte Links (CXXIX)

Grafik: Pixabay / Brian Penny - Lizenz
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Emily Webber: The Scaling Teams checklist

Checklisten für die Skalierung von Entwicklungsorgseinheiten gibt es viele, sowohl als alleinstehende Werkzeuge als auch als Teil von Skalierungs-Frameworks (looking at you, SAFe). Diese hier von Emily Webber und Jamie Arnold ist also nichts grundsätzlich Neues, hat aber eine nützliche Erweiterung: die einzelnen Abschnitte sind mit Wenn-Dann-Bedingungen verbunden und zeigen so Abhängigkeiten auf.

David Pereira: Why Fail Fast Culture Doesn’t Fly In Most Places

"Fail early, fail often" oder das in seiner Bedeutung ähnliche "Move fast and break things" sind populäre Mantras in der agilen Bewegung. David Pereira weist darauf hin, dass das zwar grundsätzlich richtig ist, aufgrund der Stigmatisierung des Begriffs "Scheitern" aber nur schwer umzusetzen. Und er weist darauf hin, dass der Zweck des Scheiterns (das schnelle Lernen) auch anders zu erreichen ist.

Jenny Wanger: Product ops without permission

Die Ratschläge, die Jenny Wanger hier verfasst, sind zwar auf die Einführung von Product Operations ohne offiziellen Auftrag ausgerichtet, lassen sich aber auch auf andere Vorgehensmodelle übertragen (Agile without permission, DevOps without permission, etc). Ihre Kernbotschaft: die einzelnen Elemente lassen sich auch ohne Methoden-Label einführen, einfach weil sie Sinn ergeben und Mehrwert stiften. 

Falk Steiner: 20 Jahre unbemerkt - Programmierfehler sorgt für fehlende Lehrer

Mal wieder ein bemerkenswertes Beispiel für die potentiell weitreichenden Folgen defekter Software: 20 Jahre lang wurden freiwerdende Lehrerstellen trotz vorhandenem Budget nicht besetzt. zuletzt waren es über 1400. Falk Steiner gelingt es dabei, die Ursachen und Wechselwirkungen nachvollziehbar zusammenzufassen. So ist es zwar weiter unglaublich, aber wenigstens nachvollziebar.

Maarten Dalmijn: If You're Using AI to Generate Requirements or User Stories You're Completely Missing the Point

Zuletzt noch ein Link zu einem KI-Thema, bzw. zu einem anschaulichen Fall für eine falsche Art sie einzusetzen. Wie Maarten Dalmijn richtig schreibt: wenn man künstliche Intelligenz einsetzt um Vorgänge zu beschleunigen, die nicht der Engpass des Gesamtsystems sind, dann wird die Gesamtleistung dieses Systems nicht verbessert sonden verschlechtert. Damit ist niemandem geholfen.

Montag, 28. Juli 2025

Law of the second floor

Bild: Public Domain Pictures / Petr Kratochvil - CC0 1.0

Einige der "Gesetze", in denen Zwangsläufigkeiten und Regelmässigkeiten grosser Organisationen beschrieben werden, haben es in den letzten Jahrzehnten zu grösserer Bekanntheit gebracht, etwa Conway's Law oder Goodhart's Law. Heute soll es aber um eines der weniger bekannten gehen. Gefunden habe ich es im Blog des Agilen Otter, und es trägt den Namen TheLaw of the Second Floor, sinngemäss übersetzbar mit Das Gesetz der zwei Stockwerke.


Nobody two levels ABOVE OR BELOW you on the org chart really knows what your days are like
Law of the second floor


Auch das sinngemäss ins Deutsche übersetzt: niemand, der in der Hierarchie zwei Ebenen über oder unter Dir ist, weiss womit Du Deine Arbeitszeit verbringst. Dass diese "Gesetzmässigkeit" (bei der es sich eigentlich um eine häufig zu machende Beobachtung handelt) dann Gesetz der zwei Stockwerke heisst, liegt in der Gleichsetzung von Hierarchieebene und Stockwerk begründet, die sich tatsächlich in vielen Unternehmen so wiederfindet.


Wie alle Beobachtungen ist auch die, auf der das Gesetz der zwei Stockwerke beruht, erst einmal wertneutral, allerdings ist implizit bereits die Bewertung enthalten, dass die Unkenntnis der Situation des jeweils anderen zu suboptmalen Ergebnissen führen wird - in Ermangelung eines genauen Wissens werden Annahmen getroffen, die zu einem gewissen Anteil falsch sind, was wiederum dazu führt, dass darauf beruhende Anweisungen oder die Reaktionen auf diese es ebenfalls sind.


Ein scheinbar naheliegender Verbesserungsansatz wäre es, dieses Problem an seiner Wurzel zu behandeln, indem man allen Beteiligten die Situation der jeweils anderen nachvollziehbar macht. Das ist aber schwer bis unmöglich - unten in der Hierarchie sind Detailgrad und Focus hoch, oben ist der Detailgrad gering und an Stelle eines thematischen Focus tritt eine breite, abstraktere Sicht. In beiden Fällen sind Kontext, Terminologie, etc. hochgradig spezifisch und z.T. gegenläufig.1


Versucht wird das trotzdem immer wieder, z.B. durch Mitarbeiter-Befragungen, Veröffentlichungen im Intranet, Townhall-Meetings und weitere Formate. Mehr als ein bestenfalls oberflächliches Verständnis entsteht dabei aber selten, alleine aufgrund des damit verbundenen Kommunikations- und Lernaufwandes, der den Beteilgten in der Regel unverhältnismässig erscheint und für den in den meisten Fällen auch gar nicht genug Zeit zur Verfügung steht.


Alleine diese Erkenntnis kann, wenn sie allgemein geteilt wird, zu deutlichen subjektiven und systemischen Verbesserungen führen. Zum einen, weil es die Annahmen und Erwartungshaltungen gegenüber anderen Personen realistischer macht, zum anderen dadurch, dass niemand mehr (irrigerweise) glaubt, im Zweifel bereits alles zu wissen, was für eine Entscheidung notwendig ist. Die gemeinsame Arbeit an übergreifenden Zielen kann dadurch deutlich erleichtert werden.



1Während z.B. unten Detail-Kenntnisse für die meisten Jobs entscheidend sind, ist es auf der oberen Ebene aus Zeitgründen wichtig, Details eher zu vermeiden

Freitag, 25. Juli 2025

Wie der Staat wieder handlungsfähig wird (III)

Bild: Wikimedia Commons / Anton Heiz - CC BY-SA 4.0

Unter den vielen Berichten über sich verzögernde Infrastruktur-Projekte ist dieser hier kaum aufgefallen: der Bau des Fehmarnsundtunnels (Teil der Fehmarnbelt-Querung) dauert mindestens drei Jahre länger als geplant. Auffällig dabei ist, dass ein Grossteil dieser Verspätung nicht etwa durch Probleme beim eigentlichen Bauvorhaben entsteht (das hat noch gar nicht begonnen), sondern durch Bürokratie: Ausschreibungsprozesse, zu beachtende Fristen, Einspruchsverfahren, Klagemöglichkeiten, etc.


Der Fehmarnsundtunnel ist dabei kein Einzelfall: wer mit Bauträgern und Behördenvertretern spricht bekommt zahllose derartige Geschichten zu hören, bei denen das eigentliche Vorhaben mehr oder weniger im Plan liegt, bei denen aber bürokratische Vorgaben immer wieder zu verzögertem Start oder zwischenzeitlichen Unterbrechungen führen - und das nicht etwa durch Behördenwillkür, sondern nur weil auch die sich an Gesetze und Vorschriften halten müssen.


Wie sehr es tatsächlich die Verwaltungsbürokratie ist, die alles verlangsamt, kann man an einem anderen Beispiel sehen. den LNG-Flüssiggas-Terminals, die ab dem Jahr 2022 an der Nord- und Ostseeküste gebaut wurden. Für deutsche Verhältnisse sind sie in atemberaubender Geschwindigkeit fertig geworden, zum Teil lag zwischen dem Beschluss des Vorhabens und dem Ende der Bauarbeiten weniger als ein Jahr. Und man kann jetzt bereits ahnen, wie das gelungen ist.


Das für diesen Zweck erlassene "Gesetz zur Beschleunigung des Einsatzes verflüssigten Erdgases" (LNG-Beschleunigungsgesetz) macht fast ausschliesslich Eines: es setzt andere Gesetze und Vorschriften ausser Kraft. Formulierungen wie "Abweichend von § X ..." oder "§ Y des Gesetzes Z ist nicht anzuwenden" ziehen sich durch seinen gesamten Text und machen deutlich klar, dass hier ein subtraktiver Wandel stattfindet. Mit anderen Worten: Verbesserung durch Weglassen.


Natürlich heisst das nicht, dass alle bisherigen Gesetze und Vorschriften sinnlos sind und abgeschafft werden sollten, derartige Kettensägen-Methoden gehören (wenn überhaupt) in ganz bestimmte Sektoren der Privatwirtschaft, die entfesselnde Wirkung eines Regulierungs-Rückbaus ist aber an diesem Fall mehr als deutlich zu erkennen. Wenn der Staat wieder handlungsfähig werden soll, ist das temporäre oder dauerhafte Ausserkraftsetzen also ein durchaus gangbarer Weg.


Mindestens für kriselnde Vorhaben von gesamtwirtschaftlicher Bedeutung, so wie die wie die Fehmarnbelt-Querung eines ist, könnte man die Erlassung von deregulierenden Beschleunigungs-Gesetzen zu einer der standardmässig zu erwägenden Optionen machen. Und wenn man in diesem Zusammenhang feststellen kann, welche anderen Vorgaben besonders verlangsamend sind, hätte man auch gleich eine Idee wo dauerhafte Abschaffungen oder Reformen Sinn machen könnten.

Dienstag, 22. Juli 2025

Das Effektivitäts-Framework von Tesla und SpaceX

Bild: CCNull / Marco Verch - CC BY 2.0

Es dürfte nur wenige Personen geben, deren Image sich in wenigen Jahren so stark gewandelt hat wie das von Elon Musk - vom ökologisch-liberalen Hoffnungsträger zum techno-faschischen Oligarchen. Was dabei in Vergessenheit zu geraten droht ist, dass Musk in seinen Unternehmen vieles umgesetzt hat, was aus "agiler Perspektive" als vorbildhaft gilt.Dazu gehört unter anderem auch das fünfstufige Effektivitäts-Framework von Tesla und SpaceX, der u.a. in seiner autorisierten eponymen Biografie beschrieben ist.


 

1. Question every requirement (make them less dumb)

Die konsequente Umsetzung dessen, was auch als maximizing the amount of work not done bekannt ist. Wichtig dabei ist als Voraussetzung, dass Anforderungen immer einer Person zuzuordnen sein müssen, bei der man sie hinterfragen kann. Und ebenfalls, dass dieses Hinterfragen nicht nur als Legitim sondern als sinnvoll und gewünscht wahrgenommen wird, da jedem bewusst ist, dass niemand (egal wer er ist) davor gefeit ist, Fehler zu begehen - und zwar auch dumme Fehler.

 

2. Delete as much process as possible - even if it is too much

Ein Grundsatz, der seit Musks Kettensägen-Bürokratieabbau sicher kritischer gesehen werden muss, der aber einen rationalen Kern hat: von vielen (Umsetzungs-)Prozessen weiss man erst ob sie verzichtbar sind, wenn man durch ihre vollzogene Abschaffung getestet hat ob sie fehlen würden - andernfalls wird sich immer jemand finden, der sie verteidigt (im Zweifel der, dessen Job die Prozess-Aufrechterhaltung ist). Und wenn sie wirklich fehlen, kann man sie ja erneut einführen.

 

3. Simplify and optimize

Ab hier wird das Vorgehen dem ähnlicher, das aus Scrum, Kanban & Co bekannt ist. Wichtig ist dabei aber, dass zuerst die beiden ersten Schritte durchgeführt worden sind, um zu verhindern, dass unsinnige Anforderungen umgesetzt oder sinnlose Prozesse optimiert werden. Ein bekanntes Beispiel für die danach folgende Vereinfachung und Optimierung sind die Fertigungsstrassen der neuen Tesla-Fabriken, die erst in Zelten gebaut und optimiert werden, bevor die (teure) Fabrik um sie herum gebaut wird.

 

4. Accelerate cycle time

Sobald ein Fertigungs- oder sonstiger Arbeitsprozess grundlegend eingerichtet ist kann er in seinem Ablauf beschleunigt werden, z.B. indem Arbeitspakete kleiner geschnitten werden, Kopfmonopole aufgelöst werden oder Routinen entwickelt werden. Das Ganze idealerweise auf Basis von Daten wie Durchlaufzeiten, Qualitätsschwankungen oder Abnutzungsraten. Und auch hier gilt: die vorherigen Schritte müssen vorher stattgefunden haben, sonst riskiert man, etwas Falsches zu beschleunigen.

 

5. Automate

Dass die Automatisierung von Prozessschritten erst ganz am Ende erfolgt, hat einfache Gründe: sie ist kostspielig, und sollte daher erst stattfinden, wenn möglichst klar ist, dass das was automatisiert wird wirklich sinnvoll und effektiv gestaltet ist. Und sobald die Automatisierung stattgefunden hat, sind die Anforderungen und Abläufe der Sichtbarkeit der Menschen entzogen, und damit auch dem kritischen Hinterfragen. Frei nach Thorsten Dirks: automatisierte Scheissprozesse sind zu vermeiden.

 

Wie oben gesagt, spätestens Elon Musks Tätigkeit für die US-Regierung, in der sich sein Effektivitäts-Framework wiedererkennen lässt, hat aufgezeigt, dass es nicht in jeden Kontext übertragen werden kann oder übertragen werden sollte. Gleichzeitig hat es seine Unternehmen aber unbestreitbar erfolgreich gemacht, bis hin zu zeitweisen Quasi-Monopolen auf ihren Märkten. Wie so oft gilt daher auch hier: bitte nicht unhinterfragt kopieren, sondern zuerst kritisch bewerten. Z.B. mit den eigenen Schritten 1 bis 3.