AI-Driven Development Lifecycle (AI-DLC)

Einer der spannenden Nebeneffekte des Einzugs von Künstilcher Intelligenz (AI/KI) in die Softwareentwicklung ist, dass auch das methodische Vorgehen sich weiterentwickelt. Ob dabei ein weiteres Vorgehensmodell entstehen wird, das ähnliche Popularität erlangt wie Scrum und SAFe muss sich noch zeigen - es gibt aber einen ersten Kandidaten: Artificial Intelligence-Driven Software Development Lifecycle, oder abgekürzt AI-DLC.

Entwickelt wurde AI-DLC im Herbst 2025 im Developer Transformation Program von Amazon Webservices (AWS). Es wurde aber von Anfang an auch extern veröffentlicht, sowohl im AWS DevOps & Developer Productivity Blog (einschliesslich einer offiziellen Method Definition) als auch ausführlicher im privaten Blog des Programmleiters Dereck Chen (Teil I, Teil II, Teil III, Teil IV). Ein Menge Stoff also, aber wie genau sieht dieses Framework jetzt aus?

Auf den ersten Blick gibt es viele Elemente, die einen bekannten Eindruck machen. Im Mittelpunkt stehen autonome, crossfunktionale Teams aus 3 bis 6 Personen - so genannte Taxi Teams, da sie in ein einziges Taxi passen sollen (eine kleinere Variante von Amazons klassischen Two Pizza-Teams). Fest vorgegebene Rollen in diesem Teams gibt es nicht, empfohlen werden aber Product Manager, Full Stack Developers, QA Engineers und DevOps Engineers, sowie weitere bei Bedarf.

Auch der namensgebende Lifecycle ist in ähnlicher Form bereits bekannt. Es gibt die drei Phasen Inception (Anforderungen erfassen), Construction (die eigentliche Entwicklung) und Operation (Betrieb und Monitoring), die aber nicht nur einmal durchlaufen werden, sondern in sich ständig wiederholenden Iterationen. Diese werden Bolt (sinngemäss "Blitzstrahl") genannt, wodurch klar gemacht wird, dass sie kürzer sind als die klassischen Sprints (nur wenige Stunden oder Tage).

Dass derartig kleine Teams in derartig kurzen Zeiträumen funktionierende Incremente erzeugen, integrieren und betreiben können, liegt schliesslich am Einsatz einer Entwicklungs-KI. In allen drei Phasen erledigt sie den Grossteil der Arbeit, die menschlichen Teammitglieder sind als Human in the Loop nur noch für den initialen Input, die Qualitätssicherung und für Edge Cases zuständig, in denen die KI an Grenzen gerät und Hilfe braucht.

In der konkreten Umsetzung sieht das so aus, dass die KI in der Inception-Phase den Ist-Stand der Systeme, den Entstehungskontext (Architektur, Coding Standards, etc) und die grossen anstehenden Anforderungspakete, die Epics, bereits kennt. Aus einem dieser Epics wird eine mittelgrosse High-Level-Anforderung (eine so genannte Unit) definiert, aus der die KI User Stories und Akzeptanzkriterien erstellt. Die werden vom ganzen Team in einer so genannten Mob Elaboration geprüft und freigegeben.

Die freigegeben (und ggf. vorher nochmal in einer weiteren Verbesserungsschleife angepassten) User Stories werden als nächstes in der Construction-Phase durch die KI umgesetzt, was je nach Umfang unterschiedlich lange dauern kann. Sobald das abgeschlossen ist, erfolgt erneut eine Prüfung und Freigabe durch das gesamte Team, dieses mal unter dem Namen Mob Construction. Das kann nochmal in Unterphasen für Entwicklung und Test unterteilt werden (muss es aber nicht).

Die freigegebenen (und auch hier ggf. in einer weiteren Verbesserungsschleife angepassten) Incremente werden schliesslich durch die KI selbstständig auf Produktion deployt, einschliesslich der dabei durchzuführenden Tests und des anschliessenden Monitorings. Auch Bugs und Incidents werden (soweit möglich) von der KI selbstständig behoben. Der menschliche Anteil besteht hier aus der regelmässigen Kontrolle der dabei entstehenden Metriken und regelmässigen Sicherheits-Audits, Penetrationstests, o.Ä.

Soviel zur Beschreibung, jetzt zur Einordnung. Was auf den ersten Blick auffällt, sind die starken Parallelen zu Extreme Programming, sowohl in Bezug auf übernommene Elemente (iterativ-incrementelle Entwicklung, Epics, User Stories, Akzeptanzkriterien, Mob Programming) als auch in Bezug darauf, was nicht definiert wird (feste Rollen und Meetings, Backlogs, etc.). Selbst wenn es sich selbst nicht so nennt hat AI-DLC damit die Charakteristigen eines agilen Frameworks.

Auf den zweiten Blick fällt auf, dass der angestrebte intensive KI-Einsaz auf mehreren Vorbedingungen beruht. Sowohl das automatisierte Herunterbrechen der Anforderungen als auch das automatisierte Programmieren und Betreiben erfordern aktuelle Daten und Dokumentationen, klare und durchgehend eingehaltene Architektur- und Coding-Standards sowie ein nicht unwesentliches Token-Budget. AWS kann man zutrauen, das zu haben, andere Unternehmen müssten erst umfangreiche Vorarbeiten leisten.

Wenn das gegeben ist, kann man aber von einer deutlichen Beschleunigung der Entwicklungs-Geschwindigkeit ausgehen. AWS selbst nennt als Showcase sein Bedrock-Projekt, das von den ursprünglich geplanten 12 Monaten auf 11 Wochen beschleunigt wurde - mit Sechs Entwicklern, statt der ursprünglich eingeplanten 40. Derartige Dimensionen sind atemberaubend, und selbst wenn in anderen Vorhaben nur ein Teil davon erreicht würde, wäre es viel.

Entwickler-Produktivität

Für den Fall, dass es im eigenen Unternehmen gerade nicht aufregend genug ist - eine der sichersten Möglichkeiten das zu ändern ist, sich jemanden aus der IT-Abteilung (oder aus einer Abteilung, die die IT beauftragt) zu suchen und mit ihm oder ihr ein Gespräch zum Thema Entwickler-Produktivität zu beginnen. Was das ist, ob sie in ausreichendem Ausmass vorhanden ist und wie man sie messen kann. So lässt sich schnell Stimmung in die Firma bringen.

Aber Scherz beiseite, das Thema ist tatsächlich ein Klassiker. Und dass es seit Jahrzehnten in zahllosen Unternehmen immer wieder diskutiert wird, zeigt, dass bei ihm noch grundlegende Fragen ungeklärt sind - zum Beispiel, was das überhaupt ist, Entwickler-Produktivität. Eine allgemein anerkannte Definition gibt es bis heute nicht, und die existierenden Definitionsversuche haben alle ihre Schwächen. Daher zunächst ein Überblick: welche Versuche gibt es, Entwickler-Produktivität zu definieren?

I. Code-Output

Aus klassischer Management-Sicht der naheliegendste Ansatz. Wie viele Zeilen Code wurden in welcher Zeit geschrieben? Das ist einfach verständlich, gut messbar - und völlig unsinnig. Warum, habe ich hier aufgeschrieben. Eigentlich war das auch bereits allgemein anerkannt, seit dem Aufkommen von KI in der Softwareentwicklung hat die Zählung von Code-Zeilen (die auf einmal so schnell erzeugt werden können wie nie) aber ein unerwartetes und unschönes Revival erlebt.

II. Increment-Output

Schon besser als der erste Ansatz. Die Zählung von Incrementen (entwickelten, getesteten, integrierten und deployeten Features) geht mehr in Richtung der Zählung nutzbarer Funktionalitäten, und wird u.a, von McKinsey empfohlen. Schwierig dabei ist, dass es selbst in dem selben System massive Unterschiede beim Erstellungsaufwand verschiedener Incremente geben kann. Und das ist etwas, was auch über die Zeit nicht besser wird (bei Systemen mit geringer Degradability sogar eher schlechter).

III. Story Points (oder vergleichbare Werte)

Die vermutlich am weitesten verbreitete Metrik in agilen Entwicklungsteams, vor allem in Extreme Programming, Scrum und SAFe. Das Problem: wenn sie so benutzt werden wie ursprünglich gedacht, entsprechen sie keinen Zeiteinheiten und lassen sich nur rückwirkend und im langfristigen Durchschnitt auf solche umrechnen. Das Vorgeben einer festen Umrechnung in Zeit ist zwar möglich, beseitigt aber die Vorteile, wegen denen Story Points überhaupt erfunden wurden (siehe hier).

IV. Output-Flussmetriken

Die klassischen Lean-Metriken. Gemessen wird nicht mehr wie viele Arbeitspakete fertig werden, sondern wie lange die Fertigstellung im Schnitt braucht, ob von der Idee bis zum Endabnehmer (Lead Time) oder auf Teilstrecken dazwischen (Cycle Time). Je kürzer, desto besser. Wird auf Systemebene optimiert, etwa durch Abbau von Flaschenhälsen zwischen Anforderungsmanagement und Entwicklung, bessere Übergaben, etc. Daher auch eine System-Metrik, nicht nur eine auf Entwickler-Ebene. 

V. Outcome-Flussmetriken

Ähnlich wie der letzte Metriken-Typ, aber mit einem klareren Focus auf der Durchschnittszeit bis zur Erzielung eines angestrebten Geschäftswertes. Klassiker sind die Time to Market und die Feedback Loop Time, möglich sind aber auch andere, etwa die Durchführungsdauer eines A/B-Tests oder die Zeit bis zur Skalierung auf 10.000 Nutzer. Da daran neben den Entwicklern auch Produktmanagement, Marketing und andere Einheiten beteiligt sind, ebenfalls eher eine Metrik für das Gesamtsystem.

VI. Qualitäts-Metriken

Wieder eine reine Entwickler-Metrik. Kann sowohl unmittelbare Qualitätsmessungen enthalten (z.B. die Bug Rate oder Incident Rate) als auch Messungen der Qualitätssicherung (z.B. der Testabdeckung oder des Live-Monitorings). Anders als man zunächst denken könnte ein durchaus zweischneidiges Schwert, da hohe Qualitätsstandards zu unverhältnismässigen Aufwänden für die Durchführung von Experimenten oder die Erstellung von Prototypen und MVPs führen können.

VII. Betriebswirtschaftliche Metriken

Damit kann man die Augen vieler Controller zum Glänzen bringen. Return on Investment, Cost of Delay, Ressourcenaufwand pro Feature (z.B. in Form von Token-Verbrauch) oder Höhe von Betriebs- und Wartungskosten versprechen eine Steuerbarkeit anhand von Business Value, allerdings sind auch diese Zahlen sowohl stark vom jeweiligen System abhängig (siehen oben, Degradability) als auch von der Arbeit von verschiedenen Nicht-Entwicklungseinheiten wie Marketing oder Vertrieb.

VIII. Auslastungs-Metriken

Wieder ein Klassiker, aber diesesmal einer, der verheerende Auswirkungen haben kann. Jede Arbeitsstunde mit Tätigkeiten zu verplanen mag wie ein guter Weg zu hoher Produktivität erscheinen, da dadurch Leerlauf vermieden wird, allerdings reicht dann eine einzige Verzögerung aus um einen Domino-Effekt zu erzeugen, der alles nach hinten verschiebt (siehe hier). Und dazu kommen noch die Zusatzaufwände durch Umplanung, Informationsverteilung, Triage, Eskalation, etc.

IX. Kombinierte / gewichtete Metriken

Naheliegenderweise gibt es Versuche, mehrere Metriken zu verbinden oder miteinander zu verrechnen. Bekannt sind vor allem WSJF (Cost of Delay geteilt durch Durchlaufzeit) und das von McKinsey popularisierte inner Loop / outer Loop, das Entwicklungs- und Abstimmungs-Ergebnisse ins Verhältnis zueinander setzt. Das Problem daran ist, das sie leicht zu mechanistischen oder über-vereinfachten Betrachtungen komplexer Systeme führen können, die der Realität nicht mehr gerecht werden.

***

Was man an all diesen Versuchen, Entwickler-Produktivität zu messen, merken kann, ist, dass man bei ihrer Anwendung relativ schnell auf Probleme stösst. Zum Teil (v.A. bei Output- und Qualitätsmetriken) können versehentlich falsche Anreize gesetzt werden, zum Teil (bei Outcome- und Betriebswirtschafts-Metriken) lässt sich nur die Produktivität einer Gesamt-Organisation messen, nicht hingegen die von einzelnen Teilbereichen wie der Software-Entwicklung.

Bedingt dadurch führt der Wunsch, Entwickler-Produktivität zu messen meistens in einen nicht auflösbaren Konflikt. Auf der einen Seite stehen dabei Management und Controlling, die ein berechtigtes Interesse daran haben, die eigene Produktivität empirisch nachvollziehbar und auf Datenbasis optimierbar zu machen, auf der anderen Seite die Entwickler, die ebenfalls zu Recht anmerken, dass das durch die Erhebung und Auswertung von Metriken nur sehr eingeschränkt möglich ist.

Am Ende kann in genau diesem Konflikt aber auch die Lösung liegen. Wenn es gelingt, ihn sachlich, fallbezogen und lösungsorientiert auszutragen, kann das zu Produktivitätsmessungen führen, die dem jeweils einzelnen Fall eher gerecht werden als eine Einheitslösung, die in jedem Fall zwar zum Teil passend, zum Teil aber auch unpassend ist. Man hat dann nicht mehr ein zentrales Dashboard für alle IT-Teams, dafür aber das Potential für echte Verbesserungen. Und darum geht es doch eigentlich.

Kommentierte Links (CXXXXI)

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.

Sean Goedecke: Working with product managers

Eines der grossen Probleme rund um die Zusammenarbeit mit Softwareentwicklern, bzw. Softwareentwicklungs-Teams ist, dass ein Grossteil der Literatur zu diesem Thema aus einer Aussenperspektive geschrieben ist, also von Leuten, die keine Entwickler sind, sondern nur mit Entwicklern zusammenarbeiten. Sean Goedecke ist eine der bekannteren Ausnahmen, und auch hier ist ihm oein guter Blick aus der Innenperspektive der Softwareentwicklung gelungen.

Fagner Brack: Degradability

Es gibt Begriffe, deren Bedeutung sich erst erschliesst, wenn man sie einmal erklärt bekommt. Fagner Brack stellt hier einen solchen vor, die Degradability. Hinter diesem Begriff steckt vereinfacht gesagt das Ausmass des Verfalls der technischen Kompatibilität, dem eine Software alleine durch die Entwicklung neuer Tools und Standards ausgesetzt ist. Ist die Degradability einer Anwendung hoch, erzeugt sie ständig neue Arbeit, nur um weiterhin benutzbar zu bleiben. 

Jeff Gothelf: What “done” means when you’re shipping AI features

Die meisten Aussagen über die Veränderung der Softwareentwicklung durch KI focussieren sich auf ein (sehr kontroverses) Thema - die Erzeugung von mehr Quellcode in kürzerer Zeit. Nach Beiträgen zu anderen Aspekten muss man mitunter suchen, aber man findet sie. Z.B. hier bei Jeff Gothelf, der die interessante Idee aufwirft, in die Definition of Done einer Entwicklungs-KI auch Distributionen, Varianzen, Szenarien und Entscheidungsbäume einzubauen. 

Beth Smith: The Copenhagen Fallacy - complexity science and the organisations that keep changing without ever changing

Agile Indentity Politics

Eine steile These: eines der vermutlich grössten Probleme der gegenwärtigen Arbeitswelt trägt einen Namen - es ist die Identitäts-Politik (englisch Indentity Politics). Viele Schwierigkeiten auf die man in der Organisationsentwicklung, im Change Management oder in der technischen Modernisierung vorfindet, lassen sich darauf zurückführen. Wie immer bei steilen Thesen ist sie bewusst kontrovers. Um wieder sachlich zu werden folgt daher eine kurze Einführung. Was ist das überhaupt, Identitäts-Politik?

In der aktuellen Debatte versteht man darunter die (Selbst-)Zuschreibung bestimmter Ziele, Probleme oder Privilegien auf bestimmte soziale Gruppen, etwa soziale Schichten, Subkulturen, Menschen mit gleicher (ggf. von der Mehrheit abweichender) sexueller Orientierung, Angehörige von bestimmten ethnischen Gruppen, o.Ä. Diese Ziele, Probleme und Privilegien sichtbar zu machen und an ihnen zu arbeiten, um die Lage der davon betroffenen Gruppen zu verbessern, nennt man Identitäts-Politik.

Während zur Zeit im Mittelpunkt dieser Debatten eher der zweite Teil steht, also die Arbeit für die Interessen der eigenen Gruppe, ist aus einer Systemsicht der erste Teil mindestens genauso interessant, und vielleicht sogar interessanter: das feste Verknüpfen bestimmter Ziele, Programme, etc. mit einer sozialen Gruppe, bzw. deren Identität. In dem Moment in dem das passiert, wird sie nämlich fast zwangsläufig alle gegenläufigen Bemühungen auch als Angriff auf sich selbst wahrnehmen.

Um es noch einmal zu betonen - es geht  bei dieser These um die Arbeitswelt, nicht um das gesamtgesellschaftliche Problem, dass Menschen wegen ihrer Religion, Sprache, äusseren Erscheinung oder sexuellen Orientierung diskriminiert werden und sich zu Recht dagegen wehren. In der Arbeitswelt äussert sich Identitäts-Politik so, dass es zu einer (Selbst-)Zuschreibung bestimmter Arten zu arbeiten auf bestimmte Personengruppen kommt, mit der genannten Personalisierung von Konflikten als Folge.

Um das zu konkretisieren: wenn für ein Entwicklungsteam Praktiken wie Pair Programming oder gemeinsame Code Reviews konstituierende Elemente der eigenen Identität sind, dann wird es Ansätze wie AI-DLC, in denen das an eine KI ausgelagert wird, als bedrohlich für sich selbst empfinden. Und noch offensichtlicher: ein Scrum Master der seinen Job nicht als Beruf sondern als Berufung sieht, wird in eine Krise und Abwehrhaltung geraten, wenn sein Team ein anderes Arbeitsvorgehen haben möchte.

Mit derartigen Überlegungen im Hinterkopf lässt sich der häufig zu beobachtende Widerstand gegen Veränderungsinitiativen anders einordnen: sind die Menschen wirklich gegen Veränderungen (wie es dann häufig unterstellt wird), oder empfinden sie diese angestrebten Veränderungen als einen direkten Angriff auf sich selbst, ihre Überzeugungen, Werte, Prinzipien und Errungenschaften - also auf ihre Identität? Dann wären Zögerlichkeit und Widerstand viel nachvollziehbarer.

Da in einem sich stark und schnell wandelnden Arbeitsumfeld wie der IT Veränderungen nicht vermeiden lassen, muss Identitäts-Politik in diesem Kontext eine abgewandelte Bedeutung bekommen. Ihr Ziel sollte zwar noch immer sein, persönliche und soziale Identitäten in grösstmöglichem Ausmass zu schützen, gleichzeitig aber auch allen aufzuzeigen, wo das Verknüpfen der eigenen Identität mit zu spezifischen (und vergänglichen) Sachverhalten in eine berufliche Sackgasse führen kann. 

Im Idealfall baut am Ende die berufliche Identität nicht mehr (oder zumindest nicht zur Gänze) auf derartigem auf, sondern auch darauf, besser zu werden, dazuzulernen und neue Herausforderungen anzunehmen. Eine solche Identität würde nicht mehr dazu führen, dass Veränderungsinitiativen als persönliche Angriffe wahrgenommen werden können. In nahezu jeder grösseren Organisation würde das zu deutlich weniger Konfliktpotential führen.

It AI-n't What You Think!

Ein sehr lebhafter und unterhaltsamer Vortrag, den Venkat Subramaniam hier abliefert. Er versucht sich an einem neuen Blick auf das Thema AI, also Artificial Intelligence, und kommt dabei zu einem schönen Backronym: AI bedeutet für ihn Accelerate Inference, also die Beschleunigung von Schlussfolgerungen. Das ist für ihn nicht notwendigerweise etwas Schlechtes, sondern gibt nur Rahmenbedingungen für die Nutzung vor - er rät dazu, AI für die Generierung von Ideen zu nutzen, die Lösungs-Umsetzung aber selbst vorzunehmen, um nicht Kontrolle über Inhalt und Qualität zu verlieren.

Was seine Ausführung unterhaltsam macht sind neben dem Vortragsstil die zahlreichen Analogien, mit denen er seine Ideen erklärt, u.a. mit Bezügen zu Mahatma Ghandi, Franklin D. Roosevelt, Arthur C. Clarke, Henry Ford und Charles Darwin.

The Agile Bookshelf: Incorruptible

Für alle, die vom Silicon-Valley-Entrepreneur Eric Ries nur seine bisherige Bücher kennen, dürfte sein neues Buch Incorruptible ein eher überraschendes Thema haben. The Lean Startup gab einem ganzen Vorgehensmodell einen Namen und gilt heute als Standard-Werk für Startup-Gründer und The Startup Way übertrug das auf etablierte Unternehmen. Incorruptible geht dagegen in eine andere Richtung: es will dabei helfen, (junge) Unternehmen gegen feindliche Übernahmen zu schützen.

Um Incorruptible (zu Deutsch etwa: nicht korrumpierbar) zu verstehen, muss man zuerst erkennen, was Ries unter einer solchen feindlichen Übernahme (meiner sehr freien Übersetzung seines Begriffs Corruption, der eine grössere Bedeutung hat als das deutsche Wort Korruption) versteht. Verkürzt gesagt: eine Entmachtung des Gründers durch Investoren, die derartig auf kurzfristige Gewinnsteigerungen fixiert sind, dass sie bereit sind, dem alles zu opfern, was die Firma bisher ausgemacht hat.

Wichtig ist für ihn dabei, dass für ihn derartige Aktionen nicht durch Bösartigkeit, Partikularinteressen oder sonstige individuelle Motivationen entstehen, sondern systemische Ursachen haben. Da die Angestellten von Investment- und Kapitalverwaltungsgesellschaften in kurzen Zyklen an der Vermehrung des von ihnen verwalteten Kapitals gemessen werden, orientieren sie ihr Handeln vor allem daran, und geben dieses Ziel an die Firmen weiter, an denen sie Anteile halten.

Diese Zielsetzung der kurzfristigen Gewinn-Erzeugung gelangt in diesen Firmen zuerst zum Top-Management, dass darauf aufbauend die Aufgabe erhält, Gewinne möglichst früh abzuführen, Kosten zu senken und Auslastungen zu optimieren. Langfristige Effekte werden im Vergleich als nachrangig behandelt. Dieses herabreichen vom Investor über die Manager in alle Bereiche nennt Ries die "finanzielle Schwerkraft", da sie im Geschäftskontext quasi ein Naturgesetz ist.

Nun kann es vorkommen, dass ein Gründer oder Manager andere Ziele hat. Dass er z.B. seine Mitarbeiter stärker am Firmenerfolg beteiligen will oder dass er eher langfristig und strategisch investieren will, statt kurzfristige Gewinne zu realisieren. Das würde den Zielen seiner Investoren und institutionellen Anteilseigner aber derartig zuwiderlaufen, dass sie allein aufgrund ihrer eigenen formalen Ziele ein Interesse daran haben, ihn zu ersetzen - und damit eine feindliche Übernahme zu versuchen.

Ries listet zahlreiche Firmen auf, denen es genau so ergangen ist, gibt aber auch zahlreiche Gegenbeispiele, die diesem Schicksal entkommen konnten. Und er zeigt auf, wie ihnen das gelungen ist. Und an dieser Stelle taucht er in ein gleichzeitig langweiles und spannendes Thema ein: Governance, also den rechtlichen und internen prozeduralen Ordnungsrahmen für die Leitung und Überwachung einer Firma. Den hier liegt der grosse Hebel.

Wenn etwa in den internen Vorschriften festgelegt ist, dass ein Manager unter mehreren Optionen immer die wählen muss, die der Firma das meiste Geld bringt, ist er manchmal rechtlich verpflichtet, Entscheidungen zu treffen, die er moralisch für falsch hält. Wenn dort dagegen Mitbestimmung, Nachhaltigkeit oder gesellschaftliche Verantwortlichkeit definiert werden, können unverantwortliche Management-Entscheidungen dadurch unterbunden werden.

Was an den in dem Buch gesammelten Beispielen für derartige Firmen bemerkenswert ist, ist, dass viele von ihnen (Norvo Nordisk, Carl Zeiss, 3M, Hershey und viele mehr) überdurchschnittlichen geschäftlichen Erfolg haben. Im Grunde ist das die krönende Pointe seiner Ausführungen: werden Investoren und Anteilseigner daran gehindert, ihre Firmen kurzfristig auszupressen, sind ihre Gewinne in der langfristigen Betrachtung deutlich höher.

Was zum Schluss noch erwähnenswert ist, ist die von dem in Kalifornien lebenden Eric Ries aus offensichtlichen Gründen eingenommene US-amerikanische Perspektive. Durch sie befindet sich das in Europa und Asien verbreitete, in Amerika aber eher seltene Konstrukt des Familienunternehmens ausserhalb seiner Betrachtungen, auch wenn es die von ihm beschriebenen Ziele ebenfalls anstrebt und meistens auch erreicht. Vielleicht ein Thema für die nächste Auflage.

Estuarine Mapping

Bild: Rawpixel - CC0 1.0

Wer in Workshops oder Unterlagen die Dynamik und Veränderbarkeit seiner Arbeitsumgebung übersichtlich visualisieren wollte, der wird bisher mit grosser Wahrscheinlichkeit eines von zwei popolären Werkzeugen benutzt haben: die Stacey Matrix von Ralph Stacey oder das Cynefin Framework von Dave Snowden. Seit dem Jahr 2022 ist noch ein drittes dazugekommen: die Estuarine Map (ins Deutsche übersetzt die Flussmündungs-Karte), ebenfalls von Dave Snowden.

Die Estuarine Map, die ihren Namen bekommen hat, weil sie der Landkarte einer Ästuar-Flussmündung ähnlich sieht, ist grundsätzlich eine Übersicht über drei Objekt-Typen, aus denen das sozio-technische System einer Arbeitsumgebung zusammengesetzt ist. Constructors (Bausteine) sind die vorgegebenen Strukturen, etwa Gesetze, Bauwerke oder eingesetzte Software. Constraints (Beschränkungen) sind einengende Faktoren wie Geld oder Prozessvorgaben, Actors (Akteure) sind Menschen oder Gruppen.

Diese Objekte, die je nach Einzelfall sehr unterschiedlich sein können, werden in eine Matrix aus zwei Dimensionen eingeordnet: die erste, die Zeit, zeigt an, wie lange es vermutlich dauern würde, den Zustand oder die Zielsetzung eines Objektes zu verändern, während die zweite, die Energie, darüber Auskunft gibt, wie anstrengend oder ressourcenverbrauchend diese Bemühungen sein würden. Diese Einordnung entspricht nicht konkreten Werten wie Stunden oder Kilojoule sondern ist relativ zueinander.

Sobald die Objekt-Einordnung stattgefunden hat, kann durch das Ziehen von Linien eine Gruppierung stattfinden. Was mit wenig Zeit und Energie zu verändern ist, ist volatil (was auch heisst, dass Änderungen hier oft nur flüchtig sind), was nicht mit vertretbarer Kraft und Dauer zu ändern ist, ist kontrafaktisch (d.h. der Glaube, dass hier etwas zu verändern wäre, widerspricht den Fakten). In der Mitte trennt schliesslich die Liminal Line (Grenzlinie) die selbst veränderbaren und die nur beeinflussbaren Objekte.

Bis zu diesem Punkt ist die Estuarine Map noch eine reine Zustandsbeschreibung, sie lässt sich aber auch als Werkzeug für das Veränderungsmanagement nutzen. Zum Einen dadurch, dass bereits zu beobachtende Tendenzen mit Hilfe von Pfeilen als Bewegungen innerhalb der Matrix dargestellt werden, zum Anderen dadurch, dass mit Hilfe von verändernden Eingriffen versucht wird, derartige Tendenzen selbst einzuleiten oder anzuhalten (auch das lässt sich dann mit Pfeilen visualisieren).

Wer schon einmal mit Stacey Matrix oder Cynefin Framework gearbeitet hat wird sich auch im Estuarine Mapping schnell zurechtfinden, das Ergebnis sieht ähnlich aus und funktioniert ähnlich. Der wesentliche Unterschied ist die Erarbeitung: wärend in den beiden anderen Ansätzen eine Einordnung der Objekte in vordefinierte Felder erfolgt, werden die Grenzlienien hier erst relativ spät definiert und gezogen. Auch die Vordefinition der drei Objekt-Kategorien ist neu.

Eine bereits im Fall des Cynefin Frameworks zu beobachtende Eigenheit der Cynefin Company (der hinter beidem stehenden Organisation) ist schliesslich auch bei den Estuarine Maps wiederzufinden: eine Neigung zu leicht schrulligen Begriffen. Neben Constructor, kontrafaktisch und Liminal Line gehören dazu auch noch einige weitere, die ich hier der Einfachheit halber weggelassen habe. Aber die geben dem Ganzen auch einen Teil seines Charmes.

Ein Bild sagt mehr als 1000 Worte (LVIII)

Das Exit Ramp-Meme. Ein unverwüstlicher Klassiker.

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.