Van waterval naar Agile, ervaring uit een BI project
Geschreven door Martijn van den Eijnde op 08-04-2016

Binnen het vakgebied van BI hebben we veel te maken met blinde vlekken, niet vastgestelde definities en de business die 'meegenomen' moet worden. Tijdens één van mijn projecten ben ik lessons learned gaan analyseren om tot een set tips te komen die het iGRIP model meer Agile maken.

Agile is een term die vele concepten kent, ik doel in dit stuk voornamelijk op het aanpassend vermogen op veranderingen en de intensieve(re) samenwerking binnen een (ontwikkel)team.

Op hoofdlijnen is het iGRIP model een waterval methode. Iedere fase wordt immers afgesloten met een tastbaar resultaat. Dit resultaat wordt in de volgende fase opgepakt en als begin mee verder gewerkt, enzovoort.

Tijdens de 4e fase, het bouwen van de informatie dashboards, vindt er veelal een heen en weer geschuif plaats tussen de bouwer, de analist, de designer, de tester en de project verantwoordelijke (vaak in de rol van de persoon die de implementatie uitvoert). Er wordt iets bedacht, ontworpen, gebouwd, getest en geïmplementeerd.

Naar mijn mening is dit vaak erg bureaucratisch, maar voor sommige projecten dé methode. Vaak hoor je in dit soort projecten gemopper heen en weer, in de trend van 'alweeeer herbouwen' of 'pffff weer een ander design'. De business die de wens naar informatie heeft, weet veelal niet precies 'wat' ze willen. Dit komt door onduidelijke processen, blinde vlekken in werkwijzen en business rules en onduidelijkheid over hoe de bronapplicatie nu precies functioneel werkt.

BI projecten kunnen gezien worden als analytische projecten en deze lenen zich erg goed voor een Agile aanpak. Op hoofdlijnen betekent dit meer hapklare kleine stukken in rap tempo aanbieden en wegkauwen. Dit noemen we iteraties, of een iteratief proces. Dit vergroot het aanpassingsvermogen en de samenwerking, kortom de agility. 

Hieronder een vijftal tips die ik kan formuleren op basis van de lessons learned voor meer agility binnen BI projecten:

1. Het teamCreëer een multi disciplinair team dat in alle stappen van het project kennis en kunde heeft. Zorg er tevens voor dat dit team in alle fases relatief makkelijk tijd beschikbaar heeft om samen te kunnen werken en te kunnen overleggen. Betrek ook de business bij dit team en zorg er voor dat organisatorische barrières tot een minimum worden gebracht. Samen tot één resultaat is hier het absolute speerpunt.

2. Groot, maar toch kleinDe tweede tip kent vooral zijn impact bij de technische collega's uit het team. De hapklare brokken gaan namelijk veelvuldig veranderen. Door zo snel mogelijk kleine stukken op te leveren zal er veel 'mis geschoten' gaan worden. Een motto dat veel voorbij komt is 'Think Big, Act Small'. Neem alle informatie in alle fases goed tot je als team, maar begin klein en met veel detail. Door de 'fouten' die gemaakt worden (en natuurlijk de successen) kom je steeds dichter bij het einddoel. Ik heb het al eens benoemd, maar in dit soort projecten weet vaak niemand in het begin wat nu precies het resultaat gaat en moet zijn. Wees dus voorbereid op het maken van fouten en zie het als een leerproces.

3. En opnieuw…
De “fouten” uit tip 2 betekenen het opnieuw bouwen en ontwerpen van stukken. Bij de eerste paar iteraties kunnen stukken zelfs helemaal overhoop moeten en kunnen definities toch nog aangepast moeten worden. Houd dus vanaf het begin rekening met het herzien van zaken en doe dit door netjes en zo simpel mogelijk te werken. Simpel betekent in deze wel het bijhouden van documentatie, maar nog niet op detail niveau. Creëer bijvoorbeeld een log, wat later gebruikt kan worden als bron voor de beheer documentatie. 

4. VerwachtingenVanaf het eerste moment moeten verwachtingen actief bijgestuurd worden. De verwachting mag niet zo zijn dat bij een 2e oplevering er een perfect product staat. Ook de business moet open staan voor experimenteren en discussiëren.

5. SamenNeem in het hele project de eindgebruikers mee in de ontwikkeling. Dit zorgt voor een gevoel van participatie en zorgt voor een zachte landing. Bij een harde landing moet de informatie die getoond wordt direct 100% correct zijn, anders zal de acceptatie graad nihil zijn. Als een zachte landing goed uitgevoerd wordt, dan accepteert de eindgebruiker ook dat er nog foutjes zitten in de tussen fases. 

Bovenstaande tips gaan voornamelijk over mindset en houding. Niet alleen de mindset en houding van het uitvoerende team, maar ook het helpen van de eindgebruikers (de business en stakeholders) bij het “begrijpen” wat er gebeurt tijdens het project.