Kommentierte Links (CX)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Mittwoch, 31. Januar 2024
Philip Plickert: Hunderte Menschenleben durch einen Computerfehler ruiniert
Vor einigen Jahren hatte ich ab und zu auch Meldungen in die Kommentierten Links aufgenommen, in denen es um dramatische Folgen von Software-Fehlern ging, z.B. um Flugzeugabstürze oder um die versehentliche Entlassung von Verbrechern aus Gefängnissen. Diese Nachricht hier ist so krass, dass ich diese Kategorie wieder aufleben lasse: 700 Leiter von britischen Postfilialen wurden aufgrund fehlerhafter Software zu Unrecht wegen Unterschlagung verurteilt, einige davon zu Gefängnisstrafen. Berufliche Existenzen wurden zerstört, Reputationen ruiniert, Ehen gingen in die Brüche. Irrsinnig.Stephanie Ockerman: Stop Being So "Helpful"
Völlig zu Recht beschreibt Stephanie Ockermann ihre Beobachtung als eines der schmutzigen Geheimnisse vieler Agile Coaches: wenn sie das Gefühl haben, ihren Teams helfen zu können, indem sie ihnen bestimmte Herausforderungen abnehmen, dann tun sie das - und untergraben damit die Selbstorganisation und Problemlösungskompetenz ihrer Coachees. Dieses Verhalten ist gut gemeint und menschlich, trotzdem ist es eines das man sich abgewöhnen sollte, sobald man es an sich selbst entdeckt. Der Text enthält auch eine kleine Anleitung dazu, wie man es entdecken kann und wie man sich selbst zu mehr Zurückhaltung bringt.Montag, 29. Januar 2024
Warum so viele Manager?
 |
| Bild: Gottscho-Schleisner / Library of Congress - Public Domain |
Eine der Nachrichten, die in letzter Zeit für Aufmerksamkeit gesorgt haben, ist der bevorstehende Stellenabbau bei Bayer. Nicht nur wegen der verlorenen Arbeitsplätze, sondern auch wegen einer in diesem Zusammenhang veröffentlichten Zahl: 17.000 von 100.000 Mitarbeitern arbeiten dort im Management, also fast jeder fünfte. Mehrfach habe ich die Frage gehört, wie das denn sein kann, die Zahl wirkt auf den ersten Eindruck unglaublich hoch. Versuchen wir es mit einer Erklärung.
Da ich die internen Strukturen bei Bayer nicht kenne, starten wir mit Vergleichswerten, die ich in verschiedenen anderen Firmen erlebt habe. Auf der untersten Ebene gehen wir dabei von Teams, Gruppen oder Referaten von ca. 10 Mitarbeitern aus, einer häufig anzutreffende Grösse. Unterstellen wir, dass jede dieser Einheiten einen eigenen Team-, Gruppen oder Referatsleiter hat, kommen wir damit auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 10.
Auf der nächsthöheren Ebene gehen wir davon aus, dass jeweils fünf der untersten Einheiten eine Abteilung bilden, jeweils fünf Abteilungen einen Bereich, und so weiter, bis hinauf zu den Ressorts und Landesgesellschaften. Jede dieser Einheiten hat einen Leiter, und nicht nur das, ab einer bestimmten Grösse kommen Stellvertreter und Stabsstellen dazu. Alle diese Positionen zählen wir auch zum Management, und gehen dadurch grob von einem Manager/Mitarbeiter-Verhältnis von 1 zu 9 aus.
Dieses Verhältnis dürfte vor allem dort anzutreffen sein, wo es um gleichbleibende Regeltätigkeiten geht, z.B. in der Fertigung oder einem Callcenter. In der Wissens- oder Innovationsarbeit ist es aber meistens komplizierter, dort wird normalerweise in Projekten gearbeitet. Diese Projekte bilden dabei eine eigene, zu den Teams, Abteilungen, etc. parallele Organisation, die sich die Mitarbeiter von den gerade genannten Einheiten leiht, zu deren Koordination aber eigene Manager hat.
Gehen wir auch hier zuerst von der Grösse von 10 Mitarbeitern aus, die zu einem gemeinsamen Teilprojekt gehören.1 Und nehmen wir an, dass fünf Teilprojekte ein Projekt bilden und fünf Projekte ein Programm. Wenn wir jetzt noch davon ausgehen, dass wiederum jede dieser Einheiten einen Teilprojekt-, Projekt- oder Programmleiter hat (und die Linienmanager einbeziehen), kommen wir in den projektartig arbeitenden Teilen der Organisation auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 5 oder 1 zu 4.
Auch hier kommen aber nochmal zusätzliche Management-Positionen dazu, zum einen erneut die Stellvertreter und Stabsstellen, ausserdem aber noch die Project Management Offices (PMO), in denen sich bemerkenswerte Mengen von Menschen mit Planungen, Schätzungen, Anträgen, Genehmigungen oder Kommunikation beschäftigen können. Dazu kommen funktionale Stellen wie z.B. Qualitäts-Manager, Rollout-Manager, Compliance-Manager, etc.
Am Ende kann durch diese doppelte Management-Hierarchie in Linien- und Projektorganisation in den projektartig arbeitenden Teilen der Firma sogar ein Manager/Mitarbeiter-Verhältnis von 1 zu 3 möglich sein (!). Verrechnen wir das mit den weniger Management-lastigen Regeltätigkeits-Einheiten, ist im Gesamtdurchschnitt ein Verhältnis möglich, dass etwa dem entspricht, von dem bei Bayer berichtet wurde, etwa 1 zu 5. Diese Zahl kann also stimmen.2
Spätestens jetzt stellt sich die Frage, was all diese Manager eigentlich machen. Wenn wir die zahlenmässig kleine Gruppe der strategisch lenkenden Topmanager ausklammern, lautet die Antwort, dass sie vor allem kommunizieren und koordinieren. Kommuniziert werden Ziele (incl. deren Herunterbrechung) und Ergebnisse (incl. deren Zusammenfassung), koordiniert werden Abhängigkeiten, v.a. fachlicher und technischer Natur, aber auch die zu anderen planenden, freigebenden oder budgetierenden Einheiten.
Wichtig für das Verständnis ist dabei, dass es in der Regel ein Systemdesign gibt, dass diese Tätigkeiten tatsächlich zu Vollzeitjobs macht. Häufige Faktoren sind z.B. hohe Spezialisierungen und knappe Budgets, wodurch Mitarbeiter nur in Teilzeit in die Projekte entsandt werden können, was zu permanenten Ziel-, Termin- und Loyalitätskonflikten führt, deren Auflösung und deren zu kommunizierende Konsequenzen bei Linien- und Projektmanagern erhebliche Daueraufwände verursachen.
Daraus ergibt sich auch, was zu tun ist, wenn man das Verhältnis von Managern zu Mitarbeitern verringern will. Zum einen müssen die unteren Einheiten crossfunktionaler und durch breitere Skillprofile in Vollzeit besetzbar werden, so dass die Zahl der zu koordinierenden Abhängigkeiten abnimmt,3 zum anderen müssen diese Einheiten mehr Entscheidungskompetenzen bekommen, wodurch es nicht mehr nötig ist, ihnen ihre Aufgaben aus übergreifenden Zielen abzuleiten (das können sie dann selbst).
In einem solchen Setting kommt eine Organisation auch mit deutlich weniger Managern aus, wobei allerdings zu beachten ist, dass eine Delegation von Verantwortung nach unten ohne Begleitung und Befähigung schnell in Überforderung enden kann (die so genannte Autonomiefalle). Um diese zu vermeiden müssen die verbleibenden Manager verstärkt die Rolle von Beratern und Coaches annehmen, um so die neuen, crossfunktional-autonomen Teams in Richtung Selbstmanagement zu entwickeln.
Genau das ist laut dem oben verlinkten Artikel auch das Zielbild der organisatorischen Veränderungen bei Bayer. Wir können gespannt sein ob das erfolgreich sein wird oder nicht, vielleicht wird es ja in einigen Monaten oder Jahren neue Berichte in den Medien geben, aus denen sich das Ausmass der Erfolge ablesen lassen wird.
2Natürlich gibt es auch viele Unternehmen in denen die Zahlen andere sind, aus meiner Erfahrung sind die von Bayer aber zumindest keine totalen Ausreisser
3Ein gewisser Umfang von Abhängigkeiten ist zwar unvermeidbar, wird der klein gehalten, können die Teams diese aber auch selbst managen
Donnerstag, 25. Januar 2024
MBO und OKR
Zu den grossen "agilen Trends" der letzten Jahre gehören die Objectives and Key Results (OKRs), eine Methode um persönliche oder übergreifende Ziele, von der man sich einen einfacheren oder besseren Weg zur Agilität erhofft. Die damit erzielten Ergebnisse schwanken allerdings stark, von deutlichen Verbesserungen bis deutlichen Verschlechterungen ist alles dabei. Meine steile These dazu: man kann absehen was davon der Fall sein wird, und dafür muss man nur betrachten wie vorher mit einem anderen Ansatz umgegangen worden ist - dem Management by Objectives (MBO).
Bevor wir darauf eingehen eine kurze Begriffsbestimmung. OKRs wurden von Andrew Grove bei Intel entwickelt und von seinem damaligen Mitarbeiter John Doerr später bei Google eingeführt und dadurch popularisiert. Sie teilen Ziele in qualitative Objectives und quantitative Key Results auf, von denen die ersten abstrakt-übergreifend und die zweiten davon abgeleitet und konkret überprüfbar sind. In der Umsetzung werden Objectives quartalsweise gesetzt und durch Key Results nach und nach erreicht.
Dass dieser Ansatz flexibler (und agiler?) als die sonst üblichen starren Jahresziele ist, liegt auf der Hand, und tatsächlich ist er als bewusste Weiterentwicklung, bzw. Ablösung eines Vorgehensmodells entwickelt worden, mit dem diese in den meisten Fällen umgesetzt werden, eben dem MBO. Grove und Doerr weisen in ihren Büchern High Output Management (Grove, 1983) und Measure what Matters (Doerr, 2017) explizit auf diese Art der Entstehung hin.
[Before the introduction of OKRs], goals were centrally planned and sluggishly trickled down the hierarchy. At others, they became stagnant for lack of frequent updating; or trapped and obscured in silos; or reduced to key performance indicators (KPIs), numbers without soul or context. Most deadly of all, MBOs were commonly tied to salaries and bonuses.Andy Grove: High Output Management, S.25
Besonders der letzte Punkt ist dabei erwähnenswert, da er den durch ihre Langfristigkeit immer realitätsferner werdenden MBOs eine destruktive Dynamik hinzufügt: die Koppelung der Zielerreichung an Gehaltsbestandteile. Es ist eine menschliche, bzw. betriebswirtschaftliche Reaktion - um den vollen Bonus ausgezahlt zu bekommen, werden alle Ziele konsequent umgesetzt, und zwar auch dann wenn sie mittlerweile als unsinnig erkannt wurden. Geld sticht Sinn.
Die Rollen sind damit klar verteilt. Alt und neu, überkommen und modern, starr und flexibel, Objectives and Key Results und
Management by Objectives. Wie fast immer bei derartig klaren Gegensätzen gilt aber auch hier, dass sie zu einfach sind um wahr zu sein. Betrachtet man das Buch in dem die MBOs erstmals beschrieben wurden, The Practice of Management, geschrieben 1954 vom österreichisch-amerikanischen Ökonomen Peter Drucker, entdeckt man Erstaunliches.
The most effective managers I know [...] have each of their subordinates write a “manager’s letter” twice a year. In this letter to his superior, each manager first defines the objectives of his superior’s job and of his own job as he sees them. He then sets down the performance standards which he believes are being applied to him. Next, he lists the things he must do himself to attain these goals—and the things within his own unit he considers the major obstacles. He lists the things his superior and the company do that help him and the things that hamper him. Finally, he outlines what he proposes to do during the next year to reach his goals.Peter Drucker: The Practice of Management, S. 343
Mit anderen Worten: das was OKRs ausmacht und es angeblich von den MBOs unterscheidet ist in diesen bereits enthalten. Die dezentrale Planung, die Trennung von Zielen und Ergebnissen, die Möglichkeit zu Anpassungen während des Jahres, all das war von Drucker bereits so angedacht. Und selbst die durch die Knüpfung an Gehaltsbestandteile durchgeführte Steuerung von oben war nicht in seinem Sinn, stattdessen spach er bewusst von Management by Objectives and Self-Control.
Reports and procedures should be the tool of the man who fills them out. They must never themselves become the measure of his performance.Peter Drucker: The Practice of Management, S. 359
Die Betrachtung des MBO wird damit komplett auf den Kopf gestellt - nicht der Ansatz selbst ist problematisch, sondern seine falsche Umsetzung, nicht er selbst beinhaltet Top Down-Management, fehlende Flexibilität und nicht zielführende Anreizgebung, sondern die Menschen die ihn umsetzen bringen diese Ideen mit und überschreiben damit die in ihrem Ursprung komplett in die andere Richtung orientierten Umsetzungs-Empfehlungen.
Und damit kommen wir zurück zur Eingangs-These: will man voraussagen können wie eine Organisation mit Objectives and Key Results klarkommen wird, muss man eigentlich nur überprüfen wie sie mit Management by Objectives umgeht. Setzt sie dieses wie ursprünglich gedacht ein, werden auch OKRs gut funktionieren, verfremdet sie es bis in ihr Gegenteil wird sie das mit grosser Wahrscheinlichkeit auch mit OKRs tun. Da so ziemlich jede halbwegs grosse Firma bewusst oder unbewusst mit MBO arbeitet, ist das eine erstaunlich effektive Art der Überprüfung.
Montag, 22. Januar 2024
Täglich grüßt das Murmeltier - ungewollte Folgen agilen Managements
Als sich abgezeichnet hat, dass ich die Konferenz Manage Agile 23 verpassen werde, war ich enttäuscht, und zwar vor allem aus einem Grund: ich hatte mich auf die Keynote von Stefan Kühl gefreut, einem Professor der Soziologie und bekannten Beobachter und Kritiker der agilen Bewegung. Aber jetzt ist wieder alles gut, denn Summit (der Konferenzveranstalter) hat das Video veröffentlicht, und wie erwartet ist es sehenswert und unterhaltsam.
Inhalt seiner Ausführungen ist, dass er die Eigenschaften von Management-Moden herausarbeitet und die agile Bewegung auf sie überprüft. Sein Fazit: die Kriterien sind gegeben, Agile ist eine Mode. Und er wagt sogar eine Prognose: in fünf Jahren wird sie vorbei sein. An der Stelle kann man gespannt sein ob er recht behalten wird, nicht zuletzt mit Blick auf die Geschichte: das Ende der Agilität wird seit fast einem Vierteljahrhundert vorhergesagt, ohne das es bisher dazu gekommen ist (und dass ich die Klassifizierung als Management-Mode nicht teile habe ich bereits woanders aufgeschrieben). Trotz allem: sehens- und hörenswert.
Donnerstag, 18. Januar 2024
300 agile Zertifizierungen
Wie letztes mal ist es ohne Anspruch auf Vollständigkeit, einige Beobachtungen kann man aber machen. Es sind noch einmal mehr geworden (über 300 statt 240), es sind Anbieter verschwunden und andere sind dazugekommen. Einige Titel befinden sich hart an der Grenze zur Realsatire (z.B. "Scrum Developer Instructor" und "Agile PeopleOps Agility") und einige Zertifizierungsorganisationen haben verwirrend ähnliche Namen (z.B. die Agile Coach Alliance und die Agile Coaches Alliance).
Eine interessante Entwicklung ist, dass einige Zertifizierungen umbenannt wurden. Man kann spekulieren, dass das letzte mit den Gerichtsprozessen zwischen den verschiedenen Anbietern zu tun hat (am bekanntesten dürfte der zwischen Scrum Alliance und Scrum Inc sein), die Teil der Auseinandersetzungen um diesen Millionenmarkt sind. Mal sehen ob es auch bei den ähnlichen Namen der Zertifizierungsorganisationen dazu kommt.
| Organisation | Zertifizierungen | Auflistung |
|---|---|---|
| International Consortium for Agile | 26 |
|
| CertiProof | 22 |
|
| Scrum Alliance | 16 |
|
| Scrum.org | 14 |
|
| EXIN | 14 |
|
| Agile Coaches Alliance | 14 |
|
| Scaled Agile Framework | 13 |
|
| DevOps Institute | 13 |
|
| Kanban University | 12 |
|
| International DevOps Certification Academy | 12 |
|
| Scrum Institute | 12 |
|
| ScrumStudy | 10 |
|
| Industrie- und Handelskammern1 | 9 |
|
| EuropeanScrum | 9 |
|
| Scrum Inc | 8 |
|
| Flight Levels Academy | 8 |
|
| Scrum Agile Institute | 8 |
|
| Agile Academy | 8 |
|
| DevOps Agile Skills Association | 7 |
|
| APM Group International | 7 |
|
| ProKanban | 6 |
|
| Large Scale Scrum2 | 5 |
|
| OpenSpace Agility Framework | 5 |
|
| Project Management Institute | 5 |
|
| Lean Change | 4 |
|
| Agile Coach Alliance | 4 |
|
| Agile Marketing Academy | 4 |
|
| Agile PeopleOps Framework |
4 |
|
| AgilityHealth | 4 |
|
| International Business and Quality Management Institute | 4 |
|
| OKR Institute | 4 |
|
| EduScrum | 4 |
|
| TÜV3 | 4 |
|
| Axelos | 3 |
|
| Alliance for Qualification | 3 |
|
| International Association of Project Managers | 3 |
|
| Ineko Institut (Universität Köln) | 3 |
|
| International Software Testing Qualifications Board | 2 |
|
| International Software Quality Institute | 3 |
|
| OKR Consortium | 3 |
|
| British Computer Society - The Chartered Institute for IT | 2 |
|
| International Requirements Engineering Board | 2 |
|
| KPI Institute | 2 |
|
| IT Service Management Academy | 1 |
|
| DEKRA | 1 |
|
2Der LeSS-Friendly Scrum Trainer ist eine Erweiterung des Certified Scrum Trainer der Scrum Alliance
3Zertifizierungslehrgänge verschiedener TÜV-Gesellschaften
Montag, 15. Januar 2024
Dunning, Kruger & KI
Dass die allgemeine Verfügbarkeit von KI-Anwendungen (KI = künstliche Intelligenz) die Arbeitswelt in kurzer Zeit stark verändert hat, ist ein Allgemeinplatz, welche Veränderungen das sind, ist im Einzelfall aber doch immer wieder überraschend. So gehört anscheinend zu ihnen, dass die Nutzung von KI zu einem verstärkten Auftreten des Dunning-Kruger Effektes führen kann, also zu einer unrealistisch guten Selbsteinschätzung, gerade dann wenn eigentlich das Gegenteil der Fall ist.
Nachlesen kann man das aktuell in einer Studie des IT-Sicherheits-Providers Snyk, die auf Interviews mit 500 Entwicklern beruht, schon etwas älter (von 2022) ist eine Meta-Studie der Stanford University, die die Forschungsergebnisse mehrerer amerikanischer und kanadischer Wissenschaftler zusammenfasst. Ohne David Dunning, Justin Kruger oder ihr Paper Unskilled and unaware of it beim Namen zu nennen, beschreiben sie genau das, was den nach ihnen benannten Effekt ausmacht.
Zum Hintergrund: es gibt systemische Gründe, wegen denen der von KI-Tools generierte Code oft schlecht ist. Anders als von Laien angenommen lernen diese Programme nicht selbst, sondern werden von Menschen trainiert, und zwar aus Kostengründen von Billigkräften aus Afrika oder Asien. Bei einfachen Wissensfragen oder Bildgenerierungen funktioniert das auch gut, beim Überprüfen von Quellcode kommen Menschen dieses Gehalts- (und damit Bildungs-)Niveaus aber schnell an Grenzen.
Die Grundlage dieser Trainings ist (vereinfacht gesagt) aller im Internet stehender Code, der natürlich in weiten Teilen schon älter ist. Der auf dieser Basis generierte neue Code ist daher nicht in dem Sinn schlecht, dass er nicht funktioniert (das würde dann doch auffallen), er ist es in dem Sinn, dass er an veralteten Architektur- und Sicherheitsstandards ausgerichtet ist und die so erzeugten Programme aus diesem Grund schwerer verständlich, aufwändiger in der Wartung oder einfacher zu hacken sind.
Statt sich dessen bewusst zu sein, herrschte bei den an den Untersuchungen teilnehmenden Entwicklern aber mehrheitlich die genau gegenteilige Meinung vor: sie waren davon überzeugt, dass der Code, den sie sich von ihrer KI (z.B. von Github Copilot oder Facebook InCoder) hatten generieren lassen, modern, gut lesbar und sicher wäre. Und genau das, die unrealistisch hohe Meinung über die Qualität eher dürftiger eigener Arbeitsergebnisse, ist der Dunning Kruger Effekt.
Die genauen Gründe, aus denen dieser Effekt in genau diesem Kontext auftritt, sind in den genannten Studien nicht erforscht (und es ist auch fraglich, ob ihre Identifizierung so einfach möglich wäre), einen vermutlich nicht unwichtigen Faktor hat aber Rebecca Parsons, der CTO von Thoughtworks, beschrieben: die Antworten der Chatbots sind immer so formuliert, dass sie den Eindruck zweifelloser Richtigkeit erwecken. Das kann dazu führen, dass diese dann auch vom Anwender angenommen wird.
Die Lehre die man daraus ziehen kann ist, dass gerade KI-generierter Code mit grosser Vorsicht behandelt und möglichst sorgfältig reviewt werden sollte, bevor er irgendwo integriert und deployed wird. Das führt zwar dazu, dass die Menge der Arbeit, die man an eine künstliche Intelligenz delegieren kann gefühlt weniger wird, dafür ist das Ergebnis aber auch besser und sicherer. Und auch das gehört zu Dunning Kruger dazu - wenn man gemerkt hat, dass man betroffen ist, geht der Effekt zurück.
Donnerstag, 11. Januar 2024
Gall's Law
Herzlich willkommen, liebe Leser, das heutige Thema ist ein weiteres "Gesetz", oder besser gesagt eine weitere pointierte Betrachtung über regelmässig zu beobachtende Phänomene der Organisations- und Softwareentwicklung, diesesmal vom amerikanischen Arzt, Systemtheoretiker und Historiker John Gall: das nach ihm benannte "Gall's Law", im deutschen manchmal unter dem Titel "Gall'sches Gesetz" anzutreffen. Es lautet folgendermassen:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
(John Gall: Systemantics - How Systems Really Work and How They Fail)
Ins Deutsche übersetzt: Ein komplexes System, das funktioniert, hat sich in jedem Fall aus einem einfachen
System entwickelt, das funktioniert hat. Ein komplexes System, das von
Grund auf neu entwickelt wurde, funktioniert nie und kann nicht dazu gebracht werden zu funktionieren. Man muss mit einem funktionierenden,
einfachen System neu beginnen. Eine starke Aussage, aber ist an ihr auch etwas dran? Ist es wirklich so, dass man komplexe Systeme nicht neu entwickeln kann?
Die Antwort darauf ist ausnahmsweise nicht "kommt drauf an", sondern "kann man nicht genau sagen", und zwar aus einem einfachen Grund: weder für ein komplexes System noch für ein funktionierendes System gibt es eine allgemein anerkannte Definition, die eine einwandfreie Zuordnung einzelner Fälle ermöglichen würde. Um allgemein anwendbar sein müssen derartige Definitionen abstrakt bleiben, wodurch der Einzelfall niemals eindeutig zuzuordnen ist.
Was hingegen reichlich vorhanden ist, ist anekdotische Evidenz, und die geht klar in Galls Richtung. Im Software-Bereich wäre z.B. die seit Jahren vor sich hin scheiternde Entwicklung des "Auto-Betriebssystems" von VW zu nennen, aber auch viele andere von Lidl bis Postbank, im Bereich der Organisationsentwicklung die unzähligen Konzern-Reorganisationen, von denen laut einer Studie in über 1000 Unternehmen über 50 % ihr Ziel verfehlen (die tatsächliche Zahl dürfte nochmal höher sein).
Der Gund dafür dürfte im Wesen der Komplexität liegen, die sich dadurch auszeichnet, dass in den von ihr betroffenen Systemen so viele Teilbereiche auf so unterschiedliche und unübersichtliche Art miteinander verbunden sind, dass ihre Interaktion (bzw. deren Ergebnisse) unvorhersehbar ist. Und genau hier liegt das Problem: Unvorhersehbarkeit bedeutet in diesem Zusammenhang nämlich auch, dass die Abläufe und Koordinationsmechanismen nicht im Voraus planbar sind.
Was dagegen möglich ist, ist die emergente Entstehung eines komplexen Systems. Mit anderen Worten: beginnt man mit einem noch einfachen, stabilen System kann man diesem in kleinen Schritten komplexitätsfördernde Faktoren (Größe, Kleinteiligkeit, Vielfältigkeit, Vernetzung, Dynamik, etc.) hinzufügen, deren Auswirkungen beobachten, sie ggf. kompensieren und nach dieser Stabilisierung den nächsten kleinen Schritt gehen. So wächst das komplexe System (halbwegs) kontrolliert heran.
Das ist der Hintergrund von Gall's Law. Eigentlich verständlich, es bleibt nur eine Frage zu klären: warum dieser Absolutheitsanspruch mit den kategorischen Aussagen, dass man in jedem Fall einfach beginnen mus und dass ein komplexer Gesamtentwurf nie funktionieren kann? Wäre Differenzierung nicht besser? Man kann nur raten, aber zwei Gründe liegen nah - zum einen verkauft sich Prägnanz gut und zum anderen wäre eine differenzierte Aussage eine zu vermutlich eine zu schwache Warnung.
Würde Gall's Law z.B. lauten, dass über 50 % aller Versuche komplexe Systeme zu entwerfen ihre Ziele nicht vollständig erreichen, wäre das zwar akkurater, es würde aber auch weniger Menschen davon abhalten es doch zu versuchen. Dann lieber die polemische, dafür aber deutliche Warnung. Wer auf die nicht hört, kann zumindest nachher nicht mehr sagen, es habe von nichts gewusst.
Montag, 8. Januar 2024
Bullshit Jobs and Fake Agile
Dieser Vortrag von Nigel Thurlow ist eine Provokation, allerdings eine mit einem ernsthaften Hintergrund. Anhand der Definitionen aus dem Buch Bullshit Jobs bezeichnet er Product Owner, Scrum Master und Agile Coaches als genau solche, da sie oft nur Schein- oder Alibi-Tätigkeiten ausüben, weil die Verbesserungen, die sie eigentlich bewirken sollen, durch politische oder systemische Faktoren verhindert werden. Man muss es leider zugestehen - das was er beschreibt kommt in der Realität vor.
Umgekehrt kann man seine Ausführungen aber auch als Anleitung dafür nehmen, wie es besser geht. Wenn wirkliche Agilität das Ziel ist, kann man Output-Fixierung, fehlende Systemsicht, falsche Anreizgebung, komplizierte Aufbauorganisationen und die weiteren von ihm genannten Hindernisse abbauen. Und wenn Product Owner, Scrum Master und Agile Coaches daran arbeiten dürfen, sind es auch keine Bullshit-Jobs mehr.
Donnerstag, 4. Januar 2024
Die VUCA-Verkennung
Wenn es einen Begriff gibt, der von fast jedem Agile Coach oder Scrum Master regelmässig benutzt wird, dann ist es VUCA (volatility, uncertainty, complexity, ambiguity), bzw. dessen deutsche Übersetzung VUKA (Volatilität, Unsicherheit, Komplexität, Ambiguität). Meistens verwendet um zu zeigen, aufgrund welcher Faktoren Agilität nötig ist, verbirgt sich hinter ihm oft eine interessante Wahrnehmungs-Schere: die Selbsteinschätzungen der Betroffenheit durch VUCA gehen z.T. weit auseinander.
Aus einer abstrakten Beobachterposition heraus ist die Sache klar: sich ändernde Rahmenbedingungen, Marktdynamiken und unerwartete Ergebnisse von Hypothesen-Validierungen setzen praktisch jedem Entwicklungsteam permanent zu, so dass regelmässiges Innehalten, Abgleichen des Ist-Standes mit dem Ziel und ein Abgleichen des Ziels mit der möglicherweise veränderten Realität zwingend notwendig ist, wenn man nicht am Bedarf vorbeiarbeiten und so die eigene Firma gefährden will.
Umgekehrt gibt es aber interessanterweise aus vielen Teams und Management-Runden die genau entgegengesetzte Wahrnehmung. Die Existenz von Volatilität, Unsicherheit, Komplexität und Ambiguität im eigenen Umfeld wird hinterfragt oder sogar negiert, oft mit dem Hinweis, dass die Umgebungsfaktoren seit Jahren oder sogar Jahrzehnten unverändert und stabil wären. Oft treffen diese unterschiedlichen Einschätzungen (Vuca und Nicht-Vuca) sogar im selben Kontext auf - wie kann das sein?
Um den weniger wahrscheinlichen Fall zuerst zu betrachten: es kann tatsächlich vorkommen, dass es im Umfeld von Entwicklungsteams über längere Zeiträume zu keinen unerwarteten Entwicklungen kommt. Ein Fall der mir einmal untergekommen ist war z.B. ein Intranet, das nur mit einem selbstentwickelten Browser aufrufbar war. Es wurde zwar weiterentwickelt, war aber von den Überraschungen und Neuerungen der "Aussenwelt" komplett abgekoppelt. Wie gesagt, möglich aber selten.1
Wesentlich wahrscheinlicher ist eine andere Erklärung: die Existenz der VUCA-Dynamiken wird nicht erkannt oder (ggf. unbewusst) ignoriert. Wer schon einmal in grösseren Organisationen unterwegs war, wird mit etwas Nachdenken sicher auf einige derartige Fälle kommen, die er selbst miterlebt hat. Wichtig für Ihr Verständnis ist dabei, dass diese "Betriebsblindheit" in den meisten Fällen nicht aus individuellen Schwächen entsteht, sondern systemische Gründe hat.
Einer davon kann ein Organisationsdesign sein, das die Entwicklungsteams durch ein zwischengelagertes Anforderungs- oder Produktmanagement weitgehend von Kunden, Anwendern und externen Faktoren abschirmt. Die äusseren Dynamiken finden in solchen Fällen zwar statt, die Teams sind sich ihrer aber nicht bewusst. Die Konsequenz ist ein irgendwann stattfindendes unschönes Erwachen, z.B. dadurch, dass man im Jahr 2020 herausfindet, dass COBOL nicht mehr zeitgemäss ist.2
Ein zweiter Fall wäre der, den man despektierlich als "kollektive Betriebsblindheit" bezeichnen könnte. Er liegt vor, wenn auf allen Hierarchie-Ebenen und in allen Organisationseinheiten die bestehenden Veränderungsdynamiken nicht erkannt oder als zu unwichtig eingeschätzt werden. Beispiele dafür wären die Mobiltelefon-Sparten von Siemens und Nokia, die das Potential der Smartphones nicht erkannt haben. Ihr Schicksal zeigt auch auf, welche Folgen solche Verkennungen haben können.
Ebenfalls anzutreffen ist der unschöne Fall, dass Monopolstellungen ausgenutzt werden, um Anwenderwünsche und technische Neuerungen bewusst zu ignorieren. Das wird z.B. einem grossen ERP-Entwickler immer wieder unterstellt, die meisten derartigen Fälle finden aber im Rahmen interner Anwendungsentwicklungen statt, vor allem dort, wo Konzerne ihre eigene Individualsoftware herstellen. Die Konsequenz daraus ist meistens eine zurückgehende Mitarbeiter-Loyalität, ggf. Kündigungen.3
Welche Variante es auch ist, mit den zu Beginn genannten wenigen Ausnahmen handelt es sich bei fast allen Fällen, in denen Produktentwicklungs-Einheiten glauben, nicht von den VUCA-Faktoren betroffen zu sein, um Verkennungen der Realität, die sich früher oder später rächen werden. Zumindest in einem techniknahen Umfeld sollte man sich daher besser mit ihnen beschäftigen, und zwar auch und gerade dann wenn man das Gefühl hat, ihnen gar nicht ausgesetzt zu sein.
2Diesen Moment der Erkenntnis habe ich bei einigen Teams eines Kunden miterleben dürfen
3Auch hier eine Erlebnis aus der Praxis: in einem Townhall Meeting eines Kunden fiel einmal der Satz "Wem's nicht passt, der kann ja gehen." Und die Leute gingen.
