Bonus-malus regelingen zijn vaak onderdeel van een contract. De malus wordt ingezet om ervoor te zorgen dat de prestatie van een leverancier niet onder een afgesproken minimum valt. De bonus om ervoor te zorgen dat de leverancier zijn focus legt op de zaken die voor zijn klant belangrijk zijn.

Past straffen en belonen echter wel in een Agile manier van werken? In deze blog wil ik aan de hand van een typisch voorbeeld binnen software-ontwikkeling, toelichten binnen welke condities een bonus-malus werkt.

Onderdeel van een contract

Daarbij ga ik uit van het volgende voorbeeld: Een organisatie moet voldoen aan een nieuwe wet, die op 1 januari ingaat. Met leverancier moeten afspraken gemaakt worden over het aanpassen van een IT-systeem om te kunnen voldoen aan die nieuwe wetgeving.

Samen met je leverancier is er een backlog van features opgesteld . Naast het realiseren van de features is ook het verbeteren van de code-kwaliteit van de software onderdeel van het contract.

In dit voorbeeld zien we een aantal mogelijkheden voor het toepassen van een bonus-malus regeling. We zouden een “beloning” kunnen definiëren op halen van de doelstelling om de wet te ondersteunen op 1 januari, een “beloning” op het verbeteren van de code-kwaliteit en een “boete” op het niet op tijd opleveren van de afgesproken features. Op deze manier hebben we de belangrijkste performance indicatoren ondersteund met een financiële component.

De vraag is of de bonus-malus afspraken maken dat de leverancier de voor de klant beste aanpak gaat kiezen?

Het antwoord ligt genuanceerd; naarmate er meer vertrouwen is tussen de partijen en in de relatie meer aandacht is voor billijkheid, autonomie, reciprociteit, eerlijkheid en integriteit gaat de bonus-malus beter zijn werk doen.

Vertrouwen is essentieel

In een Agile aanpak waarbij het vertrouwen tussen beide partijen laag is, gaat een bonus-malus niet werken. Ofschoon het belang wat aan een bonus-malus in dat geval wordt gehecht, als hoog wordt gepercipieerd. Ik geef een voorbeeld:

Een leverancier die de samenwerking onvoldoende respecteert, zal zijn marge willen optimaliseren en met minimale inspanning het maximale uit het contract halen. Deze leverancier plukt het laaghangende fruit, zonder mee te denken over het eindresultaat voor de klant.

Eindgebruikers zijn in zo’n geval ontevreden over de oplossing, maar contractueel zijn de features binnen de termijn opgeleverd. Er zouden veel incidenten kunnen zijn, maar de code-kwaliteit is door slimme aanpassingen met 10% gestegen en de bonus daarmee binnengehaald.

Een klant die de samenwerking niet respecteert, zal eigen doelstellingen voorop stellen. In ons voorbeeld kan de leverancier voorstellen om de eerste maand te werken aan de code-kwaliteit, zodat in de daaropvolgende periode sneller ontwikkeld kan worden. Als de klant ervoor kiest om enkel te focussen op het zo snel mogelijk realiseren van features om de deadline zeker te stellen, zal de leverancier niet in staat zijn om de bonus voor optimaliseren code-kwaliteit binnen te halen.

Het blijkt dat alleen als er voldoende vertrouwen is, en over en weer en de relatie wordt gediend, de bonus-malus regeling gaat werken.

Samenwerking tussen klant en leveranciers is één van de waarden van Agile. Transparantie is één van de drie pilaren waarop Scrum aanpak is gestoeld. Vanuit de klant dient voldoende transparantie geboden te worden over de gewenste resultaten en effecten van de gerealiseerde dienst. Vanuit de leverancier worden keuzes over de oplossing en de effecten daarop op benodigde resources en de output inzichtelijk gemaakt.

In onderling overleg gaan ze op zoek naar de optimale balans om met optimale inzet van resources maximaal effect te sorteren.

Bonus malus als stuurinstrument

Een bonus malus is een stuurinstrument wat geïntroduceerd is bij meer traditionele aanpakken. Het doel daarvan was om de leverancier de pijn (en winst) te laten voelen zodat deze de tijd ‘onder water’ goed besteedt.

In een Agile aanpak wordt er geen tijd ‘onder water’ besteed, door voortdurende samenwerking en gezamenlijke review momenten. Toch kan binnen een Agile samenwerking, het toepassen van een bonus-malus constructie focus geven op de doelstellingen die je gezamenlijk wilt bereiken. Daarmee vormen ze naar mijn idee een geschikt instrument om prestatie-doeleinden met een financiële component te ondersteunen.

Webinar Agile Contracting terugkijken

Wil je meer weten over Agile Contracting? Bekijk dan hier de webinar die Ruud Bruls heeft gegeven of lees de blog over Agile vs. contract, gaat het samen?

Ook interessant

Meer weten?

Wilt u hier meer over weten, dan kunt u bij inspearit en/of cibit academy daarvoor terecht. Bel daarvoor 030-2308900 of stuur een mail naar info.nl@inspearit.com.

Ruud Bruls is een pragmatische coach met veel ervaring in software ontwikkeling en aansturing van software ontwikkeling. Hij overziet situaties en weet knelpunten op te lossen door vanuit zijn ervaring praktische werkwijzen in te brengen in de teams. Hij helpt anderen inzicht te krijgen in hun persoonlijke motivatie om hun persoonlijke belangen zoveel mogelijk in lijn te brengen met het leveren van de beste bijdrage voor de organisatie.

Heeft u een vraag?

Neem contact op