Bild: Pixabay / Buffik - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

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:

1. Don’t scale
2. Create independence
3. Create interdependence between teams
4. Create interdependence between products
5. Manage dependencies between work to be done

Wichtig für das Verständnis - diese Regeln bilden eine Art Eskalationshierarchie: nach jeder von ihnen sollte man sich nur dann richten, wenn alle davor ausprobiert wurden und nicht funktioniert haben.

Chris Combe: Add skills not people to your cross-functional teams

Aus diesem Artikel von Chris Combe könnte man möglicherweise eine weitere Skalierungsregel ableiten: wenn in einem Team bestimmte Fähigkeiten fehlen füge erst dann neue Teammitglieder hinzu wenn die bestehenden sich das Wissen nicht aneignen können. Warum die Vergrösserung eine eher schlechte Idee ist erklärt er dabei mit Hilfe zahlreicher Referenzen und Verweise, die jeweils zu weiteren lesenswerten Texten führen.