Jeroen van den Berg – Jeroen.van.den.berg@bartosz.nl
Testen is geen doel op zich. Het in een voorspelbaar tempo leveren van software met voldoende kwaliteit is dat wel. In de Quality Infected Team benadering wordt kwaliteit gestuurd door het team en niet alleen door de tester. Binnen deze benadering onderkennen we drie aandachtsgebieden, namelijk: whole team approach, fast feedback en exploration. Hoe pas je dit toe in de praktijk? In dit artikel ga ik in op de pijler whole team approach. Ben je al bekend met het three amigo principe en de bug-hunt? En weet je wat de voordelen zijn van de whole team approach, ook binnen jouw team?
Quality Infected Teams
Een Quality Infected Team (QIT) is kort samengevat een team dat streeft naar een voorspelbaar ontwikkelproces en software oplevert waar klanten écht wat aan hebben. Kwaliteit staat hierbij centraal en de neuzen van de teamleden staan daarom altijd in dezelfde richting. Er is een gedeeld begrip over hoe doelen bereikt worden. Een QIT hanteert een whole team approach als het gaat om kwaliteit, kent de onschatbare waarde van fast feedback en gebruikt exploration om te leren wat ze nog niet weten.
Van workshop naar concrete verbeterpunten
Op dit moment ben ik gedetacheerd bij een overheidsinstantie. Hier werken we met elf teams aan één product via de SAFe methodiek. Als Agile (test)coach was ik verantwoordelijk voor het aanbrengen van verbeteringen in de huidige werkwijze. Om dat te bewerkstelligen hebben we het QIT gedachtegoed geïntroduceerd. In eerste instantie bij één team om het vervolgens binnen alle teams te laten landen met een workshop. Door middel van een kaartspel ontdekken de deelnemers op welke vlakken zij als team kunnen verbeteren. Op iedere kaart staat een practice beschreven die het team kan inzetten om sneller tot betere software te komen.
De verbeterpunten die naar voren kwamen tijdens de eerste workshop vielen voornamelijk onder het aandachtsgebied whole team approach. Zo hebben we het wekelijks organiseren van een three amigo sessie geïnitieerd en al meerdere bug-hunts georganiseerd.
Een gezamenlijk begrip door three amigo sessies
Het three amigos principe houdt in dat iemand van de business, een developer en een tester samen de backlog-items gaan refinen. Met als doel om een gezamenlijk begrip, ook wel ‘shared understanding’, te krijgen en daarmee tot betere user story’s te komen. Voor de business staat de vraag centraal: welk probleem proberen we op te lossen? De developer houdt zich bezig met: hoe kunnen we een oplossing bouwen om het probleem op te lossen? En de tester vraagt zich af: wat kan er eventueel gebeuren en misgaan? Doordat deze drie disciplines tot een gezamenlijk begrip komen, is de kans vele malen groter dat de software ook daadwerkelijk juist wordt gemaakt: ‘Building the right thing en Building the thing right’.
Kennisoverdracht, domeinkennis en een beter product door bug-hunt
Het tweede verbeterpunt dat naar voren kwam tijdens de workshop QIT, hebben we opgepakt door het organiseren van een bug-hunt tijdens de Innovation & Planning sprint (IP-sprint). Gefaciliteerd vanuit de test community kregen de verschillende teams een uitleg over exploratory testing (ET) en over de functionele componenten. Vervolgens werd aan de teams gevraagd om drie componenten (functioneel brok) van de applicatie te gaan testen. Daarbij werd er gerouleerd waardoor ieder team met twee componenten aan de slag kon gaan. Alle bevindingen zijn daarna vastgelegd en vervolgens geprioriteerd door de product owners. Deze manier van werken leverde drie voordelen op: kennisoverdracht vanuit de testers over exploratory testing, domeinkennis (waar sommigen nog onvoldoende over beschikten) en ten slotte heeft het uiteindelijk een beter product opgeleverd.
Voordelen whole team approach
Het grootste voordeel van het toepassen van de whole team approach is het bereiken van gedeeld begrip binnen het team of over de teams heen. Een ‘shared understanding’ over wat er moet gebeuren (‘making the right thing’) en hoe het moet worden gemaakt (‘making the thing right’).
Een ander voordeel is dat door de whole team approach iedereen in het team elkaars werkzaamheden voor in elk geval een klein gedeelte kan overnemen. Wanneer de tester afwezig is, kan de developer bijvoorbeeld een gedeelte van zijn of haar werkzaamheden overnemen. Eén tester kan het development werk van meerdere personen niet bijhouden en dus moet hij of zij altijd geholpen worden bij deze activiteit. Hiermee wordt het testen een activiteit in plaats van een rol! Daarnaast kun je als team pas opleveren als de software getest is, dan voldoe je namelijk pas aan de definition of done (DOD). Op deze manier wordt de oplevering steeds meer team effort.
Tips voor het toepassen van de whole team approach
Toepassen van de whole team approach kost tijd en heeft ook een bepaalde voorbereiding nodig. Mijn tip is daarom om klein te beginnen. Start bijvoorbeeld met één team en bouw daarna het gedachtegoed uit met de overige teams. Niet iedere aanpak past bij iedere opdracht. Ga door met de verbeteringen die wél werken en wees ook niet bang om mislukte verbeteringen niet meer toe te passen, anders wordt het ‘waste’. Een manier om dit te doen is het toepassen van de QIT workshop en op gezette tijden het spel te herhalen in de retrospectives of de inspect and adapt (I&A).
En als laatste wil ik jullie meegeven: blijf volhouden! Verzin meerdere manieren om de whole team approach te propaganderen en als de ene manier niet werkt, dan doe je het daarna weer op een andere manier.
Wil je meer weten over de workop Quality Infected Team? Neem dan gerust contact met mij op.