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.

Charles Lambdin: Industrial Revolution Org Cultures

Wenn man komplexe Zusammenhänge verstehen will kann es eine gute Idee sein, sich mit ihrem Entstehungskontext zu beschäftigen. Charles Lambdin geht dafür weit in die Vergangenheit zurück, bis zur Gesellschaft der New York and Erie Railroad, die im Jahr 1854 das erste Unternehmens-Organigramm aller Zeiten erstellte - für viele der Startschuss des modernen Managements. Aufbauend darauf zeichnet er eine zweite, eher unbekannte Entwicklungslinie der Management-Lehre auf, die nach und nach von der heute dominierenden, auf das Management von Menschen fokussierten Variante abzweigte und stattdessen einen Schwerpunks auf das Management systemischer Faktoren legte. Als bekannte Vertreter nennt Lambdin u.a. William Edwards Deming, Edward Martin Baker, Peter Scholtes und Johanna Rothman, deren Werke zur vertieften Beschäftigung mit dem Thema sehr zu empfehlen sind. Sie zeigen, dass Management deutlich mehr sein kann als das was in den meisten grossen Organisationen zu beobachten ist.

Matthew Ström: The micromanager's dilemma

Um beim Thema Management zu bleiben - dass niemand Micro-Management mag, dieses Vorgehen aber trotzdem weit verbreitet ist, ist ein Rätsel dem Matthew Ström auf den Grund zu gehen versucht. Sein Ansatz: die Analyse von micromanagendem Vorgehen anhand des Gefangenen-Dilemmas. Die Erkenntnis die er daraus zieht ist die, dass kein Manager sich sicher sein kann, dass ein Teil seiner Untergebenen die Delegation von Verantwortung nicht ausnutzen würde. Da die dadurch entstehenden Nachteile schnell die dadurch entstehenden Vorteile aufwiegen würden ist Micromanagement nicht nur eine naheliegendes sondern (scheinbar) sogar ein wirtschaftlich sinnvolles Vorgehen. Ström nennt verschiedene Ansätze mit denen man sich aus diesem Denkgebäude befreien kann, lässt aber meiner Meinung nach den effektivsten aus - die Delegation von Ergebnisverantwortung in stabile, selbstorganisierte Teams, deren Mitglieder dann untereinander dafür sorgen können, dass sich keiner auf Kosten der anderen zurückhält.

Dorian Taylor: Agile as Trauma

Wer schon einmal miterlebt hat, in welchem Ausmass Mitglieder der Umsetzungsebene die Einführung von agilen Arbeitsweisen als Befreiung empfinden können, wird Dorian Taylor zustimmen - zumindest in der Anfangsphase kann es einer der Haupteffekte sein, die Traumatisierung durch schlechte Management-Praktiken (Micromanagement, Herrschaftswissen, Schuldzuweisungen, etc.) zu heilen. Problematisch wird es aber, wenn diese Trauma-Bewältigungs-Funktion des agilen Arbeitens zu einem Selbstzweck wird und dazu führt, dass Agilität negativ definiert wird (d.h. als Abwesenheit von Wasserfall-Prozessen oder Hierarchien). In einem solchen Kontext werden Elemente an denen auch in einem agilen Modus aktiv gearbeitet werden muss vernachlässigt werden, zum Beispiel Unternehmensführung, Software-Architektur und Produktstrategie. Findet eine solche Vernachlässigung statt, kann der (scheinbar) agile Arbeitsmodus selbst anfangen traumatisierend auf die von ihm Betroffenen zu wirken.

Michael Bolton: Talking About Coverage

Wenn es um die eher technische Seite der Agilität geht wird mit grosser Wahrscheinlichkeit früher oder später die Testabdeckung als entscheidender Faktor genannt werden, also die Metrik aus der sich ablesen lässt zu wieviel Prozent des Code durch automatisiert ausgeführte Tests abgesichert ist. Warum diese Zahl wichtig ist, ist einfach zu erklären: versehentliche Seitenauswirkungen von Featureentwicklungen werden sofort erkannt, die dauerhafte Funktionsfähigkeit einer Anwendung wird regelmässig überprüft, bestenfalls sind die Tests sogar eine einfach zu verstehende Dokumentation der Software. Weit weniger klar ist häufig, was durch diese Tests eigentlich abgesichert wird. Michael Bolton verhilft hier zu mehr Klarheit indem er aufschlüsselt was mögliche Definitionen von Testabdeckung sind, wofür sie gut ist (und wofür nicht) und wann man welche Variante anwenden kann. Eine einfache Erklärung hat man zwar auch nach dem Lesen seines Textes nicht, man hat den Sachverhalt aber deutlich besser verstanden.

Jason Yip: All my thoughts on program management

Ob Agilität auch in Vorhaben möglich ist die so gross sind, dass sie organisatorisch nur noch als Programm (übergreifende Struktur über mehreren Projekten oder Produktlinien) abgebildet werden können, lässt sich ausgiebig diskutieren. Lässt man diese Überlegungen beiseite bleibt aber zumindest die Frage, wie man zumindest so viel Agilität wie möglich erreichen kann. Jason Yip trägt einige gute Ideen dazu zusammen, wie oft in seinen Artikeln angereichert durch hilfreiche Visualisierungen. Empfehlenswert für jeden der in einem skalierten Umfeld unterwegs ist.