Als Scrum de kwaliteit vermindert

Scrum wordt door sommige mensen gebracht als de oplossing voor alle problemen. Maar de praktijk valt soms anders uit. Zo kan kwaliteit ook binnen een Scrum traject erg onder druk komen te staan. En bepaalde sterke punten binnen een Scrum aanpak, kunnen juist nadelig werken voor het testtraject. De terechte vrijheid van het Scrumteam kan leiden tot een slecht product. Maar pas wel op voor je een schuldige aanwijst!

Binnen Scrum heeft het scrumteam, terecht, heel veel vrijheid om het eigen proces in te vullen. Om bijvoorbeeld een eigen Definition of Done op te stellen. Of te bepalen welke testen er uitgevoerd zullen worden tijdens de sprint. Bij veel vrijheid komt veel verantwoordelijkheid. En daarmee veel mogelijkheid om de verkeerde weg in te slaan.

Zo kan je de acceptatiecriteria gebruiken om een story die je nooit in productie zal brengen, toch goed te laten keuren. In de acceptatiecriteria staat vaak echt niet dat bij een proces dat een halve minuut kan duren, de gebruiker moet zien dat hij moet wachten. Bijvoorbeeld met een zandlopertje. Dat zo ongeveer elke gebruiker na ongeveer 10 seconden denkt dat de site niet werkt en weggaat, doet niet ter zake. Het staat niet in de acceptatiecriteria, dus de story is goed.

En je hebt als Scrum team alle vrijheid om voor een website te besluiten om deze nu even niet in verschillende browsers te testen. Een browser is voldoende. Geschikt voor mobiel komt later wel. Dat websites juist regelmatig problemen geven op verschillende browsers, zeker op mobiel, is nu niet belangrijk. Scrum is een ideale methode om je kop in het zand te steken en door te gaan. Dat mag je tenslotte ook, want je bent zelf verantwoordelijk.

Laat ik wel eerlijk blijven: kwaliteit staat misschien bij veel Scrum projecten wel onder druk. Maar situaties die lijken op bovenstaande voorbeelden zal je niet bij alle Scrum projecten zomaar tegenkomen. Naar mijn ervaring staat kwaliteit vooral onder druk bij projecten die niet regelmatig naar productie gaan. Als een applicatie naar productie gaat en de kwaliteit is slecht, dan wordt het Scrumteam vanzelf gedwongen hun kwaliteitsproblemen aan te pakken. Geen enkele organisatie accepteert dat er drie sprints achter elkaar producten worden opgeleverd, die vervolgens weer teruggedraaid moeten worden.

Het probleem ontstaat vooral bij projecten waar de gang naar productie later is. Omdat men eerst een groot deel van de functionaliteit af wil hebben. Vaak is hier sprake van herbouw van een bestaande applicatie. De nieuwe applicatie moet dan toch minimaal vergelijkbaar zijn met de oude, voordat je naar productie gaat. Waardoor kwaliteitsproblemen meer verborgen kunnen blijven. En de redenering "Dat kunnen we in een komende sprint wel oplossen"erg geloofwaardig klinkt.

Juist bij projecten met een herbouw karakter is ook de druk vanuit de organisatie groter. Men wil resultaat zien. Hoe meer nieuwe functies, hoe meer vertrouwen men in het Scrumteam heeft. Om dit vertrouwen te winnen, kan je heel eenvoudig story's met problemen toch als afgerond beschouwen. Bij de Sprint Review kan je om de problemen heen een demo geven. De problemen schuif je door, geen probleem, je hebt nog zo veel sprints.  Het resultaat van de sprint lijkt nu opeens duidelijk beter. Het probleem is alleen, dat dit de volgende sprint weer gebeurt. En de sprint erna weer. En de sprint erna weer. Op een bepaald moment heb je een volledige sprint nodig om alle problemen op te lossen. Tijd voor die sprint is er niet. En verwerken in andere sprints is moeilijk. Want op de organisatie komt dat al vrij snel over als "het team levert minder werk".

Andere manieren om veel nieuwe functies op te leveren, is om werk te besparen. En veel testtaken zijn hiervoor ideaal. Regressietesten, performancetesten, compatibiliteitstesten, ze kosten tijd. Maar niemand van de business heeft het door als je ze achterwege laat. Terwijl de extra story's zeer welkom zijn. Bouwen van nieuwe story's is ook goed zichtbaar. Testen daarentegen, je kan er nauwelijks een demo over geven. En zelfs als je het doet, de interesse is niet groot. Dat deze tijd in latere sprints, op deze manier gedacht, ook niet beschikbaar is, is van latere zorg.

Maar niet altijd is druk vanuit de organisatie de oorzaak. Veel ontwikkelaars die beginnen met Scrum hebben ook moeite om om te gaan met de vrijheid die ze krijgen. Kregen ze eerst vaak het proces voorgeschreven. En stond tot in detail de te bouwen functie uitgewerkt. Nu moeten ze het proces bijna helemaal zelf bepalen. En wat ze moeten bouwen, kan je plotseling niet meer alleen lezen... nee, je moet deze zelf bespreken . Soms zelfs zelf beslissen. Dat moet je leren, maar de tijd die hiervoor nodig is krijg je niet. Toch krijg je krijg je wel te horen dat je beslissing niet correct was; het was dan een dom besluit. Veel ontwikkelaars grijpen zo terug naar de oude papieren zekerheid: als het niet is vastgelegd, hoef ik het niet te doen. Dat geeft tenminste duidelijkheid en voorkomt dat jij fouten maakt. Het voorkomt niet dat het fout gaat, maar het voorkomt wel dat jij fouten maakt.

Is Scrum dan niet geschikt voor herbouwtrajecten? Ik denk dat iedereen mijn antwoord kan raden: natuurlijk wel! Er zijn echter in mijn ogen wel bepaalde factoren nodig om een Scrumproject te laten slagen zonder kwaliteitsverlies.

1. Een scrumteam mag door een organisatie niet onder druk gezet worden om meer story's op te leveren. Zeker niet als de organisatie niet in staat is om de kwaliteit van het tussenproduct goed te controleren.
2. Een scrumteam moet in staat zijn om zonder schuldvraag hun fouten vast te stellen. Fouten zijn niet van een persoon, maar van het team als geheel. Het doel van het vinden fouten is niet een zondebok vinden, maar het streven naar een beter product en/of proces.
3. Elk scrumteamlid moet ernaar streven om trots te zijn op de opgeleverde story. Niet alleen op zijn of haar regels code, maar ook op het eindresultaat van de story als geheel. Niet alleen op de story's waar hij of zij een bijdrage heeft geleverd, maar op alle story's. Dit zal zeker niet altijd lukken, maar het moet altijd het streven zijn.
4. Scrumteamleden moeten gemotiveerd worden om kwaliteit te leveren. En gemotiveerd worden om het proces zo in te richten dat ze sneller de gewenste kwaliteit bereiken. Juist in dit laatste moet de organisatie de tijdwinst zien, die ze zo graag willen. Als het Scrumteam eerder problemen onderschept, kunnen ze eerder en vaak sneller opgelost worden. Of de problemen zullen niet eens voorkomen. En daardoor komt er weer tijd vrij om extra story's te bouwen. Maar dan wel met de gewenste kwaliteit.

Uiteindelijk komt de kwaliteit neer op de volgende regel uit de Scrumguide: "Aan het eind van een Sprint moet het nieuwe Increment “Klaar” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Klaar” gebruikt door het Scrum Team." Een Increment moet dus niet alleen voldoen aan de Definition of Done, maar ook bruikbaar zijn. Een niet erg duidelijk omschreven criterium. Maar als elk lid van het Scrumteam trots is, inclusief productowner, scrummaster, programmeur en tester, dan is het bijna zeker bruikbaar. Bij elk lid dat de bruikbaarheid ter discussie stelt, blijft het nodig om kritisch naar de kwaliteit te kijken. Want te vaak heeft dat ontevreden lid wel een heel terechte opmerking over de kwaliteit, en als gevolg hiervan vaak over de bruikbaarheid. En hiervoor moet je altijd open willen en kunnen blijven.