Kommentierte Links (XLII)

Bild: Pixabay / Bru-nO - Lizenz

• Tim Harford: Why Big Companies Squander Brilliant Ideas

  Ein langer Text, aber lesenswert. Mit mehr als 20.000 Zeichen führt Tim Harford aus warum sich große Organisationen mit Innovationen schwer tun: zum einen weil neue, zu Beginn noch nicht profitable Ideen sich im internen Wettbewerb um Ressourcen nicht gegen die etablierten, seit langem Gewinn abwerfenden Cash Cows durchsetzen können, zum anderen weil die bestehenden Organisationsstrukturen so stark auf die bestehenden Produkte zugeschnitten sind, dass neue Produktideen nur umgesetzt werden wenn sie ebenfalls diesen Strukturen entsprechen - was häufig nicht der Fall ist. Der dritte Grund dagegen ist wesentlich polemischer und darum mit Vorsicht zu geniessen: "Because people are idiots."
  

• Dennis Willkomm: Am Scheitern scheitern – Gefahren der Fehlerkultur

Ich freue mich ja immer wenn ich merke, dass ich nicht der erste aus der lokalen Agile-Community bin der dieses Internet vollschreibt. Dennis Willkomm hat sich hier eines selten behandelten Themas angenommen, nämlich dem, dass nicht nur die Einführung von Methoden sondern auch die Veränderung einer Unternehmenskultur im Cargo Cult enden kann. Mit Exkursen in die Psychologie unterfüttert wird eine Erkenntnis herausgearbeitet die man vielen Change Management-Abteilungen nur wünschen kann: wer glaubt seinen Mitarbeitern eine neue Kultur einfach überstülpen zu können wird damit alles mögliche erreichen, nur nicht das was er eigentlich beabsichtigt hat.

• Alice Newton Rex: Escape From the Feature Roadmap to Outcome-driven Development

  Ein Thema das ich in letzter Zeit immer wieder in Product Owner-Workshops besprochen habe findet sich auch hier wieder: gegenüber Stakeholdern/Management/Kunden/Auftraggebern sollte sich ein Product Owner nicht zur Lieferung bestimmter Funktionalitäten verpflichten sondern zur Lieferung abstrakt formulierter Kundenmehrwerte, deren bester Umsetzungsweg sich erst im Rahmen der Umsetzung selbst ergeben wird. Dieser Ansatz widerspricht zwar dem üblichen Verhalten in vielen Organisationen (Alice Newton Rex erklärt gut warum), führt aber bereits mittelfristig zu besseren Ergebnissen als die vordefinierte Roadmap, die zuverlässig zu einem Ziel führt das von der Zielgruppe mittlerweile längst verlassen worden ist. (Siehe auch: agile Roadmaps)
  

• Joe Crick: It Doesn’t Have to be Perfect

  Einige gute Gedanken zum Thema Legacy Code, nicht zuletzt deshalb weil sie nicht aus einer technischen sondern eher aus einer soziologischen Perspektive geschrieben wurden. Folgende Aspekte sind für Joe Crick im Umgang mit Legacy Code wichtig:
  
  • Respektiere das was er tut: er mag nicht den Standards entsprechen, aber die aus ihm bestehende Anwendung sichert Dein Einkommen.
  • Verstehe wie er entstanden ist: die Organisationsstruktur zur Zeit seiner Entstehung spiegelt sich im Code wieder (→ Conway's Law). Damals hat er vielleicht mehr Sinn ergeben als heute.
  • Lege realistische Standards an: die Aussage aus der Überschrift. Code muss nicht perfekt sein, es reicht wenn er gut ist. Beziehungsweise - gut genug für den Zweck den er erfüllen soll.
  • Sei massvoll in der Beurteilung: in den seltensten Fällen ist Legacy Code der unbrauchbare Mist als der er häufig beschimpft wird. Er mag buggy, kompliziert und umständlich sein, aber dann sollte man ihn auch nur so nennen.
  • Gehe gelassen mit ihm um: Kein Mensch ist perfekt, alle machen Fehler. Und umgekehrt und nicht alles ein Fehler was man selbst nicht versteht. Wer das akzeptiert kann besser mit den Hinterlassenschaften anderer umgehen.
  Gedanken wie diese sind praktisch immer hilfreich, und zwar nicht nur beim Schreiben von Software. Auch im Change- oder Prozessmanagement können sie von Nutzen sein, denn letztendlich ist auch die Struktur einer Firma nichts anderes als organisatorischer Legacy-Code.

• Department of Defense, Defense Innovation Board: Detecting Agile BS

  Unter allen möglichen Orten an denen man nach einem Leitfaden zur Überprüfung von Agilität suchen würde ist eine Behörde so ziemlich einer der letzten. Und doch - wenn man es wagt wird man überrascht. Das amerikanische Verteidigungsministerium hat ein nicht nur brauchbares sondern sogar wirklich gutes Dokument entwickelt, das sich auch quer durch alle Branchen anwenden lässt. Statt Formalien abzufragen konzentriert es sich auf das Wesentliche - wird in kurzen Zyklen Mehrwert geliefert? Wird Feedback von den Anwendern (den echten, nicht deren Vorgesetzten) eingeholt? Sind wiederkehrende Tätigkeiten automatisiert? Etc. Besonders schön: um den in der Überschrift genannten "Agile Bullshit" auszufiltern sind auch typische falsche und ausweichende Antworten auf die Überprüfungsfragen vorhanden. Und jedem der in grossen Organisationen gearbeitet hat werden die sehr bekannt vorkommen.