BI en Agile, Droomhuwelijk?

of toch niet?

De afgelopen tijd heb ik me ernstig verdiept in Agile methoden en technieken. Natuurlijk heb ik wel in wat projecten gewerkt waar scrum werd gebruikt, maar waar ging het nu echt over. Gewapend met de Agile and Iterative Development: A Manager’s Guide van Craig Larman begonnen met het onderzoeken van de basis van Agile. Dan kom je natuurlijk bij de bron: Het Agile Manifesto.

De grote vraag die ik mezelf stelde: BI en Agile, is dit een droomhuwelijk? Agile is voor snelle ontwikkelingen en opleveren wat de klant nodig heeft. BI wil ook snel opleveren en opleveren wat voor de klant nodig is. Maar ja, datakwaliteit, tracebility, past dat allemaal wel?

Dus na het lezen van het boek van Larman meer research op basis van de de tips in het boek. Ook nog het BI Symposium bezocht, waar Agile centraal stond en de Agile en BI Conferentie van BI-Podium. Ik ben dus zeker geen expert op Agile gebied, maar er vallen mij wel een aantal zaken op.

Kijkend naar de principes van Agile uit het manifesto:

1. Personen en interacties boven processen en tools.

2. Werkende software boven uitgebreide documentatie.

3. Samenwerking met de klant boven onderhandeling over het contract.

4. Omgaan met verandering boven het volgen van een plan.

lijkt het een ideale combinatie. Want iedereen die in BI werkt weet dat de vragen van de afnemers van onze producten bijna sneller wijzigen dan wij ze kunnen bedenken.

Kijkend naar de principes van Agile is daar al de eerste valkuil. Dat ,wij van BI’ bedenken wat onze afnemers willen, is eigenlijk tegen de Agile principes. We moeten het samen bedenken, niet vooraf door de technici en dan hopen dat het klopt.

Een andere valkuil is de fabel dat het ineens allemaal sneller en beter gaat. Waar elke Agile deskundige het over eens is, is dat de organisatie en de klant er klaar voor moet zijn. Wat is dat dan, dat klaar zijn?
Een aantal zaken voeren de boventoon, hier een kleine greep: De klant moet beslissen wat de prioriteit is voor de business, in samenwerking met het team (vaak scrum team). Dit impliceert veel meer dan er staat. Dit betekent dat de klant geïnteresseerd moet zijn in de uitkomst van het traject. Tijdens het hele project. Dat hij of zij hier tijd, mensen en middelen voor wil vrij maken, een visie heeft waar hij of zij heen wil. Vanuit de deskundigen moet er een multidisciplinair team klaar zijn om met een klant samen te werken (echt te luisteren, genoeg kennis van de business om alles te begrijpen) met een werkomgeving die snelle ontwikkeling, verandering en deployment toestaat en faciliteert. Dus geen lange procedures naar productie, voldoende ruimte op de servers etc.

Agile methodes werken alleen als feed back tijdens de ontwikkeling verkregen wordt en meteen evaluatie en vasthouden leermomenten na de ontwikkelingsperiode (sprint) plaats vindt.

Andere uitdagingen die zo even in mij opkomen: Werkende software boven uitgebreide documentatie werkt misschien in een project, maar veel diensten in bedrijven vragen voor het onderhoud toch weer uitgebreide documentatie. Hoe borg je de kwaliteit van deze documentatie? Zijn er andere manieren? Misschien eerst maar eens met elkaar bepalen wat nu ‚genoeg documentatie’ is?

Ook de samenwerking met de klant boven onderhandeling over het contract … wow, best wel een statement. Jarenlang heb ik als consultant geleerd om pas te beginnen met een klus als het contract rond was, omdat het risico dat de klant niet betaald te groot is …

En dan het project voor de financiële afdeling, waar je gewoon van het plan afwijkt om om te gaan met de verandering. Dan kloppen de begrotingen dus ook niet meer, hoeveel tijd ga je besteden aan het aanpassen hiervan? En moet je dan weer door de beslissingsmolen van een bedrijf voordat je verder mag? Of is het project daarom achteraf niet volgens begroting en dus mislukt? (Hoewel er nu wel software staat die doet wat de bedoeling is?).

En dan natuurlijk de IT deskundige. Samenwerken met de klant, dus als de klant zegt dat het zo goed genoeg is, dan het ook zo doen. Ik kan me zo voorstellen, dat je als IT deskundige die al jaren verteld aan de klant wat goed voor hem of haar is, dat dit nogal een aardverschuiving is. Natuurlijk ga je nu niet stoppen met nadenken, maar je moet je klant echt goed vertellen waarom dingen nodig zijn, zodat hij of zij de beslissing kan nemen. Dus BI-er, leg maar even uit wat datakwaliteit is en waarom het echt moet … in ‚mensentaal’, niet in vaktermen.

Kortom: BI en Agile ik denk dat we nog veel moeten ontdekken, maar dat het in de basis prima bij elkaar past. Daarom hoop ik dat bedrijven het Agile gedachtengoed niet alleen voor IT projecten gaat adopteren, maar dat het hele bedrijf mee gaat in deze stroming zodat er een echte fijne samenwerking komt van de business kant en de IT deskundigen. Samen voor een eindresultaat in plaats van ieder zijn of haar deelverantwoordelijkheid. Ik kijk er naar uit.

Dit artikel is eerder verschenen in de online versie van Computable