Soms ziet een plan er op papier prima uit, maar kan het in de praktijk heel anders uitwerken. Zo had ik bij een van mijn klanten de opdracht gekregen om naast het uitvoeren van performance testen deze ook te professionaliseren en vorm te geven volgens het agile principe. Op basis van een situatieanalyse met de eisen en wensen vanuit de teams en de lijnorganisatie ontstond een plan dat door alle managers werd goedgekeurd. De implementatie leek een eitje te gaan worden. Niets was echter minder waar.
De basis van het plan was vrij eenvoudig. De testers binnen de agile teams zijn verantwoordelijk voor wat er getest moet worden. De ontwikkelaars zijn verantwoordelijk voor hoe de tests er technisch uit zien. Voor wat betreft de performance testen zouden de teams zelf verantwoordelijk zijn voor performance van hun code als unittest. Een integrale end-to-end performance test zou nog steeds de verantwoordelijkheid blijven van een centraal team. Het idee was om dit plan eerst bij twee teams te implementeren. De reacties van zowel de teams als de team managers waren echter zo negatief, dat het werd afgeblazen.
5 valkuilen voor het implementeren van performance testing in agile teams
Wat ging hier nou fout? Ik kwam tot de conclusie dat ik in de volgende (typische) valkuilen ben getrapt:
1. Onterecht aanname van kennis over performance
Ik had er geen rekening mee gehouden dat de agile teams geen tot weinig kennis hadden van performance of performance testing. Er was voorafgaand aan de presentatie van het plan te weinig tijd besteed aan het opleiden van de teams.
2. Gebruik van vakjargon
In mijn plan gebruikte ik vakjargon als performance testen, testplannen en testscripts. Omdat hier weinig kennis van was zagen de teams deze zaken als een enorme drempel. Ze konden daardoor ook simpelweg niet overzien hoeveel werk dit met zich mee zou brengen.
3. Geen draagvlak bij de teams
De teams hadden bij de transitie naar agile werken te weinig begeleiding gekregen waardoor ze teveel vrijheid namen. Volgens hun eigen definitie was agile dat ze volledig autonoom waren en zich dus niets van de organisatie hoefden aan te trekken. Dit zorgde voor weerstand tegen veranderingen die buiten het team geïnitieerd waren.
4. Geen draagvlak bij het management
Ondanks het akkoord op mijn plan bleek dat het management zich niet voldoende bewust was van de gevolgen van de implementatie. Dit realiseerde men zich pas nadat de teams hun beklag deden waarna het management ook direct de goedkeuring introk.
5. Werken volgens een oude structuur in een agile omgeving
Uiteindelijk was de belangrijkste valkuil dat ik zelf het plan niet agile had aangepakt. Ik was op de klassieke manier requirements gaan verzamelen, analyseren, plan opstellen en gaan uitvoeren. Dit alles zonder de constante feedback loop die onderdeel is van het agile ontwikkelproces.
Hoe dan wel? Zo implementeer je performance testing in agile teams.
Na deze mislukte poging heb ik een tweede kans gekregen om opnieuw het performance testen bij de SCRUM-teams onder te brengen. Om te voorkomen dat anderen die voor dezelfde uitdaging staan niet in dezelfde valkuilen trappen, deel ik hierbij mijn belangrijkste learnings.
- Betrek de teams tijdig
Ik heb ervaren dat het essentieel is om de teams vanaf het begin te betrekken bij alle plannen, afstemmingen, overleggen en akkoorden. Hierdoor voelden zij zich ook verantwoordelijk voor het succes van de verandering. - Benader het proces agile
Het belangrijkste leerpunt was om het veranderproces agile te benaderen. Maak gebruik van de kracht van SCRUM. Kortcyclische sprints, met duidelijke stories en doelen, en haalbare aanpassingen. Aangezien de teams erg gefocust waren op functionaliteit kregen ze vrij weinig tijd om verbeteringen door te voeren. Een haalbare story was dan ook het opstellen van één unittest. Een volgende story was het opstellen van nog een unittest en een onderzoek naar de load-criteria. Zo konden de teams in een realistisch tempo hun kennis en testproducten opleveren zonder dat zij zich onder druk gezet voelden. - Zorg dat de verandering vanuit de teams zelf komt
Het heeft twee grote voordelen om de team zelf verantwoordelijk te maken voor de verandering:- Het team steunt de verandering aangezien deze door henzelf wordt aangestuurd. Ook hebben ze controle over het proces en kunnen ze aanpassingen doen zodat het eindresultaat bij hun eigen werkprocessen past.
- De product owner wordt door het team meegenomen in de verandering waardoor ook hij een betere afweging kan maken bij het prioriteren van de performance test stories.
Deze valkuilen en learnings kunnen veel tijd besparen en maken het verschil tussen succes en falen van je project. Doe er dus je voordeel mee. En mocht je meer willen weten over performance testing in agile teams, ik help je graag verder!