Development

Procesmanagement
Agile overleg

De kunst jezelf de maat te nemen

Zo zet je Agile meetmethoden het best in op de werkvloer

© Shutterstock
16 december 2016

Zo zet je Agile meetmethoden het best in op de werkvloer

Agile werken belooft veel. Maar komen die beloften uit? Zijn al die agile teams wel goed bezig? Daar valt alleen iets over te zeggen als er gemeten wordt. Maar hoe geef je het meten in een agile context – waarin zelfsturing een van de centrale aspecten is - het beste vorm? En wat zijn de valkuilen?

De IT-wereld heeft in hoog tempo het agile werken omarmd. Bij veel organisaties zijn de verwachtingen rond de overgang naar deze manier van werken hooggespannen: producten van hogere kwaliteit, tegen een lagere prijs en in minder tijd geproduceerd. Meer business value, meer tevreden klanten én (niet onbelangrijk) meer tevreden medewerkers die plezier hebben in hun werk. Maar, komen die verwachtingen ook uit? Zijn al die agile teams wel goed bezig? Om een goed antwoord op die vragen te kunnen geven, helpt het om feiten te verzamelen, te meten. Daarmee betreden we het speelveld van de agile metrics. Hoe ziet dat speelveld eruit, hoe moet het spel gespeeld worden?

Metrieken passen bij empirisch karakter van agile

De afgelopen maanden zijn er diverse artikelen in AG Connect verschenen over het gebruik van (agile) softwaremetrieken: van Werner Heijstek (september), van Jolijn Onvlee en Richard Sweer (oktober) en van Frank Vogelezang (november). In dit artikel blijven we weg van de vraag welke metrieken het beste zijn en richten we ons vooral op de vraag hoe je meten in een agile context het beste vorm kan geven.

Agile meten

Binnen de agile wereld is het zelfsturende karakter van de teams een van de centrale aspecten. Het gebruik van metrics moet dan ook aansluiten bij de werkwijze van een agile team. Dat betekent dat niet een aparte Quality Assurance-afdeling bepaalt wat en hoe er gemeten wordt, maar dat de agile teams zelf aan het stuur zitten, met de QA-afdeling in een faciliterende rol. Dat brengt ons tot de volgende uitgangspunten:

Metrieken moeten aansluiten bij de werkwijze van het team

1. De teams hebben een belangrijke stem in de keuze van de metrieken die ze willen gebruiken om te bepalen of ze goed bezig zijn.

2. De teams zijn medeverantwoordelijk voor het uitvoeren van de benodigde metingen en het verzamelen van de meetresultaten.

3. De teams worden bij het meten ondersteund door (veelal aanwezige) tooling, zodat metingen met zo min mogelijk belasting kunnen worden uitgevoerd.

4. Ieder team analyseert trends in gemeten waarden en stelt vast of er actie ondernomen moet worden.

5. De gemeten waarden zijn niet geheim: iedereen in de organisatie (andere teams, management) heeft inzage in de team-dashboards.

Belangrijkste agile metrics

• Procesmetrieken

De meest gebruikte procesmetriek is de ‘velocity’: het aantal storypoints dat in één sprint is gerealiseerd. Hiermee meet een agile team zijn eigen productiviteit. In een ‘burn down chart’ wordt tijdens de sprint aangegeven welk deel van de bij de start geplande omvang (story points) daadwerkelijk is gerealiseerd. Tijdens een sprint kan ook worden gekeken naar het aantal taken waaraan gewerkt wordt – ‘Work in Progress’, WiP. De ‘cycle time’ geeft aan hoeveel tijd er verloopt tussen het indienen van een request en het in productie gaan van het resultaat.

Vanuit ontwikkeltools kan het aantal ‘check-outs / check-ins’ worden geteld, en kan worden geregistreerd wie in het team deze handelingen heeft verricht. Deze metriek kan worden gebruikt om inzicht te krijgen in het risico dat een team(lid) loopt bij de integratie van ingecheckte code in de code van het hele product.

De ‘test success rate’ (of ‘test failure rate’) is een indicatie van de kwaliteit van het ontwikkelproces. Daarnaast geeft de ‘test coverage’-metriek aan welk deel van de software wordt doorlopen door de (unit) tests. Tijdens het ontwikkelen komen defects naar voren. Het aantal openstaande defects (‘pending defects’) is ook een maat voor de kwaliteit van het ontwikkelproces.

• Productmetrieken

De belangrijkste productmetriek is het antwoord op de vraag wat het product de organisatie oplevert, de ‘business value delivered’. Die kan uitgedrukt worden in geld, maar bijvoorbeeld ook in klanttevredenheid (‘customer satisfaction’).

De omvang (‘size’) van de opgeleverde software wordt nog vaak uitgedrukt in functiepunten. In het verleden is er een groot aantal metrieken ontwikkeld om de statische kwaliteit van software vast te stellen. Het aantal ‘violations’ of ‘coding rules’ is een maat voor de statische kwaliteit van de code. Daarnaast vormt een goede set van functionele testgevallen (‘test cases’) een maat voor de kwaliteit van het product als geheel.

Alle software, nieuw of al jaren in gebruik, bevat technische schuld: onvolkomenheden die in de software zijn geslopen, achterstallig onderhoud. De hoeveelheid aanwezige technische schuld (‘technical debt’) is ook een maat voor de kwaliteit van software.

• Teammetrieken

Met de opkomst van het agile werken is er ook expliciet aandacht gekomen voor (het functioneren van) het team. We vatten dit samen in een tweetal metrieken: ‘team effectiveness’ en ‘team satisfaction’. De team effectiveness heeft betrekking op meer objectieve aspecten zoals de omvang van het team, de beschikbaarheid van teamleden, de samenstelling van het team, onderlinge afspraken. De team satisfaction (ook wel team happiness genoemd) omvat de meer subjectieve aspecten, zoals tevredenheid over het in een sprint bereikte resultaat, je prettig voelen in je werk en met je collega’s.

De inzet van metrieken past bij het empirische karakter van agile. De eerste twee uitgangspunten passen goed bij het zelfsturende karakter van agile teams. Wat betreft het derde uitgangspunt: de agile teams van nu werken doorgaans met een omvangrijke toolset ter ondersteuning van hun werkzaamheden. Die ontwikkelomgeving levert, met weinig extra inspanning, een heleboel metrieken op. Het is voor veel metingen dan ook niet nodig om een aparte toolset aan te schaffen en te installeren. Het vierde uitgangspunt is een directe vertaling van het agile principe dat benadrukt dat een agile team continu streeft naar verbetering (continuous improvement). Met een of meer dashboards kan een team niet alleen zichzelf, maar ook de buitenwereld (opdrachtgever, management) duidelijk maken hoe het is gesteld met de kwaliteit van werken. Transparantie – het delen van informatie – moet daarbij vooropstaan.

Valkuilen

Hoe zorg je ervoor dat een agile team zijn performance gaat meten en daardoor beter gaat functioneren? Daar is geen recept voor te geven. Iedere organisatie, ieder team, iedere situatie is anders. Daarbij is het verstandig om een paar valkuilen te vermijden. We noemen er vier:

• Het ‘streetlight-effect’: je kijkt alleen naar wat zichtbaar is onder een lantaarnpaal en zoekt niet in de schemering/duisternis daarbuiten. Wees je bewust van de verleiding om alleen te kiezen voor metrieken die direct voor het grijpen liggen. Het is zaak om met het team je goed af te vragen met welk doel je wilt meten en daar de selectie van metrieken door te laten bepalen.

• De ‘metrics galore’ is het tegenovergestelde van de eerste valkuil: niet kunnen kiezen uit de vele grootheden die gemeten kunnen worden, vaak met weinig inspanning. Maar het bijhouden van en reageren op een stortvloed aan meetwaarden is een veel te grote en daarmee ongewenste belasting van een team. Het is dan ook veel praktischer om te werken met een gerichte selectie van metrieken en te zorgen voor duidelijke dashboards.

• Een derde valkuil is het ‘observer-effect’: een individu of een team past zijn werkzaamheden zo aan dat hij of het goed scoort op wat er gemeten wordt, terwijl onderdelen van het werk die niet gemeten worden, geen of weinig aandacht krijgen. Uiteraard is het een goede zaak als een team aandacht heeft voor wat er gemeten wordt. Maar het is wel belangrijk om het eigen gevoel voor kwaliteit niet hiertoe te beperken.

• De laatste valkuil is ‘metrics for metrics’ – het meten om het meten. Een team produceert een mooie set meetwaarden omdat dat nu eenmaal moet, maar doet daar verder niets mee. Het is belangrijk dat meten gedragen wordt door het team, dat meetresultaten regelmatig aandacht krijgen – bijvoorbeeld in sprint-retrospectives. En dan helpt het als ze voortdurend zichtbaar zijn – bijvoorbeeld via dashboards op schermen aan de wand.

Agile meten in de praktijk

Ervaring leert dat voor veel agile teams het meten als basis voor continuous improvement nog zeker geen gemeengoed is. Twee aspecten worden door heel veel teams gemeten: de team velocity en het aantal defects. Soms aanwezig zijn burndown charts als het gaat om de kwaliteit van het proces, en test coverage, statische codekwaliteit-metrieken als het gaat om productkwaliteit. Het expliciet meten van team satisfaction zien we weinig. In sprint retrospectives is er zeker aandacht voor het functioneren van het team, maar dat wordt niet structureel gemeten en er wordt niet structureel op geacteerd.

In een sprint-retrospective wordt de velocity van de afgelopen sprint besproken. Is de velocity lager dan verwacht, dan wordt er gezocht naar verklaringen – onverwacht lagere capaciteit in het team door bijvoorbeeld ziekte, een verkeerde inschatting van de omvang van de te realiseren user stories.

De aandacht voor de in een sprint gerealiseerde productkwaliteit is minder, en minder structureel. Defects (issues) worden doorgaans wel geregistreerd, maar er wordt niet door ieder team actief op gereageerd. Voor metrieken als test coverage of statische codekwaliteit geldt dat, als een team ze meet, er wel op wordt geacteerd.

Zie ook Development op AG Connect Intelligence
1
Reacties
Rik Pennartz 18 december 2016 20:40

Een mooi artikel. Goede agile teams gebruiken continue allerlei meetinstrumenten. De belangrijkste meetwaarden zijn m.i. de release cycle time ( hoe snel krijgen we een nieuw verzoek in productie) en business value (moeilijk te meten, maar wel belangrijk).

Reactie toevoegen