Hoe je je voorbereidt op en beslissingen over uitbrengen of niet uitbrengen overleeft

Daar gaat dit artikel dus over. Het biedt niets nieuws of “baanbrekends”, alleen zeer praktische reflecties en adviezen op basis van mijn eigen nagelbijtende ervaringen als QA-leider gedurende meerdere decennia, en de lessen die ik daaruit heb getrokken. Mijn eigen QA-directierealiteit, zogezegd. Lessen die je natuurlijk vrij bent om te negeren/tegenspreken/bespotten, al naargelang je goeddunkt.

Het is duidelijk voor iedereen die enige tijd QA-leiding heeft gegeven dat het centrale trauma van die ervaring bestaat uit het onderhandelen over de beruchte vergadering “wel of niet uitbrengen”. En het overleven ervan. 

Want hier komt alles samen, wordt QA verhoord als een moordverdachte en zijn alle andere “belanghebbenden” de rechercheurs (een eufemisme als er ooit een was). En, zoals alle rechercheurs, willen ze maar één ding van je: dat je de bekentenis ondertekent.

Maar zo hoeft het niet te zijn. Het enige wat je nodig hebt, is een waterdicht alibi. Ik schrijf dit artikel om je dat te geven.

Tijd voor een verhaal

De grootste fout die QA-leiders maken wanneer ze een vergadering over wel of niet uitbrengen ingaan, is een gebrek aan voorbereiding. Of beter gezegd: een gebrek aan effectieve voorbereiding. 

De meeste QA-leiders of -managers gaan deze vergadering “voorbereid” in, voornamelijk en vaak uitsluitend met defectmetingen. Een aantal openstaande problemen, het aantal openstaande problemen van categorie A, het aantal openstaande problemen van categorie B, enzovoort. Soms zal de QA-leider, als de rest van het team geluk heeft, een vaag, impressionistisch beeld kunnen geven van de testdekking die QA tot dat moment heeft bereikt. Hoewel de gegevens die ze hiervoor gebruiken doorgaans simpelweg bestaan uit een inventaris van tests en testscripts die ze hebben uitgevoerd. Dat is helemaal geen meting van de werkelijke testdekking. Dit zijn inspanningsmetingen, geen echte kwaliteitsmetingen.

De denkfout achter deze strategie gaat verder dan het gebruik van dubbelzinnige of betekenisloze metingen om een (soort van?) argument voor wel of niet uitbrengen te maken. De fout die hier wordt gemaakt, is veel fundamenteler.

De reden is dat de hierboven beschreven QA-besluitvormingsstrategie gebaseerd is op een duidelijke categoriefout. De QA-leiding gaat er in dit scenario van uit dat het doel van de vergadering over wel of niet uitbrengen is om gegevens te presenteren die anderen kunnen verwerken en op basis waarvan ze zelf een beslissing kunnen nemen. Niets is minder waar, of schadelijker voor het gezag van QA.

Wat de rest van het productteam tijdens deze vergadering van de QA-leiding verwacht, is niet nóg meer gegevens. Ze verwachten een duidelijk en gezaghebbend oordeel over de vraag of het product wel of niet moet worden uitgebracht. Nu. Vandaag. 

Natuurlijk zijn test- en defectgegevens nodig om het deskundige oordeel van QA, wat dat ook moge zijn, te onderbouwen en draagvlak ervoor te creëren. Maar QA moet een gezaghebbend oordeel geven. 

Anders doet QA afstand van zijn unieke verantwoordelijkheid voor en gezag binnen de organisatie die verantwoordelijk is voor productoplevering. Het is inherent ontwijkend en passief-agressief. Dat draagt er niets aan bij om de positie van QA binnen diezelfde organisatie te versterken. 

Op termijn is het een neerwaartse spiraal voor de kansen van QA om een gelijkwaardige stem binnen het ontwikkelproces te worden. Een situatie waar QA eindeloos over klaagt, terwijl QA om precies deze reden vaak zelf verantwoordelijk is voor zijn eigen irrelevantie.

Dit betekent dat de QA-leiding de vergadering over wel of niet uitbrengen moet ingaan met een duidelijk en overtuigend verhaal dat leidt tot een ondubbelzinnige aanbeveling. Met andere woorden: je moet die vergadering ingaan met de bereidheid en de intentie om met digitaal bloed op de stippellijn te tekenen voor welke aanbeveling je ook doet. Geen indekken. Geen verschuilen achter de rokken van aannemelijke ontkenbaarheid. 

Want als je dat niet doet, verliezen jij en je team alle geloofwaardigheid binnen de organisatie. En, wat erger is, stellen jullie jezelf bloot aan alle schuld als anderen die beslissing voor jullie moeten nemen en het resultaat een kwaliteitsramp in het veld is. En laten we eerlijk zijn: dat is precies wat de andere functies willen. Ze willen jou de schuld geven van alles en jouw eigen getwijfel over de productkwaliteit als bewijs tegen je gebruiken.

Een belangrijke factor die deze passief-agressieve benadering van de beslissing over wel of niet uitbrengen mogelijk maakt, is de overtuiging — vaak opportunistisch ingezet —  dat “Het niet uitmaakt wat ik zeg, ze gaan toch wel uitbrengen”. Deze mentaliteit, deze strategische keuze voor machteloosheid, is precies wat de organisatorische machteloosheid van QA in stand houdt. Dat is nog eens een zichzelf waarmakende voorspelling! 

Afgezien van politiek en zelfondermijnende psychologie is deze strategie gebaseerd op een fundamenteel misverstand over wat QA tijdens die vergadering moet leveren. Er wordt namelijk niet gevraagd om een onherroepelijke beslissing over wel of niet uitbrengen, ook al neemt de beslissing die je publiekelijk moet maken die openbare vorm aan. 

En ja, je moet nog steeds een gezaghebbend oordeel presenteren. Maar om dat te doen, moet je de vraag begrijpen die je daadwerkelijk gezaghebbend moet beantwoorden.

De vraag die aan QA-leiders werkelijk wordt gesteld, is deze: Wat zijn de risico’s — hun waarschijnlijke voorkomen en ernst in het veld — van vandaag leveren? In plaats van bijvoorbeeld volgende maand? Met andere woorden, er wordt van u gevraagd een risicobeoordeling te geven om rationeel risiconemen door het hogere management op dat moment mogelijk te maken. 

Dit betekent dat uw definitieve antwoord tijdens de vergadering over wel of niet leveren uiteindelijk een definitief antwoord over risico is. Niet over de vraag of u wel of niet op de knop moet drukken waarmee de raket de ruimte in wordt gelanceerd.

Wat op zijn beurt betekent dat het kwaliteitsverhaal dat u tijdens die vergadering vertelt uiteindelijk op scenario’s gebaseerd moet zijn. Dat wil zeggen dat het geen simpel ja of nee zal zijn, hoe graag alle anderen dat ook willen om hun handen in onschuld te kunnen wassen wat betreft de verantwoordelijkheid voor de beslissing (wat nooit het geval is, toch?). Om het enigszins schematisch weer te geven, moet uw presentatie uit twee delen bestaan:

• Ten eerste een gezaghebbende, betekenisvolle datagestuurde verklaring van de huidige productkwaliteit. Met statistieken om die te onderbouwen. Spoiler: u hebt meer nodig dan alleen bugstatistieken om dit te doen.
• Ten tweede een gezaghebbende beoordeling van de latente kwaliteit die onbenut blijft als de beslissing wordt genomen om het product nu te leveren. Is die kwaliteit zo waardevol dat het de moeite waard is om tijd aan het releaseschema toe te voegen om die kwaliteitsschuld in te lossen? Zo ja, welke afwegingen tussen tijd en kwaliteit beveelt QA aan? En op welke specifieke gebieden van de functionaliteit van het product moet tijdens deze verlenging worden gericht, en hoe zouden we weten dat de latente kwaliteit is gerealiseerd?

Dit is in feite geen manier om de gestelde vraag te ontwijken. Het is een manier om haar te beantwoorden in de volledige context van alle parameters, variabelen en kosten die met die beslissing samenhangen — vandaag, volgende week of volgende maand. 

Want — en dit is een waarheid die u in uw QA-bewustzijn moet branden — uw echte publiek tijdens die vergadering bestaat niet uit de andere functionele leidinggevenden. Het is het hogere management. Of zij nu fysiek bij de vergadering aanwezig zijn of niet. Wat u zegt, zal hun met grote spoed worden overgebracht. Vertrouw me hierin.

En dit werkt alleen maar in uw voordeel. Want wat CEO’s en COO’s meer dan wat ook waarderen, is dat ze betekenisvolle opties krijgen voorgelegd, onderbouwd met concrete feiten en gegevens. Wat ze meer dan wat ook haten, is dat hun simpelweg wordt gezegd: “Eh, we zijn nog niet klaar om te leveren. En we kunnen u niet precies vertellen waarom. Maar misschien kunnen we dat over vier maanden.” Daarom gaan CEO’s op zoek naar nieuwe overnames — om een compleet nieuw productleveringsteam binnen te halen. 

De terugkerende klacht van productleveringsteams is dat het hogere management bij decreet een harde releasedatum oplegt, waar het niet van wil afwijken. U zou uzelf kunnen afvragen waarom ze dit zo consequent doen. 

Dat komt doordat ze nooit een definitief antwoord krijgen op de vraag wat de toestand van de productkwaliteit is en, als hun gewenste leverdatum niet kan worden gehaald, op welke datum dat wel kan. Daarom leggen ze hun eigen datum op. Omdat het productteam hun geen betekenisvolle alternatieven heeft geboden.

U moet dus naar de vergadering over wel of niet leveren gaan met een overtuigend, driedimensionaal, feitelijk en op scenario’s gebaseerd verhaal, dat leidt tot een gezaghebbende reeks aanbevelingen. Die aanbevelingen kunnen zelf betekenisvolle opties rond kosten en baten van kwaliteit bevatten voor de beslissing om wel of niet te leveren. Een paar minuten mompelen over bugstatistieken en de beslissing vervolgens aan alle anderen overlaten, is niet dat verhaal.

Natuurlijk zult u hiervoor uw eigen QA-methodologie, training en statistieken tot in de puntjes op orde moeten hebben. Ik heb elders gedetailleerde artikelen over deze onderwerpen geschreven (namelijk op LI), maar omdat ze procestheoretisch van aard zijn, vallen ze buiten de pragmatische focus van dit artikel.

Een gelukkig einde

Wat ik hierboven heb geschreven, lijkt misschien ontmoedigend en op het eerste gezicht wellicht enigszins tegenstrijdig. Daarom wil ik dit artikel afsluiten met mijn ervaring met een zeer succesvolle vergadering over wel of niet leveren. Een vergadering die enigszins anders verliep dan ik hierboven beschrijf, en zelfs anders dan ik had verwacht.

Mijn team had een volledig nieuw product getest. Niet alleen een nieuw product, maar een product dat zich richtte op een niche waarin het bedrijf nog geen eerdere ervaring had. Het was vanaf het begin dus een marathon van verborgen gevaren, onbekende onbekenden en onaangename verrassingen.

Het moment voor de vergadering over wel of niet leveren brak aan. Aan het begin van mijn ambtstermijn als QA-directeur had ik een strikt regime ingevoerd voor de manier waarop we kwaliteitsstatistieken zouden definiëren, inclusief statistieken voor testdekking die gebaseerd was op vereisten, en niet op modules of testscripts. We beschikten bovendien niet alleen over bugstatistieken, maar ook over trends in bugs en statistieken over de snelheid van codewijzigingen om ons verhaal kracht bij te zetten. 

En al deze statistieken waren onmiskenbaar positief. Alle systemen stonden op groen. Er waren geen als/dan/anders-scenario’s nodig. Voor één keer zag ik geen reden om niet luid en duidelijk te zeggen: “Leveren maar!”, zonder voorbehoud. 

Technisch gezien was het echter niet mijn rol om dat te doen. Omdat het project werd geleid door een van mijn QA-managers, was het aan die persoon om dat gezaghebbende oordeel te vellen. Deze manager vatte alle statistieken nauwkeurig samen en erkende dat ze allemaal positief waren. 

Vervolgens begon die, tot mijn verrassing, te aarzelen over de vraag of het product al dan niet klaar was om te leveren. Verrassend, omdat we natuurlijk vóór die vergadering hadden besproken wat het standpunt van QA zou zijn. (Belangrijke opmerking: Verras uw baas nooit tijdens een vergadering.)

Ik vroeg de manager: “Wat zou ervoor nodig zijn om u comfortabel genoeg te voelen om een beslissing om te leveren aan te bevelen? Als het niet vandaag kan, wanneer dan wel?”

Tot mijn verbazing kon — of wilde — de manager opnieuw geen antwoord op mijn vraag geven. Het werd mij duidelijk dat deze manager eenvoudigweg geen verantwoordelijkheid wilde nemen voor het nemen van die beslissing, voor het zetten van zijn handtekening. Wat ik buitengewoon teleurstellend vond. 

Het was ook een belediging voor de engineeringmanager van het project, die de QA-inspanningen onophoudelijk had gesteund en een eersteklas product had ontwikkeld. Hij verdiende het niet om zo voor een voldongen feit te worden gesteld. Ik evenmin.

Dus greep ik in en zei: “Ik heb GEEN goede reden gezien of gehoord om dit product vandaag NIET uit te brengen. Dat is het oordeel van QA, en ik neem als QA-directeur de volledige verantwoordelijkheid voor deze beslissing.”

Ik dacht dat de engineeringmanager me bijna wilde kussen. Maar na die vergadering kregen QA-teams veel aanzien en enorm veel respect van engineering, projectmanagement en productmanagement. 

Want de weg om in onze wereld serieus te worden genomen, is publiekelijk verantwoordelijkheid nemen. Waar ik me op dat moment volledig veilig bij voelde, omdat ons verhaal vanaf het allereerste begin hierop was voorbereid. En het was geschreven met een gelukkig einde in gedachten.

Het product bleek na de release in de praktijk van hoge kwaliteit te zijn en was een groot succes. Het uitstellen van de release om te voorkomen dat iemand verantwoordelijkheid moest nemen voor de beslissing om het product wel of niet uit te brengen, zou alleen hebben geleid tot een minuscule toename van de productkwaliteit, tegen onredelijke kosten in geld en tijd tot de marktintroductie. 

Hoe we dat hebben gedaan, is een verhaal voor een andere dag.

Zoals altijd: veel succes met jullie QA-inspanningen.

Gerelateerde podcast: SAMENWERKING, AI EN CONTAINERISATIE (MET MICHAEL RITCHSON VAN NASA)