Gepokt en gemazeld in het BI-speelveld zijn velen van ons tot de conclusie gekomen dat het oh zo bekende eenrichtingspad, genaamd waterval, vaker niet dan wel de juiste benadering voor een BI-traject is. Na een levendige discussie over project- en ontwikkelmethoden kwam de vraag boven drijven of agile het ei van Columbus is voor BI.
Naarstig zijn wij met z’n allen opzoek naar 'betere' methodes. Methodes om de broodnodige flexibiliteit te combineren met resultaatgerichtheid. Tegelijkertijd maken vrijwel alle aan agile gerelateerde werkwijzes een hernieuwde populariteit mee. In verschillende markten zien we het veelvuldig toegepast worden. Een link met de snel wijzigende projecten uit de BI-wereld is vervolgens snel gelegd. Gezien de dynamiek van deze projecten is de impact van agile wellicht zelfs groter dan elders in softwareland.
Is dat daadwerkelijk zo? Zien we de kern van agile, zoals samengevat in het agile-manifesto en hieronder benoemd, ongeacht de specifieke methodes zoals extreme programming, scrum etc. terug in onze projecten?
– Individuen en interactie boven processen en tools.
– Werkende software boven uitgebreide documentatie.
– Samenwerking met de klant boven contract onderhandelingen.
– Aanpassing aan wijzigingen boven het volgen van een plan.
De eerst genoemden sluiten de schuin gedrukte termen niet, maar ze zijn wel belangrijker in de agile-wereld.
Stel, we passen deze principes toe, leidt dat tot succesvollere BI-projecten? Zijn wij überhaupt in staat een project volledig agile uit te voeren? Zijn onze tools voldoende flexibel om op dergelijke wijze te ontwikkelen? Zijn wij vervolgens instaat een dergelijke opdracht te verkopen aan onze opdrachtgevers of kunnen zij voldoende personeel vrij spelen voor deelname aan de verschillende iteraties?
Tig vragen, met duizenden mogelijke antwoorden en nuanceringen. De kernvraag blijft ‘worden agile-methodieken geadopteerd en toegepast in de BI-wereld?’ Ontwikkelen we rapportages volgens pair programming, elke dag starten met een scrum-meeting of stiekem toch nog DSDM? Ongeacht de methode kijk ik uit naar de ervaringen van de andere BI-experts en BI=-specialisten. Wat zien jullie? Een hersenspinsel, een hype of de volgende grote stap in BI-ontwikkeling?
Kristiaan Soomers & Ivo van der Heijden
Zelf heb ik getest in een ‘agile’ BI-traject, een project waarbij de specs van de rapportages frequent wijzigden en waarin door intelligentere queries steeds meer functionele mogelijkheden tot onze beschikking kwamen. Conclusie vanuit het testen was dat je veel met het team moet communiceren, overleggen bijwonen en aantekeningen maken van besluiten. Meer dan de gemiddelde tester gewend is.
De hoeveelheid data was wel een probleem: een enkele testrun op de volledige dataset kostte soms vier uur. Da’s geen korte feedback loop meer! Dus we hebben veel tests op extracts van data uitgevoerd, om in een later stadium te testen op de volledige data. Dat werkte prima.
Overigens: daily stand ups en pair programmen hoeven niet specifiek agile te zijn, die kun je ook in ‘gewone’ trajecten doen (en daar veel voordeel uit halen).
@Anko Tijman
duidelijk punt over de hoeveelheid tests en communicatie hierom trend die uitevoerd worden binnen een snel wijzigend traject. Ik ben ook erg benieuwd naar de samenwerking met de opdrachtgever, hoe verliep die?
Wij – Pentaho – beginnen nu ook klanten te hebben die dit toepassen. Belangrijkste drijfveren waren korte, snelle en vooral duidelijke milestones via sprints gebaseerd op use cases die naar “best effort” ge?mplementeerd werden. Show often & early aan de business kant, was zo’n beetje de insteek.
De schrik om 3-6m te verdwijnen en daan maar te hopen dat het goed zou zijn voor de eindgebruikers houdt te veel risico’s in. Het was ook een manier om de scope van die use cases enigszins bevroren te krijgen.
Binnen Pentaho gebruiken wij trouwens ook deze methodologie voor onze eigen ontwikkeling. En ook daar zien wij v??l voordelen in, bijv. vanuit sales hoeven wij niet te wachten op een productrelease alvorens te zien wat er gaat komen…
Volmondig ja, het toepassen van Agile technieken leidt tot succesvollere BI. Het is de ideale manier om snel tot een oplossing te komen die aansluit bij de wensen van de klant. E?
en grote maar: zowel de BI consultants als de klant moeten goed begrijpen wat Agile is en hoe je het toepast. En dat blijkt lastig. Consultants begrijpen niet goed genoeg wat Agile inhoudt, de klant durft geen project te starten waarvan de uitkomst niet is uitgekristalliseerd en het stellen van prioriteiten (en dus het maken van keuzes) is een frustrerende aangelegenheid. Forceer het niet, maar pas Agile elementen op maat toe, waarbij het kennisniveau van consultants en klant leidend is.
Ik ben absoluut een voorstander van agile ontwikkelen in een BI-context. Kijkend naar de vragen waarmee het artikel eindigt denk ik dat de implementatiepartners prima in staat zijn om op deze wijze te ontwikkelingen. Ook aan de kant van de tooling zie ik geen grote struikelblokken. De grootste showstoppers verwacht ik aan de kant van de opdrachtgever. Het verkopen (of kopen) van een product dat beperkt gespecificeerd is is lastig en impliceert een groot vertrouwen in de verkopende partij. Daarnaast zie ik bij veel projecten dat de opdrachtgever, ofschoon van goede wil, de te besteden tijd onderschat. Vooral dit laatste punt kan het succes van BI-projecten (agile of niet) maken of breken.
Is Agile de juiste ontwikkelmethode voor BI? Elke ontwikkelmethode die rekening houdt met de specifieke ‘eigenaardigheden’ van Business Intelligence is in ieder geval beter dan een die dat niet doet. Dat heeft Agile dus sowieso voor op de klassieke watervalmethodieken.
BI draagt weliswaar bij aan de business doelstellingen maar vooraf is vaak niet bekend in welke mate. Ook zijn de business requirements aan het begin niet altijd even duidelijk. Tenslotte is het ontwikkelproces dan ook nog eens vrij lineair (bron, ETL, datamodel, datamart, rapport, eindgebruiker). De uitdaging bestaat dan ook hoe om te gaan met het voortschrijdend inzicht dat ontstaat.
Agile draagt daar aan bij door: korte iteraties, used cases, snelle & frequente opleveringen, meenemen voortschrijdend inzicht, nauwe samenwerking met de klant, geintegreerd testen, etc.
De kernvraag blijft ‘worden agile-methodieken geadopteerd en toegepast in de BI-wereld’?
Het antwoord daarop is simpel: Agile is all in the mind. Het is niet de vraag of BI projecten Agile KUNNEN worden uitgevoerd, het is de vraag of BI mensen het daadwerkelijk WILLEN.
Als uitvoerend BI consultant heb ik beide typen projecten meer dan eens meegemaakt; volledig gestructureerde en gefaseerde waterval projecten met een informatie analysefase, een ontwerpfase en een bouwfase aan de ene kant en ‘anarchie’ aan de andere kant. Hoewel ik me kan voorstellen dat een opdrachtgever de risico’s die kleven aan ‘anarchie’ projecten weinig aantrekkelijk zal vinden, kom ik daarentegen doorgaans tot de conclusie dat de volledig structureerbare projecten
eigenlijk geen BI projecten zijn. In mijn visie omvat een BI project het gericht zoeken en presenteren van nieuwe kennis uit bestaande of nieuwe interne/externe
bedrijfsgegevens om daarmee operationeel/tactisch of strategisch voordeel te behalen. Hoe is de ontdekking en ontsluiting van nieuwe kennis vooraf te faseren? Hoe kan
je eventuele vervolgstappen of verfijningen op voorhand voorzien? Heeft Newton de ontdekking van de zwaartekracht eigenlijk wel gepland? Watervalprojecten zijn dus geen BI projecten maar rapportage projecten. Een BI project heeft een andere methodologie nodig, een methodologie die pas de eindfasen bereikt wanneer de
opdrachtgever voldoende nieuwe kennis heeft verworven (of deze zoektocht niet meer wenst te financieren). Als Agile methodieken in staat zijn echte kennisprojecten te faciliteren, dan ben ik een Agile fan.
Binnen de software development hebben we de laatste decenia geleerd dat in veel situaties een waterval methode minder geschikt is. Het loont de moeite om al in een vroeg stadium flexibel om te springen met de samenwerking tussen business en IT bij de realisatie van Data Warehouse oplossing. Juist bij dit soort oplossing blijkt het moeilijk te zijn om de specificaties exact te formuleren. Het bouwproces zelf kan voor een belangrijk deel bijdragen aan het inzicht in de eigen informatiewens, en bijgevolg bijstelling ervan. Alhoewel er ook argumenten tegen de toepasbaarheid van Agile binnen de BI te noemen zijn ben ik een groot voorstander.
In de praktijk verdient het aanbeveling om niet strikt alleen maar een methode als Agile toe te passen bij de realisatie van BI oplossingen. Ook andere methodieken hebben belangrijke verbeteringen op de waterval methode meegebracht. Het is dan ook nuttig om per situatie te bekijken welke principes uit welke methodes nuttig kunnen zijn binnen BI ontwikkeling. We zijn als vakgebied al heel wat stappen verder gekomen, dus gebruik die kennis.
Zijn wij uberhaupt in staat een project volledig agile uit te voeren?
Ik denk dat wij weinig keus hebben, vanuit de BI Awards hebben wij gezien dat de opdrachtgever niet (meer) geduldig is. Men wil BI inzetten om de business te ondersteunen, innovatie, nieuwe initiatieven, problemen oplossen, eerder weten wat goed en wat fout gaat. De reactie van een BI team moet op iedere verzoek zijn ‘Het antwoord is Ja, maar wat is de vraag?’
Zijn onze tools voldoende flexibel om op dergelijke wijze te ontwikkelen?
De tools zijn het probleem niet, al jaren niet meer. De snelheid en flexibiliteit van ontwikkeling die door de moderne versies van SAP BusinessObjects, QlikView en dergelijke aangeboden wordt is ruim voldoende, het probleem ligt bij de mensen ? durft men de risico te nemen?
Zijn wij vervolgens instaat een dergelijke opdracht te verkopen aan onze opdrachtgevers of kunnen zij voldoende personeel vrij spelen voor deelname aan de verschillende iteraties?
Het korte antwoord is Nee, meestal niet. Een goede BI project is nooit klaar, en dat is moeilijk te verkopen. Men verwacht, net zoals het bouwen van een brug dat het op een goede moment af is, en dan blijft alleen onderhoud over, met veel minder mensen en veel lagere kosten en dat is niet zo. Hoe moeilijk dat ook is moeten wij meer naar de opbrengsten kijken en minder naar de kosten.
Effectieve BI/PM draait om het voortdurend kunnen ontdekken en veranderen van de behoeften. De klassieke manier van omgaan met behoeften is verantwoordelijk voor de meeste problemen in BI/PM projecten, het snel kunnen opleveren van producten is kritische succesfactor nummer 1 voor BI/PM. BI-Team werkt daarom altijd volgens de agile methode, met successen bij vele bekende en ook grote organisaties. De tools zijn al sinds 1984 beschikbaar, het heet: Spreadsheet friendly OLAP. Excel als client voor een in-memory OLAP server is de sleutel tot effectieve BI/PM. Producten komen van diverse leveranciers zoals o.a. het open source PALO project van Jedox en TM1/Xcelerator van IBM/Cognos. Het bestaan van BI-Team bewijst dat agile projecten verkocht worden. Maar het vraagt wel een toegesneden verkoopproces, waarbij het vooral gaat om het opbouwen van het vertrouwen van de klant. Naarmate gebruikers zelf meer met de tools kunnen doen werkt BI/PM beter, wat optimaal het geval is met ‘Spreadsheet friendly OLAP’. Directe betrokkenheid bij echte informatie, maakt dat gebruikers beschikbaar willen zijn. Zie voor uitgebreide informatie over agile BI/PM de BI-Team whitepapers: ” BI-Team Implementation Methodology”, “Succesvolle BI is geen toeval” en “BI-Team Referentie Architectuur”. Kortom agile is de bewezen meest geschikte aanpak voor BI/PM, de juiste tools zijn beschikbaar, de gebruikers begrijpen het voordeel goed en maken zich beschikbaar.