productiviteitsmetingen benchmark software ontwikkeling

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 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?

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 u een kijkje in onze keuken aan de hand van een praktijkvoorbeeld.

Hetzelfde recept, twee teams, verschillende productiviteit
Binnen een organisatie werken twee ontwikkelstraten aan software voor één specifiek eindproduct. Het ene team werkt voor eindgebruiker A en het andere team voor eindgebruiker B. De problematiek waar ze tegen aanlopen is identiek, ze gebruiken hetzelfde technische platform en dezelfde ontwikkeltaal. Voor beide teams zou men verwachten dat ze hetzelfde presteren. Dit blijkt na onze metingen niet het geval. Ze scoren beiden boven marktgemiddeld maar team A scoort beter dan team B: Hoe komt dat? Dit biedt aanleiding om uit te zoeken, waar zitten de verschillen en hoe komt het dat de productiviteit per teams verschillen? Denk bijvoorbeeld aan werkwijze of samenstelling van de teams. Kortom, leer van elkaar en verbeter.

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.

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.

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.

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. Realtime software heeft gemiddeld gezien een lagere productiviteit, omdat het ingewikkelder is om te maken. Om een realtime-ontwikkelstraat toch te kunnen vergelijken met een ontwikkelstraat die webapplicaties bouwt, kijken we steeds naar hoe ver de gemeten productiviteit van het eigen marktgemiddelde ligt. Een realtime straat die zo bij de top 20% hoort doet het beter dan een webapplicatie die bij 40% van de referentieprojecten in de database boven zich moet dulden.

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. Bij straten met een goede of stijgende productiviteit kunnen best practices worden opgetekend en bij de minder presterende straten kan worden ontdekt wat niet goed werkt. Niet alle maatregelen werken even goed. Door de jaren heen hebben wij inzicht gekregen in welke maatregelen het meest effectief zijn. Welke factoren hebben de grootste invloed op de productiviteit?

Een productiviteitscijfer alleen is maar een getal. Vaak zijn er allerlei redenen aan te wijzen waarom de productiviteit is zoals hij is. Het is belangrijk om die context in kaart te brengen, zodat de gemeten productiviteit op waarde kan worden geschat. Als we begrijpen hoe een productiviteit tot stand is gekomen, kunnen we ook beter de juiste verbetermaatregelen of best practices te formuleren. Elke release heeft zijn eigen traject, verhaal en ‘smaak’ die de productiviteit beïnvloeden. Hoe volwassen is een team? Hoe ingewikkeld is de release? Wordt er goed samengewerkt? Hoe soepel verloopt de flow van business-wens naar werkende software? Wat waren storingsfactoren en wat speelde er tijdens de realisatie? Tijdens een gesprek met de teams achterhalen we deze informatie. Na oplevering van een release blikken we terug op wat er goed gaat en wat beter kan. Door reflectie op de release zijn de teams in staat zelf sturing te geven aan verbetering van toekomstige sprints.

Ik vraag teams naar wat er speelde in vier categorieën van factoren, waarvan we weten dat ze veel invloed hebben op de productiviteit:

Mensen en kennis
Complexiteit van de release
Methode en processen
Techniek en tooling

De mensen in een team zijn misschien wel de belangrijkste component in de productiviteit. Van groot belang is het kennis- en ervaringsniveau van de teamleden. Hoe ervaren zijn de teamleden in de beoefening van hun vak? Hoe ervaren zijn ze in het probleemdomein? Het is duidelijk dat een ervaren ontwikkelaar efficiënter en effectiever werkt dan een junior. Uitloop kan zelfs worden veroorzaakt door één persoon die veel vragen stelt en steeds alles ter discussie stelt en daarmee veel extra overleg in de hand werkt. Stabiliteit speelt eveneens een grote rol. Veel verloop creëert onrust binnen het team. Door uitstroom gaat kennis verloren en nieuwe instromers moeten worden ingewerkt.

Niet alleen de kwaliteit van het team is een belangrijke factor. Ook de materie waaraan zij werken is belangrijk. Hoe complexer het probleem is, des te meer tijd kost het om de oplossing te realiseren. Die complexiteit kan veroorzaakt worden door verschillende zaken. Een release kan complex zijn doordat de business een nieuw probleem poneert waarover in het verleden nog niet is nagedacht. De oplossingsrichting moet dan nog bedacht worden. Een andere oorzaak kan zijn dat het probleem fundamenteel ingewikkeld is en alleen met gecompliceerde algoritmes kan worden opgelost. De ontwikkeling van een functie met ingewikkelde algoritmes en logica achter de schermen kost vanzelfsprekend meer tijd om uit te werken dan eenvoudige bevragingen van een database of cosmetische wijzigingen. De complexiteit van een probleem is ook terug te zien in de niet-functionele eisen aan een systeem. Deze dragen niet direct bij aan de functionaliteit maar kosten achter de schermen veel tijd om op orde te maken.

Een derde belangrijke categorie betreft de methoden en processen waarmee het werk wordt uitgevoerd. De ontwikkelmethode moet passend zijn bij het type software dat wordt ontwikkeld en de methode moet ook op een effectieve manier worden toegepast. Werkt men scrum/agile, volgens de watervalmethode of betreft het continuous delivery? Zijn er dagelijkse stand-ups? Werkt men met één team in dezelfde ruimte, verspreid door het gebouw of zelfs over verschillende tijdszones? De softwareontwikkelprocessen moeten goed zijn ingericht en soepel verlopen. Hoe goed wordt er samengewerkt en zijn de processen op elkaar afgestemd? Is er voldoende capaciteit om user stories uit te werken of moeten ontwikkelaars hierop wachten? Worden testresultaten snel genoeg teruggekoppeld? Dit gaat niet alleen over de processen binnen het team, maar zeker ook de processen die de grenzen van het ontwikkelteam overschrijden. Denk aan de afstemming van wensen met de business, besluitvorming door management, overdracht van software aan beheer.

Tot slot is de mate van automatisering van het team zelf van grote invloed op de productiviteit. Over welke tooling beschikt een team om processen te automatiseren en te ondersteunen? Te denken valt aan tooling voor het managen van requirements en backlogs, configuratiemanagement, versiebeheersystemen en geautomatiseerd testen. Zeker in een agile ontwikkelstraat, waar vaak software wordt opgeleverd, levert het tijdsbesparingen op om over te stappen op automatisch testen. Met één druk op de knop is het uitvoeren van tests een kwestie van minuten/uren in plaats van dagen/weken. Daarnaast is ook de onderliggende techniek van het ontwikkelplatform relevant. Wordt het team geholpen door de techniek of er juist door gehinderd? Hoe stabiel is het ontwikkelplatform, het netwerk? Hoe omslachtig is het om een build voort te brengen? Hoe makkelijk is het om een testomgeving op te zetten voor een ontwikkelaar? Hoe representatief is de acceptatieomgeving voor de uiteindelijke productieomgeving? Met de juiste technische ondersteuning kan een team efficiënter zijn werk doen, wat gunstig is voor de productiviteit.

Uiteraard blijft de inventarisatie niet beperkt tot de oorzaken van de behaalde productiviteit. Tegelijk met de oorzaken worden ook mogelijke maatregelen besproken. Zowel oorzaken als mogelijke maatregelen worden met de rapportage onder de aandacht van het management gebracht. De maatregelen worden opgenomen op de backlog van het team. In overleg met business en IT-management krijgen de backlog-items een prioriteit.

De kwaliteitskeuken
Een ontwikkelstraat scoorde qua productiviteit gedurende een aantal jaar consistent boven het marktgemiddelde, tot aan eind 2018. De eerste meting in 2019 scoorde ineens lager dan het marktgemiddelde en de tweede meting in 2019 nóg lager. De productiviteit daalde met iedere meting die wij uitvoerden. Met het inzetten van deze beweging bewezen onze metingen dat er iets bijzonders aan de hand was. Reden om met het team om tafel te gaan en naar een verklaring te zoeken. Het team herkende de problematiek. Bij elk van de hierboven genoemde vier categorieën, die van belang zijn voor de productiviteit, was er iets gaande. Dit gaf een duidelijke verklaring voor de ingezette daling waardoor de klant gericht verbeteringen kon doorvoeren.

Een QSM-productiviteitsmeting geeft een objectief oordeel over de gerealiseerde productiviteit. Het resultaat kan onderling én met de markt vergeleken worden. Hierdoor weet u hoe goed uw softwareontwikkeling het doet en of deze verbetert. Met de kennis en ervaring van meer dan 13.000 projecten die QSM inbrengt weten wij bovendien gericht de belangrijkste redenen achter de behaalde productiviteit te achterhalen, eventuele verbetermaatregelen te formuleren of leermogelijkheden te identificeren voor andere teams in uw organisatie. Een gedegen bespiegeling van hoe de werkvloer het ervaart, wordt door ons omgezet in een objectieve meting met uitgebreide analyse. Dankzij herhaling van de metingen krijgt u zicht op de ontwikkeling van de productiviteit en kunt u tijdig en doelmatig ingrijpen.

productiviteitsmetingen benchmark software ontwikkeling

Benchmark en optimaliseer software ontwikkeling

Productiviteitsmetingen – een kijkje in de keuken van QSM

Verbeter-initiatieven – met de juiste smaakmakers

Benchmark – inzicht in eigen performance

Productiviteit en kwaliteit

Marktgemiddelde als benchmark

Welke ingrediënten beïnvloeden productiviteit?

Mensen en kennis

Complexiteit van de release

Methoden en processen

Techniek en tooling

Oorzaken en maatregelen

Kortom

“De jaarlijkse QSM-productiviteitsmetingen geven richting aan interne verbetertrajecten. Ook onze lange termijn commitment resulteert in een efficiëntere samenwerking.”

Meer weten?

Krijg weer Grip op IT

Spread the word. Share this post!