http://www.agiletestenbijnee.nl/2015/07/als-scrum-de-kwaliteit-vermindert.html
Dit onderwerp is voor mij zeker niet minder actueel geworden. Er is nog steeds een hoge druk vanuit management en klanten om de beloofde story's in een sprint af te ronden. En nog steeds worden er, om dit waar te maken, shortcuts genomen. Nog steeds liggen deze shortcuts vaak in het testen, zoals korter testen, minder regressietesten of bugs in de applicatie laten zitten. En natuurlijk is het ook nu niet mogelijk om minder werk op te pakken in een volgende sprint, zodat er tijd vrij komt om je testproces goed en volledig afkomt. Want als een team de vorige sprint 20 storypoints heeft opgeleverd, moet dat de vorige sprint ook.
Maar zelf ben ik ondertussen drie jaar verder gegroeid. En waar ik toen alleen het probleem kon constateren, heb ik wat manieren geleerd om dit proces te voorkomen of te verminderen.
Maak afspraken met managers, Scrum Masters, Product Owners en bij voorkeur de klant
De eerste stap is het maken van goede afspraken. Zorg, voordat je deze gesprekken ingaat, wel voor een duidelijke boodschap: "Als we dit proces volhouden zal de kwaliteit van ons product steeds verder afnemen en afnemen. En dat gaat ons vanzelf klanten kosten." Het basisprincipe is simpel: als in elke sprint meer bugs ontstaan, dan worden opgelost, neemt elke sprint opnieuw de kwaliteit van de applicatie af. Als het daarnaast niet mogelijk is op een bepaald moment meer tijd vrij te maken om bugs op te lossen, wat vaak ook echt niet kan, is het eenvoudig te bedenken wat er met de kwaliteit gebeurt. Deze neemt verder af. En hoewel klanten niet snel van applicatie zullen wisselen, komt er een moment dat de slechte kwaliteit voor hun een grens heeft bereikt. Maar pas op dat moment het probleem oplossen zal veel, heel veel tijd kosten. Tijd, die tot nieuwe problemen zal leiden, omdat er veel minder tijd zal zijn voor nieuwe functionaliteit. En ook dat kan klanten gaan kosten.
De belangrijkste minimale afspraak om te maken, is dan ook de volgende: "Elke sprint moet meer bugs oplossen, dan introduceren". De beste afspraak is: "Een sprint mag geen nieuwe bugs introduceren". Een tussenvorm: "Gevonden bugs moeten minimaal in de sprint erna opgelost worden". Kijk hoe ver je komt. Start op de hoogste vorm, maar besef dat elk van deze afspraken al tot een verbetering zal leiden.
En belangrijk: maak deze afspraken met managers, Scrum Masters en Product Owners. Daarnaast, als het ook maar enigszins mogelijk is, maak deze afspraken met de klant. Een manager kan ingrijpen, omdat hij het werk te langzaam vindt gaan. Nu het invoeren van een goed testtraject bijna altijd tot langzamer opleveren zal leiden, is het verstandig dit ingrijpen te voorkomen. Een Scrum Master moet zijn of haar team motiveren te streven naar deze kwaliteit. En ook kunnen uitleggen waarom we het doen. De Product Owner moet bereid zijn te accepteren dat er minder nieuwe functionaliteit opgepakt wordt. En als je het ook uit kan leggen aan de klant, zal deze minder snel druk op de organisatie leggen om toch meer nieuwe functionaliteit op te leveren. Want echt: ook voor de klant is de kwaliteit zeer belangrijk.
Maak statistieken
Na het maken van de afspraken, kan je van 1 ding gelijk uitgaan: deze afspraken gaan gebroken worden. Het besef is er, maar onder druk zal men al snel zeggen: "Maar je moet toch een keer een uitzondering kunnen maken?". Of "Zo ernstig is het probleem toch niet?". Om dit voor te zijn, moet je vanaf het moment van afspraken statistieken bijhouden. Twee statistieken zijn hierbij van belang:
- Het totaal aantal openstaande bugs in de loop van de tijd
- Het aantal bugs opgelost in de sprint en het aantal bugs ontstaan in de sprint
Er is altijd een registratie van openstaande bugs. Zorg ervoor dat je minimaal 1 keer per maand telt hoeveel bugs dit zijn en noteer dit. Bij de meeste applicaties is dit nog geen 5 minuten werk.
De tweede vorm van statistieken is iets meer werk. Tel aan het begin van de sprint hoeveel bugs er worden opgelost. Houdt vervolgens tijdens de sprint bij hoeveel bugs er geïntroduceerd worden. Bereken vervolgens het verschil tussen deze twee en leg deze drie getallen vast. Het belangrijkste is het verschil per sprint. Bijna elke sprint opnieuw een toename in bugs maakt wel degelijk indruk, zelfs als dit er maar 1 per sprint is.
Spreek communicatie af
Spreek af hoe de bovenstaande statistieken gecommuniceerd worden.
- Alleen melden als het mis gaat of altijd melden?
- Wie moeten op de hoogte gebracht worden?
- Wie heeft als taak actie te ondernemen om het probleem op te lossen?
Maar het allerbelangrijkste is:
- Hoe laat je weten dat de kwaliteit de verkeerde kant op gaat?
Als je elke maand een mailtje stuurt, zal deze op een bepaald moment nauwelijks meer gelezen worden. Spreek dan bijvoorbeeld af de titel van de mail te wijzigen of een meeting in te plannen, als jij vindt dat er actie moet worden ondernomen. Zorg ervoor dat de communicatie duidelijk en zichtbaar verandert, als de statistieken duiden op een afname in kwaliteit.
In het kort
Om Scrum de kwaliteit niet te laten verminderen, moet je minimaal per sprint minder bugs introduceren dan oplossen. Om dit voor elkaar te krijgen, moet je goede afspraken maken met alle betrokkenen: managers, Scrum Masters, Product Owners en bij voorkeur de klanten.
Maak na de afspraken goede statistieken, die het proces bewaken. Ga er nooit vanuit dat de afspraken alleen voldoende zijn. Er zal, vroeg of laat, door druk van worden afgeweken. Het effect hiervan moet dan zichtbaar gemaakt kunnen worden.
En spreek af hoe deze statistieken gecommuniceerd worden en met wie. Denk hierbij sterk aan het volgende: de communicatie moet, als actie noodzakelijk is, een zichtbaar andere vorm hebben, dan bij de gewenste situatie. Zodat dit gegarandeerd door de betrokkenen opgemerkt zal worden.
