Agile Afternoon Het uitwisselen van ervaringen over Agile testen en -testmanagement Bartosz onderkent het belang van Agile en positioneert zich als dé Agile testpartij van Nederland. In dat kader heeft Bartosz voor haar klanten en relaties een evenement georganiseerd met als onderwerp Agile testen en -testmanagement. Onderdeel van dit evenement waren een drietal interactieve workshops, zogenoemde ‘Test Scrum of Scrums’, waarbij op een actieve en gestructureerde wijze ervaringen aan de orde zijn gekomen. De deelnemers vervullen allen een functie als lijn-, test- of projectmanager bij klanten van Bartosz. Tijdens deze workshops stond het uitwisselen van ervaringen en ´leren van elkaar´ centraal. Een aantal vraagstellingen vormden de leidraad van deze workshops, namelijk: Hoe organiseer je de testcompetentie binnen Agile? Is er nog een rol weggelegd voor de Testmanager? Bestaat de testafdeling niet meer, omdat het testen geheel is belegd binnen het scrum-team? In dit verslag worden de meest relevante ervaringen beschreven en toegelicht. Iedere scrum werd ingeleid door een uit de praktijk gegrepen verhaal van één van de deelnemers. De verantwoordelijkheid van de Testmanager Eén van de stellingen die aan bod is gekomen heeft betrekking op de verantwoordelijkheid en de rol van de Testmanager in Agile trajecten. Je kunt je afvragen of deze rol, en de daarbij behorende verantwoordelijkheden, nog steeds noodzakelijk is binnen Agile projecten. En zo ja, wat zijn deze taken en verantwoordelijkheden dan? Zijn deze veranderd in Agile trajecten ten opzichte van Waterval projecten? Testers zitten nu in ‘vaste’ (scrum-)teams die verantwoordelijk zijn voor de kwaliteit van de opgeleverde software. De Testmanager is niet meer verantwoordelijk voor het direct aansturen en inplannen van het werk. Dat gebeurt binnen de teams door de ScrumMaster. Maar wat doet een Testmanager dan wel in een Agile project?
Verslag Agile Afternoon
www.bartosz.nl
1
De Testmanager en het inplannen van resources Samen met de deelnemers is allereerst gediscussieerd over de stelling: ‘De Testmanager is verantwoordelijk voor het inplannen van resources’. De meningen over deze stelling waren verdeeld. Enerzijds kwam naar voren dat de Testmanager niet verantwoordelijk is voor HR zaken en dus niet voor het inplannen van resources. Hooguit geeft de Testmanager advies over resources op basis van het aangeboden en/of vereiste profiel. De Lijnmanager zet de resources in, in overleg met de Scrummaster. Anderen gaven aan dat de verantwoordelijkheid voor het inplannen van de resources ligt bij de Projectleider of zelfs de Releasemanager. Het moge duidelijk zijn dat er van organisatie tot organisatie nog veel verschillen zijn met betrekking tot het inplannen van testresources. Ook kwam naar voren dat er gewerkt wordt met vaste scrumteams en dat er daardoor geen resources hoeven te worden ingepland. Er is sprake van een vaste inzet per week, de Testmanager is hooguit verantwoordelijk voor de verdeling van de werkzaamheden. Eén van de deelnemers gaf ook aan dat een optimale samenstelling van het team de taak is van de testcompetentie, en niet van de Testmanager. Anderzijds werd genoemd dat de Testmanager wél verantwoordelijk is voor de inzet van testresources, maar dat dit wel afhangt van de taken, bevoegdheden en verantwoordelijkheden die aan de Testmanager zijn toegewezen. De Testmanager is bijvoorbeeld verantwoordelijk voor resourceplanning vanwege de kennis en vaardigheden die hij van testprofessionals verwacht en hij/zij kan deze ook beoordelen. Bovendien is de Testmanager op de hoogte van de eventuele ontwikkelplannen die spelen bij de testcompetentie binnen de organisatie. Met name in het geval van het inhuren van resources is de Testmanager verantwoordelijk omdat de Testmanager weet wat er aan expertise nodig is en beter op de hoogte zou moeten zijn van wat er ‘te koop is’ in de markt. Naast de inzet van testers kan de Testmanager ook verantwoordelijk zijn voor de inzet van resources voor de gebruikersacceptatietest. Wat duidelijk naar voren kwam tijdens de workshops is dat het testen gedaan moet worden door senior gebruikers. Zorg ervoor dat acceptatietesten niet worden gedaan door "de eerste de beste". Maar draag er zorg voor dat de juiste mensen geselecteerd worden en stuur hierop. De Testmanager en de integrale afstemming van testactiviteiten Een andere stelling die aan bod is gekomen met betrekking tot de verantwoordelijkheid van de Testmanager in Agile projecten is: “De Testmanager is verantwoordelijk voor integrale afstemming van alle testactiviteiten (binnen en buiten scrum).” Velen zijn het hier mee eens. Als Testmanager heb je een echte regiefunctie en dien je verantwoording af te leggen naar de programmaboard of de stuurgroep. De Testmanager bepaalt de aanpak, en stemt dit af met de scrummaster. Verder is de Testmanager verantwoordelijk voor de bewaking van de standaarden, richtlijnen, sjablonen enz. Ook moet de Testmanager
de
technische
afhankelijkheden
tussen
verschillende
scrumteams
managen.
Afhankelijkheden worden met een duidelijke afstemming over teams heen namelijk zo beter in de tests opgenomen, zonder te veel of te weinig te testen. Er werd ook aangegeven dat er bij grote programma’s een overall Testmanager wordt ingezet. Integrale afstemming vindt in dit geval plaats via releasemanagement indien dat nodig is.
Verslag Agile Afternoon
www.bartosz.nl
2
Het is mogelijk dat er een test community of practice ingericht is waarin continue afstemming plaatsvindt. De Testmanager houdt zich bezig met continue integratie, zorgt ervoor dat het team bij elkaar past en is integraal verantwoordelijk voor de testwerkzaamheden over de scrum teams heen. Wanneer een geïntegreerde aanpak ontbreekt, leidt dit tot een lagere effectiviteit en efficiëntie. Het is dus van belang dat de Testmanager de integraliteit van de testwerkzaamheden bewaakt. Tijdens de workshop is genoemd dat het bepalen van de inhoud van de release en de planning van de integratiefase niet de taak is van de Testmanager, maar de taak is van de ScrumMaster en/of het programmaboard. Dit zou betekenen dat de Testmanager niet verantwoordelijk is voor de specifieke afstemming van de testactiviteiten, maar dat de ScrumMasters hiervoor bij elkaar komen. Om vervolgens de voortgang inzichtelijk te kunnen maken, zowel binnen als buiten de sprint, dient een weekbord ingezet te worden. Dit zorgt voor transparantie en een goed overzicht. De Testmanager stuurt in een Agile omgeving niet meer op tijd en kosten. In Agile wordt gestuurd op het aantal zogenaamde features/use cases/user stories/etc. die opgepakt kunnen worden binnen een sprint. De deelnemers van de workshop gaven aan dat tijd, kosten en kwaliteit dan een vaste parameter zijn zolang de regels omtrent MoSCow en timeboxen worden gevolgd. In een sprint worden altijd een afgesproken set aan features opgeleverd op tijd en binnen budget zonder dat er extra opgeschaald moet worden. Maar een Projectleider die het Agile concept niet voldoende doorgrond blijft vaak (traditioneel) sturen op tijd en geld waardoor de kwaliteit in gevaar komt omdat niet op functionaliteiten wordt bezuinigd. Dit blijft vooralsnog een spanningsveld tussen de Projectleider en Agile. Verder is in de workshop naar voren gekomen dat een Testmanager bijvoorbeeld de PRA sessies doet en de integrale afstemming binnen de scrums en over de keten heen verzorgd. Verder werd aangegeven dat de Testmanager bijzondere zaken doet zoals performance testen, security testen en de overall kwaliteitsbewaking. De verantwoordelijkheid en de rol van de testcompetentie of -afdeling Twee andere stellingen die aan bod zijn gekomen tijdens de sessies hebben betrekking op de verantwoordelijkheid en de rol van de testcompetentie of –afdeling. Aangezien testers nu onderdeel zijn van een team dat gezamenlijk verantwoordelijk is voor kwaliteit is het interessant om te discussiëren over de noodzaak en de rol van de testafdeling. Testcompetentie/-afdeling organisatorisch ingebed? De deelnemers hebben eerst stilgestaan bij de stelling: “De testcompetentie/-afdeling is organisatorisch ingebed”. Over het algemeen geldt dat er commitment dient te zijn vanuit de directie voor Agile werken. Er dient zowel verticaal als horizontaal in de organisatie commitment te zijn om Agile in de organisatie uit te dragen. De deelnemers van de workshop waren van mening dat een Agile project anders geen kans van slagen heeft. Gedurende de sessie kwam naar voren dat de testcompetentie/-afdeling inderdaad vaak organisatorisch is ingebed. Er is sprake van een transitie naar een resource pool (een vaste groep met intern inzetbare testers) in plaats van een indeling per domein of systeem. Het team is namelijk verantwoordelijk voor kwaliteit. Er werd genoemd dat de testcompetentie gericht is op het testen en niet zozeer op de testers. Verslag Agile Afternoon
www.bartosz.nl
3
De testers worden aangestuurd vanuit de scrumteams zelf. De testcompetentie zal meer de randvoorwaarden gaan invullen, oftewel het beleid gaan bepalen en organiseren. Over de scrums heen dient er aandacht te zijn voor de keten en aansluiting te worden gevonden binnen het IT-landschap. Eén van de deelnemers gaf aan dat de testcompetentie wel is ingebed maar nog niet op de juiste plek. Namelijk binnen de IT in de projectorganisaties, terwijl in de lijn prettiger zou zijn. De testcompetentie vormt een bundeling van schaarse kennis en zorgt voor bijvoorbeeld het beschikbaar stellen van een toolcoach. Verder houdt een testcompetentie zich bezig met het centraal inkopen en onderhouden van de tools en wordt het beheer van de contracten gedaan. Ook werd er gediscussieerd over de type testers. Succesvol meedoen binnen een scrumteam vereist enige senioriteit. Hard en soft skills moeten goed ontwikkeld zijn. Daarom het liefst geen junior testers in Agile teams. Daarnaast is technische oriëntatie belangrijk bij de testers. Omdat er binnen een team zo nauw wordt samengewerkt tussen testers en ontwikkelaars is het van belang dat je elkaar begrijpt. Door gebrek aan technische knowhow en interesse kan dit de samenwerking negatief beïnvloeden. Verder dienen de teamleden fysiek dicht bij elkaar te zitten op de afdeling. Fysiek dicht bij elkaar zitten stimuleert de interactie. Hoe meer afstand hoe meer ruis er kan ontstaan in een team.
De testcompetentie/-afdeling en de verantwoordelijkheid voor testbeleid en kwaliteit Een andere stelling die aan bod is gekomen is: “De testcompetentie/afdeling is verantwoordelijk voor testbeleid en/of de kwaliteit van de software”. In de discussies kwamen de volgende zaken naar voren ten aanzien van deze stelling: onderdeel van het beleid is kennis, opleiding, coaching, tools, specialisme, leveranciers enz. Aangegeven werd dat het belangrijk is om duidelijke afspraken te maken en Agile richtlijnen vast te leggen. Hanteer zoveel mogelijk een standaard werkwijze. Maak duidelijke afspraken over kwaliteit. Formuleer de normen SMART, bijvoorbeeld over het maximum toelaatbare bugs, dekkingsgraden, testtechnieken, risico’s etc. Daarnaast kwam naar voren dat een proactieve houding van het team, en dus van de testers, wordt verwacht. Verder dient het team voldoende business- en/of proceskennis te hebben.
Verslag Agile Afternoon
www.bartosz.nl
4
Daarnaast is aangegeven dat kennisdeling erg belangrijk is. Een onderdeel van het beleid is het stimuleren van kennisdelen in én tussen de teams, bijvoorbeeld door competentie-sessies. Als we specifiek naar de stelling kijken dan waren een aantal deelnemers het er niet mee eens. Zij vinden dat de testcompetentie of de testafdeling niet verantwoordelijk is voor het testbeleid en de kwaliteit van de software. Zij geven aan dat dit op een hoger niveau belegd is. Iemand gaf aan dat de afdeling niet verantwoordelijk is voor de kwaliteit maar wel verantwoordelijk is voor het inzicht geven in kwaliteit. Ook werd er aangegeven dat het hele scrumteam verantwoordelijk is, en niet alleen de testcompetentie. Verder kwam naar voren dat de kwaliteit wordt geborgd door DoD (Definition of Done: welke exit criteria nodig zijn om vast te stellen of het product backlog item gereed is) en DoS (Definition of Success: deelnemer-eigen term). Een ander veel gehoord geluid was dat de Projectleider verantwoordelijk is en niet de testcompetentie of de testafdeling. In de workshop komt dus duidelijk naar voren dat hiervoor geen simpele oplossing is en dat voor beide situaties voors en tegens gelden. Er waren ook deelnemers die het wel met de stelling eens zijn. Zij geven aan dat de testcompetentie wel verantwoordelijk is, maar dat er soms te conservatief gedacht en gehandeld wordt, weinig innovatief en volop in risico’s denken (‘beren op de weg’). Er kwam naar voren dat de testafdeling de overall kwaliteit zal moeten borgen en daarvoor het benodigde gereedschap moet aanreiken. Er werd ook genoemd dat een centraal testbeleid goed werkt om een uniforme werkwijze te waarborgen. Ervaringen van diverse teams worden hierin meegenomen. Continue verbeteren is een focus die vanuit de helikopterview pas echt goed kan worden uitgevoerd en dan komt een testcompetentie die verantwoordelijk is voor testbeleid en kwaliteit wel erg goed van pas.
Verslag Agile Afternoon
www.bartosz.nl
5
Randvoorwaarden Tijdens de workshops werden er een aantal randvoorwaarden genoemd voor de verschillende stellingen. Deze zijn hieronder opgesomd. Randvoorwaarden algemeen Tijd om te leren. Fouten maken mag/moet, geef het team de tijd en investering om te kunnen leren. Daarom is het ook belangrijk dat er vanuit het management commitment wordt gegeven hiervoor. Soft skills: communication is key. Niet bang zijn om fouten te maken. Er moet een veilige omgeving worden gecreëerd door de ScrumMaster waarin mensen niet bang zijn om fouten toe te geven om daar vervolgens weer van te leren. Kundigheid personeel. Juiste samenstelling team (rollen). Blijf streven naar verbetering. Ambitie tonen en belonen. Mensen die een stapje extra zetten binnen een team moeten ook beloond worden. Dit kan als stimulans dienen om het totale team op een hoger niveau te brengen. Business in team zorgt ervoor dat ook de "buitenwereld" / ketenpartners / business actief betrokken is bij de scrum. Bijvoorbeeld bij stand-up meetings. Kleine teams. Noodzakelijk voor een goede communicatie. Houd het simpel: proces en regels. Scrum gedragen door MT. Beleid en visie over Agile/Scrum door het MT is essentieel; vooral bij grotere ketens. Management gelooft erin! Scrum teams en MT moeten samen communiceren over doelen; "wat wil de klant nu echt?". Als dit helder is, verloopt de uitwerking (in de scrum teams) beter Testautomatisering Randvoorwaarden voor de testcompetentie Juiste tools TDD Incidenten zijn integraal onderdeel van scrum team Empowered Onderdeel team Randvoorwaarden voor de Testmanager Faciliteren Waakzaam en dienstbaar
Verslag Agile Afternoon
www.bartosz.nl
6
Conclusie Over het algemeen valt op dat er voor vrijwel alle stellingen zowel best practices en lessons learned te noemen zijn. Ook kunnen de ervaringen behoorlijk verschillen. Dit geeft aan dat er binnen Agile geen ‘silver bullet’ is om bepaalde problemen op te lossen, maar dat de oplossing erg context afhankelijk is. Ook de historie en het volwassenheidsniveau van de IT- en testorganisatie spelen hier een belangrijke rol. Alsmede de manier hoe het is ingebed in de organisatie (volledig of deels). In algemene zin kan gesteld worden dat vanuit Agile-optiek een goede oplossing zich dient te baseren op het Agile manifesto zodat deze in lijn is met het Agile gedachtengoed. Deze oplossing inbedden of inpassen in een huidige waterval georiënteerde of naar Agile transformerende organisatie is maatwerk en vereist Agile-, test- en veranderkundige kennis en doorzettingsvermogen. Samenvattend is naar voren gekomen dat er binnen Agile omgevingen zeer zeker plaats voor een georganiseerde testcompetentie en ook voor de rol van testmanager. Alleen niet meer in de omvang zoals in de traditionele omgevingen, maar minder operationeel. Daarentegen schuift de rol veelal op van projectniveau naar meer tactisch/strategisch niveau en/of integrale test activiteiten.
Verslag Agile Afternoon
www.bartosz.nl
7
