Kommentierte Links (XCIII)
Bild: Pixabay / Buffik - Lizenz |
Alexander Schatten: Getting Nothing Done
Der Titel sagt es ganz passend - wir bekommen nichts mehr fertig, oder zumindest keine Grossvorhaben mehr. Das was Alexander Schatten hier an sich ewig hinziehenden Infrastruktur- und IT-Projekten zusammenträgt ergibt eine beeindruckende und bedrückende Liste. Nicht besser wird der Gesamteindruck durch die von ihm identifizierten Gründe: langsamer werdender technischer Fortschritt, Überregulierung, mutlose und politisch getriebene Entscheidungsfindung sowie die abnehmende Fähigkeit die nötigen Ressourcen für grosse Projekte zur Verfügung stellen zu können. Ich würde noch einen hinzufügen: die Unwilligkeit und Unfähigkeit einmal beschlossene Pläne nachträglich anzupassen.Stefan Kühl: Komplexität – Das Irrtum der Vereinfacher
Ein interessanter, aber sicher auch kontroverser Artikel. Stefan Kühl geht in ihm davon aus, dass alle Massnahmen, die zur Vereinfachung eines komplexen Systems führen sollen, ihr Gegenteil erreichen und in Wirklichkeit alles nur noch komplexer machen, bis zum Kontrollverlust. Als Beschreibung der Realität ist das durchaus zutreffend, fast alle Vereinfachungsprogramme die man in grossen Organisationen vorfinden kann sind eher Verschlimmbesserungen. Widersprechen würde ich allerdings beim Determinismus - man kann Komplexität sehr wohl reduzieren, allerdings muss dafür versucht werden das angestrebte Ziel zu vereinfachen und nicht nur die zu seiner Erreichung eingesetzten Techniken und Prozesse.Jason Yip: My take on why goal cascades are harmful and what to do instead
In diesem Blogpost fasst Jason Yip gut zusammen was die Probleme der so genannten "kaskadierenden Ziele" sind, die von ganz oben vorgegeben und dann durch alle Hierarchieebenen durchgereicht werden: Entkoppelung von Entscheidungskompetenz und Umsetzungskompetenz, langsame Durchführung, Ausblendung von (sinnvollen) Eigendynamiken der unteren Ebenen und Vernachlässigung von lokal wichtigen Nebenzielen. Sein Gegenvorschlag: von ganz oben sollten eher abstrakte Leitlinien und Produktvisionen kommen, die dezentral in Ziele heruntergebrochen werden, die dann regelmässig dezentral aufeinender abgestimmt werden können. PS: Der Blogpost ist auch die Fortführung eines gleich benannten Artikels von John Cutler, der ebenfalls zum Lesen empfohlen ist.
Carl Rogers: The Five Orders of scaling agile teams
Die erste Regel der agilen Skalierung erfreut sich mittlerweile einer gewissen Popularität. Sie lautet schlicht Lass es sein. Für die möglichen weiteren Regeln gibt es zwar viele Ideen, eine Übereinkunft darauf welche es sein sollen existiert aber nicht. Diese Variante von Carl Rogers hätte das Potential zu weiter Verbreitung, weshalb ich hier zu ihrer Bekanntheit beitragen will:2. Create independence
3. Create interdependence between teams
4. Create interdependence between products
5. Manage dependencies between work to be done