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 |
Lavaneesh Gautam: Behind the Bottlenecks - The Root Causes of Dependencies in Teams
In komplexen Umgebungen ist es sehr häufig so, dass sich hinter scheinbar einfachen Begriffen erstaunlich vielschichtige Sachverhalte verbergen. Dass das auch im Fall der Abhängigkeiten so ist arbeitet Lavaneesh Gautam sehr schön heraus: je nachdem ob sie durch berufliche Spezialisierung, geteilte Verantwortlichkeiten, Architektur-Muster oder Organisationsdesign verursacht werden, können sie sehr unterschiedliche Formen annehmen und unterschiedliche Behandlung erfordern.Roman Pichler: Setting up Product Teams for Success
Seit einigen Jahren haben die Konzepte von agiler Entwicklung und Product Thinking begonnen sich mehr und mehr zu überlagern. Dieser Artikel von Roman Pichler könnte daher auch "Setting up agile Teams for Success" heissen, die relevanten Parameter sind die gleichen. Wie immer sollte man das Ganze nicht unreflektiert als Blaupause benutzen, es ist aber einguter Denkanstoss.Militarnyi: Saab Develops Anti-Aircraft System in Record 84 Days
Ich bin schon lange überzeugt, dass agiles Arbeiten überall möglich ist, wenn der Sense of Urgency gross genug ist. Ein (drohender) Krieg ist leider gerade der unter diesen Treibern, der stark zunimmt. Als Ergebnis sehen wir plötzlich auch bei hochkomplexen Produkten Entwicklungsgeschwindigkeiten, die wir noch vor wenigen Jahren für unmöglich gehalten hätten. Und die Erfolgsmechanismen sind die bekannten: Modularität, Einfachheit des Designs und Entscheidungsspielraum der Umsetzungsmannschaft.Pawel Rola: Product Backlog Management with Upstream Kanban – From Chaos to Clarity
Mal wieder ein Klassiker. Pawel Rola erklärt sehr gut nachvollziehbar, wie die Nutzung von Kanban-Praktiken dafür sorgen kann, dass der Anforderungsmanagement-Prozess eines agilen Teams transparenter, expliziter und flüssiger werden kann. Und das sogar in Übereinstimmung mit den Vorgaben, die Scrum für ein Product Backlog macht - man muss es einfach nur horizontal abbilden statt vertikal, und alles passt wunderbar zusammen.John Ward: Agile marketing - The source of enterprise agility
Als Letztes etwas zum Nachdenken. John Wards Idee, dass Enterprise Agility (also die Fähigkeit einer Gesamtorganisation, sich schnell an Veränderungen anzupassen) nur unter Einbezierung des Marketings möglich ist, ist naheliegend. Das Marketing dabei als treibende Einheit zu sehen ist aber eher selten, diese Rolle haben meistens eher IT oder HR. Ein interessanter Ansatz.Freitag, 28. Februar 2025
Kommentierte Links (CXXIV)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
Luxshan Ratnaravi: The Six Agile People Manager Stances
Über die Jahre hat es immer wieder Artikel gegeben, die die verschiedenen Ausprägungen verschiedener agiler Rollen beschrieben haben: für den Scrum Master, den Product Owner, den Agile Coach, den Agile Leader, den Tech Lead, etc. Luxshan Ratnaravi hat aber tatsächlich noch eine weitere Rolle gefunden, mit der das anscheinend noch nicht passiert ist - den Agile People Manager. Was in dieser Galerie aber bemerkenswerterweise immer noch fehlt, sind die Developer.Jeff Sutherland: Mastering Agile Spikes for Smarter Resource Management
Anscheinend hat Jeff Sutherland, der Godfather of Scrum, eine neue Firma, JVS Management. Auf deren Seite findet sich diese Übersicht über den Einsatz von Spikes in Extreme Programming und Scrum, von ihrem Ursprung über ihre Einsatzmöglichkeiten bis hin zu einer Case Study. Wie in Sutherlands gesamtem Spätwerk finden sich auch kontroverse Passagen (z.B. "The PO assigns a fixed number of story points to a Spike"), insgesamt ist es aber ein guter Überblick.Salvatore Sanfilippo: We are destroying software
Ich bin nicht sicher, ob das, was Salvatore Sanfilippo hier verfasst hat, eine blosse Aufzählung ist, eine nüchterne Analyse, eine Anklageschrift, ein Rant, ein Wutausbruch oder eine kopfschüttelnd vorgetragene Betrachtung der über die Zeit aufgekommenen Missstände und Missverständnisse der modernen Softwareentwicklung. Vermutlich ist es von allem etwas, vorallem ist es aber eines: sehr schön minimalistisch im Layout. Das ist doch schon mal etwas.Doc Norton: Fixing Full-Stack Teams; Specialization Required
Was Doc Norton hier adressiert ist ein häufiges Missverständnis, dass das in agilen Unternehmen meistens angestrebte Full Stack-Prinzip umgibt - hinter diesem Konzept verbirgt sich nicht die Idee, dass jedes Mitglied eines solchen Teams in der Lage ist, alle für dieses Team anliegenden Aufgaben zu erledigen. Stattdesssen sind die Team-Mitglieder in Summe dazu in der Lage. Ist das einmal verstanden werden die Diskussionen um das Full Stack-Prinzip sofort weniger emotional.Charity Majors: Corporate “DEI” is an imperfect vehicle for deeply meaningful ideals
Der Zeitgeist bewegt sich gerade nicht unbedingt in die Richtung von DEI (Diversity, Equity and Inclusion) - und das nicht nur zu Unrecht, sicher ist dieser Ansatz an einigen Stellen zu weit getrieben worden. Dass er aber grundsätzlich gut ist arbeitet Charity Majors hier sehr schön heraus, einschliesslich der Widerlegung einiger weit verbreiteter Missverständnisse.Freitag, 31. Januar 2025
Kommentierte Links (CXXIII)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
David Pereira: The Refactoring Guide for PMs Tired of Endless Tech Discussions
Eine der klassischen Herausforderungen, an denen (nicht nur agile) Entwicklungsteams scheitern, ist die Erklärung von Refactoring für Menschen ohne IT-Hintergrund. Wer mal wieder in dieser Situation ist, kann sich an diesen Artikel von David Pereira halten. In ihm wird nicht nur das Konzept erklärt, sondern auch warum es wichtig ist, wie mayn es falsch machen kann, wie man es richtig machen kann, wann man es machen sollte und was typische Formen von Refactoring sind.Jeff Gothelf: OKRs for Organizational Agility
Auf die Gefahr hin, versehentlich in die Falle von Maslows Hammer zu laufen - man kann Objectives und Key Results (OKRs) eigentlich für so gut wie alles benutzen. Jeff Gothelf zeigt hier ein eher selten verwandtes Einsatzgebiet auf: die Verwendung von OKRs für agile Transitionen (oder wie er es nennt, organisatorische Agilität). Im Wesentlichen geht es dabei darum, Reaktions- und Durchlaufzeiten messbar zu verkürzen. Schlicht, aber wirkungsvoll.Erik de Bos: Using the Flow Channel to Measure Team Effectiveness
Neben dem Durchfluss von zu erledigenden Aufgaben durch ein Verarbeitungssystem hat der Begriff Flow im Arbeitskontext eine zweite Bedeutung: den idealen Zustand, in dem eine Person oder ein Team werder überfordert noch unterfordert ist, und daher hochmotiviert und leistungsbereit. Erik de Bos differenziert das mit Hilfe des so genannten Flow Channel aus, in dem ein Team versuchen kann, dauerhaft zu bleiben, um optimale Ergebnisse erbringen zu können.Marty Cagan: The Product Model and Agile
Dieser Blogpost hier ist durchaus erstaunlich, da sein Verfasser, Produktmanagement-Thought Leader Marty Cagan, über lange Zeit dafür bekannt war, öffentlich schlecht über agile Rollen und Frameworks zu sprechen. Irgendetwas scheint seine Meinung geändert zu haben, denn auf einmal findet er es nicht nur grundsätzlich ok wenn agil gearbeitet wird, er erkennt sogar an, dass Agile Coaches dazu einen wertvollen Beitrag leisten können - was er allerdings vor allem im Delivery-Bereich sieht.Sebastian Sigl: High-Performing Teams Focus On These 4 Areas to Remain Successful
Zugegeben, Sebastian Sigls Überschrift klingt auf den ersten Blick so, als würde als nächstes eine Plattitüden-Sammlung folgen. Tatsächlich ist seine Übersicht aber durchaus sinnvoll, denn er zählt nicht nur die vier Bereiche auf (Anpassungsfähigkeit, Zielsetzung, Psychologische Sicherheit und Feedback), sondern er zeigt auch Fehler auf die man vermeiden sollte, wenn man hier besser werden möchte - darunter auch einige unerwartete, wie z.B. ein zu grosses Vertrauen in Expertenwissen.Dienstag, 31. Dezember 2024
Kommentierte Links (CXXII)
|
| Grafik: Pixabay / Brian Penny - Lizenz |
Martin Fowler: Continuous Integration
Agile Produktentwicklung kann durch Methoden wie Scrum, Kanban und die Skalierungsframeworks einfacher werden, mindestens genau so wichtig sind aber bestimmte technische Aspekte. Martin Fowler, einer der Verfasser des Manifests für agile Softwareentwicklung, hat sich mit Continuous Integration einen davon herausgesucht und in diesem epischen Essay (über 80.000 Zeichen!) alles was man zu diesem Thema wissen sollte zusammengefasst - bzw. fast alles, aber für alles andere enthält er Buchempfehlungen und weiterführende Links. Für jeden der bei diesem Thema mitreden möchte, eine absolute Empfehlung.Donald 'Mark' Haynes: An Agile focus on minimalism
Das was Mark Haynes hier hervorhebt ist eine zu oft vergessene Wahrheit: wer mit agilem Arbeiten erfolgreich sein will, der muss in der Kunst des Minimalismus geübt sein, da grosser Umfang und komplizierte Zusammenhänge sehr schnell zu Schwerfälligkeit und Langsamkeit führen. Was man bei ihm lernen kann ist, dass dieser Minimalismus nahezu überall anwendbar ist - bei Prozessen, bei Entwicklungspraktiken, in der Software-Architektur und in Anforderungen. Was daraus folgt: bei agilen Transitionen sollte es weniger um das Hinzufügen von Rollen, Regeln, Prozessen und Praktiken gehen und mehr darum, möglichst viele bestehende abzuschaffen.
Christiaan Verwijs: Why Teams Need Composition Autonomy
Das hier ist eine kontroverse, aber interessante Meinung. Christian Verwijs ist davon überzeugt, dass ein wesentlicher Aspekt autonomer Teams sein sollte, dass sie ein Mitspracherecht bei der Frage haben sollten, wer ihnen angehört. Wichtig für das Verständnis seiner Ausführungen ist dabei, dass er die Gewährung dieser Mitsprache-Rechte nicht als Alles oder Nichts-Entscheidung sieht, sondern dazwischen eine Skala definiert, auf der unterschiedliche Teams unterschiedlich eingeordnet werden können (und auf der sie sich auch noch weiter hin- und herbewegen können).Jeff Gothelf: Aligning, Not Cascading, OKRs with an OKR Lineage
Nachdem die Objectives and Key Results von der agilen Bewegung "adoptiert" wurden, stellte sich bei ihnen in kürzester Zeit die gleiche Frage, deren Beantwortung auch von den anderen agilen Frameworks verlangt wurde: wie funktioniert das im grossen Massstab? Jeff Gothelf hat sich den beliebtesten OKR-Skalierungsansatz, die "kaskadierenden OKRs" angeschaut und für nicht gut befunden, hat aber auch eine bessere Alternative im Angebot: die Lineage OKRs (Abstammungs-OKRs). Statt Ziele von oben nach unten durchzureichen, werden sie hier dezentral erstellt, müssen dabei aber einen Bezug zur nächsthöheren Ebene aufweisen können.Melissa Perri: Building a Great Product Management Organization
In Teilen der US-amerikanischen Tech-Szene hat mittlerweile der Begriff "Product" (bzw. Product Management) den Begriff Agile verdrängt oder assimiliert. Dieser Artikel von Melissa Perri (einer der bekanntesten Product Management-Vordenkerinnen) zeigt gut auf, wie dort eine produktorientierte Organisation verstanden wird, was sie beinhalten sollte und woran man Dysfunktionen erkennt. Ein Vergleich zu den üblichen Agile-Talking Poin ist durchaus interessant, da man sowohl Gemeinsamkeiten als auch Unterschiede erkennen kann (z.B. die Thematisierung von Karrierepfaden).Benjamin Ross Hoffmann: Systems of Bullshit Work
Dieser Text ist ein bisschen Meta, da sich Benjamin Ross Hoffmann in ihm auf das Buch Bullshit Jobs bezieht, in dem der Ethnologe David Graeber einen Grossteil der heutigen Jobs als unnötig bezeichnet. Hoffmann differenziert das aus, indem er erklärt, durch welche Faktoren es zum Entstehen dieser Jobs kommt. Wer schon einmal fehlgeschlagene agile Transformationen erlebt hat wird vieles aus denen hier wiederfinden, z.B. im achten Beispiel: Your job might be to perform a ritualized imitation of a service that would be useful if genuine. Es dürfte den einen oder anderen Scrum Master geben, auf den das zutrifft.Maarten Dalmijn: The Era of Copy-Paste Agile Is Over
Maarten Dalmijn hat sich im vergangenen Jahr einen Namen damit gemacht, den aktuellen Zustand der agilen Bewegung, bzw. des agil industriellen Komplex, wortgewaltig zu kritisieren. Auch an dieser Stelle macht er damit weiter, diesesmal mit der Hypothese, dass die gängigen agilen Frameworks den Widerstands- und Beharrungskräften grosser Organisationen nicht gewachsen sind und darum fast zwangsläufig scheitern müssen. Diese Ansicht (und die von ihm vorgeschlagene Alternative) muss man nicht teilen, als provokanter Denkanstoss ist sie aber durchaus wertvoll.Marty Cagan: Transformation as a Project
Eines der grossen Mantras der agilen Bewegung und der Produktorientierungs-Bewegung ist, dass sie weg von der projektbasierten Organisationsform wollen, die in den meisten grossen Organisationen der Standard ist. Und beide leiden unter der tragisch-ironischen Situation, dass sie mit ansehen müssen, dass viele Versuche ihre Ansätze einzuführen dann doch wieder als Projekt durchgeführt werden, mit all den Problemen die damit verbunden sind. Marty Cagan thematisiert diese Dysfunktion ebenfalls, hat aber auch Ideen wie es besser gehen kann: durch kleine Anfänge, schnelle Lernzyklen, asynchrone Fortschritte und kontinuierliche Optimierung. Wie auch sonst?, möchte man fragen.John Cutler: Why Orgs Become Too Tall
Dass John Cutler seinen Ruf als ausgezeichneter "Systems Thinker" nicht von ungefähr hat, wird (spätestens) aus diesem Blogpost klar. Ausgehend von der weit verbreiteten Beschwerde, dass viele Organisationen zu gross und zu bürokratisch sind, analysiert er, welche sich wiederholenden Muster dafür sorgen, dass es immer wieder dazu kommt. Das ist zum einen erhellend, zum anderen aber auch hilfreich, da es aufzeigt, an welchen Stellschrauben gedreht werden kann, um Organisationen wieder zu verschlanken und Bürokratie abzubauen.Nigel Baker: What Has Gone Wrong - And How To Fix It.
Apropos Systems Thinking: in diesem Blogpost von Nigel Baker findet sich einiges davon (und daneben auch Humor und Polemik, was das Ganze sehr lesenswert macht). Das Thema, das er derartig beleuchtet, ist (ähnlich wie weiter oben bei Maarten Dalmijn) der Zustand der agilen Bewegung. Wer dieses recht zähe Thema gerne launisch und unterhaltsam aufbereitet haben möchte, ist an dieser Stelle richtig.Freitag, 27. Dezember 2024
Kommentierte Links (CXXI)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Liam Kane: Continuous Improvement – The Kaizen Way
Dass agile Produkt- und Softwareentwicklung ihren Ursprung im Lean Management hat ist unter Methodikern ein Allgemeinplatz, was das im Konkreten bedeutet bleibt aber häufig unklar. Liam Kane leistet hier Aufklärungsarbeit und hebt zwei zentrale Aspekte hervor: zum einen ist das Verbesserungsziel die Steigerung der Wertgenerierung, statt wie im klassischen Management der Produktivität, zum anderen erfolgt die Verbesserung kontinuierlich in kleinen Schritten statt in seltenen, aber dafür grossen Schüben. Gut auf den Punkt gebracht.Willem-Jan Ageling: 7 Hacks to Scale Agile Without Overly Complicated Frameworks
Diese Liste von Willem-Jan Agelings sieben "Hacks", mit denen man ohne übermässig komplizierte Frameworks Agilität im grossen Massstab erreichen kann, ist eine interessante Zusammenstellung, und das alleine deshalb weil sie sowohl Praktiken als auch Organisationsprinzipien als auch Haltungen enthält - in den meistens derartigen Zusammenstellungen kommt nur jeweils eine dieser Kategorien vor. Wer sich mit den agilen Skalierungsframeworks auskennt wird hier sowohl Elemente von LeSS und Nexus als auch von SAFe wiedererkennen. In gewisser Weise der Versuch ein "Best of" zu extrahieren.Doc Norton: Frequent releases improve outcomes
In der agilen Community dürfte Doc Norton mit seiner Aussage, dass häufige Releases zu besserer Ergebnisqualität führen, offene Türen einrennen, in klassisch geprägten Unternehmen herrscht allerdings immer noch die gegenteilige Meinung vor. Da diese Ablehnung meistens auf der nachvollziehbaren Sorge beruht, Geschwindigkeit nur auf Kosten der Qualitätssicherung erreichen zu können, geht Norton auch darauf ein, mit einer wichtigen Klarstellung - natürlich muss zuerst an dieser gearbeitet werden, und zwar so, dass auch sie in hoher Frequenz nötig ist. Iccha Sethi: Tying Engineering Metrics to Business Metrics
Dieser Artikel ist wirklich interessant, da er sich eines weit verbreiteten Problems annimmt: sowohl Business als auch IT verfügen über Metriken, mit deren Hilfe sie Fortschritte und Ergebnisse überprüfen, es sind aber in den meisten Fällen keine gemeinsamen, sondern nur solche, die jeweils auf nur einer Seite verwendet werden und die der anderen als wenig nachvollziehbar oder wenig wichtig erscheinen. Dadurch dass sie hier zueinander in Beziehung gesetzt und miteinander verbunden werden, wird es einfacher gemeinsame Ziele zu definieren und auf sie hinzuarbeiten.Charity Majors: “Founder Mode” and the Art of Mythmaking
Eines der grossen Buzzwords des Jahres 2024 ist "Founder Mode" gewesen, ein Management-Ansatz, der durch Brian Chesky, einen der Gründer von AirBnB, erfunden und popularisiert wurde. Er stellt so ziemlich das Gegenteil aller anderen modernen Management-Ansätze dar, da er sowohl ein mittleres Management als auch crossfunktionale, empowerte, autonome Teams ablehnt und stattdessen alles auf eine einzige alleinentscheidende Person (den Founder) ausrichtet. Da es Chesky auf diese Art gelungen ist, sein Unternehmen aus der Krise zu führen, ist dieses Vorgehen zumindest eines mit dem man sich beschäftigen sollte, um darüber mitreden zu können. Charity Majors hat das dankenswerterweise gemacht, indem sie das Interview, in dem Chesky seinen Founder Mode vorstellt, ausführlich analysiert hat. Das Kurz-Fazit: Chesky hat die Schieflage seines Unternehmens nicht nur behoben, er hat sie vorher auch selber verursacht. Sein Management-Ansatz ist daher mit Vorsicht zu betrachten, selbst wenn er auch sinnvolle Elemente enthält.Samstag, 30. November 2024
Kommentierte Links (CXX)
|
| Grafik: Pixabay / Geralt - Lizenz |
Joe Foley: Delete to Accelerate: Boulders, rocks, pebbles - An Agile model that scales
Kurz bevor ich diesen Artikel von Joe Foley gelesen habe, habe ich selber den sehr ähnlichen Ansatz Rock, Pebbles, Sand bei einem Team meines aktuellen Kunden eingeführt. Was beiden gemeinsam ist, ist, dass sie dem häufigen Problem begegnen, dass vorgegebene Planungszyklen (Quartale, Sprints, etc.) nicht vollständig verplanbar sind. Statt in der verbleibenden Zeit mit der nächstwichtigsten Arbeit zu beginnen (die im Zweifel nicht abschliessbar ist), wird diejenige unter den nächstwichtige Aufgaben gewählt. die im verbleibenden Zyklus abschliessbar ist. Ein elementarer Unterschied.Cliff Berg: Empowerment, Not Self-Organization
Es ist eine Debatte die so alt ist wie die agile Bewegung: bedeutet Selbstorganisation nur, dass sich ein bereits zusammengestelltes Team selber entscheidet, auf welchem Weg es ein vorgegebenes Ziel erreicht, oder sollte es sich auch selbst zusammenstellen und sich selbst einen Auftrag suchen dürfen? Cliff Berg plädiert hier für die erste Variante, und zwar nicht aus ideologischen Gründen, sondern aus Pragmatismus. Bei allen Vorteilen ist das Risiko von Konflikten und Dyfunktionen in vielen Fällen zu hoch für das nötige Investment. Ich kann da nicht widersprechen.Sean Gödeke: How I ship projects at big tech companies
Was Sean Gödeke hier aufbringt ist auf den ersten Blick ein technisches Thema - wann ist eine neu entwickelte Funktion "verschifft" (im IT-Englisch: für die Endkunden-Nutzung verfügbar gemacht)? Seine auf den ersten Blick überraschende Definition: nicht dann, wenn das prozessual abgeschlossen ist, sondern erst dann wenn das Management und andere Stakeholder mit dem Ergebnis zufrieden sind. Ist das nicht der Fall, werden auch einwandfrei funktionierende Auslieferungen wieder und wieder überarbeitet werden müssen. Ein guter Impuls um die Definition of Done zu überdenken.Paweł Huryn: 10 Sources of Waste in Product Management
Zum Thema der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten aus dem Toyota Production System habe ich schon eine ganze Artikelserie geschrieben, aber auch ich kann aus Paweł Huryns Übertragung auf das Produktmanagement noch neue Erkenntnisse ziehen. Ich glaube sogar, dass es egal ist wo und in welcher Form man sie einsetzt - sobald man sich ernsthaft mit dem Thema Ressourcenverschwendung beschäftigt, wird man überall Verbesserungspotentiale finden können.Pim de Moree: Bayer's Bold Bet: How a 160-Year-Old Giant is Liberating 100,000 People
Bei der aktuellen Konzern-Transformation der Bayer AG bin ich mir unsicher: in der Theorie klingt alles richtig und sinnvoll, was man von Beteiligten aus dem Unternehmen hört, klingt dagegen mitunter eher planlos und willkürlich. Andererseits entspräche das auch wieder den typischen Abwehrreaktionen von Menschen, denen ihre Komfortzone genommen wird. In diesem Text von Pim de Moree steht wieder die positive Seite im Vordergrund. Wie es wirklich ist, wird man vermutlich erst in einigen Jahren wissen, bis dahin ist es eine spannend zu beobachtende Live-Fallstudie.Donnerstag, 31. Oktober 2024
Kommentierte Links (CXIX)
|
| Grafik: Pixabay / Geralt - Lizenz |
John Utz: Delete to Accelerate: Transforming Your Product with a Reverse Roadmap
Weniger ist mehr, das gilt in vielen verschiedenen Kontexten, aber ganz besonders im Umfeld agiler Produktentwicklung. Kleinere Anforderungen lassen sich schneller umsetzen, kleine Anwendungen einfacher umbauen oder erweitern, kleinere Systeme einfacher betreiben. Um in diesen Zustand zu kommen, empfiehlt John Utz eine zweite, parallele Roadmap. Während in der ersten das Hinzufügen von Features, etc. im Mittelpunkt steht, konzentriert sich die zweite auf das Verschlanken. Doc Norton: Opportunity Solution Trees
Ich bin grosser Fan davon, Change Management in Form von kleinen, überschaubaren Experimenten durchzuführen, aus ähnlichen Gründen wie den weiter oben genannten. Aber wie behält man dabei den Überblick über alle Ausgangshypothesen, Validierungsschritte und Ergebnisse? Doc Norton stellt mit dem Opportunity Solution Tree ein mögliches Werkzeug vor, in dem man nachvollziehen kann welche Experimente mit welchen Ergebnissen stattgefunden haben.Stefan Kühl: Disruption
Mal wieder ein "akademischer Rant" von Stefan Kühl, der als Soziologe eine eigene und distanzierte Sicht auf Manager, Berater und ihre Moden hat. Diesesmal ist die Postulierung einer im Vergleich zur Vergangenheit angeblich einzigartigen Disruption Gegenstand seiner Kritik, und wer seine Beiträge kennt, der weiss auch bereits, wie sein Fazit lautet: so einzigartig ist die aktuelle Situation gar nicht. Es sind andere Disruptionen als früher, aber keine schwerwiegenderen.Maarten Dalmijn: Are Scrum Masters Too Much Overhead? / Are Product Owners Too Much Overhead?
In diesen beiden Artikeln hat es Maarten Damijn erkennbar darauf angelegt, die Scrum-Community ein bisschen zu provozieren, denn er stellt nicht nur die Notwendigkeit der beiden Rollen Scrum Master und Product Owner in Frage, sondern fragt darüber hinaus, ob es sich bei ihnen nicht sogar um Overhead handelt. Die Antwort gibt er selbst: es kommt darauf an. Womit er erkennbar hadert ist, dass man sie in solchen Fällen zwar weglassen kann, das Ergebnis dann aber nicht mehr Scrum heissen darf.Lisa Crispin: The Agile Testing Quadrants
Zuletzt ein Heads up für die agile QA-Community. Mit den agilen Test-Quadranten verfügt sie über eines der bekanntesten "agilen Werkzeuge", das schon 2008 durch das Buch Agile Testing bekanntgemacht wurde. Mit Lisa Crispin macht eine der beiden Autorinnen hier darauf aufmerksam, dass die meistens verwendete Version nicht mehr die aktuelle ist, da sie weiterentwickelt und verbessert wurde. Vielleicht ein Grund für einen schnellen Kontrollblick in den eingenen methodischen Werkzeugkoffer.Montag, 30. September 2024
Kommentierte Links (CXVIII)
|
| Grafik: Pixabay / Geralt - Lizenz |
Pim de Morree: The Anatomy of a Self-Managing Organization - Why Networks Trump Hierarchies
Die Idee einer netzwerlartigen Organisation wird immer wieder angeführt, wenn diskutiert wird, wie auch im grossen Masstab Agilität und Flexibilität möglich sein können, die dabei immer wieder gestellte Frage ist aber die, ob das auch in der Realität funktionieren kann. Pim de Morree kann diese Zweifel ausräumen indem er verschiedene grosse und mittelgrosse Unternehmen nennt, in denen bereits jetzt so gearbeitet wird, von Haier über Indaero, Buurtzorg und Vertica bis hin zu W.L. Gore. Derartige Praxisbeispiele können nicht nur Zweifel zerstreuen, sie bringen die Diskussion auch wieder zum richtigen Thema zurück: was müssen wir tun um selbst so arbeiten zu können? Erik de Bos: The Puzzle of Self-Organisation
Dieser Artikel von Erik de Bos enthält mit Enrise ein weiteres Beispiel für eine Netwerk-Organisation, konzentriert sich aber auf ein anderes Thema: was muss für wirkliche Selbstorganisation auf Teamlevel eigentlich gegeben sein? Der wichtigste unter den von ihm genannten Faktoren ist dabei eine gewisse Erfahrung, was auch intuitiv Sinn ergibt - ohne Erfahrungwerte ist es schwer, Potentiale und Risiken einzuschätzen, und ihnen vorbeugend oder reaktiv zu begegnen. Dort wo Erfahrungen vorhanden sind (oder nach und nach entstehen) sind Effektivität und Erfolgsaussichten von selbstorganisierten Einheiten dagegen deutlich höher.Bob Galen: Shatters Anonymous
Ein bisschen Meta-Perspektive. Bob Galen sinniert hier über zwei viral gegangene Linkedin-Artikel des Disciplined Agile-Erfinders Scott Ambler, in denen dieser (mit grenzwertiger Wortwahl) der agilen Bewegung vorgeworfen hat, ihre eigene Position durch Dogmatismus, Kommerzialisierung und fehlende Lösungsorientierung untergraben zu haben. Galen stimmt dieser Beschreibung grundsätzlich zu, was ihm darin fehlt, ist aber eine wie auch immer geartete Lösungsorientierung. Er ruft daher alle Meinungsführer der agilen Bewegung dazu auf, die zu erarbeiten. Ein Aufruf dem man sich nur anschliessen kann.Prateek Singh: On Deterministic Fixed-Length Timeboxes
Ein Artikel, der in gleich zweifacher Hinsicht interessant ist. Zum einen, weil Prateek Singh in ihm die Probleme, die mit festen Deadlines oder festen Sprintlängen verbunden sind, gut herausarbeitet. In komplexen Umfeldern lässt sich eine Fertigstellungsdauer nicht seriös prognostizieren, dafür gibt es zu viele Unbekanntheiten und Dynamiken. Zum anderen ist aber interessant, wie wenig er über die Praktiken zu wissen scheint, mit denen in den Iterativen Ansätzen damit umgegangen wird (vereinfacht gesagt mit variablem Scope eines fixen Ziels). Mit diesem Wissen hätte er (der hier stellvertreten für die Kanban-Community steht) Scrum noch besser kritisieren können.Charles Lambdin: What Is Cost of Delay?
Zuletzt etwas Grundsätzliches. Charles Lambdin nimmt sich eines oft diskutierten aber z.T. sehr unterschiedlich verstandenen Konstrukts an, der Verspätungs-Kosten (Cost of Delay). Zu den verschiedenen interessanten Aspekten auf die er dabei eingeht gehört u.a., dass es auch negative Verspätungskosten gibt (die er mit Benefits of Delay treffender benennt) und dass es trotz einer letztendlichen Unbezifferbarkeit gute Gründe dafür gibt, es trotzdem zu versuchen. Lesenswert.Samstag, 31. August 2024
Kommentierte Links (CXVII)
|
| Grafik: Pixabay / Geralt - Lizenz |
Jeff Gothelf: How to build a high-performance culture without culling the herd
Um zu zeigen, wie man zu einer Hochleistungskultur kommt, kann es schon ausreichen, das Gegenteil zu beschreiben - und genau das tut Jeff Gothelf in seinem Artikel zunächst. Förderung von konkurrierenden Einzel-Leistungen, eine Angstkultur durch ständige Kündigungs-Androhungen und ein Nicht-Einschreiten gegen toxisches Management-Verhalten können jede Leistungbereitschaft nachhaltig zerstören. Umgekehrt sind eine Belohnung guter Zusammenarbeit, ein respektvoller Umgang mit den Mitarbeitern und die Beförderung entsprechend handelnder Menschen in Management-Positionen hochgradig förderlich für Hochleistungen. Eigentlich sollten alle Punkte dieses Artikels Selbstverständlichkeiten sein.Nick Brown: Escaping Story Points with Right-sizing
Ich muss gestehen, dass mich die vor allem im Kanban-Umfeld anzutreffende Community, die an der durch historische Daten unterfütterten Prognose von Umsetzungsdauern arbeitet, zutiefst fasziniert. Hier ist alles gegeben, was man sich als überzeugter Agilist wünscht: empirisches Vorgehen, differenzierte Einschätzungen, Visualisierung von Daten, Wiederholbarkeit und Nachvollziehbarkeit des Vorgehens, etc. Und jemandem wie Nick Brown nimmt man es auch ab, dass er mit voller Überzeugung hinter dem steht was er hier schreibt. Das Einzige was mir noch fehlt, damit aus Faszination Begeisterung wird - ich möchte es einmal funktionieren sehen.Charles Lambdin: A Persona How-To
Personas gehören zu den sinnvollsten Werkzeugen, die man bei der Produktentwicklung benutzen kann, vor allem dort wo echte Anwender nur schwer zu erreichen sind. Das Risiko dabei ist aber, dass diese Beschreibungen idealisierter Nutzer zu sehr auf Bauchgefühl beruhen und damit kognitiven Verzerrungen unterliegen. Charles Lambdig zeigt auf wie es besser geht, indem er einen mehrstufigen Prozess modelliert, in dem nach und nach aus Marktforschungsdaten validere Personas entstehen. Das ist natürlich aufwändiger als blosses "Empathiesieren", bringt aber auch deutlich bessere Ergebnisse.Matt Philip: Team size is a polarity to be managed, not a problem to be solved
Im Grunde sagt die Überschrift dieses Blogposts von Matt Philipp alles Wichtige bereits aus: die Grösse eines Teams (egal welche das ist) ist erstmal weder gut noch schlecht, selbst wenn das in der agilen Community mit ihrer Fixierung auuf Teamgrössen von fünf bis zehn Personen mehrheitlich anders gesehen wird. Sein pragmatischer Ansatz besteht (verkürzt gesagt) aus drei einfachen Fragen, die man sich stellen kann: welche Vorteile bringt mir eine bestimmte Teamgrösse, welche Nachteile bringt sie mir, und in welcher Relation stehen diese beiden Zahlen zueinander. Ein wunderbarer Weg um diese Diskussion zu versachlichen und neutral bewertbar zu machen.Melissa Suzuno: Why Ramsey Solutions Rotates Engineers in Their Product Trios
Als letztes noch ein weiterer Kontrapunkt zu einer verbreiteten starken Meinung - der, dass erfolgreiche (agile) Teams über einen möglichst langen Zeitraum stabil (d.h. in ihrer Zusammensetzung unverändert) bleiben sollten. Am Beispiel eines echten Unternehmens zeigt Melissa Suzuno auf, dass sogar das Gegenteil richtig sein kann, wenn es einen Zweck gibt, der sich so am besten erreichen lässt. Auch hier wieder - eigentlich eine Selbstverständlichkeit. Eigentlich.Mittwoch, 31. Juli 2024
Kommentierte Links (CXVI)
|
| Grafik: Pixabay / Geralt - Lizenz |
Carlos Arguelles: How Amazon and Google view CI/CD in an entirely different way
Je weiter man vom Silicon Valley entfernt ist, desto mehr neigt man dazu, die dortigen grossen agilen Vorzeigefirmen zu glorifizieren und zu mystifizieren. Carlos Arguelles' Erfahrungsberichte aus seiner Zeit bei Amazon und Google wirken in diesem Zusammenhang wie ein Realitätsschock, schliesslich beschreiben sie, dass in beiden Unternehmen Vorgehensweisen verbreitet sind, die eigentlich nicht State of the Art sind - geringe Testabdeckung bei Amazon, Flaky Tests bei Google. Die sehr unterschiedlichen Wege zur Kompensierung dieser Probleme zeigen, dass es nicht nur einen Weg zu technischer Exzellenz gibt. Es gibt mehrere, die nur in sich konsistent sein müssen. Vladimir Kalmykov: How to Use an MVP Razor to Build Features
Die Dabatte darüber, was eigentlich ein MVP ist, ist Jahrzehnte alt und wird vermutlich noch Jahrzehnte weitergehen. Und selbst wenn man sich auf eine der vielen Varianten festgelegt hat bleibt die Frage, wie man in der Praxis Anforderungen und Systeme so schneiden kann, dass das Ergebnis (im positiven Sinn) "minimal" ist. Vladimir Kalmykov führt zu diesem Zweck das Ausschlussmodell des "MVP Razor" ein, das aus einer schlichten Frage besteht: "Kann man das Produkt oder Feature noch stärker verkleinern, ohne seine Grundfunktionalität einzuschränken?" Das scheint zunächst banal, anhand anschaulicher Beispiele zeigt Kalmykov aber auf, dass mehr dahinter steckt als man zunächst denken könnte.David Pereira: 12 Product Principles
Zu den Büchern in meinem immer länger werdenden "Lese-Backlog" gehört auch Untrapping Product Teams von David Pereira, über das ich schon viel Gutes gehört habe. In diesem Artikel greift er einen zentralen Inhalt seiner Buches auf, die 12 Produkt-Prinzipien. Aufgeteilt in die vier Kategorien Strategy, Discovery, Delivery und Collaboration ergeben sie ein kompaktes Set an Leitprinzipien, die einem Team dabei helfen können, nicht versehentlich in eines der verbreiteten Antipattern abzurutschen. In einem an den Artikel angehängten Kurzinterview durch Paweł Huryn werden sie danach noch weiter vertieft und eingeordnet. Vielleicht sollte ich die Reihhenfolge meiner noch ungelesenen Bücher ändern.Adrian Baker: Agile and deadlines - How to align Agile delivery with long-term planning
Zu den verbreiteten Mythen über agiles Arbeiten gehört, dass es nicht in Kontexten funktioniert, in denen es Deadlines und feste Planungshorizonte gibt. Adrian Baker entkräftet dieses Vorurteil nachhaltig, indem er eine ganze Reihe von Ansätzen aufzählt, mit denen es doch gelingen kann. Was seine Ausführungen von vielen anderen abhebt: statt sich in wolkige Richtlinien und abstrakte Konzepte zu flüchten, hebt er konkrete Praktiken und Funktionen aus Scrum, SAFe, XP, Day One und (Huch!) Jira hervor, die man zu diesem Zweck nutzen kann. Das ist Praxisnähe im besten Sinne des Wortes, selbst wenn es bei dem einen oder anderen "agilen Puristen" zu Herzrasen führen mag.Itamar Gilad: The Lifecycle of Goals - Research, Discover, Deliver, Monitor
Zum Abschluss einige Gedanken zum Thema Zielsetzungen. Anders als oft angenommen sind die in der (agilen) Produktentwicklung nicht zwangsläufig fix und unveränderbar, sondern sie können (und müssen) sich mit der Zeit ändern. In Analogie zu den Produkt- und Projekt-Lebenszyklen entwirft Itamar Gilad hier den Lebenszyklus der Entwicklungsziele, in dessen Verlauf sie nach und nach ihre Natur ändern. Der Begriff des "Moving Target" bekommt dadurch nochmal eine neue Bedeutungs-Dimension.Samstag, 29. Juni 2024
Kommentierte Links (CXV)
|
| Grafik: Pixabay / Geralt - Lizenz |
Maarten Dalmijn: Scrum Alternatives: SCREAM!
Die Mitte der 2010 Jahre ist im Rückblick die große Zeit der Scrum-Verschlimmbesserungen gewesen Ich selbst habe mich seinerzeit über einige dieser (inzwischen zu Recht in Vergessenheit geratenen) Konstrukte aufgeregt, namentlich über Reliable Scrum, Ultimate Scrum, Secure Scrum und Autoscrum. Maarten Dalmijn hat jetzt irgendwo einen weiteres derartiges Framework ausgegraben, dem ohne erkennbare Ironie der Name SCREAM! gegeben wurde, und das im Gegensatz zu den anderen noch irgendwo im Einsatz ist - mit sehr überschaubaren Ergebnissen. Es ist ein kurioses Phänomen: nahezu alle Versuche, ein "verbessertes Scrum" zu erfinden, enden im Gegenteil. Pawel Huryn: How to Fix the Double Diamond of Design Thinking?
Ich habe eigentlich schon länger vor, irgendetwas zum Thema Design Thinking zu schreiben, zu dem ich ein sehr gespaltenes Verhältnis habe. Einerseitz ist der Ansatz von der Grundidee gut, andererseits endet seine Umsetzung regelmässig mit einem Wasserfall im Wasserfall, genauer gesagt mit einem Sequenzmodell innerhalb der Anforderungsphase. Pawel Huryn ist mir mit seinem Artikel jetzt zuvorgekommen, und das auch noch mit einem lobenswerten Spin. Statt sich einfach nur über das zu beschweren, was problematisch ist, macht er Vorschläge dazu, wie es besser ginge: durch mehr Feedback-Schleifen, Continuous Delivery und zusätzliche Erkenntnisquellen. Das sind gute Ideen.Danny Faught: Beyond Scrum
Eine häufige Entwicklung (und eine, die ich auch absolut ok finde) ist die, dass Teams, die eine Zeit lang nach Scrum gearbeitet haben, irgendwann anfangen dessen Regeln an ihre Bedürfnisse anzupassen. Danny Faught berichtet in seinem Erlebnisbericht seiner letzten Einsätze von einigen Veränderungen, die auch ich immer wieder erlebt habe: aus den fest getakteten, auf ein einziges Ziel focussierten Sprints wird ein Flow-orientierter Durchlauf, aus dem Versuch Aufwände zu schätzen werden Durchsatz-Zahlen, dazu kommen andere Elemente aus Kanban und XP. Das was die Fälle aus diesem Bericht von vielen anderen unterscheidet ist ihre Ehrlichkeit - es wird auch nicht so getan, als würde das Ergebnis noch Scrum sein. Es ist irgendetwas anderes geworden.Elaine Lin Hering: How to Get Your Team to Actually Speak Up
Ein weiterer Schritt heraus aus der Scrum Bubble, diesesmal einer, in dem es um eine der absoluten Grundlagen und Vorbedingungen für agiles Arbeiten geht: darum, dass die Mitarbeiter bereit sind, offen, ehrlich und proaktiv zu kommunizieren. Die Ausführungen von Elaine Lin Hering zu diesem Thema haben viel mit psychologischer Sicherheit zu tun, aber auch mit ehrlichkeit, Berechenbarkeit, Einbeziehung und Unterstützung. Das ganze mit einer Management-Perspektive im Hinterkopf, also darauf bezogen, was ein Manager machen kann, um die erwähnten Effekte herbeizuführen.Kent Beck: Minimum Viable Product revisited
Das es sehr unterschiedliche Verständnisse der Natur eines Minimum Viable Product (MVP) gibt, hatte ich irgendwann bereits aufgeschrieben. Auch Kent Beck, einer der Erfinder des Extreme Programming, hat seine Definition, die sehr der aus dem Lean Startup ähnelt. Ein MVP ist in seiner Sicht das Ergebnis der kleinstmöglichem Umsetzungsarbeit (→ Minimum), mit der man einen belastbaren Lerneffekt (→ Viable) zu dem Kundenanliegen an dem man arbeitet (→ Product) gewinnen kann. Mit anderen Worten: kein MVP to earn", sondern ein "MVP to learn". Auch aus meiner Sicht die spannendere und oft zielführendere Variante.Freitag, 31. Mai 2024
Kommentierte Links (CXIV)
|
| Grafik: Pixabay / Geralt - Lizenz |
Christiaan Verwijs: Why Science Is Essential To Professionalize Our Community
Es ist einer der grossen Schwachpunkte der agilen Community: es gibt sehr viele starke Meinungen über das für und wieder der verschiedenen Frameworks und Praktiken, nur in den seltensten Fällen sind sie aber durch belastbare und reproduzierbare Empirie validiert. Christiaan Verwijs erklärt warum das problematisch ist, zeigt auf welche Möglichkeiten es gibt, die eigenen Ansichten mit Fakten zu untermauern und weist auf ein grundlegendes Problem hin: anders als in anderen Berufen gibt es bei Product Ownern, Scrum Mastern, Agile Coaches keine nichtkomerziellen Organisationen, die für die Einführung und Beibahaltung derartiger Arbeitsweisen sorgen könnten.Benjamin Huser-Berta: Limit Work in Progress without Work In Progress Limits (Teil I, Teil II)
Kanban ist vermutlich das am häufigsten missverstandene agile Framework (die Debatte ob es agil oder lean ist sparen wir uns an dieser Stelle). Die meisten Menschen verwechseln es mit dem blossen Kanban-Board, und selbst die, die verstehen, dass mehr dahinter steckt, kennen darüber hinaus häufig nur die Praktik der Limitierung paralleler Arbeit. Benjamin Huser-Berta zeigt eine weitere auf, die Messung und Regulierung des Total Work Item Age (TWIA), also des durchschnittlichen Alters der im System befindlichen Arbeitspakete. Beim Durchlesen dürfte auch klar werden, warum TWIA eher unbekannt ist - damit zu arbeiten erfordert Aufwand und Disziplin.Hauke Friederichs: Mit billiger Hightech gegen die Russen
Die Verteidigung der Ukraine gegen den russischen Angriffskrieg hat an vielen Stellen den verdrängten Fakt wieder erkennbar gemacht, dass das agile Arbeiten Wurzeln und Parallelen in der Kriegsführung hat (siehe hier, hier und hier). Hauke Friedrichs hebt am Beispiel von für die Ukraine arbeitenden deutschen Rüstungsfirmen eine weitere hervor: bei der Entwicklung von neuen Waffen- und Abwehrsystemen sind einfache, flexible Praktiken dringend nötig, wenn sie zeitnah zum Einsatz kommen sollen. Schnelle, unbürokratische Entwicklung, enger Austausch mit den Anwendern, modularer Aufbau und kontinuierliche Weiterentwicklung. Die Parallelen zur agilen Produktentwicklung sind unübersehbar.Michael Küsters: The Scrum Master as a Trash Collector
Ein interessanter Ansatz zum Reframing der Rolle des Scrum Masters. Statt seine Rolle durch die Einführung dessen zu definieren, was Scrum einer Organisation zusätzlich hinzufügt (Rollen, Regeln, Praktiken, Meetings, etc) stellt Michael Küster bei seiner Betrachtung in den Mittelpunkt, was der Scrum Master abschaffen sollte: Bürokratie, Redundanzen, Ineffizienz, Stress und weitere verbreitete Zeit- und Geldfresser. Mein erster Gedanke - würde sich diese Sichtweise im Management verbreiten, würde das automatisch zu einer ganz anderen Legitimation vieler Massnahmen führen.Maarten Dalmijn: Scrum's Built-in 'Get Out of Jail Free Card' Against Criticism
Was Maarten Dalmijn hier macht, ist die Enttarnung vieler Verteidungen von schlecht funktionierendem Scrum als No true Scotsman-Fehlschlüsse. Sie alle drehen sich darum, dass angeblich nicht die Methode selbst im jeweiligen Zusammenhang unpassend war, sondern dass sie lediglich falsch oder halbherzig umgesetzt wurde. Hätte man es "richtig" gemacht, wäre alles ganz anders gekommen. Das ist natürlich bequem, geht aber an der Realität vorbei. Scrum ist nicht überall die ideale Lösung, manchmal gibt es andere Ansätze die besser passen.Dienstag, 30. April 2024
Kommentierte Links (CXIII)
|
| Grafik: Pixabay / Geralt - Lizenz |
Jeff Gothelf: Why is it so hard to admit there’s uncertainty in our work?
Meine Theorie ist, dass ein grosser Teil der oft fehlenden Akzeptanz agilen Arbeitens darin begründet ist, dass die Menschen es sich nicht eingestehen wollen, in einer nur eingeschränkt planbaren Arbeitsumgebung tätig zu sein. Jeff Gothelf geht an dieser Stelle tiefer ins Detail und versucht zu ergründen, warum das schwerfallen kann. Verkürz gesagt: weil (das Eingeständnis von) Ungewissheit unangenehm ist und weil man einmal geäusserte Annahmen und Zusagen ungerne zurücknimmt. Warum man einen guten Grund hat, diese inneren Widerstände zu überwinden, begründet er gleich mit - wer von Anfang an von Ungewissheit ausgeht, wird sein Vorhaben resilienter organisieren, wodurch es nicht so schnell aus der Bahn geworfen werden kann.Charles Lambdin: What Does 'Iterate' Mean?
Es ist ein Vergehen, dessen sich jeder berufliche Spezialist früher oder später schuldig macht - man benutzt bestimmte Fachbegriffe irgendwann ganz automatisch, ohne darüber nachzudenken wie sie eigentlich ursprünglich gemeint waren. Einer dieser Begriffe, der im Rahmen von agilem Arbeiten immer wieder genutzt wird, ist das Iterieren. Charles Lambdin hat sich die Mühe gemacht und ist dem Ursprung dieses Wortes nachgegangen, mit der überraschenden Erkenntnis, dass er bereits von den Verfassern des Manifests für agile Softwareentwicklung uneinheitlich benutzt worden ist. Vielleicht ist das auch einer der Gründe dafür, dass sich der alternative Begriff des Sprints durchgesetzt hat.Michael Mankins, Patrick Litre: Transformations That Work
Ein Longread, aber einer, der die investierte Zeit lohnt. Michael Mankins und Patrick Litre haben zu dem Thema der Unternehmenstransformationen (agil, digital, etc) geforscht und kommen zu erstaunlichen Zahlen: die Hälfte der von ihnen befragten Unternehmen hat in den letzten fünf Jahren mehrere derartige Veränderungsprogramme durchlaufen, von denen führten aber nur zwölf Prozent wirkliche Veränderungen herbei. Interessant ist, was diese kleine Erfolgsgruppe gemeinsam hat - die Transformationsvorhaben waren keine zeitlich begrenzten Projekte sondern wurden langfristig und als Teil der täglichen Arbeit beschlossen und umgesetzt, sie waren nicht mit Sparprogrammen verbunden, die Organisation wurde nicht durch zu viele gleichzeitige Veränderungen gestresst, und es wurden ambitionierte Ziele gesetzt, den unteren Ebenen aber Freiheiten in der Ausgestaltung gelassen.Maarten Dalmijn: Why OKRs Often Slowly Wither Away
Was Maarten Dalmijn hier über OKRs schreibt, trifft auch auf jede andere Form von agilem Arbeiten zu: damit es funktionieren kann sind bestimmte Rahmenbedingungen nötig. Sind diese noch nicht vorhanden, wird die neue Vorgehensweise nicht die gewünschten Ergebnisse bringen, sondern nach und nach wieder absterben. In diesem Problem liegt aber auch bereits die Lösung: wenn man die notwendigen Vorbedingungen einmal verstanden hat, kann man sich fragen, was man tun kann um sie herbeizuführen. Daran zu arbeiten sorgt dann oft für mehr Agilität als die Einführung von OKRs (oder Scrum, oder sonstwas) selbst.Biplab Subedi: 5 Product Discovery Pitfalls Leading to Scrum Failures
Als letztes mal wieder eine kleine Liste. Biplab Subedi hat fünf häufige Product Discovery-Fehler zusammengetragen, wegen denen eine Scrum-Einführung schiefgehen kann. Hier sind sie:
1. Inadequate Time for the Problem Space
2. Discovery Solely for Estimation
3. Discovery Without Past Evidence
4. Discovery for a Quarter or More
5. Separation of Responsibilities in Discovery and Delivery
Mehr Details gibt es drüben bei ihm. Ich würde nur noch ergänzen, dass er sich Fälle bezieht, in denen Product Discovery tatsächlich nötig ist. Es gibt auch Fälle, in denen das nicht so ist.2. Discovery Solely for Estimation
3. Discovery Without Past Evidence
4. Discovery for a Quarter or More
5. Separation of Responsibilities in Discovery and Delivery
