Kommentierte Links (CV)
Bild: Unsplash / Fabio Bracht - Lizenz |
Emily Webber: Bridging Silos and Overcoming Collaboration Antipatterns in Multidisciplinary Organisations
Dass die Aufteilung einer Organisation in Einheiten aus gleichartigen Spezialisten (so genannte "Silos") eine schlechte Idee ist, ist keine neue Erkenntnis. Warum das so ist ist häufig wesentlich unklarer, viele Begründungen beschränken sich auf abstrakte Schlagwörter wie "Kommunikations-Overhead" oder "fehlende Systemsicht". Emily Webber wird konkreter und nennt drei verbreitete nachteilige Folgen: die Aufteilung einzelner Spezialisten auf mehrere Teams (mit Termin-, Prioritäts- und Loyalitätskonflikten als Folge), Machtkämpfe zwischen den Silos auf Kosten des Gesamtsystems und die sich daraus ergebende Macht-Ungleichgewicht zwischen den Gewinner- und Verlierer-Silos. Auch beim Aufzeigen besserer Alternativen geht sie über die abstrakte Forderung nach einem crossfunktionalen Team hinaus. Wer schon immer den Unterschied zwischen Multidisziplinär, Interdisziplinär und Transdisziplinär wissen wollte, wird bei ihr fündig.Łukasz Korecki: OKRs? More like, R U OK?
Ich bin schon seit langem skeptisch gegenüber OKRs, und Łukasz Korecki geht in seinem Artikel auf einige Gründe ein die auch ich kritisch sehe: Mit ihrer üblicherweise quartalsweisen Ansetzung der Objectives sind sie nicht besonders agil, mit ihrem Beharren auf messbaren Key Results verleiten sie zu Output statt Outcome, da sie wie alle anderen auf Messbarkeit ausgelegten Vorgehensmodelle eine starke Anfälligkeit für Goodhart's Law haben (When a measure becomes a target, it ceases to be a good measure) und zuletzt führt diese Art der Ergebnisfixierung zu einer Vernachlässigung von Lern- und Discovery-Bemühungen. Eine Beobachtung von ihm teile ich ebenfalls: positive Äusserungen über OKRs kommen fast nie von denen die damit arbeiten müssen, sondern fast ausschliesslich von denen die sie anordnen oder durch Trainings mit ihnen Geld verdienen. Jason Yip: Continuous Integration / Continuous Delivery
Die technische Seite von Agilität wird leider manchmal vernachlässigt, weshalb es mich immer wieder freut wenn sie irgendwo Erwähnung findet. Jason Yip macht das, indem er auf die Frequenz eingeht, in der neu entwickelter Code mit dem bestehenden zusammengeführt wird. Indem er sich von den langen zu den kurzen Zeiträumen vorarbeitet kann er aufzeigen welche Probleme es bei den ersten gibt (der Begriff "Integration Hell" sagt eigentlich alles aus) und welche Vorteile die letzten haben. Gut ist, dass er nicht nur den bestmöglichen Weg hervorhebt (jeder Entwickler integriert seien neuen Code mindestens einmal täglich) sondern auch die verschiedenen Tests die dabei durchlaufen werden: nicht nur die Pre-Merge-Tests vor der Integration, sondern auch die Post-Merge-Tests danach.