Category Archives: iteration

Agile business intelligence

Posted on by
1

Het besparen van kosten is een veelgenoemde aanleiding voor Business Intelligence (BI) 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 echter direct geld op. En dus ging zoekt de instantie naar de optimale verhouding tussen het aantallen onderzoeken en het aantal opgespoorde fraudes. Kortgezegd wilde men met zo min mogelijk onderzoeken zoveel mogelijk fraudeurs vinden.

Deze doelstelling is archetypisch voor BI-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 op? Welke bronsystemen moeten worden geraadpleegd? Vaak wanneer het project eenmaal loopt, doen zich doorlopend 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. BI-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 juist 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 hoe deze aanpakken ook een positieve bijdrage kunnen leveren aan het uitvoeren van BI-projecten.

Wat kenmerkt BI-projecten?

De doelstellingen van BI-projecten zijn altijd direct business gerelateerd. 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 uiteindelijk leveren. Neem voorbeeld de eerdergenoemde overheidsinstantie, waar niet op voorhand was uit te drukken hoeveel geld men kon besparen bij het vinden van de optimale verhouding tussen het aantal onderzoeken en het aantal gevonden fraudeurs. Uiteindelijk bleek in dit voorbeeld pas na afloop van het project dat de resultaten nog beter waren dan van te voren was geschat.

Hoewel vroegtijdig in projecten nog is vast te stellen welke analyses en rapportages benodigd zijn, is de exacte invulling hiervan nauwelijks concreet te formuleren. Wat wil de opdrachtgever nu echt zien in zijn rapporten? Neem als voorbeeld een rapportage over de verhouding tussen inkomende en uitgaande berichten bij een telecom-operator. 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 interessant fenomeen is ook 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 BI-projecten beslaat dit type werk circa tachtig procent van de ontwikkeltijd.

clip_image002

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 BI-project op ETL is gefocust, 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 onderstaande afbeelding.

clip_image004

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 mind 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 – BI-ontwikkelaars in plaats van softwareontwikkelaars – worden deze hiaten meestal pas laat in het BI-project ontdekt. Met alle gevolgen van dien. Zo uitgevoerd zijn veel BI-projecten duurder dan strikt noodzakelijk.

Wat kenmerkt agile?

In software development 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 kenmerken zich in:

  • Korte iteraties. Project worden uitgevoerd in korte iteraties, variërend van twee weken tot een maand. Tijdens ieder van deze iteraties 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 feedback lus 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 opleveren voor de opdrachtgever.
  • Snel en frequent opleveren van software. Tijdens agile projecten wordt ook al tijdens de eerste iteraties workitems opgeleverd aan de opdrachtgever, al dan niet direct in productie. Dit zorgt ervoor dat mogelijke problemen, bijvoorbeeld rond architectuur of infrastructuur, al snel in het project boven water komen.
  • 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 over 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 nieuwe 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 in 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.

clip_image006

Iteraties, hier sprints genoemd, duren in de regel twee tot vier weken. Bij de start van een sprint wordt tijdens de sprint planning meeting door de product owner samen met het team de te realiseren user stories vastgesteld. Het team verdeelt deze in taken en schat de hoeveelheid werk hieraan 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 work items worden geëvalueerd. Aansluitend vindt de retrospective plaats, waarin het team de werkwijze evalueert en verbetert.

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 de aanpak 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 BI-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 work items 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 base line 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.

clip_image008

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 Realise 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.

Iedere iteratie heeft in Smart dezelfde opbouw. De iteratie start met een kick-off Plan en eindigt met de retrospective Evaluate. Daartussen worden de work items gerealiseerd tijdens Build.

clip_image010

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 BI-projecten, waarin het meer 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 aan standaardtypen, zogenaamde 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 BI bijzonder goed van pas komt. In plaats van de verticale fasering van traditionelere BI-projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal in te steken. 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 voor 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. 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 BI-project. Zo toont het project al op heel korte termijn benefits.

Zo wordt voortschrijdend inzicht nu eens niet uitgebannen, zoals traditionele, 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 daarbij bijvoorbeeld aan het realiseren van data entry voor ontbrekende gegevens.

Compacte eenheid van werk

Kort gezegd is een BI-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, en 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 of file import.

Hoewel afkomstig uit reguliere software development, blijken smart use cases ook prima aan te wenden voor agile BI-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 software development. 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 BI-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 focus 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.

clip_image012

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 zelfs is door het modelleren van de use cases hergebruik van dataflows snel geïdentificeerd.

In BI-projecten is het snel en frequent opleveren van nieuwe rapportages en analyses van groot belang voor de opdrachtgever. Immers, ieder nieuwe rapportage kan direct worden benut in de praktijk en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben BI-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 juist effectief gebruik te maken van deze inzichten en feedback.

Dashboards en burn-down-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 burn-down-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.

clip_image014

De meeste agile projecten gebruiken voor dergelijke dashboards post-its aan de muur, of een online gereedschap. In een oogopslag is zo, ook voor de opdrachtgever, te zien wat de voortgang van de smart use cases is.

Omdat de omvang van smart use cases worden geschat in punten, is bij ieder 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 BI-projecten is het daarbij belangrijk dat ook de “back end” smart use cases die stappen uit de ETL of data entry representeren door de opdrachtgever worden geaccepteerd. Dit kan bijvoorbeeld gebeuren met de opdrachtgever de resultaten van dergelijke use cases in de reporting tool te demonstreren.

Een burn-down-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.

clip_image016

In agile BI-projecten is het overigens niet alleen zeer zinvol een burn-down-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 burn-down-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 BI-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 BI-project, en kan voortschrijdend inzicht sneller en goedkoper leiden tot een optimaal eindresultaat. Het toepassen van smart use cases biedt BI-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 burn-down-charts per rapport, bieden bovendien direct inzicht in de realisatie van de rapportages en analyses. Agile BI biedt daardoor snel resultaat met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen toch?

Dit artikel verschijnt in het themanummer Agile Datawarehousing van maandblad Informatie

Sander Hoogendoorn
Principal Technology Officer en Agile Thoughtleader Capgemini, auteur van de boeken Dit Is Agile (agile, Scrum, Smart) en Pragmatisch Modelleren met UML (smart use cases).

Sandra Wennemers
Principal Consultant en Data Warehouse Architect Capgemini

Zie ook www.smartusecase.com en www.ditisagile.nl

Death by Dogma versus Agile Assembly

Posted on by
4

On November 3, 2011 I presented the keynote of the Agile Open Holland Conference in Dieren. During this challenging talk I discussed the current state of affairs in agile organizations and projects and the effects of the recent strong rise in popularity of agile approaches. Let’s put it mildly: there’s a lot of work to be done.

Death by dogma

Almost all organizations, large and small, are turning towards agile to escape failing traditional software development projects. Due to this strong increase in popularity of agile approaches and techniques, many newcomers will enter the field of agile coaching. Of course without the very necessary real-life experience but proudly waving their Certified Professional Scrum Master Sensei Trainer Certificate proving they at least had two days of training.


Going through the hardship of two whole intense days of training becoming a Certified Agile Jedi Knight is worthwhile!

In my opinion, as a result many organizations and projects in the next couple of years will be coached why well-willing consultants who have barely made it through boot camp, and in the famous Shu-Ha-Ri learning model haven’t yet made it beyond copying their teacher. This will lead to very dogmatic applications of the more popular agile approaches, mostly Scrum, especially when the so-called leaders in the field themselves turn to dogma. This dogmatic thinking will block the use of more mature techniques and technology in agile projects, even when these would really improve projects, or would prevent agile projects from failing. “No, you can not do modeling in Scrum” and “Burn-down charts are mandatory” are two such simple real-life example statements that I’ve witnessed some certified agile Jedi Knight make. Due to this lack of experience and the growing dogmatism in the agile beliefs, more and more agile projects will fail. Death by dogma.

During my keynote I discussed many examples of dogmatic Scrum implementations and the drawbacks from being dogmagile, building the story up from my previous posts Scrumdamentalists and Crusaders and Flower-Power Agile Fluffiness.

But maybe even more important during the keynote I also show that there is no such thing as one-size-fits-all agile. Different organizations and different projects require different agile approaches. Sometimes lightweight agile, for instance implemented using Scrum, user stories, simple planning, simple estimation, and one co-located team using post-its on a wall is just fine. But in many projects the way of working used should rather be built up from slightly more enterprise ready approaches, for example using Smart, smart use cases, standardized estimation, multiple distributed teams and on-line dashboards.

What is agile anyway?

Implementing agile in your projects starts with establishing what it means to be in an agile project. As I demonstrate in the keynote, I consider short iterations, collaborative teams, a small unit of work, continuous planning, delivering early and often, and simplifying communication to be crucial to considering a project working in an agile way.

From there you can pick and choose from a wide variety of approaches, techniques and technology. Most of them stemming from the agile era, but some of them can also be related to older (or more mature) era’s. Concluding you might say that to be successful in implementing agile in your organization, you will need to assemble your agile approach from everything that will help you implement these six agile bare necessities. Anyway, enjoy!

Death by Dogma versus Agile Assembly

Een introductie in agile business intelligence [in Dutch]

Posted on by
2

Om kosten te besparen, een veelgenoemde aanleiding voor Business Intelligence (BI) projecten, wilde een bekende overheidsinstantie weten hoe effectief de bestrijding van uitkeringsfraude was. Hierbij speelde een interessant fenomeen. Het onderzoeken van mogelijke fraude kost de instantie geld, maar het vinden van fraudeurs levert daarentegen direct geld op. En dus ging men op zoek naar de optimale verhouding tussen het aantallen onderzoeken en het aantal opgespoorde fraudes. Kortgezegd wilde men met zo min mogelijk onderzoeken zoveel mogelijk frauders vinden.

[Dit artikel is gepubliceerd in Database Magazine]

De hiergenoemde doelstelling is archetyisch voor BI-projecten. Hoewel dergelijke doelstellingen vaak nog redelijk zijn te definieren, is de realisatie hiervan vaak schimmig. Welke rapportages moeten worden ontwikkeld en wat staat daar op? Welke bronsystemen moeten hiervoor worden geraardpleegd? En wanneer het project eenmaal loopt, doen zich doorlopend nieuwe inzichten voor. Bijvoorbeeld over het ontbreken van benodigde informatie in bronsystemen. En anders doet de opdrachtgever wel inspiratie voor nieuwe wensen en eisen op uit feedback over opgeleverde rapportages en analyses. BI-projecten kenmerken zich derhalve door onvolledige requirements en doorlopend voortschrijdend inzicht.

Op het gebied van systeemontwikkelmethodieken hebben zich de laatste jaren enorme veranderingen voorgedaan. Meer en meer organisaties en projecten stappen over een nieuwe generatie methodieken, die voortschrijdend inzicht niet langer schuwen, maar juist omarmen en zich kenmerken door cooperatieve samenwerking en het frequent, in korte iteraties opleveren van software. Deze methodieken worden wel de ook de agile methodieken genoemd. De vraag is hoe deze methodieken, afkomstig uit reguliere softwaredevelopment, ook een positieve bijdrage kunnen leveren aan het uitvoeren van BI-projecten.

Wat kenmerkt een BI-project?

De doelstellingen van BI-projecten zijn altijd direct business gerelateerd, zoals 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 het ontwikkelen datawarehouse. Kenmerkend voor dit type projecten is dat lastig is vast te stellen welke concrete bijdrage deze analyses en rapportages uiteindelijk leveren. Neem voorbeeld de eerdergenoemde overheidsinstantie, waar niet op voorhand was uit te drukken hoeveel geld men kon besparen bij het vinden van de optimale verhouding tussen het aantal onderzoeken en het aantal gevonden fraudeurs. Uiteindelij k bleek na afloop van het project dat de resultaten nog beter waren dan van te voren was geschat.

Alhoewel vroegtijdig in projecten nog is vast te stellen welke analyses en rapportages benodigd zijn, is de exacte invulling hiervan nauwelijks te formuleren. Wat wil de opdrachtgever nu echt zien in zijn rapporten? Neem als voorbeeld een rapportage over de verhouding tussen inkomende en uitgaande berichten bij een telecom operator. 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 interessant fenomeen is ook 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 analyse benodigd is. In de meeste BI-projecten beslaat dit type werk zo’n 80% van de ontwikkeltijd.

 

clip_image002

 

Toch blijft dit werk meestal onzichtbaar voor de opdrachtgever. Deze concentreert zich – terecht – vooral op de op te leveren rapportages en analyses. Maar doordat de bluk van het werk in een BI-project op ETL is gefocust, worden meestal ook de fasen van zo’n 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 onderstaand afbeelding.

 

clip_image004

 

Met als gevolg dat pas in deze laatste fase van het project iets wordt opgeleverd waarmee de opdrachtgever aan de slag kan. Dit heeft een belangrijk nadeel. Pas in een laat stadium geeft de klant feedback. Mogelijke aanpassingen aan rapportages en analyses als gevolg hiervan zijn nu lastig te realiseren omdat alle ETL al is opgeleverd. Bovendien is het niet uitgesloten dat als gevolg van deze feedback sommige stappen uit de ETL overbodig blijken. In dit laatste geval is er zelfs werk voor niet uitgevoerd. Dan wordt het BI-project een dure onderneming.

Tenslotte kan het nog voorkomen 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 applicatietjes door de verkeerde ontwikkelaars worden ontwikkeld – business intelligence specialisten en geen reguliere ontwikkelaars – worden deze hiaten in gegevens meestal pas lopenede het project ontdekt. Met alle gevolgen vandien.

Wat kenmerkt agile software development?

In de reguliere software development is afgelopen jaren een hele nieuwe generatie aan methodieken ontstaan, die de best practices van vorige generaties koppelen aan een sterk iteratieve en cooperatief karakter. Deze methodieken, zoals DSDM, extreme programming, Scrum, Smart en feature driven development (FDD) kenmerken zich alle als volgt:

  • Korte iteraties. Werkende software wordt opgeleverd in korte iteraties, variërend van twee weken tot een maand. Tijdens ieder van deze iteraties wordt een klein deel van de software geanalyserd, ontworpen, gebouwd, getest en vaak zelds opgeleverd. Pas bij de start van een iteratie wordt vastgesteld welke functionaliteit tijdens de komende iteratie wordt ontwikkeld. Hiermee verkorten projecten de feedbacklus met de opdrachtegever rigoreus. Zo verbetert de kwaliteit van de ontwikkelde software in hoog tempo. Dit in tegenstelling tot traditionele projecten, waarin de software vaak in een big bang wordt opgeleverd aan het eind van het project.
  • Compacte eenheid van werk. Bovenstaande kan alleen worden bereikt als er een eenduidige en kleine eenheid van werk wordt gehanteerd in projecten. Hierbij geldt dat individuele work items directe waarde vertegenwoordigen voor de opdrachtgever en bovendien zo klein zijn dat er meerdere zijn te realiseren tijdens een individuele iteratie.
  • Snel en frequent opleveren van software. Tijdens agile projecten wordt al tijdens de eerste iteraties software opgeleverd aan de opdrachtgever, al dan niet direct in productie. Dit zorgt ervoor dat problemen, bijvoorbeeld rond de architectuur, al vrij snel na de start van het project boven water komen.
  • 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 requirements nog tijdens het lopende project mee te nemen. Hiertoe wordt pas bij de start van een iteratie vastgesteld welke work items tijdens deze iteratie worden opgepakt. Nieuw work items kunnen hierbij worden meegenomen, ten faveure over al eerder benoemde werk items.
  • Nauwe samenwerking klant en opdrachtnemer. Het snel en frequent opleveren van software in korte iteraties vraagt een intensieve samenwerking tussen klant en opdrachtnemer, waarbij bij voorkeur op dagelijkse basis overleg plaatsvindt, bijvoorbeeld om de nieuwe gerealiseerde work items te bekijken.
  • Geïntegreerd testen. Omdat software frequent en al vroegtijdig wordt opgeleverd in projecten, is het testen van de software van cruciaal belang vanaf dag één in een project.

Smart

Een bekende agile methodiek is Smart, die veel is toegepast in reguliere systeemontwikkelprojecten. Deze methodiek is ooit ontwikkeld als implementatie van DSDM, maar is inmiddels uitgegroeid tot een kernachtige agile methodiek, waarin best practices zijn ondergebracht uit bijvoorbeeld Rational Unified Process, Scrum en extreme programming. Naast typische agile karakteristieken die hierboven zijn beschreven kent Smart een aantal additionele technieken, voortgekomen vanuit de praktijk. Deze technieken geven projecten een eenduidige eenheid van werk, maar helpen ook om de voortgang te bewaken:

  • Smart use cases. De eenheid van schatten, plannen, requirementsanalyse, ontwerp en ontwikkeling is een gestandaardiseerde vorm van use cases, die wel smart use cases worden genoemd. Smart use cases worden gebruikt om de functionele requirements van een project uit te drukken. Interessant aan deze smart use cases is dat ze gelijkmatig van grootte en complexiteit zijn, waardoor ze gemakkelijk zijn in te schatten, en zo klein zijn dat er diverse binnen het tijdbestek van een enkele iteratie worden gerealiseerd.
  • Smart estimation. Aanvullend hierop is een schattingstechniek die de totale complexiteit en omvang van een project uitgedrukt in smart use case punten. De smart use cases worden hiertoe uitgedrukt op een eenvoudige schaal, die van 1 tot 5 gaat, maar voor uitzonderingssituaties 8 en 10 heeft gereserveerd. Er zijn voor diverse typen projecten standaardtypen use cases geïdentificeerd, die al zijn uitgezet op deze schaal. Dit geldt voor het ontwikkelen van bedrijfsapplicaties, service-oriëntatie, content management en reporting, bijvoorbeeld met behulp van Sharepoint. Inmiddels zijn er ook standaardtypen voor ETL opgesteld.
  • Monitoring. De voortgang in Smart-projecten wordt voortdurend gemonitord via een tweetal pragmatisch gereedschappen. Zo wordt een agile dashboard gebruikt waarin de status van de smart use cases uit het project is uitgedrukt. Bovendien hanteren projecten een burn down chart, waarin steeds de verwachte einddatum is te extrapoleren.

Fasen van Smart

Smart kent een beperkt aantal eenvoudige fasen, zoals is weergegeven in onderstaande afbeelding. Een project is verdeeld over twee voorbereidende fasen genaamd Propose en Scope, een kortcyclische hoofdfase Realize, een afrondende fase Finalize en eventueel een fase voor het beheren van de applicatie die Manage wordt genoemd. Deze latste fase start zodra het project de software heeft opgeleverd.

clip_image006

 

In iets meer detail:

  • Propose. Tijdens deze fase wordt de scope, de omvang en de complexiteit van het project vastgesteld, uitgedrukt in smart use cases. Propose mondt uit in een projectvoorstel en een eerste schatting.
  • Scope. Tijdens Scope wordt het projectvoorstel verder uitgewerkt, waarbij onder meer herbruikbare componenten en niet-functionele requirements op het menu staan. Deze fase leidt tot het plan van aanpak voor de uitvoering van de rest van het project.
  • Realize. De fase Realize is gericht op het interactief realiseren van de software. Deze fase is opgedeeld in korte iteraties, liefst van twee weken. Tijdens iedere van deze iteraties worden een aantal smart use cases gerealiseerd. Welke use cases dit zijn, wordt vastgesteld bij de start van een iteratie (in de deelfase Plan). Daarna worden ze gerealiseerd tijdens een dagelijkse sub-iteratie in Realize. De iteratie wordt uiteindelijk afgerond en geëvalueerd (in deelfase Evaluate).
  • Finalize. Tijdens de iteraties van de fase Finalize wordt de software afgerond. Er wordt geen nieuwe functionaliteit meer ontwikkeld. Vervolgend wordt het project afgerond en geëvalueerd.
  • Manage. Deze fase beschrijft het onderhoud van de opgeleverde software. Ook hierbij gelden de smart use cases als uitgangspunt, en wordt meestal gewerkt in maandelijkse of tweemaandelijkse iteraties.

Hoewel de meeste agile methodieken zijn voortgekomen uit de reguliere systeemontwikkeling, zijn de karakteristieken, technieken en fasering goed toepasbaar in business intelligence projecten – wat in principe natuurlijk ook software development is. Laten we eens kijken.

Snel en frequent opleveren

Het snel en frequent opleveren van voor de klant relevante software is een aspect van agile methodieken dat in business intelligence bijzonder goed van pas komt. In plaats van de verticale fasering in traditionelere BI-projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal in te steken. Niet langer worden alle extracties eerst opgeleverd, aansluiten de transformaties en het laden van de gegevens om pas daarna de rapportages te ontwikkelen. Liever wordt er per rapportage ontwikkeld. Hierbij kiest de opdrachtgever welke rapportages de hoogste prioriteit hebben, en start het team met het uitsluitende realiseren van de daartoe benodigde extracties en transformaties, en het opstellen van de rapportage. Deze kanteling van werkzaamheden vergroot de mogelijkheden op feedback van de opdrachtgever, en de toepasbaarheid van het opgeleverde. Belangrijk bijkomend voordeel is dat de rapportages zodra ze beschikbaar zijn, soms al enkele weken na aanvang van het project, direct kunnen worden aangewend om de bedrijfsprocessen te verbeteren. Zo toont het project al op heel korte termijn benefits.

Korte iteraties

Agile software development promoot het werken in heel korte iteraties, bijvoorbeeld van twee weken of dertig dagen. Bij de start van iedere iteratie wordt beschouwd welke work items de hoogste prioriteit hebben. Dit zijn rapportages, maar individuele smart use cases die van pas komen bij de realisatie van een rapport. Zo wordt voortschrijdend inzicht nu eens niet uitgebannen, zoals in traditionele werkwijzen, maar kunnen nieuwe inzichten direct worden geïncorporeerd. Hoewel het principe geldt dat tijdens de lopende iteratie de scope niet mag wijzigen, kunnen nieuwe requirements al tijdens een eerstvolgende op de rol worden gezet. Zodra de opdrachtgever de eerste versie van een rapportage of analyse onder ogen krijgt, kan hij of zij direct feedback formuleren, die ook weer direct wordt geïmplementeerd; zonder daarbij afbreuk te doen aan de structuur en voortgang van het project. We hebben in projecten gemerkt dat zo het in de praktijk benutten van analyses en rapportages (zeg maar de acceptatie) sneller tot stand komt. Tenslotte is het mogeljk nieuwe inzichten rond eventueel benodigde data entry direct op te pakken, zodra deze gaande het project worden onderkend.

Compacte eenheid van werk

Kort door de bocht gezegd is een BI-project uit te drukken in drie typen ontwikkelwerk: datamodellering en ETL, het definieren van analyses en rapporten en het ontwikkelen van data entry applicaties. In Smart geldt de smart use case als eenheid van werk, zowel voor het beschrijven van de requirements, het maken van schattingen als het realiseren van voor de gebruiker relevante functionaliteit – en zelfs als eenheid voor het testen van deze functionalitiet. Voor het modelleren van smart use cases gelden strikte richtlijnen, die ertoe bijdragen dat smart use cases een vergelijkbare lage granulariteit hebben, en al vroeg in een project zijn toe te passen – al tijdens de fase Propose. Er is een groot aantal standaardtypen smart use cases beschreven, die use case stereotypes worden genoemd. Voorbeelden hiervan zijn manage (onderhoud van een object), search (zoeken naar objecten), graph (rapportage) of file import.

Opvallend genoeg is gebleken dat smart use cases ook prima in agile BI-projecten kunnen worden aangewend. 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 software development. Maar ook voor het vaststellen van analyses en zelfs voor het uitvoeren van ETL zijn inmiddels use cases stereotypes vastgesteld, zoals collect, integrate en aggregate.

Smart use cases worden vroeg al vroeg in een agile BI-project geïdentificeerd, tijdens de Propose en Scope fasen. Daarbij wordt alleen de overview van use cases vastgelegd; details worden pas uitgewerkt tijdens realisatie. Aan de hand van deze overview is de omvang en doorlooptijd van het project in te schatten. Aansluitend worden de iteraties uit de fase Realize ingepland. Tijdens deze iteratie ligt de focus op het realiseren van individuele rapportages, op basis van de hiertoe benodigde smart use cases voor ETL, eventuele data entry en de definitie van de gewenste rapportage.

 

clip_image008

Deze wordt zo snel mogelijk gerealiseerd en met de opdachtgever afgestemd. Bijkomend voordelel is dat de onderliggende dataflows, die nu zijn uitgedrukt in smart use cases, beter individueel te testen zijn, en zelfs is door het modelleren van de use cases hergebruik van dataflows snel geïdentificeerd.

In BI-projecten is het snel en frequent opleveren van nieuwe rapportages en analyses van groot belang voor de opdrachtgever. Immers, ieder nieuwe rapportage kan direct worden benut in de praktijk en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben BI-projecten baat bij het met voortschrijdend inzicht dat onstaat dankzij de korte iteraties in agile projecten. Beter dan dit uit te bannen, zoals traditioneel wordt gepoogd, is het om juist effectief gebruik te maken van deze inzichten en feedback. Daarbij is de keuze om in projecten te focussen op de realisatie van individuele rapportages en analyses, in plaats van laag voor laag de benodigde ETL te ontwikkelen.

Agile dashboards

Daarbij biedt Smart een tweetal pragmatische gereedschappen om de voortgang van het project te bewaken; een agile dashboard en een burn down chart. Tijdens de uitvoering van een project verkeren de individuele smart use cases in verschillende, opvolgende statussen, zoals New, In Iteration, Working, Testing, Rework en Accepted. Het agile dashboard biedt een overzicht over de smart use cases in het project, die in kolommen zijn verdeeld, afhankelijk van de status waarin ze zich bevinden. In een oogopslag is zo, ook voor de opdrachtgever, te zien hoever het project is.

clip_image010

Omdat de smart use cases worden uitgedrukt in smart use case punten, is bij ieder statuswijziging direct na te gaan hoeveel punten (en uren) nog benodigd zijn om het project te voltooien. Een burn down chart toont de dagelijkse momentopname van deze uren, uitgezet in de tijd. Een eenvoudige extrapolatie kan nu de verwachte einddatum van het project calculeren.

clip_image012

In agile BI-projecten is het overigens niet alleen zeer zinvol een burn down chart te gebruiken voor het gehele project, maar ook om een dergelijke chart per rapportage te projecteren. Juist omdat de rapportages zo snel mogelijk moeten worden opgeleverd, levert dit laatste de opdrachtgever directe informatie over de voortgang, en wanneer het nieuwe rapport is in te zetten in het besturen van zijn bedrijfsprocessen.

Afsluitend

De agile karakteristieken, fasen en technieken zoals hier gepresenteerd spelen bijzonder goed in op de snel wijzigende en uitbreidende wensen en eisen aan BI-projecten. Het toepassen van smart use cases biedt projecten daarnaast een gestructureerde, maar vooral pragmatische manier om in het hele project met eenzelfde eenheid van schatten en werken te opereren. De gereedschappen die in Smart-projecten worden gebruikt om de voortgang te meten, zoals het agile dashboard en de burn down charts per rapport, bieden bovendien direct inzicht in de realisatie van de rapportages en analyses, met snel resultaat tot gevolg, en met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen toch?

Sander Hoogendoorn
Principal Technology Officer Capgemini

Sandra Wennemers
Managing Consultant Capgemini

Zie ook www.smartusecase.com voor meer informatie over Smart, smart use cases (inclusief stereotypes) en smart estimation.

A recipe for enterprise agile. Mixing Scrum and Smart

Posted on by
2

To cut to the chase, those of you who have worked on enterprise or service oriented projects before already know this. These types of projects are characterized by a large number of organizational, functional and technically complicating factors. Enterprise software development projects are surrounded by a large number of complicating characteristics and challenges:

  • Many different stakeholders. Projects have many different parties in the organization that are involved. Often such project realize goals for different departments or divisions in the organization. As an example I once coached a project that served 22 different departments. Quite often these departments or division try to achieve overlapping or even contradicting goals.

IMAG0218[4]

  • Business processes. In general enterprise projects (re-)implement (parts of) business processes that are key to the organizations success, rather than building a straightforward web application.
  • Complex software architectures. Most likely, enterprise projects implement business processes in a complex IT landscape or architectures. Think of landscapes that host many different applications all tied together.

IMAGE_634[8]

  • Many external dependencies. Often, such complex IT landscapes contain components that are outside of the organization. Services that run outside the corporate firewall, with other parties. A well known issue to agile projects is that of availability. We need the new version of the service in this iteration, but the other party runs a waterfall project that will not deliver this year.
  • Changing requirements. In enterprise projects, requirements change continuously. Either by changing insights during the project, but more often due to changing legislation or regulations.
  • Many different types of deliverables. Traditionally these projects count many different types of deliverables. Think of service description, user interface, process models, non-functional requirements, workflow, project plans, test plans and many, many others.
  • Multiple roles. Large organizations count many different roles that are involved in projects. There are business analysts, enterprise architects, information analysts, testers, release managers, SAP developers, web developers, SAP functional consultants,

Thus these project often become a mission impossible, and fail in large numbers. Such projects are difficult to estimate, therefore hard to plan. For developers it’s tough to build the software, often with many new techniques and technologies, and even worse for testers, these projects are sheer Impossible to test well. This is where a structured agile approach should come to the rescue.

Being agile in enterprise projects

Independent of the approach that is applied, or the agile process that is followed, being successful in agile projects follows a number of key principles:

  • Multi-disciplinary teams. Instead of different roles such as analysts, designers, developer and testers working in consecutive stages in a project, all roles collaborate in implementation individual work items from heads to tales.
  • Short iterations. Project work in short time boxes, in most cases 2, 3 or 4 weeks. During such an iteration, a number of work items is planned, completed and evaluated – with different terminology in use with different agile processes.
  • A small standardized unit of work. Projects requires a small unit of work, to be able to deliver a number of them in a single iteration. Large work items such as traditional use cases therefore do not apply well.
  • Testing from day one. Testing is an important discipline during agile projects. Testers are involved from the very first iteration, when the first work items are realized. Note that testing in most projects goes way beyond the obvious unit testing – which is actually a developer technique.
  • Continuous measurement. Successful agile projects continuously measure their progress. Since they are always delivering individual work items, measurement in agile projects is easy.
  • Continuous (process) improvement. At the end of each iteration not only the realized work items are evaluated, but also the project approach itself is evaluated, leading to highly effective project approaches.

Scrum in a nutshell

When organizations first start with agile projects, Scrum is often the process of choice. At this point in time, Scrum is by far the most popular and best known agile approach. Scrum is a straightforward lightweight agile process that offers a collection of highly applicable principles and techniques for short iterative projects and is easy to understand. It also specifies a remarkable terminology with scrums, sprints and user stories.

image[3]

In a nutshell, Scrum is characterized as follows:

  • Sprints. Projects are divided into iterations, called sprints. In general these are 2 to 4 weeks.
  • Backlogs. Work items still to be done during a project reside in a so called project backlog. At the start of each sprint items from the backlog are placed in the sprint backlog. These are the worked items to be realized.
  • Sprint cycle. All iterations follow the same simple process, with an iteration kick-off, actual work and a retrospective workshop for evaluation.
  • User stories. The main unit of work is usually the user story, although this is not mandatory. This rather informal requirements technique is shared with the agile process extreme programming.
  • Planning. In general the project and sprint planning is visualized in task boards, which usually is put up on a wall using post-its. Progress is monitored by using burn down charts, a straightforward diagram that on a daily basis displays the number of points still to realize. A trend line in the burn down chart extrapolated from the points identifies the likely project end date. Again this technique is shared with a number of other agile processes, including Smart and extreme programming.
  • Delivery. Every iteration or sprint results in fully delivered products, software or otherwise.

Scrum has proven to be a successful approach in many (smaller scale) web projects. In larger, more complex, service or cloud oriented and enterprise projects, I think Scrum needs to be augmented to fit the project and its environment. Let me explain.

Beyond lightweight agile

When applying Scrum or other lightweight agile processes such as Crystal Clear or the set of lean principles (applied to software development that is) to more complex projects of all sorts, you might recognize a number of shortcomings:

  • Business goals. It is often unclear how the work items in such projects (in most cases user stories) link back to business goals, stakeholders and business processes to implement.
  • Analysis and design. Although many people in the so-called agile community will now think I’m promoting a waterfall approach, in most agile approaches there are hardly any analysis or design activities or deliverables defined.

    For instance, it is undefined how the backlog in a Scrum project is assembled. Let me assure you, in more complex projects some analysis and design is required, albeit not in big-upfront-design mode.

  • Architecture. The same argument goes for software architecture. Most agile approaches lack decent software architectural activities and deliverables. Architecture is often assumed as-is. If you’re implementing business processes that run through a systems landscape of over 40 collaborating systems, you will definitively need to design your architectures, but again this need not be in big-upfront-architecture mode.
  • Roles. Scrum and extreme programming describe a very limited set of roles that, although looking slick,  in most projects does not adhere to the standing organization. There’s often enterprise architects, information analysts, business analysts, middleware developers, application management, testers, release manager. How will a project work with all those roles? There’s a bit more to it than just saying they are allowed to participate in the daily scrum.
  • Testing. Apart from the obvious (developer) techniques such as unit testing, the role of testing more specifically – which is essential in larger agile projects – is not very well described in lightweight agile approaches.
  • User stories. Although very flexible, user stories are a highly unstructured unit of work, despite efforts in epics or story maps. Applying such an unstructured unit of work may result in low re-use, non-repeatable estimation, difficult to standardize development, testing and measurement beyond the individual projects. In a multi-project environment user stories will block progress and reuse (of for instance metrics and code).
  • Delivery cycle. Scrum does not specify the organization of delivery of the products to different environments such as test, acceptance and (pre)production (so called OTAP).

When executing large, more complex, service oriented or enterprise projects, I therefore strongly recommends to overcome these limitations by augmenting Scrum and the likes with additional techniques.

Smart accelerators

In my personal experience in enterprise projects I have had very good experiences with mixing the agile process Scrum with the best practices from another agile processes called Smart to overcome the drawbacks of the aforementioned approach.

Smart originated from the Netherlands in 1998 and was originally designed to implement best practices for DSDM, an iterative approach that was popular in those days. Later Smart grew out to a stand-alone agile approach that particularly combines well with other more basis agile approaches such as Scrum and extreme programming, but also aligns well with PRINCE2.

 image[7]

More specifically Smart puts accents on aspects in project that are only marginally highlighted in other agile approaches. As an example Smart adds the following accelerators to projects:

  • Preliminary iterations. Preliminary iteration types Propose and Scope is where work items are added to the backlog such as a modeling business processes, modeling smart use cases, creating an estimate, creating a cost-benefit analysis, writing a project plan (not that obvious it seems), first-cut software architecture set-up, development environment set-up, project kick-off, team education and first-cut user interface guidelines.
  • Smart use cases. Next to the more “non-functional” work items mentioned above, Smart introduces the well-known smart use cases requirements technique. Smart use cases not only model the needs of the user, but also identify workflow and reusable back-end services.

    This technique allows for identifying re-use, repeatable and reliable estimation, and very good traceability between requirements, architecture and code, great functional testing capabilities. An absolute must in enterprise projects.

ManageSite[2]

  • Estimates. Estimation of size and complexity of a project is estimated and measured in smart use case points, defined on a scale from 1 to 10. Smart use case points of course come from estimating the size or complexity of smart use cases, and is a highly pragmatic and repeatable technique..
  • Work item life cycle. Where Scrum’s work item life cycle contains to-do, working and done, in Smart, work items are delivered through a slightly more structured life cycle, that allows for all roles in enterprise projects to be maximally involved in a collaborative manner.

    Due to the life cycle, work items need not be broken down in tasks, a cumbersome and highly unstructured elements of Scum. In Smart work items simply move through the stages of the life cycle (in most cases in one or two days), the progress of which can be shown easily on a dashboard.

  • Designing. During the daily stand-up meeting, it is decided whether or not a design session is required. This time-boxed design session addresses the design or a single smart use case. Most project will organize this design session directly after the daily stand-up. On a typical time scale, if the stand-up runs from 10:00 to 10:15, the design session runs from 10:15-11:00.

    During such sessions all roles that need to deliver input to this particular use case participate. Of course also the developer and tester are present, so all roles create a homogeneous view of the smart use case at hand.

IMG_0247[4]

  • Smart testing. Working with user stories will normally not result in a very efficient test approach, as user stories do not add structure to the project. Smart describes a standardized approach on functional testing in agile projects of course based on smart use cases.
  • Stabilizing iteration. Usually the last iteration of a Smart project or the last one to an upcoming release is used to round off remaining work items, build issues, bugs, and remaining features. This iteration is merely used to stabilize the solution. In Smart this iteration type if referred to as Finalize.

Blending Scrum and Smart

Besides defining an obvious project life cycle, these best practices from Smart blend in really well with the more lightweight approach of Scrum and extreme programming. This leads to the following best practices:

  • Initial backlog. The initial backlog of the project is filled with the work items Smart recommends, rather than assuming a user story filled backlog. When prioritizing work items for the first sprint in a mixed Scrum and Smart project, it is very likely that these are picked.

    As a result, after one or two iterations, a project plan for the remainder of the project is produced, containing at least an estimate, based on the smart use cases that are also defined during these iterations (of course without any analysis or design, just the diagrams, the ovals and the actors).

  • Iteration kick-off. After the initial work-items are cleared from the backlog, the smart use cases become the primary work item type in the project. During sprint kick-off a number of smart use cases is picked to implement in the next sprint.
  • Dashboard. The traditional Scrum task board is replaced by Smart’s agile dashboard, containing columns for the stages in the work item life cycle – In Iteration, Designing, Working, Testing, Rework, Accepted. If appropriate additional columns can be added, e.g. when testing is split up in Developer Testing and Customer Testing.

IMAGE_041[7]

  • Points. The progress in the project is not measured in story points, but rather in smart use case points.
  • Scrum meeting. The focus of the daily scrum meeting shifts a bit as it is also used to answer the question: what still needs to be done on the smart use case(s) we’re currently working on to get them accepted?
  • Design. Host the design sessions as Smart recommends, preferably right after the daily scrum meeting. 
  • Testing. As the work item life cycle clearly stipulates, functional testing, often done manual is all in a days work. The role of the testers here becomes imminent in the project.
  • Finalize. Projects have to decide when to apply a Finalize iteration to stabilize the solution and round up loose ends. Depending on the type of project, these iteration can be the very last sprint, but also can be very well aligned with the organizations release calendar.

This approach of mixing best practices, techniques and tools from Scrum, Smart over the past 12 years has proven to be very successful in a variety of projects and project types, including larger Java and .NET projects. service oriented projects, business intelligence projects, and even packaged implementations.

Moreover, when augmented with more technical best practices from extreme programming, such as refactoring, continuous integration, pair programming, and test driven development (smart use cases are a very good unit for unit testing code) projects are aligned to deliver on-time, on-budget, and with just-enough documentation and fitting (reusable) features. As former US president Bush used to say: failure is not an option.

Being Smart in enterprise agile

Posted on by
Reply

As agile is becoming more and more mainstream, organization are starting to do enterprise software development project using well-known but fairly basic lightweight agile processes.

IMAGE_089 

In many projects this has lead to surprisingly bad result, baffling the agile Certified Pokémon Trainers who are coaching these projects. The presentation below shows a number of accelerators or technique that projects can apply to tackle the challenges of enterprise agile projects.

Would be happy to hear your comments!

Being Smart at enterprise agile

De uiterste houdbaarheidsdatum van requirements

Posted on by
Reply

Vorige week gaf ik – voor de zoveelste keer – training in het identificeren en modelleren van smart use cases. Dit keer bevond ik me in de hippe ruimtes van Meeting Plaza Utrecht, boven het altijd sfeervolle Hoog Catharijne. Tijdens de goed verzorgde lunch werd het onderwerp al snel bepaald door de uiterste houdbaarheidsdatum. Van levensmiddelen, maar meer nog, van requirements.

Stickeren

In de horeca is het al jaren een goed gebruik, het stickeren van levensmiddelen, zo weet ik van televisieprogramma’s als Keuringsdienst Van Waren.. Een eenvoudige sticker vertelt wanneer het product is opengemaakt, en tot wanneer het houdbaar is. Is deze uiterste houdbaarheidsdatum verstreken, dan wordt het product weggegooid, onbruikbaar voor consumptie.

image

Maar dan. De uiterste houdbaarheidsdatum van requirements? Het onderwerp kwam ter tafel toen een van de cursisten vertelde op dit moment te werken aan de realisatie van een verzameling requirements uit een RFC die inmiddels twee jaar oud is. Twee jaar oude requirements? De kans is groot dat deze requirements inmiddels al behoorlijk beschimmeld zijn; wet- en regelgeving is gewijzigd, en de wensen van de gebruikers zijn ontegenzeggelijk veranderd. Als tijdens een gemiddeld project de requirements al 20-25% wijzigen, hoe vergaat het dan requirements die ergens op een plank liggen te verstoffen?

Requirements en kaas

Welbeschouwd zijn requirements te vergelijken met kaas. Je hebt jonge requirements, net rijp genoeg om te consumeren, jong belegen requirements die eigenlijk al hadden moeten worden gerealiseerd, en dan oude requirements, die opzichtig beginnen te brokkelen. Tenslotte zijn alle ongebruikte requirements overjarig. Wellicht smaakvol, maar ze vallen al uit elkaar op het moment dat ze worden gehanteerd.

image

En net als kaas die op een plank ligt te rijpen verdienen requirements dezelfde zorgzame aandacht willen ze na een of twee jaar nog consumeerbaar zijn. Ze moeten worden omgedraaid, geevalueerd en verzorgd. Gebeurt dit niet dan verschimmelen ze en moeten ze eenvoudigweg uit de handel worden genomen, ongeschikt voor comsumptie.

Ik denk dan ook dat het een goed idee is ook requirements te stickeren, net als alle andere bederfelijke waar. Wanneer zijn ze aangemaakt, en belangrijker nog, wanneer dienen de requirements gerealiseerd te zijn.

Maar wanneer zijn onze requirements eigenlijk bedorven? Een kritisch agile luisteraar zal wellicht zeggen dat requirements beginnen met rotten zodra ze zijn opgeschreven. Immers, voortschrijdend inzicht begint direct te werken. Wellicht is het goed een standaardtermijn voor bederf te hanteren, zeg een half jaar. En wellicht zijn requirements waarin de user interface speelt sneller bedorven. Die krijgen dan een sticker van drie of vier maanden. En wanneer requirements over hun uiterste houdbaarheidsdatum heen zijn? Gewoon weggooien!

YAGNI

Het is overigens goed mogelijk de uiterste houdbaarheidsdatum te rekken. Hier komt het bekende YAGNI-principe goed van pas. You aren’t gonna need it. Ofwel voorkom in projecten al het werk dat op dit moment nog niet nodig is. Doorvertaald naar requirements komt dit er op neer dat alhoewel het verstandig is aan het begin van een project vast te stellen welke requirements er moeten worden gerealiseerd, alle details  van deze requirements pas echt nodig zijn zodra de realisatie ervan aanvang neemt. En dat is pas veel later.

Dit verklaart ook deels het succes van agile, kort-iteratieve projecten. De details (analyse en ontwerp) van een requirement worden pas bepaald zodra deze tijdens een van de iteraties daadwerkelijk wordt gebouwd. Zo wordt voorkomen dat er vroeg in een project veel werk in requirements wordt gestoken die nooit worden gerealiseerd, zoals in watervalprojecten nog wel eens het geval is. En bovendien, wanneer de details bijvoorbeeld pas na een half jaar worden onderzocht, is het voortschrijdend inzicht van dat half jaar automatisch geborgd. Om in de metafoor te blijven, zo zijn requirements altijd vers.

Benieuwd overigens wat de uiterste houdbaarheidsdatum van deze post zal blijken te zijn.

Delivering products in agile (Smart) projects

Posted on by
Reply

In most cases where a form of agile software development is applied, projects are challenged with difficult issues, such as a swaggering scope, unclear and incomplete requirements, unstable software architecture, are quickly approaching dead lines. Within these strict boundaries projects try to deliver high quality software at high productivity – or velocity. This is not an easy challenge.

Delivering just what is needed

Therefore, during agile projects there is high pressure on delivering just that what is needed. The emphasis of an agile project team is on creating just the right (amount of) software, and minimizing the amount of work spent on other products, such as documentation and work in the peripherals of the project. Although many project teams seem to call on this principle to actually not deliver any documentation, the fine art of being agile is delivering just-enough, just-right documentation.

In our experience, a lot of time is spent in agile projects on deciding what’s enough, and moreover, what’s right. Especially when projects are executed in complex organizations, and applying complex (service or cloud oriented) technology, finding the right level of documentation is actually a quite intriguing task, and goes beyond writing (structured or not) user stories.

Delivering products

In the vision of the agile process Smart (and other agile processes, including Scrum and feature driven development) projects should focus on delivering products, not just on performing activities. Please note that working software is not the only product a project delivers.

The agile process Smart suggests to deliver a number of products that will guide projects through these just-enough, just-right in a more standardized fashion. In essence, Smart projects are product driven, as are other agile processes such as Scrum, FDD and OpenUP. During each of the iterations in a Smart project, the team delivers a number of working products. These products fall into a few categories:

  • Project deliverables. In each of the different types of iterations Smart suggests to deliver additional products that will help drive your project to success. These products might include well know deliverables such as a project proposal and non-functional requirements.
    Although none of these product are actually mandatory in a Smart project, they are considered good practice, and over the years have been produced in numerous Smart projects. Using these standard suggested products, organizations get an even better grip on the projects at hand. Note that emphasizing the existence of other project deliverables besides working software (in smart use cases) does not mean projects become less agile.
  • Smart use cases. The body of products delivered in a project is formed by smart use cases, small discrete pieces of functionality that drive development. Smart use cases is a technique to rapidly model your functional requirements at a equal-granular level. Smart use case supply a small and very useful unit of work, and furthermore serve as the main unit of estimation, planning, but also drive realization, testing and even delivery.

All products, both project deliverables and smart use cases run through (a subset of) the product life cycle.

Project deliverables

All products that need to be delivered to run your projects and do not deal with implementing functionality directly (which moreover is partitioned in smart use cases) are referred to as project deliverables. Most of these project deliverables are one-off, although they might be maintained and updated during the project, such as the project’s software architecture and the domain model. Any Smart project needs to decide which of the suggested project deliverables will be produced, and in which iterations.

IMG_0243

An easy way to achieve the optimal set of project deliverables is to add the products suggested by Smart to the project’s backlog during the different iterations defined in the Smart process. Or alternatively, add them to the backlog at the start of the project. This allows project teams to add them to the list of products to deliver in any of the iterations.

For example, during the first Propose iteration the smart use case model, a project estimate and a project proposal can be added to the iteration backlog. At the start of the Scope iteration, the software architecture and reusable services might be added. At the start of each of the iterations, the customer and the project team decide which of these products will be picked up and produced.

Examples of project deliverables

Some examples of project deliverables are:

  • Project proposal. A first proposal covering the primary scope of the project and a first cut estimate is produced as a the final project deliverable for Propose iterations.
  • Project plan. The project plan describes the project approach, the stakeholders and goals, business case, risks, resources, timelines and project estimate. The project plan is mostly delivered at the end of Scope iterations.
  • Iteration plan. For each iteration a very brief iteration plan might be documented, sometimes not longer than a single page. This iteration plan describes the list of products (mostly smart use cases) to be implemented and resources needed. In most projects, iteration plans result from the planning session at the start of each iteration.
  • Software architecture. Document describing the architecture for the project. Ideally, your software architecture is an instance of a reusable reference architecture that might be in place at a organization. Having a reference architecture will allow a project team to focus only on deviations. This saves valuable time and effort.
  • Business process model. Most projects implement one or more business processes, and a number of additional functions that support these processes. Smart use cases can be derived from these business processes, independent of how these processes are modeled. The business process model is either obtained from the organization, or created during the project.
  • Smart use case model. The smart use case model is leading in Smart project. It delivers software estimates, and presents an overview of the scope of the project.
  • Domain model. Most custom software development projects will have a model describing the business domain and business services. Sometimes this model stems from previous version of the software, for instance modeled in a data model. In service oriented projects, the domain model in most cases overlays the services called in different back end systems, as forms the basis for a service consuming front end.

Again, in most cases these deliverables are one-off. They are created once during a project, but quite often maintained or updated later on, think of the domain model and a reusable services model.

Smart use cases

Most of the work in delivering working software in iterations that are of type Realize or ‘Finalize” relates to the realization of smart use cases. The smart use case has become our main unit of work. They are implemented following the product life cycle. The work on each individual smart use case includes analysis, design, test design, build, test and acceptance. This work is always visualized using an agile dashboard, either using post-its on a wall, or using an (online) automated dashboard.

Read more

You will find more information on these subjects at:

The iteration cycle of an agile Smart project

Posted on by
1

Smart is an easy to implement agile process, that is essentially smart use cases driven. Although Smart mixes very well with other agile processes and techniques, such as Scrum, XP and FDD, the process that takes a project through a little more ceremony than you might expect from a number of other agile processes. For instance, Smart suggests a number of products to add to the backlog, that deal with managing the project environment, such as project plans, estimates, or even setting up the development environment. Moreover, Smart is based on the use of smart use cases, where Scrum and XP on less standardized and less structured (user) stories.

The Smart iteration cycle

Each type of iteration in a Smart project is concerned with delivering a (number of) product(s), not necessarily all code. During early iterations, suggested products could for instance deal with setting up the project, determining the scope, creating a project estimate, or something trivial such as creating a straightforward project plan.

Further down the road, most of the products delivered in iterations will be (designed, built, and tested) accepted use cases. Depending on the type of products to be delivered, the iterations are branded as Propose, Scope, Realize, Finalize, and when the software is put into application maintenance iterations are usually typed as Manage.

There is one thing all these types of iteration have in common. All iterations in a Smart project follow the same procedure. This procedure is called the smart iteration cycle. The smart iteration cycle is split up into three different parts, as depicted in the image below.

image

The smart iteration cycle contains three major parts. These three parts in an iteration are Plan, Build and Evaluate.

Plan

Planning your iterations is essential. During the iteration kick-off the customer and the project team decide on which products will be delivered during the upcoming iteration. How many products can actually be delivered depend on the team velocity and the estimated effort that is required to realize the individual products.

IMG_0241

A small but pragmatic iteration plan is usually set up, which also defines the acceptance criteria for each of the products to deliver – in other word defining done for each of the products.

Smart projects focus on implementing smart use cases ,delivering working software. One of the main reasons for applying these is that the approach to modeling smart use cases is standardized an thus it is easier to define done.  Furthermore, it is also easier to estimate the effort required to realize these (quite often stereotyped) smart use cases.

Build

During the Build part of any iteration, the products will be realized to meet with the done criteria. To be able to monitor a project’s progress we realize products following a simple product life cycle, which is easy to visualize in a project dashboard. Although there are several possible variations of this product life cycle, it is always executed on a daily basis, starting with define what still needs to be done to finalize the product during the daily stand-up meeting.

IMG_0006

When it comes to implementing smart use cases, the product life cycle defines brief analysis, design, coding, test and accepting the planned smart use cases. This is in high accordance with YAGNI principles, as elaboration of the individual smart use cases takes as little time as possible before a particular use case is actually built and tested.

Evaluate

Each iteration is rounded up and evaluated. This is quite an important moment in the iteration. Basically we evaluate the speed at which the project is travelling, the products that are delivered and how well the process that is applied suits the project.

Measuring in abstract points, it is quite easy to evaluate the current speed of a project, given the number of iteration spent and the number of points realized. This results in the iteration velocity, the average number of points realized during one iteration. Projecting the iteration velocity on the number of points still left in the project, will present you with an estimated end date. This data is used the steer the project.

Each of the products delivered is briefly considered during evaluation. The project’s progress can often easily be demonstrated with a short demo.

IMG_0238

Although Smart projects are highly standardized, we see that it must fit in with the customer organization, or can be optimized to deliver a more precise to what is actually needed, or work even more efficiently. During evaluation adjustment to the process are discussed, and will be implemented during the upcoming iteration.

Read more: www.accelerateddeliveryplatform.com.