Wie man sich auf Ship/No-Ship-Entscheidungen vorbereitet – und sie übersteht

Darum geht es in diesem Artikel. Er hat nichts Neues oder „Umwälzendes“ zu bieten, sondern sehr praxisnahe Reflexionen und Ratschläge, basierend auf meinen eigenen, nervenaufreibenden Erfahrungen als QA-Leiter über mehrere Jahrzehnte hinweg – und den Lehren, die ich daraus gezogen habe. Quasi meine persönliche QA-Executive-Realness. Lehren, die Sie natürlich ignorieren, widersprechen oder belächeln dürfen – ganz wie Sie wollen.

Für jeden, der schon einmal eine Führungsrolle im QA-Bereich hatte, ist sofort klar: Das zentrale Trauma dieser Position ist die berüchtigte „Ship-or-no-ship“-Besprechung. Und das Überleben dieser. 

Hier kommt alles an einen kritischen Punkt, und QA wird wie ein Mordverdächtiger gegrillt, während die Ermittler alle anderen „Stakeholder“ sind (ein Euphemismus, wie er im Buche steht). Und wie alle Ermittler wollen sie von Ihnen eigentlich nur eines: Dass Sie ein Geständnis unterschreiben.

Aber so muss es nicht laufen. Alles, was Sie brauchen, ist ein wasserdichtes Alibi. Und genau das möchte ich Ihnen mit diesem Artikel an die Hand geben.

Geschichtenzeit

Der größte Fehler, den QA-Leiter:innen bei der Vorbereitung auf ein Ship-or-no-ship-Meeting machen, ist mangelnde Vorbereitung. Genauer gesagt: fehlende effektive Vorbereitung. 

Die meisten QA-Leads oder Manager kommen „vorbereitet“ in diese Runde – primär, und oft ausschließlich, mit Bug-Metriken. Die Anzahl der offenen Issues, die Anzahl der offenen Kategorie-A-Issues, die Anzahl der offenen Kategorie-B-Issues, blabla. Manchmal, wenn das Team Glück hat, kann die QA-Leitung sogar eine vage, impressionistische Einschätzung dazu geben, wie hoch die Testabdeckung zu diesem Zeitpunkt ist. Meistens basiert diese Einschätzung aber nur auf einer Auflistung der durchgeführten Tests und Testskripte. Das ist jedoch keinesfalls ein Maß für die tatsächliche Testabdeckung. Das sind Aufwandsmetriken, keine echten Qualitätsmetriken.

Der Trugschluss hinter dieser Strategie geht weit über die Verwendung von mehrdeutigen oder bedeutungslosen Kennzahlen hinaus, um damit (irgendein?) Argument fürs Shippen oder Nichtshippen zu liefern. Der eigentliche Fehler liegt viel tiefer.

Denn die oben beschriebene QA-Entscheidungsstrategie basiert auf einer klaren Kategorienverwechslung. Die Führungskräfte im QA nehmen in diesem Szenario an, dass der Zweck des Ship-or-no-ship-Meetings darin besteht, Daten zu präsentieren, die andere aufnehmen und dann auf deren Grundlage selbst eine Entscheidung treffen. Das könnte falscher nicht sein – und ist für die Autorität des QA sogar hochgradig schädlich.

Der Rest des Produktteams erwartet von der QA-Führung in diesem Meeting nicht noch mehr Daten. Erwartet wird ein klares und autoritatives Urteil darüber, ob das Produkt ausgeliefert wird oder nicht. Jetzt. Heute. 

Natürlich sind Test- und Fehlerdaten notwendig, um das QA-Expert:innenurteil zu verteidigen und Akzeptanz dafür zu schaffen. Aber es ist das autoritative Urteil, das QA liefern muss. 

Andernfalls gibt QA seine einzigartige Verantwortung und Autorität innerhalb der Auslieferungsorganisation auf. Das ist ein zutiefst vermeidendes und passiv-aggressives Verhalten, das der Reputation von QA nicht gerade zuträglich ist. 

Mit der Zeit bedeutet das einen Todesstoß für QAs Chancen, eine gleichberechtigte Stimme im Entwicklungsprozess zu werden. Eine Situation, über die sich QA zwar konstant beschwert, die oftmals aber das Ergebnis eigenen Handelns ist.

Das heißt: QA-Führung muss in das Ship-or-no-ship-Meeting gehen mit einer klaren und überzeugenden Geschichte, die zu einer eindeutigen Empfehlung führt. Mit anderen Worten: Sie müssen bereit und gewillt sein, im übertragenen Sinne mit ihrem eigenen (digitalen) Blut für diese Empfehlung zu unterschreiben. Keine Wackelkandidaten. Kein Verstecken hinter der Ausrede der "plausiblen Leugnung". 

Wenn Sie das nicht tun, werden Sie und Ihr Team jegliche Glaubwürdigkeit im Unternehmen verlieren. Und schlimmer noch: Sie liefern sich aus, im Nachhinein die gesamte Schuld zugetragen zu bekommen, wenn andere die Entscheidung für Sie treffen und das Ergebnis ein Qualitätsdesaster auf dem Markt ist. Was, ehrlich gesagt, exakt das ist, was sich die anderen Bereiche wünschen. Sie wollen Ihnen die Schuld geben und Ihr eigenes Zaudern in puncto Produktqualität als Beweis gegen Sie verwenden.

Ein entscheidender Wegbereiter für diesen passiv-aggressiven Ansatz bei der Ship-or-no-ship-Entscheidung ist die Überzeugung – häufig opportunistisch vorgetragen –  dass „es egal ist, was ich sage, am Ende wird sowieso ausgeliefert“. Diese Denkweise, diese strategische Annahme der eigenen Machtlosigkeit, sorgt genau dafür, dass QA im Unternehmen machtlos bleibt. Selbsterfüllende Prophezeiung lässt grüßen! 

Abgesehen von Politik und selbstschädigender Psychologie basiert diese Strategie auf einem grundlegenden Missverständnis dessen, was QA in diesem Meeting eigentlich leisten soll. Denn verlangt wird dort keineswegs ein unumstößliches Ship-or-no-ship-Urteil, auch wenn die öffentliche Entscheidung genau so aussieht. 

Und ja – Sie müssen trotzdem ein autoritatives Urteil abgeben. Aber dafür müssen Sie auch verstehen, welche Frage Sie wirklich autoritativ beantworten müssen.

Die eigentliche Frage, die an die QA-Führung gestellt wird, lautet: Wie hoch sind die Risiken – ihre wahrscheinliche Häufigkeit und Schwere im Feld – wenn wir heute ausliefern? Im Vergleich dazu, wenn wir zum Beispiel erst nächsten Monat ausliefern? Anders ausgedrückt: Sie werden gebeten, eine Risikobewertung vorzunehmen, um der Geschäftsleitung eine rationale Risikoeinschätzung zum jeweiligen Zeitpunkt zu ermöglichen. 

Das bedeutet, dass Ihre endgültige Antwort im "Ship-no Ship"-Meeting letztlich eine endgültige Antwort zum Risiko ist. Es geht nicht darum, ob Sie den Knopf drücken, der die Rakete ins All startet.

Das wiederum bedeutet, dass die Qualitätserläuterung, die Sie in diesem Meeting vortragen, grundsätzlich szenarienbasiert sein muss. Das heißt, es wird keine einfache Ja- oder Nein-Antwort geben, ganz gleich, wie sehr alle anderen das auch wollen, um jegliche Verantwortung für die Entscheidung von sich zu weisen (was ja niemals vorkommt, richtig?). Um das ein wenig zu schematisieren, sollte Ihre Präsentation aus zwei Teilen bestehen:

• Zunächst eine maßgebliche, *wirklich* datenbasierte Darstellung des aktuellen Stands der Produktqualität. Mit Metriken als Nachweis. Kleiner Spoiler: Dafür reichen Bug-Metriken allein nicht aus.
• Danach eine fundierte Einschätzung, welche „verdeckte“ Qualität liegen bleibt, falls jetzt ausgeliefert wird. Ist sie so bedeutend, dass es sich lohnt, den Release-Zeitplan zu verlängern, um diese Qualitätslücke zu schließen? Wenn ja, welche Zeit-Qualitäts-Abwägungen empfiehlt das QA? Und welche konkreten Bereiche der Produktfunktionalität müssten in dieser Phase gezielt angegangen werden, und wie könnte festgestellt werden, dass die verdeckte Qualität auch tatsächlich realisiert wurde?

Das ist keineswegs eine Ausflucht vor der gestellten Frage. Es ist eine Antwort im vollständigen Kontext aller Parameter, Variablen und Kosten, die mit dieser Entscheidung – ob heute, nächste Woche oder nächsten Monat – verbunden sind. 

Und das müssen Sie sich ganz tief in Ihr QA-Bewusstsein eingravieren: Ihre eigentliche Zielgruppe im Meeting sind nicht die anderen Fachbereichsleiter. Es ist das Top-Management. Ganz gleich, ob sie physisch anwesend sind oder nicht. Was Sie sagen, wird umgehend an sie weitergeleitet. Verlassen Sie sich darauf.

Und das spielt Ihnen sogar in die Karten. Denn was CEOs und COOs noch mehr schätzen als alles andere, sind sinnvolle Optionen, die durch konkrete Fakten und Daten untermauert sind. Was sie dagegen hassen, ist, wenn ihnen lediglich gesagt wird: „Äh, wir sind nicht bereit für ein Release. Und wir können nicht genau sagen, warum. Vielleicht wissen wir es in vier Monaten.“ Genau das ist der Grund, warum CEOs nach neuen Übernahmen suchen – um ein ganz neues Produkt-Team zu bekommen. 

Das Dauerproblem aus Sicht des Produkt-Teams ist, dass das Top-Management per Dekret einen festen Releasetermin festlegt, auf den es keinen Kompromiss gibt. Sie sollten sich einmal fragen, warum das so häufig passiert. 

Weil sie nie eine verbindliche Auskunft zum Status der Produktqualität bekommen – und falls ihr bevorzugtes Release-Datum nicht gehalten werden kann, auch kein alternatives Datum, an dem ausgeliefert werden kann. Also legen sie selbst Termine fest. Denn das Produkt-Team lässt ihnen keine fundierte Auswahl.

Deshalb müssen Sie zum Ship-no Ship-Meeting mit einer überzeugenden, dreidimensionalen, fakten- und szenarienbasierten Darstellung erscheinen, die in eine maßgebliche Empfehlung mündet – inklusive aussagekräftiger Qualitäts-Kosten-Nutzen-Alternativen für die Entscheidung, ob ausgeliefert wird oder nicht. Ein paar Minuten über Bug-Metriken zu murmeln und die Entscheidung dann anderen zu überlassen, ist nicht der richtige Weg.

Dafür müssen natürlich Ihre eigene QA-Methodik, Ihre Ausbildung und Ihre Kennzahlen erstklassig sein. An anderer Stelle (z.B. auf LI) habe ich detaillierte Artikel zu diesen Themen veröffentlicht, aber da sie überwiegend prozesstheoretisch sind, sprengen sie den pragmatischen Rahmen dieses Artikels.

Ein Happy End

Was ich oben beschrieben habe, mag auf den ersten Blick abschreckend und vielleicht sogar ein wenig widersprüchlich wirken. Deshalb möchte ich diesen Artikel mit einem Erlebnis aus einem ausgesprochen erfolgreichen Ship-no Ship-Meeting abschließen – eines, das etwas anders verlief, als ich es oben beschrieben habe, und auch anders, als ich es erwartet hätte.

Mein Team testete damals ein brandneues Produkt. Nicht nur ein neues Produkt, sondern auch eines für ein Marktsegment, in dem das Unternehmen keinerlei Erfahrungen hatte. Vom Start weg also ein Marathon aus unbekannten Gefahren, unbekannten Unbekannten und unangenehmen Überraschungen.

Irgendwann war das Ship-no Ship-Meeting angesetzt. Zu Beginn meiner Zeit als QA-Direktor hatte ich ein strenges Regelwerk eingeführt, wie Qualitätskennzahlen zu definieren sind – darunter Metriken für die Testabdeckung, und zwar anforderungsbasiert, nicht je nach Modul oder Testskript. Zusätzlich zu Bug-Metriken hatten wir auch Trends zu Fehlern und eine Metrik zur Änderungs-Geschwindigkeit im Code, um unsere Argumentation zu untermauern. 

Und all diese Kennzahlen waren unbestreitbar positiv. Alles war auf Grün. Es waren keine Wenn/Dann-/Sonst-Szenarien notwendig. Zum ersten Mal sah ich keinen Grund, nicht klar und deutlich zu sagen: „Ausliefern!“, und zwar ohne Einschränkungen. 

Trotzdem war das streng genommen nicht meine Aufgabe. Denn das Projekt war von einem meiner QA-Manager geleitet worden. Es war also seine Aufgabe, dieses Urteil abzugeben. Der Manager fasste korrekt alle Kennzahlen zusammen und bestätigte, dass sie durchweg positiv waren. 

Dann aber, zu meiner Überraschung, zauderte und haderte er damit, ob tatsächlich ausgeliefert werden konnte. Überraschend, da wir die QA-Position im Vorfeld ja eigens besprochen hatten. (Wichtiger Hinweis: Überraschen Sie nie Ihren Vorgesetzten in einem Meeting. Nie.)

Ich fragte den Manager: „Was müsste passieren, damit Sie sich wohl fühlen, eine Empfehlung zur Auslieferung zu vertreten? Falls nicht heute – was müsste sich andern, damit das künftig geht?“

Zu meiner Überraschung konnte – oder wollte – der Manager meine Frage nicht beantworten. Mir wurde klar, dass dieser Manager einfach keine Verantwortung für diese Entscheidung übernehmen wollte, nicht unterschreiben wollte. Das fand ich mehr als enttäuschend. 

Es war auch eine Beleidigung gegenüber dem Entwicklungsleiter des Projekts, der die QA-Bemühungen endlos unterstützt und ein erstklassiges Produkt entwickelt hatte. Er hatte es nicht verdient, so überrumpelt zu werden. Ich übrigens auch nicht.

Also schritt ich ein und sagte: „Ich habe keinen guten Grund gesehen oder gehört, dieses Produkt HEUTE nicht auszuliefern. Das ist das Urteil der QA, und ich, als QA-Direktor, übernehme die volle Verantwortung für diese Entscheidung.“

Ich dachte, der Entwicklungsleiter würde mich gleich umarmen. Doch nach diesem Meeting erhielt QA enormen Respekt und Anerkennung von Entwicklung, Projektmanagement und Produktmanagement. 

Denn der Weg, in unserer Welt ernst genommen zu werden, ist, öffentlich Verantwortung zu übernehmen. Was ich in diesem Moment völlig bedenkenlos tat, da unsere Geschichte von Anfang an auf dieses Ziel vorbereitet war. Und weil sie mit einem Happy End geschrieben wurde.

Das Produkt zeigte nach der Veröffentlichung in der Praxis eine hervorragende Qualität und wurde ein großer Erfolg. Die Veröffentlichung zu verzögern, nur um die Verantwortung für eine Ship/No-Ship-Entscheidung zu scheuen, hätte lediglich zu einer minimalen Qualitätssteigerung des Produkts geführt – zu unverhältnismäßig hohen Kosten in Bezug auf Geld und Time-to-Market. 

Wie wir das geschafft haben, ist eine Geschichte für einen anderen Tag.

Wie immer: Viel Erfolg bei euren QA-Projekten.

Verwandter Podcast: TEAMARBEIT, KI UND KONTAINERISIERUNG (MIT NASA’S MICHAEL RITCHSON)