Der agil-industrielle Komplex (III)

Bild: Pexels / Fauxel - Lizenz

Wenn die Rede vom agil-industriellen Komplex ist, ist damit in der Regel das über-kommerzialisierte Geschäft mit (weitgehend wirkungslosen) Zertifizierungen und Schnell-Schulungen gemeint, die in grossen Mengen nachgefragt, angeboten und verkauft werden (siehe hier). Abseits der öffentlichen Aufmerksamkeit hat sich aber noch ein weiteres kritisch zu sehendes Geschäftsfeld etabliert: die Vermittlung unpassender (!) externer Scrum Master und Agile Coaches in großem Ausmass.

Entstanden ist dieses Geschäftsfeld aufgrund des Fachkräftemangels, durch den Positionen lange nicht intern besetzt werden konnten, durch die in vielen Firmen fehlenden Karrierepfade dieser Rollen (die bei Beförderung einen Wechsel in andere Rollen notwendig machen) und aufgrund eines verbreiteten Unwillens, sie dauerhaft zu etablieren - oft getrieben von dem Missverständnis, dass der Scrum Master daran arbeiten würde, sich selbst abzuschaffen, und daher nicht dauerhaft benötigt würde (siehe hier).

Alleine diese Ursprünge sind bereits problematisch, darüber hinaus ist mittlerweile aber auch das darauf aufbauende Vermittlungsgeschäft hochgradig dysfunktional geworden. Und das nicht etwa, weil die Vermittler durchgehend unprofessionell oder böswillig wären, sondern wegen schwerer Systemfehler des ganzen Vermittlungsmarktes für agile Methoden-Rollen, die unpassende Stellenbesetzungen hochwahrscheinlich machen und häufig sogar (unbeabsichtigt) erzwingen.

Der erste dieser Fehler im System ist ein extrem ungesundes Verhältnis von Vermittlern zu den zu Vermittelnden. In den Datenbanken verfügbarer Scrum Master und Agile Coaches finden sich hunderte, bei grossen Vermittlungsfirmen sogar tausende von Profilen, dagegen steht bei den meisten dieser Firmen eine höchstens zweistelligen Anzahl von Vermittlern. Bereits eine Sichtung aller verfügbaren Profile scheitert bereits an fehlender Kapazität, eine Qualitätssicherung erst recht.

Als nächster Faktor kommt ein in fast allen Vermittlungsfällen gegebener hoher Zeitdruck dazu. Viele Vermittler warten nur wenige Tage oder sogar nur Stunden, bevor sie bei Ausschreibungen einige Profile einreichen und die Suche nach weiteren beenden. Zum einen, weil erfahrungsgemäss die ersten auch zuerst gesichtet werden und erhöhte Chancen haben, genommen zu werden, zum anderen um zu verhindern, sich selbst durch hunderte Profile arbeiten zu müssen.¹

Der dritte Fehler ist die Heranziehung eines möglichst niedrigen Preises (d.h. des aufgerufenen Stundensatzes) als zentrales Entscheidungskriterium, die vor allem grössere Unternehmen in ihren Richtlinien stehen haben. In der Theorie kann ein höherer Preis zwar durch Erfahrung und Expertise gerechtfertigt werden, da bei den meisten Vermittlern aber die Zeit zur gründlichen Sichtung der Profile fehlt (siehe oben) wird am Ende fast immer nur das eingereicht, was möglichst billig ist.

Ein Manager eines unserer Kunden hat diese Gesammtkonstellation einmal treffend zusammengefasst: "Wenn wir über die Vermittlungsagenturen nach externen Methodikern suchen, bekommen wir immer die billigsten unter denen, die gerade verfügbar sind, angeboten. Und dann merken wir schnell, warum die so billig sind, und warum die gerade keine Aufträge haben. Als nächstes fluchen dann alle über die Vermittler, dabei machen die das nur so, weil wir die so steuern."

Eine ausweglose Situation also? Natürlich nicht, Auswege gibt es immer, und hier sind sie sogar naheliegend: den grössten Hebel haben die Unternehmen, die externe Scrum Master und Agile Coaches suchen. Die müssen diejenigen Vermittlungsdienstleister anzählen, die ihnen nur spontan verfügbare Billigkräfte anbieten, und eher mit denen zusammenarbeiten, die nach ggf. längerer Suche gute Kandidaten bringen. Und sie müssen auch fair dafür bezahlen (beide, die Vermittler und die Externen).

Es gibt sogar Firmen, die genau das tun, allerdings sind es eher wenige im Vergleich zu denen, die die Systemfehler des Vermittlungsmarktes (unbewusst) verstärken, indem sie den Preis und die schnelle Verfügbarkeit immer wieder zu ihren Hauptentscheidungskriterien machen. Und solange sich diese Mengenverhältnisse nicht ändern, wird auch der Personalvermittlungs-Sektor des agil-industriellen Komplexes weiter dysfunktional vor sich hin florieren. Works as designed.

¹Dass bereits nach wenigen Tagen oder Stunden dreistellige Bewerberzahlen entstehen, ist nicht ungewöhnlich, und ist nochmal eine eigene Geschichte

Navigating Agile Transformations in a Crisis

Agile Transformationen hat es mittlerweile viele gegeben, und dementsprechend auch viele Erfahrungsberichte. Dieser hier gefällt mir, da er nicht nur eine der üblichen (und meistens geschönten) Erfolgsgeschichten ist, sondern klar benennt, dass es Probleme gegeben hat, und welche.

Darüber hinaus bietet die Referentin Polina Patsulda einen Blick in ihren Werkzeugkoffer, in dem sich vom Scarf Model über den Kübler Ross-Zyklus bis Radical Candor verschiedene Ansätze befinden, von denen man erfahren kann, wie sie hier eingesetzt wurden. 

Agile Success Stories: Teams Beyond Budgeting

Bild: Unsplash / Vitaly Gariev - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Ich durfte vor einiger Zeit als externer Berater eine agile Transformation eines grossen Konzerns begleiten, zu welcher eine ganze Reihe von Massnahmen gehörte: Reorganisation von Spezialisten-Gruppen zu crossfunktionalen Teams, Delegation von Verantwortung nach unten, Abbau von Vorschriften, Einführung von Retrospektiven und vieles mehr - was aber nach Aussage fast aller Beteiligten die wichtigste Änderung war, war die der Budgetierung.

Bis zu diesem Zeitpunkt waren die Budgetierungsprozesse so verlaufen wie in den meisten Unternehmen. Ein Budget "gehörte" einer Fachabteilung oder Initiative, die mit den umsetzenden Einheiten aushandelte, was sie dafür erhalten würde. Ab da wurden die Arbeitsstunden den jeweiligen Budgetposten zugeordnet - und nur an Arbeitspaketen für die noch Budget vorhanden war, durfte auch gearbeitet werden. Arbeit an nicht budgetierten Aufgaben war nicht erlaubt.

Dieses Vorgehen hatte ursprünglich einen sinnvollen Kern gehabt, so sollte sichergestellt werden, dass nur an den aus Unternehmenssicht wirklich wichtigen Aufgaben gearbeitet wurde, denn nur die hatten ein Budget erhalten. Für eine Welt sich schnell ändernder Märkte und Technologien war es aber zu langsam und zu bürokratisch - wer den Umsetzungsplan ändern wollte, musste bis zur nächsten (jährlichen) Budgetierung warten oder ausufernde Change Request-Dokumente ausfüllen.

Da das dazu geführt hatte, dass selbst offensichtlich notwendige Planungs-Änderungen nicht stattgefunden hatten, war die Trennung von Arbeitsplanung und Budgetierung eines der Hauptziele der agilen Transformation gewesen. Und glücklicherweise liess sich das Management auch von einem alternativen Ansatz überzeugen: von Beyond Budgeting, das bereits in den 70er und 80er Jahren in Skandinavien entwickelt worden war.

Im Rahmen seiner Umsetzung wurde die harte Verdrahtung von Budgets und Fachbereichs-Anforderungen aufgehoben, stattdessen wurden den Entwicklungsteams jeweils Budgets für ganze Jahre zugewiesen, die lediglich mit groben Themengebieten wie z.B. Zahlungsabwicklung oder Kundenkommunikation verbunden waren. Dass an den wichtigsten Dingen gearbeitet wurde, wurde nicht mehr über die Budgets, sondern durch eine übergreifende Priorisierung sichergestellt.

Wenn sich jetzt während der budgetierten Zeiträume Notwendigkeiten oder Prioritäten änderten, war es nicht mehr nötig, die ganze Finanzplanung anzupassen, es musste nur die übergreifende Priorisierung geändert werden. Natürlich war auch das mit Arbeit verbunden, im Vergleich zum alten Vorgehen war der Aufwand aber deutlich geringer. Dass notwendige Planungs-Änderungen aus Abneigung gegen den damit verbundenen Arbeitsaufwand verschoben wurden, kam ab da kaum noch vor.

Auch die budgetierten Zeiträume selbst wurden flexibler gestaltet. Es gab zwar weiterhin Jahrespläne, diese fanden aber auf einem eher hohen Abstraktionsgrad statt. Das Herunterbrechen erfolgte jeweils zum Beginn der Quartale, wodurch ein längeres Auseinanderlaufen aus (Budget-)Planung und Arbeits-Fortschritt vermieden werden konnte. In einer späteren Phase der agilen Transition wurde diese Quartalsplanung als Ressort-übergreifendes Big Room Planning durchgeführt.

Zur ganzen Geschichte gehört auch, dass diese Umstellungen nicht ohne Konflikt abgelaufen sind. Den Verlust der Kontrolle über die Detail-Budgetierung empfanden manche Fachbereichs-Manager auch als Verlust von Status und von Druckmitteln, die bisher zur Durchsetzung eigener Ziele gegen andere Interessen genutzt werden konnten. Am Ende konnte Beyond Budgeting deshalb auch nicht überall umgesetzt werden. Dort wo es gelungen war, führte es allerdings zu deutlich effektiverem Arbeiten.

Kommentierte Links (CXXXX)

Bild: Pexels / Ekam Juneja - 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.

John Cutler: Why Defining Teams Is So Hard

Erstaunlich oft sind es die scheinbar einfachen Dinge, die bei näherer Betrachtung nur schwer zu erklären sind. Die Definition eines Teams gehört in diese Kategorie - wann eine Gruppe ein Team ist und an welchen Kriterien man das festmachen kann, ist nicht allgemeinverbindlich geklärt. John Cutler kann das zumindest in Teilen auflösen, indem er klar macht, dass der Begriff nicht fix ist, sondern sich im Spannungsfeld verschiedener Sichtweisen bewegt - der Produkt-zentrischenen, der Nutzer-zentrischen, der Technik-zentrischen und der Kommunikations-zentrischen Sicht.

Catarina Buchatskiy, Viktoriia Honcharuk: Inside Ukraine’s Battlefield Innovation Loop

Aus der erstaunlichen Innovativität, die die ukrainische Armee notgedrungen im Kampf gegen einen deutlich grösseren Gegner entwickeln muss, könnte man mittlerweile eine eigene Kategorie machen. Catarina Buchatskiy und Viktoriia Honcharuk beleuchten hier den Aspekt, dass der andauernde Krieg es ermöglicht, militärische Produktinnovationen bereits früh in der Entwicklungsphase zu testen und basierend auf den dabei gemachten Erfahrungen zu verbessern.

Joost Minnaar: Organizational silos - what the Titanic teaches us about information that never arrives

Als Ikone der gescheiterten Technologien darf die Titanic mittlerweise als Beispiel für alle möglichen Missstände herhalten, hier bei Jost Minaar für die potentiell verheerenden Auswirkungen organisatorischer Silos. Neben dieser Storytelling-Komponente enthält der Artikel aber noch weitere interessante Gedanken, unter anderem dazu, warum diese Silos überhaupt entstehen und warum sie so schwer aufzulösen sind.

Tim Ottinger: Agile, YAGNI, Smaller Steps, Bikes and Automobiles...

Sollte irgendjemand auf die Idee kommen, nach der viralsten Grafik der agilen Bewegung zu suchen, würde er vermutlich bei dieser Visualisierung eines MVP landen, gezeichnet ca. 2012 von Henrik Kniberg:

Kidlin's Law

Eines der zahlreichen "Gesetze" des Projektmanagements ist Kidlin's Law. Es ist nicht völlig klar, woher es stammt (die manchmal zu lesende Zurückführung auf eine angebliche Romanfigur des Schriftstellers James Clavell ist falsch, sie findet sich in keinem seiner Bücher), dafür ist es aber mittlerweile weit verbreitet. Es lautet "If you write a problem down clearly and specifically, you have solved half of it", also "Wenn man ein Problem klar und konkret formuliert, hat man es schon halb gelöst".

Wegen des unklaren Ursprungs ist nicht völlig klar, was genau die ursprüngliche Intention des Verfassers war, aus der Praxis des Projektsmanagements (und hier besonders des Anforderungsmanagements) lässt sich aber eine Erklärung von Kidlin's Law herleiten. Sie baut auf dem erstaunlich häufigen Phänomen auf, dass Menschen sich so stark in die Umsetzung einer Lösung vertiefen können, dass sie das ursprüngliche Problem aus den Augen verlieren.

Klassische Beispiele für dieses Phänomen sind die Feature Requests grosser Lasten- und Pflichtenhefte, in denen oft mit erstaunlichen Detailgrad zu programmierende Workflows, Funktionen oder Formulare definiert werden, ohne das klar ist, wer das braucht, und wozu. In sehr vielen Fällen führt dieses Unwissen dazu, dass am Ende suboptimale oder unnötige Ergebnisse entstehen, deren Erstellung aber nicht unwesentlich Zeit (und damit Geld) kostet.

Ein Ausweg aus diesem Missstand besteht daraus, die ursprüngliche Problem- oder Bedarfs-Beschreibung in die Anforderung aufzunehmen oder mit ihr zu verbinden. Bei ihrer Vorstellung, bei der Erarbeitung der Umsetzung oder Lösung und bei der Vorstellung der Ergebnisse kann dann darauf referenziert werden, was idealerweise dazu führt, dass die suboptimalen oder unnötigen Ideen gar nicht erst erwogen, oder zumindest schnell verworfen werden. 

Findet das statt, sind die stattdessen erzeugten Ergebnisse mit grosser Wahrscheinleichkeit besser auf die Zielgruppe und ihre Bedürfnisse ausgerichtet und auch schneller fertiggestellt (da weniger Aufwand in gut gemeinte, aber unnötige Arbeiten fliesst). Diese Effektivitäts- und Effizienzeffekte sind es, die hinter dem Versprechen von Kidlin's Law stecken, dass eine klare und konkrete Formulierung eines Problems bereits die Hälfte des Lösungsweges beinhaltet.

In der Praxis bildet Kidlin's Law den (ggf impliziten) Hintergrund für viele der üblichen Zielsetzungs- oder Aufgabenstellungs-Formate, etwa für Produktvisionen, Unternehmensmissionen, Job to be done-Statements, User Stories, Big Bets und viele weitere. Sie alle sind Ziel- und Problemformulierungen, die als Ergänzung zu einer Anforderung oder Umsetzungsidee dafür sorgen, dass diese sich nicht versehentlich in eine nicht zielführende Richtung entwickeln.

Der Eiertanz um das Wort 'Agile'

Vor langer Zeit (genauer gesagt in den 70er und 80er Jahren) war die Welt der Softwareentwicklung noch eine andere, eine, die viele Entwickler sich heute kaum noch vorstellen können. Grosse, extrem arbeitsteilige Organisationen, deren einzelne Teile von einem mehrere Hierarchie-Ebenen entfernten Management auf bürokratische Weise ferngesteuert wurden, sollten in jahrelanger Arbeit riesige Projektpläne abarbeiten - und scheiterten. Nichts wurde fertig.

In den 90er Jahren formierte sich nach und nach eine Gegenbewegung, die um eine radikale, neue Idee aufgebaut war: Softwareentwicklung sollte am Besten durch kleine, crossfunktionale, selbstorganisierte Teams mit grossem Entscheidungsspielraum stattfinden. Diese Idee wurde unabhängig voneinander an verschiedenen Stellen entwickelt, und als die dahinterstehenden Menschen sich kennenlernten, wählten sie einen Namen dafür: Agile Softwareentwicklung.

Wie der konkrete Arbeitsmodus der derartigen Teams im Detail aussahen konnte von Fall zu Fall anders sein, es gab Extreme Programming, Scrum, Crystal, Feature Driven Development, IT-Kanban und Adaptive Development, später Two Pizza-Teams, Modern Agile, FAST, Squads, Pods und alle möglichen weiteren Vorgehensmodelle. Da sie alle die oben erwähnte Kernidee gemeinsam hatten, bezeichneten sie sich aber alle als agil (bzw. 'Agile").

Fast Forward in die Zeit kurz nach dem Jahr 2020. Erneut erkannten viele Firmen (vor allem solchem die mit KI entwickelten), dass kleine, crossfunktionale, selbstorganisierte Teams mit grossem Entscheidungsspielraum der beste Weg waren, um Software zu entwickeln. Erneut wurden dafür verschiedene Vorgehensmodelle entwickelt, etwa Tiny Teams, Micro Teams und Tiger Teams. Aber etwas war neu: die Erfinder dieser Modelle bezeichneten sie nur noch selten als agil.

Der Grund dafür liegt in dem Phänomen der Management-Moden. Obwohl die agilen Frameworks in ihrem Ursprung eben keine waren, wurden sie in den 2010er Jahren vielfach dazu verfremdet. Das hatte aber auch Vorteile: wer Management-Moden nutzt, kann einfacheren Zugang zu Budgets, Entscheidungsgremien und Karrieren bekommen. Erst als Mode wurde agiles Arbeiten flächendeckend erlaubt, eine Lektion, die viele Entwickler und Tech-Manager lernten und verinnerlichten.

Mit Folgen: seit kurz nach 2020 ist agiles Arbeiten keine Management-Mode mehr, sondern wurde in dieser Funktion durch KI abgelöst. Wer in Teams der oben genannten Art arbeiten will, aber keine Lust auf mühsame Überzeugungsarbeit hat, kommt daher seitdem am einfachsten ans Ziel, wenn er sein Vorgehensmodell einfach umbenennt: inhaltlich mag es das Gleiche sein, aber das Label lautet jetzt nicht mehr Agile, sondern KI - und schon stehen die Türen wieder offen.

Diese Hintergrund-Mechaniken sind einer der Hauptgründe dafür, dass zur Zeit ein Eiertanz um das Wort 'Agil' stattfindet. Jeder, der sich ein bisschen mit dem Thema beschäftigt hat, weiss, dass das was gerade in der KI-getriebenen Entwicklung stattfindet, agiles Arbeiten ist. Es ist aber auch offensichtlich, dass der Moden-Begriff, mit dem man seine Wünsche einfacher durchsetzen kann, gerade ein anderer ist. Darum wird oft gerade dort, wo man agil arbeiten möchte, der Begriff kaum benutzt.

Aus einer zweckrationalen Perspektive ist das erstmal in Ordnung. Solange das Ergebnis ist, dass man einen sinnvollen Arbeitsmodus wählen darf, ist der Weg dahin sekundär. Und selbst aus einer puristischen Sicht kann man dieser Entwicklung etwas Positives abgewinnen - durch den Verlust seines Moden-Status kann der Begriff Agile jetzt von unsinnigen Auswüchsen und Erwartungen befreit werden. Und wenn das gelingen sollte, kann man ihn auch wieder auf die Tiny- und Tiger-Teams anwenden.

Success Disaster

Dass Erfolg (in diesem Fall durchschlagender Erfolg eines Unternehmens in einem Markt) etwas ausschliesslich Positives ist, ist ein zunächst naheliegender Gedanke. Die Realität verhält sich allerdings oft wesentlich komplexer, bis zu dem Punkt, an dem gerade grosse Erfolge zu schwerwiegenden neuen Problemen führen. Der Fachbegriff für dieses Phänomen ist das 'Success Disaster', sinngemäss übersetzbar mit 'katastrophalem Erfolg'. Spannend, und viel zu selten beleuchtet.

Wie im Fall vieler andere Begriffe, die nah an der Alltagssprache sind, ist es beim Success Disaster nicht ganz einfach, die Urheberschaft zuzuordnen. Häufig genannt wird aber der britische Informatiker, Roger Needham, der damit im Jahr 1999 den unerwartet hohen Aufwand für die Lehrkräfte der englischen Fernuniversität 'Open University' beschrieb, der sich aus den in die tausende gehenden Anmeldezahlen der damals ersten Online-Seminare ergab.

Obwohl grundsätzlich auch in andere Kontexte übertragbar, fand der Begriff vor allem im Umfeld der Softwareentwicklung weite Verbreitung, und hier vor allem im Endkundengeschäft von Online Shops, Social Media-Plattformen, Online-Spielen, Streamingdiensten und ähnlichen Angeboten, deren Gemeinsamkeit ist, dass sie auf Infrastrukturen und Entwicklungs- oder Support-Teams beruhen, deren Arbeitskapazität endlich ist. Steigt die Zahl der Nutzer sprunghaft an, drohen sie daher zu kollabieren.

Bekannte Success Disaster sind etwa der mehrere Tage andauernde Zusammenbruch der Konzert-Verkaufsplattform Ticketmaster unter dem Ansturm von Taylor Swift-Fans, der legendäre Fail Whale aus der Frühzeit von Twitter oder die Ausfälle praktisch aller grossen Gaming-Stores nach der Veröffentlichung des Computerspiels Hollow Knight: Silksong. Zu diesen bekannten dürften ausserdem zahllose unbekannte Beispiele kommen.

Der theoretisch einfachste Weg zur Vermeidung derartig katastrophaler Erfolgsauswirkungen ist natürlich, von Anfang an ausreichend Infrastruktur (und ggf. Personal) vorzuhalten, was aber teuer, und bei ausbleibendem Massen-Erfolg eine komplette Fehlinvestition sein kann. Ein flexiblerer Weg kann FinOps sein, ein Ansatz zu dem unter anderem gehört, Angebotsspitzen automatisch zu erkennen und dann situativ Cloudspeicher dazuzubuchen (ggf. auch automatisiert).

Der schlechteste unter allen möglichen Wegen besteht dagegen daraus, die Anzahl der Zugriffe zu reduzieren indem ein Teil von ihnen geblockt wird, seien es solche aus bestimmten geografischen Regionen, solche ohne bestehenden Account, solche ohne bestimmte Vorbestellungs- oder Rabattcodes, etc. Das Success Disaster wird dadurch zwar eingedämmt, ob die ausgesperrten und deshalb frustrierten Kunden jemals wieder zurückkommen, ist aber unklar.

Ein Bild sagt mehr als 1000 Worte (LVII)

Wenn man sich die letzten Jahre vor Augen führt, in denen wir eine globale Pandemie, den Durchbruch von 3D-Druck und KI in den Massenmarkt sowie mehrfache schwere Störungen der globalen Lieferketten erlebt haben, erscheint dieses Bild von Tom Fishburne naheliegend. Allerdings ist es älter, bereits aus dem Mai 2020 (kurz nach den ersten Covid19-Lockdowns).

Das Bemerkenswerte daran: Fishburne schrieb damals unter diesem Bild, dass er das turbulente Jahr 2020 für keine Ausnahme hielt, sondern, dass bereits die aus heutiger Sicht ruhigen und stabilen Jahre vorher ebenfalls von starken Disruptionen geprägt waren. Darum war für ihn schon damals die Achterbahn die passende Analogie zur Wirtschafts-Normalität.

From 'NoOps' to 'NoDev' Era

In der Softwareentwicklung ist es seit dem eintreten von KI-Anwendungen in den Massenmarkt zu einem geradezu atemberaubenden Innovations und Disruptions-Tempo gekommen - und keiner weiss wo es hinführen wird. Adrian Cockcroft skizziert hier eines der interessanteren Zukunftsszenarien: ein grosser Teil der Jobs wird sich vom Schreiben der Software zu Plattform-Services verlagern, durch die sichergestellt wird, dass KI-generierter Code sicher, verlässlich, verständlich, veränderbar, Archtitektur-Standards entsprechend und Audit-sicher ist.

Was zu den oben genannten Zwecken wichtig wird um die KI-Agenten in die richtige Richtung zu lenken ist für Cockcroft ironischerweise genau das, was vor einem Vierteljahrhundert am Anfang der agilen Bewegung stand: systemisches Denken, Clean Code, einfach verständliche Anforderungen, gute Testabdeckung und kollaboratives Arbeiten - nur dass das es jetzt von Agenten angewendet wird statt von Menschen.

Der Wettlauf in die Nazi-Vergangenheit

Die Geschichte von den zwei Wettbewerbern, die um die Wette an einer gleichen Software bauen, um als erster eine Marktlücke besetzen zu können, ist mittlerweile altbekannt. Und genau so alt sind die Zweifel: ist das wirklich jemals irgendwo so passiert? Seit kurzem können wir das nicht nur bejahen und mit einem Beispiel belegen, sondern sogar mit einem besonders wilden. Es geht um eine Branche im Umbruch, um eine einmalige Gelegenheit, um künstliche Intelligenz - und um den Nationalsozialismus.

Beginnen wir mit der Branche im Umbruch, mit den Medien. Bereits seit Jahrzehnten gehen die Zahlungsbereitschaft der Leser und mit ihnen auch Umsätze und Gewinne zurück. Gleichzeitig wird der Wettbewerb härter - die Nachrichten gibt es einen Klick weiter auf einer anderen Website umsonst. Um Abonnements zu verkaufen brauchen die Verlage also exklusive Inhalte, und idealerweise solche, die kein Wettbewerber hat, und die man auch nicht so einfach abschreiben kann.

Im März 2026 gab es auf einmal eine Gelegenheit, sich solche Inhalte zu erschaffen. Das US-amerikanische Nationalarchiv veröffentlichte die im zweiten Weltkrieg beschlagnahmte Mitgliederdatei der NSDAP, allerdings in einem nur aufwändig zu durchsuchenden Format. Die Chance: der Erste, der sie einfach durchsuchbar machen würde, konnte diese Suche hinter eine Paywall stellen und damit neue zahlende Abonennten gewinnen, die die eigene Familiengeschichte überprüfen wollten.

Zwei der grössten deutschen Medien nahmen die Herausforderung an, eine solche Lösung als erster zu entwickeln: die Zeit und der Spiegel. Und das Ergebnis dieses Wettrennens war eindeutig: am 18.03. ging das Archiv in den USA online, schon am 7. April veröffentlichte die Zeit ihre Suchmaschine, der Spiegel folgte erst am 7. Mai. Wer wissen wollte, ob Oma und Opa Nazis waren, hatte da schon längst ein Abonnenement der Zeit gekauft, das Marktfenster war bereits weitgehend geschlossen.

Wie genau es geklappt hat, in nur drei Wochen eine solche Software zu entwickeln hat die Zeit zwar nicht im Detail beschrieben (nur dass sie bei der Programmierung die KI Gemini benutzt hat), es ist aber offensichtlich, dass in einem agilen Modus gearbeitet wurde. Für Anforderung, Entwicklung, Test und Rollout standen schliesslich jeweils nur wenige Tage zur Verfügung, am Ende ist dabei das alte Versprechen der agilen Bewegung, Software in 30 Tagen zu erstellen, sogar unterboten worden.

Die ganze Geschichte ist ein schönes Beispiel dafür, dass in einem IT-Projekt die auf den ersten Blick gar nicht so lange Differenz von vier Wochen entscheidend für den Erfolg eines Produkts oder Features sein kann. Und wer weiss - vielleicht sitzt irgendwo beim Spiegel gerade ein Manager und ärgert sich darüber, dass sein Unternehmen moderne Arbeitsweisen lange eher reflexhaft verdammt hat, als ihnen mit Offenheit und Interesse gegenüberzutreten.

Agile Success Stories: Testlabor as a Service

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Die heutige trug sich in einem Robotik-Startup zu. Wie in derartigen Firmen üblich war am Anfang alles klein und überschaubar gewesen, was sich mit zunehmendem Wachstum aber nach und nach änderte. Besonders häuften sich die Probleme, nachdem die MVP-Phase überwunden war. Um die funktionale Sicherheit der Embedded Software (des Betriebssystems) zu gewährleisten waren jetzt umfangreiche Tests nötig, die schon bald so lange dauerten, dass kaum noch Zeit für die Entwicklung blieb.

Um das nachvollziehbar zu machen: anders als im Fall reiner Softwareprodukte ist das Testen von Robotern nur schwer zu beschleunigen und zu parallelisieren. Dass z.B. ein Sensor nach zu langem Dauerbetrieb des Roboters der Software ein Signal übermittelt, das dort eine Warnung vor drohender Materialermüdung auslöst, kann nur in einem sehr langwierigen Testdurchlauf validiert werden, der nur in Gänze und ohne Unterbrechung ausführbar ist.

Aufgrunddessen besteht ein Grossteil der Robotik-Entwicklung aus Testläufen in einem Testlabor, was in grossen Organisationen das Risiko einer der folgenden beiden Auswirkungen hat: entweder das Entwicklungsteam betreibt auch das Labor, was aufwändig ist und ständige Kontextwechsel zur Folge hat, oder die Tests werden von einem separaten Test-Team durchgeführt, was zu einer Wasserfall-artigen Silo-Bildung führt, die in der modernen Produktentwicklung eigentlich nicht mehr gewollt ist.

Um es nicht dazu kommen zu lassen, wählten wir in dem erwähnten Robotik-Startup einen anderen, eher ungewöhnlichen Weg. Es gab zwar ein separates Team, das für das Testlabor zuständig war, es führte die Tests aber nicht selbst aus, sondern war nur dafür zuständig das Labor zu betreiben und zu erweitern. Seine Nutzung wurde den anderen Teams überlassen, die es quasi als Plattform-Dienstleistung nutzen konnten. "Test Lab as a Service" wurde es auch scherzhaft genannt.

Konkret sah das so aus, dass am Rand der Testfläche eine ausreichende Zahl der neuesten Generation von Hardware-Prototypen stand. Auf einer grafischen Weboberfläche wurde angezeigt welcher von ihnen gerade verfügbar war und welche Software-Version auf ihm lief. Sobald es eine neue Version dieser Betriebssoftware gab, konnte das jeweilige Entwicklungsteam sie auf einen der Roboter-Prototypen laden, eine Testfahrt starten und sich dann erstmal mit anderen Dingen beschäftigen.

Die im Folgenden stattfindende Testfahrt wurde von verschiedenen Kameras aufgezeichnet. Am Ende der Fahrt wurden das so entstandene Video, die Telemetriedaten der Sensoren des Roboters und die Monitoring-Daten der Software in einem gemeinsamen Ordner abgelegt und das Entwicklungsteam wurde benachrichtigt. Die Hard- und Software, die diese Daten automatisiert sammelte und zur Verfügung stellte, war Teil der Dienstleistung des Plattform-Teams für die Entwicklungsteams.

Die positiven Folge dieser Aufteilung waren spiegelbildlich zu den oben genannten Risiken. Die Entwicklungsteams konnten sich auf die Entwicklung und das Testen ihrer Features konzentrieren und mussten sich nicht mit dem aufwändigen Betreiben des Testlabors befassen. Das Plattformteam dagegen hatte einen klaren Focus auf dem zu Verfügung stellen dieses Labors, ohne selbst mit dem Durchführen der Testfahrten beschäftigt zu sein (von gelegentlichem Troubleshooting abgesehen).

Durch dieses Vorgehen entstand ein hochgradig effektiver und effizienter Entwicklungsprozess, der von allen Beteiligten als einer der besten gelobt wurde, den sie in der Embedded Software bis dahin erlebt hatten. Und als Nebeneffekt führte die automatisierte statt manuelle Überwachung der Testläufe dazu, dass ein immer grösser werdender Schatz an Daten entstand, der für wiederholte Auswertungen zur Verfügung stand. Heute, mit KI, wären damit nochmal ganz andere Dinge machbar.

Kommentierte Links (CXXXIX)

Bild: Pexels / Ekam Juneja - 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.

Tom Geraghty: The Vasa

Die Geschichte des schwedischen Kriegsschiffs Vasa, das unmittelbar nach seinem Stapellauf gesunken ist, ist eines der berühmtesten gescheiterten Grossprojekte aller Zeiten. Bei Tom Geraghty findet man nicht nur Bilder ihres Wracks, sondern eine gute Zusammenfassung der verschiedenen Faktoren, die dazu führten, dass es trotz offensichtlich nicht gegebener Seetüchtigkeit auf das Wasser geschickt wurde. Ihr Zusammenspiel ergibt das "Vasa-Syndrom", das sich auch auf andere Vorhaben übertragen lässt.

Mike Fisher: Build the Right Thing

Eine der besten Erklärungen des Unterschieds von Effizienz und Effektivität ist die, dass Effizienz "build the thing right" bedeutet, Effektivität dagegen "build the right thing". Wem das noch zu abstrakt ist, der kann bei Mike Fisher nachlesen, was es bedeutet, das Richtige zu bauen. Und das erklärt an einem sehr anschaulichen Beispiel, der Entwicklung des ersten motorengetriebenen Flugzeugs im Amerika des frühen zwanzigsten Jahrhunderts.

Jurgen Appelo: Value Stream Examples - From Signal to Impact

Value Streams, Value Stream Maps und ähnliche Konzepte sind Klassiker der Organisationsoptimierung, aber Jurgen Appelo hat völlig recht wenn er sagt, dass den meisten von ihnen etwas fehlt: die Abschnitte nämlich, die sich vor und nach der produkterzeugenden Organisation befinden. Oder mit anderen Worten: der Markt, dessen Bedürfnisse, Zahlungsbereitschaften und Nutzerverhalten elementar für den Erfolg jedes Produktes sind.

Itamar Gilad: 5 Ways Product Discovery Breaks Down (Part I), (Part II)

Die beiden Teile dieser Ausführung von Itamar Gilad haben jeweils ihren eigenen Wert. Im ersten klärt er darüber auf, was Product Discovery eigentlich ist (inclusive einiger häufiger Missverständnisse), im zweiten zeigt er auf, warum sie in vielen Unternehmen nicht funktioniert. Besonders nützlich dabei ist, dass er jeden der häufigsten Gründe dafür nicht nur beschreibt, sondern auch erklärt, wie man ihn vermeiden oder beheben kann.

Karl Scotland: Strategic Insouciance - Why Too Much Focus Can Kill Emergence

Zum Schluss ein kleiner Gedankenanstoss: in praktisch jedem Management-Ratgeber wird zu radikaler Focussierung geraten, um nur die wirklich wichtigen Dinge zu tun, die aber dafür richtig. Karl Scotland hat völlig recht wenn er sagt, dass das auch schädlich sein kann - dann nämlich, wenn der Focus zum Tunnelblick wird, und man neue Ideen und Impulse dadurch Ignoriert. Er rät dazu, Focussierung anders zu interpretieren: nicht notwändigerweise auf nur ein einziges Thema, aber darauf, nicht zu viele Themen zur selben Zeit anzugehen.

Freie Vorgesetzten-Wahl

Wenn man sich anschaut, wie die erfolgreichen agilen Vorzeigeunternehmen organisiert sind, bekommt man nur selten ein vorbildhaft implementiertes agiles Framework zu sehen, dafür aber viele spannende Inspirationen. Diese hier verdanke ich Thuan Pham, dem ersten CTO von Uber, der im Pragmatic Engineer-Podcast von einer bemerkenswerten Praxis dieser Firma erzählt:¹ wer will, kann jederzeit und ohne Hindernisse seinen Vorgesetzten wechseln.

Dass diese Möglichkeit ein deutlicher Paradigmenwechsel im Vergleich zur üblichen Geschäftswelt ist, ist offensichtlich. In fast allen anderen Firmen ist der Vorgesetzte jemand, den man im Wortsinn vorgesetzt bekommt. Man hat bei der Zuteilung wenig bis gar kein Mitspracherecht, er entscheidet über Versetzungen und Beförderungen (oder muss zumindest beteiligt werden) und ein Wechsel zu einer anderen Führungsperson ist meistens nur mit grossem Aufwand möglich.

Ist die Beziehung zum eigenen Vorgesetzten gut, ist das Alles kein Problem, ist sie dagegen eher schlecht, kann es hochproblematisch sein. Aufgrund des gegebenen Abhängigkeitsverhältnisses wird eine Unzufriedenheit oft gar nicht oder erst zu spät thematisiert. Die freie Vorgesetzten-Wahl bei Uber ist laut Pham eine bewusste Massnahme gewesen, um dieses Macht-Ungleichgewicht aufzubrechen und eine Beziehung auf Augenhöhe zu ermöglichen.

Die offensichtlichsten Folgen hat das im Fall eines Vorgesetzten, der eine sehr volatile oder ständig schrumpfende Mitarbeiter-Gruppe hat. Für das obere Management ist beides ein deutlicher Indikator dafür, dass hier möglicherweise ein Führungsproblem vorliegt, um das man sich kümmern sollte - und für jeden Mitarbeiter, der gerade einen neuen Vorgesetzten sucht, ein Zeichen dafür, dass er sich erst über diese Führungskraft informieren sollte, bevor er sie auswählt.²

Es gibt aber auch in konfliktfreien Konstellationen Vorteile, die sich aus der freien Vorgesetzten-Wahl ergeben. So gibt es auch in dieser Rolle unterschiedliche Stärken, seien sie fachlich, technisch, sozial oder sonstwie geartet, wodurch es Vorteilhaft sein kann, immer zu demjenigen zu wechseln, dessen Profil den aktuellen eigenen Bedürfnissen am Besten entspricht (gegebenenfalls nur temporär, um irgendwann zurückzukommen. Auch das ist ja möglich).

Natürlich lässt sich diese Praktik nicht in jedes andere Unternehmen übertragen, je nach Branche, Unternehmensgrösse, Art der Arbeit, beruflichem Spezialisierungsgrad und Betriebsverfassung kann das einfacher oder schwerer sein. Es ist aber zumindest etwas, was man samt möglicher Vor- und Nachteile erwägen und für sich ausprobieren kann. Und wenn man es ausprobiert, hat es in jedem Fall das Potential zu sehr deutlicher Flexibilisierung und kultureller Veränderung eines Unternehmens.

¹Wobei unklar bleibt, ob diese Praxis auch nach seinem Ausscheiden aus dem Unternehmen fortgeführt wurde
²Und natürlich kann auch das ständige Wechseln eines Mitarbeiter zu neuen Vorgesetzten ein Indikator für Probleme sein

The Agile Bookshelf: Managementmoden nutzen

Bild: Unsplash / Tom Hermans - Lizenz

"Das ist doch nur wieder eine Management-Mode, die ist bald wieder vorbei." Praktisch jeder, der an Veränderungsvorhaben in grossen Organisationen beteiligt war, wird diese Aussage schon einmal gehört haben, egal ob es im Einzelfall um Digitalisierung, Lean, Agile, KI oder ein sonstiges Thema geht. Woran zu erkennen ist, ob es sich wirklich um eine Mode handelt, und was der beste Umgang damit ist, bleibt allerdings in den meisten Fällen unklar.

Dankenswerterweise gibt es allerdings neben diesen Bauchgefühl-Aussagen auch wissenschaftliche Auseinandersetzungen mit diesem Thema, unter anderem in Form des empfehlens- und lesenswerten Buchs Managementmoden nutzen (Eine sehr kurze Einführung) von Stefan Kühl, einem Soziologie-Professor der Universität Bielefeld, der schon seit längerem die Funktionsweisen grosser Unternehmen und sonstiger Organisationen untersucht.

Der erste und offensichtlichste Mehrwert dieses Werkes ist, dass in ihm definiert wird, was eine Management-Mode überhaupt ist, nämlich eine aktuell populäre Vorstellung darüber, wie Firmen, Behörden, etc. organisiert werden können, häufig verbunden mit Annahmen, dass sie auch die aktuell bestmögliche Antwort auf die Herausforderungen einer Gegenwart ist, von der vergangene Management-Konzepte noch nichts wissen konnten, und auf die sie daher nicht vorbereitet sind.

Darüber hinaus ordnet Kühl auch ein, warum derartige Moden für viele Manager so anziehend sind, angefangen von der scheinbar universellen Anwendbarkeit über die Lieferung einfacher Antworten auf komplexe Probleme bis hin zu einer mitgelieferten Legitimation durch eine auf den ersten Blick wissenschaftlich scheinende Fundierung und eine häufige Einbettung in idealistische, weit über die Gewinnoptimierung hinausgehende Ziele (Fortschritt, Nachhaltigkeit, Humanismus, etc).

Neben diesen eher theoretischen Erwägungen bietet das Buch aber auch eine konkrete Anwendbarkeit für Praktiker. Wie sein Titel erkennen lässt liefert es auch Ansätze zur Nutzung von Management-Moden in Veränderungsprozessen. So kann man zum Beispiel erkennen, wie sich durch ihren gezielten Einsatz Veränderungsbereitschaft steigern lässt oder wie man ein Vorhaben, dass man schon seit langem plant, in Moden-getriebenen Programmen unterbringen kann.

Passend für die zeitlich stark verplanten Angehörigen grosser Organisationen ist Managementmoden nutzen (Eine sehr kurze Einführung) auch tatsächlich von überschaubarer Länge. Ohne Inhalts- und Lieraturverzeichnis hat es gerade einmal 80 Seiten, lässt sich also relativ schnell durchlesen. Und für alle, die sich des Lesens von Büchern entwöhnt haben, ist Kühls Buch auch Gegenstand der aktuellen Staffel seines Podcasts Der ganz formale Wahnsinn, in dem man sich alles auch anhören kann.

Echtes Nutzerverhalten

Mit sichtbarer Zufriedenheit stellte sich der Geschäftsführer Wirtsrat vor seine Belegschaft. Viele Themen wollte er anlässlich der Frühjahrstagung seiner Organisation ansprechen, aber eines ganz besonders und zuerst: seine Freude darüber, dass die Sachbearbeiter jetzt endlich die Vorteile des im letzten Jahr angeschafften teuren neuen CRM-System akzeptierten und seine intelligenten Funktionen benutzten. Er hatte keine Ahnung, wie es sich in Wirklichkeit verhielt.

Ich habe den Geschäftsführer Wirtsrat (der in Wirklichkeit anders hiess) vor langer Zeit in einem meiner ersten Jobs kennengelernt. Er war ein eher klassisch sozialisierter und denkender Vorgesetzter, der überzeugt war, dass zu viel Transparenz und Mitsprache Entscheidungen nur verzögern würden. Aus diesem Grund hatte er das besagte CRM-System auch alleine ausgewählt und gekauft, ohne vorher mit denen zu reden, die es später benutzen würden. Er wusste schliesslich, was gut war.

Die Anwender hatten eine ganz andere Meinung. An sich fanden sie das System ähnlich gut wie das alte, nur eine Funktion fanden sie extrem nervtötend: beim Öffnen jeder einzelnen Ebene des zentralen Ordnerbaums erfolgte ein Ladevorgang von mehreren Sekunden, während denen die "intelligenten Funktionen" geladen wurden - Hilfs- und Hinweis-Funktionen, die sich alle etwa auf dem Niveau von Karl Klammer bewegten: gut gemeint, aber schon nach Kurzem sehr nervig.

Der eigentliche schlimme Nervfaktor war aber ein anderer: es waren die Ladevorgänge, die sich bei tieferen Ordnerbäumen auf bis zu einer halben Minute summieren konnten. Ständig hörte man im Büro fluchende Mitarbeiter, die ewig darauf warteten, endlich bei der Zielebene anzukommen. Der Geschäftsführer Wirtsrat hielt allerdings starr an seiner Meinung fest: die intelligenten Funktionen wären eine wertvolle Hilfe und das neue CRM wäre deswegen gut.

Auch ich war schon nach kurzem von den langen Ladezeiten genervt, und besonders an einem Morgen dauerte alles gefühlt doppelt so lange wie sonst. Ohne gross darüber nachzudenken überbrückte ich die Zeit durch schnelles, ununterbrochenes Klicken auf den Apply-Button, als auf einmal etwas Unerwartetes geschah - eine Systemmeldung tauchte auf und zeigte an, dass das System wegen zu vieler Eingaben überlastet war, weswegen die intelligenten Funktionen temporär ausgeschaltet würden.

Auf einmal waren die Ladezeiten weg. Mit ihnen zwar auch die Hilfsfunktionen, aber die waren wie gesagt ohnehin verzichtbar. Nach dem Neustart war zwar alles wieder da, aber nach kurzem Ausprobieren stellte sich heraus, dass man mit erneuten Dauerklicken die Hilfsfunktionen wieder vorübergehend deaktivieren konnte. Schon nach kurzem hatte sich der Trick herumgesprochen, und der Arbeitstag fast aller Kollegen begann mit schnellem Klicken, gefolgt von zufriedenen Seufzern.

Dem Geschäftsführer Wirtsrat hat während meiner Zeit in seiner Organisation niemand gesagt, dass praktisch jeder Mitarbeiter an jedem Morgen als erstes die intelligenten Funktionen deaktivierte, um während des restlichen Tages produktiv arbeiten zu können. Er hielt die plötzlich stark zurückgehenden Beschwerden für ein Zeichen von Akzeptanz, weshalb es diese auch stolz auf der zu Beginn erwähnten Frühjahrstagung vor allen Mitarbeitern erwähnte. Die Mitarbeiter grinsten und schwiegen.

Natürlich war das ein Extremfall, in verschiedenen Abwandlungen findet man derartige Funktionen und Manager aber in vielen, vielen Organisationen. Und für mich ist dieses Erlebnis, bei dem für viel Geld ein neues System angeschafft wurde, das praktisch alle Mitarbeiter so nervte, dass sie es täglich durch destruktives Nutzerverhalten deaktivierten, ein prägendes gewesen. Davon, ein neues System zwangsweise, ohne Einbeziehung der Nutzer einzuführen, habe ich seitdem immer abgeraten.

Der Krankenstand als Kulturwandel-KPI

Selbst wenn man denken sollte, nach über 15 Jahren in der Beratung hatte man so langsam alles gesehen - manchmal wird man doch überrascht. So war es bei mir vor kurzem während eines Termins mit einer anderen Beratung, die in einigen ihrer Kundeneinsätze eine ganz erstaunliche Erfolgs-Messgrösse hat: den Krankenstand. Und es handelt sich nicht etwa um eine Gesundheitsberatung, sondern um eine, die sich auf Kulturwandel-Programme spezialisiert hat.

Bei genauerem Nachdenken ist es aber (leider) nur folgerichtig, dass jemand auf die Idee kommt, körperliche Gesundheit und Unternehmenskultur zu verbinden, denn tatsächlich können bestimmte Arten der Unternehmenskultur so belastend sein, dass man von ihnen krank wird. Über die Jahre habe ich selber genug Beispiele dafür erleben dürfen (zum Glück nicht in der eigenen Firma, sondern auf  verschiedenen Kundeneinsätzen).

Die offensichtlichste Fall dürfte das sein, was man im Englischen die Hustle-Kultur nennt. In ihr werden Überstunden, Wochenendarbeit und Erreichbarkeit in den Ferien als etwas Positives gesehen und von den Mitarbeitern erwartet, nicht nur vom Management sondern auch von ihren jeweiligen Kollegen. Dass das das Risiko körperlicher Erschöpfung mit sich bringt ist offensichtlich, bis zum irgendwann folgenden Zusammenbruch.

Ähnlich gelagert ist die Helden-Kultur. In ihr Herrscht die Annahme vor, dass bestimmte Aufgaben nur von bestimmten Menschen erledigt werden können, in der Regel vom jeweils grössten Spezialisten des jeweiligen Sachgebiets. Weil die dann das Gefühl vermittelt bekommen (oder selbst haben) unersetzbar zu sein, opfern sie sich und ihre Freizeit wieder und wieder auf, auch hier bis zum irgendwann eintretenden Zusammenbruch.

Ein dritter und nochmal unschönerer Fall ist die Sklavenhalter-Kultur. In ihr hat ein Unternehmen (bzw. dessen Führung eine derartige Kontrolle über bestimmte Teile des Arbeitsmarktes oder bestimmte Karriereoptionen, dass sie es sich leisten können ihre Angestellten auszubeuten, in die Akkord-Arbeit zu treiben oder Ähnliches mit ihnen zu machen. Auch hier mit der irgendwann eintretenden Folge körperlicher Erschöpfung und daraus folgender Erkrankung.

Subtiler aber nicht weniger schlimm sind toxische Unternehmenskulturen. Getrieben von niederen Motiven (Neid, Vorurteilen, Sadismus, o.Ä.) behandeln sich die Mitarbeiter gegenseitig schlecht, sabotieren sich, verleumden sich oder tun sich ähnlich schlimme Dinge an. Die Folge davon ist weniger die körperliche Abstumpfung sondern eher die Entwicklung psychischer Leiden, die dann irgendwann in Form psychosomatischer Erkrankungen in Physische umschlagen können.

Zuletzt sind auch Kafkaeske Kulturen weiter verbreitet als man denken sollte. In ihnen sorgen Bürokratie und Regelfetischismus dafür, dass immer weniger Arbeitszeit sinnvoll verbracht wird und immer mehr in unnötige Termine, Prozesse und Dokumentationen fliesst. Das Resultat ist die Entfremdung der Menschen von ihrer Arbeit, bis zu dem Punkt an dem sie an permanenter Sinnlosigkeit geistig zerbrechen und Schaden nehmen.

All diese Varianten von Unternehmenskultur treiben auf ihre jeweilige Weise den Krankenstand hoch und in allen Fällen ist es folgerichtig so. dass ein Kulturwandel ihn (mit etwas zeitlichem Versatz) senken kann, wenn es ihm gelingt, die zugrundeliegenden Ursachen zu beheben. Wie das geschehen kann ist dann von Fall zu Fall anders, von der Abschaffung absurd sinnloser Regeln über das Herunterfahren der Arbeitslast bis zur Entlassung sadistischer Manager kann vieles helfen.

Eine externe Kulturwandel-Begleitung kann tatsächlich viel in diese Richtung bewegen, von der Identifikation von Ursachen, die aufgrund interner Betriebsblindheit gar nicht mehr auffallen, über die Analysen systemischer Zusammenhänge bis hin zur Kompetenz in Konfliktmoderation oder Beteiligungsformaten. Vieles davon könnten ich oder meine Kollegen sicher auch anbieten, und ich kann mich sogar auch an sinkende Krankmeldungen erinnern.

Was ich mich aber nur mit Überwindung trauen würde, ist diese zu einem Haupt-Erfolgskriterium meiner Arbeit zu machen, da wirken für mich zu viele Faktoren mit, die ich nur wenig oder gar nicht beeinflussen kann. Diese Zahl im Blick zu halten und über die Zeit zu verfolgen könnte aber eine gute Idee sein, im Rahmen von Kulturwandel-Initiativen ist sie mindestens ein starker Indikator, den man als einen von mehreren Inputs nutzen kann.

Netflix’s Secret to Safe Automation at Scale

Zu den grossen Problemen der Softwareentwicklung gehört ihr hoher Abstraktionsgrad, der einfache Erklärungen und Visualisierungen unglaublich schwer macht. Angesichts dessen ist dieser Vortrag von Aubrey Chipman und Roberto Perez Alcolea etwas Besonderes, da in ihm selbst Fachbegriffe wie Direct/Transitive Dependencies und Artifact Observability sichtbar gemacht und lebhaft erklärt werden.

Was mich übrigens ursprünglich in dieses Video hineingezogen hat, ist der direkt am Beginn eingebrachte Spoiler "This is not an AI talk". Nichts gegen künstliche Intelligenz, die revolutioniert gerade die Softwareentwicklung. Aber in letzter Zeit waren mir die meisten Konferenzen zu Hype-getrieben und zu monothematisch. Es gibt genug andere spannende Themen, so wie dieses hier.

Wie man (fast) ohne Prozesse arbeitet

Es ist eine Traumvorstellung vieler Angestellter - ein Berufsleben ganz ohne Regelmeetings, fest definierte Prozesse oder sonstige einengende Strukturen. Eines in dem man "einfach nur arbeiten" kann. Und es gibt sogar Firmen, denen das anscheinend weitgehend gelungen ist, z.B. WhatsApp vor der Übernahme durch Facebook. Wie genau das ausgesehen hat kann man sich jetzt anhören, denn die damalige WhatsApp-Mitarbeiterin Jean Lee berichtet im Pragmatic Engineer Podcast davon.

Der erste, und vermutlich wichtigste, Punkt den man von ihr lernen kann ist, dass WhatsApp damals eine kleine Firma war, und sich bewusst entschieden hat, klein zu bleiben. Zum Zeitpunkt der Übernahme gab es 30 Angestellte, davon 20 in der Softwareentwicklung. Eine derartig überschaubare Gruppe ist natürlich viel einfacher ad hoc und auf Zuruf zu koordinieren. Um so klein bleiben zu können, wurde sogar bewusst auf zusätzliche Features und Marktsegmente verzichtet.

Im Zusammenhang damit stand, dass alle Firmenangehörigen jeden Tag in einem grossen gemeinsamen Büro sassen. In einem derartigen Setting ist jeder sofort erreichbar, man bekommt zwangsläufig mit was die anderen tun, und Informationen können schnell und beiläufig an der Kaffeemaschine oder im Aufzug ausgetauscht werden. Ein zusätzlicher Vorteil ist, dass Information Radiators wie digitale Displays oder Kanban Boards durchgehend für alle sichtbar sind.

Als nicht zu vernachlässigendes Element kommt dazu, dass es kaum funktionale Spezialisierungen gab. Wie Jean Lee berichtet, waren in der damaligen Firma WhatsApp die Manager (einschliesslich des CEO) gleichzeitig an der Softwareentwicklung beteiligt, während die eigentlichen Entwickler Crashkurse in den wirtschaftlichen Aspekten erhielten und auch alle Geschäftszahlen kannten. Es gab also keine organisatorischen Silos, die sich untereinander prozessual koordinieren mussten.

Zuletzt darf man nicht vergessen, dass WhatsApp damals erst wenige Jahre alt war, und ein sehr minimalistisches Produkt hatte (im Wesentlichen eine Messaging App, Features wie Video Calls, Channels, Stories und DesktopApp existierten noch nicht), es gab also vergleichsweise wenige Feature Requests, technische Schulden und Refactoring-Wünsche, die man in einem strukturierten Planungs- und Priorisierungsprozess hätte verhandeln und eskalieren müssen.

Ich habe bereits mit anderen Firmen vergleichbarer Grösse und Struktur arbeiten dürfen, und z.T. auch dort ein vergleichbares Minimum an Prozessen und Strukturen erleben dürfen, was aber in allen Fällen nur gut funktioniert hat, so lange die Produkte und Organisationen von überschaubarer Grösse und Kompliziertheit waren. Sobald Wachstum stattfand, kamen auch die Prozesse (und Vergleichbares passierte laut Jean Lee nach der Übernahme von WhatsApp durch Facebook).

Es bleibt also am ende eine gleichzeitig positive und negative Erkenntnis: Berufsleben ganz ohne Regelmeetings, fest definierte Prozesse oder sonstige einengende Strukturen ist möglich, vermutlich aber nur in sehr kleinen und jungen Unternehmen. Wer Wert darauf legt, wird also alle paar Jahre zu einem neugegründeten Startup wechseln müssen. Wer dagegen einen Job etwas länger behalten möchte, der wird schon bald um Prozesse nicht mehr herumkommen.

Ein Bild sagt mehr als 1000 Worte (LVI)

Gefunden auf Reddit, der unendlichen Fundgrube.

Agile Success Stories: Agile QA

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist bedauerlich, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Eine an der ich vor längerer Zeit beteiligt war betraf die Qualitätssicherung in einem grossen IT-Projekt. Die hier tätigen Tester galten in der allgemeinen Wahrnehmung als doppelt problematische Schwachstelle: am Ende fast jedes Sprints wurden in den Entwicklungsteams die Tests der dort programmierten Features nicht mehr rechtzeitig fertig, und nach dem Sprintende waren die Regressionstests häufig zuerst grün, enthielten aber Wochen später plötzlich doch Fehlermeldungen.

Eine Analyse der Entwicklungsabläufe zeigte schnell zwei Hauptprobleme auf: zum Einen gab es in den Teams wasserfallartige Abläufe, in deren Rahmen die Entwickler lange unter sich arbeiteten, und die Tester erst kurz vor Sprintende erfuhren, was sie zu testen hatten (und das dann unter Zeitdruck tun mussten) zum Anderen hatte sich die übergreifende Regressionstest-Suite mit der Zeit selbst zu einem schwerfälligen Legacy-System entwickelt, dass nur noch aufwändig anzupassen war.

Dementsprechend wurden drei Verbesserungsmassnahmen durchgeführt. Zuerst wurden die Tester früher in die Abläufe ihrer Teams integriert. In den Backlog Refinements wurden sie daran beteiligt, die Akzeptanzkriterien testbar zu verfassen statt abstrakt, ihre Testaufwände wurden stärker in den Aufwandsschätzungen berücksichtigt und beim Planen der Sprints wurden Grösse, Auswahl und Anzahl der Entwicklungs-Aufgaben so vorgenommen, dass am Ende genug Zeit zum Testen blieb.

Als zweite Massnahme erfolgte eine stärkere Einbeziehung der Software-Entwickler in die QA-Abläufe. Wie oben geschrieben hatten die bis dahin das Testen als ein nachgelagertes Thema gesehen, das sie selber nicht mehr betraf. In dem verbesserten Vorgehen wurde dagegen eine Testpyramide angestrebt (siehe hier), in der bestimmte Mengen an (von den Entwicklern erstellten) Unit-, Integrations- und Lasttests zu einem Abnahmekriterium wurden, was das Testen am Sprintende deutlich beschleunigte.

Als Drittes wurde eine Überarbeitung der Regressionstest-Suite vorgenommen, die ja zu einem eigenen Problem geworden war. Bis dahin war sie einfach nach jedem Sprint um weitere Tests erweitert worden, während die bestehenden nur angepasst wurden, wenn (und nur dort wo) es Änderungen an den getesteten Funktionen gegeben hatte. Aufgrunddessen waren viele Tests redundant, kompliziert und unübersichtlich, was Anpassungen extrem aufwändig machte.

Um das zu verbessern wurde die Testsuite modularisiert und parametrisiert. Das Eine bedeutete, dass bestimmte Validierungen (z.B. des Login) nicht mehr in verschiedenen Tests enthalten waren, sondern nur noch in einem einzigen Modul, das dafür in beliebig viele Tests eingebunden werden konnte. Das Andere bedeutete, dass bestimmte variable Informationen (Browser, Ordnerpfade, etc.) nicht mehr hart im Test standen, sondern an einer zentralen Stelle systemweit geändert werden konnten.

In Summe führten diese verschiedenen Massnahmen dazu, dass die zu Beginn genannten Probleme fast völlig verschwanden. Die Tests (und mit ihnen die neuen Features) wurden in den Sprints fertig, in denen sie auch programmiert wurden, und die Aktualisierung der Regressionstests benötigte nur noch die Arbeit an einzelnen Modulen oder Parametern, statt an zig Stellen, wodurch versehentliche Seitenauswirkungen der neuen Features sofort gefunden werden konnten, statt Wochen später.

Am Ende ist es eine Binsenweisheit: eine Kette ist nur so stark wie ihr schwächstes Glied, und in vielen Softwareentwicklungs-Organisationen ist dieses schwächste Glied die Qualitätssicherung. Auch hier die agilen Praktiken einzuführen, und zwar sowohl technisch als auch prozessual, ist etwas, wovon alle Beteiligten massiv profitieren können.

Kommentierte Links (CXXXVIII)

Bild: Pexels / Ekam Juneja - 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.

Mike Fisher: Twitching Before You Sprint

Dass sich die Welt (oder zumindest die Welt der Software-Entwicklung) immer schneller dreht, merkt man auch daran, dass Vorgehensweisen die früher als unglaublich schnell galten, plötzlich als langsam wahrgenommen werden. Mike Fisher empfiehlt hier zum Beispiel anstatt der üblichen Sprints (die normalerweise ein bis vier Wochen dauern) einen deutlich schnelleren Modus: kleine Mikro-Vorhaben, die er "Twitches" (Zuckungen) nennt. Mal sehen, wo diese Beschleunigung noch hinführt.

Steve Blank: Your Startup Is Probably Dead On Arrival

Apropos Beschleunigung. Steve Blank geht in diesem Blogpost davon aus, dass Startups die vor Beginn der Durchbrüche der KI-Technologie gegründet wurden, bereits jetzt technisch und prozessual abgehängt sind - und das selbst dann, wenn sie erst wenige Jahre alt sind (für ihn trifft das auf alle zu, die vor 2025 gegründet wurden). Der aus seiner Sicht entscheidende Paradigmenwechsel: die Erstellung von Software ist plötzlich so billig, dass hier ein limitierender Faktor komplett entfällt.

Christina Wodtke: Everyone on Your Team Is Right (And That’s the Problem)

Das was Christina Wodtke in ihrem Artikel beschreibt, habe ich selbst zigfach erlebt: verschiedene Einheiten oder Hierarchieebenen einer grossen Organisation sind so stark von ihren jeweiligen Sachzwängen, Erfahrungen und Glaubenssätzen geprägt, dass jede andere Sichtweise ihnen widersinnig erscheint, und jeder der eine andere Sichtweise hat irrational. Was sie als Ausweg aus dieser Situation sieht, würde ich unterschreiben: man muss sich selbst aktiv in die jeweils andere Position begeben.

Doc Norton: This Has Happened Before. It's Happening Again.

Dass im Moment ganze Berufe von den Fortschritten in der Künstlichen Intelligenz grundlegend verändert werden dürfte unstrittig sein, und dass die Softwareentwicklung einer dieser Berufe ist, ebenso. Ob dieser Umbruch ein nie dagewesenes Ausmass hat, ist dagegen diskutabel, Doc Norton kann mehrere Beispiele vergleichbarer vergangener Umbrüche nennen, an die sich die Entwickler auch angepasst haben. [Ein Zusatz-Link: im Pragmatic Engineering-Podcast äussert sich Grady Booch sehr ähnlich.]

Jannik Reigl: What if Germany isn’t very good at research?

Als letztes ein grundsätzliche Beobachtung, die ich ebenfalls schon in vielen Firmen gemacht habe. In Deutschland sind wir offensichtlich sehr gut darin, bestehende Technologien und Produkte weiterzuentwickeln und ihre Herstellung zu optimieren. Wenn es zu Disruptiven Innovationen und Sprunginnovationen kommt, tun wir uns dagegen oft schwer. Jannik Reigl versucht zu erklären, welche Faktoren uns in diese Situation geführt haben.

Cockburn's Razor

In der englischen Sprache gibt es die schöne Firur des Razors (Rasiermessers) mit dem ein Vorgehen bezeichnet wird, bei dem man überflüssige oder verwirrende Elemente von einer Überlegung "abrasiert" werden. Das was danach übrigbleibt soll klarer und verständlicher sein als der Ausgangszustand. Der Bekannteste ist vermutlich Occam's Razor ("The simplest explanation is usually the best one."), es gibt aber auch weitere, wie zum Beispiel diesen hier.

Cockburn's Razor ist benannt nach Alistair Cockburn, einem der initialen Unterzeichner des Manifests für agile Softwareentwicklung. Wann genau er entstanden ist lässt sich nicht mehr genau zurückverfolgen, es wird aber vermutlich irgendwann nach Mitte der 90er Jahre gewesen sein, da Cockburn erst ab dieser Zeit einen Bekanntheitsgrad hatte, der es möglich machte, seinen Namen für die Popularisierung von Vorgehensmodellen zu benutzen. Er lautet:

Don't add stept to process until you need them
Delete steps from process as soon as you can
Apply this to every file, every process doc, every CSV Column
If it doesn't serve Ring 0 right now, archive it or delete it

Alistair Cockburn, Cockburn's Razor

Diese Faustregel wirkt auf den ersten Blick eingängig, da sie ein einfacher Weg ist, um sowohl soziale als auch technische Prozesse schlank zu halten, sie ist aber in vielen Organisationen nur schwer umzusetzen. Der Hauptgrund dafür ist der vor allem in grösseren Einheiten stark verbreitete Wunsch, möglichst viel Standardisierung, Vergleichbarkeit und Stabilität zu haben, welcher wiederum auf der Hoffnung beruht, dadurch die Transparenz und Steuerungsfähigkeit zu erhalten.

Selbst wenn es gelingen sollte, diese Quelle ständig nachwachsender Bürokratie zu neutralisieren, bleiben aber ggf. noch Probleme in der individuellen Dimension. Vor allem auf den unteren Ebenen einer Organisation gibt es Menschen, die eine kategorische Ablehnung gegen Prozesse und Meetings jeglicher Art entwickelt haben (siehe hier) und sie darum grundsätzlich alle abrasieren wollen - selbst dann, wenn sie einen sinnvollen Zweck haben. Die müssen überzeugt oder überstimmt werden.

Die Umsetzung von Cockburn's Razor erfordert daher nicht nur ein ständiges Überprüfen und Anpassen, sondern in der Realität auch ein kontinuierliches Informieren, informiert Werden, Überzeugen und Aushandeln. Es ist also keine leichte und eindeutige Lösung, trotzdem aber eine die besser für die Verschlankung und Schlankhaltung von Prozessen geeignet ist als die meisten anderen.

Greenfield, Brownfield, Blackfield

Es gibt Begrifflichkeiten, die man irgendwann benutzt ohne gross darüber nachzudenken. Im IT-Projektmanagement gehört dazu das Gegensatzpaar Greenfield und Brownfield, welches vereinfacht gesagt für Neuentwicklungen und Weiterentwicklungen von Systemen steht. Wie ich vor kurzem erfahren habe, gibt es aber auch noch eine dritte, bisher neue Kategorie - die des Blackfield, wobei ausgerechnet die in meinem Umfeld relativ häufig ist.

Alle drei sind Teile der metaphorischen Sprache, einer alten, durch das Extreme Programming popularisierten Praktik des Software-Projektmanagement, bei der man komplexe Sachverhalte dadurch nachvollziehbar macht, dass man für ihre Beschreibung Worte des alltäglichen Lebens benutzt. Da die drei "Feldtypen" jeweils typische Ausgangslagen von Entwicklungsprojekten beschreiben, lohnt es sich, sie zu kennen. Hier sind sie:

Greenfield

Zu Greenfield gibt es in der deutschen Sprache sogar eine Entsprechung, nämlich das Beginnen eines Vorhabens "auf der grünen Wiese", wo vorher noch nichts war. Das bedeutet keine bestehenden Strukturen und Architekturen, keine technischen Schulden und keine hohen Betriebsaufwände, auf der anderen Seite aber auch keine Bestandskunden und kein bereits existierendes Business Model. Wenig überraschend: Entwickler lieben Greenfield, Manager sind eher Misstrauisch ihnen gegenüber.

Brownfield

Ohne dass es eine gebräuchliche deutsche Übersetzung gibt, kann man sich Brownfield-Projekte wie Vorhaben auf einem schlammigem Acker vorstellen, in dem die Reste vergangener Vorhaben versunken oder untergepflügt sind. Bestehende Strukturen, Architekturen und technische Schulden (und Business Models) gibt es hier mehr als genug, weshalb alle weiteren Schritte mit etwas "Archäologie" beginnen müssen, um zu verstehen auf was für Fundamente man aufbaut und in welchem Zustand diese sind.

Blackfield

Blackfield ist die neue, mir bisher noch unbekannte Analogie. Um beim Bild zu bleiben: man steht hier auf verbrannter Erde. Gescheiterte Ablöseprojekte, abgebrochene Weiterentwicklungen, hastige Notlösungen und nicht dokumentierte Hotfixes haben ein fragiles Trümmerfeld zurückgelassen, auf dem selbst kleine Veränderungen zu Destabilisierungen und Zusammenbrüchen führen können, die umfangreiche (und teure) Stütz- und Reparaturmassnahmen notwendig machen.

Was vielen nicht bewusst ist: in grösseren und älteren Organisationen (Banken, Behörden, etc.) sind Brownfield-Umgebungen der Normalfall und Blackfield-Umgebungen keine Seltenheit, da IT-Systeme hier z.T. seit Jahrzehnten unter hohem Spardruck entwickelt wurden. Das hat zur Folge, dass bei jedem neuen Vorhaben mit ungeplanten Mehrarbeiten von nicht genau vorhersagbarem Umfang zu rechnen ist, im Extremfall bis hin zu einer Vervielfachung des ursprünglich angenommenen Arbeitsaufwandes.

Um nicht in diese Situation zu geraten, macht es Sinn, die alten Relikte und Ruinen von Zeit zu Zeit zu abzureissen, den Untergrund wieder zu verfestigen und schädliche Rückstände zu entsorgen. Refactoring, wie man in der Softwareentwicklung sagt. Um die Metapher auf die Spitze zu treiben: dabei kann ein Revierpark entstehen, also eine renaturisierte Industriebrache, auf der dann wieder erneut mit einem Greenfield-Ansatz begonnen werden kann.

Conceptual Knowledge vs Procedural Knowledge

Grafik: CCNull / Marco Verch - CC BY 2.0

Beim Lesen von David Epsteins Buch Range sind verschiedene Konzepte aus meinem Psychologie-Studium wieder emporgestiegen, unter anderem die Prozeduralen und Konzeptionellen Probleme, bzw. der zu ihrer Lösung notwendigen Wissensgebiete des Prozeduralen und Konzeptionellen Wissens. Es handelt sich dabei um universell anwendbare Ansätze, die aber in meinem beruflichen Umfeld noch einmal besondere Implikationen haben.

Prozedurales Wissen (umgangssprachlich auch als Know-How bezeichnet) umfasst Informationen, die unmittelbar anwendbar sind, seien es mathematische Rechenwege, Navigationsanweisungen oder Kochrezepte. Die Prozeduralen Probleme, für deren Lösung sie gedacht sind, treten regelmässig und in immer vergleichbarer Form auf, so dass die Problemlösung im Wesentlichen aus der Wiederholung früherer Lösungen bestehen kann.

Konzeptionelles Wissen umfasst dagegen Informationen über abstrakte aber universell gültige Wirkungszusammenhänge, etwa Grundrechenarten, die Bedeutung von Strassenschild-Formen und die geschmacklichen und chemischen Eigenheiten und (In)Kompatibilitäten von Kochzutaten. Die Konzeptionellen Probleme, für deren Lösung sie gedacht sind, sind komplex, dynamisch oder neuartig, so dass die Problemlösung jeweils neu gefunden und validiert werden muss.

In der Welt der Organisation von Arbeitsabläufen lassen sich diese beiden Wissensgebiete im Wesentlichen auf zwei bekannte Vorgehensmodelle mappen: Prozedurales Wissen findet sich vor allem im Lean Management, mit dem Fertigungsstrassen, Callcenter und ähnliche Einrichtungen optimiert werden können, während sich Konzeptionelles Wissen vor allem in agilen Arbeitsweisen wiederfindet, die in Produkt-Neuentwicklungen innovative Wege finden müssen.

Was Epstein nun in seinem Buch schreibt (und durch wissenschaftliche Studien belegt) ist aber, dass die Menschen eine grundsätzliche Neigung zu Prozeduralem Wissen haben, da es einfache Verständlichkeit, sofort nachvollziehbare Lösungswege und schnelle Fortschritte ermöglicht. Diese verzerrten Präferenzen gehen so weit, dass oft selbst bei der Lösung Konzeptioneller Probleme versucht wird, diese mit Prozeduralem Wissen zu lösen - selbst dann, wenn das gar keinen Sinn macht.

Auf die moderne Arbeitswelt übertragen: selbst für die Lösung neuartiger Probleme, für die eigentlich Systems Thinking, Mustererkennung, Inspect & Adapt und ähnliche abstrakte Ansätze die Richtigen wären, versuchen viele Menschen und Organisationen zunächst reflexartig auf Best Practices, Industrie-Standards, Playbooks und ähnliche Anleitungen zurückzugreifen. Das Scheitern vieler digitalen, agilen und sonstigen Transformationen dürfte darin begründet sein.

Um noch tiefer zu bohren: auch den Grund für die Bevorzugung Prozeduralen Wissens fasst Epstein zusammen, und es ist auch ein ganz einfacher - im Gegensatz zum anspruchsvolleren und vergleichsweise schwer zu durchdringenden Konzeptionellen Wissen erfordert das Prozedurale Wissen weniger gedankliche Anstrengung und weniger Lernaufwand. Dass es bevorzugt wird, liegt also schlicht an der geistigen Bequemlichkeit vieler Menschen.

Für das Innovations- und Change Management beutet das, dass seine Vertreter bereit sein müssen, auch als unbequem wahrgenommen zu werden, zumindest so lange bis im jeweiligen Einzelfall beweisbar ist, dass Konzeptionelles Wissen auch tatsächlich der passende Weg zur Lösung Konzeptioneller Probleme ist. Und als Schlusspointe: auch die Kategorisierung von Wissen und Problemen in Konzeptionell und Prozedural ist Konzeptionelles Wissen. Hilfreich, aber nicht für jeden sofort zugänglich.

Project Manager of my Heart (A Programmer Love Song)

Was wäre die Welt ohne KI? Zumindest wäre sie ärmer an Liedern wie diesem hier, das herrlich durchgeknallt die Zuneigung eines Softwareentwicklers zu seinem (in agilen Methoden bewanderten) Projektmanager besingt.

Und als wäre das nicht bereits genug, sind im Text ausserdem noch zahlreiche IT-Fachbegriffe untergebracht. Ein wahres Nerd-Feuerwerk.

Make Meetings great again

Manche Erkenntnisse hat man unbewusst bereits seit langem, man muss aber einmal darauf hingewiesen werden, damit sie es explizit ins Bewusstsein schaffen. Einen derartigen Aha-Effekt habe ich vor kurzem während des Auftritts der Psychologin Rebecca Hinds im Unsiloed Podcast gehabt, in dem sie ein verbreitetes Problem auf den Punkt brachte: die meisten Menschen werden unbewusst darauf konditioniert Meetings schlimm zu finden und abzulehnen.

Die Art auf die das stattfindet dürfte jeder schon irgendwann erlebt haben. Wenn (aus welchem Grund auch immer) das Gespräch auf das Thema Meetings kommt, werden Augen verdreht und es wird gestöhnt. Nur noch Meetings habe man im Kalender, heisst es dann in der Regel, man käme zu nichts anderem mehr. Und sinnlos seien sie auch, eine einzige Zeitverschwendung. Und früher oder später kommt der Spruch, dass statt des Meetings auch eine Email gereicht hätte, darauf kann man wetten.

Natürlich sind diese Klagen in dieser Absolutheit nicht gerechtfertigt. Es ist zwar sicher ein grosser Teil aller Meetings hinterfragbar, viele haben aber einen sinnvollen oder sogar unverzichtbaren Zweck (mehr dazu hier). Was aber durch die Dauerbeschwerden entsteht, ist schlimmstenfalls sogar ein starker Konformitätsdruck, Meetings in der Öffentlichkeit ebenfalls kategorisch schlecht zu finden - selbst wenn man das selbst gar nicht so sieht.

Rebecca Hinds stellte im Podcast dazu ein bemerkenswertes Forschungsergebnis vor: wenn Personen sowohl einzeln als auch Gruppen gefragt wurden, was sie von Meetings hielten, gingen die Antworten deutlich auseinander. In der Gruppe waren die Bewertungen signifikant negativer als in Einzelbefragungen, was ein klarer Indikator dafür ist, dass diese Aussagen nicht auf Fakten zurückzuführen waren, sondern auf die (angenommenen) Erwartungshaltungen der Gruppe.

Um das Ganze ins Positive zu drehen: wenn die weit verbreitete und für die Zusammenarbeit letztendlich schädliche übertriebene Ablehnung von Meetings jeglicher Art im Wesentlichen auf fehlgeleitete Gruppendynamiken zurückgeht, dann können wir selbst dafür sorgen, dass sich diese Dynamiken umdrehen. Das Einzige was wird dafür tun müssen ist, positiv über Meetings zu reden, selbst wenn uns das aus den genannten Gründen zu Beginn schwerfällt.

Das heisst natürlich nicht, dass die zweifellos in vielen Meetings vorhandenen Missstände beschönigt oder verschwiegen werden sollen. Es heisst aber, dass durch ein Gegenüberstellen der unzweifelhaft ebenfalls vorhandenen sinnvollen Effekte ein differenziertes Bild entsteht, und dass es auch den anderen Gruppenmitgliedern ermöglicht wird, dieses differenzierte Bild zu haben oder zurückzugewinnen. In diesem Sinne: Make Meetings great again!