KI-Strategie · 4. September 2026

Prozess lassen,
Autoren tauschen.

Eine Organisation mit rund 200 Leuten fährt seit Monaten einen agentischen Entwicklungsablauf und hat dabei nichts an Planung, Sprints oder Roadmap geändert. Geändert hat sie, wer die Dokumente schreibt. Yuval Yerets Fallbeispiel auf scrum.org, und warum das für einen Betrieb mit zehn Leuten die bessere Nachricht ist als jede Superapp.

Lesedauer5 Minuten
KategorieKI-Strategie
Fallbeispielca. 200 Personen, 3 bis 4 Monate
Stand4. September 2026
„WIR HABEN DEN PROZESS NICHT GEÄNDERT": QUARTALSPLANUNG, SPRINTS, ROADMAP, JIRA, ALLES WIE VORHER FÜR JEDEN SCHRITT ZUR GUTEN ANFORDERUNG EINE SKILL-DATEI, EIN LEIT-SKILL FRAGT DICH AUS „DIE LEUTE SOLLEN NICHTS MEHR SELBST SCHREIBEN. SIE KORRIGIEREN DIE SKILLS ODER DEN KONTEXT" ABER: EIN FALLBEISPIEL AUS DER SOFTWARE-ENTWICKLUNG, ERZÄHLT VON EINEM BERATER „WIR HABEN DEN PROZESS NICHT GEÄNDERT": QUARTALSPLANUNG, SPRINTS, ROADMAP, JIRA, ALLES WIE VORHER FÜR JEDEN SCHRITT ZUR GUTEN ANFORDERUNG EINE SKILL-DATEI, EIN LEIT-SKILL FRAGT DICH AUS „DIE LEUTE SOLLEN NICHTS MEHR SELBST SCHREIBEN. SIE KORRIGIEREN DIE SKILLS ODER DEN KONTEXT" ABER: EIN FALLBEISPIEL AUS DER SOFTWARE-ENTWICKLUNG, ERZÄHLT VON EINEM BERATER

Die kleinste Änderung,
die wirklich etwas ändert.

Nach jeder beeindruckenden KI-Demo greifen Führungsteams zum großen Umbau: neuer Prozess, neue Rollen, neues Werkzeug. Der Agile-Berater Yuval Yeret beschreibt am 4. September auf scrum.org das Gegenteil, anhand einer Organisation, die Shay Mandel begleitet: Prozess lassen, nur den Autor tauschen. Das ist kleiner als alles, was nach einer Demo vorgeschlagen wird, und es funktioniert seit drei bis vier Monaten im echten Betrieb.

1

Skills schreiben,
Menschen korrigieren.

Quartalsplanung, Sprint-Planung, Roadmap, die Liste der Funktionen fürs Quartal, Jira, Confluence, die Trennung von Technik, Produkt und Fachbereich: alles unverändert. Was die Organisation stattdessen tat, war, die Arbeit zu zerlegen. Für jeden Schritt, der zu einer guten Anforderung führt, gibt es jetzt eine Skill-Datei: Problem beschreiben, Problem analysieren, Daten holen, Nutzerforschung, Wireframes, dann das Anforderungsdokument. Ein übergeordneter Skill sagt dir, in welchem Schritt du bist, und interviewt dich so lange, bis er den Abschnitt schreiben kann: Wie misst du das? Welche Wirkung erwartest du?

Dieselbe Behandlung bekam die teure Seite der Übergabe: die Prüfung durch die Technik. Ein Skill „PRD-Review durch Engineering" prüft vorab, ob jede Fachdomäne ihre Fragen im Dokument beantwortet findet, und gibt dem Produktmanager Korrekturvorschläge, bevor ein Mensch das Dokument sieht. Danach prüft ein Mensch, wirklich. Mandels Regel für alle: „Die Leute sollen nichts mehr selbst schreiben. Sie sollen die Skills oder den Kontext korrigieren." Wer ein schlechtes Ergebnis bekommt, repariert nicht das Ergebnis, sondern das System, das es erzeugt hat. Oder in seinen Worten: „Wir sind jetzt Entwickler, nicht des Codes, sondern des Systems."

ABER: Ein Fall, ein Berater, eine Branche

Es ist ein Fallbeispiel aus der Software-Entwicklung, erzählt von einem Berater, dessen Geschäft solche Umstellungen sind, ohne Zahlen zu Zeit- oder Qualitätsgewinn. Yeret sagt selbst, dass Menschen weiterhin den letzten Blick behalten, „bis sie das Vertrauen haben", und dass die Frage, welche Entscheidungen menschlich bleiben, eine echte Designfrage ist, kein Häkchen. Übertragbar ist das Prinzip, nicht die Zahl der Skills.

Das Fallbeispiel

QuelleYuval Yeret, scrum.org, 04.09.2026
Organisationca. 200 Personen
Im Betrieb seit3 bis 4 Monaten
Geändert am Prozessnichts
Geändertwer die Dokumente schreibt
Bei FehlernSkill korrigieren, nicht Text
Menschletzter Prüfer, nicht erster
2

Welches Dokument
schreibst du jede Woche neu?

Ein Betrieb mit zehn Leuten hat keine Quartalsplanung und kein Jira, aber er hat Artefakte: das Angebot, die Auftragsbestätigung, die Reklamationsantwort, den Wochenbericht an den Kunden, die Stellenanzeige. Alles Dokumente, die jede Woche neu entstehen und jedes Mal fast gleich aussehen. Yerets Prinzip übersetzt: Nicht den Ablauf umbauen. Einmal aufschreiben, wie ein gutes Angebot entsteht, in Schritten, und dann korrigiert man die Anleitung, nicht das Angebot.

Genau so laufen meine eigenen Bausteine. Für einen Artikel wie diesen gibt es eine Anleitung, die sagt, welche Quellen geprüft werden, was in die Faktenbox gehört und wo der Widerspruch stehen muss. Wenn ein Artikel schlecht wird, ändere ich die Anleitung, nicht den Artikel. Das ist Mandels „Entwickler des Systems" im Kleinen, und es ist derselbe Gedanke wie Metas Wissensdateien und die Personalakte der Frontier Firm: Das Wissen liegt in Dateien, die jeder lesen und verbessern kann. Der Unterschied zu einer Superapp ist, dass es dir gehört.

Der Anfang in vier Schritten

Erstens: das eine Dokument wählen, das am häufigsten neu entsteht. Zweitens: aufschreiben, in welchen Schritten ein gutes Exemplar entsteht und welche Fragen vorher beantwortet sein müssen. Drittens: die Anleitung dem Agenten geben und ihn das Dokument schreiben lassen, mit dir als letztem Prüfer. Viertens: bei jedem Fehler die Anleitung ändern, nie nur das Dokument. Nach zehn Durchläufen ist die Anleitung besser als jeder Mitarbeiter am ersten Tag, und sie geht nicht in Urlaub.

Für den Betrieb

Artefakte im BetriebAngebot, AB, Reklamation, Bericht
Nicht ändernden Ablauf
Ändernwer schreibt, wer korrigiert
Menschentscheidet und prüft zuletzt
Bei FehlernAnleitung ändern
Startein Dokument, vier Schritte

Wer das Dokument repariert, hat morgen dasselbe Problem. Wer die Anleitung repariert, hat es nie wieder.

Das ist der ganze Unterschied zwischen KI als Schreibhilfe und KI als System.

Keine Transformation.
Ein anderer Autor.

Von allen Texten dieser Woche über Agenten, Superapps und Frontier Firms ist das für mich der nützlichste, gerade weil er so unspektakulär ist. Keine neue Organisation, kein neues Werkzeug, keine Warteliste. Ein Betrieb behält seinen Ablauf und ändert, wer schreibt und wer korrigiert. Das ist eine Entscheidung, die ein Inhaber an einem Nachmittag treffen kann, und sie ist reversibel, falls sie nicht trägt.

Der eigentliche Wechsel steckt in Mandels Satz vom „Entwickler des Systems". Er meint nicht, dass jeder programmiert. Er meint, dass jeder, der ein schlechtes Ergebnis sieht, nicht mehr das Ergebnis flickt, sondern die Anleitung. Wer das im Betrieb durchsetzt, hat in einem halben Jahr Anleitungen, die besser sind als jede Einarbeitung. Wer es nicht durchsetzt, hat KI-Text, den jeder jedes Mal neu korrigiert, und das ist Workslop mit Extraschritt.

Merken für die Praxis

Nicht den Prozess umbauen. Ändern, wer die Dokumente schreibt: Skills schreiben, Menschen korrigieren die Skills.
Mensch bleibt letzter Prüfer, nicht erster. Welche Entscheidungen menschlich bleiben, wird ausdrücklich festgelegt.
Ein Fallbeispiel aus der Software-Entwicklung ohne Zahlen. Übertragbar ist das Prinzip.
Start im Betrieb: ein Dokument, vier Schritte, und bei jedem Fehler die Anleitung ändern, nie nur den Text.

Quelle: Yuval Yeret, „Don't Redesign Your Process Yet. Change Who Writes the Artifacts." (scrum.org, 04.09.2026, zuerst auf yuvalyeret.com, mit Zitaten von Shay Mandel). Stand: 04.09.2026.

Gratis-Online-Guide

Der KI-Werkzeugkasten 2026

Welches Modell für welche Aufgabe, welche Tools wirklich zählen und wie du richtig promptest — komplett lesbar, kein Download.

Jetzt gratis lesen →
Kein Spam · Double-Opt-In · Abmeldung jederzeit
✓ Eingetragen — bitte bestätige noch die Mail in deinem Postfach.
Zum KI-Werkzeugkasten →

Dein erstes Dokument,
das sich selbst verbessert.

Ich schreibe mit dir die Anleitung für das Dokument, das du jede Woche neu erzeugst, und richte den Agenten ein, der es ab dann schreibt. Du prüfst zuletzt. Lass uns anfangen.

Kennenlernen →