Help! Mijn leverancier werkt Agile...

Indien in een programma de software ontwikkeling is uitbesteed, wil je als opdrachtgever grip hebben op de voortgang en inzicht of wat er geleverd gaat worden daadwerkelijk van waarde is.

Het laatste dat je wilt, is verzanden in discussies met de leverancier over scope en changes.

Als klant wil je graag zo vroeg mogelijk inzicht krijgen en feedback geven, maar dat kan niet altijd omdat bepaalde features nog niet af zijn. Te laat feedback geven heeft als risico dat er geen tijd meer is om alle bevindingen op te lossen en benodigde changes te ontwikkelen. Daardoor levert je product mogelijk minder waarde aan klanten en medewerkers.

Hoe zorg je er nu voor dat acceptanten op een effectieve wijze worden ingezet en hun opmerkingen op een efficiënte manier kunnen worden verwerkt in het product, zonder de leverancier te beperken in het ontwikkelen van creatieve oplossingen?

Begin bij de user stories

Als klant start je met het formuleren van de business requirements, al dan niet in de vorm van user stories. Deze worden doorgenomen met een business consultant of analist van de leverancier. Voordat deze requirements ontwikkeld kunnen worden, moeten ze refinet worden met het ontwikkelteam. De kans is groot dat tijdens het refinen aannames worden gedaan, verkeerde interpretaties of omwille van de technische (on)mogelijkheden de requirements niet volledig worden afgedekt.

Met name in het begin van het project valt er veel winst te behalen door walk troughs te organiseren waarin de leverancier de belangrijkste user stories presenteert. 

Acceptanten effectief inzetten

Tijdens het ontwikkeltraject geven de ontwikkelteams demo’s aan hun stakeholders waardoor deze globaal inzicht krijgen in hetgeen is ontwikkeld. Het is verstandig om na elke oplevering een intake uit te voeren in de staging-omgeving, de omgeving waarin na elke sprint de ontwikkelde software wordt deployed, om het inzicht in de kwaliteit van de oplevering te vergroten.

Het eerste doel is vaststellen welke componenten klaar zijn om te integreren met andere onderdelen om zo complete ketens of afgeronde processen te vormen. Het tweede doel is vaststellen welke componenten onderdeel uit kunnen maken van een (gebruikers)acceptatietest. Op basis van de resultaten van de intake worden acceptanten geïnformeerd over de wijze waarop testen op korte termijn uitgevoerd kunnen worden.

Omdat features en processen in delen worden opgeleverd, kunnen die pas in een laat stadium daadwerkelijk worden geaccepteerd. Het is verstandig om delen ervan na elke sprint door een acceptant te laten beoordelen. Denk daarbij aan het beoordelen van schermen, het controleren van berekeningen en de implementatie van business rules. Geef prioriteit aan aspecten waarvan je verwacht veel feedback te krijgen van de acceptanten, bij voorbeeld user experience (UX). Dan ontvang je in een vroeg stadium de meest relevante feedback.

Door samen met de leverancier de prioriteit van de backlog te bepalen kan je er voor zorgen dat features geleidelijk geaccepteerd worden. Het risico bestaat dat te veel features in ontwikkeling zijn en pas in een laat stadium worden afgerond waardoor je de meeste acceptatietesten tegelijkertijd moet uitvoeren.

Geef prioriteit aan user stories en het oplossen van bevindingen die op zichzelf relatief weinig waarde hebben, maar er wel voor zorgen dat een stuk ontwikkeling kan worden afgerond.

Opmerkingen kunnen niet worden verwerkt

Om stakeholders en acceptanten betrokken te houden is het van belang om ze inzicht te geven in de acties die zijn ondernomen op basis van hun feedback. Het is funest als het ontwikkelteam geen tijd heeft of krijgt om bevindingen op te lossen of changes door te voeren en de acceptant het gevoel heeft dat er niets gedaan kan worden met de feedback. Het is verstandig om met de leverancier af te spreken dat er een percentage van de capaciteit gebruikt wordt om bevindingen op te lossen en changes door te voeren.

Timing is essentieel als het gaat om het betrekken van stakeholders.

Haal feedback pas op als de back log niet te veel grote stories meer bevat en er een “walking skeleton” is ontwikkeld. Een walking skeleton bevat de belangrijkste technische componenten en werkende software welke getest kan worden. Ontwikkel vervolgens een beperkt aantal features en laat daarvoor een acceptatietest uitvoeren. Doe dat voor er een minimal marketable product is ontwikkeld. Op die manier is er nog voldoende ruimte om alle feedback in behandeling te nemen.

Zorg er voor dat wensen die gemakkelijk zijn door te voeren op korte termijn worden ontwikkeld. Op die manier ervaren de stakeholders dat ze ook daadwerkelijk invloed hebben op het te realiseren product. Dat verhoogt de mate van acceptatie. Het is dan ook makkelijker om eventuele changes pas in een latere fase te ontwikkelen. Zorg voor een vlot lopende changeprocedure met de leverancier anders neemt besluitvorming te veel tijd en effort in beslag.

Conclusie: Agile is goed, controle is beter

Om het accepteren van extern ontwikkelde software op een effectieve manier uit te voeren, moet je goede afspraken maken met de leverancier over het managen van de backlog, testuitvoer, bevindingen en changes. Door periodiek in onderling overleg de prioriteitstelling van het te ontwikkelen werk te bepalen, verhoog je de kans dat de geleverde software daadwerkelijk geaccepteerd wordt door de business en optimale waarde heeft voor klanten.

naar overzicht

Wilt u reageren of meer weten?

Heeft u iets in dit artikel gelezen dat uw interesse gewekt heeft? Laat het ons weten!

Deze post delen?

Trotse winnaar van een
FD Gazellen Award
2014 t/m 2018

© 2018 | Europalaan 12a | 5232BC 's-Hertogenbosch | T: +31 (0)85 0290550 | E: info@pancompany.com