R&D-Transformation mit KI-Agenten, eine Codebase nach der anderen.
Die meisten R&D-Organisationen setzen Agenten in eine Teamform, die für Menschen gebaut wurde, die jede Zeile selbst tippen. Der Durchsatz springt in einem Team, stockt im nächsten, und das Organigramm bleibt, wo es war. Das R&D-Betriebsmodell, ein Modul des Agentischen SDLC-Programms, gestaltet die Organisation danach neu, wie die Arbeit heute läuft: zuerst ein Delivery-Setup pro Codebase, darauf kleine Pods und ein zentrales Team, das jede Verbesserung zu allen Pods bringt. Es funktioniert von etwa 15 bis etwa 500 Engineers, auf modernem Code, auf Legacy-Code oder auf der üblichen Mischung aus beidem.
Zuerst das Setup, pro Codebase
Jede Codebase durchläuft dieselben vier Readiness-Stufen, bevor sich ein Team darauf auf mehr Durchsatz verpflichtet.
- Stufe 1PrimedAgenten finden sich zurecht: Kontext, aufgeschriebene Konventionen, eine Abhängigkeitskarte, Workflow-Tooling.
- Stufe 2VerifiableAgenten können ihre eigene Arbeit prüfen: eine grüne Pipeline, schnelle Regressionstests, Charakterisierungstests auf den Pfaden, die den Umsatz tragen.
- Stufe 3ProducibleSpecs fliessen vom Tracker zu den Agenten, ein zweites Modell prüft, und die Review-Tiefe richtet sich danach, wie viel eine Änderung kaputt machen kann.Ab hier verpflichten sich Teams auf Durchsatz
- Stufe 4CompoundingErkenntnisse aus jedem Lauf werden zu wiederverwendbaren Skills, und Sie sehen, welche davon tatsächlich wiederverwendet werden.
Ein Team verpflichtet sich auf Durchsatz, sobald seine Codebase Stufe 3 erreicht. Davor würde die Zahl das Setup messen und wenig über das Team sagen. Die Stufen beschreiben eine Codebase; das L0-L4-Reifegradmodell beschreibt die Organisation als Ganzes, und eine einzelne Organisation hat meist Codebases auf mehreren Stufen.
Pods aus drei bis fünf Personen, ein zentrales Team, ein Lab darin
- Spec LeadEntscheidet, was gebaut wird, und schreibt es auf.
- Builder · 2-4Steuern die Agenten.
- Review LeadBenannt. Verantwortet, was gemergt wird.
Die Arbeit läuft in Pods aus drei bis fünf Personen. Wo ein Fehler teuer wäre, bekommt der Pod eingebaute Verifikation. Pods haben keine Manager.
Ein kleines Plattform-Team verantwortet das gemeinsame Setup: Agenten-Tooling, die Pipeline und ihre Gates, die Skill-Bibliothek, das Review-Routing und die Spec-Pipeline. Es bleibt klein und wächst, wenn der Legacy-Anteil hoch ist, weil Legacy-Codebases mehr Setup-Arbeit brauchen.
- Lab · erkundenEine Person fährt schnelle, grobe Experimente mit neuen Modellen und Agenten-Fähigkeiten gegen Ihren eigenen Delivery-Prozess und verwirft die meisten davon.
- Lab · härtenEine andere härtet die Gewinner zu Skills und Tooling.
Weil das Lab im zentralen Team sitzt, erreicht ein gutes Ergebnis die ganze Organisation.
Die vorhandenen Rollen umwandeln
- QAVerification Engineers, die das Test-Tooling bauen
- Product ManagerSpec Leads, die die Spec-Warteschlange verantworten
- ManagerEinige wenige People Leads, dazu Review Leads und KI-Champions
Wo die Organisation kleiner werden muss, geschieht das über natürliche Fluktuation und Einstellungsstopps, ohne Entlassungsrunden, und das Pod-Modell wird nie zusammen mit einem Stellenabbau angekündigt. Juniors bleiben geschützt. Sie sind in ein paar Jahren Ihre Senior Engineers.
Kanban, begrenzt durch das Review
- Idee
- Spec
- Plan-Review
- Umsetzung
- Verifikation
- Merge
Scrum-Zeremonien weichen einem Fluss. Die Spec ist die Arbeitseinheit, und sie ist erst bereit, wenn sie Akzeptanztests enthält. Die Arbeit läuft von der Idee zur Spec, zu einem zweiten Modell, das den Plan prüft, dann zu Umsetzung, Verifikation und Merge.
Die Menge paralleler Arbeit ist durch das begrenzt, was Ihre Reviewer tatsächlich prüfen können, denn dort staut sich Arbeit im Agenten-Tempo. Standups und Sprint-Planung entfallen. Die Demo bleibt, ebenso eine monatliche Retro, die ihre Erkenntnisse zurück in die Skills schreibt.
Gemessen pro Team
Jedes Team wird an komplexitätsbereinigter Velocity gegen eine Baseline gemessen, die vor jeder Änderung fixiert wird, neben Qualität und Kosten. Daneben stehen einige Betriebssignale: wie viel menschliche Arbeit jeder Anwendungsfall noch braucht, welche Skills wiederverwendet werden und auf welcher Readiness-Stufe jede Codebase steht.
Individuelle Leistung bleibt aus den Zahlen heraus. Ticketzahlen sind nie das Ziel.
Legacy, modern oder beides
Auf modernem Code ist das Setup vom ersten Tag an die Basis, und Pods können innert Wochen Stufe 2 oder 3 erreichen. Ein getesteter Monolith bringt zuerst seine Tests auf Stufe 2, dann ziehen die Pods darauf. Tiefes Legacy, Jahrzehnte alt und kaum getestet, beginnt mit einem Quartal nur für das Setup: Charakterisierungstests, Regressionsläufe von Tagen in Richtung Stunden und das Wissen zentraler Maintainer aufgeschrieben. Nichts davon bekommt einen Big-Bang-Rewrite. Legacy-Code ohne strategische Zukunft bleibt auf Stufe 1 und wird gewartet.
Für einen gemischten Bestand gilt diese Reihenfolge:
- 1Die reifste Codebase zuerstAls Vorlage.
- 2Greenfield-Arbeit darauf
- 3Dann die getesteten Bestände
- 4Tiefes Legacy zuletztMit früh und parallel begonnener Charakterisierungsarbeit.
Willige Teams gehen voran. Den Legacy-Kern selbst auf neue Technologie zu bringen, ist ein eigenes Mandat, die Legacy-Migration.
Ein Festpreis nach R&D-Kopfzahl
- Etwa 15-50 EngineersCHF 50-80k
- 50-150 EngineersCHF 80-150k
- 150-500 Engineersab CHF 150k, auf Offerte
Wie sicher ich bin, und was öffentlich ist
Das ist das Setup, das ich heute für jede R&D-Organisation bauen würde. Teile davon stützen sich mehr auf Praxisberichte als auf kontrollierte Studien. Sorgfältige Messungen des Gewinns pro Engineer liegen deutlich unter den Schlagzeilen der Anbieter, und das Review ist der Engpass, der immer weiterwandert. Die Dimensionierung wird in jedem Mandat kalibriert.
Das Tooling ist öffentlich. Flow-Next, der Open-Source-Workflow, den ich baue und in Mandaten einsetze, liefert die Bausteine, auf die dieses Setup angewiesen ist.
- 8.2Product Owner und Business Analysts können ihren Teil einer Spec über ein Interview in Alltagssprache durchlaufen, ohne dass ein Engineer es steuert.
- 8.3Das Review-Panel kann einen Reviewer nach dem anderen laufen lassen, auf lokalen Modellen oder bei Anbietern mit Rate-Limits.
- 8.5Ein Review-Fokus lässt sich pro Task setzen.
- 8.5.2Das Modell, das Sie für die Umsetzung benennen, ist das Modell, das sie ausführt.
Häufige Fragen
Was kostet das?
Das R&D-Betriebsmodell ist ein Festpreis nach R&D-Kopfzahl: etwa 15-50 Engineers CHF 50-80k; 50-150 Engineers CHF 80-150k; 150-500 Engineers ab CHF 150k, auf Offerte. Alle Preise verstehen sich exkl. MWST. Die meisten Organisationen starten mit der SDLC-Diagnose (CHF 15-25k), die auch bewertet, auf welcher Readiness-Stufe jede Codebase steht.
Wie hängt das mit dem Code-Factory-Aufbau zusammen?
Beide sind Module des Agentischen SDLC-Programms. Der Code-Factory-Aufbau richtet die Factory mit einem Lead-Team ein. Das R&D-Betriebsmodell gestaltet die Organisation darum herum über alle Codebases neu: Pods, das zentrale Team, Rollen und Fluss. Der Gruppen-Rollout trägt das Ergebnis danach in die übrigen Unternehmen einer Gruppe.
Funktioniert das für ein Team von 20?
Ja. In dieser Grösse ist das zentrale Team eine Teilzeitrolle, die Builder übernehmen, und das Lab sind zwei Hüte, die dieselben Leute tragen. Das Modell trägt bis etwa 500 Engineers, gegliedert in Produktlinien.
Verlieren Leute ihre Stelle?
Der Plan wandelt Rollen um. Wo die Kopfzahl sinken muss, tragen das natürliche Fluktuation und Einstellungsstopps, Juniors sind geschützt, und die neue Teamform wird nie an eine Ankündigung von Entlassungen gekoppelt.
Müssen unsere Teams die Tools wechseln?
Nein. Ein Team auf Cursor bleibt auf Cursor; ein Team auf Claude Code bleibt dort. Geteilt werden die Readiness-Stufen, die Pod-Form und die Review-Regeln.
Wie messen Sie, ob es funktioniert hat?
Pro Team, gegen eine Baseline, die vor der Änderung fixiert wurde: komplexitätsbereinigte Velocity, Qualität und Kosten, zusammen gelesen. Ein Durchsatzgewinn, der mit entwischten Fehlern erkauft wurde, zählt als Verlust.
Ein Gespräch, dann eine Diagnose oder ein Scoping.
Wir gehen durch, wo Ihre R&D-Organisation steht, welche Codebases bereit sind und ob das Programm oder ein einzelnes Modul der richtige erste Schritt ist.