Alle IT-kennis onder één wereldwijd dak
Werken bij de beste IT dienstverlener van Nederland?
Resultaat door passie voor IT
Start trefwoorden te typen om de site te doorzoeken. Druk enter om te verzenden.
Generative AI
Cloud
Testing
Artificial intelligence
Security
May 05, 2023
In eerdere artikelen zijn we ingegaan op Regie op Ketenkwaliteit met daarbinnen de Ketentest in SAFe®. Maar hoe zit het eigenlijk met de rol van Testmanager (TM) binnen (Scaled) Agile? Het eenvoudige antwoord zou zijn: die wordt niet genoemd, dus is er niet meer. En als we het over de individuele teams en de Release Treinen hebben dan klopt dat ook. Maar er knaagt iets. In dit artikel proberen we dat te verduidelijken.
Wanneer we ons richten op de taken en verantwoordelijkheden van de “voormalig” TM dan zien we dat binnen de Agile wereld een verschuiving heeft plaats gevonden. Een deel van de taken verschuift naar de Product Owners en een deel verschuift naar de individuele teams.Product Owner (PO)
Zo is de PO verantwoordelijk voor de kwaliteit van wat aan de teams wordt gevraagd te leveren en dient erop toe te zien dat dit ook gebeurt. De PO zal daarom de acceptatie criteria moeten benoemen voor de User Stories (US) die worden gepland. Daarvoor is het belangrijk om de behoefte van de klant te kennen. Daarbij is stakeholdermanagement van groot belang. Ken je stakeholders binnen zowel de business als beheer, het belang en het mandaat van deze stakeholders en manage deze belangen richting de resultaten van de teams en communiceer/deel deze resultaten via bijvoorbeeld reviews/demo’s.TeamsDe teams en de teamleden daarbinnen zijn verantwoordelijk voor het leveren van de gevraagde kwaliteit en het inzichtelijk maken daarvan. Ook zijn zij verantwoordelijk voor het uitvoeren van risico analyses en het benoemen van een testaanpak per US, het uitwerken en uitvoeren van scenario’s en het vastleggen van de resultaten. Ook het opzetten en onderhouden van een regressietestset en de toepassing van test automatisering valt onder de verantwoordelijkheid van de teams.Een en ander lijkt versnipperd, maar door de samenwerking tussen beide partijen zou de kwaliteit voldoende moeten worden geborgd. Belangrijk hierbinnen is om elkaar aan te spreken op mogelijke risico’s en potentiële verbeteringen en daarop bij te sturen, zodat je groeit en verbetert als individu en als groep. Kortom, dit zou gewoon goed moeten werken. Hierbij kun je ook de rol van Agile Quality Coach inzetten om de betrokkenen te begeleiden en te coachen.Maar juist door dat woordje “versnipperd” begint er wel iets te knagen. Dat komt doordat de TM voorheen meer deed dan wat nu bij deze partijen is belegd. En dan gaat het om het creëren van visie, beleid en richtlijnen op het gebied van kwaliteit en testen: De kapstok waar alles onder valt. Dat deel heeft onvoldoende een plek gekregen in “de nieuwe wereld”. Het gevaar dat dan ontstaat is dat er wildgroei in een organisatie plaats kan vinden en er mogelijk zelfs beveiligingsrisico’s worden gelopen (denk aan gratis, minder veilige tools die worden ingezet) en er onvoldoende synergie tussen de teams en treinen ontstaat. Een ander deel betreft de begeleiding en coaching van de specialisten. Deels gebeurt dat door het team zelf, de Scrum Master en eventueel de Agile Quality Coach. Deels zou dat echter op hoger niveau een plek dienen te krijgen: Een Community of Practise.
Naar mijn mening zou het goed zijn wanneer iemand zich in beginsel, minimaal op Solution niveau, bezighoudt met de genoemde visie, beleid en richtlijnen. Dit zou wanneer je klein en simpel begint ook op ART niveau kunnen zijn. “In beginsel”, omdat ik me kan voorstellen dat er op termijn, wanneer de organisatie naar een hoger volwassenheidsniveau is gegroeid, minder behoefte is aan een dergelijke rol op een lager niveau. Als daar sprake van is kun je kiezen om deze aspecten naar een hoger niveau in de organisatie te tillen. Welke naam je aan die rol koppelt is wat mij betreft vrij invulbaar voor een organisatie. Je kunt hiervoor de termen “Kwaliteitsmanager” of “Testmanager”, of soortgelijke termen gebruiken. De naam maakt niet uit. Het gaat om wat die persoon doet!
Dit betekent niet dat de teams en individuen hun vrijheid verliezen in de keuze hoe dat ze zaken aan willen pakken. Dit betekent wel dat deze vrijheid op hoofdlijnen wordt gestuurd, met als doel:
Waar moet je dan zoal aan denken? De visie, het beleid en de richtlijnen richten zich op kwaliteit en testen en kunnen worden opgenomen in een document als Generieke Test Afspraken (GTA). Concreet zouden de volgende onderdelen hierbinnen een plek dienen te krijgen, waarbij ik benadruk dat dit op hoofdlijnen gebeurt.
De teams en de individuen worden vervolgens periodiek, door de verantwoordelijke voor bovenstaande, getoetst op naleving van deze onderdelen en waar nodig bijgestuurd of gecoacht. Ook kan deze bijvoorbeeld onderdelen onder de aandacht brengen tijdens een Community of Practise.
Heb je vragen of wil je hierover van gedachten wisselen neem dan contact op met Tinus. Wil je je eerst nog verder orienteren? Bekijk dan onze test services of onze expertise in testengineering!
Community manager Agile Quality Improvement