Scrum is op dit moment één van de meest populaire Agile ontwikkelmethoden. Mocht u op het punt staan een Scrumproject in te kopen, kijk dan eens kritisch naar uw contract of inkoopvoorwaarden. Een aantal bepalingen zullen namelijk niet echt meer iets toevoegen en zijn als rudimenten van een watervalverleden te beschouwen.
Eerste reden: customer collaboration over contract negotiation
Het “Manifesto for Agile Software Development” stelt dat de samenwerking met de klant belangrijker is dan het onderhandelen van een contract. Veel leveranciers zullen dit echter niet gelijk tegenwerpen als u met uw contract of inkoopvoorwaarden aan komt zetten. Maar zorg er dan wel voor dat het contract passend is.
Wil de leverancier echt niet aan uw contract of inkoopvoorwaarden, laat de leverancier dan ten minste de “Principles behind the Agile Manifesto” onderschrijven. Welke inkoper wil er nou niet dat “het opleveren van werkende software” en “de tevredenheid van de klant als prioriteit van leverancier” onderdeel zijn van een contract (zie hier gelijk een mogelijke onderhandelingsstrategie).
Zorg er natuurlijk wel voor dat de algemene voorwaarden van de leverancier niet van toepassing zijn. De leverancier heeft veelal (ook) een contract of algemene voorwaarden gebaseerd op waterval of andere ouderwetse ontwikkelmethoden. Uitzonderingen daargelaten natuurlijk. Neem de leverancier die wel nagedacht heeft over Scrum en contractvorming serieus.
Tweede reden: embrace change!
De crux van Scrum. Niets staat vast en de wereld is aan verandering onderhevig. Heeft uw contract een uitgebreide en formele bepaling over change requests, of nog erger, meerwerk? Dan maakt deze in de wereld van Scrum geen indruk. Sterker nog, die bepaling hoort daar niet thuis.
Changes zijn intrinsiek aan een Scrum project.
Derde reden: requirements en specificaties
Een bepaling over het eerst vaststellen van requirements en/of specificaties waarop akkoord dient te komen van u? In de wereld van Scrum werkt men met zogenaamde user stories. Deze worden samen met de klant vastgesteld. Door middel van stellen van prioriteiten en plannen worden sprints gevuld met user stories. Als u wel precies weet wat u wilt, althans, u denkt het te weten, en u wilt dit vooraf vastleggen, denk dan na over
u een Scrum project wilt inkopen.
Vierde reden: acceptatie
Een rudiment uit een watervalverleden. Van oudsher zet u de leverancier aan het werk en die levert aan het einde van de doorlooptijd (met het liefst fatale termijnen) een product op. Dit onderwerpt u vervolgens aan een acceptatietest om te kijken of het opgeleverde voldoet aan de specificaties en het liefst ook aan uw bedrijfsdoelstellingen.
Zoals eerder gezegd wordt er bij Scrum gebruik gemaakt van sprints. Na elke sprint wordt er een werkend product opgeleverd (als Scrum goed gevolgd wordt). Die werkende programmatuur dient u elke keer te testen en te bekijken (bijvoorbeeld in de rol van product owner) alvorens wordt aangevangen met een nieuwe sprint.
Vijfde reden: vaste prijs en vaste scope
Vaste prijs en vaste scope is natuurlijk sowieso een illusie. Maar bij Scrum past het niet echt. Maar u heeft één grote onzekerheid: budget.
U wilt geen open verbinding met uw schatkist creëren. Begrijpelijk. Een mogelijke oplossing is een vaste prijs met een variabele scope. Of, als u uw leverancier in het begin niet vertrouwd, een vaste prijs en gedeeltelijk vaste scope (werk dan bijvoorbeeld met MoSCoW, maar dat vergt wel discipline van beide partijen).
Let er wel op dat een slimme leverancier u zal proberen te houden aan het gehele budget als u een vaste prijs afspreekt. Echter, als Scrum goed gevolgd wordt, wordt er na elke Sprint werkende software opgeleverd waarvan u wel eens zou kunnen vinden dat die software goed genoeg is om in productie te nemen ("potentially shippable").
De leverancier zoekt veelal naar betaalmodellen voor Scrum à la nacalculatie. Let daar ook op.
Conclusie
Belangrijk is om vast te stellen waarom u een Scrumproject wilt inkopen. Realiseert u zich daarna dat de redenen waarom u een Scrum project wilt inkopen moeten overeenkomen met de waarden waar Scrum feitelijk voor staat. Het past dan niet om de leverancier een watervalachtig contract op te leggen, tenzij deze goede Scrum paragrafen bevatten. Spreek dus niet met gespleten tong. Let er ook op dat er leveranciers zijn die Scrum gebruiken als verkoopargument, en vervolgens niet (helemaal) conform Scrum werken. Of nog erger: de leverancier wil met Scrum het risico van een het runnen van een projectorganisatie (geen of niet altijd zwarte cijfers schrijven) afwentelen op de klant. Prik daar doorheen!