Playing the Blame Game

Welke tester kent het niet? Een deadline of sprint wordt niet gehaald. En vervolgens is er een oorzaak nodig. Wat vaak neerkomt op het vinden van een dader. Omdat het werk rond het einde van een sprint of deadline vaak bij de tester ligt (die zit tenslotte aan het eind), is de tester vaak de eerste persoon waarnaar gekeken wordt. Je testte te langzaam, te veel, enz. Of er zijn klachten van klanten over de kwaliteit gekomen. Dan is het misschien niet eens vreemd, dat er naar het testen gekeken wordt. Maar ook niet altijd terecht. In dat geval testte je juist te snel, te weinig, enz. .

Het zoeken naar de oorzaak van problemen is op zich een goed proces en een belangrijke stap, om problemen in de toekomst te verbeteren. Maar hoewel hierbij steeds wordt vermeldt, dat er niet naar personen gekeken moet worden, is dit erg moeilijk. Als je de conclusie trekt, dat het testen te lang heeft geduurd, kijk je daar al snel de testers op aan. Maar als je de conclusie  trekt, dat de testers te laat konden starten, kijk je al snel naar developers.

Toch merk ik in de praktijk, dat het kijken naar 1 of meer personen bij het probleem meestal niet het de oorzaak van een Blame Game is. Waar het mis gaat, en wat het tot een echt Blame Game maakt, is als de ander jou gaat vertellen wat de oorzaak of oplossing van het probleem is. Constateren dat testen te lang duurt, kan terecht zijn. Maar te vaak gaat de brenger van de boodschap een stap verder. Hij of zij vertelt je ook waarom het testen te lang duurt. Bijvoorbeeld: "Je test teveel". Zo'n opmerking is vaak het startschot van een volledige Blame Game ronde. Want de neiging is zo ontzettend groot om daarop te reageren met bijvoorbeeld "De developers willen gewoon mij niet de juiste informatie geven, waardoor ik niet kan weten wat ik moet testen".

Stopping the blame game

Hoe voorkom je dit? Hoe groot de neiging ook is, schiet niet in de verdediging. Het heeft ook weinig zin, want je wordt toch niet geloofd. Je gesprekspartner heeft vaak wel degelijk tijd en aandacht besteed aan het probleem en is tot deze conclusie gekomen. Hoe onterecht de conclusie ook is, jij bent niet in staat om in 1 gesprek de ander te overtuigen door deze achterstand. Jij hebt tenslotte niet de tijd en aandacht kunnen besteden aan dit onderwerp, waardoor jij geen feiten tegen de genoemde conclusie in kan brengen. En dat is wat je nodig hebt: feiten. Alleen met feiten kan je een einde maken aan een Blame Game.

Dus daarom: geef wel degelijk aan dat je het er niet mee eens bent. Maar geef daarnaast vooral aan dat je mee wil werken om het probleem op te lossen. Probeer erachter te komen, waar deze conclusie op gebaseerd is. En, ongeacht of dit lukt op niet, vraag de tijd om dit probleem goed in beeld te krijgen. Probeer er ook voor te zorgen, dat je het eisenpakket in beeld krijgt. Hoelang mag het testen duren? Dan weet je waar je mee kan vergelijken.

Er zijn nu twee mogelijkheden: je krijgt de kans om zelf alsnog tijd aan de oplossing te besteden of je wordt gedwongen tot een oplossing van de ander. In het tweede geval: leg tijdens het gesprek de verantwoordelijkheid van de oplossing bij de ander. Maak heel erg duidelijk: dit is geen goed besluit. Maar probeer niet meer te overtuigen.

Wat er ook gebeurt: neem na het gesprek zelf de tijd en aandacht om naar het probleem te kijken. Als er bijvoorbeeld gezegd wordt, dat je langzaam test en je weet dat dit waar is, leg dan de oorzaken vast. Leg per story, RFC, enz. vast waardoor de vertraging veroorzaakt wordt: voor de test is veel voorbereiding nodig, er zijn veel varianten om te testen, je moet eerst informatie achterhalen, vragen aan anderen staan erg lang open, er zijn tijdens de test wijzigingen, waardoor het testen overnieuw moet, enz. Als het probleem niet waar is, leg dan vast hoelang je over het testen doet.

Als jou een oplossing is opgedwongen, leg dan ook de risico's van deze oplossing vast. Waarom wil jij deze oplossing niet? Bij het gedwongen inkorten van testen kan je bijvoorbeeld bang zijn voor meer fouten bij klanten, omdat je testen moet inkorten. En bedenk hoe je dit risico kan bewaken. Je kan bijhouden hoeveel fouten klanten melden bij een acceptatietest. Maar je kan ook duidelijk aan gaan geven, wat jij in de aangegeven tijd niet kan testen. Mensen zeggen snel: "test gewoon wat sneller". Maar als je aangeeft: "OK, dan test ik X en Y en Z niet", is het enthousiasme over de oplossing vaak een stuk minder.

Wanneer je de feiten over het aan jou gemelde probleem verzameld heb, maak een nieuwe afspraak. Leg de feiten voor en vertel daarbij wat volgens jou het probleem is. Wat is de belangrijkste oorzaak van het langzame testen? Wat is de werkelijke doorlooptijd van het testen? Wat zijn de risico's van de genoemde oplossing? Hoe kunnen we dat bewaken? In veel gevallen is een gesprek als dit de finish van een Blame Game. Omdat dit gesprek ervoor zorgt, dat je samen werkt aan een oplossing. Je staat niet meer tegenover elkaar.

Een Blame Game ontstaat vaak, doordat de twee kampen beiden het gevoel hebben, dat de ander niet naar ze luistert. Ze niet serieus neemt. De truuk om een Blame Game te stoppen, is om niet toe te geven dat de ander gelijk heeft, maar tegelijkertijd wel duidelijk te maken dat je de ander serieus neemt. Ook jij wil deze situatie oplossen. Daarom wil je weten wat er aan de hand is, wat eraan gedaan kan worden en wil je best een oplossing uitproberen. Mist er bij die oplossing wel naar de risiso's wordt gekeken.

De extra truck is om feiten te vinden, die in jou ogen een goed beeld geven van het probleem. Om tot een beeld te komen, waar jullie het over eens zijn. Want als jullie het over de feiten eens zijn, wil je beiden hetzelfde probleem oplossen. Wat het vinden van een oplossing, waar jullie beiden achter staan, een stuk eenvoudiger maakt.