Agile

In mijn vorige blog heb ik omschreven dat er in de omgeving waar ik werkzaam ben verschillende agile-facetten zijn geïmplementeerd, maar dat de manier waarop er gewerkt wordt niet zo agile is. Het blijkt lastig om definitief afscheid te nemen van concepten uit het waterval tijdperk. Zijn organisaties soms bang om te veranderen? In deze blog beschrijf ik op basis van mijn eigen ervaringen drie concrete activiteiten die verandering teweeg kunnen brengen en zorgen voor meer ‘agility’.

Agile werken door eenvoud

Hoe zorg je er nou voor dat er meer ‘agility’ in het team komt? Om deze verandering in gang te zetten kun je het concept uit Lean inzetten, namelijk: werken zonder verspilling. Binnen de organisatie waar ik werkzaam ben heb ik een aantal activiteiten ingezet die hebben geleid tot efficiënt werken en meer wendbaarheid binnen het team.

1. Three Amigos sessies invoeren

Het Three Amigos principe houdt in dat een business, developer en tester de backlog-items verduidelijken. Binnen mijn team wordt er gewerkt volgens ATTD waarbij Story Mapping en Specification by Example wordt toegepast. Echter, het komt vaak voor dat de ‘waarom-vraag’ onvoldoende duidelijk is. Waarom zou de PO of de business dit zo willen? Er ontbreekt een gezamenlijk begrip of beeld. De Three Amigos sessies worden ingezet om dit gezamenlijk begrip te krijgen en daarmee tot een betere user story te komen.

Doordat de business, developer, business analist en ik samen om tafel zijn gegaan, kwamen er andere vragen naar voren. Waarom bevat de keuzelijst opties die niet gebruikt gaan worden in het gemoderniseerde systeem? Het antwoord van de materiedeskundige was dat gemigreerde data van het oude systeem ook een plaats moet krijgen in het nieuwe systeem. Dit was een reden om de hoeveelheid werk van de user story bij te stellen, omdat de software architectuur het (nog) niet toeliet en er moest een migratiescript geschreven worden. Het was duidelijk dat deze informatie een defect in de software zou veroorzaken. De voorbeelden en inzichten lieten de developers zien dat ze hierdoor de technische oplossing kunnen matchen met de functionele behoeftes. Door de eenvoud van een Three Amigo sessie kwam de informatie sneller naar voren en inmiddels zijn deze sessies een standaard taak van een user story geworden.

2. Toepassing van Exploratory Testing

De toepassing van Exploratory testen (ET) werd aanvankelijk binnen de organisatie misbruikt voor het handmatig testen. Dit is bij deze herintroductie van ET niet het geval. Nu moet de software al getest zijn voordat we een ET-sessie ingaan. Er is hiervoor gekozen om aan te tonen wat de waarde is van ET. Maar ook wat het verschil is tussen handmatig testen en onderzoekend testen. Namelijk om nieuw systeemgedrag te ontdekken, met als doel de softwarekwaliteit vergroten. Door de test charters voor te bereiden en het doel van de sessie op papier te zetten, is er focus in de chaos gekomen. Bovendien is het nu duidelijk welke richting we op gaan met betrekking tot het ontdekken van het systeemgedrag. Het ontdekken van de ‘unknown unknowns’ dus.

We hebben als team een ET-sessie uitgevoerd en daarbij had ik de leiding. We zijn gecontroleerd van de gebaande paden afgegaan om het systeem te verkennen. Dit leidt vaak tot nieuwe inzichten over hoe user stories met elkaar samenhangen, maar ook geeft het informatie over de relatie met externe systemen. Door dit voortschrijdend inzicht ontstaat na afstemming met de product owner nieuwe user stories. Het team stelde ook meteen hun kwaliteitseisen bij en stelden zichzelf de vraag of ze zelf hiermee naar productie willen. Ik heb na enkele sprints voorgesteld aan de developers om de ET-sessies zelf te faciliteren en zo nu en dan nam ik een sessie weer over om er ‘feeling’ mee te houden. Bij elke user story is er een vrijwillige actiehouder/ontwikkelaar om de progress-lane op het Kanbanbord (TFS) te bewaken. ET wordt nu door de meeste teamleden uitgevoerd.

"Met deze concrete acties hoop ik jullie te inspireren. Dat deze ‘Leadership by example’ aanzet tot het zelf nemen van actie."

3. Multidisciplinair door zelflerend te zijn

Belangrijk bij agile willen werken is het verbeteren van de teamprocessen. Binnen het team heb ik benadrukt dat testen geen fase is en dat het niet draait om de effectiviteit van een individu maar om het team! Iedereen is verantwoordelijk voor de softwarekwaliteit. Met T-shaping gaat het niet zozeer om alles kunnen, het gaat om elkaar aanvullen vanuit de verschillende rollen. En daarnaast natuurlijk je kennis en vaardigheden met elkaar delen. Communicatie dus. Zo heb ik als test engineer regelmatig development-taken opgepakt, uitgevoerd, om hulp gevraagd, ingecheckt en waarde geleverd. Met vallen en opstaan, maar met een goed team is dit niet erg. Iedereen durft dan te experimenteren, fouten te maken en hiervan te leren.

Om de effectiviteit van het team te vergroten is er een aantal acties ondernomen. Allereerst hebben we de doorlooptijd en procestijd van de user stories meetbaar gemaakt. Het team ervaarde dat wanneer de user stories op de laatste dag de status ‘done’ kregen, dit zorgde voor een grote tijdsdruk op de sprint. De flow van de taken was niet meetbaar. Door de doorlooptijd en procestijd te meten en zichtbaar te maken hebben we als team kunnen zien dat de meeste user stories bijna een hele sprint van twee weken duren, terwijl de geschatte punten (op complexiteit) dat tegenspraken. Door dit inzichtelijk te maken was het mogelijk om bij te sturen.

Een tweede maatregel was het afspreken van een work in progress (WIP) limiet. Omdat er geen WIP limiet was, had iedereen meerdere taken van verschillende user stories. Door het afspreken van een WIP limiet kwam er meer focus op iets echt afmaken, in plaats van alles maar half afmaken. Met als resultaat dat de product owner niet op de laatste dag nog alles moest accepteren. Bovendien kon daardoor een eerder opgeleverde user story sneller geïntegreerd worden met de andere teams.

Als laatste hebben we met elkaar afgesproken om eerder aan de bel te trekken bij impediments. Om zo te voorkomen dat het pas wordt gemeld in de volgende stand-up. De user story blijft dan niet zodanig lang open waardoor het sprintdoel in gevaar kan komen. Om de drie weken werden de proces- en doorlooptijden geëvalueerd zodat we er continu aandacht aan bleven schenken. Doordat we de impediments zichtbaar zijn gaan maken op het Kanbanbord, kon er proactief ingegrepen worden.

De combinatie van bovengenoemde drie actiepunten heeft geleid tot een stabielere flow op het Kanbanbord en een verkorte procestijd.

 

Tijd voor actie!

Met bovengenoemde concrete acties die ik heb ondernomen binnen de organisatie waar ik ingezet  ben, hoop ik jullie te inspireren. Dat deze ‘Leadership by example’ aanzet tot het zelf nemen van actie. Een verandering vindt niet plaats door elkaar te vertellen dat je kennis hebt van agile. Want als je de theorie kent wil niet zeggen dat je het kunt. Je moet het ook daadwerkelijk doen en toepassen. Waarbij geldt: een fysieke actie inspireert anderen tot actie.

In mijn volgende blog deel ik een aantal ervaringen met jullie die bij nader inzien niet zo succesvol waren. Dus wat werkte niet? Voor mij persoonlijk misschien nog wel waardevoller en leerzamer dan de drie succesvolle acties uit deze blog.

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

Ontwerp zonder titel (19)

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.

Mijn Paarsz