In de BI-wereld wordt ervaring opgedaan met de Agile-methode. Idee is dat deze methode de gebruikers en de ontwikkelaars op een flexibele manier bij elkaar brengt. Bij recente ervaringen blijkt dat de principes van Agile niet makkelijk overeind blijven als de deadline van het project nadert. De flexibiliteit in de aanpak kan dan gaan aanvoelen als richtingloosheid. Een flexibele opstelling biedt de gebruikers ten slotte ook de mogelijkheid tot op het laatste moment van gedachte, en dus ook wensen, te veranderen.
Bij het naderen van de deadlines grijpt de ervaren ontwikkelaar dan toch snel terug op het herkenbare gevoel van zekerheid. Dat uit zich in een behoefte om functionaliteit concreet gespecificeerd te hebben, want specificaties geven zekerheid en zekerheid geeft rust. Op dat moment grijpt men graag terug naar de technieken van de overbekende wereld van de waterval.
We kunnen natuurlijk Agile snel vergeten en besluiten dat deze aanpak voor BI niet geschikt is. Of kunnen alternatieven onder de loep genomen worden? Gevoelsmatig is de gebruikersgeoriënteerde aanpak van Agile zeer geschikt voor BI. Tenslotte ligt bij BI de functionele basis in de wensen voor rapportages. Ervaren BI'ers weten dat gebruikers pas realiseren wat ze willen, nadat ze een eerste implementatie van een rapportage gezien hebben. Dat is namelijk het moment dat de creativiteitsmotor gaat draaien.
Maar wat is dan toch de reden dat het moeilijk is om van een vertouwde, gecontroleerde manier over te stappen op de Agile-aanpak? Kan het zijn dat met Agile het spel verandert, maar dat de BI'er zijn spelregels nog niet heeft aangepast? Als een American Football-speler rugby gaat spelen, dan moet deze persoon ongetwijfeld ook wennen aan het feit dat rugby veel dynamischer is en veel minder onderbrekingen heeft. Bij American Football wordt ten slotte na elke uitgespeeld scenario het spel stilgelegd voor overleg over het volgende te spelen scenario.
Wat mij betreft moeten BI'ers dus eens goed kijken naar de actuele spelregels voor het ontwerpen en ontwikkelen van BI-oplossingen. Klassieke datamodeltheorieën en de technische uitwerking hiervan zijn niet bedacht met de intentie flexibiliteit in het proces te introduceren. Zonder de spelregels aan te passen op het gespeelde spel, zal het toepassen van de Agile-methode gedoemd zijn te mislukken.
Het lastige met Agile binnen de BI is naar mijn idee dat niet alleen de BI-ontwikkelaars open moeten staan voor Agile, maar ook de directe omgeving.
Wil Agile goed werken, dan moeten de testers bereid zijn om in kleine blokken (use case en/of iteratie) te testen, waarbij het doel per iteratie gewijzigd kan zijn. Daarnaast moeten beheerders bereid zijn om de kleine blokken in productie te zetten. Dit betekent dat ook testers en beheerders Agile moeten werken.
Mijn ervaring is dat beide partijen hier nogal moeite mee hebben waardoor projecten vervallen in sub-Agile oplossingen als Agile bouwen, maar volgens Waterval testen en/of naar productie. Daarmee wordt de kracht van Agile binnen BI sterk beperkt.
In de klassieke BI is de deadline meestal vrij hard. Na maanden ontwikkelen, testen en accepteren kan de gebruiker dan eindelijk aan de gang. Pas in tijdens acceptatie zullen de eerste creatieve processen gestart worden, maar pas tijdens werkelijk gebruik in de praktijk blijkt de echte bruikbaarheid van de BI-oplossing.
Door de lange wachttijd zijn de verwachtingen hoog en gespannen. Als het project dan ook nog eens uitloopt, wordt het extra pijnlijk is als de resultaten dan ook nog eens tegenvallen. Ondanks dat er exact gebouwd is wat was gespecificeerd.
Termen als “deadline” en “uitoop” zijn hiermee erg zwart-wit geworden.
Door de Agile methode te volgen in al zijn facetten, dus inclusief de grote betrokkenheid van de eindgebruiker, de tester en de beheerder, zullen de creatieve processen van de eindgebruiker veel eerder gestimuleerd worden. Door kleine tussenresultaten in een productie-omgeving beschikbaar te stellen kan de gebruiker dat deel van de oplossing al aan de praktijk toetsen.
Hierdoor kan deze in een veel eerder statium het pad bijsturen naar het werkelijke (vaak vooraf nog onbekende) eindresultaat. Bovendien kunnen nu ook productie-specifieke problemen eerder naar boven komen.
Hierdoor wordt de kans op uitloop juist verkleind. Fouten en wijzigingen worden eerder gevonden, eerder doorgevoerd en hebben minder impact op het gehele systeem. Wordt nu het roer volledig omgegooid, dan zal dat sneller en veel geleidelijker worden ingezet waardoor ook dan de impact veel kleiner is, soms zelfs onmerkbaar klein.
Belangrijker is dat er al een deel van de oplossing in productie staat. Bij het naderen van de deadline is zelfs het overgrote deel al in productie, wordt al gebruikt en is dus ook bewezen bruikbaar! Vaak zijn het de minder noodzakelijke stukken waar de uitloop op van toepassing is.
Termen als uitloop en deadline worden hierdoor veel minder zwart-wit. De oplossing wordt immers al deels gebruikt en de eerder beschreven kans op teleurstelling is al volledig weggenomen.
De grotere betrokkenheid maakt zelfs dat het niet halen van een deadline als begrijpelijk en acceptabel kan worden ervaren.
Mijns inziens is Agile uitermate geschikt, zelfs zeer wenselijk, voor BI-projecten.
Zoals met elke methode geldt echter ook hier dat Agile alleen werkt als deze gevolgd wordt in alle facetten, dus ook geadopteerd door de hele omgeving van het project.
@Arjan: prachtig betoog, waar ik het ook nog eens volledig mee eens ben. Het houdt echter niet op bij de testers, beheerders en gebruikers. Beter gezegd, het begint met een organisatie die in staat is op deze manier te werken, opdrachtgevers die een project op deze manier durven uit te laten voeren. Als we het kunnen ‘verkopen’, volgt de rest van het bedrijf vanzelf, mits de leidinggevenden het goede voorbeeld geven.
Een top-down aanpak, of is een bottom-up aanpak veel beter? Als we de mensen op de vloer weten te overtuigen, volgt het management vanzelf? Een kip-ei discussie, die eigenlijk weinig relevant is. Hoe je het ook doet, we zullen onze BI projecten hoe dan ook succesvoller moeten maken en Agility biedt daarvoor een kans. Gaat men ineens massaal overstag? Nee, natuurlijk niet, dat heeft tijd nodig. Mensen moeten overtuigd worden. Om te overtuigen kunnen zelfs de principes van Agile gebruikt worden, hoe toepasselijk. Iteratief moeten praktijkcases steeds weer en steeds sterker aantonen dat succes een logisch gevolg is. Wie weet zelfs de start van een frisse wind in ons BI projectlandschap. Het aanpassen van de spelregels is wat dat betreft een logische eerste stap.