Kommentierte Links (CXXII)
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.
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.
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.
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).
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.
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).
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 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.
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.
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.
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.
