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!