2. Teststrategie schrijven voor een cross-functioneel team
Om zichtbaarheid te geven over het toetsen van de softwarekwaliteit, hebben een aantal beleidsmakers de teams opgedragen om een teststrategie te schrijven. De kaders die opgesteld ware, passen naar mijn idee niet in een agile context. De teststrategie gaat uit van uitgebreide testtechnieken toepassen, automatiseren en risicoklassen geven aan user stories. Er wordt verzocht om extra taken aan te maken zodat zij een query makkelijker kunnen draaien in TFS om rapporten te draaien die niets zeggen over de testdekking of codekwaliteit. User stories uit het verleden die op ‘Done’ waren gezet en geen testtaak hadden, moesten alsnog aangemaakt worden. De informatie was voornamelijk bedoeld voor interne audit, terwijl de teststrategie als een globale leidraad fungeerde voor het team. De teststrategie moest getekend worden door personen uit de hele organisatie, wat niets bijdraagt aan het proces. Hier heb ik de keuze gemaakt om niet meer in te gaan op de verzoeken van de beleidsmakers. Ik ben gestopt met handtekeningen verzamelen. In mijn visie op testen en kwaliteit pas dit namelijk niet bij agile werken.
Na een overleg met het team hebben we de afdelingsdirecteur gevraagd om bij ons team langs te komen. We hebben laten zien welke maatregelen we nemen op het gebied van kwaliteitsborging en risico mitigatie en hoe transparant we daarin zijn. We gaan niet opeens kwaliteit leveren als er een getekend document opgeleverd is heb ik uitgelegd. Ze begreep de boodschap dat de Internal Audit naar ons team verwezen moet worden in plaats van het lezen van een teststrategie. Dat het snel oplossen van defects belangrijker is dan de vooraf bedachte processen volledige af te testen voor livegang. De teststrategie is nooit meer getekend, maar de teststrategie wordt wel gehanteerd.
3. Opsplitsen naar kleinere teams
Een aantal maanden na de start van het project was het team flink gegroeid en inmiddels 13 personen groot. Dit resulteerde in veel communicatielijnen wat tot veel onnodige discussies leidden. Daarom heb ik voorgesteld om het team te splitsen naar twee wendbare teams. Dit werd uitgevoerd, met het doel om de ‘velocity’ van het team te verhogen. Door het opsplitsen naar twee teams ging de communicatie aanzienlijk beter, echter was de ‘velocity’ niet veel hoger geworden en de flow bleef laag. De reden was dat de kennis onvoldoende verspreid was onder de teamleden waardoor er meer tijd ging zitten in het zoeken naar informatie. Fysiek zaten we in dezelfde ruimte, maar niet iedereen werkte meer aan hetzelfde sprintdoel. Dit werd duidelijk in de retrospective waarin beide teams aan deelnamen.
We hebben ons dus verkeken op het ervaringsniveau per individu. Als één team zijn we complementair aan elkaar, maar opgesplitst was er duidelijk een sterk en een zwak development team. Deze blinde vlek was niet zichtbaar toen het nog één team was. Na drie sprints zijn we dus weer verder gegaan als één team.
Hiermee komt er een einde aan mijn serie blogs. Ik hoop dat jullie ze met plezier gelezen hebben en er wellicht nog iets van hebben kunnen opsteken. Mocht je vragen hebben, of advies willen, aarzel dan niet om contact met me op te nemen.