Warum das Team Quality Radar kein weiteres Reifegradmodell ist

Vor einigen Tagen habe ich auf LinkedIn einen Beitrag über das Team Quality Radar veröffentlicht. Daraus entwickelte sich eine spannende fachliche Diskussion über die Frage, wie sich das Team Quality Radar von etablierten Reifegradmodellen wie TMMi, TPI Next oder CMMI unterscheidet.

Eine Frage fand ich dabei besonders interessant:

Warum braucht es einen teamorientierten Ansatz, wenn es bereits etablierte Reifegradmodelle gibt?

Je länger ich darüber nachgedacht habe, desto klarer wurde mir: Das Team Quality Radar wurde nie mit dem Ziel entwickelt, ein weiteres organisationsweites Reifegradmodell zu sein. Es verfolgt bewusst einen anderen Ansatz.

Was klassische Reifegradmodelle leisten

Modelle wie TMMi, TPI Next oder CMMI unterstützen Organisationen dabei, ihre Test- und Entwicklungsprozesse weiterzuentwickeln. Sie schaffen gemeinsame Standards, fördern Vergleichbarkeit und helfen dabei, Prozesse messbar und kontinuierlich zu verbessern.

Gerade in größeren Organisationen leisten diese Modelle einen wichtigen Beitrag, wenn es darum geht, Qualitätsarbeit organisationsweit zu gestalten und weiterzuentwickeln.

Eine Beobachtung aus der Praxis

In den vergangenen Jahren durfte ich viele Projektteams begleiten – in unterschiedlichen Unternehmen, Branchen und Organisationsformen.

Dabei ist mir immer wieder eine Beobachtung begegnet:

Viele Unternehmen verfügen bereits über Test Policies, Teststrategien oder andere Qualitätsvorgaben. Diese schaffen wichtige Rahmenbedingungen und geben Orientierung. Die täglichen Entscheidungen über Qualität entstehen jedoch dort, wo Software entwickelt, getestet und ausgeliefert wird – im Projektteam.

Zum Beispiel:

• Haben wir die größten Risiken ausreichend berücksichtigt?
• Testen wir die richtigen Bereiche?
• Können wir dieser Änderung wirklich vertrauen?
• Welche Verbesserung bringt unserem Team aktuell den größten Nutzen?

Diese Fragen beantwortet keine Test Policy. Sie müssen vom Team gemeinsam beantwortet werden.

Genau an dieser Stelle entstand die Idee für das Team Quality Radar.

Das Team Quality Radar schließt die Lücke

Das Team Quality Radar versteht sich nicht als Ersatz für bestehende Strategien oder Reifegradmodelle.

Es ergänzt sie.

Während Unternehmensvorgaben den Rahmen schaffen, unterstützt das Team Quality Radar die Teams dabei, ihre tägliche Qualitätsarbeit gemeinsam zu reflektieren und daraus konkrete Verbesserungen abzuleiten.

Der Fokus liegt deshalb bewusst auf dem Projektteam.

Nicht mit dem Ziel, einen Reifegrad zu bestimmen oder Teams miteinander zu vergleichen, sondern ein gemeinsames Verständnis darüber zu entwickeln,

• wo das Team aktuell steht,
• welche Qualitätsthemen für das Team relevant sind und
• welche Verbesserungen den größten Mehrwert versprechen.

Aus diesen Gesprächen entsteht ein Improvement Backlog, das das Team Schritt für Schritt umsetzen kann.

Was passiert, wenn mehrere Teams das Team Quality Radar nutzen?

Eine spannende Frage aus der LinkedIn-Diskussion war, wie sich die Erkenntnisse mehrerer Teams später auf Organisationsebene nutzen lassen.

Meine Antwort darauf lautet: nicht über identische Bewertungen oder einen vorgegebenen Entwicklungspfad.

Sondern über gemeinsame Erfahrungen.

Stellen wir uns drei Teams vor:

• Team A erkennt, dass eine fehlende Teststrategie die größte Herausforderung ist.
• Team B konzentriert sich auf den Ausbau der Testautomatisierung.
• Team C stellt fest, dass vor allem die Zusammenarbeit zwischen Fachbereich und Entwicklung verbessert werden sollte.

Alle drei Teams arbeiten mit demselben Team Quality Radar – und dennoch entstehen drei unterschiedliche Improvement Backlogs.

Genau darin sehe ich die Stärke des Ansatzes.

Im nächsten Schritt können die Teams ihre Erfahrungen austauschen. Vielleicht hat Team B einen guten Weg gefunden, Testautomatisierung schrittweise einzuführen. Vielleicht hat Team C eine neue Form der gemeinsamen Story-Verfeinerung etabliert. Andere Teams können diese Good Practices übernehmen und an ihren eigenen Kontext anpassen.

Wenn sich dabei wiederkehrende Muster zeigen, können daraus organisationsweite Empfehlungen oder Standards entstehen – nicht weil sie von oben vorgegeben wurden, sondern weil sie sich in mehreren Teams bewährt haben.

Bottom-up und Top-down gehören zusammen

Das war von Anfang an eine bewusste Entwurfsentscheidung.

Das Team Quality Radar soll kein organisationsweites Reifegradmodell sein. Gleichzeitig schließt es organisatorische Verbesserungen nicht aus.

Im Gegenteil: Gute Rahmenbedingungen entstehen häufig dann, wenn Organisationen von den Erfahrungen ihrer Teams lernen. Ebenso profitieren Teams von klaren Leitplanken und gemeinsamen Standards.

Top-down und Bottom-up sind deshalb keine Gegensätze. Sie ergänzen sich.

Mein Fazit

Nach der Diskussion bin ich sogar noch überzeugter von diesem Ansatz.

Aus meiner Sicht beantworten klassische Reifegradmodelle und das Team Quality Radar unterschiedliche Fragestellungen.

Die einen unterstützen Organisationen dabei, ihre Qualitätsarbeit weiterzuentwickeln.

Das Team Quality Radar unterstützt Projektteams dabei, ihre tägliche Qualitätsarbeit gemeinsam zu reflektieren und die nächsten sinnvollen Verbesserungen abzuleiten.

Beides hat seine Berechtigung.

Denn Qualität entsteht nicht allein durch gute Strategien oder Prozesse. Sie entsteht vor allem durch die Entscheidungen, die Teams jeden Tag gemeinsam treffen.