Klant-gestuurde agile ontwikkeling
Geschreven door Timo Hoogendorp – ICT lead
Waarom we voor deze route hebben gekozen?
Al vrij vroeg bij het opzetten van mijn huidige team was het duidelijk dat we een groep mensen hebben met een behoorlijk brede selectie aan vaardigheden die allemaal zouden kunnen bijdragen aan een verscheidenheid aan projecten op onze roadmap. Het was moeilijk om externe en interne belanghebbenden het eens te laten worden over urgentie versus prioriteit en tijdlijnen. Dan was er de extra complexiteit van externe deadlines en budgetten. Als een klant bereid is te betalen, of zelfs heeft betaald, voor iets dat moet worden ontwikkeld en er is een beoogde tijdlijn, betekent dit dan dat het automatisch voorrang krijgt op andere dingen die misschien voorrang zouden moeten krijgen? Bij wie ligt die beslissing bovendien? Bij het technische team, of bij iemand anders?
Sommige van deze projecten waren grote/langdurige projecten, wat zou betekenen dat de schaarse resources tot wel een jaar in dit project zouden worden opgeslokt. De impact op de tijdlijn voor andere projecten zou aanzienlijk zijn, en als gevolg daarvan kregen deze grotere projecten doorgaans een lagere prioriteit van de belanghebbenden van de operationele teams. Als onvermijdelijk resultaat zouden we ook zien dat quick-win- en korte-termijn- projecten worden opgepikt boven meer fundamentele herontwerpprojecten of ambitieuzere nieuwe-marktprojecten.
Een andere observatie die we maakten, is dat de eisen en specificaties van projecten soms veranderen naarmate de ontwikkeling vorderde. In het projectinitiatiedocument en de vereisten die het bevatte, ontbraken vaak de details. Soms, terwijl we aan het itereren waren, voelde het alsof de aanvragers zelf niet echt wisten wat ze precies wilden ontvangen totdat we begonnen met het ‘verbeteren’ van onze eerste ontwikkeling.
Het tastbare product dat tot dan toe was ontwikkeld, inspireerde de aanvragers of belanghebbenden vaak en maakte duidelijk wat we precies aan het doen waren. Dat bepaalde must-haves geïntroduceerd moesten worden voor de bevordering van de adoptie in onze operationele organisatie, of zelfs volledige bezwaren tegen het project ontstonden omdat het in strijd zou zijn met andere interne projecten of processen. Het leidde tot extra gebruiksverzoeken die onderdeel moesten zijn van de ontwikkeling. Verzoeken die achteraf gezien onderdeel moesten zijn van een ander project, worden in een andere sprint opgepikt. Een typisch voorbeeld van onnodige scope-inflatie, ondanks de beste bedoelingen van mijn collega’s.
Deze slechte koppeling tussen het technische team en de aanvrager, en het gebrek aan begeleiding en vrij lange ontwikkeltrajecten maakte het noodzakelijk deze processen te herzien. We hebben tijd en middelen verspild aan het bouwen van dingen die volledig opnieuw moesten worden opgebouwd, die niet voldeden aan de behoefte van de gebruiker, of niet waren wat de gebruiker vroeg of nodig had. Bovendien leidde deze ontkoppeling tot een behoorlijk tijdrovend gebruikersadoptieproces. Wanneer het project ‘klaar’ was, betekende ‘gebruikersadoptie’ meestal enkele sessies om uit te leggen hoe het product werkt, waar specifieke essentiële functies en processen te vinden zijn, en een mooie lijst van de eindgebruikers van ‘hadden moeten en zouden kunnen hebben’ functionaliteiten die we ‘zeker in de volgende sprint moeten oppakken’. Het eindproduct voelde al verouderd en aan verbetering onderhevig vanaf het moment dat het in gebruik genomen werd.
