Beheer

IT beheer
Marionet

Zo manage je het duivelsvierkant in agile teams

Hoe je de wensen van agile teams en IT-control dichter bij elkaar brengt

9 augustus 2022

Hoe je de wensen van agile teams en IT-control dichter bij elkaar brengt

Er heerst nog steeds argwaan tussen agile teams en het hoger management. De aanpak waarmee veel agile teams ontwikkelen, zou gepaard gaan met onzekerheden waardoor managers het gevoel hebben niet 'in control' te zijn. Zij hebben de behoefte om te managen op Kwaliteit, Scope, Tijd en Geld, ziet Richard Sweer. Iets wat bij agile teams en Agile Release Trains niet gemakkelijk is. Of toch wel?

Het spanningsveld tussen agile teams enerzijds en de managers en IT-controllers anderzijds is een bekend fenomeen. Maar agile is here to stay. Het is niet meer weg te denken in de wereld van maatwerk softwareontwikkeling. Een agile manier van werken levert een hogere kwaliteit op en zorgt ervoor dat vaker deelopleveringen kunnen plaatsvinden. Daarnaast leidt de aanpak doorgaans tot meer tevredenheid onder de eindgebruikers.

Het is daarom een goede zaak de wensen van agile teams en die van managers dichterbij elkaar te brengen. Iedereen moet zich content voelen bij agile softwareontwikkeling. Agile teams die efficiënt hun ding doen in overleg met de business, terwijl het management grip houdt, eventueel bijstuurt en kan vertrouwen op de juiste (interne/externe) IT-leverancier is het ideaal. Dit is alleen mogelijk als voor iedereen vooraf duidelijk is hoe je de agile teams aanstuurt en monitort met behoud van het gedachtengoed van een agile werkwijze.

Het duivelsvierkant

Met goede afspraken is agile ook voor hoger management geen probleem

Duivelsvierkant fig 1

Er bestaat bij (project)management een wankel evenwicht tussen de vier onderling sterk samenhangende projectvariabelen Kwaliteit, Scope, Tijd en Geld. Men noemt dit ook wel het duivelsvierkant van projectmanagement.

De variabele Kwaliteit is niet-onderhandelbaar. Hierdoor blijven Tijd, Scope en Geld over als variabele indicatoren. De uitdaging is om vóór aanvang van de bouw van een IT-systeem goede afspraken te maken over de vier variabelen. Dit geldt vooral bij een agile werkwijze, waarbij het uiteindelijke resultaat in grote lijnen bekend is, maar niet de weg ernaartoe.

Het 4 KPI-model

Objectief kwantificeren is de basis van succes

Om vooraf concrete inschattingen en afspraken te maken over de Kwaliteit, Scope, Tijd en Geld van een IT-systeem, is het slim deze te kwantificeren. Dit kan door de KPI's en hun onderliggende metrieken te relateren aan de functionele omvang. De functionele omvang is een goede indicator voor de grootte en complexiteit van IT-systemen en dus ook voor de variabele Tijd, Geld en Scope. Je bepaalt de omvang met functiepunten, te meten aan de hand van ISO-standaarden, zoals ISO/IEC 24570:2018 NESMA. Hierdoor is het dus mogelijk om de voortgang objectief te kwantificeren.

Metrieken

De metrieken zijn in vier categorieën in te delen, in volgorde van belang: kwaliteit, tevredenheid, wendbaarheid en productiviteit.
Op basis van een uitgebreide vragenlijst kunnen de set en de waarden van de metrieken bepaald worden. Om grip en controle op agile teams te krijgen, moet men al snel denken aan een set van ongeveer 35 metrieken. Niet alle metrieken kunnen automatisch gemeten worden. Zaken als bestede uren, gevonden defects en het bepalen van de functionele omvang moeten handmatig bepaald worden. De overige metrieken kunnen op basis van de hedendaagse tools en technieken geheel automatisch gemeten worden. Meer informatie over metrieken: zie het eerdere artikel in AG Connect  “Agile: No grip no Glory” van september 2018 of  www.finidy.nl/publicaties

4 KPI-model toegepast op het duivelsvierkant 

Slechts drie indicatoren zijn onderhandelbaar

Zoals eerder aangegeven zou de Kwaliteit nooit onderhandelbaar moeten zijn in agile teams. Het moet altijd onderdeel zijn van de Definition of Done (DoD) dat een duidelijke omschrijving geeft van hoe een opgeleverde Product Backlog item er uit moet zien. We plaatsen Kwaliteit dan ook in het midden van onderstaande driehoek, waarvan de hoeken worden gevormd door Tijd, Geld en Scope.

Duivelsvierkant fig 2

Over deze drie prestatie-indicatoren (KPI’s) kan het team met de Product Owner onderhandelen, bijvoorbeeld door onderdelen sneller of goedkoper op te leveren of door ze uit te breiden met aanvullende functionaliteit (Scope). Dergelijke onderhandelingen gebeuren uiteraard in goed overleg met alle belanghebbenden.

Kwaliteit

De vier KPI’s Kwaliteit, Tijd, Geld en Scope bepaal je elk aan de hand van sub-indicatoren die telkens zijn gebaseerd op verschillende metrieken. Zo kun je de KPI Kwaliteit per software release onder meer ophangen aan een maximumaantal fouten per functionele omvang (Defect Density), aan de kwaliteit van de code (op basis van ISO 25010) en aan de gemiddelde oplostijd van geconstateerde fouten. De KPI Tijd bepaal je door een inschatting te maken van de functionele omvang, de uren per functiepunt die je moet besteden en het aantal Agile teams die je inzet.

Geld

Voor de prestatie-indicator Geld gebruik je een vaste prijs per functiepunt. Voor deze prijs per functiepunt maak je afspraken over diverse determinanten, zoals de functionele omvang, het kennisniveau, de aantal teams, de te gebruiken technologie, de complexiteit van de processen en het belang van niet-functionele vereisten.

Scope

Tot slot is er de KPI Scope, waarin je vastlegt welke functionaliteit het team per periode oplevert. Ook hierover kun je afspraken maken over het toevoegen, wijzigen en/of verwijderen van functionaliteit naar aanleiding van aangepaste wensen. Hierdoor blijft de flexibiliteit van het team geborgd, een belangrijke voordeel van de Agile werkwijze.

Door de Kwaliteit, Tijd, Geld en Scope indirect te relateren aan functiepunten en gebruik te maken van ISO-standaarden zoals ISO 24570, ISO 25010 en ISO 25023, kun je de voortgang van softwareontwikkeling al vroeg monitoren en bijsturen. Bijvoorbeeld bij de opstelling van de backlog, maar zeker tijdens refinements. Je kunt er ook mee vastleggen hoeveel functiepunten minimaal nodig zijn, voordat de eerste versie van het product kan worden live gezet als MVP (Minimal Viable Product). De functionele omvang is bovendien de beste indicator voor business value. Doorgaans bestaat er een duidelijke correlatie tussen hoeveelheid businessfunctionaliteit en business value. En daar draait het om in een Agile manier van werken.
 

Samenwerkingsmodellen

Verhoog de betrokkenheid en verantwoordelijkheid van de leverancier

Het succes van de inzet van prestatie-indicatoren en hun metrieken bij agile softwareontwikkeling is mede afhankelijk van wijze waarop de opdrachtgever en de leverancier samenwerken. Grofweg bestaan er vier sourcing typen, die variëren in de verdeling van risico's en betrokkenheid van de opdrachtgever en de leverancier.

  1. Time & Material: Opdrachtgever betaalt de leverancier op basis van de bestede uren. Risico ligt vooral bij de opdrachtgever.
  2. Time & Material met KPI's: Opdrachtgever betaalt de leverancier op basis van de bestede uren. Risico ligt nog vooral bij de opdrachtgever, maar op basis van de gemeten KPI’s kan er wel een goed onderbouwd gesprek plaatsvinden van de geleverde diensten, zeker als er vooraf bepaalde doelstellingen per KPI zijn afgesproken.
  3. Output-based sourcing: Opdrachtgever betaalt leverancier na oplevering van de in de Definition of Done (DoD) afgesproken kwaliteit en geleverde business functionaliteit (aan de hand van functiepunten). Hier ligt het grootste risico ten aanzien van budget- en tijdoverschrijding bij de leverancier.
  4. Outcome-based sourcing: Opdrachtgever betaalt leverancier na behalen van afgesproken omzet en winstmarges. Een bijzondere wijze van contracteren die niet in alle situaties toepasbaar is en zeker een hoog risicogehalte heeft voor de leverancier:
  • Geld              We spreken een vaste prijs per functiepunt af
  • Tijd                We spreken een vast aantal uren per functiepunt af
  • Kwaliteit        Allle kwaliteitsmetrieken worden onderdeel van Definition of Done
  • Scope            Meten we op basis van een ISO Functional Size Measurement                 standaard, zoals ISO/IEC 24570:2018 NESMA functiepunten

Output-based sourcing

Extra motivatie voor het beste team resultaat

Vooral het output-based sourcingmodel is interessant voor opdrachtgevers, doordat een relatief groot deel van het risico bij de leverancier ligt. Dit heeft als voordeel dat de leverancier extra is gemotiveerd om de werkzaamheden naar ieders tevredenheid af te ronden.

Om bij het output-based sourcingmodel te managen op de duivelsvierkant, zoals veel managers en IT-controllers graag doen, zijn de volgende punten van belang:

  • Tijd: Spreek een bonus/malus af op de doorlooptijd. Het team kan de doorlooptijd onder meer beïnvloeden door tijdige opschaling.
  • Geld: Spreek een prijs per functiepunt af. De opdrachtgever kan de kosten onder meer beïnvloeden door offshoring of door productieverbeteringen door te voeren. Met offshoring bespaart men gemakkelijk 50% van de softwaremaatwerkkosten.
  • Scope: Meet met functiepunten. Als je scope vermeerdert of vermindert, weet je de impact op Tijd en Geld.
  • Kwaliteit: Leg de kwaliteit vast op basis van metrieken en maak ze onderdeel van Definition of Done (DoD). Zorg ervoor dat Kwaliteit niet onderhandelbaar is.

Conclusie

  • De inzet van het 4 KPI-model neemt de argwaan tussen agile teams en hoger management weg.
  • Output-based contracteren kan voor de opdrachtgever vele voordelen bieden. Hiervoor is wel een bepaald volwassenheidsniveau noodzakelijk, zowel van de opdrachtgever maar vooral van de leverancier.
  • Mocht een output-based contract een ‘brug te ver zijn’, begin de samenwerking dan vanuit een contract gebaseerd op Time & Material met KPI’s. Na een kalibratieperiode van de KPI’s, waarin de waarde van de metrieken duidelijk worden, kun je een output-based contract overwegen op basis van deze nieuwe inzichten.

 

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (juli-augustus 2022). Wil je alle artikelen uit dit nummer lezen, zie dan de inhoudsopgave.

Lees meer over
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.