Mandats-Beispiel: Qualität und Release-Stabilität

Mehrere Teams arbeiteten parallel an einem komplexen digitalen Produkt. Releases waren geplant, abgestimmt und kommuniziert, aber in der Praxis dann selten verlässlich umgesetzt.

• Kurz vor jedem Release wurden Prioritäten geändert.
• Bugs tauchten spät auf.
• Bestehende Funktionalität wurde durch neue Features instabil.

Zusagen gegenüber Fachbereichen oder Kunden wurden zunehmend vorsichtig formuliert oder wurden ganz vermieden.
Das Vertrauen in die eigene Release-Fähigkeit nahm spürbar ab.

Die Teams waren erfahren und engagiert. Trotzdem entstand das Gefühl, dass Qualität eher gehofft als gesteuert wurde.

Die Projekt- und Bereichsleitung stand zwischen widersprüchlichen Erwartungen.

Einerseits bestand der Anspruch, regelmäßig neue Funktionen zu liefern. Andererseits war klar: jedes zusätzliche Feature erhöhte das Risiko, bestehende Stabilität weiter zu untergraben.

Die Verantwortung für Qualität wanderte nach oben. Entscheidungen wurden spät oder gar nicht getroffen. Operativer Druck konzentrierte sich auf wenige Personen.

Unser Fokus lag nicht auf neuen Tools oder Prozessen, sondern auf Klarheit und Verantwortung.

Gemeinsam wurde geklärt:

• Was bedeutet „Qualität“ in diesem Kontext konkret?
• Welche Kriterien müssen vor einem Release erfüllt sein?
• Wer entscheidet verbindlich über Release-Fähigkeit?

Qualitätskriterien wurden explizit gemacht.
Der Release-Prozess wurde strukturiert.
Abhängigkeiten und Risiken wurden transparent gemacht.

Nicht als zusätzliche Bürokratie, sondern als Grundlage für verlässliche Entscheidungen.

Releases wurden wieder planbar.
Qualitätsrisiken waren früh sichtbar und adressierbar.

Die Projektleitung konnte Zusagen wieder verantwortungsvoll und belastbar treffen.
Teams arbeiteten fokussierter.
Die operative Anspannung nahm deutlich ab.

Nicht, weil weniger gearbeitet wurde – sondern weil Klarheit und Verantwortung wieder griffen.