Search
  • Leon Bosma

FPA en Agile, is meten echt weten?

Updated: Mar 23

Nu Agile werken meer gemeengoed begint te worden, haken steeds meer 'oude' methodes er op aan. Zo ook het verschijnsel van Functie Punt Analyse (FPA). Steeds vaker klinkt de roep om FPA ook in Agile omgevingen en dan komt de vraag op of en, zo ja, hoe FPA in een Agile aanpak (nog) zinvol is.




Meestal begint de argumentatie van voorstanders van FPA in een Agile-omgeving op ongeveer dezelfde manier. Er wordt gesteld dat werken met Agile nog steeds betekent; "een werkend product opleveren binnen een afgesproken tijd en inspanning en met een afgesproken kwaliteit." Vanaf daar gaat de argumentatie op weg om te bewijzen dat FPA daarin een rol kan spelen.


Helaas is de premisse al onjuist. Immers, er wordt uitgegaan van een op te leveren product als doel van het project. Waarbij FPA wordt gebruikt als middel om te meten hoeveel 'product' een team oplevert.


In Agile werken is het uitgangspunt echter niet zoveel mogelijk 'product' in zo weinig mogelijk tijd. Het streven is juist zoveel mogelijk effect met zo weinig mogelijk 'product'. Immers, hoe minder er moet worden gemaakt om het gewenste effect te halen, hoe minder inspanning hoeft te worden geleverd en hoe eenvoudiger toekomstige veranderingen zijn.


Kortom, FPA meet iets dat binnen een Agile-aanpak niet langer van wezenlijk belang is. Of sterker nog, FPA heeft het risico contra-productief te worden in een Agile-aanpak. Het bevordert een focus op zoveel mogelijk produceren in plaats van een focus op zoveel mogelijk effect leveren. ("hoe meer ingewikkelde software in een uur hoe beter")


Niet uit het veld geslagen, betoogt de voorstander vaak daarna dat FPA een manier is om teams en leveranciers onderling te vergelijken bij een inkoopkeuze. Een dergelijke vergelijking kan alleen worden gemaakt als er vooraf een FPA van het gewenste product kan worden gedaan. En bovendien moeten de benchmarks van leveranciers en teams onderling vergelijkbaar zijn.


Een FPA kan alleen vooraf worden gedaan als er vooraf een oplossing (een product) is uitgedacht en (deels) ontworpen. Agile werkwijzen worden juist gekenmerkt door zeer beperkt ontwerp vooraf en een veel meer exploratieve wijze van realiseren van de oplossing. Kortom, er is niet zoveel te tellen in een Agile traject.

NB 1: tenzij er vooraf een ontwerp ligt, maar de vraag is dan hoe Agile het traject daadwerkelijk is.

NB 2: tenzij er wordt geteld per sprint/iteratie, maar de vraag is dan hoe zinvol FPA dan nog is om leveranciers te vergelijken.


Benchmarks van productiviteit van leveranciers en teams zijn alleen onderling vergelijkbaar als de omstandigheden waaronder de productiviteit is geleverd vergelijkbaar zijn. Dat vereist eerst dat verschillende leveranciers en teams een zelfde soort projecten met een zelfde soort oplossingen op een zelfde soort wijze hebben gerealiseerd. En vervolgens moet het aan te besteden project daarmee weer vergelijkbaar zijn. Agile werkwijzen worden juist ingezet in situaties die nieuw en innovatief zijn, waarin de oplossingen van gisteren misschien juist niet werken.


Kortom, FPA binnen Agile is een poging iets te vergelijken dat (voor een flink deel) onvergelijkbaar is. Nu kunnen er altijd metingen worden gedaan en getallen worden opgeleverd, maar de vraag is wat de informatieve waarde van die getallen dan werkelijk is.


Dan blijft natuurlijk wel de vraag openstaan; hoe gaan we op met inkoopkeuzes als we Agile willen werken (en FPA 'werkt niet')? En daar hebben we misschien wel de taaiste paradigma verandering door te maken.


Bij inkoopkeuzes gaat het 99 van de 100 keer om vraagstukken van contractoptimalisatie. Zo goed mogelijk afspreken wat er wanneer voor hoeveel geld geleverd zal worden en dat het liefst met de partij die het goedkoopst is. En vanzelfsprekend vastleggen wat er gebeurt als deze afspraken worden geschonden (bonus-malus, etc.)


Best Value Procurement is een poging om in dergelijke keuzes meer waardegestuurd te worden. Maar ook daar geldt nog steeds; goede afspraken vastleggen en afrekenen als van deze afspraken wordt afgeweken. En nog steeds; eerst worden leveranciers vergeleken en er wordt (telkens opnieuw) een leverancier gekozen per project.


Agile werkwijzen propageren juist een streven naar verandering; er moet (kunnen) worden afgeweken van afspraken om het uiteindelijk gewenste effect te kunnen halen. Zowel voor wat betreft het op te leveren product als voor wat betreft de wijze waarop dat product tot stand komt. Agile werkwijzen propageren juist een nauwe, langdurige samenwerking, vanuit de overtuiging dat samen leren leidt tot grotere verbeteringen en mooiere resultaten. Dus telkens nieuwe contracten met telkens nieuwe leveranciers zijn contra-productief.


De vraag is wellicht dus niet; hoe vergelijken we leveranciers, of hoe meten we productiviteit, maar hoe gaan we langdurige productieve Agile samenwerkingsverbanden aan?

4 views

Contact

Reactorweg 301

3542 AD Utrecht

​​

Tel: 06 3409 9944 - Sylvia van Immerseel

info@agileright.nl

www.agileright.nl

  • AR LinkedIn
  • Black YouTube Icon

© 2020 Agile Right B.V.