Hoe richt je een Agile ontwikkeltraject in binnen een organisatie die nog bezig is om de transformatie naar Agile te maken? Welke effecten heeft de wijze waarop de informatieanalyse is uitgevoerd op een daarop volgend softwareontwikkeltraject? In dit tweede artikel over de informatievoorziening bij het Centraal Orgaan opvang asielzoekers (COA) wordt er op deze en andere vragen ingegaan.
Beeld: Shutterstock
In de afgelopen jaren is bij het COA op een vernieuwende manier inzicht ontwikkeld op de benodigde informatie om vluchtelingen humaan en sober op te vangen en te begeleiden. Dit inzicht is verkregen door de informatiebehoefte proefondervindelijk te verkennen met behulp van een prototype. Dit prototype bleek in de praktijk zo goed te voldoen, dat alle opvanglocaties van het COA dit systeem als tijdelijke applicatie zijn gaan gebruiken, ondanks de gebreken die vastzitten aan het gebruik ervan. Meer informatie over hoe dit prototype tot stand gekomen is en welke do’s en dont’s daarbij zijn komen bovendrijven, staan in het eerste artikel over de informatievoorziening bij het COA.
Meten is weten
Ondanks het succes van de tijdelijke applicatie, waren er een aantal redenen om de applicatie te herbouwen.. Vanuit de medewerkers op de werkvloer kwamen er een tweetal belangrijke opmerkingen die niet direct op te lossen waren met het aanpassen van de tijdelijke applicatie. Ten eerste gaven zij aan het omslachtig te vinden dat informatie die in de tijdelijke applicatie werd opgeslagen ook opgeslagen moest worden in een ander, al bestaand systeem. Met andere woorden, zij vroegen om een koppeling tussen beide systemen. Daarnaast gaven de medewerkers aan dat het tijdelijke systeem niet erg modern was vormgegeven.
Een derde belangrijke opmerking kwam vanuit de ICT-afdeling. Omdat inmiddels de applicatie op alle locaties van het COA in gebruik was genomen, werd het steeds belangrijker dat het systeem goed kon worden beheerd. Daarbij werd door de ICT-afdeling aangegeven dat het beheer van de tijdelijke applicatie niet kon worden gegarandeerd. De tijdelijke applicatie was immers gerealiseerd met snelheid van realisatie in het achterhoofd en niet de snelheid c.q. eenvoud van beheer. Om deze garantie te kunnen geven, de koppeling te realiseren en het systeem een moderner – gebruiksvriendelijker – uiterlijk te geven, is ervoor gekozen om de tijdelijke applicatie te herbouwen.
Successen uit het verleden
Gelet op het succes van de gekozen aanpak bij het ophalen van de informatiebehoefte, waren er twee kritische succesfactoren die bij het herbouwtraject behouden moesten blijven. De eerste betrof de gebruikersparticipatie. De informatiebehoefte – en het prototype – waren tot stand gekomen door op locatie samen met de medewerkers aan de slag te gaan. De tweede succesfactor betrof de realisatiesnelheid. Bij eerste versies van het prototype was gebleken dat een dergelijke eerste versie niet perfect hoeft te zijn, mits gebreken snel verholpen worden en ontbrekende functionaliteit snel wordt opgevuld. De positieve effecten van deze twee succesfactoren, zoals goede aansluiting bij de gebruikerswensen en een hoge gebruikersacceptatie, zouden ook bij het herbouwtraject goed van pas komen.
Solide basis
Om de permanente applicatie te kunnen gaan bouwen is een gedetailleerde beschrijving opgesteld van de tijdelijke applicatie. Deze gedetailleerde beschrijving is aangevuld met wensen die niet in de tijdelijke applicatie konden worden gerealiseerd, zoals de koppeling met het bestaande systeem. Om het wensenpakket goed te kunnen realiseren dienden een drietal belangrijke keuzes gemaakt te worden, te weten:
1. De opzet van de architectuur
2. Het ontwikkelplatform
3. De (software)ontwikkelmethode
Voor het opstellen van de architectuur is gebruik gemaakt van TOGAF. Door de enterprise architect is in eerste instantie een event driven architectuur voorgesteld. Een belangrijk argument hierbij was de behoefte vanuit de Uitvoering om de bewoner meer centraal te zetten in de dagelijkse werkzaamheden. Hiervoor is het nodig om goed inzicht te hebben in de gebeurtenissen die voor een bewoner van belang zijn.
De veranderingen in de omgeving van het COA zijn in de afgelopen periode turbulent geweest. De verwachting is dat ook in de toekomst rekening gehouden zal moeten worden met snelle en onverwachte gebeurtenissen. Daarom is het van belang dat de systemen die de werkzaamheden van het COA ondersteunen snel hierop ontwikkeld en aangepast kunnen worden. Tegen deze achtergrond is de keuze gemaakt voor Mendix omdat met behulp van dit product in hoog tempo gewenste functionaliteit kan worden gerealiseerd (met een maximum van 4 uur per functiepunt).
Als softwareontwikkelmethode is gekozen voor Agile/Scrum. Een aantal uitgangspunten van Agile/Scrum sluiten naadloos aan bij de projectdoelstellingen, zoals regelmatig werkende software opleveren, nauwe samenwerking tussen verschillende ‘traditionele’ rollen (zoals analisten, ontwikkelaars, testers etc.) en veel reviewmomenten (demo’s) met stakeholders (zoals de medewerkers op de werkvloer).
Bevindingen
Het herbouwtraject startte onder gunstig gesternte. Dankzij de bijzondere wijze waarop de informatiebehoefte werd opgehaald, kon het project beschikken over een enthousiaste groep medewerkers op de werkvloer die mee wilden werken aan het project. Verder was een groot deel van de gevraagde requirements helder inzichtelijk: er was immers een tijdelijke applicatie als voorbeeld beschikbaar en de functionaliteiten daarvan waren bovendien uitgewerkt in een gedetailleerde beschrijving. Met betrekking tot dit laatste is gedurende het project wel gebleken dat elk voordeel ook zijn nadeel kan hebben. Hoewel de tijdelijke applicatie veel gemak opleverde, omdat bijvoorbeeld bepaalde gebruikerswensen al geheel uitgekristalliseerd waren, bleven sommige uitdagingen ook verborgen. Dit kon gebeuren doordat ze, vanwege specifieke eigenschappen van de tijdelijke applicatie, daarin geen rol speelden, terwijl het in de definitieve applicatie wel een probleem was.
Architectuur
Het werken met een event driven architectuur (EDA) bleek niet eenvoudig. TOGAF beschrijft de mogelijkheid over de aanwezigheid van een Enterprise Architect, die een zogenaamde enterprise architectuur (EA) neerlegt, waarin enkele kaders en uitgangspunten beschreven staan. TOGAF biedt een verschillende manieren om die Enterprise Architectuur te realiseren en te implementeren. Een belangrijke manier is dat de Enterprise Architect erop toeziet dat naar aanleiding van de Enterprise Architectuur een business architectuur (BA), een informatiearchitectuur (IA) en een technische architectuur (TA) opgesteld worden. Als blijkt dat kaders en uitgangspunten uit de EA niet te verenigen zijn met één van de andere architecturen, dan dient ofwel de EA aangepast te worden, ofwel een project gestart te worden dat veranderingen bewerkstelligt zodat de onderliggende architectuur alsnog verenigd kan worden met de EA.
De EA was bij de start van de werkzaamheden gericht op een event driven architectuur (EDA). Bij de uitvoering van de werkzaamheden is hier onvoldoende invulling aan gegeven omdat het belang van de opgestelde EDA in eerste instantie voorrang heeft gekregen boven het belang van de behoefte van de gebruikers en de (on)mogelijkheden van Mendix. Dit is opgelost door (alsnog)de business architectuur op te stellen en de informatiearchitectuur en technische architectuur daarop af te stemmen. Hierdoor kon de applicatie alsnog gerealiseerd worden op een manier die herkenbaar was voor gebruikers. Bovendien was de applicatie technisch veel makkelijker te realiseren. Helaas is daarbij wel afscheid genomen van de opgestelde EDA en is de koppeling tussen de definitieve applicatie en het bestaande systeem gerealiseerd op een data driven-manier. Dat heeft een hoop extra complexiteit opgeleverd.
Ontwikkelplatform
Door na het herbouwtraject de grootte van de definitieve applicatie te bepalen middels een functiepuntanalyse en dit vervolgens af te zetten tegen de geïnvesteerde manuren, is vastgesteld dat het oorspronkelijke doel voor de ontwikkelsnelheid van 4 uur per functiepunt is behaald. Op dat vlak is de keuze voor Mendix als ontwikkelplatform dus de juiste geweest. Wel verdient het vermelding dat het herbouwtraject langer geduurd heeft dan oorspronkelijk gepland, voornamelijk doordat de grootte van de tijdelijke applicatie in eerste instantie zwaar is onderschat. Een ander punt van aandacht is dat er nu gekozen is om bij het herbouwtraject de tijdelijke applicatie in zijn geheel te herbouwen middels Mendix. Mogelijk zou er tijdswinst te behalen zijn geweest als per functionaliteit bekeken was of Mendix het beste platform was om die functionaliteit in te ontwikkelen – en zo niet, voor die functionaliteit een ander ontwikkelplatform (of bestaande systemen) te gebruiken.
Agile in een waterval-organistie
Zoals eerder vermeld is gekozen voor Agile/Scrum als ontwikkelmethode. Hier is invulling aan gegeven door een team neer te zetten bestaande uit een aantal ontwikkelaars/testers, een projectarchitect, een Scrum Master, een informatieanalist, een gedelegeerd product owner en een product owner. De product owner-rol werd ingevuld door de locatiemanager van de locatie waar ook de ontwikkeling heeft plaatsgevonden. Ze was hiervoor echter niet fulltime beschikbaar. De samenwerking met een gedelegeerd product owner, die tevens Subject Matter Expert was, nagenoeg fulltime bij het ontwikkelteam zat en de dagelijkse ‘kleine’ beslissingen nam, werkte echter uitstekend en was één van de kritische succesfactoren van het project.
Tijdens het ontwikkeltraject is intensief samengewerkt met de medewerkers op de werkvloer van het COA, de eindgebruikers van de applicatie. Zo bevond het ontwikkelteam zich op locatie en werden er wekelijks demo’s gegeven van de ontwikkelde functionaliteiten en werd de feedback verwerkt. Mochten er vragen zijn die niet direct door de (gedelegeerd) product owner beantwoord konden worden, dan konden de experts die bij het team op de locatie aanwezig waren vaak snel het verlossende antwoord geven. Deze intensieve samenwerking met de uiteindelijke gebruikers van de definitieve applicatie heeft geleid tot een systeem dat weinig weerstand opriep tijdens het implementatietraject, omdat het goed aansloot op de wensen en belevingswereld van de gebruikers.
Hoewel in het project zelf gebruik gemaakt werd van Agile/Scrum, gold dat op nog lang niet alle plekken in de rest van de organisatie volgens deze methode werd gewerkt. Dat heeft vertraging opgeleverd, omdat de rest van de (ICT)organisatie nog niet volledig kon meegaan in het tempo van het Scrumteam. Als voorbeeld kan gewezen worden op de aanpassingen die gedaan moesten worden aan het bestaande systeem van het COA. Die noodzakelijke aanpassingen zaten vol in een strakke planning, waarbij releaseplanningen en resourceplanningen al maanden van tevoren waren vastgelegd. Bovendien waren er te weinig resources beschikbaar gesteld om de werkzaamheden uit te kunnen voeren, met als gevolg dat pas veel te laat aan de ketenintegratie begonnen kon worden.
Naarmate het project vorderde, werd er steeds nadrukkelijker gestuurd op scope. Deze sturing vond plaats door de stuurgroep en/of de projectleider van het project. Normaal gesproken ligt in een Agile ontwikkeltraject de macht om te sturen (enkel) bij de product owner. Dat dit nu niet het geval was, is een direct gevolg van het feit dat de organisatie nog niet gewend was om geheel volgens Agile te werken.
De oorspronkelijke opdracht van het project was om de tijdelijke applicatie één op één over te bouwen; precies dat en niet meer dan dat. Dat er op deze scope gestuurd werd was problematisch om een tweetal redenen:
• De tijdelijke applicatie was een informatieanalyse-tool, waarin ook functionaliteiten gebouwd zijn die, na testen, toch niet zo nuttig bleken, of alleen bruikbaar waren op een beperkt aantal locaties. Met andere woorden: de business value van de functionaliteiten in het prototype verschilde nogal per functionaliteit.
• In Scrum hoort, door de product owner, gestuurd te worden op business value. De nadrukkelijke sturing op scope conflicteerde hier naarmate het project vorderde steeds meer mee. Er moesten functionaliteiten gerealiseerd worden die niet zoveel waard waren, terwijl andere (inmiddels opgehaalde) gebruikerswensen die wel veel waard waren, niet gerealiseerd mochten worden omdat die niet in het prototype zaten.
Het uiteindelijke gevolg van de sturing op scope is dat de business value van de definitieve applicatie lager was dan deze had kunnen zijn als er wél op business value gestuurd had kunnen worden.
Als gevolg van bovenstaande is de aanwezigheid van een stevige projectleider, met slagkracht naar ‘buiten’ toe maar zonder een inhoudelijk sturende rol, een randvoorwaarde gebleken voor het succes van het project. Op deze wijze is de projectleider ervoor verantwoordelijk dat de voor het Scrumteam noodzakelijke randvoorwaarden die door de niet-Agile-organisatie gerealiseerd moeten worden, gerealiseerd worden. De inhoudelijke sturing (op business value) wordt dan bij de product owner gelegd.
Tenslotte kan worden opgemerkt dat Agile/Scrum een methode is waarop in de duivelsdriehoek tijd en geld worden vastgezet en niet kwaliteit/scope. Dit heeft tot wat verwarring geleid bij de gebruikers en andere volgers van het project. Als gevolg van een aantal hierboven beschreven tegenvallers is het een aantal keer niet gelukt om alle gewenste functionaliteiten te realiseren in de beschikbaar gestelde tijd. Dit betekende dat het project een aantal keer moest worden bijgesteld, waarbij de indruk is ontstaan dat er gestuurd is op tijd en geld en niet op resultaat. Dat was natuurlijk niet het geval: er is door de product owner gestuurd op de volgorde waarin de functionaliteiten gerealiseerd zijn. Daarbij is vanzelfsprekend geprobeerd om de functionaliteiten met de hoogste business value als eerste te realiseren. Dit verschil was ‘vanuit gebruikersperspectief’ echter lastig te zien.
Conclusies
Bij het COA is op een bijzondere wijze een analyse uitgevoerd naar de informatiebehoefte van de medewerkers om het dagelijks werk uit te voeren. Daar is een tijdelijke applicatie uit voortgekomen. Het herbouwtraject om die tijdelijke applicatie te vervangen door een definitieve applicatie, heeft een aantal waardevolle lessen opgeleverd. De bijzondere wijze waarop de informatieanalyse is uitgevoerd, heeft geleid tot het volgende:
• Het project heeft een vliegende start gekregen dankzij het draagvlak die de werkwijze opgeleverd heeft in de organisatie.
• Dat er een tijdelijke applicatie als voorbeeld was, heeft enerzijds veel gemak opgeleverd, maar anderzijds ook specifieke uitdagingen verborgen, zoals de complexiteit van het leggen van de koppelingen.
Bij het uitvoeren van het project middels Agile viel het volgende op:
• De combinatie van een product owner uit de business en een (fulltime bij het team aanwezige) gedelegeerde product owner met veel subject matter expertise, is bijzonder effectief gebleken.
• Hetzelfde geldt voor de intensieve samenwerking met de medewerkers die de definitieve applicatie uiteindelijk in gebruik hebben genomen.
• Er zou meer business value opgeleverd zijn als er tijdens het project zou zijn gestuurd op business value en niet op scope.
• Er is een krachtige projectleider nodig om te zorgen dat een Agile-team succesvol kan zijn in een niet-Agile omgeving.
• Deze projectleider moet zorgen voor de randvoorwaarden die het project nodig heeft om te slagen, maar dient de inhoudelijke sturing (op business value) bij de product owner te laten liggen.
Overige bevindingen van het project zijn:
• Alleen sturen op de EA en het overslaan van het opstellen van een business architectuur is niet juist gebleken.
• Het ontwikkelplatform Mendix heeft de beloofde ontwikkelsnelheid behaald.
• Nog meer snelheidswinst zou waarschijnlijk behaald kunnen worden door per functionaliteit te kijken met behulp van welk platform dit het beste gerealiseerd kan worden.
Het herbouwproject om die tijdelijke applicatie te vervangen, is een project met veel hindernissen geworden, maar wel een project dat uiteindelijk succesvol is geweest. Er is een definitieve applicatie uit voortgekomen die eenvoudig in gebruik te nemen is en voldoet aan de wensen van de gebruikers. In een volgend artikel zal het beheer en de beheersbaarheid van de definitieve applicatie onder de loep genomen worden.
Lars Wortel is consultant bij Capgemini. Johan van Wamelen is beleidsadviseur bj het COA en richt zich in zijn werkzaamheden op het slaan van een brug tussen gebruikers en aanbieders van ICT voorzieningen. Zijn interesse ligt bij vraagstukken op het gebied van de organisatie van de informatievoorziening in grote publieke organisaties.
