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 |
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 |
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 |
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 |
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 |
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 |
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.Dienstag, 31. März 2026
Kommentierte Links (CXXXVIII)
|
|
| Bild: Pexels / Ekam Juneja - Lizenz |
Mike Fisher: Twitching Before You Sprint
Dass sich die Welt (oder zumindest die Welt der Software-Entwicklung) immer schneller dreht, merkt man auch daran, dass Vorgehensweisen die früher als unglaublich schnell galten, plötzlich als langsam wahrgenommen werden. Mike Fisher empfiehlt hier zum Beispiel anstatt der üblichen Sprints (die normalerweise ein bis vier Wochen dauern) einen deutlich schnelleren Modus: kleine Mikro-Vorhaben, die er "Twitches" (Zuckungen) nennt. Mal sehen, wo diese Beschleunigung noch hinführt.Steve Blank: Your Startup Is Probably Dead On Arrival
Apropos Beschleunigung. Steve Blank geht in diesem Blogpost davon aus, dass Startups die vor Beginn der Durchbrüche der KI-Technologie gegründet wurden, bereits jetzt technisch und prozessual abgehängt sind - und das selbst dann, wenn sie erst wenige Jahre alt sind (für ihn trifft das auf alle zu, die vor 2025 gegründet wurden). Der aus seiner Sicht entscheidende Paradigmenwechsel: die Erstellung von Software ist plötzlich so billig, dass hier ein limitierender Faktor komplett entfällt.Christina Wodtke: Everyone on Your Team Is Right (And That’s the Problem)
Das was Christina Wodtke in ihrem Artikel beschreibt, habe ich selbst zigfach erlebt: verschiedene Einheiten oder Hierarchieebenen einer grossen Organisation sind so stark von ihren jeweiligen Sachzwängen, Erfahrungen und Glaubenssätzen geprägt, dass jede andere Sichtweise ihnen widersinnig erscheint, und jeder der eine andere Sichtweise hat irrational. Was sie als Ausweg aus dieser Situation sieht, würde ich unterschreiben: man muss sich selbst aktiv in die jeweils andere Position begeben.Doc Norton: This Has Happened Before. It's Happening Again.
Dass im Moment ganze Berufe von den Fortschritten in der Künstlichen Intelligenz grundlegend verändert werden dürfte unstrittig sein, und dass die Softwareentwicklung einer dieser Berufe ist, ebenso. Ob dieser Umbruch ein nie dagewesenes Ausmass hat, ist dagegen diskutabel, Doc Norton kann mehrere Beispiele vergleichbarer vergangener Umbrüche nennen, an die sich die Entwickler auch angepasst haben. [Ein Zusatz-Link: im Pragmatic Engineering-Podcast äussert sich Grady Booch sehr ähnlich.]Jannik Reigl: What if Germany isn’t very good at research?
Als letztes ein grundsätzliche Beobachtung, die ich ebenfalls schon in vielen Firmen gemacht habe. In Deutschland sind wir offensichtlich sehr gut darin, bestehende Technologien und Produkte weiterzuentwickeln und ihre Herstellung zu optimieren. Wenn es zu Disruptiven Innovationen und Sprunginnovationen kommt, tun wir uns dagegen oft schwer. Jannik Reigl versucht zu erklären, welche Faktoren uns in diese Situation geführt haben.Samstag, 28. Februar 2026
Kommentierte Links (CXXXVII)
|
|
| Bild: Pexels / Ekam Juneja - Lizenz |
Jim Highsmith: The Agile Manifesto at 25
In diesem Monat ist das Manifest für agile Softwareentwicklung fünfundzwanzig Jahre alt geworden, und unter den vielen Menschen, die darüber geschrieben haben, möchte ich Jim Highsmith hervorheben, der es auf den Punkt gebracht hat: die agile Bewegung hat seitdem gleichzeitig gewonnen und verloren. Gewonnen, weil viele ihrer Ideen zu Standards geworden sind, verloren, weil viele ihrer Praktiken zu sinnentleerten Ritualen erstarrt sind. Beides ist wahr.Jeff Gothelf: Technical systems will continue to succumb to culture
Dass die Begeisterung für neue Tools den Blick für Realitäten vernebeln kann, ist ein Phänomen das es schon vor der KI-Welle gegeben hat, das jetzt aber noch einmal verstärkt wurde. Jeff Gothelf bringt es auf den Punkt - Tems die bisher bei der Arbeit nur das absolut nötige Minimum geleistet haben, werden durch KI nicht produktiver - aber sie erreichen dieses absolut nötige Minimum jetzt mit noch weniger Anstrengung. Das Ergebnis bleibt gleich.Braden Kelley: Three Myths That Kill Change and Transformation
Um ein bekanntes Sprichwort zu paraphrasieren: die bekannten Regelmässigkeiten, denen das Change Management unterliegt, sind einfach, schnell zu verstehen - und falsch. Braden Kelley nennt drei dieser scheinbar naheliegenden aber meistens falschen Faustregeln. 1. Wenn Menschen verstehen, warum Änderungen angestossen werden, werden sie sie mittragen; 2. Skeptische Minderheiten sollten so lange bearbeitet werden, bis sie überzeugt sind; 3. Erste kleine Erfolge ziehen automatisch grössere nach sich. Klingt alles wünschenswert, ist aber in der Realität meistens falsch.Liam Kane: When Work Ages - Block It or Remove It from WIP?
Ein sehr praktisches Problem, vor dem viele nach Kanban arbeitende Teams regelmässig stehen: wie visualisiert man Arbeit, an der es gerade aus irgendeinem Grund nicht weitergeht? Die Antwort ist natürlich "Es kommt darauf an", da das aber zu generisch ist, formuliert Liam Kane das Ganze weiter auf und zeigt anhand einiger Wenn-Dann-Bedingungen, welche Arten von Blockaden welche Arten von Visualisierung nach sich ziehen können.Lorin Hochstein: Poor Deming never stood a chance
Manchmal hilft Vereinfachung bei der Kommunikation von komplexen Sachverhalten. Dieser Text von Lorin Hochstein ist so ein Fall, denn er komprimiert die jüngere Management-Geschichte auf den Gegensatz der Lehren von Peter Drucker und W. Edwards Deming. Lässt man sich darauf ein, wird man auf einen ähnlichen Schluss kommen - die Ideen von Drucker haben gewonnen, zumindest in der westlichen Welt. Ob das gut oder schlecht ist, kann jeder für sich bewerten.Samstag, 31. Januar 2026
Kommentierte Links (CXXXVI)
|
| Bild: Pexels / Ekam Juneja - Lizenz |
Stefan Kühl: Die Komplexitätsreduktion durch Managementmoden
Die (scheinbaren) Vorteile von Management-Moden lassen sich für Stefan Kühl einfach zusammenfassen: Jede Problemlösung bringt zwangsläufig auch „Lösungsprobleme“ mit sich, also Seitenauswirkungen, unbedachte Konsequenzen und Ähnliches. Managementmoden mit ihren häufig stark vereinfachenden Vorgehensanleitungen helfen dabei, diese „Lösungsprobleme“ auszublenden. Zumindest für eine gewisse Zeit.Stefan Norrvall: Three Axes — Now What?
Für Stefan Norrvall scheitern Veränderungsvorhaben Richtung Agilität in grossen Organisationen deshalb, weil es gegenläufige "Achsen" gibt, die die Veränderungskräfte in unterschiedliche Richtungen lenken: nicht delegierbare zentrale Verantwortlichkeiten, externe Regulierungen und fehlende formale Legitimierungen emergenter Praktiken. Dabei ist das Scheitern nicht zwangsläufig, wird aber wahrscheinlich, wenn man diese Achsen ignoriert.Stephanie Ockerman: Self-Managing Teams - From Compliance to Collaboration
In gewisser Weise eine Fortsetzung des letzten verlinkten Artikels. Stephanie Ockerman beschreibt hier nicht nur die notwendigen "Bausteine" für selbstorganisierte Teams, sondern auch die Hindernisse, die grosse Organisationen ihnen (z.T. unbewusst) in den Weg legen. Und in denen findet sich einiges, was man den Auswirkungen der drei oben genannten Achsen zuordnen könnte. Ein schönes Beispiel dafür, wie systemisch alles zusammenhängt.Maarten Dalmijn: Red Vs Blue Roadmaps - Why Most Roadmaps Suck
Ein neuer Blick auf Output-orientierte und Outcome-orientierte Roadmaps. Die ersten (Output-orientiert, bzw. Rot) sind für Maarten Dalmijn das Ergebnis von Angst vor den Folgen eines möglichen Scheiterns, während die zweiten (Outcome-orientiert, bzw. Blau) Fehlentwicklungen als unvermeidbar betrachten, und ihren Focus daher nicht auf Fehlervermeidung sondern auf Fehlerbehebung legen. Wie er richtig sagt: das muss man sich bewusst trauen.Mike Fisher: Culture Debt
Es gibt technische Schulden, es gibt organisatorische Schulden und für Mike Fisher gibt es auch kulturelle Schulden. Ähnlich wie die beiden anderen Typen werden sie bewusst aufgenommen, um zu Beginn schneller zu Ergebnissen zu kommen, vor allem durch Inkaufnahme von ruppigen Umgangsformen und von toleriertem unmoralischem Verhalten von Leistungsträgern. Und genau wie die anderen beiden Typen sind einmal aufgenommene kulturelle Schulden nur mit einem erheblichen Mehraufwand wieder zu tilgen.Mittwoch, 31. Dezember 2025
Kommentierte Links (CXXXV)
|
| Bild: Pexels / Ekam Juneja - Lizenz |
James Shore: The Best Product Engineering Org in the World
Eigentlich war ich mir ziemlich sicher, das Video von James Shore's Keynote auf dem Regional Scrum Gathering Tokyo irgendwann mal in einen Post auf dieser Seite eingebunden zu haben. Da ich es nicht finde, ist hier das Transkript. Anscheinend ist seine Firma, die er hier beschreibt, einer der mittlerweile seltenen Fälle, in denen Extreme Programming der offizielle Arbeitsmodus ist - und wenn man ihm glauben darf, mit durchschlagendem Erfolg.Charles Lambdin: Why Agile Is Losing Steam
Artikel über die Ursachen der zur Zeit abnehmenden Beliebtheit agiler Arbeitsweisen gibt es viele, die meisten davon allerdings nur mit geringem Tiefgang, bzw. mit der offensichtlichen Absicht, mit einer Alternative zu Geld oder (unternehmensintern) zu mehr Macht zu kommen. Charles Lambdins Text hat wesentlich mehr Tiefgang, da er auf einer systemischen Betrachtung der umgebenden Gesamt-Organisationen aufbaut, mit denen die agilen Teams und Methodiker oft eher unglücklich interagieren.Itamar Gilad: Embracing Uncertainty - A Modern Take On Strategy, Goals, and Roadmaps
Itamar Gilad setzt mit seinen Überlegungen an einem häufigen Problempunkt an: wenn die Märkte und Technologien sich ständig ändern, wie kann man da planen? Und umgekehrt - wie soll man ohne Planungen in der Lage sein, ein Unternehmen zu führen? Seine Ausführungen fassen einige bewährte Praktiken zusammen, mit deren Hilfe man diesem Dilemma entkommen kann, verbunden mit einigen hilfreichen Tools und Visualisierungen.Steve Denning: How Networks Of Competence Help Avoid The Trauma Of Reorganizations
Dass Reorganisationen grosser Unternehmen auf viele Mitarbeiter traumatisierend wirken können ist einer der dunklen Aspekte des Change Managements, über die eher selten gesprochen wird. Steve Denning sieht die Ursache dafür in dem typischen Organisationsdesign, in dem Identifikation und Expertenstatus sich aus der Zugehörigkeit zu Organisationseinheiten ableiten (und mit ihnen verloren gehen können). Seine naheliegende Lösung: die Entkoppelung dieser Aspekte von der Firmenstruktur.Tobias Mayer: A simple Guide to Scrum
Um zu verstehen, warum das eigentlich sehr einfache Scrum-Framework von vielen Menschen als kompliziert und unverständlich empfunden wird, muss man sich die offiziellen Scrum-Regeln wie eine Legacy-Software vorstellen, die seit mehr als einem Vierteljahrhundert ständig erweitert und angepasst wird. Das was Tobias Mayer gemacht hat, kann man im Rahmen dieser Metapher als Refactoring verstehen: die Funktionsweise ist die gleiche geblieben, aber der Aufbau ist wesentlich klarer.Charity Majors: In Praise of “Normal” Engineers
Der Hintergrund dieses Artikels ist ein Mythos, und zwar der des so genannten "10x Engineer", also einer Softwareentwicklers, der zehnmal besser ist als der Durchschnitt, und der daher der ideale Angestellte einer IT-Firma ist. Charity Majors relativiert diese Wunschvorstellung und ordnet sie ein: in einem so grossen und sich so stark ändernden Berufsfeld wie der IT ist es praktisch unmöglich, dauerhaft 10x Engineer zu sein. Besser als trotzdem nach einem zu suchen ist es daher, ein Umfeld zu schaffen, in dem auch normale Entwickler das Beste aus sich herausholen können.Benji Weber: Teamwork & XP in the era of Genies
Um Missverständnisse zu vermeiden: wenn Benji Weber von "Genies" spricht, dann meint er nicht geniale Menschen, sondern die Softwareentwicklung unterstützende KI-Programme, die für ihn Geister (englisch: Genies) sind, die man nicht wieder in ihre Flasche zurückbekommt. Was er herausstreicht: der beste Arbeitsmodus für sie ist der, der auch bei menschlichen Programmierern der beste ist - kleine Releases, kleine Codebase, schnelle Tests, viel Automatisierung und verständlicher Code.Mike Fisher: How Culture Scales (or Doesn’t)
Von vielen Menschen wird (Unternehmens-)Kultur als etwas gesehen, das einfach da ist und sich nicht gezielt verändern oder gestalten lässt Die Organisationssoziologie und -psychologie würde widersprechen: es geht, allerdings mit dem Haken, dass es nicht einfach ist - vor allem in grossen Organisationen. Zum Glück hat Mike Fisher gerade für die einiges an Ratschlägen parat, mit deren Hilfe man sich dieser verdienstvollen Aufgabe annehmen kann.Melissa Suzuno: The Product Operating Model Explained
Zum Product Operating Model, dem v.A. von Marty Cagan popularisierten Arbeitsmodus der kalifornischen Tech-Firmen, ist schon viel gesagt und geschrieben worden. Was diese Erklärung von Melissa Suzuno aus dieser Masse heraushebt ist die Mischung aus Struktur und Ausführlichkeit. Man muss sich etwas Zeit nehmen, aber dann weiss man nicht nur wie das Ganze gedacht ist, sondern auch wie man versuchen kann, es bei sich einzuführen und was man dabei beachten sollte..Jeff Gothelf: What if there’s no behavior change to measure?
Zu den grossen Mantras der Objectives und Key Results (in der Produktentwicklung) gehört es, dass sie auf eine Verhaltensänderung der Käufer oder Nutzer eines Produktes abzielen sollten, und zwar auf eine, die gemessen werden kann. Das macht erstmal Sinn, wirft aber die Frage auf, wie man dann im Fall von Refactorings oder nichtfunktionaler Anforderungen mit OKRs arbeiten kann, schliesslich soll dabei ja keine Änderung spürbar sein. Jeff Gothelfs eigentlich naheliegende Antwort: in solchen Fällen sollte darauf hingearbeitet werden, dass Käufer oder Nutzer ihr Verhalten nicht ändern. Eigentlich einfach.
Montag, 29. Dezember 2025
Kommentierte Links (CXXXIV)
 |
| Grafik: Pixabay / Brian Penny - Lizenz |
John Cutler: Product Operating Models vs Operating Systems (Part I, Part II)
In den letzten Jahren ist das "Product Operating Model" zu einem beliebten Buzzword in der Welt der Manager und Unternehmensberater geworden, häufig verbunden mit der Ankündigung, es im eigenen Unternehmen, bzw. beim Kunden einführen zu wollen. Das das nicht ganz so einfach ist, kann man sich denken, und John Cutler zeigt auf warum: ein Operating Model ist per Definition so abstrakt, dass es an den jeweiligen Kontext angepasst werden muss. Da beginnen dann die Schwierigkeiten.Roman Pichler: Should Product Teams be Self-Managing?
In den Produktmanagement- und Agile-Communities dürfte diese Frage fast durchgehend mit ja beantwortet werden - (gute) Product Teams müssen selbstorganisiert sein. Wie das im konkreten Fall aussehen soll ist dann schon weit weniger klar (siehe oben). Roman Pichler nennt daher einige zentrale Erfolgsfaktoren: die Team-Zusammenstellung, das Zusammenarbeitsmodell, den Handlungsspielraum, die Führung und die Förderung.Andi Roberts: Why Tuckman’s model may no longer serve 21st century teams
Wenn wir über Tuckmanns Phasen-Modell sprechen (Forming, Storming, Norming, Performing, Adjourning) muss uns bewusst sein, dass es keine empirisch überprüfbare Regelmässigkeit ist, sondern ein in der Realität kaum auftretendes Ideal. Alternative Ansätze wie dieser hier von Andi Roberts sind daher hochgradig sinnvoll, allerdings handelt es sich in seinen eigenen Worten zunächst nur um ein mögliches Vorgehen, also eines, für das noch Erfahrungswerte fehlen.Jessica Wolfe: Rethinking “The Developer” - Builders, Modernizers, Orchestrators
Um die oft komplexe Realität für uns begreifbar zu machen, neigen wir Menschen zur Bildung von Kategorien oder Gruppen, denen wir dann gemeinsame Merkmale zuschreiben. Dass wir dabei manchmal über das Ziel hinausschiessen, zeigt Jessica Wolfe am Beispiel der Gruppe der Software-Entwickler. Die ist in der Realität keineswegs einheitlich, sondern umfasst verschiedene, sehr kontextspezifische Ausprägungen, mit denen jeweils eigene Interaktionsformen Sinn machen.Mike Fisher: When Change Outruns Us
Eine der Regeln für den totalen Stillstand in Unternehmen lautet, dass die Geschwindigkeit auf der Beschlussebene höher sein sollte als die Geschwindigkeit auf der Umsetzungsebene. Mike Fisher zeigt in diesem Text auf, dass das mehr als nur eine Pointe ist - in vielen Firmen ist es ein ernsthaftes Problem, das dort die Profitabilität, Innovationsfähigkeit und Handlungsfähigkeit massiv einschränken kann. Und er gibt auch Ratschläge, wie sich Veränderungen nachhaltiger gestalten lassen.Montag, 1. Dezember 2025
Kommentierte Links (CXXXIII)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
Steve Blank: The Department of War Just Shot the Accountants and Opted for Speed
Als externer Berater oder Mitarbeiter erlebe ich die lähmenden Auswirkungen klassischer Einkaufsprozesse regelmässig anhand der eigenen Beauftragung, die sich dadurch erstaunlich lange verzögern kann (der "Rekord" liegt bei mehreren Jahren). Angesichts derartiger Zustände sind Initiativen wie die von Steve Blank hier vorgestellte nur zu begrüssen. Ich hoffe, dass sie in Deutschland wahrgenommen und als Inspiration genutzt wird.John Cutler: 'Functional' Feature Factories Explained
Der nächste Teil einer bemerkenserten Serie. 2016: 12 Signs You’re Working in a Feature Factory. 2019: 12 Signs You’re Working in a Feature Factory — 3 Years Later. 2022: Scaled Feature Factories. 2024: How to Learn and Practice Product Management in a Feature Factory. und jetzt das hier: 'Functional' Feature Factories Explained. Man kann gespannt sein, wie viele weitere Teile John Cutler noch verfassen wird - hoffentlich einige.Maik Seyfert: Shadow Structures - The Unofficial Systems That Actually Run Your Organization
Informelle Strukturen und Prozesse, organisatorische Hinterbühne, Realstruktur (als Gegenstück zur Formalstruktur) und vieles mehr - das was Maik Seyfert hier als "Schattenstruktur" beschreibt hat viele Namen und Erscheinungsformen. Was er richtigerweise hervorhebt: man kann sie weder verbieten noch erfolgreich bekämpfen. Um eine Organisation erfolgreich führen und verändern zu können, muss man sich auf sie einlassen und sie einbinden.Kent Beck: Why Does Development Slow?
Das Gefühl kennt jeder, der Software-Entwicklungsorganisationen eine Zeit lang begleitet hat - mit der Zeit geht die Geschwindigkeit in der neue Features erstellt werden mehr und zurück, bis irgendwann selbst kleine Änderungen erstaulich lange dauern. Kent Becks "Exhale, Then Inhale"-Ansatz will das ändern, indem er regelmässig Zeit und Ressourcen für Identifikation und Beseitigung der verlangsamenden Faktoren vorsieht. Etwas, das hochgradig sinnvoll klingt.Christina Wodtke: The Premortem - Your Product’s Autopsy Before Launch
Der Begriff sagt es eigentlich schon aus, wenn man ein Post Mortem eines Vorhabens durchführt, ist es zu spät um aus dem Gelernten noch Änderungen abzuleiten. Christina Wodtkes Pre Mortem setzt nicht nur zeitlich früher an, sondern zeigt auch vier Faktoren auf, die für Produktentwicklungen tödlich sein können, und die deshalb möglichst früh identifiziert und behandelt werden sollten - Technical Failures, Market Failures, Ethical Failures und Regulatory & Environmental Changes.Freitag, 31. Oktober 2025
Kommentierte Links (CXXXII)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
Russ Miles: A Myth of Progress
Der Untertitel dieses Artikels fasst gut zusammen, worum es Russ Miles geht: On hype cycles and how to break them by focussing on human needs. Er vergleicht die Versprechen und Befürchtungen rund um Künstliche Intelligenz mit vergangenen Hypes, erkennt vieles wieder und arbeitet Gemeinsamkeiten heraus. Praktisch ist dabei eine Checkliste am Ende, mit deren Hilfe man überprüfen kann, ob man gerade einem Hype aufsitzt und wie man sich davon befreit.Petra Wille: Why It’s Time to Forget the Project vs. Product Operating Model Debate
Ein weiterer Beitrag zur ewigen Produkt vs Projekt-Debatte, die mittlerweile schon seit mindestens zwei Jahrzehnten durch Blogs und Konferenzen wabert. Diesesmal zumindest eine, die sich nicht in den rhetorischen Schützengraben begibt, sondern differenziert einordnet. Denn was Petra Wille hier beim Namen nennt, sollte eigentlich Common Sense sein - es geht nicht um ein entweder/oder sondern um ein sowohl als auch, bzw. um die Frage, was gerade besser zum Kontext passt.Gene Kim: A Patient Advocate's Guide to Navigating A Hospital System
Was passiert, wenn die Frau eines Prozessmanagement-Experten ins Krankenhaus eingeliefert wird? Er beginnt die um sie herum stattfindenden Abläufe zu analysieren, um dafür sorgen können, dass sie in der bestmöglichen Art und Weise genutzt werden. Herausgekommen ist dabei dieser bemerkenswerte Erfahrungsbericht des DevOps-Experten Gene Kim, der zwar sicher etwas USA spezifisch, aber trotzdem hochinteressant zu lesen ist.Maarten Dalmijn: The Best Product Managers Optimize For Reversibility and Optionality
Ein Drama an dem man immer wieder in IT-Projekten vorbeikommt sind Entscheidungen, die sich aus technischen Gründen kaum rückgängig machen lassen, selbst wenn sie sich als falsch herausstellen. Maarten Dalmijn zieht daraus den einzig sinnvollen Schluss: wenn der richtige Weg nicht sicher ist, sollte man sich keine Optionen derartig verbauen, sondern sich immer die Möglichkeit offen lassen, Features wieder ausbauen zu können.Sean Goedeke: How I influence tech company politics as a staff software engineer
Zum Schluss ein Gedankenanstoss von Sean Goedeke, der einer häufigen Annahme widerspricht - auch als einfacher Softwareentwickler der untersten Hierarchiestufe kann man strategische Entscheidungen im eigenen Sinn beeinflussen - wenn man weiss wie grosse Organisationen funktionieren und sich das zu Nutze macht. Mit anderen Worten: man braucht Systemsicht, Vorbereitung und Reaktionsfähigkeit.Dienstag, 30. September 2025
Kommentierte Links (CXXXI)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
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.Montag, 1. September 2025
Kommentierte Links (CXXX)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
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.Donnerstag, 31. Juli 2025
Kommentierte Links (CXXIX)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
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, 30. Juni 2025
Kommentierte Links (CXXVIII)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
Itamar Gilad: The Product Operating Model Explained
Seit der Begriff des Product Operating Model 2023 von Marty Cagan eingeführt wurde, gilt es in der Product Management-Community als anzustrebendes Zielbild. Für alle, die die Bücher und Blogposts von Cagan nicht in Gänze durchlesen wollen, hat Itamar Gilad die wesentlichen Punkte zusammengefasst. Praktisch aus meiner Sicht ist dabei vor allem die von ihm entwickelte grafische Darstellung, die einen schnellen und einfachen Zugang ermöglicht.Liam Kane: An Agile Transformation Dashboard
Apropos grafische Darstellung. Liam Kane hat vier Kernelemente des agilen Arbeitens zu einem Dashboard zusammengefasst, mit dem sich der Fortschritt einer agilen Transformation verfolgen lässt: Agile Practice Adoption, Value Delivery, Team Health und Strategic Outcomes. Wie diese im Detail gemessen werden, kann (und sollte) im Einzelfall angepasst werden, als übergreifende und messbare Kategorien sind sie aber gut geeignet.Mike Bowler: The big rewrite
Wer etwas Zeit in grösseren IT-Organisationen verbracht hat kennt die Situation, die Mike Bowler hier beschreibt - ein Bestandssystem ist schwer bedienbar, wartbar und weiterentwickelbar, also wird ein Ablöse-Projekt gestartet, dessen einziges Ergebnis ein neues schwer bedienbares, wartbares und weiterentwickelbares System ist. Wo das passiert ist, ist zwar der Code ausgetauscht worden, die Entwicklungspraktiken, die zu seiner schlechten Qualität geführt haben, sind aber geblieben.Maret Kruve: ADEPT - The Product Discovery Framework that Fits on a Sticky Note
Was ist eigentlich aus der Steuererklärung auf dem Bierdeckel geworden, die uns mal versprochen wurde? Naja, so lange wir sie noch nicht haben nehmen wir stattdessen das Product Discovery Framework, das auf ein Post-It passt, entwickelt von Maret Kruve. Natürlich dient diese Grösse dabei nur dem Erklären der fünf Dimensionen Attractive, Doable, Effective, Practical und Targetable, im Detail ist es etwas grösser, aber immer noch schlank.Celine Nguyen: The Perils of ‘Design Thinking’
Als letztes ein Longread. Celine Nguyen bespricht zunächst Maggie Gram's Buch The Invention of Design, leitet daraus aber eine grundsätzliche Kritik des Konzepts des Produkt-Designs ab. Nicht in dem Sinn, dass sie es für schlecht erklärt, sondern dahingehend, dass sie seine Begrenzungen und Risiken aufzeigt - vor allem solche, die entstehen, wenn versucht wird, Design Thinking und ähnliche Praktiken ausserhalb der Produktentwicklung anzuwenden.Samstag, 31. Mai 2025
Kommentierte Links (CXXVII)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
John Cutler: A Love Letter to Physical Boards (and What Comes Next)
Ich gestehe: diesen Liebesbrief von John Cutler an physische Task- und Kanban-Boards würde ich sofort unterschreiben. Tools wie Jira, Trello, Obsidian, Miro & Co haben zwar seit dem Corona-bedingten verstärkten Aufkommen von Remote-Arbeit massiv Funktionen und Nutzer dazugewonnen, sie haben die eigentlich einfache Idee visualisierter Arbeit aber auch massiv mit Regeln, Verlinkungen, Verschachtelungen und Formatierungen überladen. In diesem Fall war es tatsächlich früher besser.Milan Milanović: How Google Measures and Manages Tech Debt
Die technischen Schulden gehören zu den Begriffen, die zwar weit verbreitet sind, unter denen sich aber auch jeder etwas anderes vorstellt. Milan Milanović teilt hier eine interessante Fallstudie, die der Firma Google die technische Schulden in 10 Kategorien unterteilt: Migration needed or in progress, Poor or missing documentation, Inadequate testing, Bad code quality, Dead code, Code degradation, Knowledge gaps, Problematic dependencies, Failed migrations und Outdated release processes.Thomas Germain: Still booting after all these years - The people stuck using ancient Windows computers
Dass uralte Windows-Systeme bis heute die Grundlage für viele Geschäftsprozesse und kritische Infrastrukturen bilden ist schon lange ein Thema, so umfassend wie hier bei Thomas Germain habe ich es aber noch nicht aufbereitet gesehen. Was man von ihm mitnehmen kann: es gibt handfeste betriebswirtschaftliche Gründe dafür, dass sie nicht schon längst überall abgelöst wurden. Das macht es zwar verständlicher, im Ergebnis aber nicht besser.Barry O'Reilly: The Bootstrapped Revolution: How Small Teams Are Redefining Entrepreneurship
Ein bisschen Kontext vorweg: was Barry O'Reilly hier über kleine Business Einheiten schreibt, die mit weniger als 10 Mitgliedern ganze Märkte aufrollen, ist sehr spezifisch für das technische und soziale Ökosystem des Silicon Valley. Selbst wenn es aber nicht zur Gänze auf den stärker regulierten und von Grossunternehmen dominierten europäischen Markt übertragbar sein sollte - es zeigt deutlich, zu was kleine Einheiten in der Lage sein können, wenn man ihnen die passenden Rahmenbedingungen gibt.Alex Ewerlöf: When a team is too big
Je nach Sichtweise die Ergänzung oder das Gegenstück zum letzten verlinkten Text. Ausgehend von der Frage, ab wann ein Team zu gross wird um unbürokratisch arbeiten zu können, ist Alex Ewerlöf der grosse Rundumschlag gelungen. Synchrone und asynchrone Kommunikation, Silos und Taskforces, Software-Architektur, Generalisten, Spezialisten, Mob Programming, Lean Management, Ownership und künstliche Intelligenz - alles zusammen in einem lesenswerten Text.Mittwoch, 30. April 2025
Kommentierte Links (CXXVI)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
