Early offshore

Particularly during the early years of offshore software development, the majority of projects were executed using rather traditional, Waterfall-style approaches. Projects were characterized as fixed-price and fixed-date. The requirements and the design were compiled onshore, after which coding and testing was done in another part of the world, be it Eastern Europe, India or South America.

The Waterfall model typically involves executing each of the activities in software development consecutively, and only once – requirements, analysis, design, code, test and deployment – to deliver a product based on the completion of each of these project milestones. Interestingly, this model has led to high failure rates in projects, even without offshoring some of the activities. At each milestone knowledge is lost and testing is executed very late – only when development is done – with exponentially rising costs of repairing bugs. Moreover, achieving completeness in requirements early on in a project is difficult and changes to requirements are costly.

Oddly enough, even with these anomalies, and even with failing local projects, many organizations still ventured into offshore software development applying the Waterfall model. Not surprisingly, many of these projects failed to deliver on time or on budget and did not deliver the required functionality. Despite the hoped-for benefits of lower costs and high availability of skilled people, offshore projects add another level of complexity due to more complex control and coordination, and because of language, cultural and time zone discrepancies.

Is Agile more suited for offshore than Waterfall?

So with Agile approaches, such as Scrum and Kanban, reaching the peaks of their popularity, an interesting question is: can Agile approaches and techniques overcome some of the shortcomings of offshore Waterfall development?

In short, Agile approaches are characterized by working in short iterations, where during each iteration a number of continuously re-prioritized work items are fully realized by a multi-disciplinary team, usually applying a similar life cycle per work item – requirements, analysis, design, code, test and deployment – as Waterfall uses over a whole project.

At the start of an Agile project the requirements are only identified, and not compiled into full detail. This list of requirements is known as the backlog, and is not designed to be complete. Rather, items from the backlog are elaborated on during iterations (also known as sprints). So all the real work is done during iterations. As a consequence, Agile teams are required to be multidisciplinary, and work together on a daily basis to implement functionality work item by work item. As such, co-location of teams, quite often at the client, works best in Agile.

So is Agile more suited than Waterfall for offshore software development? Clearly there are huge benefits. Requirements, analysis and design needn’t be finalized until a work item is actually implemented. So there is no grand, fixed, inflexible design decided upfront. Testing and deployment also take place immediately after coding the individual work items, not only at the end of the project. The total life cycle of a work item is usually no longer than a couple of days, instead of the whole project duration. That is why Agile works well in domains where it is accepted that requirements are never complete and might change, which is the case in the vast majority of projects worldwide.

So what happens when Agile approaches and techniques are applied to offshore software development to overcome Waterfall shortcomings? Apart from the apparent benefits, applying Agile to offshore also comes with consequences. Applying an Agile approach will involve close collaboration between all roles, whether on-site or offshore. It will also involve daily communication, and the ability to work on the same work item at the same time. Communication is therefore key in Agile projects, and as we all know, distance makes communication harder. Therefore offshore Agile teams need to be able to rely on other means of communication than on-site teams. Moreover, it is key that information is clear and  unambiguous, which is difficult as this is exactly the bottleneck that Agile is trying to overcome, as work items are not elaborated on until implemented.

But despite some of the difficulties involved in offshore Agile projects, particularly in highly complex domains or around regulatory sensitivities, Agile approaches have the potential to offer many benefits. In my opinion, it almost goes without saying that offshore Agile is going to be more effective to most organizations than offshore Waterfall, but only when key issues around communication, overheads and language issues are overcome.  I will explore some of the key strategies for making offshore Agile software development work in my next post.

Offshore Agile Software Development: Does It Work?

Gone with the wind

So you would say the current raging popularity of everything agile would bring greater joy to my personal life. Unfortunately it doesn’t. Agile has become the new magical keyword for improving just about anything thinkable. There’s an agile mindset. The word agile is dropped on a daily basis in advertisements. There’s agile cars, agile games, and even agile washing powder. And on the fly agile seems to inspire people, communities and even movements to change the world. Great.

Yes, I know agile is characterized in dictionaries by quickness, lightness, and ease of movement or even nimble. So yes, I totally agree agile can be applied to much more than software development. But to quote Clark Gable in Gone With The Wind: Frankly, my dear, I don’t give a damn. I don’t care much for changing the world, or even changing organizations. I want to write software. Better. Faster.

Let me give you some examples where agile is going. At a recent agile conference delegates put up a board of interesting books. It contained highly agile books, such as Your Brain At Work, Tribal Leadership and Fearless Change. Without any doubt very interesting and worthwhile books. But what happened to the classics? I didn’t spot Design Patterns, Framework Design Guidelines, Code Complete, Clean Code, or Patterns Of Enterprise Application Architecture?

These days, agile is used as a adapter for all kinds of coaching and personal improvement. From Getting Things Done through neuro-linguistic programming to gamification. There is even an agile game conference in the planning. Or what about personal energy management, product owner “light bulbs” or agile kitchens? All very nice, but very little to do with programming. As said, agile is becoming an accepted synonym for any form of personal development.

Half-full or half-empty?

And it’s getting worse. In many organizations I’ve noticed that agile is both used to illustrate failure of things that have absolutely nothing to do with agile, as well as an explanation for things that go well. Also having nothing to do with agile. Let me also give some examples of this interesting use of the word agile.

First of all, agile seems to become synonymous for anything that is done just-in-time. For instance, some account manager, barely making the deadline for submitting a proposal to a client, commented on the process stating: “Great, we did this really agile,” suggesting that delivering just-in-time is really agile. Nor the proposal, nor the way it was written had anything to do with agile whatsoever. At another occasion, two people showed up late for a meeting. The organizer of this meeting, which was neither a kick-off, a retrospective nor a stand-up meeting, just smiled and said: “Well, that’s agile, isn’t it?” Well, it isn’t. So agile also has become a synonym for things are run over a deadline. The glass can be half-full or half-empty, depending how you look at it.

I suppose it is due to the liberal definition of agile that the word, and in its slipstream words such as Scrum, Kanban and Lean have become daily speech patterns. I am quite aware that we as software developers and testers have no right to claim the word agile for ourselves. And I for one certainly wouldn’t want to deprive anyone from having fun with it. Everybody is entitled to personal development, or to chasing his or her dream to change the world or even an organization, but sometimes I wish we could just go back to what we developers and testers do best: write code and test functionality.

To send mail messages, the MailManager plugs in an implementation of the IMailProvider interface. Currently, Adf provides two mail providers, the obvious implementation SmtpMailProvider, and the DummyMailProvider, which creates the mail messages and dumps it in a specified directory.

Smart use cases, implemented in task classes, are always unit tested. Here, each of the public methods of the tasks are tested using the Adf.Test libraries from the framework. A number of test methods is usually implemented to test all possible scenario’s of going through the smart use cases. In the following code example, such as method is shown.

In this example, the Init() method of the task is called. After it is called the test framework can perform any number of checks. In this example, all validations should succeed, and the Status property of the Account domain object should be set to Unverified. The last validation ViewIsActivated will check if the accompanying (web, Windows RT) page or Windows form is presented to the user.

Recently, we have added new features to also validate whether a task has sent the mail message it was supposed to send. To provide for this functionality, we’ve added a TestMailProvider to the Adf.Test libraries. In your test project, this mail provider needs to be plugged in to the MailManager, as follows in code (or in the app.config file).

This will ensure that any mail messages being send by the tasks, is sent through the TestMailProvider. The test mail provider will, similar to the DummyMailProvider, place mail messages in a specified directory, but foremost it will also notify the TestManager that a message was sent.

Next, when unit testing the method that either sends, or doesn’t send the mail messages, you will be able to verify this, as in the following code example.

You can use the MailIsSent or the MailIsNotSent methods for this means.

protected void lbOpslaan_Click(object sender, EventArgs e)
{
    BindManager.Persist(Persoonsgegevens, panelPersoonsgegevens);

    MyTask.OpslaanPersoonsgegevens();
}

I have added a mechanism to Adf.Net that supports three levels of validation messages. When the ValueObjectPropertyParser is unable to create a valid instance of a value object, it will act as follows.

First it will look if a specific validation message is present at the property itself it tries to create. Use the following attribute ValidationMessageAttribute to define such as message.

[MaxLength(15)]
[ValidationMessage("ReseFasa.Persoonsgegevens.Telefoonnummer")]
public PhoneNumber Telefoonnummer
{
    get { return Get<PhoneNumber>(PersoonsgegevensDescriber.Telefoonnummer); }
    set { Set(PersoonsgegevensDescriber.Telefoonnummer, value); }
}

The message defined will show during validation only if this specific property for this domain object fails to instantiate.

If such an attribute is not present, the parser will look at the type of the property. In this specific example it is PhoneNumber. At the class (or struct) you can now define a ValidationTypeMessageAttribute attribute as follows.

[ValidationTypeMessage("ResaFasa.Telefoonnummer")]
public struct PhoneNumber : IValueObject, IComparable {

This message will show for any property of this type in any domain object that fails to be instantiated. Except of course for those properties that have the ValidationMessageAttribute attribute defined.

If no such attribute is defined on the class or struct, the ValueObjectPropertyParser will display the default validation message, which is defined by the code Adf.Business.NotInstantiable.

Please note that, in any case, normal handling of validation takes place. The defined attributes should use always a code, where the actual message is stored in resource files. By default all three messages take two arguments that can be used as parameters in the message. The first argument {0} is set to the improper value, and the second argument {1} is set to the property that could not be instantiated, with the following result.

The task pattern consists of three major parts:

• Starting the task, either using a parameterized Init() method, or the default Start() method.
• After a task calls another task, and this second task is finished, control goes back to the calling task, using any of the specific ContinueFrom() methods, or the default Continue() method.
• When a task reaches any of the post-conditions of a task, the task needs to be ended, usually through the Ok() or Cancel() method.

In this specific post I’ll look at reaching the post-conditions. In the pattern, the Task class itself acts as the layer super type and implements a number of method to end itself. A use case can have multiple post-conditions. Some of them are positive, some can be negative. And sometimes a specific case needs to be addressed.

When a reaches it positive post-condition, it is a best practices to end it using the Ok() method. This method takes a params object[] p, which allows you to pass back results from the task to the calling task, using the following signature.

public virtual void OK(params object[] p);

A similar method Cancel() exists for task that end in a negative post-condition, usually because the user cancels the interaction:

public virtual void Cancel(params object[] p);

But, Adf.Net also supplies a similar method Error(), to allow tasks to finish with an error, possibly technical.

Under the covers, these three methods call on another method, which is called Finish(). This method takes care of passing back an instance of TaskResult. This result also gets posted back to the calling task, so it knows how the called task has ended. As in the following example, you could also use Finish() yourself.

if (persoon.IsNullOrEmpty())
{
    ValidationManager.AddError(GEENPERSOONGESELECTEERD);
    Finish(TaskResult.Error);
}

Please note that the code above is equal to the following code.

if (persoon.IsNullOrEmpty())
{
    ValidationManager.AddError(GEENPERSOONGESELECTEERD);
    Error();
}

By default, TaskResult has the following values in Adf.Net: Ok, Cancel, Error.

However, as TaskResult is implemented using the descriptor pattern, additional project specific value can be added easily, by inheriting from TaskResult, and added the specific values. Thus you would be able to end your task in more project specific ways, such as in the code example below.

if (persoon.IsNullOrEmpty())
{
    ValidationManager.AddError(GEENPERSOONGESELECTEERD);
    Finish(Dashboard8TaskResult.Aborted);
}

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

This month I hope to round off the work on my new book Dit Is Agile (in Dutch). Last reviews are coming in, and I’m very happy with the results of my hand-drawn illustration for this new book.

The idea of drawing the illustrations by hand instead of using PowerPoint or Visio is working out fine, and also allows me to add some cartoons to the book as well.

I hope and trust the book will be in shops soon.

After a series of very disappointing games the Dutch national football team was eliminated during the preliminary rounds of the European Championships. Comments weren’t mild. The most heard comments largely focused on the lack of team spirit and mental fitness. Not uncommon to Dutch national football teams.

Earlier this week an interesting broadcast of the Dutch sports program Studio Sport included a discussion between some football players and the successful Dutch field hockey coach Mark Lammers. The latter stated that teams perform much better if the players share responsibilities. The Dutch football players at the table responded to this statement that this might work well in a modern game such as field hockey, as one the players said that he even saw it working in his daughters field hockey team, but that football is by nature a very conservative game, with lots of high profile media attention and that in this game the players should just execute the coaches orders.

I couldn’t help but watching this from an agile view. Clearly Mark Lammers would do well managing an agile software development project. Even though responsible for the team as a whole, he insist on giving the players the liberty to collaborate. Pretty similar to how agile project managers guide their project teams. Funny enough the Dutch football players ridiculed his ideas, and repeated that the players should just follow orders. That the game would become total chaos otherwise. Having seen the Dutch team playing, chaos was a actually a word that came to mind. And following up the coaches orders wasn’t part of it.

It’s actually the very same mockery agile has received from traditional managers over the years. Yes this agile stuff might work in small projects (such as the one football players daughters hockey game) or in fancy mobile projects (field hockey is a modern game), it doesn’t work in large, complex, high profile projects. Software development is a highly conservative game. It should not be bothered by this letting-the-players-share-the-responsibilities-in-the-team mumbo jumbo. Football players just execute their individual tasks. Just as analysts, developers and testers do in important software development projects.

Lammers had a good argument. Wouldn’t they agree that if players had influence and saying in what would be the best task, or how to execute it in the best way, they would simply run harder and even collaborate better as a team? The football players looked at him like they saw water burning. Lammers just couldn’t get through to them. Similar to the many discussions I’ve had about agile with traditional managers. It is the team that does the job. Not the individual players.

Doesn’t it just amaze you who unhappy highly appreciated players like Robin van Persie, Klaas Jan Huntelaar, or Wesley Sneijder with their respective tasks, and hence didn’t make it as a team? Wouldn’t that be similar to having Erich Gamma, James Gosling, Scott Guthrie and Anders Hejlsberg as the team of programmers in a project, and than have the project managers handing them out individual tasks, and denying them any influence in the project?

Much to my demise, one of my current projects is actually a waterfall project. Although I am one of the most seasoned guys (resources to the project manager) on the team, and have the role of software architect, the project manager insists on defining individual tasks that I should perform. There’s a whole list. I even book hours on individual posts per task. The horror.

So even though I’m in the role of overlooking the technology in the project, I’m actually constructing individual parts of the framework and the application. Solo. Now to me that is not a very motivating situation. Collaboration isn’t stimulated. So there’s little between the members in the team. In my opinion the project is running in a highly sub-optimal mode, where everybody delivers individual tasks, and then throwing the result over the wall to the next person. The project could be executed much more efficiently if we could operate as a team. With shared responsibilities. Not as a disjoint set of qualified individuals.

Back to the Dutch national football team during these European Championships. Wouldn’t you agree that this is actually a very good description of the whole thing? A bunch of highly qualified individuals all executing individual tasks that didn’t like to do? Wesley Sneijder clearly didn’t like his role as a left winger. And neither did Arjen Robben like his role. Hence they executed them without flair, without efficiency, and most of all without operating as a team. They were executing individual tasks, and throwing the result over the wall to the next person.

And still, at the end of the television debate, the field hockey coach was unable to convince the conservative football players. They clearly totally missed what he was talking about. Even when the question was posed whether the players are subordinate to the coaches tactics and plan, of whether it might be better to form a team that best fits the players qualities, they chose to stick to the plan. To put it in the words of the agile manifesto: they valued following a plan over individuals and interactions.

If only the next Dutch football team would learn from agile. And if only traditional project managers would learn from their kids field hockey teams, the Dutch team might be the next world champion. And our projects might actually succeed.

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.