Is agile te snel voor prima software?

Toen mijn vader in 1948 opging voor het aannemers-examen, was het onderwerp het begroten van een garage. In de koffiepauze hoorde hij welke prijzen iedereen in gedachte had. “ƒ 3800” zei de één, weer anderen schatten ƒ 3960 en ƒ 3400. Mijn vader had alleen nog de benodigde materialen uitgetrokken. Het laatste uur schreef hij zijn lijst netjes, maar wanhopig, uit, want de prijs berekenen, daar was hij nog lang niet aan toe.

Na 6 weken ontving hij toch een uitnodiging voor een mondeling. Mijn vader ging en bedankte de examinator voor zijn herkansing. “Hoezo?”, vroeg de examinator hem. Mijn vader antwoordde dat de anderen al bij de pauze de prijs wisten, terwijl hij daar nog bij lange na niet aan toe was.

De examinator antwoordde: “Meneer van der Leer, wie op de verkeerde manier begint zal nooit tot een goed einde komen. De anderen zijn gezakt. U bent één van de twee kandidaten die door zijn naar het mondeling!”. En hij vervolgde “En, meneer van der Leer, u zult vaak ’s avonds door moeten werken, maar als u goed begint hebt u een kans dat u goed eindigt. Als u verkeerd begint, zult u nooit slagen.”

Dat is lang geleden, maar het gaat nog altijd op: wie op de verkeerde manier begint zal nooit tot een goed einde komen. Dat geldt voor begroten van bouwwerken, dat geldt voor projectvoering en dat geldt voor software schrijven.

Ik ben een beetje anti-agile

Als het om software ontwikkelen gaat, ben ik een beetje anti-agile. Ik durf het bijna niet te zeggen, maar het is zo.

Niet dat ik pro waterval ben, want ik ga mee in de tijd. Dingen veranderen. Mijn vader deed zijn examen met potlood en papier, later gebruikte hij Excel en dat ging een stuk sneller. Wat hij niet deed was afwijken van zijn principe: begin goed, want anders kom je niet tot een goed einde.

En dat is precies wat ik mis bij agile. Agile staat voor mij bijna gelijk aan vlug werken en opleveren. Dat vlugge, dat lukt prima met de toolsets van tegenwoordig. Dat opleveren ook. Wat ik mis is de diepgang: kan het systeem alle eisen verwezenlijken? Is het robuust genoeg, sluit het aan op de business processen?

Waar is het grotere geheel?

Wat ik bij agile mis is de aandacht voor het grotere geheel. Een agile team is in zichzelf gekeerd. Focus op productie en levering. Ja, als het om een eenvoudig systeem gaat, dan is er niets aan de hand. Het kan dat mijn beeld eenzijdig is, omdat ik nooit met een eenvoudig systeem in aanraking kom.

Software ontwikkelprojecten die crashen

Ik word namelijk nogal eens betrokken bij projecten en software ontwikkelingen die niet goed gaan. Niet goed, is een eufemisme. Ik zie veel projecten die uit de bocht vliegen. Waar keer op keer op keer een deadline niet gehaald wordt. Waar opgeleverde systemen in productie crashen. En dan vraag ik me af: kan dat zomaar? Het antwoord lijkt: Ja, dat kan zomaar. Om een mij onbekende reden staat er niemand op die zegt: “Zo kan het niet langer!!”. Totdat de wal het schip keert. Er komt soms toch een moment waarop zelfs de meest gehaaide manager moet toegeven: “Het lukt ons niet”.

Ik lees ook over zulke mislukte projecten in de pers. Het valt me op dat dan, achteraf, iedereen ervan overtuigd is dat het nooit wat had kunnen worden. Dat de stekker er al jaren geleden uitgetrokken had moeten worden. Dat mislukken vanaf het begin een gegeven was.

En dan kom ik erop terug dat ik een beetje anti-agile ben.

Ik ben anti-agile omdat ik tegen snel starten ben

Ik ben vooral anti-agile als iedereen staat te trappelen van ongeduld om te beginnen en dan om elf uur ’s morgens de prijs denkt te weten van de garage. Een prijs die concreet is, een prijs die indruk wekt dat iemand deskundig is. En achteraf blijkt de prijs veel te laag, omdat bijvoorbeeld het dak vergeten is. Want dat zag de maker niet. Die bleef aan de kant kijken en zag niet het geheel.

Een voorbode van falen

Mijn ervaring met software ontwikkelen is dat snelle starts voorbode zijn van uiteindelijk falen. Software kent, zoals garages, daken die je niet ziet vanaf de buitenkant. Eenmaal gebouwd en opgeleverd blijkt het product toch niet te voldoen aan elementaire eisen en ja, dan is Leiden in last. Zie het dan maar eens te repareren, dat kost handenvol geld. En tijd. Tijd, waar niemand op gerekend had.

Na het feest volgt de deceptie

Voor mij is dat typisch voor de huidige agile aanpak van software projecten. Men schakelt snel en bouwt vervolgens de dingen die snel gemaakt kunnen worden. Het eerste opgeleverde product werkt. Hoera, iedereen in jubelstemming. En dan komt de deceptie, want de moeilijke functies moeten nog ontworpen worden. Dan blijkt het ontwerp niet te passen bij de database en bij wat er gebouwd is. Alles moet opnieuw. Terwijl mensen al met het systeem werken. Leg dat maar eens uit.

Je móet vooraf nadenken

Wat men bij agile software bouwen uit het oog (en het hart) verliest, is dat vooraf nadenken noodzakelijk is. Het programmeren is zo makkelijk. Als het fout gaat doen we het gewoon opnieuw en beter. Zo nodig nog een keer. Al die keren samen zorgen voor uitloop. Plus, dat het vertrouwen bij de gebruiker gaat tanen. Waarom dan, zo vraagt de gebruiker zich af, waarom kan zoiets eenvoudigs niet in één, twee keer goed?

Het wordt pas echt vervelend als er wantrouwen ontstaat. Als de bouwers gaan stellen dat de gebruiker continu zijn eisen verandert, niet meewerkt, in feite, dat de gebruiker de schuld van alle uitloop en ellende is. De gebruiker pikt dat niet en voelt zich, mijns inziens terecht, aangevallen en de dialoog stokt. Dat is het moment waarop het ook voor de buitenwereld duidelijk wordt dat het project een mislukking is.

Helaas, waterval is evenmin de oplossing

Waarom zeg ik dat? Ik kan zeggen dat de wereld te snel verandert, dat waterval dus per definitie achterloopt en dat gelooft iedereen. Dan maak ik me er met een Jantje van Leiden van af. Dat doe ik niet. Wat ik wel zeg is: Waterval is niet verkeerd omdat de wereld te snel verandert, het is verkeerd omdat de wereld veranderd is.

We leven al lang niet meer in de tijd van potlood en papier en van loopjongens die bestelbonnen naar de groothandel brengen. We bestellen op Internet. Vliegensvlug. Met zulke ontwikkelingen moet een aannemer rekening houden anders gaat hij achterlopen en wordt te duur.

Aandacht voor het grote geheel

Wat essentieel is aan waterval is: de aandacht voor het grote geheel. Er wordt bij waterval niet gebouwd voordat alle eisen op een rij staan en een ontwerp is gemaakt dat al die eisen verwezenlijkt. Zo doende is zeker dat er tenminste één oplossing bestaat (ook al is die nog niet gebouwd) waarmee het business probleem aantoonbaar en integraal aangepakt wordt.

Voor de goede orde: bij het grote geheel zijn er veel eisen waar een softwaresysteem aan moet voldoen. Naast het ondersteunen van de business: security, performance, schaalbaarheid, onderhoudbaarheid, aanpasbaarheid. Je kunt het hele scala van hoedanigheden uit ISO 25010 erbij halen. En dan heb je nog niet alles. Dat maakt goed software ontwikkelen zo ontzettend lastig.

Pas bouwen als je alle eisen kent en kunt realiseren

Voor mij staat daarom als een paal boven water dat je niet met bouwen moet beginnen voordat je alle eisen kent en er minimaal één (het liefst meer dan één) ontwerp bestaat dat al die eisen realiseert. Dat eisen opstellen en ontwerpen mag best agile gebeuren: dat levert zeker bij ontwerpen veel tijdwinst op. En door de meest moderne hulpmiddelen te gebruiken voor de broodnodige flexibiliteit. Ik vind zelfs dat er voor sommige delen voorbeelden moeten zijn, inzichtelijk voor iedereen. Dat de meest cruciale zaken tot in detail onderzocht zijn op wat goed is.

De methode verdwijnt op de achtergrond

Heel opmerkelijk: als er eenmaal een goed ontwerp staat, er voorbeelden zijn van hoe het systeem er uit gaat zien en cruciale zaken aantoonbaar zullen lukken, dan vervaagt voor het realiseren het onderscheid tussen agile en waterval.

Hoe je de bouw dan aanpakt, het resultaat zal aan de verwachtingen van de eindgebruiker voldoen.

Is dit niet wat wij allemaal willen?