De voordelen van scrum en smart

De voordelen van scrum en smart
Voortschrijdend inzicht omarmen, multidisciplinair samenwerken en software in korte iteraties opleveren: de agile aanpak wint terrein. Kan deze aanpak, zoals scrum en smart, een positieve bijdrage leveren aan business intelligence-projecten?
Het besparen van kosten is een veelgenoemde aanleiding voor business intelligence-projecten. Zo wilde een bekende overheidsinstantie weten hoe effectief de bestrijding van uitkeringsfraude was. Het onderzoeken van mogelijke fraude kost de instantie geld, maar het vinden van fraudeurs levert direct geld op. Dus ging de instantie op zoek naar de optimale verhouding tussen het aantal onderzoeken en het aantal opgespoorde fraudes. Kortgezegd wilde men met zo min mogelijk onderzoeken zoveel mogelijk fraudeurs vinden.
Deze doelstelling is typerend voor business intelligence-projecten. Hoewel de doelstellingen vaak concreet zijn te definiëren, is het realiseren ervan niet altijd evident. Welke rapportages moeten worden ontwikkeld? Wat staat daar in? Welke bronsystemen moeten worden geraadpleegd? Vaak doen zich als het project eenmaal loopt voortdurend nieuwe inzichten voor. Bijvoorbeeld over het ontbreken van benodigde informatie in bronsystemen. En anders doet de opdrachtgever wel inspiratie op voor nieuwe wensen en eisen uit feedback over opgeleverde rapportages en analyses. Business intelligence-projecten kenmerken zich vaak door onvolledige requirements en doorlopend voortschrijdend inzicht.
Op het gebied van aanpakken voor systeemontwikkeling hebben zich de laatste jaren enorme veranderingen voorgedaan. Steeds meer organisaties en projecten stappen over op een nieuwe generatie aanpakken, die voortschrijdend inzicht niet langer schuwen maar omarmen. Ook kenmerkt deze nieuwe generatie aanpakken zich door multidisciplinaire samenwerking en het frequent in korte iteraties opleveren van software. In één woord: agile. De vraag is nu of en zo ja hoe deze aanpakken een positieve bijdrage kunnen leveren aan het uitvoeren van business intelligence-projecten.
Kenmerken
Wat kenmerkt business intelligence-projecten? De doelstellingen van business intelligenceprojecten zijn altijd direct businessgerelateerd. Denk bijvoorbeeld aan het minimaliseren van verzekeringsfraude of het behouden van klanten. Tijdens een project worden analyses en rapportages gedefinieerd die ondersteunen bij het beheersen en optimaliseren van de bedrijfsprocessen van de opdrachtgever. Deze rapportages en analyses worden – meestal dagelijks – gevoed uit een datawarehouse. Kenmerkend voor dit type projecten is dat vaak lastig is vast te stellen welke concrete bijdrage deze analyses en rapportages leveren. Neem voorbeeld de eerder genoemde overheidsinstantie, waar niet op voorhand was uit te drukken hoeveel geld deze kon besparen bij het vinden van de optimale verhouding tussen het aantal onderzoeken
en het aantal gevonden fraudeurs. Pas na afloop van het project bleek dat de resultaten nog beter waren dan van tevoren was ingeschat. Hoewel vroegtijdig in projecten is vast te stellen welke analyses en rapportages benodigd zijn, is de exacte invulling hiervan nauwelijks concreet te formuleren. Wat wil de opdrachtgever echt zien in zijn rapporten? Neem als voorbeeld een rapportage over de verhouding tussen inkomende en uitgaande berichten bij een telecomoperator. Pas toen de opdrachtgever het rapport onder ogen kreeg, bleken er diverse soorten inkomende berichten te zijn, die ook weer gekoppeld zijn aan diverse soorten uitgaande berichten. Een typisch voorbeeld van voortschrijdend inzicht. Een ander interessant fenomeen is het extractie-, transformatie- en laadproces (ETL). Hierbij worden in een aantal stappen de gegevens uit bronsystemen verzameld, geïntegreerd en geaggregeerd tot een formaat dat voor de rapportages en analyses benodigd is. In de meeste business intelligence-projecten beslaat dit type werk circa tachtig procent van de ontwikkeltijd
(figuur 1) .
Figuur 1. Kenmerken van business intelligence-projecten

Toch blijft dit werk meestal helaas onzichtbaar voor de opdrachtgever. Deze concentreert zich – terecht – vooral op de op te leveren rapportages en analyses. Maar doordat de bulk van het werk in een business intelligence-project op ETL is gericht, worden meestal ook de fasen van een dergelijk project rond ETL ingericht. Dat wil zeggen dat eerst alle extracties worden ontwikkeld, aansluitend de transformaties, om vervolgens alle gegevens te laden. Pas nadat dit is gelukt worden de rapportages en analyses gedefinieerd, zoals weergegeven in figuur 2 .
Figuur 2. Meestal worden ook de fasen van een business intelligence-project rond ETL ingericht

Het gevolg hiervan is dat pas in deze laatste fase van het project iets wordt opgeleverd waarmee de opdrachtgever aan de slag kan. Dit heeft een belangrijk nadeel. Voor de opdrachtgever blijft het project lang ‘onder water’. Pas nadat veel tijd en geld is geïnvesteerd, kan de opdrachtgever feedback geven op de geproduceerde rapportages en analyses. Bovendien is de ETL dan al min of meer volledig opgeleverd. Aanpassingen aan rapportages en analyses zijn nu lastig te realiseren. Ook is het niet uitgesloten dat als gevolg van deze feedback sommige stappen uit de ETL overbodig blijken. In dit geval is er zelfs werk voor niets uitgevoerd. Ten slotte komt het voor dat voor de gewenste rapportages en analyses gegevens nodig zijn die niet direct uit de bronsystemen zijn af te leiden. Aanvullende gegevens worden dan vaak handmatig toegevoegd tijdens de ETL. Vaak worden hiervoor gaandeweg het project kleine administratieve applicaties ontwikkeld. Nog los van het feit dat deze applicaties door de verkeerde ontwikkelaars worden ontwikkeld – business intelligence-ontwikkelaars in plaats van softwareontwikkelaars – worden deze hiaten meestal pas laat in het business intelligence-project ontdekt. Met alle gevolgen van dien. Zo uitgevoerd zijn veel business intelligence-projecten duurder dan strikt noodzakelijk.
Agile
Wat kenmerkt agile? In softwareontwikkeling is afgelopen jaren een nieuwe generatie aan aanpakken ontstaan, die de best practices van eerdere generaties koppelen aan een sterk iteratief en coöperatief karakter. Deze aanpakken, zoals DSDM, extreme programming (XP), scrum en smart worden gekenmerkt door:
• Korte iteraties. Een project wordt uitgevoerd in korte iteraties, variërend van twee weken tot een maand. Tijdens elke iteratie wordt een klein deel van de software geanalyseerd, ontworpen, gebouwd, getest en zelfs opgeleverd aan de opdrachtgever. Pas bij de start van een iteratie wordt vastgesteld welke functionaliteit tijdens de komende iteratie wordt gerealiseerd. Projecten verkorten zo de feedbacklus met hun opdrachtgever. Dit verbetert de kwaliteit van de ontwikkelde software in hoog tempo. Dit in tegenstelling tot traditionele projecten, waar de software in een ‘big bang’ wordt opgeleverd aan het eind van het project.
• Compacte eenheid van werk. Om dit te kunnen bereiken hanteren projecten een eenduidige en kleine eenheid van werk. Er worden altijd meerdere workitems opgeleverd per iteratie. Individuele workitems leveren direct waarde op voor de opdrachtgever.
• Snel en frequent opleveren van software. Al tijdens de eerste iteraties worden workitems opgeleverd aan de opdrachtgever, al dan niet direct in productie. Zo komen mogelijke problemen, bijvoorbeeld rond architectuur of infrastructuur, al snel in het project boven water.
• Incorporeren voortschrijdend inzicht. Anders dan in traditionele projecten, waar voortschrijdend inzicht zoveel mogelijk wordt uitgebannen, is het in agile projecten mogelijk en zelfs gebruikelijk nieuwe en wijzigende requirements direct mee te nemen. Dit kan doordat steeds bij de start van een nieuwe iteratie wordt vastgesteld welke workitems worden gerealiseerd. Nieuwe workitems kunnen nu al worden meegenomen, ten faveure van al eerder benoemde workitems.
• Nauwe samenwerking klant en opdrachtnemer. Het snel en frequent opleveren van software in korte iteraties vraagt een intensieve samenwerking tussen opdrachtgever en opdrachtnemer. Er vindt bij voorkeur op dagelijkse basis overleg plaats, bijvoorbeeld om de nieuw te realiseren workitems te analyseren.
• Geïntegreerde testen. Omdat software frequent en al vroegtijdig wordt opgeleverd in projecten, is het testen van de workitems van cruciaal belang vanaf dag één van een project.
Scrum
Van alle agile aanpakken is scrum verreweg de populairste. Niet zelden wordt scrum met agile vereenzelvigd. De helderheid van de aanpak maakt scrum een goed uitgangspunt voor projecten. Een scrum-project begint zodra de lijst met workitems is vastgesteld. Dit heet de ‘product backlog’. Meestal omvat deze een verzameling ‘user stories’. De backlog wordt vastgesteld door de vertegenwoordiger van de opdrachtgever, de ‘product owner’.
Iteraties, hier ‘sprints’ genoemd, duren in de regel twee tot vier weken. Bij de start van een sprint stelt de product owner samen met het team tijdens de sprint planningmeeting de te realiseren user stories vast. Het team verdeelt deze in taken en schat de hoeveelheid werk in uren in. Op basis hiervan en op basis van de snelheid in vorige sprints en de samenstelling van het team in de komende iteratie wordt bepaald hoeveel stories er in de sprint passen. Deze stories worden op de ‘sprint backlog’ geplaatst. Aan het einde van een sprint vindt de ‘sprint review meeting’ plaats, waarin de gerealiseerde workitems worden geëvalueerd. Aansluitend vindt de ‘retrospective’ plaats, waarin het team de werkwijze evalueert en verbetert (figuur 3) .
Figuur 3. De scrum-aanpak

Scrum kent slechts een beperkt aantal rollen. Het werk wordt gedaan door het team, dat in de regel vijf tot negen personen telt en waarvan de individuele rollen niet zijn beschreven. De product owner vertegenwoordigt in het project de klant. Een ‘scrum master’ coacht de product owner en het team. De voortgang in het project wordt bewaakt op een eenvoudig dashboard. De eenvoud en populariteit van scrum maken deze aanpak tot een goed raamwerk voor startende projecten. De toegepaste terminologie uit de aanpak werkt aanstekelijk. Scrum is eenvoudig toe te passen en kan gemakkelijk waar nodig worden uitgebreid met technieken uit andere agile aanpakken.
Smart
In onze ervaring kan scrum voor business intelligence-projecten goed worden gestructureerd met elementen uit andere agile aanpakken, in dit geval smart. Deze van origine Nederlandse agile aanpak kent meerdere typen iteraties. Bij de start van een project wordt de backlog gevuld met workitems die voorwaardelijk zijn om software te realiseren. Denk aan het vaststellen van stakeholders en doelstellingen, het modelleren van bedrijfsprocessen, rapportages en analyses in ‘smart use cases’, het maken van een schatting op basis van deze smart use cases, het opstellen van een baseline architectuur, het inrichten van de ontwikkelomgeving en het maken van een projectplan. Deze workitems worden gerealiseerd tijdens de voorbereidende iteraties ‘propose’ en ‘scope’. De iteratie propose mondt uit in een eerste projectvoorstel. Scope eindigt met het opleveren van het projectplan (figuur 4) .
Figuur 4. De smart-aanpak kent meerdere typen iteraties
 
Na deze inleidende iteraties wordt de backlog gevuld met de gemodelleerde smart use cases, die de standaard eenheid van werk zijn in smart. De smart use cases worden gerealiseerd tijdens een of meerdere releases. Een release bestaat uit een reeks van ‘realize’-iteraties, gevolgd door een ‘finalize’-iteratie. Tijdens realize-iteraties worden de smart use cases gerealiseerd, getest en geaccepteerd. Iedere release wordt afgesloten door een finalize-iteratie, waarin de nadruk nog sterker ligt op testen en op het stabiliseren van de code.
Elke iteratie heeft in smart dezelfde opbouw. De iteratie start met een kick-off ‘plan’ en eindigt met de retrospective ‘evaluate’. Daartussen worden de workitems gerealiseerd tijdens ‘build’ (figuur 5) .
Figuur 5. In smart heeft elke iteratie dezelfde opbouw

In smart telt het team meerdere rollen. De belangrijkste zijn projectsponsor, gebruiker, domeinexpert, ontwikkelaar, tester en coach. Smart doet het goed in langlopende, vaak wat complexere projecten zoals business intelligence-projecten, waarin het structureren van rapportages en analyses in smart use cases beter past dan eerdergenoemde user stories. Smart use cases zijn direct gerelateerd aan de bedrijfsprocessen van de opdrachtgever. Bovendien worden ze gemodelleerd en geschat op basis van een reeks standaardtypen, zogenoemde stereotypes. Er zijn al stereotypes beschreven voor bijvoorbeeld stappen in ETL, rapportages en analyses.
Snel en frequent opleveren
Het snel en frequent opleveren van voor de opdrachtgever relevante software is een aspect van agile dat in business intelligence bijzonder goed van pas komt. In plaats van de verticale fasering van traditionelere business intelligence-projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal te realiseren. Niet langer worden eerst alle extracties en aansluitend de transformaties en het laden van de gegevens opgeleverd om pas daarna de rapportages en analyses te ontwikkelen. Liever ontwikkelen we per rapport of analyse. Hierbij kiest de opdrachtgever steeds welke rapporten of analyses de hoogste prioriteit hebben, en werkt het team uitsluitend aan de minimale set aan smart use cases die nodig zijn om deze te realiseren. Deze representeren de benodigde extracties en transformaties en natuurlijk het rapport zelf. Deze kanteling van werkzaamheden maakt directe feedback van de opdrachtgever mogelijk. Een belangrijk bijkomend voordeel is dat de rapporten en analyses direct kunnen worden aangewend om de bedrijfsprocessen van de opdrachtgever te verbeteren. Soms al enkele weken na de start van het business intelligence-project. Zo toont het project al op heel korte termijn ‘benefits’. Op deze manier wordt voortschrijdend inzicht nu eens niet uitgebannen, zoals in traditionele projecten, maar worden nieuwe inzichten direct meegenomen. Hoewel in principe tijdens een lopende iteratie de scope niet wijzigt, kunnen nieuwe requirements al tijdens een eerstvolgende iteratie op de rol worden gezet. Zodra de opdrachtgever de eerste versie van een rapportage of analyse onder ogen krijgt, formuleert hij direct zijn feedback, die dan vrijwel direct wordt geïmplementeerd – denk bijvoorbeeld aan het realiseren van ‘data entry’ voor ontbrekende gegevens.
Compacte eenheid van werk
Kort gezegd is een business intelligence-project uit te drukken in drie typen ontwikkelwerk: datamodellering en ETL, het definiëren van analyses en rapporten en het ontwikkelen van aanvullende data entry applicaties. In smart is de smart use case de leidende eenheid van werk, zowel voor het modelleren van bedrijfsprocessen en requirements als voor het schatten, realiseren en testen van voor de gebruiker relevante functionaliteit. Voor het modelleren van smart use cases beschikken we over richtlijnen die ertoe bijdragen dat smart use cases een lage granulariteit kennen en al tijdens propose en scope zijn te modelleren. Er is bovendien een groot aantal stereotypes beschreven die het modelleren, schatten en realiseren standaardiseren en vergemakkelijken. Voorbeelden hiervan zijn ‘manage’ voor data entry, ‘search’ voor het zoeken naar record, en ‘file import’.
Hoewel afkomstig uit reguliere softwaredevelopment, blijken smart use cases ook prima te gebruiken voor agile business intelligence-projecten. Wat betreft het definiëren van rapportages en het ontwikkelen van aanvullende data entry ligt dit voor de hand, omdat dergelijk werk niet wezenlijk verschilt van reguliere softwaredevelopment. Maar ook voor het vaststellen van analyses en zelfs voor het uitvoeren van ETL zijn use cases stereotypes vastgesteld, zoals ‘collect’, ‘integrate’ en ‘aggregate’.
Smart use cases worden al vroeg in een agile business intelligence-project gemodelleerd, tijdens propose en scope. Daarbij worden de smart use cases slechts geïdentificeerd en geschat. Details worden pas uitgewerkt tijdens latere iteraties. Aansluitend worden realize- en finalize-iteraties ingepland. Tijdens deze iteraties ligt de nadruk op het realiseren van individuele rapportages, op basis van de hiertoe benodigde smart use cases voor ETL, eventuele data entry en de definitie van het rapport (figuur 6) .
Figuur 6. Iteratieve business intelligence-projecten

De benodigde smart use cases worden zo snel mogelijk gerealiseerd en met de opdrachtgever afgestemd. Bijkomend voordeel is dat de onderliggende dataflows, die nu zijn uitgedrukt in smart use cases, goed individueel te testen zijn, en door het modelleren van de use cases is zelfs het hergebruik van dataflows snel te identificeren. In business intelligence-projecten is het snel en frequent opleveren van nieuwe rapportages en analyses van groot belang voor de opdrachtgever. Elke nieuwe rapportage kan tenslotte direct worden benut in de praktijk en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben business intelligence-projecten veel baat bij het voortschrijdend inzicht dat ontstaat dankzij de korte iteraties in agile projecten. Beter dan dit uit te bannen, zoals traditioneel wordt getracht, is het om effectief gebruik te maken van deze inzichten en feedback.
Dashboards en ‘burndown charts’
Om agile projecten te beheersen en de voortgang
 
 
te bewaken wordt in de regel gebruikt gemaakt van een tweetal pragmatische gereedschappen; een agile dashboard of taskboard en een ‘burndown chart’. Alle te realiseren workitems doorlopen een levenscyclus die de stappen uit het realiseren ervan beschrijft, doorgaans in enkele dagen tijd. Voor smart use cases telt deze levenscyclus stappen als ‘new’, ‘in iteration’, ‘working’, ‘testing’, ‘rework’ en ‘accepted’. Doorgaans breiden projecten deze cyclus uit naar gelang de projectspecifieke werkwijze dit verlangt. De stappen in de levenscyclus van workitems of smart use cases vormen de kolommen op het dashboard of taskboard van een agile project (figuur 7) . De meeste agile projecten gebruiken voor dergelijke dashboards post-its aan de muur, of een online gereedschap. In één oogopslag is zo, ook voor de opdrachtgever, te zien wat de voortgang van de smart use cases is.
Figuur 7. Dashboard of taskboard van een agile project

Omdat de omvang van smart use cases worden geschat in punten, is bij elke statuswijziging snel na te gaan hoeveel werk nog nodig is om de onder handen zijnde rapportages en smart use cases te voltooien. Zodra een smart use cases is geaccepteerd, krijgt het team de bijbehorende punten. In agile business intelligence-projecten is het daarbij belangrijk dat de opdrachtgever ook de ‘back end’ smart use cases accepteert die stappen uit de ETL of data entry representeren. Dit kan bijvoorbeeld gebeuren door met de opdrachtgever de resultaten van dergelijke use cases in de reporting tool te demonstreren.
Een burndown chart toont een dagelijkse momentopname van deze punten, uitgezet in de tijd. Met een eenvoudige extrapolatie is nu de verwachte einddatum van het project te calculeren (figuur 8) .
Figuur 8. Met een burndown chart is de verwachte einddatum van een project te calculeren

In agile business intelligence-projecten is het overigens niet alleen zeer zinvol een burndown chart te gebruiken voor het gehele project, maar ook om per te realiseren rapport en analyses deze voortgang te projecteren. Juist omdat de rapportages individueel worden opgeleverd, leveren deze laatstgenoemde burndown charts de opdrachtgever directe informatie over wanneer het nieuwe rapport is in te zetten in het besturen van zijn bedrijfsprocessen.
Snel resultaat
Agile aanpakken zoals scrum en smart spelen bijzonder goed in op de snel wijzigende en uitbreidende wensen en eisen van opdrachtgevers aan business intelligence-projecten. Daarbij wordt in korte iteraties aan het ‘goed genoeg’ opleveren van individuele rapporten en analyses gewerkt. Zo heeft de opdrachtgever al veel eerder profijt van zijn business intelligence-project en kan voortschrijdend inzicht sneller en goedkoper leiden tot een optimaal eindresultaat. Het toepassen van smart use cases biedt business intelligence-projecten daarnaast een gestructureerde maar vooral pragmatische manier om met eenzelfde eenheid van schatten, realiseren en testen te opereren, die bovendien direct te relateren is aan de bedrijfsprocessen van de opdrachtgever. De pragmatische gereedschappen die in agile projecten worden gebruikt om de voortgang te meten, zoals agile dashboards en burndown charts per rapport, bieden bovendien direct inzicht in de realisatie van de rapportages en analyses. Agile business intelligence biedt daardoor snel resultaat met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen, toch?
 
Sander Hoogendoorn is principal technology officer en agile thoughtleader bij Capgemini en auteur van de boeken Dit is agile en Pragmatisch modelleren met UML (smart use cases) . E-mail: aahoogendoorn@gmail.com
 
Sandra Wennemers is principal consultant en datawarehousearchitect bij Capgemini. E-mail: sandra.wennemers@capgemini.com Zie ook www.smartusecase.com en www.ditisagile.nl.
 

Tag

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