De kosten meten van change versus run binnen agile teams

Auteur(s): Harold van Heeringen

De kosten meten van change versus run binnen agile teams

Bron: Harold van Heeringen (Metri) en AGconnect

De meeste CIO’s hebben de opdracht om zo veel mogelijk business value te leveren, via IT, tegen zo laag mogelijke kosten. De vraag dient zich dan aan: hoe meten we business value en over welke kosten hebben we het dan? Business value is een zeer lastig te meten concept, volgens velen zelfs onmeetbaar. Daar zijn gestandaardiseerde methodes voor. Harold van Heeringen wijst er echter op dat niet alleen de functionaliteit die wordt opgeleverd bepalend is voor de business value, maar dat de kwaliteit daarvan ook zeer sterkt meetelt in deze metingen.

Over het algemeen is men het er wel over eens dat het ontwikkelen, wijzigen en/of verwijderen van softwarefunctionaliteit in ieder geval een belangrijk onderdeel van het creëren van business value is, mits de gevraagde en geleverde functionaliteit daadwerkelijk waarde oplevert voor het bedrijf. De ontwikkelkosten bestaan onder andere uit werkplekken en ontwikkeltoollicenties, maar vooral ook uit de bestede uren van mensen. Hoewel het zeker interessant is om bijvoorbeeld via een benchmark te besparen op werkplekken en licenties, focust dit artikel zich vooral op de bestede mensuren.

‘Vroeger’ werden er projecten opgestart om softwarefunctionaliteit te ontwikkelen, tegenwoordig zijn het vaak de agile werkende teams die aan een product werken en die periodiek een werkende versie van het product ter beschikking stellen aan de gebruikers. Je zou kunnen stellen dat hoe meer nieuwe en gewijzigde functionaliteit in een softwareproduct wordt verwerkt, hoe meer waarde dit zou moeten hebben voor de organisatie. De vraag is dan: hoe productief zijn de teams?

Productiviteit

Productiviteit is een kengetal waarmee de verhouding tussen inspanningen en resultaten inzichtelijk wordt gemaakt. De universele definitie is output gedeeld door de input. In softwareontwikkeling is dit bijvoorbeeld een aantal eenheden geproduceerde software gedeeld door een aantal uren inspanning.

In veel industrieën is dit een van de belangrijkste stuurmetrieken. In de IT weet men echter meestal niet hoe productiviteit objectief en gestandaardiseerd gemeten kan worden. Men wil het vaak wel, maar weet niet hoe. De reden hiervoor is dat het vaak relatief eenvoudig is de input te meten van de teams: de uren die worden besteed aan de verschillende activiteiten. Het wordt echter als moeilijk beschouwd om de output van softwareontwikkeling te meten op een gestandaardiseerde, objectieve manier.

Veel organisaties denken dat de output van agile teams gemeten kan worden in story points. Story points zijn een superhandig middel en nuttig voor het team, maar het betreft een subjectieve maat om een groepsinschatting te maken voor de hoeveelheid uren die nodig zijn. Metrieken gebaseerd op story points kunnen daarom niet buiten het team worden gebruikt om te schatten of om de productiviteit te meten. Zonder een gestandaardiseerde outputmetriek is vergelijken moeilijk.

Lastig maar belangrijk

Productiviteit is daarom in veel organisaties lastig te meten over de teams heen. Veel CxO’s hebben geen idee wat de productiviteit is van hun teams en hoe deze zich verhoudt met de markt. Maar de productiviteit bepaalt wel voor een groot deel de business value die geleverd kan worden, gegeven een bepaald budget. Het meten, vergelijken en verbeteren van de productiviteit van de teams is daarom een zeer belangrijke managementtaak.

Met formal-sizingtechnieken kan de functionele output van teams worden vastgesteld volgens ISO-gecertificeerde methoden, zodat teams onderling en met de markt vergeleken kunnen worden. Deze methode is al decennialang in gebruik en er zijn inmiddels veel data beschikbaar van gestandaardiseerde productiviteitscijfers in vrijwel alle technologieën. De standaard agile team performance metrics die worden gemeten en gebenchmarkt, zijn gebaseerd op de gerealiseerde functionele omvang: productiviteit, cost efficiency, delivery speed en sprint quality.

Metri Business Value

Business value

In de praktijk bevat het werk van agile teams meer dan het ontwikkelen van functionaliteit. In de bovenstaande figuur wordt duidelijk dat in de eerste sprint nog volop aan de functionaliteit kan worden gebouwd, maar dat naarmate er meer sprints zijn uitgevoerd, ook andere werkzaamheden de kop opsteken: de rode blokken. Daar waar de blauwe blokken te maken hebben met het creëren van businesswaarde, zijn de rode blokken weliswaar belangrijk, maar leveren deze niet direct zichtbare business value op.

Als er bijvoorbeeld een hoge-prioriteitincident optreedt door een probleem in de code, dan moet die code snel gerepareerd worden. De business vindt echter dat het incident nooit had mogen voorkomen. Onafhankelijk van de mate van volwassenheid van het team geldt dat hoe meer rode blokken er zijn en hoe groter deze rode blokken zijn, hoe lager de productiviteit is en hoe minder zichtbare business value geleverd kan worden. Er is echter een uitzondering hierop.

Kwaliteit

Bovenstaande figuur laat zien dat ook de kwaliteit van de applicatie belangrijk is. Een hoge productiviteit gaat soms ook gepaard met een steeds lager wordende kwaliteit van de applicatie, soms tot een punt waar in een of meerdere sprints moet worden gewerkt om de onderhoudbaarheid weer op peil te brengen. Binnen onze Agile Team Performance Monitor (ATPM)-metingen zien we dit vaak terug. We meten de kwaliteit van de software op de aspecten onderhoudbaarheid, robuustheid, security, efficiency en overdraagbaarheid tegen alle gangbare internationale standaarden en best practices. Het gericht verbeteren van de kwaliteit leidt tot minder verstoringen en snellere oplostijden. Door te focussen op de juiste code refactoring, en dan met name gericht op de onderhoudbaarheid, wordt dat rode blok mogelijk tijdelijk wat groter, maar vervolgens worden de andere rode blokken kleiner, terwijl de blauwe blokken groter worden bij gelijk bestede uren. Het gericht oplossen van technical debt lijkt dus in eerste instantie uren te kosten die ten koste gaan van de doorontwikkeling, maar uiteindelijk zien we in onze onderzoeken dat dit uiteindelijk veel oplevert: meer business value voor hetzelfde budget, minder verstoringen, lagere runkosten en uiteindelijk meer tevreden gebruikers en medewerkers.

Een praktijkvoorbeeld van twee teams 

Het standaardteam waarin geen extra aandacht is voor technical debt management, realiseert bij gelijkblijvende productiviteit minder functionaliteit door de tijd heen, omdat er steeds meer tijd besteed wordt aan het oplossen van issues. Het team dat voldoende tijd besteedt aan het voorkomen van deze issues, wordt productiever en levert uiteindelijk meer business value, terwijl het aantal verstoringen lager is.

De change-versus-run-kostenbalans binnen agile teams is dus sterk afhankelijk van de kwaliteit van de applicatie. Het gericht verbeteren of in stand houden van de kwaliteit lijkt counterproductief, maar levert uiteindelijk de meeste business value.

Meer weten?

Spreek direct een specialist, neem contact op met Metri voor een snel en duidelijk antwoord:

Stel je vraag



Deel dit artikel:

Boeingavenue 251 - 1119 PD Schiphol-Rijk - Nederland - Tel + 31 20 655 1777