Bij Incentro hebben we inmiddels heel wat Business Intelligence-opdrachten uitgevoerd op basis van scrum. Onze conclusie? De projecten verlopen lang niet altijd zoals de methodiek voorschrijft. Dit zette ons aan het denken: misschien zijn BI en agile werken tóch niet zo’n gelukkige combinatie. In deze blog onderzoeken we de oorzaken en bieden we oplossingen.

Agile werken levert je business – als het goed is – duidelijke voordelen op: de meeste toegevoegde waarde, op de kortst mogelijke termijn, in concrete producten. Dat resultaat, hoe klein dan ook, noemen we een minimal viable product (MVP). Dit product is in principe direct klaar voor gebruik en moet antwoord geven op de oorspronkelijke vraag of behoefte van de business.

business-waarde-over-looptijd-van-project

Als je een website bouwt, een documentmanagementsysteem ontwikkelt of een zoekmachine inricht, dan zijn de taken en resultaten relatief eenvoudig in kleine stukjes op te delen: de MVP’s. Daarom leent zo’n project zich uitstekend voor een agile-aanpak. Kijken we naar traditionele manieren van implementatie – neem de watervalmethode – dan zijn we er inmiddels allemaal wel van overtuigd dat het stukken efficiënter kan. Bovendien krijgt de eindgebruiker door de lange doorlooptijd vaak helemaal niet waar hij om vroeg. Agile werken is voor dit probleem sinds een aantal jaren dé oplossing, stelt Kisielnicki.

Maar werkt dit ook zo goed voor Business Intelligence? Bij BI-projecten moet je steeds data van verschillende bronnen toevoegen aan het datawarehouse, een aspect dat veel aandacht nodig heeft. Bijvoorbeeld om de architectuur op orde te krijgen, het datamodel aan te passen en nieuwe business rules toe te voegen. De MVP kan dan voorlopig nog niet in productie. Allemaal zaken die de business niet ziet, maar ze rekent er wél op deze terug te zien in de kwaliteit van de resultaten. Het verloop van de bouw van de functionaliteit (dat wat je oplevert aan de gebruiker) ligt daarom vaak buiten BI.

uitgangspunten-Scrum.org-BI-project-aangevuld-door-Incentro

Wil je een agile-aanpak loslaten op je BI-opdracht? Grote kans dat je hier tegenaan loopt:

1: business intelligence is geen softwareontwikkeling
Auteurs, experts en gebruikers zijn het er unaniem over eens: agile werken is geschikt voor softwareontwikkeling in kleine stand alone projecten. En dus niet voor BI-projecten. Deze projecten zijn over het algemeen veel te complex voor de agile-methodiek, concludeert Moss. Dat los je op door hier nadrukkelijk met de opdrachtgever over te spreken en de verwachtingen te temperen.

2: een tastbaar product heeft tijd nodig
Zeker bij traditionele BI, waarin je eerst een datawarehouse moet opbouwen om daarna een data mart te maken, heb je veel tijd en energie nodig om data goed te ontsluiten. Bovendien is het noodzakelijk om informatie te analyseren en de data over te brengen via ETL (extract, transport en load). Dit krijg je vaak niet in één sprint voor elkaar. Laat staan dat de business vanaf sprint 1 – zelfs als deze een maand duurt – al direct een tastbaar product oplevert. De concrete producten waar de business op wacht? Een dashboard, rapport of data dump, waarmee ze direct aan de slag kunnen. Beschrijf de producten in je sprint in de vorm van kleine acties die je kunt testen en afvinken in het developmentteam. Dat kun je dan laten zien aan de product owner en de rest van de organisatie. Veel concreter dan dit wordt het in eerste instantie niet.

3: datamanagement is niet agile
BI-projecten bestaan maar voor een klein deel uit softwareontwikkeling als scripts en code schrijven. Het overgrote deel is datamanagement. En dat past niet zo goed in agile werken. Denk aan data integration, data standardization, enterprise data modeling en meta data. De focus op omgaan met data en de complexiteit ervan, maakt geen onderdeel uit van de agile-methodiek. Maak de organisatie duidelijk dat je geen duurzame BI-oplossing kunt bouwen zónder datamanagement op orde te hebben. En laat weten dat dit (veel) tijd en aandacht vraagt.

4: magere datakwaliteit
In veel gevallen blijkt de data juist het probleem te zijn. Bijvoorbeeld als deze incompleet is, incorrect of bij integratie zelfs tegenstrijdig. De organisatie verwacht dat het BI-team dit wel even oplost en gewoon dashboards, rapporten en inzichten levert. Maar de functionaliteit (lees: de rapportages en het dashboard) kan alleen worden geleverd als de datakwaliteit goed genoeg is om betrouwbaar inzicht mee te verstrekken. Dit is vaak een punt van discussie. Hoe je dit oplost? Door de data in de oorspronkelijke bron te verbeteren of aanvullingen in het datawarehouse door te voeren. Het eerste vereist een actie van de organisatie en is een moeizaam proces. Het tweede is minder duurzaam, maar wel populairder.

5: denken versus doen
Agile werken bij softwareontwikkeling vraagt kennis van object-oriented programmeertaal, zoals Java, C++ en Python. Maar bij BI is vooraf veel denkwerk nodig. Bijvoorbeeld om de juiste architectuur te kiezen, en de verschillende databronnen en applicaties aan elkaar knopen, zodat alles naadloos met elkaar samenwerkt. Dit vraagt om een andere aanpak en een ander type ontwikkelaars. De oplossing ligt in een breder developmentteam, met meer ruimte voor structuur en inrichting. Zo kun je rekenen op een goed doordachte opzet en worden aanpassingen tot een minimum beperkt.

6: communicatie is key
Als het om rapportages en dashboards gaat, zijn de toekomstige gebruikers niet altijd even goed in staat voorafgaand aan de bouw de details van het gevraagde product te definiëren. Ze willen veel liever een voorbeeld zien en daarop commentaar geven, zodat het product kan worden bijgesteld. Dit vraagt om duidelijke afstemming met het ontwikkelteam. Wordt deze communicatie onderschat en ondergewaardeerd? Dan leidt dat vaak tot wederzijdse teleurstelling. Daarom is communicatie in elke fase van het project in elke sprint noodzakelijk. Neem de organisatie mee in je denkrichting, schets de oplossingen op papier, in demo’s of mockups.

Als Business Intelligence en agile werken elkaar het jawoord zouden geven, leven ze dan nog lang en gelukkig? Het antwoord daarop heeft nogal wat kanttekeningen. Het beste antwoord is waarschijnlijk: dat hangt van de omstandigheden af, het is geen match made in heaven, maar het kan wel.

Wat in elk geval werkt in een agile BI-project, is de scope van de sprints verleggen van de softwareontwikkeling naar de data-inspanning die je moet leveren om iets zinvols te bouwen. Neem daarbij alles rondom de data in ogenschouw: van denkwerk tot integratie. Hou er wel rekening mee dat wát er opgeleverd kan worden, uitermate klein is. Maar volgens de opzet van agile werken is dat het enige wat je kunt leveren: een volwaardig product met toegevoegde waarde voor de business. Scrum zegt tijd en kwaliteit staan vast en gaan boven functionaliteit. En daarmee is wat je levert dus lang niet altijd perfect, net als in een echt huwelijk.