“De opdrachtgever krijgt er flexibiliteit voor terug”

In gesprek met Sander Hoogendoorn, schrijver, coach, trainer, spreker en onafhankelijk adviseur op het gebied van softwareontwikkeling, over de wereld achter agile.

U geeft presentaties, trainingen en schrijft boeken. Hoe bent u op dit punt terecht gekomen?

“Ik ben al vroeg gestart met programmeren. Op mijn vijftiende programmeerde ik op een Commodore 64. Daarna studeerde ik informatica, eerst aan de HTS en daarna aan de universiteit. Tijdens mijn eerste baan bij CMG (nu CGI) bleek ik wel aanleg voor programmeren te hebben. Vervolgens dacht ik: laat ik er eens iets over gaan vertellen. Dat bleken mensen leuk te vinden. Dit leidde ertoe dat ik trainingen ging geven en artikelen ging schrijven. Al snel werd ik ook gevraagd om op conferenties te spreken, eerst in Nederland, maar kort daarna ook internationaal. Ik ben er dus als het ware ingerold. In mijn werk heb ik me eigenlijk altijd beziggehouden met de innovatie van softwareontwikkeling. Wat mij daarbij opvalt, is dat projecten gericht op softwareontwikkeling overal ter wereld vaak op dezelfde manier fout gaan.”

Hoe gaan softwareontwikkelprojecten dan vaak fout?

“Veel projecten maakten en maken nog steeds gebruik van de lineaire of watervalmethode, waarbij ervan uit wordt gegaan dat een project en de wereld om het project heen planbaar en beheersbaar zijn. Er worden dan vooraf heel gedetailleerde stappenplannen uitgewerkt en gevolgd op basis van in steen gehouwen wensen en eisen, die daarna in de praktijk vaak al snel achterhaald blijken te zijn. De wereld verandert nu eenmaal voortdurend. Denk maar aan veranderende wet- en regelgeving, nieuwe technologie of personele bezetting. Van de projecten waarvoor dit soort traditionele methodieken worden gehanteerd, faalt tussen de 75 en 90%.”

Hoe zit dat bij overheidsprojecten?

“Ook grote overheidsprojecten falen vaak omdat daar, bijvoorbeeld bij aanbestedingen, nog steeds gebruik wordt gemaakt van zo’n traditionele lineaire aanpak met lang van te voren vastgestelde wensen en eisen. Daarbij speelt bij de leveranciersselectie de prijs ook nog een belangrijke rol, met als gevolg dat leveranciers zo goedkoop mogelijk inschrijven en uiteindelijk niet de beste mensen (kunnen) leveren voor het project. Men gaat er in dit soort gevallen nog te veel vanuit dat alles tot in hoge mate van detail is vast te leggen en planmatig is op te leveren. Dat is een illusie! Wensen en eisen veranderen tijdens de uitvoering van een project voortdurend. En terecht. Je kunt niet vooraf rond de tafel gaan zitten en alles in detail specificeren voor een systeem dat pas vijf jaar later in de lucht is.”

“Softwareontwikkeling kent een hoge dynamiek, denk alleen al aan de voortdurende technologische ontwikkelingen die beschikbaar komen”

Waarom kun je zaken niet tot in detail plannen?

“Softwareontwikkeling kent een hoge dynamiek, denk maar aan de voortdurende technologische ontwikkelingen die beschikbaar komen, klanten die van gedachten (wensen) veranderen, wijzigingen binnen de teamsamenstelling en nieuwe ervaringen en ideeën die zich in de teams ontwikkelen. Er is zo veel aan verandering onderhevig dat je dat van tevoren niet allemaal kunt voorzien. In ieder project, in iedere branche, maar zeker bij softwareontwikkeling, veranderen de dingen nu eenmaal. Softwareontwikkeling is een relatief jonge professie en ontwikkelt zich razendsnel. Dat maakt vooraf plannen zo enorm lastig. De technologie is amper bij te houden.”

“Als gevolg hiervan kwam er midden jaren negentig een kentering in de manier waarop mensen over methodieken nadachten en zijn de opvattingen over wat werkt en wat niet, gaan schuiven. Waterval is een type methodiek waarbij je zegt: we spreken alles van tevoren af en aan het eind van een project kijken we of het conform het plan is gegaan. Organisaties zagen in dat dit niet de optimale manier was om software te realiseren. Want als je gedurende het project wijzigingen wilde, kon je die niet goed meer kwijt. De watervalmethode bleek onvoldoende flexibel. Wat je toen zag ontstaan waren projecten die in steeds kortere cycli gingen opereren.”

Op welke manier zorgt agile voor meer flexibiliteit?

“Kenmerkend voor agile is dat projecten in kleine brokjes worden opgeknipt. In plaats van een plan voor een heel jaar wordt een project bijvoorbeeld in twaalf brokjes van een maand opgedeeld. Dit leidt ertoe dat er voortdurend kan worden bijgestuurd. De lengte van dergelijke brokjes, vaak time box, iteratie of sprint genoemd, werd in de loop der jaren steeds korter. In eerste instantie kenden projecten iteraties van drie tot vier maanden. Naarmate we meer leerden over dit iteratieve werken, werden deze blokken steeds korter. Rond de eeuwwisseling ging men al plannen en werken in iteraties van rond de zes weken. Veel projecten werken nu in iteraties van twee of drie weken, of zelfs nog korter. Tijdens iedere iteratie wordt een deel van de wensen en eisen opgeleverd en vervolgens wordt gekeken wat er in de volgende iteratie wordt gedaan. Belangrijk voordeel van deze aanpak is dat je als team heel snel feedback krijgt op de geleverde resultaten. Hoe korter de iteratie, hoe sneller je feedback krijgt en hoe effectiever je bent. De feedbackloop is dus nooit langer dan de lengte van de iteratie.”

Wat gebeurt er tijdens een iteratie?

“Tijdens zo’n iteratie verricht het projectteam de afgesproken werkzaamheden, maar evalueert het ook het opgeleverde werk en kijkt het hoe de werkwijze is te verbeteren. Ook dat is kenmerkend voor agile: je werkwijze voortdurend verbeteren. Dit is een groot verschil met projecten die opgezet zijn volgens de watervalmethode. Bij die traditionele methodiek vindt evaluatie meestal pas plaats na afronding van het project, tijdens de uitvoering van het project leer je dus te weinig!”

Waarom werken agile-projecten beter?

“Het lerend vermogen in kortcyclische projecten is vele malen groter en dat is een van de redenen dat agile-projecten beter werken. Bij een agile-aanpak wordt er gewerkt met een lijst van uit te voeren activiteiten, de zogenaamde backlog. De belangrijkste activiteit wordt steeds als eerste opgepakt. Na realisatie hiervan kijkt het team in overleg met de opdrachtgever wat de volgende op te pakken activiteit is. Als de opdrachtgever van gedachte of prioriteit wisselt, kan dit eenvoudig worden meegenomen. Zo doet het team steeds de belangrijkste dingen.”

Wat betekent agile voor de relatie tussen opdrachtgever en softwareontwikkelaar?

“Opdrachtgevers hebben vaak moeite met het (in detail) definiëren van wat zij uiteindelijk nodig hebben. Het vooraf bepalen wat je nodig hebt en hoe je dat moet bereiken is lastig omdat de wereld in rap tempo verandert. Voor een opdrachtgever is het ook veel beter om per twee weken te bepalen wat de volgende stap zou moeten zijn. Dan krijgt hij uiteindelijk veel meer waar voor zijn geld dan wanneer de watervalmethode wordt gehanteerd. De opdrachtgever krijgt er een stuk flexibiliteit voor terug.”

“Een agile-aanpak verlangt dat de opdrachtgever continu betrokken is bij het project en dat hij op ieder moment kan aangeven wat hij wil met de eerstvolgende activiteit”

“Een dergelijke aanpak verlangt dat de opdrachtgever continu, liefst dagelijks, betrokken is bij het project en dat hij op ieder moment kan aangeven wat hij wil met de eerstvolgende activiteit. De relatie tussen opdrachtgever en teams is in een agile-project dan ook heel intensief. Een bijkomend verschil met de watervalmethode is dat je daar veel meer te maken hebt met het wij-zijdenken tussen opdrachtgever en opdrachtnemer. Bij een agile-aanpak doet zich dit nauwelijks voor, daarvoor zit de opdrachtgever te dicht op het team. Je probeert met zijn allen tot een goed product te komen.”

Naast agile lezen we ook over scrum, extreme programming, DSDM, kanban. Wat zijn de verschillen?

“Je kunt agile zien als een soort mantelbegrip voor allerlei initiatieven die zijn ontstaan vanwege ontevredenheid over de inflexibiliteit van de traditionele methodieken. Nieuwere aanpakken bleken een groot aantal elementen gemeenschappelijk te hebben. Daar is in 2001 de term agile op geplakt. Alle agile-aanpakken hebben min of meer dezelfde principes en uitgangspunten: het werken in korte iteraties, het voortdurend opnieuw prioriteren, het binnen een iteratie volledig uitvoeren van een aantal activiteiten en het werken in multidisciplinaire teams. Deze principes komen in alle aanpakken terug. Scrum geeft invulling aan de agile-principes, maar hanteert een eigen terminologie (een iteratie heet bijvoorbeeld een sprint), maar dat doet er niet zoveel toe, het gaat om de principes. Dat geldt ook voor andere bekende aanpakken als extreme programming, DSDM of smart.”

Hoe ziet de ontwikkeling van dergelijke methodieken eruit?

“We gaan binnen softwareontwikkeling alles in nog kleinere brokjes doen. We bouwen straks aan een product door steeds hele kleine stukjes software te implementeren, bijvoorbeeld in microservices. Dit doe je in zo kort mogelijke cycli, bijvoorbeeld in een dagelijks ritme, met zo klein mogelijke teams, denk aan drie á vier personen per team. Ik noem dat microteams. Door zo kortcyclisch te werken, in feite nog veel kortcyclischer dan in agile-projecten, krijg je heel andere mechanismen binnen je organisatie. Uiteindelijk blijkt dan dat je voortdurend producten doorontwikkelt en dat de aloude projectmetafoor in deze professie eigenlijk geen zin heeft. Dit heet continuous delivery.”

Zitten er ook negatieve kanten aan agile?

“Ik zou zeggen van niet. Wel is een voorwaarde voor succes dat de opdrachtgever betrokken bij het project moet zijn. Hoewel deze betrokkenheid de opdrachtgever meer tijd lijkt te kosten dan traditioneel, is dat doorgaans in werkelijkheid niet het geval. Het verschil is dat de tijd die in het project wordt gestoken veel meer verspreid is over de doorlooptijd van het project. Bij de watervalmethode is de opdrachtgever voornamelijk bij het begin en aan het eind van een project intensief betrokken, bij agile is de opdrachtgever dagelijks betrokken. Het is bij agile niet zozeer dat de opdrachtgever er meer tijd in steekt, het is wellicht evenveel tijd, maar hij moet frequenter (kort) beschikbaar zijn. Iedere dag een klein beetje. Vaak wordt er ook een product owner aangewezen. Deze product owner zit tussen het team en de opdrachtgever in.”

Klopt het dat u met een volgend boek bezig bent?

“Mijn boek Dit is agile beschrijft mijn ideeën en ervaringen tot aan 2014. Nu ben ik bezig met de allernieuwste ontwikkelingen en ervaringen, die zich meer begeven op het vlak van continuous delivery en hele platte organisaties met zelforganiserende teams en heel weinig management en overhead. Mijn volgende boek, The continuous culture, dat ik samen met mijn vriendin Kim van Wilgen schrijf, gaat dan ook over deze laatste ontwikkelingen.”