Kommentierte Links (CVI)

Bild: Unsplash / Fabio Bracht - Lizenz

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

Christiaan Verwijs: On Stakeholders, And How To Discover Them

Eine Frage mit der sich viele Teams schwer tun ist die, wer eigentlich die Stakeholder ihres Produkts oder Services sind. Die klassische Definition "Jeder, der ein Interesse daran hat oder von ihm betroffen ist" ist zwar richtig, hilft aber aufgrund ihrer hohen Abstraktionsebene nur eingeschränkt weiter. Christiaan Verwijs bietet mit diesem Artikel nicht nur einige etwas konkretere Definitionen und Ratschläge an, sondern auch ein sehr nützliches Werkzeug: 10 Fragen anhand derer ein Team feststellen kann, mit welchen Stakeholdern es zu tun hat und was deren Interessen und Betroffenheiten sind.

Marty Cagan und Joakim Sundén: The Product Model at Spotify

Eines vorweg, um Missverständnisse zu vermeiden: das was Marty Cagan und Joakim Sundén hier beschreiben, ist nicht das berühmt-berüchtigte organisatorische Spotify Model mit seinen Tribes, Chaptern, Gilden und Squads, sondern der grundlegende Ansatz, wie bei Spotify mit Produktentwicklung, Produktstrategie und Product Discovery umgegangen wird. Verkürzt gesagt baut es auf möglichst autonome (Teil-)Produkt-Teams auf, die Erkenntnisse aus dem beobachteten Benutzerverhalten verwenden, um durch kleine, schnell validierbare Veränderungen die Nutzungsintensität hochzutreiben. Wer ähnlich erfolgreich wie Spotify werden will sollte sich eher an diesem Product Model orientieren als an der Organisationsstruktur.

Steve Denning: Escaping From The Prison Of ‘Processes’ (Part I, Part II)

Was Steve Denning von praktisch allen anderen Vordenkern der agilen Bewegung unterscheidet, ist seine Zielgruppe. In seinen Kolumnen auf Forbes.com richtet er sich explizit an CEOs und andere Top-Manager, was dazu führt, dass er auch seine Analysen und Lösungs-Ideen auf diese Gruppen ausrichtet. Seine Zusammenfassung des Weges, der grosse Unternehmen in das "Gefängnis obsoleter Prozesse" geführt hat und seine Anleitung zum "Ausbruch" aus diesem Gefängnis sind vor diesem Hintergrund zu lesen. Mit seinen dazugehörenden Ausführungen zu Aktienkursen, ISO-Standards und Management-Rekrutierung ist er entfernt von der sonst dominierenden Team- und Produktzentrierung, und genau deshalb eine wertvolle Ergänzung.

Thorsten Ball: Why We Don’t Ship Software as Fast as We Used To

Von älteren Entwicklern und Managern hört man es immer wieder: "früher" wurde Software schneller entwickelt und zum Kunden gebracht als "heute". Das Bemerkenswerte daran - selbst wenn man Vergangenheitsverklärung und Fortschrittspessimismus mit in Betracht zieht, ist diese Aussage (scheinbar) richtig, wie Thorsten Ball anhand der aus heutiger Sicht atemberaubend schnellen Entwicklung der Computerspiel-Klassikers Doom aufzeigt. Die Erklärung, die er für die (scheinbare) Verlangsamung mitliefert ist die, dass die heutigen Software-Produkte um ein vielfaches komplexer sind als die früheren, diese Komplexität (unterschiedliche Endgeräte, grössere Betriebssysteme, permanente Internet-Verbindung, mehr Nutzer, etc.) aber nicht auf den ersten Blick erkennbar ist. Sicher ein wichtiger Faktor für die häufigen Missverständnisse zwischen "Business" und "Development".

Benji Weber: One does not simply deliver software

Sprache formt unsere Wirklichkeit, oder zumindest deren Wahrnehmung durch uns. Aufbauend auf diese Erkenntnis erklärt Benji Weber, warum es keine gute Idee ist, das zur Verfügung stellen neuer Software-Funktionen als Delivery (Auslieferung) zu bezeichnen. Verkürzt gesagt: es erweckt den Eindruck, dass alles einfacher, aber auch fragiler wäre als es eigentlich ist, und sorgt dadurch für unrealistische Erwartungshaltungen und unnötige Befürchtungen, die früher oder später zu Konflikten führen müssen.