Agile

Een organisatie transformeren naar agile is makkelijker gezegd dan gedaan! Het implementeren van agile-facetten en tegelijkertijd moeite hebben met definitief afscheid nemen van concepten uit het waterval tijdperk is iets waar verschillende organisaties tegenaan lopen. Op basis van mijn eigen ervaringen heb ik in mijn vorige blog een drietal makkelijk toepasbare, concrete activiteiten beschreven die leiden tot meer ‘agility’. In deze blog deel ik een aantal ervaringen met jullie die bij nader inzien niet zo succesvol waren. Dus wat werkte niet?

1. Test Driven Development (TDD) werken

Developers maken unittests om de werking van het stukje code te ‘bewijzen’. Met oog op kwaliteit zorgt het er ook voor dat er veilig een refactorslag gemaakt kan worden om grip te krijgen op de technical debt. Wanneer bugs gevonden worden, komt er veel zoek- en analysewerk bij kijken. Dus TDD helpt de developers snelle feedback te geven en er wordt een vangnet gerealiseerd door unittesten te maken. Deze redenen waren voldoende overtuigend om te laten inzien dat TDD werken een logische keuze is, in combinatie met het op een andere wijze uitvoeren van unittesten. Ook door de developers werd erkend dat TDD een waardevolle methode is.

Uiteindelijk is er niet besloten om TDD te gaan werken omdat het in die fase van het project een te grote investering was om het team TDD te leren. Developers gaven aan dat ze eerst werkende software wilden maken en daarna de tests. Het voordeel van TDD is dan weg.

Ik heb nadrukkelijk aangegeven dat we niet inboeten op de softwarekwaliteit. Dit zorgde ervoor dat er wel unittesten achteraf werden gemaakt bij elke functionaliteit met ET als aanvulling. Deze keuze is een suboptimale oplossing, maar beter dan geen unittests en dus ook geen snelle feedbackloops. Tooling zoals SonarQube zorgt ervoor dat de code coverage van ons domein meer zichtbaar wordt, waardoor het team momenteel bewuster is geworden van de codekwaliteit.

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.

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Bartosz_Header_004

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Bijtanken bij Bartosz

Gamification

Jan25

Software testen is geen handwerk maar keihard denkwerk. We maken een mentaal model van hetgeen we aan het testen zijn en aan de hand daarvan gaan we op zoek naar hoe we dat model kunnen kraken. Belangrijke skills die je hierbij nodig hebt zoals Critical Thinking en Problem Solving kun je ontwikkelen.

Ben je in staat om je analytische vaardigheden in te zetten om een puzzel op te lossen of een algoritme te kraken? Kun je onder woorden brengen wat de oplossing was? En wat was je aanpak was om de uitdaging aan te gaan?

Zo kennen we verschillende vormen van Gamification binnen het testvak. De eerste Bijtanken bij Bartosz van 2019 laat zien welke spelvormen we daarbij inzetten en waarom we daar zoveel waarde aan hechten. Maar we gaan vooral ook doen!

Mijn Paarsz