Reifegrad messen statt schätzen

Wo eine Organisation auf dem Weg zur agentischen Softwareentwicklung steht, wird in den meisten Häusern geschätzt: nach der Zahl verteilter Copilot-Lizenzen, nach Zufriedenheitsumfragen oder nach den Erfolgsgeschichten einzelner Teams. Belastbar ist das nicht. Dieser Beitrag beschreibt, welche Kennzahl auf welcher Reifegradstufe zählt, wie ein Reifegrad-Assessment den Standort je Domäne bestimmt, mit welchem Kennzahlensystem der agentische Software Development Lifecycle gesteuert wird und was nach der 90-Tage-Messung im laufenden Betrieb überwacht wird.

Warum Schätzungen in Pilotinseln enden

Im ersten Beitrag dieser Serie habe ich das Reifegradmodell in sechs Stufen von L0 bis L5 vorgestellt, im zweiten die Prüfgates, an denen Menschen entscheiden. Beides bleibt Theorie, solange eine Organisation nicht weiß, wo sie steht. Und genau hier beobachten wir in fast jedem Haus dasselbe Muster: Die Lizenzen sind verteilt, die Entwicklerinnen und Entwickler berichten von Zeitgewinnen, die Akzeptanzrate der Vorschläge wird ausgewertet, und auf Portfolioebene verändert sich weder Durchlaufzeit noch Qualität noch Kostenstruktur messbar.

Der Grund ist nicht, dass die Werkzeuge nicht wirken, sondern dass die falsche Kennzahl beobachtet wird. Die Akzeptanzrate eines Copiloten misst, wie oft eine Person einen Vorschlag übernimmt. Sie sagt nichts darüber, ob Aufträge schneller produktionsreif werden, ob die Fehlerrate stabil bleibt oder ob die Organisation mit weniger Personaleinsatz denselben Output liefert. Wer mit dieser Kennzahl steuert, optimiert die Werkzeugnutzung und übersieht das Betriebsmodell. Das ist der erste der vier Gründe, aus denen agentische Transformationen scheitern: Werkzeuge ohne Betriebsmodell. Und es ist der Grund für einen unserer Grundsätze: Steuern Sie mit Evidenz, nicht mit Anekdoten.

Eine Kennzahl, die zur Reifegradstufe passt, sagt mehr über den Standort als jede Selbsteinschätzung.

Eine Leitkennzahl je Reifegradstufe

Das Reifegradmodell, das wir in Anlehnung an das Capability Maturity Model (Paulk et al. 1993) und die DORA-Forschung zur Delivery-Performance (Forsgren, Humble, Kim 2018) verwenden, ordnet jeder Stufe eine Leitkennzahl zu.

Zwei Dinge fallen an dieser Tabelle auf. Erstens wechselt die Kennzahl am Kipppunkt zwischen L3 und L4 ihren Gegenstand: Bis L3 wird die Interaktion zwischen Mensch und Werkzeug gemessen, ab L4 das Ergebnis eines Auftrags, den ein Agent end-to-end bearbeitet hat. Wer die Zykluszeit je Auftrag nicht erheben kann, weil es keine abgegrenzten Aufträge mit maschinenlesbaren Gate-Kriterien gibt, steht noch nicht auf L4, unabhängig davon, wie leistungsfähig die eingesetzten Modelle sind. Zweitens ist die Kennzahl auf L5 keine Geschwindigkeitskennzahl mehr, sondern eine Effizienzkennzahl mit Qualitätsbedingung: Durchsatz je Vollzeitkraft zählt nur bei stabiler Qualität.

Das Modell ersetzt damit Anekdoten durch eine Regel: Eine Organisation steht auf der Stufe, deren Leitkennzahl sie aus ihren Delivery-Systemen erheben kann und mit der sie tatsächlich Entscheidungen trifft.

Das Assessment: Standort je Domäne, nicht je Organisation

Eine Organisation hat keinen einzigen Reifegrad. Eine Bank kann in CI/CD und Release Engineering auf L2 stehen, im Daten- und Wissensfundament auf L0 und in einzelnen Teams mit Copiloten auf L3. Ein Gesamtwert würde diese Unterschiede verdecken und die entscheidende Information verlieren: Welche Domäne begrenzt den Fortschritt der anderen? Ohne konsolidierte Plattform gibt es keine verlässlichen Agenten, ohne Quality Gates keine Autonomie, ohne Governance keine regulatorische Freigabe.

Deshalb arbeiten wir im Reifegrad-Assessment mit einem Kapabilitätsmodell, das die Delivery-Organisation in Domänen zerlegt und jede Fähigkeit einzeln gegen die sechs Stufen bewertet. In einem laufenden Projekt bei einer europäischen Großbank (anonymisiert, Projektstand erstes Quartal 2026) umfasst das Modell 41 Fähigkeiten in neun Domänen, regulatorisch auf Bankenaufsicht, DORA und KI-Verordnung gemappt: Engineering-Praktiken, CI/CD und Release Engineering, Architektur und Plattform, Resilienz und Observability, Delivery-Governance und Flow, Daten- und Wissensfundament, Sicherheit, Risiko und Compliance, Fachbereichs- und Kundenausrichtung sowie Kultur, Menschen und Führung. Der Standort lag bei L2, das Programmziel für das erste Jahr liegt bei L3 in der Fläche, Agent-Unterstützung folgt ab Jahr zwei.

Drei Regeln machen ein solches Assessment belastbar:

• Evidenz statt Fragebogen. Die Einstufung je Fähigkeit stützt sich auf das, was in Repositories, Pipelines, Ticketsystemen und Betriebsdaten nachweisbar ist, nicht auf die Selbsteinschätzung der Teams. Ein Team, das angibt, Tests zu automatisieren, wird an seiner Testabdeckung gemessen.
• Baseline vor dem ersten Piloten. Die Baseline-Kennzahlen werden in der Diagnose erhoben, aus denselben Systemen und mit derselben Definition, mit der später gemessen wird. Ohne Baseline lässt sich nach 90 Tagen Pilotbetrieb kein Effekt nachweisen, sondern nur behaupten.
• Regulatorisches Mapping. Jede Fähigkeit ist den Anforderungen zugeordnet, die sie erfüllt: der KI-Verordnung (EU) 2024/1689 bei menschlicher Aufsicht und Nachvollziehbarkeit, der Verordnung (EU) 2022/2554 (DORA) bei IKT-Risikomanagement und Resilienz. So ist die Lücke zur Aufsichtsfähigkeit von Anfang an sichtbar, nicht erst vor dem Produktivgang.

Das Ergebnis der Diagnose, die in vier bis acht Wochen abgeschlossen ist, sind vier Dinge: der Standort je Domäne, das quantifizierte Effizienzpotenzial samt Baseline, ein priorisiertes Startportfolio mit Quick Wins und ein Roadmap-Entwurf in drei Horizonten. Es ist die Faktenbasis, auf der Vorstand und Aufsichtsgremien über das Zielbild entscheiden.

Das Kennzahlensystem: eine Vorstandskennzahl, Phasen-KPIs, Leitplanken

Sobald der Standort bestimmt ist, braucht die Steuerung ein Kennzahlensystem, das über die Pilotphase hinaus trägt. Wir arbeiten mit drei Ebenen.

Auf Vorstandsebene genügt eine Kennzahl: Delivery-Effizienz, gemessen als abgeschlossene Arbeitseinheiten je Vollzeitkraft, quartalsweise je Bereich, direkt aus den Delivery-Systemen erhoben und damit nicht manipulierbar. Das Zielbild ist nüchtern: Der Output bleibt stabil, der Personaleinsatz sinkt über natürliche Fluktuation, weil Agenten die repetitive Arbeit absorbieren. In unserem illustrativen Zielbild liefert ein Bereich im ersten Quartal 120 Arbeitseinheiten mit 25 Vollzeitkräften, also 4,8 Einheiten je Vollzeitkraft, und im vierten Quartal dieselben 120 Einheiten mit 20 Vollzeitkräften, also 6,0. Das entspricht 25 Prozent mehr Effizienz bei 20 Prozent weniger Personaleinsatz über vier Quartale, ohne Verwerfungen.

Phasen-KPIs messen den Fortschritt im Detail: die Zeit von der Idee zur validierten Spezifikation, die Zeit vom Commit zur Produktionsreife und der Anteil automatisierter Tests. Sie zeigen, in welcher Phase des Lebenszyklus die Agenten wirken und wo die Übergaben noch Zeit kosten. Auf L4 kommt die Zykluszeit je Auftrag hinzu, gemessen von der Abnahme der Spezifikation am Gate Definition of Ready bis zur Produktionsfreigabe.

Qualitäts-Leitplanken entscheiden, ob Effizienz überhaupt zählt: Change Failure Rate, Produktionsstörungen der Prioritäten eins und zwei, Defektrate und Testabdeckung dürfen sich nicht verschlechtern. Den etablierten Standard dafür liefern die vier Kennzahlen der DORA-Forschung (DevOps Research and Assessment; Forsgren, Humble, Kim 2018): Deployment-Frequenz, Durchlaufzeit von Änderungen, Change Failure Rate und Wiederherstellungszeit. Sie sind nicht mit der gleichnamigen EU-Verordnung zu verwechseln.

Für die Einordnung unserer eigenen Zahlen gilt dieselbe Disziplin. Die bis zu fünffach schnellere Delivery gilt im agentisch orchestrierten Umsetzungsmodell, also für den reinen Coding-Anteil, bei bis zu 80 Prozent geringeren Codierkosten. Über Gesamtprojekte inklusive Strategie, Spezifikation und Steuerung liegt der Effizienzgewinn bei 20 bis 45 Prozent, die Qualität steigt durch systematische Verifikation um rund 30 Prozent. Alle vier Werte sind Erfahrungswerte aus ReqPOOL-Projekten 2023 bis 2026, projektspezifisch validierbar und keine wissenschaftliche Evidenz. Ein Assessment, das eine fünffache Beschleunigung über das Gesamtprojekt verspricht, hat die Kennzahlen verwechselt.

Was nicht gemessen werden sollte

Ebenso wichtig ist, was aus dem Kennzahlensystem herausbleibt. Generierte Codezeilen, die Zahl der Prompts, verbrauchte Tokens oder die Auslastung der Lizenzen messen Aktivität, nicht Wirkung. Sie steigen mit jedem Agenten, den man hinzufügt, und sagen nichts darüber, ob die Organisation schneller, besser oder günstiger liefert. Ich halte sie für die gefährlichsten Kennzahlen der agentischen Entwicklung, weil sie so leicht zu erheben sind und so überzeugend aussehen.

Nach der 90-Tage-Messung: Monitoring als Dauerzustand

Die Pilotierung mit zwei bis drei Leuchtturmzellen endet mit der 90-Tage-Messung gegen die Baseline. Sie beantwortet die Frage, ob das Betriebsmodell in der eigenen Organisation nachweislich funktioniert, und liefert die Blaupause für die erste Rollout-Welle. Skaliert wird nur bei erfüllten Kennzahlen; Quick Wins müssen ihren messbaren Effekt binnen 180 Tagen zeigen, zurückgestellte Initiativen werden im nächsten Planungszyklus neu bewertet.

Nach dem Piloten hört die Messung nicht auf, sie wechselt ihren Charakter. Drei Mechanismen tragen das Monitoring im laufenden Betrieb:

1. Kennzahlen aus dem Prozess, nicht aus Berichten. Weil Gate-Kriterien maschinenlesbar hinterlegt sind und jeder Agentenschritt protokolliert wird, entstehen Zykluszeit, Testabdeckung und Change Failure Rate als Nebenprodukt der Arbeit. Niemand muss sie nachträglich erheben, und niemand kann sie schönen.
2. Die Definition of Operability als viertes Gate. Im Betrieb übernehmen Agenten Monitoring, Anomalie-Erkennung und Self-Healing-Vorschläge; Prüfagenten erstellen SLA-Berichte, Ursachenanalysen und Qualitätstrends; Menschen entscheiden über Eskalation, tragen die Incident-Verantwortung und halten die Lessons Learned fest. Erkenntnisse aus dem Betrieb fließen in Backlog und Spezifikation zurück.
3. Der Reifegrad als wiederkehrende Messung. Skalierung folgt Portfolio-Logik: Jede Domäne wird gegen das Reifegradmodell gemessen und in Wellen ausgerollt, jede Welle liefert die Evidenz für die nächste. Verbindlich wird der Northstar durch Vorstandssponsorship, Budget und genau diese eine Kennzahl in der Unternehmenssteuerung.

In reqCoder, dem vollständigen agentischen Software Development Lifecycle von ReqPOOL, der bei uns intern im Einsatz ist, ist dieses Monitoring eingebaut. Jede der vier Stages hinterlässt Evidenz am Gate: Scope-Nachweis und Schätzung nach dem Prototyp, reqChecker-Prüfung und Security-Scan in der Beta, Signoff-Abnahmebericht und Audit-Trail vor dem Deployment, überwachter Betrieb in der Produktion. Aus derselben Evidenz lesen wir die Kennzahlen ab, mit denen wir unsere eigene Delivery steuern. Wer eine Stage beauftragt, sieht die Messwerte vor der Entscheidung über die nächste.

Was das für Ihre Organisation bedeutet

• Standort messen, bevor Sie Werkzeuge kaufen. Ein Assessment je Domäne in vier bis acht Wochen liefert die Baseline, ohne die kein Lizenzprogramm seinen Effekt nachweisen kann, und verhindert, dass Piloten zu Inseln werden.
• Die Leitkennzahl der Zielstufe früh erheben. Wer L4 anstrebt, sollte die Zykluszeit je Auftrag bereits in den Pilotzellen messen, auch wenn sie anfangs schlecht aussieht.
• Baseline und Leitplanken vor dem Piloten festschreiben. Sonst wird die 90-Tage-Messung zur Interpretationsfrage.
• Eine Kennzahl für den Vorstand, nicht zwanzig. Delivery-Effizienz je Vollzeitkraft mit vier stabilen Leitplanken ist beschlussfähig; ein Dashboard mit vierzig Metriken ist es nicht.
• Aktivitätskennzahlen streichen. Codezeilen, Prompts und Tokens gehören in die Kostenrechnung, nicht in die Steuerung.

Der nächste Schritt

Wie wir das Reifegrad-Assessment, das Kennzahlensystem und die 90-Tage-Messung in Ihrer Delivery-Organisation aufsetzen, lesen Sie auf der Seite Agentic Software Development Lifecycle. Wie die Evidenz an den Gates unserer eigenen agentischen Pipeline entsteht, beschreibt die Seite reqCoder. In einem Expertengespräch bestimmen wir gemeinsam, welche Leitkennzahl Ihre Organisation heute tatsächlich erhebt und was das über Ihren Standort auf dem Reifegradpfad sagt.