Scrum: ligt al het risico bij de opdrachtgever?

Een belangrijk verschil tussen scrum en de traditionele waterval-aanpak is dat je bij scrum het eindresultaat niet vastlegt. Je bepaalt alleen budget en doorlooptijd. Dit druist in tegen een diepgewortelde menselijke eigenschap: de drang naar zekerheid. Veel opdrachtgevers voelen scrum daardoor als een groot risico. Maar is het risico werkelijk zo groot?

In detail afspreken wat je krijgt, is ook risicovol

Projecten zijn zelden zonder risico. We proberen dan die risico’s weg te managen. Bij kleine, overzichtelijke projecten is de waterval-aanpak een relatief goede methode om dat te doen. Je spreekt van tevoren precies het resultaat af, en je vermijdt zo het risico dat je te weinig krijgt. Of iets wat je niet wilde. Bij grote projecten beginnen we met een analysefase om de resultaten precies te kunnen omschrijven. Die analyses hebben alleen de neiging om uit te lopen. Het kost tijd om alles in detail uit te zoeken. Elk antwoord werpt nieuwe vragen op.

Daardoor zijn de resultaten van de analysefase vaak al gedateerd voordat het project begonnen is. Je krijgt nu precies wat je twee jaar geleden dacht te willen hebben. Je hebt een enorm bestek, gebaseerd op aannames over de eindklant en de wereld waarin het project gaat leven. Het risico van het projectresultaat ligt nu in een document. Dat geeft je weinig mogelijkheden om met voortschrijdend inzicht om te gaan.

Dus ook als je precies de projectdeliverables afspreekt, loop je als opdrachtgever veel risico: het risico om de verkeerde afspraken gemaakt te hebben.

Scrum laat de risico’s waar ze horen

Het verfrissende van scrum is om het risico van het projectresultaat én de mogelijkheid om het te beheersen, bij een persoon te leggen: de product owner. De product owner bepaalt wat prioriteiten zijn. De product owner bepaalt of iets goed genoeg is. Daarmee is ze niet alleen een levend programma van wensen, maar borgt ze ook dat elke minuut aan de meest waardevolle feature van dat moment gewerkt wordt.

Het project kan sneller starten omdat je geen uitgebreid programma van eisen nodig hebt. Je krijgt als opdrachtgever een ongeëvenaarde real-time invloed op het project! Daarmee heb je ook een grote verantwoordelijkheid gekregen. Je kan niet langer de opdrachtnemer aan het budget houden. Het zou niet fair zijn om oneindig verbeteringen te eisen, zonder dat de teller loopt.

Loopt de opdrachtnemer dan geen enkel risico?

Bij een waterval-traject met vastgesteld resultaat, is het grootste risico voor de opdrachtnemer om er verlies op te lijden. De opdrachtnemer zal er dus energie instoppen om geen verlies te lijden op het project: er komen financiële buffers in het project en resultaten worden met een duivelse nauwkeurigheid opgeleverd, ook als dat niet meer waardevol is.

Het is voor iedereen beter als de leverancier zijn energie stopt in het hoog houden van de productiviteit en het concurrerend maken van offertes. Dat is precies wat je bij scrum krijgt. Omdat je bij scrum na elke sprint een waardevol resultaat hebt, kunnen beide partijen ook na elke sprint de toegevoegde waarde meten. Zo wordt het heel zichtbaar of de opdrachtnemer waar voor zijn geld levert. Een flexibele scope betekent niet dat de opdrachtnemer nooit meer een avondje doortrekt met pizza. Dat kan alsnog, als de opdrachtnemer het gevoel heeft dat de toegevoegde te laag was. Bij scrum gaat het om een goed track record, een vertrouwensrelatie en fantastische samenwerkingen die voor mond-tot-mond reclame zorgen.

Is scrum alleen voor opdrachtgevers met diepe zakken?

Je weet bij scrum niet precies wat je krijgt. Moet je dan bijbetalen tot je hebt wat je wil? Hoe beheers je dit risico in scrum? De truc is regelmatige backlog refinement. Tijdens dit wekelijkse of zelfs dagelijkse moment bekijk je waar je uitkomt in de komende sprints. Door goede backlog refinenement is voor de product owner direct duidelijk wat zijn beslissingen betekenen voor het eindresultaat. Zo is het mogelijk om te krijgen wat je wil, zonder oneindig diepe zakken te hebben als opdrachtgever.

Sterker nog: misschien moet je voor een waterval-traject wel diepere zakken hebben dan voor scrum. Als je daar iets niet goed beschreven hebt, krijg je al gauw meerwerkoffertes.

Scrum maakt risico’s vroeg zichtbaar, maar je moet er wel naar handelen

Scrum is niet inherent veiliger of onveiliger dan een waterval-traject. Er kunnen goede redenen zijn om niet te gaan scrummen. De risico’s zijn wel eerder en beter zichtbaar. Als je op zo’n moment de koe bij de hoorns vat, houd je alles onder controle. Scrum weet: we zijn gewoon apen die niet in de toekomst kunnen kijken, maar we zijn wel verdomd vindingrijke apen. Laten we dat benutten.

Dit artikel is het derde deel in een serie over Scrum. Lees hier het eerste deel: ‘6 redenen om niet te scrummen’ en het tweede deel ‘Scrum: de fijne kneepjes van backlog refinement’.