Het contract voor een Scrum project

De klant is bereid te tekenen voor de opdracht die met Scrum zal worden uitgevoerd. De klant ziet de voordelen van Scrum: Iedere twee weken een demo en de mogelijkheid bij te sturen. Voortschrijdend inzicht kan leiden tot nieuwe prioriteiten en nieuwe specificaties. Maar hoe leggen de partijen dit vast in een contract?

---

Een fixed priced, fixed date, fixed scope contract.

Dit de traditionele benadering. Een voorbeeld: De leverancier maakt een vluchtige schatting van de benodigde inspanning in uren op basis van de beschrijving van de klant van wat hij wil hebben. De manager van de schatters vermenigvuldigt het aantal uren met twee omdat de ervaring leert dat er altijd meer werk is dan initieel gedacht. Het management zet er 30% risicotoeslag bovenop omdat het risico nu eenzijdig bij de leverancier ligt. In het contract wordt opgenomen dat meerwerk wordt berekend tegen time-and-material tarieven.

Na twee sprints staat een rudimentaire versie van de applicatie live. Na de tiende sprint is de applicatie voldoende uitontwikkeld om in gebruik te worden genomen. Er is nieuwe functionaliteit bijgekomen waar aanvankelijk niet aan was gedacht. De stakeholders hebben in overleg met de product owner functionaliteit die in het contract staat naar achteren geschoven. Er is nog geen meerwerk in rekening gebracht. Er is alleen geschoven in prioriteit.

Tijdens de tiende sprint bekijkt de projectmanager met de product owner hoeveel werk er nog ligt. Meteen is duidelijk dat daar nog vijf sprints voor nodig zijn. Dat gaat meer kosten dan begroot. Er is nog ruimte voor twee sprints. Gelukkig is daar de meerwerk clausule. Maar dat gaat om werk dat al is gedaan. Er volgt een moeilijk gesprek met de klant. De klant is van mening dat de leverancier dit werk had moeten zien aankomen en op zijn minst van te voren overeenstemming had moeten bereiken over de meerkosten.

De klant-leverancier relatie is bekoeld. Dit heeft zijn weerslag op de samenwerking tussen de leveranciersteam(s) en de business vertegenwoordigers bij de klant. De projectmanager escaleert.

Er volgt overleg op het hoogste niveau. De directies trekken een hele middag uit om op de hei samen te zitten. Tijdens een presentatie van de leverancier blijkt dat veel, zelfs functionaliteit die tijdens de rit is ingebracht, gerealiseerd is. Besloten wordt om nog drie sprints uit te voeren waarvan de laatste extra in rekening mag worden gebracht. De features die onderaan de backlog staan, en dus de minste waarde hebben worden niet gerealiseerd. De kou is uit de lucht en het team haalt opgelucht adem. De klant krijgt de kern van wat was bedoeld, niet wat was gespecificeerd. Qua doorlooptijd, budget van de klant en winstgevendheid van de leverancier was het project een succes. Alleen, daarvoor was wel een crisis nodig en een stevige inzet van de projectmanager.

Maar wat als de klant vasthoudt aan alle in het contract opgenomen functionaliteit, als geen van de stakeholders wil toegeven?

Het scenario is dan: De projectmanager stelt een lijst op van alle functionaliteit die nog gemaakt moet worden en legt die voor aan het team en passeert daarmee de product owner. De projectmanager heeft berekend dat alles in drie sprints af moet zijn om nog uit de kosten te komen. De klant is akkoord dat geen nieuwe functionaliteit wordt aangenomen. Het team heeft geen zeggenschap over wat zij aankunnen in een sprint. Om af te krijgen wat de projectmanager verlangt worden concessies gedaan aan de kwaliteit. De moraal van het team daalt. De Scrum master geeft het op. Het testen wordt uitgesteld tot aan het einde van de laatste sprint. Om tijd te sparen worden er geen tussentijdse releases meer gedaan. Aan het eind van de laatste print blijkt dat er nog veel fouten zijn. Er wordt een weekend doorgewerkt om de fouten te herstellen. De applicatie gaat live. Na de livegang blijkt dat er niet alleen nog fouten inzitten maar dat meerdere stakeholders ontevreden zijn. Net die functionaliteit die zij nu echt belangrijk vinden zit er niet in.

Een alternatief: "Money for nothing, change for free"

Dit alternatief is gepresenteerd in 2008 door Jeff Sutherland. Zie deze slide show vanaf slide 25. De titel is een variatie op de titel van de Money for nothing, chicks for free song van Dire Straits.

Een voorbeeld: Ook deze klant wil vooraf een prijs afspreken maar is bereid het contract af te stemmen op de toepassing van Scrum met een bonus-malus contract.

De leverancier maakt een vluchtige schatting van de benodigde inspanning in uren op basis van de beschrijving van de klant van wat hij wil hebben. De manager van de schatters vermenigvuldigt het aantal uren met twee omdat de ervaring leert dat er altijd meer werk is dan initieel gedacht. Er wordt géén risico opslag berekend. In het contract wordt opgenomen dat de klant actief betrokken is bij het project en voor het begin van elke nieuwe sprint met de product owner vaststelt welke user stories nieuw zijn en welke user stories van een zelfde omvang kunnen komen te vervallen. Verandering is welkom maar de scope blijft gelijk. Dit is het principe van 'change for free'. Ook wordt afgesproken dat de klant vrij kan besluiten dat de volgende sprint de laatste is. In dat geval betaalt de klant de kosten van de gerealiseerde sprints plus 20% van de restwaarde van het contract. Dat is het principe van 'money for nothing'.

Na twee sprints staat een rudimentaire versie van de applicatie live. Na de tiende sprint is de applicatie voldoende uitontwikkeld om in gebruik te worden genomen. Er is nieuwe functionaliteit bijgekomen waar aanvankelijk niet aan was gedacht. Zoals contractueel afgesproken is dit ten koste gegaan van 'oude' functionaliteit die naar achteren is geschoven. De product owner ziet aankomen dat deze functionaliteit niet gerealiseerd kan worden voor het beschikbare budget. Hij overlegt met de opdrachtgever en besluit nog twee sprints te gaan voordat het project wordt afgesloten. De leverancier wordt gevraagd te berekenen wat de twaalf sprints totaal kosten. Van het gecontracteerde bedrag blijft nog een ton over. De leverancier krijgt 20k en de klant is 80k goedkoper uit dan begroot. En de applicatie is maanden eerder live dan gepland.

Nog beter: Samenwerking op basis van vertrouwen

De klant uit het vorige voorbeeld heeft nog een ander project dat moet worden uitgevoerd. Een voorbeeld: De klant heeft een duidelijke visie waar zij naar toe wil en een ervaren product owner die alvast een backlog heeft opgesteld waarin de user stories staan, gesorteerd naar business value. Het team dat de vorige opdracht heeft uitgevoerd bestaat nog. Aan het team wordt gevraagd een inschatting in story points te maken van de bovenste helft van de backlog. Klant en leverancier weten dat het team gemiddeld 100 storypoints per sprint aankan. Voor de eerste helft van de backlog komt het team uit op 500 story points, dus 5 sprints om deze te realiseren. Klant en leverancier spreken een prijs af per gerealiseerde story point.

Na twee sprints staat een rudimentaire versie van de applicatie live. Na de vijfde sprint blijkt dat er functionaliteit is bijgekomen waar aanvankelijk niet aan was gedacht. Een deel daarvan is al gerealiseerd, de rest staat nu bovenaan de backlog en dringt daarmee een aantal oudere wensen naar achteren. Alle user stories zijn nu ingeschat. Na de tiende sprint is de applicatie al volledig in gebruik. De product owner en leverancier besluiten het project met sprint elf af te sluiten. Wat nog op de backlog staat is niet belangrijk genoeg om de kosten te verantwoorden. De klant denkt inmiddels aan een volgend project dat een grotere meerwaarde heeft.

De klant heeft maandelijks betaald voor de opgeleverde story points. Hij krijgt nog een laatste factuur voor sprint 11. Dit project is gerealiseerd zonder de inzet van een projectmanager, er is geen slag geslagen naar de benodigde uren, er is geen risico opslag toegepast.

Sales argumenten voor een agile contract

Fixed price, fixed date en fixed requirements klinkt goed maar wie vertrouwd daar nog op? Een agile contract kent geen meerwerk en de klant krijgt na iedere sprint een werkend product waarmee meteen duidelijk is waar de ontwikkeling staat. Het contract bepaalt onder welke condities de klant het project kan beeindigen. In het ongunstigste geval gebeurt dit omdat de klant vindt dat te weinig voortgang wordt geboekt voor het geld dat er in is gestoken. Dat zelfde gebeurt ook met all fixed contracten, maar dan tegen de tijd dat geleverd had moet worden en het budget uitgeput is. De kans is groot dat er dan zelfs geen minimaal werkend product is.

Meer over agile contract vindt u in deze primer.