Im zweiten Teil haben wir gesehen, woran KI-Einführungen im Arbeitsalltag hängen bleiben: an ungeklärter Verantwortung, an einem Rollout ohne Stichtag, an organisatorischen Lücken, die KI schneller sichtbar macht, und an unbegleiteter Trauer über den Verlust der eigenen fachlichen Identität. Übrig geblieben ist die Frage, wer diese Arbeit übernimmt.
In diesem dritten Teil schauen wir uns an, wie sich die Aufgaben zu einer Rolle bündeln lassen, warum wir dabei über die Bezeichnung reden müssen, was diese Rolle ausdrücklich nicht übernimmt und was sich für uns Product Owner parallel dazu verschiebt.
Kurze Unterbrechung – das Agile-Nachschlagewerk unserer Agile Community
Die Rolle: Agile Change Manager
Schauen wir uns also genauer an, wie sich diese Aufgaben bündeln lassen – und warum die Bezeichnung dabei mehr als eine Formalie ist.
Warum die Bezeichnung wichtig ist
Die Arbeit, die in einem KI-Rollout entsteht, ähnelt unserer agilen Arbeit sehr stark: übersetzen zwischen technischer und fachlicher Seite, Hindernisse sichtbar machen, priorisieren, Feedback in die Entwicklung zurückführen, Veränderung begleiten. Trotzdem ist „Scrum Master“ für diese Aufgabe eine ungeschickte Bezeichnung, und zwar aus einem sehr praktischen Grund: Viele Entscheider verbinden den Begriff vor allem mit der Moderation von Zeremonien.
Diese Zuordnung ist nicht nur ungenau, sie ist im Moment auch geschäftlich riskant. Für die Moderation von Zeremonien gibt es inzwischen nämlich ein Angebot am Markt. Es existieren Anbieter, die Standups und Retrospektiven automatisiert abwickeln,
- im AWS Marketplace finden wir Multi-Agent-Plattformen für Scrum-Zeremonien,
- und Microsoft 365 Copilot bringt ein Scrum-Assistant-Template gleich mit.
Wer seinen Wertbeitrag also über Zeremonienmoderation beschreibt, konkurriert mit Software, die im Einkauf als Position mit klarem Preis auftaucht. Das ist keine Position, die wir uns wünschen sollten.
Die Bezeichnung Agile Change Manager beschreibt dagegen, was tatsächlich zu tun ist. Sie ist keine Umbenennung aus kosmetischen Gründen, sondern eine Präzisierung des Auftrags – und sie hat einen sehr handfesten Effekt: Sie macht die Rolle beschreibbar, begründbar und damit auch besetzbar.
Auftrag und Einordnung
Die Rolle ist Teil des bestehenden Rollout- oder Plattformteams und keine Instanz daneben. Sie arbeitet mit der vorhandenen Roadmap, dem vorhandenen Backlog und den bestehenden Entscheidungswegen, sodass weder ein zusätzliches Transformationsprogramm noch neue Gremien entstehen. Für jede wesentliche Erweiterung beantwortet sie fünf Fragen:
Im Folgenden stellen wir die konkreten Aufgaben kurz vor.
1. Change-Blick auf die Rolloutplanung – früh einordnen statt nachträglich reparieren
Sobald eine Erweiterung konkret geplant wird, prüft die Rolle gemeinsam mit der technischen und fachlichen Verantwortung, wer betroffen ist, wie stark sich die Arbeit verändert und welche Kommunikation und Befähigung nötig sind. Das Ergebnis wird im bestehenden Projektwerkzeug festgehalten. Ein zusätzliches Change-System brauchen wir dafür nicht.
2. Vorbereitung mit echten Nutzenden – testen, ob es im Arbeitskontext trägt
Bei neuen Nutzungsmöglichkeiten und veränderten Abläufen werden einige Beschäftigte aus dem betroffenen Bereich früh einbezogen. Sie prüfen nicht, ob die Funktion technisch läuft, sondern ob sie im realen Arbeitskontext verständlich und brauchbar ist: passende Begriffe, verlässliche Ergebnisse, notwendige Prüfschritte, typische Sonderfälle, fehlende Daten oder Berechtigungen.
3. Einführung passend vorbereiten – nur das bauen, was gebraucht wird
Dazu gehören eine verständliche Ankündigung, ein kurzes Briefing für die Führungskraft, eine Demo an einem echten Arbeitsfall, eine kompakte Anleitung und ein klarer Weg für Fragen. Was wir dagegen nicht brauchen, ist eine allgemeine Schulung für alle, wenn sich nur ein bestimmter Arbeitsablauf ändert.
4. Den Start begleiten – Ursachen trennen, statt Symptome sammeln
In den ersten Tagen und Wochen bleibt die Rolle nah an den Nutzenden und trennt dabei sauber zwischen fehlendem Wissen, unklarer Kommunikation, technischen Fehlern, fehlenden Daten oder Rechten, unpassendem Prozessdesign und unzureichender Ergebnisqualität. Jeder Punkt bekommt eine zuständige Person und einen nächsten Schritt – und landet im gemeinsamen Adoption-Backlog, nicht in einer separaten Liste.
5. Kurz auswerten und wiederverwenden – Erfahrungen zu Bausteinen machen
Nach der Stabilisierung halten wir knapp fest, was funktioniert, was noch klemmt und welche Beispiele beim nächsten Mal wiederverwendbar sind. Die Auswertung soll Entscheidungen ermöglichen, keine Berichtsbibliothek erzeugen.
Was die Rolle nicht übernimmt
Diese Abgrenzung ist genauso wichtig wie die Aufgabenliste, weil sie die Rolle überhaupt erst haltbar macht. Nicht Bestandteil des Auftrags sind:
Die Rolle sorgt dafür, dass notwendige Entscheidungen rechtzeitig sichtbar werden. Sie nimmt den zuständigen Personen ihre Verantwortung aber nicht ab. Wo diese Grenze verwischt, wird aus Change-Begleitung ein Ausfallbürge für ungeklärte Zuständigkeiten – und das hält keine Organisation längere Zeit durch.
Diese Beiträge könnten dich auch interessieren:
Woran wir Erfolg erkennen
Für jede größere Einführung vereinbaren wir wenige passende Signale, denn nicht jede Funktion braucht dieselben Kennzahlen. Vor dem Start sollte gelten: Die betroffenen Nutzergruppen sind bekannt, der veränderte Arbeitsablauf ist verständlich beschrieben, die Zuständigkeit für fachliche Fragen und technische Probleme ist geklärt, und Information und Befähigung sind vorbereitet.
Nach dem Start lauten die Fragen: Wird die Funktion für die vorgesehenen Aufgaben tatsächlich eingesetzt? Verstehen die Nutzenden, wann sie prüfen oder eingreifen müssen? Sind wiederkehrende Probleme sichtbar und einer zuständigen Stelle zugeordnet? Und spart der neue Ablauf Zeit, reduziert er unnötige Schritte oder verbessert er die Qualität? Bei Automatisierungen kommt eine Bedingung hinzu, die leicht untergeht: Fehler, Nacharbeit und Ausnahmen müssen mindestens so transparent bleiben wie vorher.
Und wir Product Owner?
Auch unsere Rolle gewinnt an Bedeutung, und der Grund klingt zunächst widersprüchlich: Sie gewinnt an Bedeutung, weil Bauen billiger wird.
Wenn Entwicklungskapazität nicht mehr der entscheidende Engpass ist und immer mehr Fachbereiche in die Lage kommen, Lösungen direkt zu beauftragen, dann steigt nicht in erster Linie unsere Lieferfähigkeit, sondern die Nachfrage. Ohne jemanden, der kuratiert, entsteht über die Zeit eine Landschaft maßgeschneiderter Anwendungen, die gewartet, abgesichert, dokumentiert und irgendwann auch wieder abgeschaltet werden müssen. Die Fähigkeit, begründet Nein zu sagen, wird also mit jeder Steigerung der Produktionskapazität wertvoller – weil die Kosten einer falschen Zusage nicht mehr in der Entwicklung anfallen, sondern im Betrieb.
Dazu kommt eine handwerkliche Verschiebung in unserer Spezifikationsarbeit. Akzeptanzkriterien müssen nicht mehr nur für Menschen verständlich sein, sondern präzise genug, dass daraus prüfbare Testszenarien entstehen können. Der Unterschied zwischen „die Suche soll schnell sein“ und einem Kriterium, gegen das sich automatisiert testen lässt, war früher eine Frage der Sorgfalt. Er wird zur Kernkompetenz. In Stellenausschreibungen großer Unternehmen taucht diese Anforderung inzwischen wörtlich auf, etwa als Akzeptanzkriterien, die für autonome und teilautonome Agenten-Workflows geeignet sein müssen.
Scrum.org formuliert die Konsequenz knapp:
Ein KI-Agent kann kein Product Owner sein.
Die Priorisierung einer Liste lässt sich automatisieren. Die Verantwortung für die Frage, was gebaut werden sollte und was besser nicht, lässt sich nicht delegieren.
Voraussetzungen und realistische Grenzen
Eine einzelne Change-Rolle kann einen Rollout dieser Breite wirksam begleiten – allerdings nur unter bestimmten Bedingungen. Aus der Praxis sind das vor allem diese vier:
Dedizierte Besetzung
Bei einem Rollout über sechs bis zwölf Monate ist diese Aufgabe kein Kommunikationsanteil neben anderen Tätigkeiten. Halbe Zuständigkeiten führen dazu, dass die Arbeit immer dann ausfällt, wenn es im Projekt eng wird – also genau dann, wenn sie gebraucht wird.
Früher Zugang zur Roadmap
Die Rolle muss von geplanten Integrationen erfahren, während sie noch geplant werden, und nicht, wenn sie fertig sind. Nachträgliche Change-Begleitung ist Schadensbegrenzung.
Ein belastbares Mandat
Erkannte Hindernisse müssen verbindlich in die Projektarbeit eingebracht werden können. Fehlt dieses Mandat, produziert die Rolle Berichte statt Wirkung.
Realistische Lieferplanung
Eine Person kann viele kleinere Erweiterungen parallel begleiten und Formate wiederverwenden. Sie kann aber nicht mehrere tiefgreifende Prozessänderungen gleichzeitig intensiv betreuen. Sollen mehrere arbeitsverändernde Automatisierungen zeitgleich produktiv gehen, müssen wir den Rollout entzerren oder befristet Unterstützung aus den betroffenen Fachbereichen holen. Das ist keine Frage der Change-Organisation, sondern der Planung.
Und eine Grenze sollten wir von Anfang an aussprechen: Keine Change-Rolle kann eine technisch unreife oder fachlich ungeklärte Lösung akzeptiert machen. Wenn Nutzende auf echte Qualitäts-, Daten- oder Prozessprobleme hinweisen, dann müssen diese im Produkt oder im Arbeitsablauf behoben werden. Wer stattdessen an der Akzeptanz arbeitet, verbrennt Vertrauen – und dieses Vertrauen brauchen wir bei der nächsten Erweiterung wieder.
Unser Fazit
Der einfachste Test, ob eine Organisation diese Rolle braucht, kostet etwa zwanzig Minuten. Wir nehmen die nächste geplante Erweiterung der KI-Plattform und gehen die fünf Fragen durch: Wer ist betroffen, was ändert sich in der täglichen Arbeit, was müssen die Betroffenen wissen, was muss vorher geklärt sein, woran erkennen wir hinterher, ob es funktioniert hat. Wer schon bei der zweiten Frage ins Stocken kommt, hat die Antwort auf die Ausgangsfrage übrigens schon gefunden.
Für uns Agilisten steckt in dieser Entwicklung eine unbequeme, aber im Kern gute Nachricht. Der Teil unserer Arbeit, der sich immer am leichtesten beschreiben ließ – Zeremonien moderieren, Boards pflegen, Velocity berichten – wird zunehmend von Software übernommen. Der Teil, den wir immer nur schlecht erklären konnten, wird dagegen zum Kern der Aufgabe: zwischen technischer Realität und Arbeitsalltag übersetzen, Verantwortung klären, bevor sie im Ernstfall ausfällt, und Menschen durch eine Veränderung begleiten, die an ihre berufliche Identität geht. Kent Beck hat das für seinen eigenen Beruf so formuliert: Der Wert von 90 Prozent seiner Fähigkeiten ist auf null gefallen, die Hebelwirkung der verbleibenden zehn Prozent um den Faktor tausend gestiegen. Auf uns übertragen heißt das nicht, dass unsere Rollen verschwinden. Sie verlagern sich – weg vom Prozess, hin zur Transformation.
Wenn in eurer Organisation gerade ein KI-Rollout läuft oder ansteht und einige dieser Fragen noch offen sind – wer betroffen ist, wer prüft, wer entscheidet und wer die Menschen dabei begleitet – dann sprecht uns gerne an. Wir helfen dabei, die passende Form für euren Kontext zu finden.
Quellen und Bezüge
- Scrum.org zur Product-Owner-Rolle in KI-Kontexten
- Kent Beck zur Verschiebung des Kompetenzwerts
- Stellenausschreibungen mit expliziter Anforderung an agententaugliche Akzeptanzkriterien (u. a. IQVIA, Citi, 2026)
- Rollenkonzept „Agile Change Manager“ nach der internen Leistungsbeschreibung von Johann-Peter Hartmann, Mayflower
- Datenlage und Kontext aus dem Vortrag „KI killt Agile. Wer steuert die Transformation?“ von Johann-Peter Hartmann
Schreibe einen Kommentar