Posts mit dem Label Kommentierte Links werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Kommentierte Links werden angezeigt. Alle Posts anzeigen

Donnerstag, 1. Oktober 2026

Kommentierte Links (CXXXIV)

Bild: Pexels / Ekam Juneja - 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.

Ralph Jocham: Scrum's Protocol Is Easy to Copy. Its Agenda Is Not.

Wenn man mit Anwendern über Scrum spricht hört man immer wieder zwei erstaunlich gegensätzliche Meinungen: für die einen ist Scrum einfach zu verstehen und umzusetzen, für die anderen nur schwer zu greifen und hochgradig anspruchsvoll in der Nutzung. Ralph Jocham hat dafür eine gute Erklärung - das scheinbar Einfache ist der formale Rahmen, das Anspruchsvolle ist die Erreichung der dahinterstehenden Ziele, für die die Formalitäten nur Mittel zum Zweck sind.

Steve Blank: AI Killed the MVP – Long Live the IUP

Aus dem guten alten Minimum Viable Product (MVP) sind mit der Zeit unzählige Varianten abgeleitet worden, vom Riskiest Assumption Test bis zum Minimum Lovable Product. Steve Blank bringt eine weitere Variante ins Spiel, das Initial Untested Product (IUP), eine mit Hilfe von KI erstellte digitale Anwendung, die deutlich vollständiger ist als ein MVP, im Gegensatz zu diesem aber noch nicht an echten Usern getestet wurde (was aber natürlich noch folgen muss).

Maarten Dalmijn: Mastering the Four Abstraction Levels of Refinement

Ein Phänomen, dem ich immer wieder begegne, ist, dass die Backlog Refinements agiler Entwicklungteams mit sehr geringem Vorlauf stattfinden, häufig nur von wenigen Tagen. Maarten Dalmijn gibt hier eine gute Anleitung für einen grösseren Denkrahmen: man fängt an mit dem übergreifenden (Produkt-)Ziel, macht weiter mit dem funktionalen Lösungsansatz und der technischen Realisierungsidee. Erst dann leitet man die umsetzbaren Arbeitspakete daraus ab.

Chee-Hong Hsia: Hi Scrum Masters, if your goal is to make yourself obsolete, then you're doing it all wrong.

Ich vertrete schon seit längerem die eher seltene Meinung, dass der Satz "Der Scrum Master schafft sich selber ab" einer der veheerendsten Irrtümer rund um dieses Framework ist (siehe hier). Chee-Hong Hsia ergänzt das um einen wichtigen Aspekt: hinter der Idee, dass ein Team irgendwann keinen Scrum Master mehr braucht, steckt oft die Annahme, dass irgendwann der Zeitpunkt erreicht ist, an dem es alles gelernt hat und sich nicht mehr entwickeln muss - weiter an der Realität vorbei geht es kaum.

Christoph Laskowski: Warum Mikel Arteta sein eigenes Team sabotiert

Eine kleine Anekdote aus einer ungewöhnlichen Ecke: Mikel Arteta, der in der schwersten Fussball-Liga der Welt Meister geworden ist, bringt sein Team regelmässig mit unangekündigten Interventionen aus der Routine heraus, von (scheinbaren) Diebstählen über geänderte Tagesabläufe bis hin zu kurzfristig umgeplanten Reiserouten. Das Ziel, dadurch Resilienz und Anpassungsfähigkeit zu stärken, erinnert sehr an Chaos Engineering.

Montag, 31. August 2026

Kommentierte Links (CXXXXIII)

Bild: Pexels / Ekam Juneja - 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.

Nigel Thurlow: Why High Utilization Slows Knowledge Work

Dass es in der Kreativ- und Wissensarbeit eine schlechte Idee ist, eine hundertprozentige Auslastung der Mitarbeiter anzustreben, ist eigentlich bekannt: ein einziges ungeplantes Ereignis kann alle Pläne umwerfen, wenn keine freie Kapazität da ist um es zu bewältigen. Nigel Thurlow zeigt auf, dass das allerdings einer verbreiteten Meinung zuwiderläuft, die davon ausgeht, dass eine hohe Auslastung zu besserer Planbarkeit führt. Diese Annahme sollte möglichst früh validiert und widerlegt werden.

John Cutler: Tokens, Hours, Points, and Other Curious Proxies

Die neueste Metrik die gerade in Softwareentwicklungsabteilungen verfolgt wird ist der "Return on Tokens" (ROT). John Cutler ist schon lange genug im Geschäft um sich an andere Messgrössen zu erinner: an Arbeitsstunden, Durchlaufzeiten, Story Points und weitere. Im Umgang mit ihnen allen sieht er Gemeinsamkeiten, die er auch bei ROT wiedererkennt, und zwei mögliche Ausgangsszenarien. Als nositives wäre das Intrapreneurship, als negatives Goodharts Law.

Marty Cagan: A Fresh Definition of The Product Role

In diesem Artikel von Marty Cagan steckt zum einen ein Versuch, die Rolle des Produktentwicklers neu zu definieren, als jemand der analytisches Problembewusstsein mit systemischem Denken und der Anwendung von Lösungstechniken verbindet. In ihm steckt aber auch das Eingeständnis, das Potential von KI in der Produktentwicklung zumindest vorläufig überschätzt zu haben. Statt davon auszugehen, dass bald jeder Produkte entwickeln kann, sieht Cagan jetzt weiter einen Bedarf für Experten.

Roman Pichler: Product Operating Model - The Crucial Enabler for AI Success

Apropos Product. Roman Pichler weist darauf hin, dass die saubere Anwendung des Product Operating Model auch dann (und gerade dann) notwendig ist, wenn zukünftig vor allem mit KI entwickelt werden soll. Passiert das nicht, ist für ihn mit den gleichen Dysfunktionen zu rechnen, die es bereits im Umfeld vergangener technischer Umbrüche (Web, Mobile, etc) gegeben hat. Gelingt dagegen eine Saubere Anwendung, ist für ihn eine volle Nutzung der KI-Potentiale möglich.

Robin Marienfeld, Susanne Hakenjos: Durchsanieren in 22 Tagen

Als ich vor mehreren Jahren zum ersten mal darüber geschrieben habe, dass agile Arbeitsweisen auch im Bausektor Sinn machen, war das gewählte Beispiel eine Altbau-Sanierung. Mit der Meinung scheine ich mittlerweile nicht mehr allein zu sein, denn wie man bei Robin Marienfeld und Susanne Hakenjos nachlesen kann, gibt es mittlerweile das Framework des "Sanierungs-Sprint", durch den eine Gebäude-Sanierung in nur drei Wochen möglich wird. Und einiges aus Scrum & Co erkennt man darin wieder.

Freitag, 31. Juli 2026

Kommentierte Links (CXXXXII)

Bild: Pexels / Ekam Juneja - 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.

Lucas F. Costa: Lucas' Laws of Project Management

"Gesetze" des Projekt- oder Produktmanagement gibt es mittlerweile viele, aber Lucas Costa hat das ganze noch einen Schritt weiter getrieben und sogar ein kleines Gesetzbuch verfasst. Die 10 darin enthaltenen Regeln beziehen sich nicht explizit auf ein agiles Vorgehen, entsprechen ihm aber weitgehend, und das mit einer systemis Sicht, also unter Berücksichtigung nicht nur eines Projektteams, sondern auch der Unternehmens- und Marktumgebung.

Nigel Thurlow: The Toyota Production System (TPS) - What the House Actually Represents

Wer Nigel Thurlow in den sozialen Medien folgt, kennt seine (berechtigte) Beschwerde, dass ein Grossteil der Menschen, die sich auf das Toyota Production System (TPS) berufen, dieses nur aus zweiter oder dritter Hand kennen, und noch nie eine Fabrik von innen gesehen haben. Um die dadurch entstehenden Missverständnisse zu beseitigen holt er weit aus und fasst das Konzept mit allen seinen Aspekten zusammen. Wirklich lesenswert.

Chris Chinchilla: Nokia’s 14 Years of Mobile-Phone Supremacy Ended in an Afternoon

Die Geschichte des Aufstiegs und Niedergangs von Nokia ist seit einem Jahrzehnt zu einer immer wieder bemühten Metapher für die potentiell verheerenden Folgen von fehlender Innovation und Anpassungsfähigkeit geworden. Chris Chinchilla hat das Ganze in einem ausführlichen Longread zusammengefasst, der aber nicht nur aufzeigt, was damals schiefgelaufen ist, sondern mit mit einer oft übersehenen Pointe endet: Nokia hat sich danach neu erfunden und ist noch immer da - und erfolgreich.

Rahul Singal: Prefactoring - Clear the Way for Your New Feature

Manchmal sind es kleine Änderungen der Begrifflichkeiten, die eine Kommunikation wesentlich verändern können. Das hier ist ein Beispiel: statt von einem Refactoring, das oft die Frage aufwirft, warum etwas (scheinbar) Fertiges noch einmal überarbeitet werden soll, spricht man bei Google jetzt von einem Prefactoring, das zukünftige Arbeiten einfacher macht. Gegenüber technikfernen Budgetverantwortlichen könnte das Gespräche tatsächlich einfacher machen.

Mark Graban: A Kaizen Board in Japan, and a Manager Who Answered Every Sheet

Noch einmal zum Thema der japanischen Verbesserungskultur. Ähnlich wie Nigel Thurlow weiter oben kennt Mark Graban TPS, bzw. Lean Management aus der Praxis, und gibt hier einen interessanten Einblick. Neben der eigentlichen Geschichte der Wertschätzung auch kleiner Änderungen durch den Manager ist als Neben-Information sehr anschaulich herausgearbeitet, um welche Art von Veränderungen es beim ursprünglichen Kaizen eigentlich geht.

Dienstag, 30. Juni 2026

Kommentierte Links (CXXXXI)

Bild: Pexels / Ekam Juneja - 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.

Sean Goedecke: Working with product managers

Eines der grossen Probleme rund um die Zusammenarbeit mit Softwareentwicklern, bzw. Softwareentwicklungs-Teams ist, dass ein Grossteil der Literatur zu diesem Thema aus einer Aussenperspektive geschrieben ist, also von Leuten, die keine Entwickler sind, sondern nur mit Entwicklern zusammenarbeiten. Sean Goedecke ist eine der bekannteren Ausnahmen, und auch hier ist ihm oein guter Blick aus der Innenperspektive der Softwareentwicklung gelungen.

Fagner Brack: Degradability

Es gibt Begriffe, deren Bedeutung sich erst erschliesst, wenn man sie einmal erklärt bekommt. Fagner Brack stellt hier einen solchen vor, die Degradability. Hinter diesem Begriff steckt vereinfacht gesagt das Ausmass des Verfalls der technischen Kompatibilität, dem eine Software alleine durch die Entwicklung neuer Tools und Standards ausgesetzt ist. Ist die Degradability einer Anwendung hoch, erzeugt sie ständig neue Arbeit, nur um weiterhin benutzbar zu bleiben. 

Jeff Gothelf: What “done” means when you’re shipping AI features

Die meisten Aussagen über die Veränderung der Softwareentwicklung durch KI focussieren sich auf ein (sehr kontroverses) Thema - die Erzeugung von mehr Quellcode in kürzerer Zeit. Nach Beiträgen zu anderen Aspekten muss man mitunter suchen, aber man findet sie. Z.B. hier bei Jeff Gothelf, der die interessante Idee aufwirft, in die Definition of Done einer Entwicklungs-KI auch Distributionen, Varianzen, Szenarien und Entscheidungsbäume einzubauen. 

Beth Smith: The Copenhagen Fallacy - complexity science and the organisations that keep changing without ever changing

Ein typischer Artikel der Cynefin Co.-Artikel: erzählerischer Einstieg, leicht sperriges Vokabular, wertvoller Inhalt. Beth Smith wirft drei Fragen auf, die man besser vor dem Beginn eines Veränderungsvorhabens klären sollte - wer hat überhaupt Legitimation und Kapazität um Veränderungen anzustossen, welche dezentralen Koppelungen und Abhängigkeiten sind zu berücksichtigen und welche Umgebungsfaktoren begrenzen mögliche Veränderungen?

Erik de Bos: Why Over-Optimized Teams Fail to Deliver Real Performance

Erik des Boos bringt einen der grossen Klassiker zurück, der für praktisch jedes komplexe System gilt. Je stärker in Richtung Spezialisierung, Effizienz und Auslastung optimiert wird, desto geringer ist die Resilienz im Fall ungeplanter Ereignisse. Und da in komplexen Umgebungen ungeplante Ereignisse fast schon der Regelfall sind, sind über-optimierte Teams hier im Zweifel weniger leistungsfähig als solche, die aus lern- und entwicklungsbereiten Generalisten bestehen.

Samstag, 30. Mai 2026

Kommentierte Links (CXXXX)

Bild: Pexels / Ekam Juneja - 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.

John Cutler: Why Defining Teams Is So Hard

Erstaunlich oft sind es die scheinbar einfachen Dinge, die bei näherer Betrachtung nur schwer zu erklären sind. Die Definition eines Teams gehört in diese Kategorie - wann eine Gruppe ein Team ist und an welchen Kriterien man das festmachen kann, ist nicht allgemeinverbindlich geklärt. John Cutler kann das zumindest in Teilen auflösen, indem er klar macht, dass der Begriff nicht fix ist, sondern sich im Spannungsfeld verschiedener Sichtweisen bewegt - der Produkt-zentrischenen, der Nutzer-zentrischen, der Technik-zentrischen und der Kommunikations-zentrischen Sicht.

Catarina Buchatskiy, Viktoriia Honcharuk: Inside Ukraine’s Battlefield Innovation Loop

Aus der erstaunlichen Innovativität, die die ukrainische Armee notgedrungen im Kampf gegen einen deutlich grösseren Gegner entwickeln muss, könnte man mittlerweile eine eigene Kategorie machen. Catarina Buchatskiy und Viktoriia Honcharuk beleuchten hier den Aspekt, dass der andauernde Krieg es ermöglicht, militärische Produktinnovationen bereits früh in der Entwicklungsphase zu testen und basierend auf den dabei gemachten Erfahrungen zu verbessern.

Joost Minnaar: Organizational silos - what the Titanic teaches us about information that never arrives

Als Ikone der gescheiterten Technologien darf die Titanic mittlerweise als Beispiel für alle möglichen Missstände herhalten, hier bei Jost Minaar für die potentiell verheerenden Auswirkungen organisatorischer Silos. Neben dieser Storytelling-Komponente enthält der Artikel aber noch weitere interessante Gedanken, unter anderem dazu, warum diese Silos überhaupt entstehen und warum sie so schwer aufzulösen sind.

Tim Ottinger: Agile, YAGNI, Smaller Steps, Bikes and Automobiles

Sollte irgendjemand auf die Idee kommen, nach der viralsten Grafik der agilen Bewegung zu suchen, würde er vermutlich bei dieser Visualisierung eines MVP landen, gezeichnet ca. 2012 von Henrik Kniberg:
Seitdem haben sich zahllose Menschen daran abgearbeitet, sie zu bestätigen, zu widerlegen, zu ergänzen oder auszudifferenzieren. Dieser Text von Tim Ottinger ist eine der besseren dieser Auseinandersetzungen.

Stefan Wolpers: “Write As Little Code As Possible” Was Always the Point. AI Just Made It Urgent

Irgendwo habe ich die schöne Aussage gelesen, dass Quellcode nicht zu den Vermögenswerten eines Unternehmens gehört, sondern zu den wertmindernden Faktoren, da seine Wartung, Dokumentation, und Aktualisierung ständig Ressourcen binden. Diese Gedanken von Stefan Wolpers gehen in eine ähnliche Richtung, und zeigen ein grosses Problem auf: wenn es dank KI so einfach wie nie ist, viel Code zu erzeugen, ist das nicht nur eine Chance, sondern auch ein unkalkulierbares Risiko.

Donnerstag, 30. April 2026

Kommentierte Links (CXXXIX)

Bild: Pexels / Ekam Juneja - 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.

Tom Geraghty: The Vasa

Die Geschichte des schwedischen Kriegsschiffs Vasa, das unmittelbar nach seinem Stapellauf gesunken ist, ist eines der berühmtesten gescheiterten Grossprojekte aller Zeiten. Bei Tom Geraghty findet man nicht nur Bilder ihres Wracks, sondern eine gute Zusammenfassung der verschiedenen Faktoren, die dazu führten, dass es trotz offensichtlich nicht gegebener Seetüchtigkeit auf das Wasser geschickt wurde. Ihr Zusammenspiel ergibt das "Vasa-Syndrom", das sich auch auf andere Vorhaben übertragen lässt.

Mike Fisher: Build the Right Thing

Eine der besten Erklärungen des Unterschieds von Effizienz und Effektivität ist die, dass Effizienz "build the thing right" bedeutet, Effektivität dagegen "build the right thing". Wem das noch zu abstrakt ist, der kann bei Mike Fisher nachlesen, was es bedeutet, das Richtige zu bauen. Und das erklärt an einem sehr anschaulichen Beispiel, der Entwicklung des ersten motorengetriebenen Flugzeugs im Amerika des frühen zwanzigsten Jahrhunderts.

Jurgen Appelo: Value Stream Examples - From Signal to Impact

Value Streams, Value Stream Maps und ähnliche Konzepte sind Klassiker der Organisationsoptimierung, aber Jurgen Appelo hat völlig recht wenn er sagt, dass den meisten von ihnen etwas fehlt: die Abschnitte nämlich, die sich vor und nach der produkterzeugenden Organisation befinden. Oder mit anderen Worten: der Markt, dessen Bedürfnisse, Zahlungsbereitschaften und Nutzerverhalten elementar für den Erfolg jedes Produktes sind.

Itamar Gilad: 5 Ways Product Discovery Breaks Down (Part I), (Part II)

Die beiden Teile dieser Ausführung von Itamar Gilad haben jeweils ihren eigenen Wert. Im ersten klärt er darüber auf, was Product Discovery eigentlich ist (inclusive einiger häufiger Missverständnisse), im zweiten zeigt er auf, warum sie in vielen Unternehmen nicht funktioniert. Besonders nützlich dabei ist, dass er jeden der häufigsten Gründe dafür nicht nur beschreibt, sondern auch erklärt, wie man ihn vermeiden oder beheben kann.

Karl Scotland: Strategic Insouciance - Why Too Much Focus Can Kill Emergence

Zum Schluss ein kleiner Gedankenanstoss: in praktisch jedem Management-Ratgeber wird zu radikaler Focussierung geraten, um nur die wirklich wichtigen Dinge zu tun, die aber dafür richtig. Karl Scotland hat völlig recht wenn er sagt, dass das auch schädlich sein kann - dann nämlich, wenn der Focus zum Tunnelblick wird, und man neue Ideen und Impulse dadurch Ignoriert. Er rät dazu, Focussierung anders zu interpretieren: nicht notwändigerweise auf nur ein einziges Thema, aber darauf, nicht zu viele Themen zur selben Zeit anzugehen.