Kommentierte Links (LXVII)

Bild: Unsplash / Dayne Topkin - Lizenz

• Jez Humble: OK, apparently this still needs saying

  Es gibt ja für alles ein erstes Mal, so auch hier: erstmalig verlinke ich in den kommentierten Links nicht zu einem Artikel sondern zu einem Twitter-Thread. Was Jez Humble hier schon leicht genervt ankündigt ist eine in acht Teilen ausgeführte Widerlegung des verbreiteten Vorurteils, dass DevOps und agile Produktentwicklung nicht mit staatlichen Regulierungen wie PCI DSS, FISMA und SOX vereinbar wären. Twitter-typisch sind die im Text selbst enthaltenen Informationen eher komprimiert, der wahre Mehrwert ergibt sich aus verschiedenen weiterführenden Fallstudien und Artikeln die im Thread verlinkt sind. Ein eher trockenes Thema aber ein wichtiges für jeden der im Geltungsbereich dieser und ähnlicher Vorschriften agil arbeiten will.
  

• Barry O'Reilly: Systemic Effects - the Overlooked Key to Effective Strategic Planning

  Ein weiterer Beweis dafür, dass einem die neu zu lernenden Themen nie ausgehen werden. Seit 1971 gibt es die Futures Wheel-Methode, mit der man direkte und indirekte Konsequenzen von Entscheidungs- und Umgebungsfaktoren visualisieren kann - und erst jetzt erfahre ich davon, durch diesen Artikel von Barry O'Reilly. Letzten Endes ein mit der Mind Map verwandtes Konzept, mit dem grossen Unterschied, dass die Themen sich nach aussen nicht nur weiter ausdetaillieren sondern sich dort auch gegenseitig beeinflussen und voneinander abhängen können. Vom ersten Eindruck her würde ich sagen, dass verschiedene Einsatzgebiete möglich sind, z.B. neben der von O'Reilly genannten nichtlinearen strategischen Planung auch Ist-Analysen. Spannend.
  

• András Juhász: Technical Debt Is Overhyped. Let’s Talk about Product Debt
  

  Mir fällt gerade auf, dass ich eigentlich schon seit Jahren etwas zum Thema technische Schulden schreiben will aber nie dazu gekommen bin. [Edit: mittlerweile doch] Dann eben zuerst zu den "Produkt-Schulden". Laut András Juhász sind das voreilig eingebaute (oder nach Erkennung nicht entfernte) Features die nicht (mehr) zur Produktvision passen - was nochmal unterstreicht, dass man natürlich eine haben sollte. Eine ähnliche Definition kommt von Luke Gallimore: auch für ihn entstehen Produkt-Schulden durch die fehlende Ausrichtung auf ein übergeordnetes Ziel (statt Produktvision spricht er von Produktstrategie), er fügt aber noch eine weitere Dimension hinzu - auch die fehlende Validierung von Annahmen über die Akzeptanz und Nutzung neuer Features führt für ihn zu Produkt-Schulden. Beides sehr bedenkenswerte Überlegungen.
  

• Ron Jeffries: Working Software

  Das hier ist sehr Oldschool. Ron Jeffries, einer der Verfasser des Manifests für agile Softwareentwicklung, geht auf einen von dessen zentralen Sätzen ein: "Working software is the primary measure of progress." Nach einem kurzen Exkurs zur Frage was eigentlich "working Software" ist (Antwort: es kommt darauf an) liefert er eine sehr schön differenzierte Antwort warum sie das Hauptkriterium für Fortschrittsmessungen sein sollte, und zwar sowohl für einzelne Entwickler, als auch für Entwicklungsteams, als auch für Manager. Ein Artikel den man ausdrucken und in vielen Entwicklungsabteilungen dieser Welt an die Wand hängen sollte.
  

• Ken Schwaber: SCRUM Development Process

  Apropos Oldschool. Vor fast genau 25 Jahren (also sogar deutlich vor dem Manifest für agile Softwareentwicklung) stellten Jeff Sutherland und Ken Schwaber auf der OOPSLA-Konferenz ihre Version von Scrum vor, und obwohl es damals bereits noch ältere gab hat sich ihre durchgesetzt und nach langer Evolution zu dem entwickelt was wir heute unter diesem Namen kennen. Das bedeutet, dass heute Software-Entwicker nach Scrum arbeiten die noch nicht geboren gewesen sind als dieses Paper veröffentlicht wurde. Um so bemerkenswerter, dass dieses Framework in manchen Firmen noch immer als neumodisch gilt.