Team-Maturity-Assessment: ein datengetriebenes Framework für Engineering-Exzellenz
Von DevPrism Team
Ihr VP Engineering fragt: „Welche Teams sind reif genug, ihre eigenen Architekturentscheidungen zu verantworten?” Sie zögern. Sie glauben, es zu wissen — aber Ihre Belege sind Flurwissen, ein paar 1:1s und eine Intuition, geprägt von denen, die auf Slack am lautesten sind.
Das ist die Lücke im Reifegrad-Assessment: Organisationen müssen folgenreiche Entscheidungen über Teamautonomie, Recruiting und Investitionen treffen — und treffen sie auf subjektiven Eindrücken statt auf einer systematischen Bewertung.
Warum klassische Reifegradmodelle scheitern
Das klassische CMMI-artige Reifegradmodell (Stufe 1-5) hat drei fatale Schwächen für Engineering-Teams:
1. Sie sind binär und subjektiv
„Macht das Team Code Reviews?” Ja/Nein. Aber in welcher Qualität? Ein Team, das durchwinkt, und eines, das tiefe, lehrreiche Reviews schreibt, antworten beide mit „Ja” — und stehen auf radikal unterschiedlichen Reifegraden.
2. Sie sind Momentaufnahmen
Ein quartalsweises Assessment sagt Ihnen, wo Teams waren. Engineering-Reife ist eine Trajektorie. Sie brauchen Richtung und Veränderungsgeschwindigkeit, nicht nur die aktuelle Position.
3. Sie schreiben keine Handlung vor
Zu wissen, dass man auf „Stufe 2” steht, sagt nicht, was zu tun ist. Teams brauchen konkrete, priorisierte Maßnahmen mit erwarteter Wirkung — keine abstrakten Stufenbeschreibungen.
Die fünf Dimensionen
Ein datengetriebenes Modell erfindet seine Dimensionen nicht: Es nimmt die, für die bereits belastbare Daten vorliegen. Jede wird von 0 bis 5 bewertet und bekommt ihr eigenes Stufenvokabular.
KI-Adoption
Wer nutzt die KI-Assistenten tatsächlich, und wie intensiv?
Liest die Nutzungsdaten Ihrer Assistenten (Copilot, Cursor, Claude Code, Codex und andere): aktive gegen gekaufte Seats, Akzeptanzrate, Regelmäßigkeit über die Zeit.
Stufen: Minimal · Early · Growing.
DORA
Wie schnell und wie stabil liefert das Team?
Liest die Delivery-Metriken, berechnet aus GitHub, GitLab und Azure DevOps.
Stufen: Low · Medium · High · Elite — die übliche DORA-Klassifikation.
PR-Prozess
Fließt die Arbeit, oder wartet sie?
Liest die Pull Requests des Zeitraums: die zu lange offenen, die ohne Reviewer, die Konzentration der Review-Last. Die Dimension meldet, wie viele PRs analysiert und wie viele Auffälligkeiten gefunden wurden.
Stufen: Critical · Strained · Needs Improvement · Acceptable · Balanced · Healthy.
Qualität
Ist der ausgelieferte Code gesund?
Liest Ihre SonarQube- oder Codacy-Analysen: offene Schwachstellen, Duplikation, technische Schuld, Ergebnis der Quality Gates.
Stufen: Poor · Fair · Good · Excellent.
Kapazität
Hält das Team das Tempo durch?
Liest die Lastverteilung über die Beitragenden und macht Überlastung, Abhängigkeit von einer einzelnen Person oder ein nicht tragfähiges Tempo sichtbar.
Stufen: Critical · Strained · Needs Improvement · Acceptable · Balanced · Healthy.
Der Gesamtscore
Der Team-Reifegrad ist der gewichtete Durchschnitt der fünf Dimensionen auf einer Skala von 0 bis 5. Er kommt immer mit einer Executive Summary, die erklärt, was die Zahl abdeckt — denn ein Score allein sagt nicht, was zu tun ist.
| Score | Stufe | Deutung |
|---|---|---|
| 0 – 1 | Beginner | Erhebliche Lücken über die meisten Dimensionen. Braucht Struktur. |
| 1 – 2 | Developing | Die Grundlagen entstehen. Konsistenz ist noch nicht da. |
| 2 – 3 | Proficient | Das Team hält seine Lieferung, mit ein bis zwei abfallenden Dimensionen. |
| 3 – 4 | Advanced | Solides, verlässliches Team. Kann mehr Entscheidungen tragen. |
| 4 – 5 | Expert | Interne Referenz. Kann eigene Architekturentscheidungen verantworten. |
Ein 2,2 „Proficient” mit einer Dimension bei 1,5 ist nicht dasselbe Team wie ein gleichmäßiges 2,2: Das erste hat ein benanntes, adressierbares Problem, das zweite ein grundlegendes. Deshalb zählen die fünf Einzelwerte mehr als ihr Durchschnitt.
Der 30-60-90-Tage-Verbesserungsplan
Ein Assessment ist nur so viel wert wie die Maßnahmen, die es auslöst. Der Bericht endet mit Quick Wins, die an eine konkrete Dimension gebunden sind, und danach mit einem Plan über drei Horizonte.
Tage 1-30: Quick Wins
Ziel: die niedrigste Dimension mit den schnellsten Korrekturen.
Beispiel: Das Team liegt bei 1,5 im PR-Prozess — PRs seit 48 Tagen offen, fehlende Reviewer.
- Code Owners je Repository-Bereich festlegen (Tag 1)
- Ein Review-SLA von 24 h setzen und veröffentlichen (Tag 3)
- Automatische Reviewer-Zuweisung aktivieren (Tag 5)
Erwartete Wirkung: PR-Prozess 1,5 → 2,5 in 30 Tagen.
Tage 31-60: fundamentale Verbesserungen
Ziel: Systeme bauen, die sich über die Zeit summieren.
Beispiel: Das Team liegt bei 3,0 in Qualität, aber das Quality Gate scheitert an der Duplikation.
- Quality Gate blockierend in der CI konfigurieren (Woche 5)
- Duplikationsschwelle für neuen Code setzen (Woche 6)
- Offene Schwachstellen nach Schweregrad abarbeiten (Woche 7)
Erwartete Wirkung: Qualität 3,0 → 3,8 in 60 Tagen.
Tage 61-90: strukturelle Änderungen
Ziel: das, was sich nicht in einer Iteration beheben lässt.
Beispiel: Das Team liegt bei 1,5 in Kapazität — drei Beitragende, alle überlastet.
- Gleichzeitige Arbeit in Bearbeitung reduzieren (Woche 9)
- Wissensbereiche über Pair Programming verteilen (Woche 10)
- Den nächsten Quartalsumfang an der realen Kapazität bemessen (Woche 12)
Erwartete Wirkung: Kapazität 1,5 → 2,5 in 90 Tagen.
Fortschritt über die Zeit verfolgen
Die Stärke des datengetriebenen Assessments ist die Trendanalyse. Wenn Sie es jedes Quartal erneut ausführen:
Quartal KI DORA PR Qualität Kapazität Gesamt
Q1 2026 2.0 3.0 1.5 3.0 1.5 2.2
Q2 2026 2.5 3.0 2.5 3.5 2.0 2.7
Q3 2026 3.0 3.5 3.0 3.5 2.5 3.1
Diese Trajektorie erzählt eine Geschichte: Das Team hat seinen Plan umgesetzt, in zwei Quartalen 0,9 Punkte gewonnen und die Schwelle „Advanced” überschritten. Kapazität bleibt der Tiefpunkt — dort entscheidet sich das nächste Quartal.
Warnsignale und Interventionsauslöser
Manche Profile signalisieren Risiko lange bevor sich der Durchschnitt bewegt:
Die Geschwindigkeitsfalle
- DORA: 4,0 · Qualität: 2,0
Das Team liefert schnell und häuft Schulden an. Intervention: Features pausieren, in Qualitätsinfrastruktur investieren.
Der Review-Engpass
- DORA: 3,5 · PR-Prozess: 1,5
Die Lieferung hält, aber nur weil wenige Personen die gesamte Review-Last tragen. Intervention: Reviewer-Pool verbreitern, SLA setzen, Zuweisung automatisieren.
Kapazität unter Spannung
- Kapazität: 1,5 bei drei Beitragenden
Ein Abgang oder ein Krankheitsfall, und das Team kippt. Intervention: WIP senken, Wissensbereiche verteilen, Umfang zurechtschneiden.
KI bezahlt, aber ungenutzt
- KI-Adoption: 1,0 · Seats für das ganze Team gekauft
Das Budget fließt ab, der Nutzen nicht zu. Intervention: gezielte Befähigung, oder Seats an die Teams umverteilen, die etwas davon haben.
Die Organisationssicht
Team-Reifegrade zu einer Organisationskarte aggregieren:
| Team | Gesamt | Niedrigste Dimension | Priorisierte Maßnahme |
|---|---|---|---|
| Platform | 3.8 | Kapazität (2.5) | WIP senken |
| Payments | 4.2 | KI-Adoption (3.0) | Bereits exzellent — halten |
| Growth | 2.1 | Qualität (1.5) | Zuerst Quality Gates |
| Mobile | 2.8 | PR-Prozess (2.0) | Review-Praktiken |
Das gibt der Führung eine einseitige Sicht darauf, wo zu investieren ist: welche Teams Unterstützung brauchen, welche mehr Verantwortung übernehmen können und wo die systemischen Risiken liegen.
Wie DevPrism dieses Assessment erzeugt
Das Assessment wird auf Anforderung aus der Plattform gestartet. Ein mehrstufiger Workflow holt die Teamdaten, analysiert die fünf Dimensionen parallel und synthetisiert dann:
- Einen Score je Dimension, von 5, mit seiner Stufe — KI-Adoption, DORA, PR-Prozess, Qualität, Kapazität
- Einen gewichteten Gesamtscore, mit seiner Stufe von Beginner bis Expert
- Eine Executive Summary, die den Score in klarer Sprache erklärt und die Engpässe benennt
- Quick Wins, jeweils an eine Dimension und eine erwartete Wirkung gebunden
- Einen 30-60-90-Plan, abgeleitet aus den niedrigsten Dimensionen
- Eine Benachrichtigung an den Tech Lead, sobald das Assessment fertig ist
Keine Tabellen. Keine subjektiven Bewertungen. Kein Jahresreview, das veraltet ist, bevor es fertig ist.
Ersetzen Sie Bauchgefühl durch datengetriebenes Team-Assessment. Testen Sie DevPrism kostenlos — Team Maturity Assessment ab dem Pro-Plan inklusive.