Stell dir folgende Szene vor: Es ist Montagmorgen, du hast mehrere Projekte parallel auf dem Tisch – und in jedem Status-Call schwebt dieselbe Frage im Raum: „Wie lange dauert das noch?“ Genau an diesem Punkt steht Mima.
Mima führt KKO – ein Team, das unter ihrer Leitung mehrere Projekte für verschiedene beauftragende Firmen betreut. Manche dieser Projekte sind KKO-eigene Vorhaben, manche sind sogar persönliche Herzensprojekte. Der Kern des Teams wird von Anaya getragen: Anaya ist die Chefin einer indischen Entwicklungsfirma und damit Mimas wichtigste Auftragnehmerin. Auf Mimas Seite steht außerdem Gandalf, CTO und technischer Taktgeber: Er kümmert sich um die Leitplanken für Qualität, Prozess und die Frage, wie aus „Code“ verlässlich „Lieferung“ wird.
Und jetzt kommt die eigentliche Spannung: Mima möchte gegenüber Anaya Verbindlichkeit – am liebsten in Form von Tagen. Gandalf sieht jedoch, dass ihr gerade ein komplett anderes Spiel spielt: AI‑First.
⸻
Executive Summary (gesamt)
• Der Konflikt ist kein reines Timing-Problem, sondern ein Definitionsproblem: Wird Prozess geliefert oder Ergebnis?
• „Tage“ sind in einer Transformation die falsche Steuerungsgröße. AI‑First ist ein Umbau von Prozess, Tooling und Qualitätsstandards.
• Prototyp-Speed ist nicht Produkt-Reife. Die letzten 10% (Integration, Tests, Betrieb) dominieren die echte Lieferzeit.
• AI verstärkt Seniorität. Ohne Standards, Reviews und Enablement skaliert der Effekt nicht – er verteilt sich nur ungleich.
• Die Lösung ist ein neues Arbeitsmodell mit Anaya: Spielregeln, Phasenplan, wenige harte Metriken, Operating Model und Vertrauensarchitektur.
⸻
Teil 1: Kontext und Beteiligte
Das Ausgangsdilemma: „Wie sage ich’s Anaya – und woran machen wir’s fest?“
Mima kommt zu Gandalf, weil sie spürt: Wenn sie Anaya einfach nur „Bitte schneller“ sagt, wird sich nichts nachhaltig verbessern. Gleichzeitig kann sie sich nicht leisten, dass Projekte „diffus“ werden. Sie braucht Planbarkeit, weil KKO mehrere Auftraggeber parallel bedient – und weil „privat“ in ihrer Welt nicht heißt „unwichtig“, sondern oft „besonders wichtig“.
Anaya steht auf der anderen Seite des Tisches: Sie führt eine Entwicklungsfirma, die den Kern von KKO bildet. In solchen Beziehungen ist es naheliegend, dass die Auftraggeberseite über Zeit spricht („Wie viele Tage?“), während die Auftragnehmerseite über Vorgehen spricht („Wir müssen erst den Prozess aufsetzen“).
Mima steht also zwischen zwei Bedürfnissen: Sie braucht Ergebnisse und sie braucht ein Upgrade des Systems, weil „mehr Druck“ das System nicht verbessert – es stresst es nur. Genau hier setzt Gandalfs Rat an.
⸻
Teil 2: Technische Einordnung und Steuerungslogik
Executive Summary (Gandalfs Rat, ultrakompakt)
Definiert das Lieferobjekt neu: nicht „Tage“, sondern ein fähiges Delivery-System. Steuert über Outcome, Qualität und Reifegrad (Prozess + Tooling + Standards). Erwartet Transformationszeit; trennt Prototyp-Speed strikt von Produkt-Reife; plant Integrations-, Test- und Betriebsrealität explizit ein. Und: baut Senior-Guidance und Enablement als Feature der Umstellung – nicht als „Nice to have“.
⸻
1) Grunddiagnose: Erwartungs-Mismatch (Prozess vs. Ergebnis)
Gandalf beginnt nicht mit Tool-Fragen, sondern mit einem simplen Satz: „Ihr verkauft und kauft gerade unterschiedliche Produkte.“
• Anaya betont eine Herangehensweise: bessere Zusammenarbeit, sauberere Umsetzung, AI‑First‑Methoden.
• Mima braucht Ergebnisse: Features, Releases, sichtbare Fortschritte.
Beides ist legitim. Das Problem ist: Wenn ihr nicht klar sagt, was das Produkt eurer Zusammenarbeit ist, verhandelt ihr ständig am falschen Hebel.
Praktisches Beispiel:
Anaya sagt: „Wir haben das Refactoring abgeschlossen, die Architektur ist jetzt sauber.“
Mima hört: „Das Feature ist immer noch nicht live.“
Konsequenz: Zuerst braucht ihr eine neue Lieferdefinition – nicht nur einen neuen Sprintplan.
Konkretes Artefakt (klein, aber wirksam): eine einseitige Lieferdefinition pro Projekt:
• Outcome (was ist für den Auftraggeber wertvoll?)
• Qualitätslevel (z.B. Testtiefe, Security, Observability)
• Abnahmekriterien (wann gilt es als geliefert?)
• Nicht-Ziele (was ist explizit nicht Teil des Lieferobjekts?)
Merksatz: Wenn ihr über Zeit streitet, streitet ihr oft über das falsche Produkt.
⸻
2) Falsche Steuerungsgröße: „Anzahl der Tage“
„Wie viele Tage?“ klingt nach Kontrolle, ist aber oft eine Illusion – besonders in Umstellungen. Gandalf nennt „Tage“ eine Output-Schätzung, die in einer Transformationsphase zu wenig aussagt, weil sie die entscheidenden Unsicherheiten nicht abbildet: Toolchain, Review-Qualität, Teststrategie, Integrationshürden, Reifegrad im Umgang mit AI.
Zeit ist nicht egal. Aber: Zeit wird erst verlässlich, wenn das System stabil ist. In einer Transformation misst du zuerst den Aufbau von Fähigkeiten.
Alternative Steuerung: Reifegrad statt Tage
Gandalf denkt in Stufen, nicht in Kalendern. Zum Beispiel pro Bereich:
• Spezifikation (0: Zuruf … 3: klare Specs + Akzeptanzkriterien)
• Tests (0: kaum … 3: automatisiert + sinnvolle Abdeckung)
• CI/CD (0: manuell … 3: automatisiert + Quality Gates)
• Observability (0: „läuft“ … 3: Logs/Tracing/Alerts, die Probleme früh zeigen)
Merksatz: In einer Transformation ist „Zeit“ das Ergebnis – nicht der Startpunkt.
⸻
3) Realitätsscheck: AI‑First ist keine schnelle Umschaltaktion
AI‑First wird häufig verkauft wie ein Booster: „Mit AI geht alles schneller.“ Gandalf präzisiert: AI beschleunigt Code – nicht automatisch Qualität, Verständnis oder Betrieb.
Viele Teams erleben eine typische Kurve:
1. Euphorie: Code entsteht schneller, Demos sehen gut aus.
2. Einbruch: Integration, Bugs, Uneinigkeit über Standards.
3. Stabilisierung: Playbooks, Templates, Review-Routinen, Tooling – dann wird’s wirklich schneller.
Wenn Mima in Phase 1 „Tage“ verlangt, zwingt sie das System in Phase 2 – und interpretiert den Einbruch als Leistungsproblem, obwohl es ein Reifegradproblem ist.
Praktische Entscheidung: AI‑First beginnt nicht überall, sondern in einem Pilotbereich: ein Modul, ein Service, ein Feature-Cluster. Dort werden Standards gebaut, die später skaliert werden.
Merksatz: AI‑First ist ein Programm – kein Schalter.
⸻
4) Scope-Shift: Nicht nur Code, sondern gesamter Entwicklungsprozess inkl. Tooling
Der häufigste Fehler bei AI‑First: Man reduziert es auf „wir nutzen ein AI‑Tool beim Coden“. Gandalf macht daraus ein Betriebssystem-Upgrade:
• Spezifikationen werden strukturierter (damit AI zielgerichtet arbeitet).
• Reviews werden wichtiger (weil AI viel produziert, aber nicht „weiß“, was für euch richtig ist).
• Tests müssen früher kommen (damit schneller Output nicht schneller Chaos wird).
• CI/CD und Quality Gates müssen strenger werden (damit Geschwindigkeit nicht in Instabilität kippt).
• Betrieb/Observability muss mitwachsen (sonst merkt ihr Probleme zu spät).
Eine hilfreiche Formulierung für Mima im Gespräch mit Anaya:
„Ich will nicht nur schnelleren Code. Ich will ein System, das uns schneller zu Releases bringt – inklusive Tests, Reviews, Deployment und Betrieb.“
Merksatz: AI‑First ist nicht ein Tool. AI‑First ist eine Toolchain + ein Prozess.
⸻
5) Abgrenzung: Prototyp ≠ Produkt (Reifegrad & Erwartungsmanagement)
AI kann in Stunden etwas bauen, wofür früher Tage nötig waren. Das erzeugt den gefährlichen Reflex: „Dann muss das doch auch schnell produktiv gehen.“ Gandalf trennt hart:
• Prototyp: zeigt Richtung, ist explorativ, darf wackeln, optimiert für Lernen.
• Produkt: muss wartbar, testbar, sicher, integrierbar, supportfähig sein.
Wenn Mima „Produkt“ erwartet, aber „Prototyp“ akzeptiert, entsteht Frust auf beiden Seiten: Anaya fühlt sich unfair bewertet, Mima fühlt sich hingehalten.
Konkretes Artefakt: eine „Production Readiness Checklist“ (max. 10 Punkte), z.B.:
• Akzeptanzkriterien erfüllt
• Tests vorhanden (Unit + kritische Integration)
• Logging/Monitoring vorhanden
• Rollback-Plan/Feature Flag
• Dokumentation/Runbook
• Security-Basics geprüft
Merksatz: Ein Demo ist kein Release.
⸻
6) Zeitfalle: 90‑90‑Regel gilt auch bei AI‑First
Gandalf bringt die 90‑90‑Regel in den Raum, weil sie so gut weh tut:
Die ersten 90% dauern 90% der Zeit – die letzten 10% die anderen 90%.
Diese letzten 10% sind selten „Code“. Es sind Integration in reale Systeme, Edge Cases, Stabilität, Deployments, Migrationen, UX-Polish und Betrieb (Alerts, Dashboards, On-Call-Realität). AI hilft – aber sie eliminiert diese Arbeit nicht. Wer sie ignoriert, produziert nur schneller die ersten 90%.
Praktischer Mechanismus: Plant „Hardening“ explizit ein: Stabilisierungsschleifen, nicht als Resteverwertung am Ende.
Merksatz: Die letzte Meile ist ein eigenes Projekt.
⸻
7) Team-Fähigkeit als Bottleneck: Juniors profitieren weniger von AI als Seniors
AI macht Teams nicht automatisch gleich stark. Sie verstärkt Urteilskraft. Seniors nutzen AI, um schneller zu denken, Varianten zu prüfen, Risiken zu sehen. Juniors bekommen schneller Text – aber oft ohne die Fähigkeit, ihn zuverlässig zu bewerten.
Gandalf formuliert das als Design-Constraint: Wenn ihr AI‑First ernst meint, müsst ihr Führung, Reviews und Enablement als Teil der Delivery betrachten.
Was das praktisch bedeutet:
• Pairing (Junior + Senior) auf kritischen Aufgaben
• Review-Gates (als Sicherheitsnetz, nicht als Schikane)
• Playbooks: „Wie schreiben wir Specs?“, „Wie testen wir?“, „Wie nutzen wir AI?“
• Lernpfade und „golden examples“ im Repo
Merksatz: AI verstärkt Seniorität – und macht Führung wichtiger, nicht weniger.
⸻
Teil 3: Umsetzung und Zusammenarbeit mit Anaya
Executive Summary (Teil 3)
Teil 3 übersetzt Gandalfs Einordnung in ein arbeitsfähiges Vorgehen mit Anaya: neue Delivery-Spielregeln, ein phasenbasierter Umstellungsplan, ein schlankes Mess- und Reporting-System, ein verbindliches Operating Model für KKO sowie eine Vertrauensarchitektur aus Transparenz, Erwartungsklarheit und Eskalationswegen.
⸻
1) Vereinbarung mit Anaya – neue Spielregeln für Delivery
Der wichtigste Schritt ist nicht ein neues Tool, sondern ein neues Agreement. Mima braucht eine Sprache, die Verbindlichkeit schafft, ohne falsche Sicherheit zu erzeugen.
Ein Satz, der erstaunlich viel entkrampft:
„Wir committen nicht auf Tage, sondern auf ein Ergebnis mit klarer Definition of Done und Quality Gates.“
Was sollte in dieser Vereinbarung stehen?
• Lieferobjekt pro Iteration (Outcome, nicht Aktivität)
• Pflicht-Artefakte (Specs, Tests, Release Notes, Runbooks)
• Quality Gates (CI, Reviews, Mindest-Testanforderungen)
• Umgang mit Unsicherheit (Risiken früh markieren, Mitigations benennen)
Das ist kein juristisches Dokument. Es ist ein gemeinsames Betriebssystem für Zusammenarbeit.
⸻
2) Der Umstellungsplan – von heute bis „AI‑First in Produktion“
Damit „Transformation“ nicht nach „unendlich“ klingt, braucht ihr Phasen. Nicht als starres Gantt-Denken, sondern als Orientierung. Ein pragmatischer Vierphasen-Plan:
Phase 1: Pilot
• Ziel: Ein abgegrenzter Bereich wird AI‑First umgesetzt.
• Deliverable: Erstes Release + dokumentierte Learnings.
• Exit: Playbook-Entwurf + erste Quality Gates laufen.
Phase 2: Standards
• Ziel: Templates, Review-Routinen, Teststrategie stabilisieren.
• Deliverable: Spec-Template, PR-Checklist, CI-Gates.
• Exit: Wiederholbare Delivery im Pilotbereich.
Phase 3: Rollout
• Ziel: Standards auf weitere Projekte/Module ausweiten.
• Deliverable: Migration-Plan, Onboarding, Trainings.
• Exit: Mehrere Streams liefern nach gleichen Regeln.
Phase 4: Stabilisierung
• Ziel: Betrieb, Observability, Tech-Debt-Management.
• Deliverable: SLOs/SLIs, Alerts, Runbooks, Hardening-Zyklen.
• Exit: AI‑First ist „Normalbetrieb“, nicht Sonderprojekt.
Wichtig: In Phase 1 braucht Mima ein sichtbares Ergebnis, sonst kippt Vertrauen. Der Trick ist, den Pilot so zu wählen, dass er wertvoll genug ist, ohne das ganze System zu riskieren.
⸻
3) Messsystem statt Bauchgefühl – KPIs, Artefakte, Cadence
Wenn „Tage“ rausfliegen, braucht es Orientierung. Gandalf würde sagen: „Messsystem statt Bauchgefühl.“ Die Kunst ist, wenige Metriken zu wählen, die Verhalten verbessern, ohne zu gamifizieren. Ein Minimal-Set:
• Lead Time (von „ready“ bis „released“)
• Release-Frequenz (wie oft geht wirklich etwas live?)
• Change Failure Rate (wie oft führen Releases zu Problemen?)
• Mean Time to Recovery (wie schnell seid ihr wieder stabil?)
• Review-Quote (wie viel wird tatsächlich gegengelesen?)
• Test-Signal (kritische Pfade sind getestet)
Dazu eine Cadence:
• Weekly Delivery Review: Was ist live? Was blockiert? Welche Risiken sind neu?
• Monthly Process Review: Welche Regel hilft, welche nervt, was fehlt?
So wird Verbindlichkeit sichtbar – nicht über Versprechen, sondern über wiederholbare Lieferung.
⸻
4) Operating Model KKO – Governance, Rollen, Reviews
Ohne Operating Model wird AI‑First schnell zu „jeder macht’s anders“. Für KKO, das mehrere Projekte parallel bedient, ist das Gift.
Ein schlankes Operating Model beantwortet fünf Fragen:
1. Wer priorisiert? (Mima)
2. Wer setzt Technik-Leitplanken? (Gandalf, mit Delegationsregeln)
3. Wer liefert? (Anayas Team)
4. Wer approved Releases? (klar definiert)
5. Wie wird Qualität erzwungen? (Gates, nicht Hoffnung)
Praktisch heißt das: PR-Checklists, Review-Pflicht für kritische Bereiche, CI-Gates, Definition of Done. Nicht als Bürokratie, sondern als Schienen, damit Geschwindigkeit nicht entgleist.
⸻
5) Vertrauensarchitektur – Erwartungen, Transparenz, Verbindlichkeit
Am Ende ist vieles ein Vertrauensproblem – oder genauer: ein Problem fehlender Mechanismen, die Vertrauen erzeugen.
Eine „Vertrauensarchitektur“ besteht aus drei Elementen:
Erwartungsklarheit
Was ist „gut genug“? Was ist Produkt-Release, was ist Demo?
Transparenz über Artefakte
Nicht „wir sind bei 80%“, sondern: Spec vorhanden, Tests laufen, Release Candidate deployed, Monitoring aktiv.
Eskalations- und Entscheidungswege
Wenn etwas hängt: Wer entscheidet? Bis wann? Was passiert ohne Entscheidung?
Ein einfaches Werkzeug ist ein Ampelstatus pro Stream:
• Grün: Lieferung läuft, Risiken klein
• Gelb: Risiken real, Mitigation geplant
• Rot: Blocker, Entscheidung/Eskalation nötig
So werden Probleme früher sichtbar – und Gespräche werden sachlicher.
⸻
Zusammenführung und ultrakompaktes Konzentrat
Ausführliche Zusammenfassung
Der Konflikt zwischen Mima (KKO) und Anaya ist auf den ersten Blick ein Zeitkonflikt – auf den zweiten Blick aber ein Konflikt über das Lieferobjekt. Gandalf hilft, indem er das Gespräch wegzieht von „Wie viele Tage?“ hin zu „Was liefern wir eigentlich – Prozess oder Ergebnis?“ In einer AI‑First‑Umstellung ist „Tage“ eine schlechte Steuerungsgröße, weil ihr nicht nur Features baut, sondern Fähigkeiten: Prozess, Tooling, Standards, Reviews, Tests, Betrieb. Diese Transformation hat eine Lernkurve: Erst wirkt alles schneller (Prototypen), dann kommt die Realität (Integration, Qualität, Betrieb), und erst mit stabilen Standards wird Geschwindigkeit nachhaltig.
Genau deshalb ist die Trennung von Prototyp und Produkt zentral. AI kann schnell funktionierenden Code erzeugen – aber „funktionierend“ ist nicht automatisch wartbar, sicher oder supportfähig. Die 90‑90‑Regel erinnert daran, dass die letzten 10% (Integration, Edge Cases, Stabilität, Deployments, Observability) die Zeit dominieren – und dass AI diese Arbeit nicht eliminiert. Zusätzlich wirkt ein Team-Bottleneck: AI verstärkt Seniorität. Ohne Senior-Guidance, Review-Gates und Enablement wird das Team nicht gleichmäßig schneller; es wird ungleichmäßig.
Die praktische Antwort ist ein neues Kooperationsmodell mit Anaya: neue Delivery-Spielregeln (Outcome/Quality/Reifegrad statt Tage), ein phasenbasierter Umstellungsplan bis „AI‑First in Produktion“, ein schlankes Mess- und Reporting-System, ein Operating Model für KKO (Rollen, Governance, Quality Gates) und eine Vertrauensarchitektur, die Transparenz und Eskalation organisiert. So entsteht Verbindlichkeit nicht durch Schätzungen, sondern durch sichtbare Artefakte, klare Standards und eine gemeinsame Definition von „fertig“.
Ultrakompaktes Konzentrat (1 Absatz)
Nicht „Wie viele Tage?“, sondern „Welches Delivery-System liefern wir?“: AI‑First ist eine Transformation von Prozess, Tooling und Qualität, in der Prototyp-Speed nicht Produkt-Reife ist und die letzten 10% (Integration/Tests/Betrieb) die Zeit dominieren; steuerbar wird das erst durch neue Spielregeln mit Anaya, einen Phasenplan, wenige harte Metriken, ein Operating Model mit Review-/Quality-Gates und eine Vertrauensarchitektur aus Transparenz, Erwartungsklarheit und klaren Eskalationswegen.
