Wenn in Unternehmen über KI-Einführungen gesprochen wird, klingt das meistens nach Beschaffung: Ein Werkzeug wird ausgewählt, Lizenzen werden gekauft, Zugänge verteilt, Schulungen angesetzt. In diesem ersten Teil schauen wir uns an, warum diese Sichtweise das eigentliche Vorhaben verfehlt, worin sich der KI-Wandel von der agilen Transformation unterscheidet, die viele von uns schon einmal begleitet haben, und warum die Menschen, die mit KI arbeiten sollen, dabei gleichzeitig drei Rollen übernehmen müssen, für die sie nie ausgebildet wurden. Es geht in diesem Teil also noch nicht um Lösungen, sondern um die Größenordnung.
Kurze Unterbrechung – das Agile-Nachschlagewerk unserer Agile Community
Wir kennen das doch alles schon … oder?
Zunächst einmal ist die Ausgangslage vertraut. Wir führen keine Software ein, wir führen eine andere Art zu arbeiten ein. Genau das haben viele von uns in den letzten fünfzehn Jahren gemacht: Teams von Wasserfall auf iteratives Arbeiten umgestellt, Übergaben durch Zusammenarbeit ersetzt, Rollen neu verteilt, Widerstände ausgehalten, Rückfälle begleitet. Wir wissen, dass so etwas Jahre dauert, dass es an der Kultur hängt und nicht am Tool, und dass es nichts hilft, den Beteiligten das Ergebnis vorzurechnen, solange sie nicht verstehen, was es für ihren Montagmorgen bedeutet.
Insofern könnte man meinen, wir seien für diese Veränderung besser vorbereitet als alle anderen. Und in einem Punkt stimmt das auch: Wir haben Erfahrung mit dem Begleiten von Arbeitsweisen-Wandel, und diese Erfahrung ist gerade sehr wertvoll.
Aber die Parallele hat eine Grenze, und diese Grenze ist der Grund für diesen Artikel. Bei der agilen Transformation hatten wir etwas, das wir dieses Mal nicht haben.
Warum es dieses Mal keine Blaupause gibt
Als wir angefangen haben, agile Arbeitsweisen einzuführen, gab es Scrum. Es gab Extreme Programming, es gab Kanban, es gab das agile Manifest mit seinen zwölf Prinzipien. Diese Frameworks waren nie perfekt, und wir haben uns jahrelang darüber gestritten, wie viel davon Substanz ist und wie viel Zertifikatsindustrie. Aber sie hatten eine Eigenschaft, die wir erst jetzt richtig zu schätzen lernen: Sie waren eine Untergrenze.
Wer Scrum korrekt aufsetzte, hatte noch kein gutes Produkt. Aber er hatte einen Rhythmus, definierte Rollen, ein Artefakt für Prioritäten und einen Termin, an dem Probleme auf den Tisch kommen. Das war das Sicherheitsnetz: Damit wird es nicht ganz schlimm. Man konnte ein Buch lesen, ein Training besuchen und jemanden einstellen, der es schon dreimal gemacht hatte. Der Weg war schwierig, aber er war kartografiert.
Für das Arbeiten mit KI existiert dieses Framework nicht. Wir haben Produktdokumentation, wir haben Vorträge über beeindruckende Einzelfälle, wir haben Prompt-Sammlungen und wir haben eine erhebliche Menge an Marketing. Was wir nicht haben, ist ein Muster, das beschreibt, wie ein Team, eine Abteilung oder ein Fachbereich mit KI-Unterstützung arbeitet, das sich lesen, üben und übertragen lässt.
Auch das Ziel ist diesmal unklar
Es kommt noch etwas hinzu, das die Sache von der agilen Transformation grundlegend unterscheidet. Damals war das Ziel bekannt und nur der Weg unklar: Wir wollten schneller liefern, näher am Kunden sein, Fehler früher finden. Beim Arbeiten mit KI kennen wir das Ziel selbst nicht. Wie ein Freigabeprozess aussieht, wenn ein Teil davon automatisiert läuft, wissen wir nicht. Welche Prüfschritte am Ende sinnvoll sind und welche zum reinen Abnicken verkommen, ist genauso offen. Wir wissen nicht einmal, welche Arbeitsschritte in zwölf Monaten überhaupt noch von Menschen erledigt werden.
Wer sich davon eine Vorstellung machen will, muss nur nachlesen, wie unsicher gerade diejenigen sind, die als Experten gelten. Andrej Karpathy, der den Begriff „Vibe Coding“ geprägt hat, schrieb Ende 2025 zwei Sätze innerhalb weniger Wochen: dass Coding Agents vorher praktisch nicht funktionierten und seitdem praktisch funktionieren – und dass er sich als Programmierer noch nie so abgehängt gefühlt habe. Wenn das die Lage an der Spitze ist, dann sollten wir aufhören, in unseren Organisationen nach der Person zu suchen, die das schon mal gemacht hat. Diese Person gibt es nicht. Auch nicht als Beratung.
Mein Kollege Johann hat für diese Lage ein Bild geprägt, das die Größenordnung besser fasst als jede Aufzählung: Die agile Transformation war der Tutorial-Level. Es gab feste Regeln, eine vorgegebene Reihenfolge, Hinweistexte am Bildrand und die Gewissheit, dass wir am Ende nicht wirklich verlieren können. Jetzt läuft das Hauptspiel: kein Handbuch, offene Welt, und die Regeln ändern sich, während wir spielen.
Was stattdessen zu tun ist: den AI-Rewrite unserer Prozesse neu finden
Wenn es keine Blaupause gibt, dann müssen wir sie für jeden Prozess selbst finden. Und zwar nicht als Optimierung des bestehenden Ablaufs, sondern als Neufassung. Johann nennt das den AI-Rewrite eines Prozesses: Wir nehmen einen Ablauf, der heute funktioniert, und fragen nicht, an welcher Stelle wir KI einsetzen könnten, sondern wie dieser Prozess aussähe, wenn wir ihn heute mit den vorhandenen Möglichkeiten neu entwerfen würden.
Das ist ein erheblicher Unterschied. Die erste Frage führt zu einem Assistenten, der in einen unveränderten Ablauf gesetzt wird und dort erstaunlich wenig ausrichtet. Die zweite Frage führt zu einem anderen Ablauf, mit anderen Prüfpunkten, anderen Übergaben, anderen Zuständigkeiten und häufig auch mit weniger Schritten.
Nehmen wir die Erstellung von Produkttexten. Der klassische Ablauf besteht aus einem Briefing, einem Entwurf, einer fachlichen Prüfung, einer Korrekturrunde und einer Freigabe. Setzen wir in Schritt zwei eine KI ein, dann haben wir Entwürfe schneller … und dieselbe Prüfungs- und Freigabekette wie vorher, die nun zum Engpass wird. Entwerfen wir den Prozess neu, dann stellen sich ganz andere Fragen:
Diese Fragen kann niemand am Schreibtisch beantworten. Wir müssen sie ausprobieren, und wir werden dabei Hypothesen aufstellen, die sich als falsch erweisen. Genau das ist Discovery: Wir wissen nicht, was funktioniert, also bauen wir kleine, überprüfbare Versuche und lernen aus dem Ergebnis. Und zwar nicht einmal für die Organisation, sondern für jeden relevanten Prozess einzeln – weil sich die Antwort für die Produkttexte nicht auf die Angebotserstellung übertragen lässt und die Antwort für den Kundenservice nicht auf die Datenpflege.
Die eigentliche Zumutung: drei Rollen gleichzeitig
Und hier kommt der Punkt, an dem die Dimension des Problems meist unterschätzt wird.
In der agilen Welt hatten wir eine funktionierende Arbeitsteilung. Es gab jemanden, der ein Bedürfnis hatte: die Kundin, den Fachbereich, die Stakeholder. Aus diesen Bedürfnissen machte jemand Prioritäten, also wir Product Owner. Ein Team hat gebaut, und jemand hat sich um Prozess und Zusammenarbeit gekümmert. Diese Trennung war nicht nur Organisation, sie war auch eine Entlastung: Niemand musste alles gleichzeitig können.
Beim AI-Rewrite fällt diese Arbeitsteilung in sich zusammen. Schauen wir uns eine Sachbearbeiterin an, die künftig mit einem KI-Assistenten arbeiten soll. Sie ist gleichzeitig:
Kundin
Sie hat das Bedürfnis, und nur sie kennt die Ausnahmen, Sonderfälle und ungeschriebenen Regeln ihres Arbeitsalltags gut genug, um zu beurteilen, was gebraucht wird.
Product Discovery
Sie ist die einzige, die herausfinden kann, ob eine Lösung im echten Arbeitskontext trägt. Kein Workshop und kein Konzept ersetzt ihr Urteil darüber, ob das Ergebnis brauchbar ist.
Prozessdesignerin
Sie muss den neuen Ablauf mitentwerfen: welcher Schritt bleibt, welcher fällt weg, wo wird geprüft, was passiert im Fehlerfall.
Das ist eine erhebliche Zumutung, und wir sollten sie auch so benennen. Diese Person hat kein Discovery-Training, keine Erfahrung mit Hypothesentests, keine Ausbildung in Prozessmodellierung und in der Regel auch keine freie Zeit, weil ihre eigentliche Arbeit weiterläuft. Sie soll aber gleichzeitig ihren Job machen, ihren Job hinterfragen und ihren Job neu entwerfen … wobei am Ende offen ist, ob es diesen Job in der neuen Form noch in gleicher Zahl gibt.
Dass unter diesen Umständen nicht alle vor Begeisterung mitziehen, ist keine Überraschung, sondern eine vollkommen nachvollziehbare Reaktion.
Warum das die Größenordnung verändert
Vergleichen wir die beiden Vorhaben einmal nüchtern.
Die agile Transformation betraf in den meisten Unternehmen primär einen Bereich, nämlich die Softwareentwicklung, und dort einige Dutzend bis einige Hundert Menschen. Sie hatte ein Framework, das sich in zwei Tagen vermitteln ließ. Und sie hatte einen Erfahrungsmarkt: Bücher, Trainings, Zertifikate, Menschen mit Referenzen.
Der AI-Rewrite betrifft jeden Prozess, in dem Wissen verarbeitet wird; also Marketing, Kundenservice, Einkauf, Personal, Controlling, Produktmanagement, Recht. Er hat kein Framework, das man vermitteln könnte. Und er verlangt von den Betroffenen nicht, eine neue Arbeitsweise zu übernehmen, sondern eine neue Arbeitsweise zu erfinden.
Auch dort, wo es funktioniert, sieht es nicht nach einer übertragbaren Vorlage aus. Die Auswertung von rund 200.000 Nutzungsverläufen von Claude Code durch Anthropic zeigt ein aufschlussreiches Muster: Entwickler setzen KI inzwischen in etwa 60 Prozent ihrer Arbeit ein, können aber nur zwischen null und zwanzig Prozent ihrer Aufgaben vollständig abgeben. Das ist kein Widerspruch, sondern der Normalzustand einer Arbeitsweise, die noch verhandelt wird: viel Beteiligung, wenig fertige Übergabe. Und dort, wo Organisationen radikal weitergegangen sind – etwa Unternehmen, die Software ohne menschliches Code-Review ausliefern – hängt der Erfolg an einer Validierungsinfrastruktur, die aufwändiger ist als die Produktion selbst. Auch das ist keine Vorlage, die sich in einem Fachbereich am Dienstag nachmittag nachbauen lässt.
Die Konsequenz ist unbequem, aber sie ist wenigstens klar: Wir können diese Veränderung nicht ausrollen. Ein Rollout setzt voraus, dass wir wissen, was am Ende dabei herauskommen soll. Was wir stattdessen brauchen, ist die Fähigkeit, in vielen Bereichen parallel herauszufinden, was funktioniert. Und zwar mit Menschen, die diese Fähigkeit bisher nicht gebraucht haben.
Und was heißt das jetzt für uns?
An dieser Stelle wird auch klar, warum unsere Rollen dabei so wichtig werden. Was hier gebraucht wird, ist nämlich weder ein Tool-Rollout noch ein Kommunikationsprogramm. Gebraucht wird jemand, der Discovery beibringt und begleitet, statt sie zu delegieren. Jemand, der Hypothesen formulieren hilft und dafür sorgt, dass eine widerlegte Hypothese als Erkenntnis gilt und nicht als Scheitern. Jemand, der die Fragen stellt, die vor einer Automatisierung geklärt sein müssen. Und jemand, der aushält, dass diese Veränderung an der beruflichen Identität von Menschen rührt.
Kurz: Es ist die Arbeit, die wir immer gemacht haben, nur ohne Framework, in mehr Bereichen gleichzeitig und mit deutlich höherem Einsatz.
Bleiben wir beim Bild: Im Tutorial-Level durften wir üben, und die Regeln waren erklärt. Im Hauptspiel gibt es keine Erklärung mehr, wir spielen auf Zeit, und die Regeln ändern sich zwischendurch. Das ist beängstigend. Es ist aber auch der Moment, in dem sich zeigt, ob wir das Tutorial verstanden haben oder nur die Tasten kannten.
Im zweiten Teil dieser Reihe schauen wir uns deshalb an, woran KI-Einführungen im Arbeitsalltag konkret hängen bleiben: warum ausgerollte Funktionen ungenutzt bleiben, welche Fragen vor einer Automatisierung geklärt sein müssen und warum wir mit unseren gewohnten Rollout-Mustern nicht weiterkommen. Im dritten Teil geht es dann um die Rolle, die diese Arbeit übernimmt. Und darum, warum sie einen anderen Namen braucht als den, den wir bisher tragen.
Unser Fazit
KI-Einführung ist keine Werkzeugbeschaffung, sondern die Einführung einer anderen Art zu arbeiten. Das kennen wir aus der agilen Transformation, und diese Erfahrung hilft uns. Der entscheidende Unterschied ist allerdings, dass es diesmal keine Blaupause gibt, die uns eine Untergrenze garantiert. Es gibt kein Scrum für das Arbeiten mit Agenten, kein Buch, das den Zielzustand beschreibt, und niemanden, der es schon dreimal gemacht hat.
Wir müssen den AI-Rewrite unserer Prozesse deshalb selbst discovern – Prozess für Prozess, mit Hypothesen, von denen einige falsch sein werden. Und die Menschen, die mit KI arbeiten sollen, sind dabei gleichzeitig Kunde, Product Discovery und Prozessdesign, ohne dafür ausgebildet zu sein und ohne dafür Zeit zu haben.
Wer die Größenordnung dieser Aufgabe einmal ausgesprochen hat, versteht auch, warum „wir machen mal eine Schulung“ daran nichts ändert. Die agile Transformation war das Tutorial. Jetzt fängt das Spiel an.
Wenn ihr gerade vor dieser Aufgabe steht und überlegt, wo ihr sinnvoll anfangt, sprecht uns gerne an. Wir helfen dabei, den passenden ersten Prozess und das passende Vorgehen für euren Kontext zu finden.
Quellen und Bezüge
- Agiles Manifest, 2001
- Andrej Karpathy zu Coding Agents und zum eigenen Gefühl, abgehängt zu sein, Dezember 2025
- Anthropic, Auswertung von rund 200.000 Claude-Code-Nutzungsverläufen über sechs Monate
- Steve Yegge, „Six Waves of Programming“ zur Entwicklung der Arbeitsweisen von Completions bis zu Agent Fleets
- Dark-Factory-Praxis bei StrongDM: Softwareauslieferung ohne menschliches Code-Review, abgesichert über Validierungsinfrastruktur
- Die Motive „Tutorial-Level“ und „AI-Rewrite“ sowie Datenlage und Kontext aus dem Vortrag „KI killt Agile. Wer steuert die Transformation?“ von Johann-Peter Hartmann
Schreibe einen Kommentar