Zo werkt agile in de praktijk

Zo werkt agile in de praktijk
Agile development is al jaren de standaard voor softwareontwikkeling. Steeds meer klanten willen weten of agile ook toegepast kan worden binnen het business intelligence-domein. Ja, een agile methodologie biedt een perfecte oplossing voor traditionele ‘delivery’-problemen.
Ron Pooters
Er is nog steeds veel onwetendheid over agile bij business intelligence-management. Er is angst dat agile principes niet conform interne en externe richtlijnen zijn en uiteindelijk leiden tot chaos. Agile principes (zoals de snelle en incrementele oplevering van functionaliteiten, de simpliciteit van de methodologie en het openstaan voor veranderende requirements) hebben ervoor gezorgd dat we tegenwoordig omringd worden door kwaliteitsvolle applicaties op het web, de smartphone of de tablet. Zij evolueren razendsnel en worden adequaat aangepast aan de wensen van eindgebruikers. Google heeft bijvoorbeeld in vier jaar tijd liefst 21 stabiele versies van zijn Chrome-browser uitgebracht. Zonder het gebruik van een agile methodologie zou dit onmogelijk zijn.
Essentie van agile
Ook binnen de wereld van business intelligence lijken deze principes een welkome verandering te bieden ten opzichte van de traditionele methodologieën. Geen wonder als je weet hoe weinig projecten op tijd, binnen budget én naar volle tevredenheid van de eindgebruiker worden opgeleverd. Een agile methodologie levert kleine werkende stukken software op in iteraties, ook wel sprints genoemd. Een agile project bestaat uit meerdere iteraties die meestal een vaste beperkte duur hebben. Dit in tegenstelling tot traditionele methodologieën die pas aan het einde van het traject alle software tegelijk opleveren. Voor het begin van een iteratie wordt de lijst van businessnoden, of in agile-termen ‘user stories’, herzien en wordt een subset van businessnoden geselecteerd die in die iteratie ontwikkeld zullen worden. Agile is overigens niet één methodologie, het is eerder een manier van werken die door verschillende methodologieën zoals scrum, Extreme Programming en andere geïmplementeerd wordt.
De drie bepalende dimensies van iedere developmentmethodologie zijn kosten, tijd en scope. Bij een traditionele methodologie wordt in het begin van het traject de scope bepaald, met een veelal gedetailleerde inschatting van de kosten en de tijd. In theorie is het eindproduct exact wat de klant gevraagd heeft, al dan niet binnen de voorziene tijd en ingeschatte kosten. Bij agile legt men de tijd en de kosten vast. Binnen deze harde grenzen speelt men met een steeds veranderende scope. De gedachtegang is dat men bij agile een product wil opleveren dat beantwoordt aan de huidige requirements van de klant, niet aan een lijstje van requirements dat een half jaar of langer geleden werd opgesteld.
Draagvlak
Er is meer en meer interesse voor agile vanuit de business intelligence-wereld, maar agile
business intelligence is zeker nog geen gemeengoed. Er is niet alleen nog steeds onwetendheid bij business intelligence-managers, ook maken de karakteristieken van business intelligenceapplicaties het ogenschijnlijk lastig om traditionele agile methodologieën toe te passen. In tegenstelling tot softwarepakketten bestaan business intelligence-applicaties uit een aaneenschakeling van heterogene componenten en afhankelijkheden, waarbij kleine wijzigingen in de ene component grote impact kunnen hebben op de andere. Wil een agile methodologie werken voor business intelligence-applicaties, dan zijn enkele aanpassingen nodig op het gebied van type iteraties, user stories en type medewerkers in het ontwikkelingsteam. Ook is het moeilijk om een agile methodologie te volgen als andere actoren binnen het business intelligence-project een traditionele ontwikkelingsmethodologie gebruiken.
Gelukkig kunnen de bestaande agile methodologieën relatief eenvoudig aangepast worden. Deze methodologieën kunnen, als ze slim worden uitgerold en toegepast voor welgekozen business intelligence ‘use cases’, het verschil maken tussen tevreden en ontevreden eindgebruikers en zo de houding van het management ten opzichte van agile business intelligence positief veranderen.
Accenture heeft op basis van ervaringen bij en vragen van klanten presentaties over agile business intelligence gecreëerd om de misvattingen en vooroordelen uit de wereld te helpen en uit te leggen hoe agile binnen hun business intelligence-organisatie zou passen. Toch kan alleen het (op kleine schaal) in de praktijk gebruiken van een agile business intelligence-methodologie aantonen of het de juiste oplossing is voor een onderneming. Voor je een agile methodologie invoert is het belangrijk te zorgen voor voldoende draagvlak bij projectmanagement en -sponsors, bij eindgebruikers en IT-personeel. Anders is er een risico dat een agile project bij de eerste tegenslag wordt stilgelegd.
Relevantie
Hoe relevant is agile voor business intelligence-projecten? Bij een grote Europese telecomoperator stelde Accenture voor om een agile methodologie te gebruiken voor het opleveren van een business intelligence-project rond customer cost analysis. De bedoeling van customer cost analysis is berekenen hoeveel een klant de operator effectief kost. Daarvoor moesten acht databronnen geïntegreerd worden, zoals facturatie, call detail records (CDR’s) van het netwerk, klantrelatiebeheer (CRM), et cetera. De reden waarom Accenture een agile methodologie voorstelde was dat de telecomoperator worstelde met tijd- en budgetproblemen bij enkele complexe projecten. Deze problemen waren te wijten aan:
• de lange looptijd tussen het identificeren van de businessnoden en de effectieve oplevering van de oplossing;
• te weinig communicatie tussen de verschillende actoren;
• weerstand bij eindgebruikers omdat ze niet betrokken waren bij de realisatie van het systeem;
• de rigide structuur van het traditionele watervalmodel waarbij het moeilijk is om een stap terug te zetten en bijvoorbeeld het design te veranderen op basis van voortschrijdend inzicht.
Agile biedt een antwoord op al deze punten. De iteratieve aanpak zorgt ervoor dat er een snelle oplevering is van functionaliteiten en dat er ruimte is om veranderingen in te passen in volgende iteraties.
Het feit dat agile veronderstelt dat de eindgebruikers intensief betrokken zijn bij de ontwikkeling van het systeem zorgt voor betere communicatie en verminderde weerstand bij de eindgebruiker,
die voelt dat hij een rechtstreekse invloed op de ontwikkeling van het systeem heeft.
Bij de telecomoperator kon de initiële weerstand tegen agile business intelligence snel omgedraaid worden in een positieve nieuwsgierigheid naar de mogelijkheden. We wezen op het feit dat ze de methodologie al jaren succesvol toepassen voor hun eigen softwareontwikkeling en dat kleine aanpassingen rekening houden met de specifieke eigenschappen van business intelligenceprojecten.
Eigenschappen
Wat zijn de specifieke eigenschappen van business intelligence-projecten? Een standaard agile methodologie kan niet zonder meer toegepast worden op business intelligence-projecten zoals het wordt toegepast bij de ontwikkeling van softwareapplicaties. Een eerste grote tegenstelling met een softwareapplicatie is dat een datawarehouse geen eindstation is; het vormt typisch een belangrijke component binnen een lange ketting van heterogene applicaties. Elke wijziging aan het datawarehouse kan dus gevolgen hebben voor de downstream applicaties. Te allen tijde moeten de bestaande en afgesproken architectuurprincipes gevolgd worden. Een voorbeeld van architectuurprincipes is het verplicht gebruik van de verschillende lagen in een datawarehouse, zoals de staging-laag (waar de data worden voorbehandeld), de datawarehouse-laag (waar de data worden geïntegreerd en opgeslagen) en de presentatielaag (die de data presenteerbaar maken naar de eindgebruiker) of het gebruiken van een bestaand data replicatiesysteem dat in geval van problemen zorgt dat data niet verloren gaan.
Door de complexe aaneenschakeling van applicaties is het testen van datawarehouseontwikkelingen niet vanzelfsprekend. In veel gevallen zijn er dagen voorbereiding nodig om systemen te aligneren en data klaar te zetten. Dit valt moeilijk te rijmen met een typische dertig dagen-iteratie of sprint in bijvoorbeeld de scrum-methodologie. Een ander probleem is de complexiteit van user stories in de context van een datawarehouse. Een op het oog simpel lijkende user story ‘toon verkoopcijfer voor productfamilie x’ moet eigenlijk nog verder opgedeeld worden in kleinere stories per business intelligence-applicatie, zoals ‘extraheer verkoopcijfers uit ERP-pakket (data-extractie of ETL-applicatie)’, ‘voeg tabel toe in datawarehouse (database applicatie)’, ‘bouw/ verrijk rapport (rapporteringsapplicatie)’ et cetera. Maar dit zijn bezwaarlijk nog ‘user’ stories te noemen, omdat de eindgebruiker dit detailniveau niet kan aanleveren.
Van agile naar agile BI
De oplossing voor bovenstaande problemen is niet zo moeilijk. De agile business intelligencemethodologie die Accenture gebruikte voor de ontwikkelingen binnen het customer cost analysis project was gebaseerd op de standaard Scrum-methodologie, maar met een aantal essentiële aanpassingen:
• Specifieke sprints: binnen business intelligence-projecten is er behoefte aan specifieke sprints. Zo kunnen architectuursprints toegevoegd worden aan een project om te zorgen dat de in aanbouw zijnde oplossing binnen de bedrijfsarchitectuur past. Deze sprints leggen de reguliere ontwikkelingen kortstondig stil om kritische architectuurproblemen op te kunnen lossen. Mocht dit korter duren dan een reguliere sprint en is er een focus op een specifiek onderwerp, dan spreekt men van een ‘spike’.
• Verschillende type rollen: ook het team van mensen binnen een agile business intelligenceproject is meer divers. Zo kan er een noodzaak zijn om een enterprisearchitect, datamodeler, projectmanager, notulist of een bepaalde expert toe te voegen aan het team.
• Hiërarchie van user stories: het toevoegen van een hiërarchie geeft het agile team de mogelijkheid om complexe user stories op te delen in meerdere hapklare ‘technische’ stories. De eindgebruiker (of ‘productverantwoordelijke’ in agile termen) definieert de user stories tot op het niveau waar hij vertrouwt mee is. De technische ontwikkelaars brengen dan een diepere laag van technische stories aan.
• Pipelinen van sprints: het is niet noodzakelijk om na elke sprint de nieuwe code onmiddellijk in productie te stellen. De ontwikkelingen uit sprints kunnen opgespaard worden en vervolgens tegelijk in productie gesteld. Pipelinen van sprints is niet specifiek aan agile business intelligence; het wordt op beperkte schaal ook toegepast binnen standaard agile methodologieën.
Maar binnen business intelligence-projecten is pipelinen heel handig omdat de iteratieresultaten weliswaar werkende software bevatten, maar meestal niet relevant zijn zonder de resultaten van de andere iteraties.
• Hybride methodologie: agile hoeft niet binnen elke fase van een project toegepast te worden. Het is vooral sterk binnen de executiefase, als er daadwerkelijk ontwikkeld wordt. Zo is het perfect mogelijk om bijvoorbeeld de analyse of de deployment volgens de traditionele manier uit te voeren. Dit is ook wat onderzoeksbureau Gartner adviseert: agile technieken kunnen het beste in combinatie met bestaande business intelligence best practices en methodes worden gebruikt 1.
Figuur 1 geeft een versimpeld beeld van een mogelijke hybride methodologie voor een agile business intelligence-project waarbij business case, analyse en deployment volgens de traditionele watervalmethode worden uitgevoerd. De ontwikkelingen worden via een agile methode uitgevoerd en vervolgens gepipelined tot één deployment op het einde van het project. Uiteraard zijn er ontelbare andere mogelijkheden voor het opleveren van een project, gebruikmakend van een hybride methodologie.
Figuur 1. Mogelijke hybride methodologie voor een agile business intelligence-project
 
Praktijk
Hoe ziet de praktijk eruit? Het toepassen van deze eenvoudige aanpassingen heeft het mogelijk gemaakt om de agile business intelligence-methodologie succesvol te gebruiken voor het customer cost analysis project. Tijdens de opstart- en analysefase van het project werden de noden van de gebruikers (user stories) opgetekend en geprioritiseerd volgens de traditionele en beproefde manier van werken. Vervolgens werd het project opgedeeld in meerdere sprints en werden de user stories verdeeld over de sprints.
Zoals agile voorschrijft was er een zichzelf organiserend team van ontwikkelaars, zowel beginnen de als meer ervaren ontwikkelaars. Ook werden een architect en een projectmanager aangesteld. De architect moest zorgen voor alignering met bestaande business intelligence-richtlijnen en architectuurregels. De projectmanager hield zich vooral bezig met administratieve activiteiten en was maar zijdelings betrokken bij het organiseren van de dagelijkse activiteiten. In tegenstelling tot de chaos die velen verwachtten, leidde dit tot meer betrokkenheid van de ontwikkelaars. Dit resulteerde in verschillende innovatieve ideeën en oplossingen: de agile methodologie gaf hen meer vrijheid.
Bij het begin van elke sprint werden de user stories geherprioritiseerd en ingeschat samen met de eindgebruikers. Voor sommige user stories hield dit in dat ze eerst moesten worden opgedeeld in meer gedetailleerde technische stories. Soms moesten er zelfs technische stories toegevoegd worden die niet rechtstreeks voortkwamen uit de business noden. Een voorbeeld hiervan was het creëren van een framework voor het opvangen van data-integratiefouten. Direct samenwerken met de eindgebruikers bleek ook een positieve invloed te hebben op het aantal ‘change requests’. Te vaak werken in een traditionele projectaanpak businessanalisten die de ‘single point of contact’ tussen IT en eindgebruiker vormen. Iedereen die als klein kind het fluisterspel heeft gespeeld (waarbij je in een kring zit en een persoon een zin fluistert in het oor van de persoon naast hem en zo verder totdat je terug bij het begin bent) weet dat er een risico is dat een businessnood die via de businessanalist bij de ontwikkelaar komt niet meer identiek is aan de oorspronkelijke formulering van de eindgebruiker.
Alle ontwikkelingen werden in een ‘sandbox’omgeving gedaan die een afspiegeling was van de productieomgeving. De ontwikkelingen werden vervolgens gepipelined totdat alle iteraties tegelijk naar productie gepromoveerd werden. Voor het testen werd geheel volgens de agile principes een lijst van testscripts gemaakt die elke nacht automatisch werden gedraaid op de laatste versie van de code. Zo werden structurele fouten snel gedetecteerd en gecorrigeerd. Het hele project werd opgevolgd volgens een reguliere projectmanagementstandaard en voldeed aan de vereiste interne en externe richtlijnen.
Zelfcorrigerend
Uiteraard waren er ook uitdagingen in het gebruik van de agile business intelligencemethodologie. Zo gaat een van de agile principes bijvoorbeeld uit van een intensieve betrokkenheid van de eindgebruiker bij de ontwikkeling van de oplossing. In werkelijkheid bleek dat na enkele weken de eindgebruikers niet meer dezelfde betrokkenheid toonden en afwezig waren op de afgesproken reguliere checkpoints omdat ze zich weer voltijds gingen richten op hun belangrijkste taak: zorgen dat het bedrijf blijft draaien.
Ook de samenwerking met andere departementen binnen het bedrijf die geen agile methodologie gebruiken verliep soms stroef. Er was onbegrip aan weerszijden: het agile team dat snel, efficiënt en met minimale administratie een taak wil volbrengen en andere teams die nauwgezet de regels volgen om te allen tijde te voorkomen dat er gevaarlijke fouten gemaakt worden op het gebied van veiligheid of wettelijke regelgeving. Gelukkig voorziet de agile methodologie in een zelfcorrigerende activiteit: op het einde van iedere iteratie is er een moment voorzien waarbij wordt stilgestaan bij de zaken die werkten en de zaken die niet werkten. In het geval van de betrokkenheid van de eindgebruikers werd ervoor gezorgd dat de eindgebruikers voldoende tijd inruimden voor het customer cost analysis project zonder dat dit een te grote impact zou hebben op hun hoofdactiviteiten. Ook hierbij was het essentieel dat het management voldoende ondersteuning bood.
Op het gebied van samenwerken met andere departementen werd de tijd ruimer ingeschat, zodat deze departementen volgens hun eigen regels konden blijven werken zonder het project op te houden. Bij een agile methodologie zijn ‘lessons learned’ dus geen ‘afterthoughts’ die pro forma worden opgesteld en dan ergens in een (digitale) la verdwijnen; ze kunnen meteen worden ingevoerd in de volgende iteratie.
Minder projectrisico’s, lagere kostenHet customer cost analysis project werd tot volle tevredenheid van de stakeholders opgeleverd. Om de impact van de agile methodologie te kwantificeren werd er een vergelijking opgesteld met andere business intelligence-projecten van eenzelfde omvang die met de traditionele methodologie waren opgeleverd. Zoals duidelijk weergegeven in figuur 2, blijkt een incrementele oplevering van functionaliteiten tot kleinere projectrisico’s te leiden en levert het vervolgens minder vertragingen en last minute veranderingen op. Dit resulteert uiteindelijk in lagere projectkosten.

 

Figuur 2. Vergelijking tussen business intelligence-projecten met agile methodologie en met traditionele methodologie.

 
Conclusie
Waarop moet u letten voor u start met agile business intelligence? Een agile methodologie biedt een perfecte oplossing voor traditionele ‘delivery’-problemen die grote en complexe business intelligence-projecten parten spelen. Door enkele kleine aanpassingen te doen, houdt u rekening met de specifieke eigenschappen van business intelligence-projecten:
• Als u agile business intelligence binnen een organisatie uitrolt, zorg dan voor voldoende draagvlak en voldoende tijd om de methodologie waar nodig bij te sturen en aan te passen aan de specifieke context. Kies voor een eerste agile business intelligence-project voor een project met een lage complexiteit op het gebied van data-integratie en met een duidelijk meetbare ‘business value’. Kunt u onvoldoende draagvlak creëren bij de verschillende actoren, stel dan alsnog voor een beperkte proof of concept uit te voeren en achteraf de resultaten te demonstreren.
• Zorg voor voldoende ervaring in het team en probeer te werken met allrounders, zoals ontwikkelaars met een zekere businessaffiniteit, aangevuld met enthousiaste en leergierige personen die minder ervaring hebben.
• Gooi niet alle verwezenlijkingen op het gebied van best practices, richtlijnen en ‘lessons learned’ overboord. Probeer agile toe te passen in de fases waarin dit het meest zinvol lijkt en gebruik vertrouwde methodes voor andere fases van een project.
 
Ron Pooters is business intelligence manager en associate principal bij Accenture België. E-mail: ron.pooters@accenture.com, twitter: @RonPooters Meer informatie: www.accenture.com/BI
 

Tag

BI

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag