How to Measure Business Value for Agile Teams

Webinar | On-Demand

IT-teams die Agile hebben ingevoerd, profiteren van snellere leveringscycli en flexibelere systemen. Ondanks de verbeterde mogelijkheden die Agile bedrijven brengt, heeft IDC Metri, de leider in het helpen van organisaties om de volledige waarde van hun IT-functies te realiseren, ontdekt dat de meeste bedrijven een aanzienlijke sprong in de prestaties zouden zien als ze kwantitatieve beoordelingstechnieken zouden toepassen om Agile-inspanningen te beheren.

Bekijk de webinar om meer te leren over deze processen en hoe eenvoudig het is om ze te implementeren terwijl u strategische begeleiding krijgt rond:

  • Hoe voorspelbaarheid, controle en zichtbaarheid te krijgen in high-profile Agile projecten
  • Hoe het monitoren en beoordelen van Agile teams budgetten kan beheersen, leveringssnelheid en kwaliteit kan verhogen en een minimum viable product kan garanderen
  • Hoe het inbouwen van kwantitatieve prestatiemaatstaven in leverancierscontracten leidt tot betere kosten, kwaliteit en prestaties van externe ontwikkelpartners
  • Wanneer het schalen en leveren van Agile praktijken van vitaal belang is voor zakelijk succes, wilt u de inzichten van IDC Metri niet missen over hoe u uw bottom line beter kunt beïnvloeden door de volledige waarde van Agile ontwikkeling te realiseren.
Watch Webinar

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 IDC Metri voor een snel en duidelijk antwoord:

Webinar: Bouw snel uw roadmap voor digitale transformatie, gebaseerd op feiten!

Veel organisaties willen een digitale transformatie opstarten, maar weten niet goed waar te beginnen. Er is geen duidelijk overzicht op het applicatie portfolio en het is erg moelijk te bepalen wat te doen met welke applicatie. Het opbouwen van dit overzicht kost veel tijd en moeite, en is vaak gebaseerd op subjectieve meningen en niet op feiten. In dit webinar laat Metri zien hoe haar Application Portfolio Strategizer dienst in zeer korte tijd een op feiten onderbouwd inzicht krijgt in de kwaliteit, business impact, cloud readiness en de aan te bevelen transformatie strategie per applicatie. Dit levert veel tijdwinst op en zorgt ervoor dat organisaties veel sneller de vruchten van de digitale transformatie kunnen plukken en daarmee succesvoller kunnen zijn.

Meer weten?

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

De revival van de functiepunt

Metri

Ik spreek met veel CIO’s en IT managers en ik merk dat veel van hen worstelen in dit ‘Agile’ tijdperk. Vaak hebben ze een groot aantal (zelfsturende) agile teams, en ontbreekt het hen aan grip. Als het om software ontwikkeling gaat bijvoorbeeld, hebben ze vaak geen idee welke functionaliteit er op welk moment klaar is, hoeveel dat dan werkelijk gekost heeft, wat de kwaliteit is en wat de risico’s zijn die de organisatie loopt met iedere nieuwe oplevering van software in het portfolio. Hoe groter het aantal teams, en hoe meer zelfsturend deze zijn, hoe moeilijker het wordt om het overzicht te houden. De teams werken vaak met door henzelf gedefinieerde Story Points om hun inschattingen te maken. Erg nuttig op teamniveau, maar het management heeft niets aan story point metrics, aangezien deze niet gestandaardiseerd zijn en niet gebruikt kunnen worden om teams te vergelijken.

Echte Agilisten zeggen misschien: “Dat hoort erbij, vertrouw op de teams”, maar de ‘echte wereld’ kent principes als accountability. Er gaat erg veel geld om in software ontwikkeling en beheer teams en er zijn mensen verantwoordelijk voor de juiste besteding van de budgetten, en hetgeen wat daarvoor wordt geleverd. Sterker nog, het snel kunnen leveren van nieuwe functionaliteit tegen lagere kosten dan de concurrent kan het verschil betekenen tussen een succesvol bedrijf en een bedrijf dat failliet gaat. Het management heeft behoefte aan solide management informatie, gebaseerd op standaarden, om inzicht te krijgen en om de juiste beslissingen te kunnen nemen.

Om applicatie dienstverlening te kunnen vergelijken is het vrijwel altijd nodig om de omvang van een applicatie of van een project vast te stellen. Voor Metri is dit cruciaal. Omdat we moeten kunnen vergelijken met andere organisaties, kunnen we hier alleen standaarden voor gebruiken. Aangezien de gebruikers normaal gesproken alleen geïnteresseerd zijn in de functionaliteit die hen wordt geboden, en niet in hoe die functionaliteit wordt geleverd (agile of traditioneel) of welke technologie er wordt gebruikt door de ontwikkelaars (Java, .Net, etc.), gebruiken we methodes om de hoeveelheid aan de gebruiker geboden functionaliteit te meten in een ISO/IEC omvangmaat: de functiepunt.

Veel lezers haken nu helaas af, want ja… functiepunten… dat deden we 30 jaar geleden al en zelfs toen werkte het niet. Nu in deze agile wereld kunnen we dat helemaal wel vergeten! Zeg het woord functiepunten tegen een willekeurige agile coach en hij zal je glazig aankijken en meewarig met zijn hoofd schudden. Blijft u toch nog even lezen alstublieft…

Functiepunt Analyse (FPA) is inderdaad in de jaren 70 ontwikkeld bij IBM, met als doel de productiviteit van de ontwikkelteams te meten. Omdat alleen de functionele user requirements worden gemeten, oftewel wat moet de software doen voor de gebruikers (niet hoe of waarom) is de methode onafhankelijk van de technische manier van ontwikkelen en van de manier waarop wordt ontwikkeld. FPA is daarmee de vierkante meter van de Software industrie. Een korte analogie: Of een muur van 20 vierkante meter nu wordt gebouwd met grote bakstenen, kleine steentjes, of in glas, aluminium of ander materiaal, de omvang in vierkante meters blijft hetzelfde. Dit is met functiepunten en de omvang van een bepaalde hoeveelheid functionele requirements exact hetzelfde. De kosten worden bepaald door de prijs per vierkante meter, en die hangen af van bijvoorbeeld de productiviteit van de metselaars en voegers en van de materiaalkosten.

Er is dus geen enkele reden waarom functiepunten niet kunnen worden gebruikt in de agile wereld. Sterker nog, de tegenwoordig gangbare user stories kunnen vaak heel eenvoudig nauwkeurig worden gemeten met FPA. Dit is met name van belang als het gaat om het begroten van software ontwikkeling. Ook in de agile wereld gaan veel software projecten mis: Het Minimum Viable Product (MVP) wordt niet binnen tijd en budget opgeleverd, en/of de technische kwaliteit is zo bedroevend dat daarna een inhaalslag moet worden gemaakt om de technische schuld te verminderen en de openstaande defects eruit te halen. Functiepuntanalyse is ook zeer geschikt om vroeg in de Project (of Product) Lifecycle een accurate begroting te maken van de kosten en doorlooptijd van het ontwikkelen van het Minimum Viable Product (MVP). Om dit te doen zet Metri gecertificeerde functiepunt analisten in om de omvang van de backlogs te meten. Daarnaast wordt professionele software cost estimation technologie ingezet, in combinatie met de Metri database waarin duizenden projecten zitten die zijn gemeten met functiepuntanalyse, om tot een accurate en goed onderbouwde begroting te komen.

Om echt grip te krijgen op de agile teams, zetten we de Agile Team Performance Monitor dienst in, waarbij de code kwaliteit gedetailleerd wordt vastgesteld, en waarbij de team performance in termen van Productiviteit (uren per functiepunt), Cost Efficiency (kosten per functiepunt), Delivery Speed (functiepunten per maand) en Project Quality (Defects per functiepunt) worden gemonitord en onderling en met de markt worden vergeleken. De binnen een sprint of release gerealiseerde functionaliteit meten we in Enhancement Function Points (EFP). Dit zijn het aantal functiepunten toegevoegd, gewijzigd en/of verwijderd in een bepaalde periode. Dit meten we handmatig, of op een geautomatiseerde manier. Op basis van de daadwerkelijk gerealiseerde Productiviteit en Delivery speed, kunnen dan de begrotingen worden bijgesteld op basis van de werkelijke performance.

Deze op functiepunten gebaseerde metrics geeft het management gedetailleerd inzicht in de trends in de performance van de teams en hoe deze teams presteren ten opzichte van elkaar en ten opzichte van de markt. Zie bijvoorbeeld de volgende figuur waarin de productiviteit is omgeslagen naar een index om deze onderling vergelijkbaar te maken en te vergelijken met de markt (1 is marktgemiddeld en bijvoorbeeld 1,12 is 12% boven marktgemiddeld).

Hoewel veel teams dit in eerste instantie vaak zien als een bedreiging, zien we juist ook dat ze gericht willen verbeteren en willen aantonen op de goede weg te zijn. Steeds vaker begrijpt men dat het gebruik van internationale standaarden en best practices een absolute noodzaak zijn om op organisatie niveau de juiste beslissingen te nemen.

CIO’s en IT managers krijgen weer grip op de teams en kunnen voorspellen welke functionaliteit op welk moment wordt opgeleverd tegen welke kosten en wat de kwaliteit van de applicaties is in combinatie met de te verwachten beheerkosten. En de teams kunnen hun professionaliteit bewijzen en gericht van elkaar leren. En dat allemaal dankzij de revival van de good old functiepunt, de vierkante meter van de software wereld!

Bent u klaar voor IT-dienstverlening uit meerdere keukens?

Soms, als ik lang in de wacht sta voordat ik eindelijk word ‘doorverbonden’, teken ik wat. Doedels heten die creaties volgens de moderne psychologie en ze schijnen wat te zeggen over je karakter. Mijn laatste doedels zeggen echter veel meer over de dienstverlening in de wereld van private- en public cloud oplossingen.

Ik tekende twee torenflats. Daartussen een iets te slap gespannen koord. Op het koord juristen, die fanatiek aan het stoeien waren op dat slappe koord. Hoe kwam ik erop om deze doedel te tekenen?

Even terug naar een eerder blog. Hierin pleitte ik voor een datacenter met nummerbehoud als een prachtige optie in de verdere standaardisering van cloud oplossingen. Dat klinkt helaas nog als toekomstmuziek. Echter, in de wondere wereld van private- en public cloud oplossingen is veel beweging en roering. Er wordt me wat gediscussieerd over voorwaarden, over beschikbaarheid, over data, connecties, combinaties en multi vendor oplossingen met gedeelde verantwoordelijkheden in vernieuwende eco-systemen en de complexe wereld die daarachter zit. Wat je vooral ziet is dat klanten de regie steeds meer richting de leverancier schuiven.

De leveranciers krijgen een steeds grotere rol in het afstemmen van diensten met de verschillende leveranciers aan een en dezelfde klant. Verschillende contractpartijen van een klant moeten gaan samenwerken om de totale dienstverlening voor de klant te realiseren zonder dat de klant de regie hierover moet voeren. Multi Vendor Management-initiatieven schieten uit de grond in een wereld die meer en meer aan het differentiëren is. Klanten verwachten een duidelijke verbetering in de gedeelde verantwoordelijkheid van de geboden services door de partijen. Denk hierbij bijvoorbeeld aan een wijziging binnen een applicatielandschap waarbij ook de infrastructuur aangepast dient te worden. De klant verwacht een werkende oplossing waarbij de verschillende leveranciers samenwerken, zonder tussenkomst van de opdrachtgever.

Dit alles vraagt nogal wat van de old school service integrators. Openheid van zaken in geleverde dienstverlening kunnen pijnlijk duidelijk gaan maken waar elkaars kwaliteiten liggen. Nieuwe samenwerkingsverbanden liggen in het verschiet. En uiteindelijk gaat het over het managen van risico’s en zo kwamen mijn doedels tot stand. Misschien verstandig om in deze discussie ook de klant mee te nemen, die zit namelijk in een van de torenflats die ik voor me zag.

Ik stond nog een tijdje in de wacht. Mijn gedachten dwaalden af naar vliegtuigen, mijn nieuwe doedel op mijn kladblok. Na jarenlange studies in de vliegtuigindustrie is namelijk gebleken dat vleugels die buigen veel meer kunnen dragen en langer meegaan. Door deze eyeopener is de veiligheid in de luchtvaart enorm verbeterd. Flexibele eco-systemen lijken op hun beurt de rechtlijnige processen in ego-oplossingen te buigen.

Toch ben ik benieuwd of de nieuwe ontwikkelingen een bijdrage gaan leveren in klantgerichte duurzame en betrouwbare oplossingen. De eerste stap in die richting lijkt gezet. Dat is het goede nieuws. De technologische ontwikkelingen van vandaag maken het mogelijk om verschillende kleinere oplossingen samen te voegen tot één geheel. Deze kleinere oplossingen kunnen ook geleverd worden door meer gespecialiseerde partijen. Het slim gebruiken van gestandaardiseerde en geaccepteerde ‘producten’ maakt gespecialiseerde dienstverlening mogelijk. Langzaam maar zeker ontstaat er een soort menukaart van IT-dienstverlening waarmee de maaltijd door de consument samengesteld kan worden. Van ster-kwaliteit tot foodtruck-niveau. Voor ieder wat wils. Leve de diversiteit. Als je maar wilt.

Langzaamaan krijgt de klant weer de regie over de benodigde oplossing waarbij de regievoering meer en meer naar de leveranciers verschuift. Multidisciplinaire dienstverlening uit verschillende keukens, bent u er klaar voor?