On Lean and Agility

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.

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.

Bild: Pexels / Ekam Juneja - Lizenz

Sean Goedecke: Working with product managers

Fagner Brack: Degradability

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

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

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.

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.

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.

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.

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