Agile-projecten: tips voor goede afspraken & succesvolle inkoop

Software-ontwikkeling met agile is hot: er is bijna geen organisatie te vinden die niet al met agile (vaak: scrum) experimenteert of dit hoog op het verlanglijstje heeft staan. En toch staat het bij de meeste organisaties nog in de kinderschoenen. Wat zijn de barrières waar bedrijven tegenaan lopen? Mijn collega’s en ik merken dat agile-projecten lastig te budgetteren zijn en daarmee vaak voor onduidelijkheid zorgen bij inkoop. Hoog tijd voor een overzicht van veelgestelde vragen en misvattingen en handvatten voor succesvolle inkoop.

Vooraf definiëren van de scope blijkt onmogelijk

Vroeger had de inkoper het makkelijker: projecten werden voor de start ingeschat en de kostprijs stond van tevoren vast. De basis voor deze ‘old school’ werkwijze wordt ook wel ‘waterval’ genoemd, een projectbenadering waarbij development-projecten altijd starten met een requirementfase die duidelijk maakt wat er gebouwd moet worden. En hiermee weet inkoop dus precies wat het kan verwachten.

Althans, op het moment van inkoop. In werkelijkheid blijkt het vooraf definiëren van de scope van projecten zo goed als onmogelijk. Met alle gevolgen van dien voor de scope, de doorlooptijd en/of het budget.

Agile breekt met vooraf bepaalde requirements

Agile-methodes (met als meest bekende scrum) gelden inmiddels als best practice voor veel software-ontwikkelingsvraagstukken. Agile breekt met vooraf bepaalde gedetailleerde requirements. Agile en scrum gaan volledig uit van het simpele feit dat aan de start van een traject onduidelijk is wat er uiteindelijk wordt. En dus focussen agile en scrum zich op de doorlooptijd in plaats van de scope. En wordt er ook geen tijd verspild aan het vooraf in detail documenteren van wat er gebouwd gaat worden.

De grote kracht van agile (agilty betekent wendbaarheid) is dat het ruimte geeft bij te sturen op basis van voortschrijdend inzicht. De methode gaat om met steeds weer veranderende omstandigheden en onzekerheid op basis van transparantie, onderling vertrouwen en nauwe samenwerking. Geen dikke requirement-documenten vooraf, maar een bondige ‘product backlog’. Geen PIT’s of meerjarenplannen, maar ‘daily stand-ups’ en ‘demo’s’.

De grote vraag bij inkoop: ‘wat krijg ik dan?’

Dat klinkt allemaal hartstikke mooi, maar het is natuurlijk ook niet onbegrijpelijk dat een inkoper hier niet zoveel mee kan. Want welke houvast heb je als opdrachtgever als de leverancier zich niet committeert aan een vooraf bepaalde scope?

Antwoord: ‘een inspanningsverplichting’

Het aankopen van custom software (te ontwikkelen websites en apps) is fundamenteel anders dan het aankopen van bijvoorbeeld kantoormeubilair of het sluiten van een huurcontract. Waarom? Van een bureaustoel weten we op voorhand allemaal vrij goed wat we kunnen verwachten. Maar maatwerk software-ontwikkeling is op voorhand simpelweg onmogelijk te specificeren.

De basis voor het succesvol aankopen van een agile-samenwerking tussen opdrachtgever en bureau, is het besef dat het bureau een inspanningsverplichting levert (en geen kwaliteitsverplichting). Dit lijkt misschien een nuanceverschil, maar dat is het niet:

• Kwaliteitsverplichting: de leverancier van het ingekochte product (neem als voorbeeld weer even die bureaustoel) neemt volledige verantwoordelijkheid voor de kwaliteit van het geleverde product (garantie). Dat kan de leverancier zich permitteren omdat zowel klant als leverancier op voorhand weten wat er wordt geleverd en wat de risico’s zijn.

• Inspanningsverplichting: als op voorhand niet 100 procent gespecificeerd kan worden wat er wordt geleverd, kan een leverancier zich niet committeren aan het te ontwikkelen product. Wel kan de leverancier zich committeren aan een te leveren inspanning, een toezegging om de benodigde werkzaamheden naar eer en geweten te leveren en regelmatig te rapporteren over de geleverde inspanning en geboekte vooruitgang.

Verreweg de meeste samenwerkingsverbanden zijn op basis van een inspanningsverplichting. Het personeel krijgt een vast salaris per maand, op de voorwaarde dat ze als medewerkers hun best doen. Maar ook externe samenwerking met adviseurs (neem als voorbeeld een advocaat) is bijna altijd een inspanningsverplichting. Om de simpele reden dat op voorhand onduidelijk is welke inspanning nodig is om tot een wenselijk resultaat te komen.

Hoeft de leverancier zich dan nergens aan te committeren?

Een inspanningsverplichting geeft een leverancier natuurlijk geen vrijbrief om de werkzaamheden naar eigen inzicht in te vullen en naar hartenlust te factureren. Op voorhand committeert een leverancier van een inspanningsverplichting zich aan transparantie over het geleverde werk en een toezegging van een toegewijd team.

• Rapportage en transparantie over het geleverde werk: hoewel een leverancier in een scrum-project zich niet committeert aan een vaste scope (een vooraf bepaald eindresultaat) committeert hij zich wel aan het regelmatig tonen van progressie. Sterker nog: de sprintcyclus van scrum geeft de opdrachtgever op gezette tijden inzicht in het geboekte resultaat.

• Committent van een toegewijd team: software-ontwikkeling is volledig afhankelijk van de kwaliteit en samenwerking van het team. Wisselingen in teamsamenstelling hebben zelden een positief effect op de eindkwaliteit. Het is als opdrachtgever van een inspanningsverplichting reëel om van je leverancier te verwachten dat deze zich committeert aan het leveren van een stabiel en volledig toegewijd development-team.

Hoe vergelijk en selecteer je een agile-leverancier?

Toegegeven: het vergelijken van leveranciers van bureaustoelen is makkelijker dan het vergelijken van development-leveranciers. Maar toch zijn er een aantal criteria waar opdrachtgevers op kunnen letten bij het vergelijken en selecteren van partners:

• Vertrouwen is de sleutel tot succes: bij software-ontwikkeling hoort nauwe samenwerking en afhankelijkheid tussen opdrachtgever en leverancier. Kies dus voor de menselijke klik en onderling vertrouwen: het is het meest invloedrijke element van een succesvolle samenwerking.
• Toewijding en focus zorgen voor kwaliteit: kies voor een leverancier die zich committeert aan het leveren van een met aandacht samengesteld en stabiel team. In het bijzonder zijn de rollen van product owner en scrum master van grote invloed op het proces en eindresultaat en mogen gedurende het traject eigenlijk nooit vervangen worden.
• Kies voor een bewezen trackrecord: agile werken (zeker scrum) is niet makkelijk. Het is een complexe methodiek die werkt bij de gratie van een ervaren team. Bewezen ervaring met deze manier van werken is daarom een rationeel vereiste.
• Selecteer op transparantie: de basis voor een samenwerking met een prestatieverplichting is grip op de voortgang. Vraag een mogelijke leverancier dus op voorhand naar hun rapportageformat met daarin een wekelijkse update over het bestede budget en een prognose van de verwachte kosten voor de komende sprint.
• Schuw makkelijke toezeggingen: in een verkoopproces is een belofte snel gemaakt. Maar makkelijke toezeggingen hebben uiteindelijk altijd een ongewenst effect op het verloop van de samenwerking. Of het nou resulteert in overrun in budget of druk op de kwaliteit van het geleverde product: het gevolg is altijd voelbaar voor de opdrachtgever.

Wat leg je vast in een agile samenwerkingsovereenkomst?

In een agile- of scrum-werkwijze kun je vooraf dus lastig contractueel vastleggen wat er geleverd wordt. Maar dat betekent niet dat een overeenkomst tussen opdrachtgever en leverancier geen waarde heeft. Een aantal belangrijke dingen die vooraf op papier vast te leggen zijn:

• De productvisie: wat wil de opdrachtgever bereiken en hoe moet het product bijdragen aan deze doelstellingen?
• Team: benoem concreet wie de rollen product owner en scrum master oppakken en wie de leden van het developmentteam zijn (of tenminste hun ervaringsniveau).
• Sprint proces en bijbehorende afspraken: benoem het sprint-proces, de lengte van elke sprint en de timing van alle demomomenten. Leg ook alle bij scrum horende afspraken vast. Denk aan het mandaat van de product owner, de regels bij het niet onderbreken van sprints en het committeren aan vaste momenten..
• De ‘Definition of Done’: te veelomvattend om in één zin toe te lichten, maar kortweg een definitie van: wat is werkende software? Aan welke kwaliteitseisen voldoet elk opgeleverd onderdeel van het product?
• Pricing model: welke tarieven gelden er, hoe werkt rapportage en wanneer wordt er gefactureerd?
• Wanneer mag wie onderbreken: Agile- of scrum-samenwerking kent geen op voorhand vastgesteld eindpunt. Daarom is het zinnig vast te leggen onder welke voorwaarden de opdrachtgever of leverancier de samenwerking kan stopzetten.

Vraag je altijd af: is agile of scrum wel de juiste route?

Agile of scrum is natuurlijk ook geen heilige graal. Hoeveel lof agile development ook krijgt (veelal terecht), er zijn genoeg projecten te bedenken waarbij het logischer is om te kiezen voor een andere benadering (lees: watervalbenadering). En in die gevallen is een waterval-aanpak makkelijker te managen (en vaak ook goedkoper). Dus ga altijd na: is agile of scrum wel de juiste keuze? Goede argumenten om ervoor te kiezen zijn:

• Het product (website of applicatie) is nieuw, waardoor het op voorhand lastig te bepalen is wat het product exact moet gaan doen en hoe het in detail moet werken.
• Het product is complex en heeft een grote mate van samenhang tussen design en techniek en vraagt dus om een multidisciplinair team (design & developers die parallel werken).
• Een korte time-to-market is cruciaal: het product verliest waarde wanneer het niet binnen een gezette tijd wordt gelanceerd.
• Het product kent veel betrokken belanghebbenden met ieder een eigen mening over wat het moet gaan worden. Er is dus veel behoefte aan zichtbaarheid en stakeholder management.
• Het project heeft een flinke omvang: in kleinere projecten (denk aan een geschatte doorloop van minder dan twee maanden) komt agile of scrum niet tot zijn recht.

Tot slot: veel gehoorde misvattingen over agile & scrum

Er leven nogal wat misvattingen omtrent agile en scrum. Daarom een aantal veelgehoorde misvattingen en de argumenten die je kunt gebruiken om ze te weerleggen:

1. Agile- en scrum-projecten zijn een blackbox: je kunt als opdrachtgever niet bijsturen

Onwaar: scrum committeert zich aan een hoge mate van transparantie en een hoge frequentie van oplevering (elke sprint een oplevering). Dit geeft de opdrachtgever bij uitstek grip op de gekozen richting en de mogelijkheid bij te sturen.

2. Agile werken geeft geen grip op het budget en hoe het uitgegeven wordt

In tegendeel: goede agile- en scrum-leveranciers rapporteren wekelijks, inclusief actuele prognoses van wat er de komende weken verwacht wordt. Maar belangrijker nog: scrum richt zich op het werkend opleveren van die delen van de software die het meeste waarde oplevert. Mocht het budget nou sneller op raken dan verwacht, is er hoe dan ook waarde geleverd (in de vorm van werkende software). Die luxe biedt waterval zeker niet.

3. Leveranciers van agile-trajecten committeren zich nergens aan en geven geen garanties af

Onzin. Ondanks dat er geen vooraf bepaalde scope is, zijn er genoeg zaken waarvan een opdrachtgever mag verwachten dat een leverancier zich daar –contractueel- aan committeert. Denk aan: rapportage, een stabiel & toegewijd team, de vooraf bepaalde productvisie en vaste deadlines voor tussentijdse oplevermomenten (demo’s).

4. Het voordeel van ‘fixed scope’ is dat het risico bij de leverancier ligt

Klinkt prettig, maar is helaas niet waar. Het risico ligt –ook bij waterval- altijd bij zowel de opdrachtgever als de leverancier. Natuurlijk kun je er als opdrachtgever voor kiezen je leverancier strak te houden aan een vooraf bepaald budget. Maar in de praktijk drukt het altijd op de kwaliteit van het geleverde product. Hoe dan ook: een te krap budget is altijd voelbaar voor de opdrachtgever.

Foto intro met dank aan Fotolia.