Onze relaties vragen zich steeds vaker af of het überhaupt nog nodig is om de IT-trajecten te meten. Omdat deze vraag ons natuurlijk in de kern raakt hebben wij met vele van u over het belang van meten binnen Agile trajecten gesproken. De tijd staat niet stil, zeker wat betreft softwareontwikkeling. Maar hoe past een organisatie zich daarop aan en waar moet men rekening mee houden?
Het belang & bestaansrecht
Verschillende meningen doen hierover de ronde. Het is niet zozeer de vraag zelf, maar juist vanuit welke invalshoek deze gesteld wordt en met welk belang. Er zijn altijd belanghebbenden die zich op enig moment tijdens een IT-ontwikkelingstraject afvragen of het budget, de bemensing en doorlooptijd voor een programma of portfolio voldoende is en of het wel op een juiste manier wordt ingezet en besteed. Dus ja, het bestaansrecht om te blijven meten is er zeker. Tijdens gesprekken binnen mijn netwerk wordt dit ook alsmaar weer bevestigd. Zoals laatst bijvoorbeeld toen een IT Controller mij vertelde: “Wij hebben 600 IT medewerkers, dat kost bij elkaar een hoop geld, natuurlijk willen wij weten wat hiermee gebeurt en waar we verbeteringen kunnen aanbrengen”.
Agile teams hebben uiteindelijk ook belang en baat bij het meten en inschatten van hun IT-trajecten. Ook zij zullen zich op enig moment toch moeten verantwoorden dat ze efficiënt en marktconform werken. Hoewel het Agile werken ontwikkelaars in staat stelt om ontwikkelingen naar eigen hand te zetten, hebben zij, naast het achteraf verantwoorden, ook een belang om vanaf de start de juiste en haalbare verwachtingen te scheppen. De prioriteiten van de Agile teams zijn echter vooral op het interne voortbrengingsproces gericht. De teams zijn tegenwoordig vaak prima in staat zijn om hun eigen sprints in te schatten en de voortgang daarvan zelf te meten en te beheersen. Het realiseren van kort cyclische sprints en waarde creatie voor de business staat echter voorop.
Haalbaarheid & risico’s
De traditionele manier van meten wordt door de teams vaak als ballast gezien. Het ontwikkelproces en de gegevens sluiten niet meer goed aan bij elkaar. Ontwerpen ontstaan tijdens de sprints en zijn niet meer vooraf beschikbaar om het gehele programma in te kunnen schatten.
Dus traditioneel of Agile, de vraag blijft voortbestaan. Hoe realistisch zijn de gemaakte plannen en met welke risico’s moet men rekening houden om niet af te wijken van de originele strategie? Het vooraf inschatten van de haalbaarheid en risico’s die gedurende het traject op kunnen spelen en hoe men daar op het moment suprême een positieve draai aan kan geven, zelfs binnen Agile opererende teams, blijft voortbestaan. Dit geldt voor diverse bedrijven en organisatie, maar vooral ook voor interne- en externe leveranciers. Want zij zijn o.a. juist diegenen die zich (periodiek) moeten verantwoorden.
De rol van PMO binnen Agile organisaties
Met de overgang van een traditionele ontwikkelomgeving naar een meer Agile georiënteerde organisatie heeft daarmee een verschuiving van verantwoordelijkheden en functies plaatsgevonden. Traditioneel werd een Project Management Office (PMO) ingericht om de projectteams te helpen bij het verantwoorden van projectplannen en het bewaken van de voortgang. Een belangrijk deel van deze traditionele PMO-taken worden nu door de Agile teams zelf uitgevoerd. Echter wel met eenheden die voor de teams van belang zijn, maar niet direct bruikbaar om de vragen buiten de teams te beantwoorden. De traditionele PMO kan deze vertaalslag prima maken.
Door vergaande automatisering van het ontwikkelproces neemt de snelheid waarin wijzigingen in software worden doorgevoerd en in productie gebracht toe (Devops). Dit maakt het soms een uitdaging om de benodigde gegevens te verzamelen zonder de Agile teams hier te veel mee lastig te vallen. De Agile manier van meten Het is duidelijk dat het meetproces zich moet aanpassen aan het veranderde ontwikkelproces. Met de komst van Agile is het verzamelen van gegevens lastiger geworden. De ontwikkelcycli zijn dermate kort dat de traditionele manier van documentatie vergaren tijdrovend is en een grote inspanning vergt. Bovendien wordt de ontwerpdocumentatie, die in het verleden vaak vooraf werd gemaakt en traditioneel als basis diende voor het meetproces, steeds vaker tijdens het ontwikkelproces of helemaal niet wordt gemaakt.
Agile teams focussen zich op het voortbrengingsproces van softwareontwikkeling en waarde toevoeging aan de business. Vragen ten behoeve van het meten voor de verantwoording buiten het team wordt dan ook vaak als storend ervaren. Het verzamelen van gegevens moet hoe dan ook anders. De oplossing ligt in een combinatie van de traditionele aanpak én de extra gegevens die de Agile manier van werken ons biedt. De Agile manier van werken biedt een schat aan alternatieve gegevens met zich mee. Gegevens die bovendien door de teams zelf in geautomatiseerde systemen worden vastgelegd. Een PMO medewerker kan deze Agile-gegevens kalibreren met behulp van meer genormaliseerde gegevens om hiermee ontwikkelingen vooraf, tijdens en na realisatie op marktconformiteit te toetsen.
Meeteenheden in alle soorten en maten
Voor de bepaling van de omvang van IT-trajecten worden verschillende meeteenheden gebruikt worden, zoals: Epics, Stories, Storypunten, Use cases, Requirements, Backlog items, Coderegels etc. Deze alternatieve eenheden zijn bruikbaar om vooraf te kunnen schatten, tijdens het project de voortgang te monitoren en om achteraf de productiviteit vast te stellen.
De hiervoor genoemde alternatieve eenheden zijn niet industrie breed gestandaardiseerd en kunnen per ontwikkelteam sterk verschillen. Het is dan ook nodig om deze eenheden per ontwikkelteam zowel initieel als ook periodiek te blijven kalibreren, zeker als de benchmarkuitkomsten daar aanleiding toe geven. Er zijn ondertussen wel genoeg historische gegevens over omvang, inspanning, doorlooptijd en kwaliteit beschikbaar in onze database om per alternatieve eenheid een marktgemiddelde en een bandbreedte vast te stellen.
Meten ten behoeve van de gehele organisatie
Meten is noodzakelijk, niet alleen voor de toezichthouders buiten de Agile teams, maar ook voor de Agile teams zelf om vooraf een goede verwachting af te kunnen geven en om zich achteraf te kunnen verantwoorden. De Agile manier van werken biedt aantrekkelijke nieuwe mogelijkheden om snel en met weinig impact op de teams de benodigde gegevens te kunnen verzamelen. Kalibreren van deze gegevens is iets waar metrieken experts traditioneel erg goed in zijn. Bovendien zijn er technieken om deze specifieke informatie op maat aan de verschillende stakeholders te leveren beschikbaar.