Kan Scrum fixed price?

11 juni 2010

Van steeds meer IT-organisaties wordt verwacht dat ze eerder en sneller IT-systemen opleveren die direct waarde creëren in de bedrijfsprocessen. Daarom kiezen organisaties steeds vaker voor Scrum. Scrum is een revolutionaire projectmanagementmethode die waardecreatie, werkende systemen, vroege feedback en zelfsturing centraal stelt. De resultaten in de praktijk zijn uiterst positief. Productiviteitsverdubbeling is al snel gerealiseerd en diverse bedrijven melden zelfs situaties waarin ze hun productiviteit vertienvoudigen.

Scrum werkt via vaste cycli (‘sprints’) met een vaste en korte duur waarin telkens een werkende versie van het systeem wordt opgeleverd. Daardoor wordt snel feedback verkregen en kan er dus gericht gewerkt worden op het eindresultaat en het leveren van toegevoegde waarde. Het eindresultaat van een project wordt vooraf alleen op hoofdlijnen vastgesteld en alle functionele details worden niet vooraf maar just-in-time opgesteld.

Gartner geeft aan dat Nederland momenteel een van de hotspots in de wereld is rond de toepassing van Scrum. Nederland is tegelijkertijd een land met een hoge mate van outsourcing. Een veelgebruikte constructie bij het uitbesteden van projecten zijn fixed-pricecontracten waarin de leverancier een garantie geeft op het eindresultaat tegen vaste kosten en een vaste opleverdatum. Dergelijke projecten worden doorgaans aangenomen op basis van een volledig gedetailleerde beschrijving van het systeem waarvoor een leverancier een aanbieding doet tegen vaste condities. Een veelgehoorde stelling is dat Scrum niet kan omgaan met die behoefte. Sterker nog, fixed-price-Scrum zou onmogelijk zijn.

Deze stelling is gebaseerd op het feit dat Scrum de mogelijkheid biedt om de scope aan te passen op basis van voortschrijdend inzicht. Tegelijkertijd wordt een vaste prijs en leverdatum gevraagd. Scrum verwelkomt veranderingen waardoor het eindresultaat vooraf nooit volledig vaststaat en het dus onmogelijk lijkt om een fixed-pricecontract af te sluiten.

Dit is een paradox. Scrum is namelijk bijzonder geschikt voor fixed-priceprojecten. De methode bevriest namelijk per definitie het budget en de looptijd. Immers, elke sprint heeft een vaste looptijd met vaste resources en dus vaste kosten. Bovendien levert elke sprint een werkend systeem op. Een fixed-priceproject met een vaste einddatum kan dus uitstekend worden opgeknipt in een aantal sprints, waarbij telkens een werkende versie van het systeem wordt geleverd. Kosten en einddatum kunnen daarom per definitie worden bevroren. Echter, in dat scenario is wel de scope van het systeem wendbaar gemaakt; de business kan deze scope besturen.

De stelling dat Scrum geen fixed-priceproject zou kunnen uitvoeren, gaat dus alleen op als alle specificaties van tevoren diepgaand worden uitgewerkt. Men bedoelt dan eigenlijk dat fixed price, fixed date én fixed scope niet met Scrum mogelijk zouden zijn. Op een set requirements een fixed-pricebod doen, is echter ook met Scrum mogelijk. Dit staat namelijk volledig los van de aanpak. Zolang de business besluit om niets te wijzigen, wordt deze scope gebruikt en opgeleverd. Echter, feitelijk is dit een niet reëel scenario, omdat juist door voortschrijdend inzicht de scope altijd wijzigt.

De oplossingsrichting voor fixed price/date/scope zit erin dat binnen Scrum een project wordt opgesplitst in iteraties die telkens een werkend systeem opleveren. Dus niet op de einddatum alle functionaliteit (en dus ook de waarde) pas opleveren. De laatste oplevering wordt bij Scrum voorafgegaan door een groot aantal deelleveringen waarin al een werkend systeem wordt opgeleverd met een subset van de functionaliteit. Essentieel is dat elke oplevering de, voor dat moment, hoogste toegevoegde waarde biedt voor het businessproces. Het systeem kan dan eerder geld gaan opleveren én er wordt eerder feedback gegenereerd.

Met een dergelijke opsplitsing wordt voorkomen dat alle feedback aan het einde komt. In die eindfase lopen de meeste projecten, immers, hun grootste uitloop op. Bijsturing in Scrum vindt daarom al tijdens het project plaats, wanneer er nog tijd en ruimte is voor maatregelen. Voor de businessprocessen heeft dat ook extra voordelen. Doordat het systeem al vanaf de eerste werkende versie kan starten met het leveren van waarde (en niet pas na afloop van het project), kan de terugverdientijd van de investering aanzienlijk worden verkort.

Dat maakt echter nog niet inzichtelijk wat er gebeurt bij verstoringen, nieuwe aanvullende functionele eisen of bij uitloop van activiteiten. Aangezien Scrum elke iteratie just-in-time inplant, kunnen alle onverwachte gebeurtenissen nog in de planning voor elke volgende sprint worden meegenomen. De planning van een project wordt daarmee gebaseerd op steeds meer meetpunten die de voorspelbaarheid van het project en de einddatum en scope steeds beter maken.

Het is overigens een misvatting dat businessafdelingen een voorkeur zouden hebben voor een vaste scope. Flexibiliteit krijgen, bij kunnen sturen, en scope aanpassen is voor hen juist zeer wenselijk. Echter, niet ten koste van alles. Zodoende is er een trend ontstaan waarin een vaste scope wordt geëist. Op basis van ervaring heeft men geleerd dat verandering van scope leidt tot: hogere kosten of een latere levering. De oorzaak daarvan zit echter niet in de scope maar in het eenmalig opleveren aan het eind. Doordat Scrum constant het systeem in een werkende versie oplevert, is een vaste scope niet langer noodzakelijk. Aangezien Scrum altijd die functionaliteit maakt die de meeste toegevoegde waarde biedt, is elke versie van het opgeleverde systeem klaar, en klaar om waarde toe te voegen. Eerder stoppen dan gepland omdat het al voldoende waardevol is, kan dus ook.

Kortom, de flexibiliteit tussen sprints zorgt ervoor dat ook een fixed price/date/scope goed met Scrum te managen is. Door altijd te prioriteren op toegevoegde waarde en steeds een werkend systeem op te leveren, kan de garantie gegeven worden dat binnen deze looptijd en budget de maximale waarde wordt geleverd. Indien de opdrachtgever ook de scope wil bevriezen, kan dat dus prima binnen Scrum. De maatregelen binnen de aanpak zorgen ervoor dat uiteindelijk de opdrachtgever beter af is dan met een klassieke aanpak omdat de leverancier meer ruimte en (bij)stuurmaatregelen heeft om een fixed price/date/scope-project succesvol uit te voeren. De omvang van de scope is dan eenvoudig te bevriezen maar kan ook bij voortschrijdend inzicht worden verbeterd.

Rini van Solingen (r.vansolingen@prowareness.nl ) is werkzaam als chief technology officer bij iSense Prowareness en is in deeltijd verbonden aan de TU Delft. Eelco Rustenburg (erustenburg@xebia.com ) is manager van de unit Agile Consultancy & Training van Xebia. Zij lanceren 15 juni in Amsterdam het managementboek ‘De Kracht van Scrum’. Deze boeklancering is gratis toegankelijk (inclusief keynote van Jeff Sutherland). Voor aanmelding, zie: www.dekrachtvanscrum.nl .

 

Extra maatregelen voor fixed-price-Scrum

▪ Business requirements als leidraad nemen

Stel niet de gespecificeerde functionaliteit centraal, maar het creëren van de waarde in het businessproces. Daarvoor hoeft de benodigde functionaliteit helemaal niet vooraf in detail te worden vastgelegd. Dit mag nog tijdens het project gebeuren. Hierdoor wordt veel tijd bespaard op het bouwen van detailfuncties die niet noodzakelijk zijn of maar beperkte waarde leveren.

▪ User-stories opstellen en prioriteren op waarde

User-stories beschrijven de functionaliteit vanuit gebruikersperspectief en vanuit het toevoegen van waarde. Door deze user-stories onderling op waarde te prioriteren, is het mogelijk om te beginnen met die stories die de meeste waarde toevoegen. Zodoende biedt elke iteratie de meeste waarde voor dat moment.

▪ Werk met wijzigingsverzoeken in de vorm van ‘Exchange requests’

Dit zijn wijzigingsverzoeken waarbij de opdrachtgever vraagt om een wijziging en tevens aangeeft ten koste van wat dat moet gebeuren. Met andere woorden: als er iets bijkomt, dan gaat er ook iets vergelijkbaars van af. Op die manier blijft de omvang van de scope bevroren terwijl de scope zelf wel sterker wordt gemaakt.

▪ Contingencymaatregelen opnemen

Het is raadzaam om in fixed price/date/scope-Scrum een of twee extra sprints op te nemen zonder dat daar op voorhand al werk aan is toegewezen. Daarmee kan onvoorziene uitloop worden opgevangen of extra functionaliteit worden gemaakt.

 

 

Fundamentele denkfouten die Scrum oplost

Scrum ‘werkt’ omdat deze methode een aantal conceptuele denkfouten direct in het werkproces heeft opgelost. Drie voorbeelden van denkfouten:

Scrum ‘werkt’ omdat deze methode een aantal conceptuele denkfouten direct in het werkproces heeft opgelost. Drie voorbeelden van denkfouten:

Requirements moeten eerst volledig en compleet zijn vastgelegd voordat er ontworpen wordt, en er moeten eerst volledige en complete ontwerpen zijn voordat er gebouwd en getest kan worden.

Dit is een denkfout omdat het verkrijgen van feedback nooit moet worden uitgesteld. Immers, hoe eerder er feedback is, hoe eerder het duidelijk wordt dat er fouten gemaakt zijn, zodat er eerder ingegrepen kan worden en nutteloze inspanningen worden voorkomen.

Volledig en gedetailleerd documenteren en opschrijven is noodzakelijk en beter dan het maken van ruwe schetsen die vervolgens besproken worden.

Dit is een denkfout omdat het nut van documentatie is: het overdragen van concepten en modellen aan mensen. Dergelijke concepten en modellen worden veel sneller en effectiever overgedragen door erover te discussiëren en vragen te stellen. Uiteindelijk gaat het om het leerproces, niet om het document.

Wijzigingsverzoeken zijn een verstorende factor en succesvolle projecten moeten daarom hun scope keihard bevriezen en bewaken.

Dit is een denkfout omdat de belangrijkste reden achter een wijzigingsverzoek is dat er voortschrijdend inzicht bestaat. Met andere woorden: het idee van een wijzigingsverzoek is dat dit het eindresultaat beter maakt. Dat negeren zou fundamenteel fout zijn. Verzoeken om verandering moeten daarom een centrale plaats krijgen in het werkproces.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Inloggen

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!