Posts mit dem Label Kommentierte Links werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Kommentierte Links werden angezeigt. Alle Posts anzeigen
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 |
John Cutler: The 4 Framework Jobs (And Why It Matters)
Vorgehensmodelle jeglicher Art sind in praktisch allen grösseren und mittleren Organisationen weit verbreitet, von klassischem Projekt und Prozessmanagement über Lean Six Sigma und Total Quality Management bis hin zu Kanban, Scrum und SAFe. Was John Cutler zurecht anmerkt ist aber, dass zu selten darüber nachgedacht wird, warum diese Modelle ursprünglich ausgewählt wurden, was mit ihnen erreicht werden sollte und ob sie noch immer der beste Weg zu diesen Zielen sind.Sjoerd Nijland: How to Say “It Depends” with Data
"Es kommt darauf an" ist die klassische Antwort aller Produkt- und Projektmanager, wenn sie nach Fortschritten und Fertigstellungsdaten gefragt werden. Dass diese Antwort ohne Kontext und Begründung nicht zufriedenstellend ist, ist offensichtlich, weshalb Sjoerd Nijland eine entscheidende Erweiterung vornimmt: er nennt eine entscheidende Variable auf die es ankommt, nämlich das Ausmass der messbaren Volatilität des Backlogs. Je höher diese ist, desto unklarer die Fortschritts-Prognosen.Hunter Schwarz: This 3D-printed train station in Japan took less than 6 hours to build
Dass CAD und 3D-Druck agiles Arbeiten auch in Bauprojekten möglich macht, ist eine der spannenden Entwicklungen der letzten Jahre. Welche Umsetzungs-Geschwindigkeiten damit erreicht werden können beschreibt Hunter Schwarz anhand des Neubaus des japanischen Bahnhofs in Arida, der in unglaublichen sechs Stunden abgeschlossen werden konnte, also in nur einer einzigen Nacht. Zum vergleich: vergleichbare Arbeiten in Deutschland dauern Monate.Maarten Dalmijn: The Explosive Nature of 'Big Bang' Rewrites
Dass Big Bang-Releases neu entwickelten problematisch sind, sollte mittlerweile allgemeines Verständnis sein. Maarten Dalmijn fügt dieser Erkenntnis noch eine weitere Dimension hinzu: auch das komplette Umschreiben einer bestehenden Anwendung mit anschliessender Big Bang-Ablösung des Bestandssystems ist riskant. Zwar sind die Nutzerbedürfnisse (hoffentlich) bekannt, das Wissen um die inneren Zusammenhänge ist aber schon schnell zu gross um sich noch verlässlich planen zu lassen.Luís Gonçalves: Scaling Startups - The Ultimate Guide For Founders
Wo würden agile Vorgehensweisen Sinn machen, wenn nicht in einem Startup? Und wodurch zeichnet sich ein Startup aus, wenn nicht durch starkes Wachstum? Dass es aber auch hier Differenzierungen gibt kann man bei Luís Gonçalves nachlesen, der vor allem den Unterschied zwischen Start Up und Scale Up hervorhebt. Der ist gravierender als man denken könnte (selbst wenn es eine Übergangsphase dazwischen gibt), so dass es sich lohnt, die beiden Typen zu kennen.Montag, 31. März 2025
Kommentierte Links (CXXV)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
