Category Archives: Smart

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

The Waterfall Dentist Anti-Pattern

Posted on by
Reply

Believe it or not, but I have a confession to make. I’m currently in a pure waterfall project. It’s my first in many, many years and despite the fact that I love the technology, I don’t like our way or working it a bit.

During the first phase of this project we are trying to deliver twenty functional work items. All of these twenty work items are analyzed first, then reviewed. After all review comments have been processed, all work items are designed. And again reviewed. After all review comments have been processed again, the developers start constructing them. And once they finish the testers have a go at the software produced.

Yes, I know this is efficient nor effective. And yes, the testers find lots of defects that could have easily been prevented using an iterative approach where we jointly work on a single work item, and only after it’s finished move on to the next. But we just don’t. And the delivery date is nearing. As a result, at the delivery date we will likely deliver twenty half-baked work items, instead of delivering maybe ten or twelve complete work items. It’s a choice.

End of discussion

You could say that the discussions about the chosen approach I have with the project manager are vivid. At the very least. “No, we’re not going to do agile,” he clearly states. “I don’t care if we call it agile or not,” I respond, “But the way we are working now is simply inefficient.” Personally I really don’t care if projects are tagged as agile, Scrum, Smart, RUP or even waterfall. I just dislike inefficient processes. “This approach is easy to explain to the client,” the project manager continues, “So we are going to stick to it. End of discussion.”

And then coming out of my girlfriends’ apartment building this morning I saw this car in the parking lot. It occurred to me immediately. We are waterfall dentists.

2012-08-18 12.42.59

Imaging you’re a young dentist, fresh out of dentistry school, and you are starting a new practice. Why on earth you would name it The Waterfall I don’t know, but twenty new patients are hurdling up to be treated. Being The waterfall dentist you use an appropriate approach. During the first week you examine all twenty patients. During the second week you commence to the first part of their treatment: drilling holes. Then in the third week, all twenty patients come back and have the holes filled. In the fourth week all patients return again for a last check-up. Just testing if all holes are filled properly. Finally, in the fifth week you get to send twenty bills to twenty happy patients. Project done. Next project.

Good bookkeeping and new patients

Doesn’t that sound good? This approach resembles my current project in great detail. So why is it, although this model is easy to explain to patients, no dentist in the world would even slightly consider to apply it? Well, first of all, your patients don’t like to walk around with unfilled holes in their mouths for a least a week. Second, your patients will have to come in to your office four times, and you will have to do pretty good bookkeeping to remember each patients details when they return. If you would have filled a patients tooth right after you’ve drilled a hole, this need for documentation and good memory wouldn’t have been necessary. Moreover, what if a new patient comes in during the second or third week with a terrible toothache? You would have to decline him saying: “Sorry, I don’t take additional work now,” advising the new patient to come back after all current patients are serviced. It’s the vicious change request. And what if you become ill during? Your whole schedule will certainly slide. As a result, none of the patients will have been fully serviced at the end of the scheduled period, leaving them in uncertainty about when you will deliver. Basically, you will loose your patients as fast as they hurdled up. And you won’t be able to send any bills.

I could probably spent another two posts in explaining why the waterfall model isn’t applied by dentist anywhere in the world. But I won’t.

We just might

Dear project managers, despite the fact that the waterfall model is so easy to explain to clients, that doesn’t make it any more effective or efficient. Armed with The Waterfall Dentist Anti-Pattern, you can explain iterative, or agile, approaches to your clients just as easy. In fact you can even service your clients better, as they may send in new urgent patients during the project, and you will be able to service those patients early. And even though you may turn ill during the project, servicing the patients one by one, rather than in a returning batch, you can actually fully service a large number of them within the designated timebox, instead of having serviced all of them half when the deadline approaches. I would much rather be able to send bills to fifteen out of twenty patients, then not being able to bill at all.

So where’s my current project standing? Well, just like The waterfall dentist might actually serve twenty patients during the current phase, we might actually deliver all twenty work items. But I wouldn’t bet my gold teeth on it.

Agile anti-patterns. Yes you agile projects can and will fail too

Posted on by
Reply

Over the years I have noticed a lot of agile anti-patterns during projects. Wrongly used agile approaches, dogmatic use of agile approaches, agile-in-name-only. Recently I have presented a talk at a number of agile and software development conferences that demonstrates patterns of agile misuse. These conferences include Agile Open Holland (Dieren), Camp Digital (Manchester), GIDS (Bangalore), ACCU (Oxford) and Jazoon (Zurich). Anyway, here’s the slide deck. Enjoy.

Agile Anti-Patterns. Yes your agile projects can and will fail too.

Evolving agile

Posted on by
1

Without any doubt agile is the biggest evolution in software development approaches since the introduction of waterfall back in the early seventies. And yes. Agile is an evolution rather than a revolution. The best practices and techniques in agile didn’t just pop-up. Rather they emerged from years of hard-working, real-life experience in succeeding and failing in projects.

So working in short iterations, in multi-disciplinary teams, prioritizing our work items regularly, and testing and delivering early and frequently using simplified communication, as we could capture agile in a single sentence, are improvements we’ve all introduced in our software development projects over the past forty years. Agile, and all of it flavors, such as Extreme Programming, Scrum, Smart or Kanban, have merely evolved from teams trying to do a little better every day. And have succeeded in doing that.

In the second decade of this century, due to the overall success of agile approaches, the majority of organizations executing projects will move towards agile. Either quickly or slowly. And for a variety of reasons. To raise quality. To increase predictability. To execute on-time, on-budget. To minimize time-to-market. Or simply because Gartner says so.

But with the success of agile come new challenges. Agile projects require agile coaches. Whether certified as Scrum Master, Lean Champion, or Pokémon Trainer, there is a lack of sufficiently experienced agile coaches. As a result an increasing number of projects is guided by ill-experienced coaches, often leading to a dogmatic and rigor application of agile. More over large organizations will feel the need to standardize, industrialize or institutionalize their agile efforts, resulting in ill-digestible, comprehensive agile manuals.

Although adaption and creativity are fundamental to agile, these growing pains will slow down the enormous progress we are making in the field of software development approaches. Agile is meant to evolve. Always. Continuously. Improving and professionalizing our software development is not a frog-leap process, proceeding with one giant leap every fifteen years. It is an fluid, never-ending process of many, many little steps taken on a daily basis. We learn from what we do. Yesterday, today, tomorrow, next year.

This post was written as a contribution to the upcoming book “Shaping Apps Germany”, published by Capgemini, Germany.

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

The explicit role of testing and testers in agile projects

Posted on by
2

Not all agile processes and approaches recognize the role of testing explicitly, other than stressing the importance of unit testing. However in short iterative projects, testing is key from day one.

On of the agile approaches that does explicitly describes the role of testing – and of having testers on-board – is the agile process Smart. One of the characteristics of this process is that its main unit of work is the smart use case. Smart specifies the life-cycle of a smart use case. By default it includes design, test design, development, testing, rework and acceptance.

Smart use cases versus user stories

In many projects additional stages are introduced. In my current project the explicit importance of testing is easily visualized in the following dashboard.

image
Dashboard from my current Smart project

All smart use cases go through this life cycle. This is a rather different approach than working with user stories. At the start of an iteration in Scrum (yes, I know iterations in Scrum are often referred to as sprints) each chosen user story needs to be split up in individual tasks. Due to the heterogeneous character of user stories, this is a repetitive activity. Smart use cases are a much more standardized unit of work, and thus can go through a standardized life cycle, without the need to split them up further.

Test stages in implementing smart use cases

From the picture it might not be all that clear, but in our current project our smart use cases go through 5 testing stages:

  • Unit testing. A developer implements (in stage Working) the code for a particular smart use case. Next to developing the code, the developer also implements the unit test for the smart use case. These unit tests are vital for regression testing the use cases (at each build).
  • Developer testing. Right after the developer finishes working on a particular smart use case, he moves the post-it to the stage developer testing. Here another developer picks it up and runs the use case to avoid basic mistakes.
  • Testing. Next the smart use case is moved to the Testing stage. Here a tester compares the smart use case implementation to the design. In most cases the tester will use a process cycle test, or a use case test to identify test scenarios and write test cases.
  • Acceptance testing. When the tester has declared the use case ok, acceptance testing is performed by the domain experts in the project. Due to the limited availability of the domain experts in most agile projects, it’s the tester who does most of the work. Acceptance testing becomes a lightweight black box test.
  • Approval testing. Last but not least, twice per iteration the newly accepted use cases are presented to the end users. The end users approve the smart use cases as soon as possible.

When an anomaly is found during either one of these stages, the smart use cases are moved to rework, validate the possible change. After that the smart use case re-enters the regular cycle.

This approach ensures high quality code and totally removes the need for extensive user acceptance testing at the end of a project.

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.

November 25 & 26, 2010 – IT Works. Pragmatic modeling using UML

Posted on by
Reply

[Two day hands-on workshop at IT Works, Hotel Crowne Plaza, Antwerp. ]

On November 25 and 26 I will present the 32th edition of an intense two-day workshop on the pragmatic use of UML modeling techniques (and beyond) with lots of hands-on exercises.

IMAGE_073
Participants modeling activity diagrams with smart use cases

During this workshops we will go through the following subjects in depth:

  • A brief introduction of UML and its modeling techniques
  • A pragmatic YAGNI approach to modeling business processes and requirements.
  • Modeling hierarchical and chronological business processes.
  • Modeling traditional and smart use cases.
  • Modeling activity diagrams (for use cases).
  • Identifying test scenario’s for (smart) use cases using activity diagrams.
  • Modeling the user interface.
  • Modeling class diagrams.
  • Domain driven design.
  • Interaction modeling. Bringing together an applications structure and behavior, based on a pragmatic use case driven software architecture.
  • Modeling service oriented projects using smart use cases.
  • Modeling in agile projects.
  • A brief introduction to model driven software development.

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.

Spring 2010 speaking engagements

Posted on by
Reply

Again doing a lot of talks this spring on a wide range of subjects, from new technology, via enterprise agile to model driven development, but also about smart use cases, domain driven design, UML, and software architectures, design patterns, frameworks and .NET.

This season’s highlights? Not a difficult choice: doing talks both at Microsoft DevDays and TechEd North America is great. But revisiting SET in Zurich is not bad either. And what about the Dutch Testing Conference?

 DSC_0058

Check out my spring talks below (with links and logo’s):

  • Around the world in 80 slides.
    February 9. Keynote at Capgemini TechEd, Utrecht.
  • Pragmatic modeling using UML and beyond
    March 3-4. Two-day workshop at IT Works, Antwerp, Belgium.
    www.itworks.be
  • We’re not in Kansas anymore. New trends in Microsoft technology
    March 8. Capgemini Micrsoft Practice Meeting. Utrecht.
  • Pragmatic modeling using UML and beyond
    March 10-11. Two-day workshop at Array Seminars, Hilversum.
    www.arrayseminars.nl
  • CIO challenges. From enterprise agile to model driven development.
    March 16. Talk Capgemini customer event, Utrecht.
  • How smart use cases will change your life
    March 23. Guest lecture at Hogeschool Utrecht, Utrecht. .
  • Agile development in everyday practice
    March 24. Seminar at Array Seminars,  Nieuwegein.
    www.arrayseminars.nl
  • Do’s and don’ts in implementing extension methods
    March 30-31. Talk at Microsoft DevDays 2010. Den Haag
    www.devdays.nl 
    .
    image
  • Beyond agile testing
    April 7. Talk at Capgemini Testing Community Event, Utrecht.
  • Beyond agile testing
    Arpil 21. Talk at Dutch Testing Conference 2010, Nieuwegein.
    www.dutchtestingconference.nl
    .
    image
  • Mission impossible? How to survice agile SAP SOA projects
    May 18-20. Talk at SET 2010. Zurich, Switzerland.
    http://www.sigs-datacom.de/set/set-2010
    .
    image
  • Estimating with smart use cases
    May 26. Seminar at Array Seminars, Nieuwegein.
    www.arrayseminars.nl
  • Software architectures and patterns in .NET.
    June 2. Seminar at Array Seminars, Hilversum.
    www.arrayseminars.nl
  • How frameworks can kill your project and how to avoid getting killed
    June 7-11. Talk at TechEd US 2010, New Orleans, USA.
    northamerica.msteched.com
    .
    image
  • Pragmatic modeling using UML and beyond
    June 23-24. Two-day workshop at IT Works, Antwerp, Belgium
    www.itworks.be