First things first: waarom eigenlijk Agile?
Om een aantal redenen. Een belangrijke reden is de korte feedbackcyclus. In een klassiek project, op basis van bijvoorbeeld de watervalmethode, is alles al opgezet en geconfigureerd vooraleer de klant de eerste keer het systeem te zien krijgt. Als op dat moment blijkt dat er dingen verkeerd begrepen zijn, dan vraagt dat veel correctiewerk. De kans is ook groot dat eisen en wensen ondertussen veranderd zijn en dat het opgeleverde product niet meer aansluit op de actuele behoefte. Om dit soort risico’s te vermijden, is een flexibelere aanpak is noodzakelijk. Agile is een methode die uitermate geschikt is om op steeds veranderende omstandigheden in te spelen. Ze zorgt voor iteratief werken in korte ‘sprints’ van 2 tot 4 weken, regelmatige feedbackloops en laat ruimte voor verandering en voortschrijdend inzicht. Het is een aanpak die er inherent vanuit gaat dat businessnoden kunnen veranderen gedurende een implementatietraject. Zo krijgen de gebruikers bij elke sprint een demo van de applicatie te zien en kunnen ze onmiddellijk feedback geven of alles voldoet aan de verwachtingen. Ze krijgen ook toegang tot een UAT-omgeving (User Acceptance Testing) zodat ze zelf kunnen toetsen hoe de functionaliteit werkt, wat de gebruikersadoptie vergemakkelijkt. Dit is dan ook een tweede reden om agile te gebruiken. De gebruikers krijgen van in het begin voeling met de applicatie en voelen zich betrokken bij het project. Doordat ze inspraak krijgen, stijgt hun engagement waardoor ze sneller geneigd zijn om de applicatie te aanvaarden én te gebruiken. Een derde reden is de sterke focus op waardecreatie; het bieden van toegevoegde waarde aan de klant. Door een permanente prioritering en focus op intrinsieke businesswaarde wordt enkel in belangrijke en relevante functionaliteit geïnvesteerd.
Agile coach: focus op de ‘zachte kant’ van verandering en doe beroep op kennis en begeleiding
Agile werken heeft veel voordelen, maar het is geen toverformule waarmee iedereen zomaar aan de slag kan. Dus als je nog nooit een agile project in D365 hebt gedaan of relatief nieuw bent met de agile methode, is het zinvol om een agile coach in te zetten. Hij zal alle vragen over hoe je een agile project best aanpakt beantwoorden en de teamleden op weg helpen met de praktische zaken. De coach zal je ook bijstaan in de interactie met de klant en hem ondersteunen in het werken met agile. Een belangrijk uitgangspunt bij agile is immers dat een goede en nauwe samenwerking tussen mensen en teams bepalend is voor het succes van een project en dat kan alleen als alle neuzen in dezelfde richting staan. Een agile coach hoeft niet per se ervaring te hebben in D365-projecten op zich, maar hij moet uiteraard wel ervaring hebben in het werken met agile.
Sprint 0: ga voor een degelijk fundament
Het is aangewezen om te starten met een sprint 0. Deze sprint is eigenlijk een voorbereidende sprint die het fundament legt voor alle volgende sprints en waarin het team de tijd krijgt om elkaar te leren kennen en afspraken te maken. Aan de hand van workshops worden de eerste vereisten en wensen van de eindgebruikers in kaart gebracht en vertaald naar user stories. Deze user stories worden dan in een productbacklog samengebracht en geprioriteerd op basis van hun businesswaarde. De items met de meeste waarde voor de gebruikers worden eerst geconfigureerd en geïmplementeerd. Zo moet er een productbacklog zijn waar voldoende user stories in zitten om een eerste sprint mee te vullen. User stories mogen zeker klein genoeg worden opgedeeld. Bij een maatwerkproject wordt er enkel gekeken naar de businesswaarde voor de klant waarmee tijdens de prioritering rekening gehouden wordt. Bij een D365-project kan je al businesswaarde creëren via ingebouwde functionaliteiten in het pakket. De solution consultant speelt hierin een belangrijke rol. Hij moet de fit/gap doen tussen de ingebouwde functionaliteiten en de gevraagde businesswaarde. Tijdens sprint 0 is het belangrijk om ook aandacht te hebben voor de technische aspecten van en de fundamentele eisen aan het systeem, zoals de architectuur, zeker als er ook integraties met andere systemen moeten gebeuren.
Product owner: zorg voor verbinding tussen de stakeholders
Een agile project valt of staat met een goede product owner. Dit is ook het geval bij D365-projecten. Een goede product owner is bij voorkeur geen manager; een manager of leidinggevende heeft vaak onvoldoende tijd om een project goed op te volgen. De functie van product owner is er niet eentje die je ‘er zomaar even bij doet’. Een product owner is best iemand die uit de business komt en dito ervaring heeft. Indien het bijvoorbeeld om een salesimplementatie gaat, is de product owner idealiter zelf een accountmanager (geweest). De product owner moet een goed contact hebben met alle stakeholders van het project en in verbinding staan met de diverse belangen van business en IT. En hij moet ervoor zorgen dat de visie zoals bepaald voor de start van het project mee bewaakt wordt. Het is daarbij van cruciaal belang voor het project dat de product owner het unanieme mandaat krijgt om beslissingen te nemen. Is dit niet het geval, dan riskeert het project vertraging op te lopen omdat er op beslissingen moet gewacht worden.
Minimum Viable Product: lanceer de essentie om snel te accelereren
In agile gaat men uit van het principe dat er op het einde van een sprint telkens een Minimum Viable Product (MVP) – een minimaal werkbaar product gemaakt met een minimale investering - kan opgeleverd worden. Deze korte iteraties verkleinen de risico’s op falen, waarbij onmiddellijke feedback zorgt voor een snellere doorlooptijd en onnodige complexiteit vermijdt. Mits doordacht gelanceerd en dat is de bedoeling, wil ‘minimaal werkbaar’ trouwens niet zeggen ‘middelmatig’. Een minimum viable product is een functionaliteit die ook effectief kan gebruikt worden en waarop verder kan gebouwd worden. In D365 is het zelfs eenvoudiger om na 2 weken iets op te leveren dan in maatwerk het geval is. De uitdaging is hier wel dat de projectaanpak en de kennis van de teams moeten afgestemd zijn op dergelijke korte delivery sprints. Agile en (automated) releases, in de geest van DevOps, gaan hier hand in hand. D365 kan je wat dat betreft beschouwen als een blokkendoos waaruit samen blokjes worden gekozen die belangrijk zijn voor het project en waarmee het project verder wordt opgebouwd.
Sprinten, meten en leren: implementeer volgens voortschrijdend inzicht
Tijdens de implementatie van het project is het vooral belangrijk dat er tijdens de sprintplanningmeetings goed wordt doorgesproken wat de prioriteit van de business is, maar ook wat de technische volgorde van de implementatie is. Het zou kunnen dat bepaalde entiteiten eerst moeten gecreëerd worden vooraleer andere items kunnen aangemaakt worden. Dit zou een impact kunnen hebben op het aantal story points dat een bepaalde user story krijgt, of op de volgorde waarop het geïmplementeerd moet worden. De sprintreviewmeetings en retro’s zijn cruciaal tijdens deze fase van het project. Tijdens de sprintreviewmeetings krijgen de gebruikers voor het eerst het resultaat te zien. Het is belangrijk om goed naar hun feedback te luisteren en dit moment aan te grijpen om hen zelf ook te laten kennismaken met D365. Dit werkt het beste door hun zo snel mogelijk na de sprint toegang te geven tot een omgeving waarin ze een bepaalde ontwikkeling of configuratie zelf functioneel kunnen testen en valideren. Indien nodig, worden een aantal aanpassingen opgenomen die in een volgende iteratie op basis van prioriteit worden behandeld. Een van de grote voordelen is dat iedereen een beter inzicht heeft in de voortgang van het project en dat business en IT ook beter en productiever op elkaar zijn afgestemd.