Hoe voorkom je de "Wet van Murphy"

Soms zijn er van die momenten en dan gaat alles fout. Is net het ene fout gegaan, gaat vlak daarna het andere fout. Als tester kom je de ene na de andere fout tegen. En als de ene fout opgelost is, is er een nieuwe fout ontstaan. Zo niet meerdere fouten. Ik denk dat er bijna geen tester is, die niet een keer in zo'n periode heeft gezeten.

Hoe voorkom je dat alles wat fout kan gaan ook werkelijk fout gaat? Een van de belangrijkste oorzaken van deze situatie is tijdsdruk. Iets moet afgerond zijn voor een bepaalde datum. Dit kan het eind van een sprint zijn of een deadline. Maar het werk is eigenlijk teveel om voor deze datum af te ronden. Dus gaat iedereen op zoek naar manieren om het werk sneller op te leveren. De tijd voor het testen wordt teruggebracht, het lezen van de vastgelegde eisen gaat sneller of wordt overgeslagen. Maar om de planning te halen, moet het wel in een keer goed. Anders haal je het niet.

Voor mijzelf heb ik dit de "Happy flow planning" genoemd. Dit is een geplande werkwijze, waarbij je ervan uitgaat dat alles goed gaat. Daarom is testen en voorbereiden bijna niet nodig. En is er geen tijd nodig om problemen op te lossen. Dit vaak onder de noemer dat een zo ervaren team toch in staat moet zijn om deze klus zonder problemen op te pakken.

Maar de reden dat een ervaren team in staat is om zo'n klus zonder problemen op te pakken, is vaak dat ze niet uitgaan van een foutloos traject. Ze controleren hun eigen werk en laten het door anderen controleren. Ze lezen en bespreken, om te kijken of ze het goed hebben begrepen en hebben onthouden. Dit lijkt in eerste instantie vaak meer tijd te kosten. In de praktijk gaat dit echter sneller of even snel als de "Happy flow planning". Want bijna nooit gaat alles in een keer goed. Waardoor men een nog krappere "Happy flow planning" moet afstemmen. Met nog meer risico en stress. En vaak nog meer fouten. Resultaat: de afgesproken datum wordt niet gehaald met de afgesproken inhoud.

Wat dan? Want soms is er nu eenmaal een einddatum. En soms is er te veel werk. Nu, het belangrijkste is een goede prioritering. Plan datgene wat het belangrijkste is het eerst, maar voer deze activiteiten wel goed uit. Hierbij kan je denken aan onderdelen van een applicatie, bijvoorbeeld eerst zoeken op naam, daarna zoeken op postcode. Maar je kan hier ook denken aan het prioriteren van activiteiten. Denk dan wel aan activiteiten, die de kwaliteit niet in gevaar brengen. En ja, vaak zijn dit toch testactiviteiten. Is het sneller om handmatig te testen, dan automatisch? Test dan handmatig. Is het sneller om de tester te laten testen, dan om een ontwikkelaar te laten testen? Laat de tester testen. Is het sneller om een ontwikkelaar te laten testen, dan een tester te laten testen? Laat een ontwikkelaar testen. Kan je even zonder documentatie, stel het uit.

Het beste is en blijft de functionaliteit zo afspreken dat de einddatum geen probleem is. Maar als dit niet kan, bezuinig dan niet op activiteiten die juist helpen om te garanderen dat de afgesproken einddatum gehaald wordt. Ook al lijkt dit overbodige tijd. Blijf je eigen werk minimaal 1 keer controleren. Laat je werk minimaal 1 keer door iemand anders controleren. En blijf nagaan of je alles goed begrepen hebt. Houdt altijd minimaal deze eisen aan en kijk waar je kan bezuinigen op de rest.

En laat deze situatie een uitzondering blijven. Want als dit vaker voorkomt, kan je doen wat je wil. Maar de "Wet van Murphy" zal uiteindelijk toeslaan. Ook de uitgestelde activiteiten hebben tenslotte hun meerwaarde. Dus op de lange termijn gaat het problemen geven als je ze blijft overslaan. En dat worden uiteindelijk vanzelf heel veel grote problemen heel veel achter elkaar.