Agile werken is op de top van zijn populariteit. Daarom kunnen we ons nu gaan afvragen wat erna komt. Krijgt het blijvend een eigen plekje in de toekomstige werkwijze? Of ondergaat Agile hetzelfde lot als zoveel projectmanagementmethoden die een tijd de oplossing voor alles leken, maar ingehaald zijn door nieuwe? Guido Bayens en Jeroen Cloo van Novius bogen zich over deze vragen.

Agile werken is voortgekomen uit ontwikkelingen als het Toyota Production System (TPS), Lean en Scrum in de jaren tachtig en negentig van de vorige eeuw. De Agile-ontwikkeling is gestart in 2001. Een groep softwareontwikkelaars waren het over veel zaken niet eens, maar zij bereikten consensus over vier belangrijke waarden. Deze vormden de basis van een brede stroming om het ontwikkelen van software voortaan anders aan te pakken. Daarover later meer.

Verrijking

Scrum, een methode die al in 1986 ontwikkeld was, werd een van de belangrijkste technieken binnen de Agile-aanpak. Hierdoor werden de waarden van Agile verrijkt met een methode die gekenmerkt werd door bepaalde rollen, ceremonies en producten. Weer later werden hier praktische middelen of technieken aan toegevoegd, zoals het Scrumbord, pokeren, de ‘retrospective’, et cetera.

Parallel aan het ontstaan van Agile werd in het eerste decennium van de 21e eeuw het concept van het ‘minimal viable product’ (MVP) ontwikkeld. Bedrijven durfden het aan om met een MVP te beginnen, dit aan klanten ter beschikking te stellen en het vervolgens verder te verrijken met extra functionaliteit. De combinatie van Agile, Scrum en het MVP leverde snel in te zetten software op. In plaats van het vaak teleurstellende ‘big design up-front’ bleek het mogelijk om software ook plateaugewijs te ontwikkelen.

De Agile-werkwijze voor softwareontwikkeling bleek een succesvolle aanpak (figuur 1). Zoiets smaakt naar meer: wat goed is voor softwareontwikkeling, zou wellicht ook nuttig kunnen zijn voor andere projecten. Zo ontstond een brede stroming die gebaseerd is op het idee dat Agile een meer succesvolle projectmanagementmethodiek is dan de bestaande. Inmiddels wordt Agile ook geroemd als methode voor programmamanagement en zelfs bedrijfsmanagement.

Figuur 1.
Bron: Chaos Report, Standish Group 2015

Agile-manifest

Terug naar de basis: wat waren ook alweer de kernwaarden van de opstellers van het Agile Manifesto? Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. Het is volgens de opstellers van het Agile Manifesto overigens niet zo dat Agile aspecten als tooling, documenteren en planmatig werken overbodig maakt. Zij erkennen de waarde van deze aspecten. Het Agile-manifest kan gezien worden als een oproep om hierin niet door te schieten en ze te blijven challengen.

“Het Manifesto zet zich een beetje af tegen een al te instrumentele aanpak”

1. Individuals and interactions over processes and tools. De gedachte achter deze uitspraak moet gezien worden als een pleidooi om oog te blijven houden voor de menselijke inbreng in het aansturen van projecten. Handboeken met procesbeschrijvingen, kwaliteitshandboeken en tools die een zekere werkwijze afdwingen, kunnen leiden tot tijdrovende bureaucratie en te weinig ruimte voor flexibiliteit en innovatie. Door recht te doen aan interventies vanuit zowel projectmedewerkers als de vele stakeholders waarmee zij te maken hebben, ontstaan gezonde tegenkrachten.

Als het echt spannend wordt, dan moet de menselijk inbreng de doorslag geven. Ook in agile werkende organisaties liggen processen en tools op de loer. Een vast sprintritme, altijd pokeren, altijd demo’s en altijd een retrospective, zijn proceskenmerken die maar beter gechallenged kunnen worden vanuit menselijke inbreng en interactie. Voor de inmiddels beschikbare uitgebreide tooling van het Scrum-proces geldt hetzelfde.


2. Working software over comprehensive documentation. Natuurlijk verwacht een opdrachtgever dat er zo snel mogelijk een concreet, werkend resultaat wordt voortgebracht. Maar degene die later het resultaat moet beheren, aanpassen en onderhouden heeft er baat bij als gebruikgemaakt kan worden van adequate documentatie.

Zo ook het idee van ‘the big design up-front’. Zoals verderop in deze beschouwing wordt toegelicht, zal het in bepaalde situaties uitstekend zijn om eerst een globaal of zelfs meer gedetailleerd ontwerp te maken van het op te leveren resultaat. Dit kan gelden voor softwareontwikkeling en zal zeker ook gelden voor projecten die geen software maar andere resultaten moeten opleveren, zoals bijvoorbeeld in de bouw of de ontwikkeling van complexe zaken als vliegtuigen, treinen of machines om chips te produceren.


3. Customer collaboration over contract negotiation. Een contract moet het transparante resultaat zijn van afspraken over samenwerking. Eenmaal opgesteld, moeten contracten bij voorkeur in de symbolische kluis blijven. Als projecten worden uitgevoerd leidt samenwerking tot betere en snellere resultaten. Zodra partijen dreigen terug te vallen op contracten, verdwijnt de energie uit ieder project, stagneert al snel iedere ontwikkeling en wordt samenwerking vervangen door vijandigheden. Aan de andere kant: vanuit zaken als aansprakelijkheid, verantwoording, kwaliteit, operational en financial control, regelgeving en dergelijke, zijn contracten veelal een noodzakelijk kwaad.

4. Responding to change over following a plan. Door snelle veranderingen in consumentengedrag, concurrentieverhoudingen, wetgeving, technologie en dergelijke, moet een juiste balans gevonden worden tussen starre plannen en wispelturigheid. Dynamisch plannen, met ingebouwde ruimte voor tussentijdse aanpassingen van resultaat, scope, budget en deadlines, zal het antwoord moeten zijn op irreële verwachtingen van opdrachtgevers.

Bredere toepassing

De Agile-waarden leken zich ook te lenen voor toepassing buiten het gebied van softwareontwikkeling. Agile kreeg bredere aanhang in kringen van projectmanagement en bedrijfsmanagement. Het Manifesto zet zich een beetje af tegen een al te instrumentele aanpak en breekt een lans voor flexibiliteit, die rekening houdt met veranderende omstandigheden en samenwerking. Plannen, methoden en instrumenten moeten niet leiden tot inflexibiliteit of het negeren van de inbreng van betrokkenen, zoals teamleden, lijn- en projectmanagement, klanten en externe partijen. Samenwerking en bijsturen zijn dus van grote waarde.

Gedreven aanhangers van Agile willen de nuance die de founding fathers hebben aangebracht, nog weleens uit het oog verliezen. Planmatig en methodisch te werk gaan en zaken voor zover nodig vastleggen, worden beschouwd als old school en daarmee afgewezen. Het meest nadrukkelijk wordt dit verwoord door een harde tegenstelling te creëren tussen de aloude Waterval-aanpak en Agile. Dit geldt als een onnodige verarming van de gereedschapskist, waarover project-, programma- en lijnmanagers moeten beschikken.

Waarde van waterval

Onder waterval worden sequentiële softwareontwikkelmethoden verstaan. De ontwikkeling doorloopt een aantal fasen, zoals definitiestudie/analyse, basisontwerp, technisch ontwerp/detailontwerp, bouw, testen, integratie en beheer en onderhoud. Op de relevantie van de Watervalmethode voor softwareontwikkeling wordt hier niet verder ingegaan. De vraagstelling betreft immers een breder perspectief: methoden voor project-, programma- en bedrijfsmanagement.

Vanuit dit bredere perspectief verdienen meer traditionele methoden veel waardering. De piramiden van Gizeh, de maanwandelingen en de Deltawerken in Zeeland zijn op traditionele wijze tot stand gebracht. Bedrijven als IBM, Roche en Toyota hebben zich zeer behoorlijk tot sterke bedrijven weten te ontwikkelen, zonder dat er sprake was van Agile.

De traditionele aanpak van project- en bedrijfsmanagement kan in veel situaties een welkome of zelfs noodzakelijke aanpak zijn van managementopgaven. Als er een nieuwe landingsbaan moet worden aangelegd voor een vliegveld, een nieuwe MRI-scanner of een nieuw model auto moet worden gemaakt, dan is een MVP om meerdere redenen niet verstandig. Een gedegen analyse, ontwerp en gepland bouwtraject is hierbij dan ook zeer aan te bevelen.

Van belang daarbij is om een goed onderscheid te maken naar de aard van de opgave en de fase waarin het ontwerpproces zich bevindt. Bij sommige opgaven kan worden volstaan met een globaal ontwerp en kan nadere uitwerking overgelaten worden aan teams die zich op een deel van de opgave richten. Bij andere opgaven is het van belang vooraf vrij gedetailleerd aan te geven hoe iets geconstrueerd moet worden, waardoor de ontwerpvrijheid van teams klein is.

“De traditionele aanpak kan in veel situaties welkom of zelfs noodzakelijk zijn”

Bij de inzet van traditionele methoden voor project- en bedrijfsmanagement dienen de eerder besproken waarden als flexibiliteit en samenwerking echter ook een belangrijke rol spelen. De traditionele methoden moeten – evenmin als Agile – blindelings worden toegepast. In de ‘body of knowledge’ die in de afgelopen decennia is opgebouwd op het gebied van project- en bedrijfsmanagement is dan ook veel te vinden over een juiste balans tussen planmatig en methodisch werken in combinatie met aandacht voor flexibiliteit en samenwerking.

One size fits all

Het succes dat Agile in softwareontwikkeling heeft opgeleverd, heeft een discussie op gang gebracht om de werkwijze niet alleen in projecten maar ook op tactisch en strategisch niveau toe te passen. Ook hier past een nuancering. Bij het (her)ontwerpen van een bedrijfsstrategie is het raadzaam om de waarden van het Agile Manifesto goed in het achterhoofd te houden. Zo heeft het weinig zin om jarenlang of zelfs maandenlang bezig te zijn met het opstellen of bijstellen van een strategisch beleid voor een onderneming.

Aan de ene kant gaan de ontwikkelingen in de markt en de technologie te snel om tot een jarenlang houdbaar strategisch plan te komen, maar aan de andere kant is een bedrijf niet gebaat bij een voortdurend wisselende strategie. De werkwijze om tot een strategie te komen echter, kan zeker gebaat zijn bij Agile-waarden als snelheid, concreet resultaat, intensieve interactie met de omgeving (markt, partners, concurrenten, technologieleveranciers) en beknopte vastlegging ervan in documenten. Het resultaat, de bedrijfsstrategie, zal zodanig moeten worden geformuleerd en vastgelegd dat periodieke bijsturing mogelijk is.

Tegelijk biedt de vastgelegde bedrijfsstrategie kaders voor te nemen beslissingen op tactisch niveau. Met andere woorden: De strategie neemt beslis- of ontwerpvrijheid weg op laatstgenoemde niveau. Er zijn keuzes gemaakt die bepalend zijn voor het vervolg.

Doeltreffend

Zo ook op tactisch niveau. Keuzen voor strategische samenwerking, afzetkanalen, aantal vestigingen, organisatiestructuur, mate van outsourcing, inrichting van bedrijfsprocessen en applicatielandschap, in te zetten technologie en infrastructuur, vloeien ten dele voort uit de zojuist besproken strategische keuzes. Opnieuw kan een agile aanpak ingezet worden om relatief snel en doeltreffend tot keuzes op de zojuist genoemde terreinen te komen. Ook hier geldt dat intensieve samenwerking met de relevante omgeving van groot belang is, dat bureaucratie moet worden voorkomen, en dat wendbaarheid geborgd moet worden.

Via een dergelijke aanpak worden opnieuw keuzes gemaakt die kaderstellend zijn voor programma’s en projecten die uitgevoerd moeten worden om de gekozen doelen te kunnen gaan realiseren. Hier zien we ook de aansluiting met het Scaled Agile Framework (SAFe). Strategische en tactische keuzes leiden tot epics die op hun beurt in een latere fase leiden tot stories en features. Epics die een langere tijd vereisen om gerealiseerd te worden, kunnen georganiseerd worden in value-streams, waarbinnen Scrumteams hoogproductief hun bijdragen leveren aan het realiseren van features en stories, waardoor ze een belangrijke bijdrage leveren aan het realiseren van de strategische doelen van de onderneming.

Tegenstelling?

De opstellers van het Agile Manifesto vroegen in de eerste plaats aandacht voor een meer flexibele wijze van softwareontwikkeling. Een in beton gegoten aanpak, vuistdikke rapporten en contracten en een ‘IJzeren Heinig’ vasthouden aan een eenmaal uitgezette planning, bleek niet altijd snel het gewenste resultaat op te leveren. Vandaar hun pleidooi om – als het nodig is – accenten anders te leggen. Zij hebben niet de stelling betrokken dat we moeten stoppen met planmatig werken.

De waarden van het Agile Manifesto attenderen erop dat er soms grenzen zijn aan de planbaarheid van projectvoortgang of van het op te leveren resultaat. De oproep van de ‘manifesters’ kan dan ook gezien worden als een geslaagde poging om bestaande methoden te verrijken met aanvullende inzichten. Hun bijdrage aan het denken over methodisch werken ligt dan ook vooral in de notie dat plannen, ontwerpen en contracten als het nodig is bijgesteld moeten worden om recht te doen aan gewijzigde inzichten of omstandigheden.

Nieuwe fase

Enkele jaren ervaring met Agile, niet alleen bij softwareontwikkeling maar ook in breder managementverband, heeft waardevolle leerervaringen opgeleverd. Zo is duidelijk geworden dat Agile kan leiden tot snel toepasbare resultaten. Grote uitdagingen beheersbaar maken door ze in kleinere stappen of plateaus te realiseren is wederom bevestigd.

Ook het idee om projecten niet alleen door een projectteam te laten uitvoeren, maar steeds nauwe samenwerking met senior management, lijnmanagement of uitvoerende medewerkers, blijkt tot betere resultaten te leiden. De Agile-ontwikkeling doet inzien dat samenwerking met managers, uitvoerenden en klanten niet alleen relevant is in de start- en acceptatiefase van een project, maar dat ook in alle fasen daartussen veel toegevoegde waarde oplevert.

“In een nieuwe fase worden combinaties van methoden en technieken mogelijk”

Het aantal en de omvang van documenten en contracten binnen de perken houden, scheelt overbodig werk. De combinatie met ideeën zoals het MVP, Kanbanborden en Scrumteams heeft de gereedschapskist van softwareontwikkelaars en projectmanagers verder aangevuld.

Haarlemmerolie

Maakt Agile alle voorgaande ontwikkelaanpakken en (project-)managementmethoden overbodig? Agile is een corrigerende verrijking van voorgaande methoden. Als een appèl om niet rucksichtslos vast te houden aan eenmaal opgestelde plannen, ontwerpen, contracten of formele eisen die aan documenten gesteld zijn.

Er breekt een nieuwe fase aan waarin combinaties van methoden en technieken mogelijk worden. Welke methode wordt toegepast hangt af van de opgave die voor ligt en factoren als de cultuur van een organisatie. Zo zal de bouw van een nieuw kantoor, een nieuwe fabriek, een vliegveld of een woning, niet snel volledig agile aangepakt worden. Zicht op het totaalontwerp en de planning van de aanvoer van materialen en de inzet van vele soorten bouwers is noodzakelijk. Met andere woorden: de planningsvrijheid is beperkt en de onderlinge afhankelijkheden zijn groot.

Het eindresultaat van dergelijke projecten moet redelijk nauwkeurig omschreven worden voordat met de werkzaamheden kan worden begonnen. Voor het bouwen van een nieuwe app ligt dit anders, zeker als het moment van ingebruikname en de omgeving waarin de app moet worden ingezet flexibel van aard is. Een globaal idee over de gebruikerswensen kan een voldoende basis zijn om te beginnen en een MVP als eerste resultaat op te leveren. Daarna kan de app verder ontwikkeld worden.

De opgave en context zijn bepalend voor de keuze van de methode. Bij een hoge mate van planningsvrijheid en geringe mate van onderlinge afhankelijkheid, zal een agile werkwijze al snel de voorkeur verdienen. Dit geldt te meer als er tevens sprake is van een grote mate van vrijheid in de kenmerken van het op te leveren eindresultaat. De onderstaande figuur laat zien hoe – op projectniveau – de afweging voor een agile aanpak versus een meer traditionele aanpak gemaakt kan worden.

Figuur 2. De afweging voor een agile versus een traditionele aanpak

Conclusie

De wakeup call van de manifesters in 2001 heeft een hoge mate van weerklank ondervonden. De zegetocht begon in de wereld van softwareontwikkeling, waarna de Agile-waarden ook meer en meer van belang geacht werden voor het managen van projecten in het algemeen, programma’s en bedrijven. Het besef dat er in nauwe samenwerking met alle belanghebbenden, snel waardevolle resultaten bereikt moeten worden in combinatie met het besef dat we nu eenmaal in een zeer dynamische en dus veranderlijke wereld terecht zijn gekomen, is belangrijk voor management op operatoneel, tactisch en strategisch niveau.

Aan de andere kant blijft het bieden van inhoudelijke kaders en planningen, gebaseerd op strategische en tactische keuzes van belang om sturing te geven aan de snelle ontwikkeling van nieuwe producten en diensten. Een juist gekozen synthese van Agile en traditioneel management lijkt voorlopig dan ook verstandig.

We kunnen de toekomst met iets meer vertrouwen tegemoetzien. Dankzij de Agile-ontwikkeling is de gereedschapskist van managers beter gevuld en kunnen we per opgave en situatie het juiste instrument inzetten.

Guido Bayens (gbayens@novius.nl) is partner van Adviesgroep Novius. Met medewerking van Jeroen Cloo (cloo@novius.nl), principal consultant en manager van het Competence Center Bedrijfsarchitectuur van Adviesgroep Novius.