Inleiding

Bij maatwerksysteemontwikkeling gaat het om het managen van het spanningsveld tussen de drie pijlers functionaliteit (scope), capaciteit (geld) en tijd (planning) met in het midden de kwaliteit van het op te leveren systeem (zie figuur 1). Bij de traditionele watervalaanpak wordt de functionaliteit vooraf nauwkeurig bepaald en vastgelegd en blijkt gedurende het project wat de uiteindelijke kosten en doorlooptijd zijn. De klant krijgt wat hij wil, maar of het systeem tijdig en tegen aanvaardbare kosten in productie wordt genomen blijft de vraag. Zeker omdat uit onderzoek van de Standish Group in 2002 ([John02]) al is gebleken dat 45 procent van de functionaliteit bij traditionele (waterval)systeemontwikkeling uiteindelijk zelden of nooit wordt gebruikt.

Figuur 1. Maatwerksysteemontwikkeling volgens de waterval- en de agile aanpak.

Bij de agile aanpak ([Pich10]) wordt gewerkt met een fixed price/fixed date, waarbij geld en doorlooptijd worden bevroren en juist de op te leveren functionaliteit nog kan variëren. De klant weet dus zeker wanneer en tegen welke kosten het systeem in productie zal gaan, maar nog niet welke functionaliteit het systeem zal bevatten.

Het belangrijkste uitgangspunt van de klant is dat er een kwalitatief goed systeem (lees: een systeem dat voldoet aan zijn verwachtingen) wordt opgeleverd. In de praktijk blijkt echter dat als de bevroren onderdelen van de driehoek niet goed worden gemanaged, dit ten koste gaat van de kwaliteit van het systeem. Eerder moeten opleveren dan gepland, teamcapaciteit die niet beschikbaar is of de scope uitbreiden zijn zaken die de kans vergroten dat het opgeleverde systeem uiteindelijk niet voldoet aan de verwachtingen van de klant. Waardoor er gedurende de nazorg-/garantieperiode weer veel werk moet worden verzet om het systeem af te maken.

Hoe kan dit in de praktijk worden voorkomen?

• Zorg dat niet alleen de IT-dienstverlener, maar ook de klant echt agile gaat werken en bij het managen van de scope niet blijft hangen in een waterval-mindset.
• Organiseer de agile teams zodanig dat voorspelbaarheid, responsiviteit, productiviteit en kwaliteit optimaal zijn.
• Zet productivity platforms in die de agile aanpak ondersteunen en alle fasen van ontwerp tot en met onderhoud optimaliseren.
• Maak met een Total Cost of Ownership (TCO)-berekening inzichtelijk dat een agile aanpak in combinatie met een productivity platform de beste prijs-prestatieverhouding oplevert.

Juiste agile mindset bij IT-dienstverlener en klant

Een belangrijk aspect bij agile ontwikkelingstrajecten is het voortschrijdend inzicht dat gedurende het proces ontstaat bij zowel opdrachtgever als IT-dienstverlener. Hoewel dit een groot deel van de kracht is van de methodiek, schuilt er tegelijkertijd een aanzienlijk gevaar in. Want als de IT-dienstverlener niet genoeg ‘nee’ antwoordt op alle eisen en wensen die de opdrachtgever en gebruikers tijdens het ontwikkeltraject inbrengen, kan dit uitmonden in systemen die bij nader inzien kwalitatief verre van optimaal blijken. Bij fixed-time/fixed-budget-projecten ([Edwa12]) kan dit resulteren in forse budget- en soms zelfs tijdsoverschrijdingen, die voor rekening van de IT-dienstverlener komen.

Bij agile projecten worden de eisen en wensen van de opdrachtgever en de gebruikers niet van tevoren tot in detail vastgelegd. In plaats daarvan worden een productvisie, product roadmap en product backlog opgesteld. De productvisie ([Suth12]) beschrijft waarom het project wordt gestart en wat de gewenste eindsituatie is door een beeld van de toekomst te schetsen. Hiermee geeft de producteigenaar richting aan het ontwikkelteam en brengt hij alle stakeholders op één lijn. In de product roadmap staat beschreven hoe het product de komende maanden en jaren zal gaan ‘groeien’ in de vorm van releases. In de product backlog ten slotte staan de requirements die moeten worden ontwikkeld en voorzien van een prioriteit (zie figuur 2). Deze requirements worden op hoofdlijnen beschreven om gedurende het ontwikkelproces verder te worden ingevuld. Doordat in korte iteraties telkens werkende software wordt opgeleverd, krijgen de opdrachtgever en de gebruikers steeds meer en beter inzicht in het hoe en wat van het systeem. Op basis hiervan wordt het systeem steeds verder uitgebreid en verbeterd.

Figuur 2. De product backlog omvat de requirements en hun prioriteit.

De keerzijde van het feit dat de requirements vooraf in de product backlog niet tot in detail zijn vastgelegd, is dat de functionaliteit hierdoor te weinig is afgebakend, waardoor het risico van ‘scope creep’ op de loer ligt. In de praktijk van agile projecten komt het maar al te vaak voor dat opdrachtgevers en gebruikers voortdurend nieuwe wensen inbrengen of veelvuldig van mening veranderen over de functionaliteit van het systeem of over hoe het systeem eruit moet komen te zien. Ook al weet de organisatie goed wat ze nodig heeft, toch kan de IT-dienstverlener laten zien dat er ook een andere (mogelijk zelfs betere) oplossing is. De capaciteit om een systeem te ontwikkelen is qua beschikbaarheid van arbeidskrachten en geld allesbehalve onbeperkt. Daarom geldt: ‘Beter is slechter dan goed genoeg’.

Desondanks komt het vaker wel dan niet voor dat de IT-dienstverlener volledig meegaat met de extra en voortdurend veranderende eisen en zonder slag of stoot uitvoert wat de opdrachtgever wil. Hiervoor zijn verschillende redenen aan te wijzen ([Shea11]). De eerste is dat het doorvoeren van veranderingen en het realiseren van nieuwe functionaliteit bij de agile aanpak gemakkelijk en snel gaat. Bovendien ligt het in de aard van de IT-dienstverlener om het de opdrachtgever zo veel mogelijk naar de zin te maken. Daar komt nog bij dat een projectleider dikwijls ook gewoon geen nee durft te zeggen, bang als hij is voor wat de opdrachtgever hiervan zal vinden en voor wat de mogelijke contractuele consequenties hiervan zullen zijn.

Nee verkopen hoort echter bij de mindset van agile werken en is beter voor alle partijen. Want simpelweg alles uitvoeren wat de opdrachtgever en de gebruikers gedurende het project aan wensen en eisen inbrengen, leidt er onherroepelijk toe dat de bevroren pijlers capaciteit en tijd omver worden getrokken of – nog erger – dat de kwaliteit van het opgeleverde systeem onvoldoende is. Ook al is agile een IT-begrip, de nieuwe agile spelregels moeten bij zowel de IT-dienstverlener als de business bekend zijn én worden toegepast in de praktijk. Dit betekent niet alleen maar nee zeggen, maar juist duidelijk communiceren welke onderdelen van de product backlog kunnen worden gerealiseerd binnen de afgesproken kaders van capaciteit, doorlooptijd en verwachte productiviteit. En als er toch iets bij moet komen, dan mag of moet de klant zelf kiezen tegen welke zaken uit de product backlog deze worden uitgeruild.

Agile teams optimaal organiseren voor productiviteit

Kan door het juist toepassen van een agile aanpak de productiviteit worden verhoogd? Uit onderzoek van Rally Software ([Macc13]) blijkt dat met een agile aanpak niet alleen de productiviteit, maar ook de kwaliteit, voorspelbaarheid en doorlooptijd kunnen worden verbeterd (zie figuur 3). Daarbij spelen de teamindeling, wijze van inschatten, teamomvang en hoeveelheid onderhanden werk een cruciale rol. Hierna wordt uiteengezet hoe deze verbeteringen kunnen worden gerealiseerd.

Figuur 3. Met de agile aanpak kunnen productiviteit, kwaliteit, voorspelbaarheid en doorlooptijd worden verbeterd ([Macc13]).

Hogere productiviteit door mensen toe te wijzen aan één vast team:

• Mensen die fulltime in één team werken zijn productiever en leveren kwalitatief beter werk af dat ook nog eens beter voorspelbaar is. Stabiele teams zijn gemiddeld 60 procent productiever, 40 procent beter voorspelbaar en 60 procent responsiever.
• Uit onderzoek ([Macc13]) blijkt echter ook dat de teamstabiliteit bij agile werken gemiddeld 75 procent is. In een team van bijvoorbeeld acht mensen worden elke drie maanden twee teamleden gewisseld. Het inwerken van nieuwe teamleden heeft wel direct een negatief effect op productiviteit, kwaliteit en voorspelbaarheid.

Betere kwaliteit door gebruik te maken van Full of Lightweight Scrum:

• Bij de agile aanpak is voorspelbaarheid ([Cohn12]) van het ontwikkelproces van belang om een sprintplanning te kunnen opstellen op basis van de product backlog. Uit onderzoek blijkt dat er teams zijn, veelal afkomstig uit een ‘pre-agile’-tijdperk, die helemaal geen schattingen maken (3 procent) of die alleen een urenschatting maken voor de uit te voeren taken (8 procent) (‘hourly-oriented’). Andere teams werken met story points (10 procent) (zogenaamde Lightweight Scrum). Maar het grootste deel van de teams werkt met story points en een breakdown in uren van de uit te voeren taken (79 procent) (zogenaamde Full Scrum).
• Teams die geen inschattingen maken blijken 3,5 keer meer fouten op te leveren in hun software in vergelijking met teams die Full Scrum werken. Als gekeken wordt naar het totaal van productiviteit, kwaliteit, responsiviteit en voorspelbaarheid, dan levert Lightweight Scrum de hoogste score op. Dus werken met story points alleen al zorgt voor een enorme positieve bijdrage.

Teams die bestaan uit zeven (plus of minus twee) teamleden presteren het stabielst:

• In de agile aanpak bestaat een ideaal team uit vijf tot negen personen. Uit onderzoek ([Macc13]) naar teams met een kleinere omvang (één tot twee of drie tot vier personen) blijkt dat de productiviteit wel hoger is, maar dat dit ten koste gaat van de kwaliteit en vooral van de voorspelbaarheid van het team.
• Verder is er ook een verband tussen de omvang van de organisatie en de omvang van de teams. Kleinere (IT-)organisaties hebben de neiging de teams ook klein (maximaal vier personen) te houden en niet Full Scrum te werken. Grotere organisaties werken veelal wel met Full Scrum en in grotere teams.

Halveer de doorlooptijd door te werken met kleinere werkpakketten:

• In de agile aanpak wordt een Scrum-board gebruikt om het onderhanden werk (het Work in Process oftewel WiP) van het team weer te geven. Een vuistregel daarbij is dat het beter is niet aan te veel items tegelijkertijd te werken.
• Uit hetzelfde onderzoek ([Macc13]) blijkt ook dat teamleden die aan slechts één of twee items tegelijkertijd werken, door een grotere focus in staat zijn de doorlooptijd (de Time in Process oftewel TiP) te halveren. Een bijkomend voordeel van weinig onderhanden werk is ook dat de kwaliteit tot wel vier keer beter kan worden. Het nadeel is wel dat als er een blokkade is voor een bepaald item, de productiviteit direct omlaaggaat omdat er geen of weinig andere items zijn die in de tussentijd kunnen worden opgepakt.

Voordelen van high-productivity platforms

Bij maatwerksysteemontwikkeling kunnen de kosten sterk verschillen bij respectievelijk traditionele systeemontwikkeling, ontwikkeling met outsourcing en softwareontwikkeling met behulp van productivity platforms die software genereren. Bij traditionele ontwikkeling is de verdeling van kosten als volgt: voorbereiding (8 procent), uitwerking van requirements (23 procent), constructie (50 procent) en test & implementatie (20 procent). In figuur 4 wordt ook de doorlooptijd weergegeven. Bij outsourcing is het mogelijk de constructiekosten te verlagen door lagere uurtarieven te hanteren, maar de kosten van het uitwerken van requirements zijn wel hoger en de doorlooptijd blijft gelijk. Door de inzet van productivity platforms voor softwaregeneratie worden de constructiekosten pas echt substantieel verminderd zonder dat hiervoor uitbesteding noodzakelijk is en kan de doorlooptijd met circa 30 procent worden verkort.

Softwaregeneratie is mogelijk met een productivity platform, zoals CA Gen, OutSystems en Mendix. Daarbij worden requirements uitgewerkt in de vorm van modellen en wordt de code niet alleen automatisch maar ook honderd procent foutvrij geconstrueerd. Hierbij blijft de focus van een agile team gericht op specificaties en communicatie met de klant en wordt geabstraheerd van de onderliggende techniek.

Figuur 4. Kosten en doorlooptijd bij verschillende methoden van maatwerksysteemontwikkeling.

Productivity platforms maken enerzijds agile werken mogelijk en kunnen anderzijds het succes van agile werken versterken:

• De productiviteit is hoger door te modelleren in plaats van te coderen, te werken onder architectuur en bestaande componenten te hergebruiken.
• Responsiviteit is mogelijk doordat snel maar wel volledig gecontroleerd met versiebeheer en automatische validatie functionaliteit kan worden ontwikkeld en gewijzigd.
• De kwaliteit is hoger door honderd procent foutvrije code en het automatisch voldoen aan niet-functionele eisen zoals performance, schaalbaarheid, continuïteit en monitoring.
• Hierdoor wordt systeemontwikkeling en -onderhoud een repeteerbaar proces, onafhankelijk van individuen, waardoor het ook beter voorspelbaar is qua productiviteit.

Uit onderzoek ([Door13]) blijkt dat door de inzet van productivity platforms in de gehele ontwikkelcyclus een productiviteitswinst te behalen valt van 30 tot wel 75 procent (zie figuur 5).

Figuur 5. Productiviteitswinst dankzij productivity platforms ([Door13]).

Zoals eerder aangegeven neemt het uitwerken van requirements in de Design-fase bij modelgedreven ontwikkeling meer tijd (25 in plaats van 20 procent) en meer kosten (43 in plaats van 20 procent) in beslag dan bij traditionele ontwikkeling en zijn er in die zin geen productiviteitsbaten.

Bij de fasen Coderen en Testen worden wel productiviteitsvoordelen van 30 tot 50 procent zichtbaar (zie ook figuur 5):

• Immediate code validation
  
  Een productivity platform werkt met een centrale repository waarin alle modellen worden opgeslagen. Alleen modellen die syntactisch juist zijn kunnen worden opgeslagen, waarbij automatisch de referenties naar andere systemen worden gecontroleerd en automatisch versiebeheer plaatsvindt. Mochten meerdere teamleden tegelijkertijd in hetzelfde model werken, dan vindt er een visuele modelvergelijking en vervolgens een modelsamenvoeging plaats. Allemaal zaken waardoor de productiviteit hoger wordt.
• Out-of-the-box components
  
  Een productivity platform ondersteunt het werken met standaard- of herbruikbare componenten voor bijvoorbeeld styling/lay-out, gebruikersbeheer, menusturing, procesmonitoring, grafieken voor managementrapportages en logging van transacties. Deze functionaliteit hoeft dus niet opnieuw te worden ontwikkeld en dat verhoogt de productiviteit. Natuurlijk kost het ontwikkelen van een herbruikbare component meer. Hier staat wel tegenover dat hergebruik van een component direct een besparing kan opleveren.
• Unified management of application layers
  
  In productivity platforms worden presentatie (schermen/interface), businesslogica en data van elkaar gescheiden. Daarnaast kan er ook nog een aparte proceslaag (workflowlaag) zijn. Deze ordening vergroot het overzicht van het model met specificaties, niet alleen bij ontwikkeling, maar juist ook bij onderhoud. Daarnaast wordt er gewerkt met een gelaagde architectuur van componenten (modellen), waardoor teamleden ook gemakkelijker parallel kunnen werken.
• Shorter test, fix and retest cycles
  
  Productivity platforms hebben functionaliteit om testbevindingen inclusief screenshots te melden en ze te analyseren en via een directe link het betreffende model te openen en de bevinding op te lossen. Ook is het mogelijk testbevindingen vanuit het productivity platform door te sturen naar tools zoals Rally Software. Het melden, oplossen en hertesten van bevindingen kan zo een stuk productiever plaatsvinden.

Bij het uitrollen in de ontwikkelstraat en doorzetten naar de productieomgeving kan een productiviteitswinst van wel 75 procent worden geboekt (zie ook figuur 5):

• Integrated version management
  
  Een productivity platform werkt dus met een centrale repository waarin alle modellen worden opgeslagen. Van alle modellen worden de versies bijgehouden en hierdoor is het mogelijk direct terug te gaan naar een voorgaande versie van een model. Tevens wordt gecontroleerd of de versies van modellen die worden gerefereerd nog actueel zijn. Voor het doorzetten van een systeem kan tevens automatisch een package of solution worden aangemaakt die alle componenten bevat van het nieuwe systeem.
• 1-click publishing
  
  Productivity platforms hebben vaak een ‘build tool’- of ‘1-click-publish’-knop om het model te uploaden naar de centrale repository, programma- en databasecode te genereren en het model te distribueren over front-end- of webservers in de doelomgeving. Binnen enkele seconden kan een ontwikkelaar de nieuwe versie van het systeem testen. Omdat dit uitrollen (de deployment) volautomatisch en zeer snel gaat, is de laatste versie van het systeem zeer actueel.
• Integrated configuration management
  
  Standaardontwikkelstraten voor productivity tools bestaan uit minimaal vier omgevingen (ontwikkel-, test-, acceptatie- en productieomgeving) in de cloud, op locatie of een combinatie daarvan. Elke omgeving bestaat uit een eigen configuratie en kan verschillen qua operatingsysteem, databasemanagementsysteem en middleware. Voor het doorzetten (de staging) van een nieuwe versie van het systeem hebben productivity platforms specifieke functionaliteit of er is een koppeling met een aparte versiebeheertool zoals GuardIEn. Alles is wederom gericht op het optimaliseren van de productiviteit van de ontwikkelaar tot en met de platformbeheerder.

De productiviteitsverbeteringen tijdens de ontwikkeling van een systeem zijn mooi, maar uit onderzoek van Gartner ([Kyte10]) blijkt dat de kosten om een systeem te ontwikkelen tot het ‘go live’-moment gemiddeld slechts 8 procent zijn van de totale eigendomskosten. Met andere woorden, 92 procent van alle kosten zit in het draaiend houden en onderhouden van het systeem in de jaren erna. Met een productivity platform kan 50 tot 75 procent productiviteitswinst worden behaald gedurende de onderhoudsfase. Door te werken met een gelaagde architectuur en specificaties in modelvorm met een centrale repository is de kennis beter overdraagbaar en de leercurve voor het uitvoeren van onderhoud minder steil. Juist daarom ondersteunen high-productivity platforms zo goed een agile aanpak.

TCO-berekening van productivity platforms

Op zakelijk gebied neemt volgens Gartner ([Kyte10]) de behoefte aan systeemfunctionaliteit toe met wel 10 tot 20 procent per jaar. Uit diverse onderzoeken blijkt dat na een jarenlange trend van daling de IT-budgetten sinds 2013 voor het eerst weer toenemen. Toch is deze toename niet groot genoeg om in de vraag naar nieuwe systemen te kunnen voorzien. Dit betekent dat er keuzes gemaakt zullen moeten worden wat wel en niet wordt ontwikkeld, wat extra kansen biedt voor productivity platforms.

Om een afgewogen keuze te kunnen maken voor een productivity platform, moeten de opbrengsten tegen de kosten worden afgezet. Bij een optimale investering zijn de opbrengsten zo hoog mogelijk en de kosten zo laag mogelijk. Bij opbrengsten gaat het om rendabele functionaliteiten die bijdragen aan de continuïteit en kwaliteit van de onderneming op de langere termijn. Als we het hebben over de kosten, gaat het om de Total Cost of Ownership (TCO), dus initiële ontwikkelkosten plus gebruiks- en beheerkosten over de gehele levenscyclus van een systeem. Dit klinkt logisch, maar toch wordt er in de praktijk te vaak gedacht ‘Het zal mijn tijd wel duren’ en wordt er alleen gekeken naar de korte termijn, en daarmee naar de ontwikkelkosten. De gebruiks- en beheerkosten worden doorgaans wat minder belangrijk gevonden.

Vanuit een financieel perspectief zijn op basis van een TCO-berekening de voordelen van een productivity platform in combinatie met een agile aanpak duidelijk te maken. Voor de vergelijking van een productivity platform met een agile aanpak met een fixed-price/fixed-date-aanpak met een standaard- (3GL-) ontwikkelomgeving stellen we een applicatie-TCO op die bestaat uit vier onderdelen:

1. kosten applicatieontwikkeling (development);
2. kosten applicatieonderhoud (maintenance);
3. kosten exploitatie en beheer (operations & support);
4. kosten ontwikkelstraat (infrastructure).

Figuur 6. TCO bij inzet van een productivity platform en van een standaardontwikkelomgeving.

In het in figuur 6 weergegeven voorbeeld uit de praktijk wordt eerst de applicatie ontwikkeld (de zogenaamde setup) en daarna drie jaar gebruikt en onderhouden. Daarbij blijkt dat het inzetten van een productivity platform tot totaal 58 procent lagere kosten leidt in vergelijking tot een standaardontwikkelomgeving.

Uit een nadere analyse van de TCO van een productivity platform blijkt dat de ontwikkelkosten gehalveerd zijn, het onderhoud 4,6 keer goedkoper is en de gebruiks- en beheerskosten slechts de helft bedragen gedurende de gehele levensduur van het systeem (zie figuur 7). Uiteraard zijn de kostenbesparingen wel afhankelijk van de geboden functionaliteit van het desbetreffende productivity platform.

Figuur 7. Totale kosten van een applicatie gedurende de levensduur.

De onderhouds- en beheerskosten (de ‘operation costs’) kunnen aanzienlijk worden teruggebracht als tijdens de ontwikkeling niet alleen naar de functionele eisen en wensen wordt gekeken, maar ook rekening wordt gehouden met niet-functionele eisen die voorschrijven hoe het systeem zich tijdens de exploitatie en de verdere evolutie gedurende de levensduur van het systeem dient te gedragen. Voorbeelden van niet-functionele eisen zijn eisen die betrekking hebben op beveiliging, audit, performance, beschikbaarheid, back-up en herstelbaarheid, portabiliteit, bruikbaarheid, onderhoudbaarheid, testbaarheid, uitbreidbaarheid, schaalbaarheid en documentatie. Het grote voordeel van het gebruik van productivity platforms is dat al deze niet-functionele eisen worden afgevangen door het platform en niet apart ontwikkeld hoeven te worden voor elk systeem. Dit is dus wederom een productiviteitswinst.

Een risico dat wel moet worden onderkend is de mogelijke afhankelijkheid van een productivity-platformleverancier. Bij de keuze van een platform dient daarom altijd op voorhand een mogelijk exitscenario bekeken te worden. Waar kan het platform draaien, in de cloud of binnen de eigen IT-infrastructuur? Waar staan de modellen in het platform op basis waarvan de systemen worden gegenereerd of geïnterpreteerd? En blijven deze modellen ook toegankelijk als het platform niet meer wordt gebruikt? Is het mogelijk de gegenereerde programmacode uit het platform te halen om die verder te gaan onderhouden in bijvoorbeeld Visual Studio of Eclipse? En ten slotte, hoe toegankelijk is de kennis van en ervaring met het productivity platform bij de leverancier, de implementatiepartners en op de arbeidsmarkt? Er ontstaat dus wel degelijk een afhankelijkheid van de platformleverancier, maar dit risico is beheersbaar met de juiste maatregelen.

Conclusies en aanbevelingen

Het inzetten van productivity platforms voor het ontwikkelen van maatwerksystemen op een agile wijze levert niet alleen substantiële productiviteitswinst op tijdens de ontwikkeling, maar ook een grote kostenbesparing gedurende de gehele levenscyclus van een systeem.

De basis van succesvol agile werken ligt in het creëren van eenzelfde mindset bij de IT-dienstverlener en de klant; het is beter de hoeveelheid capaciteit en doorlooptijd voor een ontwikkelproject te bevriezen en de functionaliteit (scope) flexibel te houden, afgestemd op de productvisie en de product roadmap. Maar dit lijkt gemakkelijker dan het in werkelijkheid is. Zodra een klant voor de keuze wordt gesteld om een item uit de product backlog uit te ruilen, omdat er bijvoorbeeld door voortschrijdend inzicht een item bij gekomen is, vallen veel opdrachtgevers terug op een traditionele (waterval)reactie dat er ‘gewoon’ meer bij moet qua scope maar dan wel voor dezelfde capaciteit en tijd.

Als de scope goed wordt gemanaged, blijkt het slim organiseren van agile teams essentieel te zijn voor een goede productiviteit, voorspelbaarheid, responsiviteit en kwaliteit tijdens het ontwikkelen van een systeem in korte sprints. Teamleden die volledig worden ingezet op één project blijken tweemaal zo productief te zijn. Voor het schatten van het ontwikkelwerk zijn minimaal story points en idealiter taakuren van grote waarde, want anders loopt het aantal mogelijke defects snel op. Kleine teams van drie tot vier personen kan, maar grotere teams van vijf tot negen personen blijken doorgaans toch meer in balans. Het loont om per teamlid slechts één à twee items als onderhanden werk te hebben om de doorlooptijd te kunnen halveren en door de sterke focus zelfs de kwaliteit van het systeem te kunnen verviervoudigen.

De volgende stap is de agile teams gebruik te laten maken van productivity platforms zoals CA Gen, OutSystems en Mendix, waarmee specificaties worden gemodelleerd en software wordt gegenereerd. De productiviteit is nog verder te verhogen door te werken onder architectuur en bestaande componenten te hergebruiken. Wijzigingen zijn snel en gecontroleerd door te voeren. De gegenereerde code is honderd procent foutvrij en het systeem voldoet automatisch aan niet-functionele eisen zoals performance, schaalbaarheid, continuïteit en monitoring doordat het platform dit regelt. De productiviteitswinst tijdens het ontwikkelen tot en met de uitrol in productie is 30 tot 75 procent. En gedurende de gehele levenscyclus van het systeem is de productiviteitswinst 50 tot 70 procent. In het algemeen wordt het nadeel van een leverancierslock-in die ontstaat bij de keuze voor een dergelijke omgeving, als beheersbaar ervaren.

Ten slotte kan ook vanuit een financieel perspectief op basis van een TCO-berekening duidelijk worden gemaakt dat de inzet van productivity tools voor agile ontwikkeling de voorkeur verdient boven een traditionele aanpak en inzet van 3GL-ontwikkeltools.