Elke IT-organisatie is benieuwd of geleverde prestaties voldoen aan de vooraf gestelde verwachtingen en doelen. Regelmatig krijgen wij hier vragen over vanuit de business en vanuit ontwikkelteams zelf. Men wil bijvoorbeeld de productiviteit van softwareontwikkeling meten om KPI’s te bewaken. Of om inzicht te krijgen en richting te bepalen voor de te stellen prioriteiten, het nemen van maatregelen of om knelpunten op de agenda van het management te krijgen. Uiteindelijk heeft het merendeel van de organisaties behoefte om antwoord te krijgen op de vragen: Wat is onze productiviteit en hoe presteren we ten opzichte van de markt en het afgelopen jaar? En als we dit over enkele jaren blijven meten, zien we dan ook daadwerkelijk productiviteitsverbeteringen?
Productiviteitsmetingen – een kijkje in de keuken van QSM
QSM voert al decennia benchmarks uit om organisaties inzicht te geven in hun productiviteit. Wat is er eigenlijk voor nodig om een objectief en onafhankelijk benchmarkrapport samen te stellen? Wat heeft een klant hieraan en welke inzichten levert het hem? In deze blog bied ik: Bert de Vries, Senior Consultant bij QSM Europe, u een kijkje in onze keuken aan de hand van een praktijkvoorbeeld.
Verbeter-initiatieven – met de juiste smaakmakers
Enkele jaren geleden heb ik een pilot uitgevoerd bij een organisatie in de transportsector. De organisatie had als KPI om een marktgemiddelde productiviteit te behalen in haar softwareontwikkeling. De pilot moest duidelijk maken of dat ook gebeurde en moest richting geven aan eventuele verbetermaatregelen: de quick wins aanwijzen. Immers, voor een ontwikkelstraat waarin het slecht gaat zijn verbeteringen op korte termijn relatief makkelijk te realiseren. Straten die het al goed doen hebben meer tijd en inzet nodig om nóg beter te presteren. Nu, enkele jaren later, stellen wij jaarlijks met diezelfde klant opnieuw vast welke ontwikkelstraten er gemeten moeten worden en hoeveel metingen per straat er plaats gaan vinden. De uitkomsten van deze productiviteitsmetingen bieden inzicht in welke verbeter-initiatieven mogelijk zijn. Toevoeging van de juiste smaakmakers stelt de organisatie in staat om heel effectief invloed uit te oefenen op de eigen productiviteit.
Benchmark – inzicht in eigen performance
Met het management wordt vastgesteld welke ontwikkelstraten er gemeten gaan worden. Daarna gaan wij in gesprek met de softwareontwikkelteams om te achterhalen welke releases er het komende jaar op de rol staan en welke we daarvan gaan meten. Welke releases worden gemeten hangt voornamelijk af van de eventuele risico’s en van de mate van belangrijkheid voor de organisatie. Ontwikkelstraten waarbij de productiviteit de afgelopen periode gedaald is, krijgen meer aandacht dan de straten die consistent goed presteren. Uiteindelijk beslist het managementteam wat er gemeten wordt.
Na oplevering van iedere release begint de daadwerkelijke uitvoering van een QSM-projectbenchmark. Hiervoor hebben we informatie nodig over de release of het project dat wordt gemeten. Het ontwikkelteam levert daarom input met betrekking tot:
- het type applicatie (webapplicatie, transactioneel, systeemsoftware, realtime, e.d.);
- de ontwikkelomgeving waarin gewerkt wordt (Java, C#, Cobol, combinatie, e.d.);
- de functionele documentatie van de te meten release (epics en user stories);
- de start- en einddatum van de release;
- de bestede uren voor functioneel ontwerp, programmeren, testen en aansturing.
Om de productiviteit te berekenen brengen we omvang, doorlooptijd en inspanning met elkaar in verband. Daarvoor gebruiken we onderstaande formule: de software equation. Hierin is te zien dat productiviteit meer behelst dan uren per functiepunt (een veel gebruikte, maar beperkte eenheid om productiviteit uit te drukken). Ook de doorlooptijd van een release heeft namelijk veel invloed op de gerealiseerde productiviteit. De exponenten maken duidelijk dat softwareontwikkeling zich niet lineair gedraagt. Bijvoorbeeld een dubbele hoeveelheid functionaliteit vergt niet twee keer zoveel inspanning en doorlooptijd.
Figuur 1. De software equation geeft uitdrukking aan het niet-lineaire karakter van softwareontwikkeling en de grote invloed van doorlooptijd op de andere factoren
Productiviteit en kwaliteit
Vanzelfsprekend nemen wij kwaliteit ook mee in de beoordeling van de productiviteit. We meten steeds de realisatie van software die van goede kwaliteit is, welke door de opdrachtgever geaccepteerd wordt en in productie genomen wordt. Immers, als blijkt dat na oplevering te veel fouten worden gevonden, dan is de software eenvoudigweg te vroeg opgeleverd. Er is dan onvoldoende tijd besteed aan het testen en oplossen van fouten en de realisatie is eigenlijk nog niet afgerond. Dit zou een geflatteerde productiviteit geven, omdat niet alle inspanning en doorlooptijd wordt meegeteld die wel nodig is om de juiste kwaliteit te behalen.
Marktgemiddelde als benchmark
Nadat de productiviteit is uitgerekend vergelijken we deze met het marktgemiddelde, dat we kennen middels onze database. In deze database hebben we gegevens opgenomen van afgeronde softwareprojecten die we door de jaren heen hebben verzameld. Als we deze gegevens in een spreidingsdiagram weergeven, dan verschijnt een wolk van datapunten. Met behulp van statistieken kunnen we een trendlijn dwars door die wolk definiëren, zodanig dat de afstand van alle punten tot die lijn zo klein mogelijk is. Deze trendlijn representeert het marktgemiddelde. De spreiding van punten in de wolk wordt uitgedrukt in sigma (standaarddeviatie). Verschillende applicatietypes hebben hun eigen marktgemiddelde. Dit is logisch, omdat de realisatie van realtime software nu eenmaal meer doorlooptijd en inspanning vergt dan het bouwen van een webapplicatie.
Én we vergelijken de productiviteit van ontwikkelstraten niet alleen met de markt, maar ook tussen straten onderling en door de tijd heen. Hiermee wordt duidelijk welke straten het goed doen en welke minder goed. Bovendien wordt duidelijk of straten zichzelf verbeteren of dat de productiviteit juist afneemt. Alle vergelijkingen bieden inzicht en mogelijkheden om te leren en de algehele productiviteit te verbeteren.
Lees hier meer over welke vier ingrediënten nu eigenlijk de productiviteit beïnvloeden en ontvang tips voor een optimale productiviteit van uw softwareontwikkeling teams.
Beste SQM,
Dank voor het delen van het bericht.
Als het over productiviteit in built & change gaat, is low-code ook een strategie wat jullie adviseren?
Deze cijfers zijn in veel gevallen vele malen hoger dan traditioneel code kloppen.
Hoor het graag even.