Uw software op maat, binnen een maand bruikbaar, tegen vast maandbudget. Dit is wie deze belofte draagt.

Van 2012 tot 2014 volgde ik een BTS domotica, een tweejarige Franse technische opleiding, in een leer-werktraject als technicus automatische deuren. Daarna wilde ik een bachelor doen om IoT-toepassingen te ontwerpen. Mijn resultaten ontmoedigden me, dus zag ik ervan af. Vervolgens werkte ik in de elektronische beveiliging.

In 2016 besloot ik mijn plan om ontwikkelaar te worden nieuw leven in te blazen. Het idee had me nooit losgelaten, en om persoonlijke redenen moest ik het hoe dan ook doen. Stap voor stap pakte ik het op, naast mijn werk, en een ontwikkelaar hielp me op weg. In 2017 werd ik benaderd door een opleidingsinstituut dat me een opleiding van negen maanden verkocht. Ik had op mijn hoede moeten zijn: een goede school hoeft geen cursisten te ronselen. Maar ik wilde koste wat het kost ontwikkelaar worden, en mijn situatie was kwetsbaar. Ik was naïef. Van ’s ochtends tot ’s avonds, van 8 tot 18 uur, moesten we video’s kijken en er daarna verslagen over schrijven. Vervolgens overhoorden we elkaar met meerkeuzetoetsen om te controleren of we het begrepen hadden. Zo leerden ze ons zogenaamd programmeren. De meeste cursisten in mijn klas zaten in een onzekere situatie. Velen kwamen uit het buitenland, en de opleiding werd hun gepresenteerd als hun kans om in Frankrijk te blijven en eindelijk interessant werk te vinden. Na drie maanden kwam een accountmanager van een detacheringsbureau dat aan het instituut verbonden was, cursisten uitzoeken om aan haar klanten voor te stellen. Ze koos mij. Om voorgesteld te worden, moesten er op mijn cv vijf jaar ervaring en een master staan. Ik weigerde. Met dat cv had ik een project gekregen dat ik niet tot een goed einde kon brengen, en dan hadden het team en de klant de prijs betaald. Het antwoord was: “Sébastien, je houdt je niet aan de verkoopvoorwaarden van het instituut.” Ik werd van de opleiding gestuurd, met het verzoek om “uit beroepsethiek”, na alles wat het instituut “voor me had gedaan”, buiten de deur niet over deze praktijken te praten. Dat instituut gedroeg zich als een sekte, en zijn verkoopvoorwaarden kwamen neer op leugens en manipulatie. Al snel, in mijn eerste maanden in deze branche, zag ik waar ik in terechtkwam: een wereld vol charlatans. Een eerste baan als ontwikkelaar kreeg ik niet. Vanaf mijn eerste stappen in dit vak wilde ik geen concessies doen aan mijn principes. In de tussentijd koos ik liever voor een ander vak, de IT-support, dan me voor te doen als iemand die ik niet was. En ernaast leerde ik zelf verder. Mensen uit het vak om me heen vertelden over projecten die misgelopen waren. Ik dacht dat het mij wel zou lukken. Agile werken had toen al mijn interesse: software in kleine stappen bouwen en bijsturen op basis van feedback. Sommige teksten spraken me aan, al begreep ik ze nog niet helemaal. Met die problemen had ik zelf nog niet te maken.

Van oktober tot december 2018 volgde ik een bootcamp webontwikkeling. Die gaf me de basis en zorgde ervoor dat ik zelfstandig verder kon leren. Ik sloot af met een certificaat in web- en front-endontwikkeling. In januari 2019 begon ik als zzp’er en vond ik mijn eerste opdrachtgevers. Ik begon in onderaanneming voor een in Nederland gevestigde ontwikkelaar met vijftien jaar ervaring. In zijn project waren het uitrollen en het testen al geautomatiseerd, een basishygiëne die destijds maar heel weinig webapplicaties hadden.

In augustus 2019 ging ik opnieuw studeren voor een bachelor. In die bacheloropleiding stonden de studenten er grotendeels alleen voor. Als ik een vraag stelde, kreeg ik te horen: “Zoek het zelf uit, doe je eigen onderzoek.” Ik vroeg me af wat ik daar eigenlijk deed. Dus zocht ik het zelf uit: ik kocht cursussen en werkte aan mijn eigen projecten. De weinige studenten die het haalden, deden hetzelfde.

Bij mijn afstuderen vroeg ik de examencommissie of ik nog een master moest doen. Op basis van mijn projecten raadde de commissie me aan direct de arbeidsmarkt op te gaan; verder studeren kon later altijd nog. Ze voegde eraan toe: “Normaal zeggen we dit niet, maar u kunt met een gerust hart gaan, u hebt uw diploma. Dit advies zouden we uw medestudenten niet geven.” Toen ik de opleidingscoördinator vertelde dat ik ermee stopte, zei ze: “We leiden onze bachelorstudenten zo goed op dat ze geen master nodig hebben.” Ik heb daar niets op gezegd, om haar niet te ontmoedigen. In werkelijkheid had ik het zelf moeten leren, en me verdiept in onderwerpen waar mensen op mijn niveau zich toen al niet per se druk om maakten.

Dat komt door mijn achtergrond en door hoe ik denk, en dat veranderde in 2017, toen ik een religieuze opleiding volgde die voorbereidde op lesgeven. Je kunt niet onderwijzen wat je niet begrijpt, of waar je niet van overtuigd bent: dan doe je het zonder enthousiasme, zonder vuur. Daar leerden we dus zelf onderzoek te doen, terug te gaan naar de bron om iets te begrijpen, en te steunen op bewijs in plaats van op loutere overtuigingen. Tijdens mijn BTS studeerde ik nog niet zo. Ik miste basiskennis, van wiskunde bijvoorbeeld, en ik had tijd noch steun om die bij te spijkeren. In mijn bachelor had ik het wel onder de knie. Als ik iets niet begrijp, leg ik me daar niet bij neer: ik blijf vragen stellen tot ik het door en door ken. Zo nodig ga ik terug naar de meest elementaire begrippen. Anders bouw je een kaartenhuis en werk je op de automatische piloot. En als ik verantwoordelijkheid krijg, wil ik die volledig dragen. Mijn fouten mogen niet op anderen terechtkomen.

In 2021 liep het project waaraan ik werkte steeds verder achter. Mijn eerste reactie was die achterstand in te halen met overuren, weekenden en te korte nachten. Ik ging niet meer uit. Niets hielp: de achterstand werd niet kleiner, en mijn gezondheid leed eronder. Ik besefte dat ik een spel speelde dat niet te winnen is. Het moest anders, ter wille van het budget van de klant en van onze gezondheid. Het hele team, niet alleen ik, wilde blijven werken aan een project dat ons boeide, ervan kunnen leven en trots zijn op wat we opleverden. Ik nam het initiatief en ging me ook met het projectmanagement bezighouden, al was dat niet mijn functie. Niemand had er belang bij dat het project mislukte, de klant niet en het team niet, wiens werk ervan afhing.

Om binnen budget en planning te blijven, maakten we als team een keuze. We stopten met het bouwen van functionaliteiten alleen omdat ze in het programma van eisen stonden. Om de belofte aan de gebruikers waar te maken, hoefde niet alles in de eerste oplevering te zitten. Wat nog gebouwd moest worden, stelden we uit. Wat al gebouwd was en onmisbaar bleek, versterkten we. Waar we al aan begonnen waren maar wat in dit stadium niet essentieel was, schrapten we. Vooral richtten we ons op wat er echt toe deed. De derde deadline, de eerste waarbij ik zelf het projectmanagement op me had kunnen nemen, haalden we, en we leverden een bruikbare applicatie op. Ik zag dat de applicatie binnen een maand bruikbaar had kunnen zijn als we bij de kern waren begonnen. De rest had daarna kunnen volgen, zonder in te leveren op kwaliteit. Ik wist nog niet wat agile werken echt inhield. Maar ik zag wat projectmanagement dat zich aanpast oplevert.

Ik wilde beter worden in geautomatiseerd testen: weten waar je tests neerzet, en hoe je een applicatie goed test. Op zoek naar mensen die het vak beheersen, kwam ik een lezing tegen van Dave Farley, de bedenker van de deployment pipeline, vaak CI/CD-pipeline genoemd. Samen met Jez Humble definieerde hij continuous delivery, waarvan geautomatiseerde tests maar één onderdeel zijn. Wat hij uitlegt, is eenvoudig en direct toepasbaar.

Dan bleef de vraag van het budget nog over. Ik wist dat je met schattingen geen budget kunt vastleggen en geen planning haalt, maar ik wist niet hoe het anders moest. Het Agile Manifesto kende ik al sinds het begin van mijn loopbaan, en één waarde ervan deelde ik: uitgaan van wat de gebruikers moeten kunnen doen, en alleen bouwen wat daaraan bijdraagt.

Ik wist dat het patroon dat ik steeds zag, niet alleen mijn indruk was. Wat ik wilde weten, was of het gedocumenteerd was, met cijfers onderbouwd. Ik ging zoeken en stuitte op onderzoek met deze uitkomst: 0,5 % van de grootschalige projecten, in alle sectoren, voldoet aan budget, planning en verwachte resultaten (Flyvbjerg, How Big Things Get Done, 2023, 16.000 projecten). Alle drie tegelijk halen is een kwestie van geluk: in het vak heet dat de ijzeren driehoek, en er geeft altijd één kant mee. De rest overschrijdt het budget, of blijft erbinnen door een deel van de plannen te schrappen, zoals wij hadden gedaan. Een ander onderzoek maakte ook indruk op me: slechts 1/3 van de bij Microsoft geteste ideeën verbetert de beoogde indicator (Kohavi et al., Online Experimentation at Microsoft, 2009). De oorzaak lag in de manier waarop projecten worden aangepakt, en die kun je veranderen. Sindsdien wil ik zelf contact hebben met de gebruikers om hun doelen te begrijpen, zonder dat iemand daartussen verandert wat ze zeggen. Een tussenpersoon kan het ophalen van de wensen makkelijker maken, zodat ontwikkelaars niet al hun tijd kwijt zijn aan overleg, maar mag niet verhinderen dat gebruikers en ontwikkelaars met elkaar praten. Zodra een functionaliteit live staat, controleer ik of het doel ervan wordt gehaald. Anders loop je het risico functionaliteiten op te leveren waar niemand iets mee doet.

In 2023 kwam ik bij een groot concern in het team van een project dat twee jaar heeft geduurd, met twee miljoen euro geïnvesteerd. Meerdere teams werkten aan dezelfde software, elk op een eigen kopie van de code. Niemand vroeg om het werk tussentijds te integreren. Na ongeveer vier maanden moest het werk van alle teams worden samengevoegd: alle bugs kwamen in één keer boven, samen met de conflicten tussen de kopieën en de keuzes welke code bleef. Na maandenlang wachten, elk team op zijn eigen eiland, volgden twee weken overwerk en stress. Het werk continu en stap voor stap integreren had volstaan. De integratie was nauwelijks klaar toen een leidinggevende die we nooit zagen ons kwam vertellen dat het project werd geannuleerd: de markt had geen interesse in wat we maakten. Terwijl er nooit iets in productie was gegaan: de software was nooit aan de gebruikers voorgelegd. Collega’s zeiden toen tevreden tegen me: “We worden beter: vroeger hadden we zes jaar nodig om tot deze conclusie te komen, nu nog maar twee.” Een ontwikkelaar uit mijn team vertrouwde me ook toe: “Ik zit hier nu vijf jaar, en niets van waar ik aan gewerkt heb, is ooit in productie gegaan.” Toen dacht ik: nee, ik blijf hier niet.

Later, bij een andere opdracht, kwam het team elke week bijeen voor een retrospective, zoals Scrum voorschrijft, om te kijken hoe de processen van de organisatie beter konden. Ik werd om mijn voorstellen gevraagd, en het antwoord was: “Zo werken we nu al vijf jaar, en we gaan niet veranderen.” Op dat moment besef ik dat hier iets hypocriets aan zit. Ik snap niet wat ik hier doe. Mijn opmerkingen worden van tafel geveegd, en uiteindelijk word ik aan de kant gezet, nadat me te verstaan is gegeven dat ik niet in de interne processen van het team pas. Wie vandaag als zzp’er bij een klant in het team zit, wordt behandeld als een werknemer en belandt in schijnzelfstandigheid. Na die ervaring besloot ik de koe bij de hoorns te vatten en me te bekwamen in wat ik nog miste om te begrijpen hoe agile werken toepasbaar is op de ontwikkeling van maatwerksoftware, om eindelijk mijn projecten van begin tot eind zelf te kunnen dragen.

En het werd tijd: met deze aanpak had ik al resultaten geboekt. In 2024 had een applicatie na drie maanden ontwikkeling 600 gebruikers. Ik had de oprichter laten inzien dat het niet gaat om de functies die hij in zijn hoofd heeft, maar om zijn gebruikers te interviewen, alleen te bouwen waar zij om vragen, en nieuwe functies stap voor stap op te leveren, in een continue stroom. Datzelfde jaar konden we bij een ander project, omdat we allemaal dezelfde aanpak deelden, de applicatie na zes maanden ontwikkeling aan 30 bètatesters voorleggen.

Sinds 2019 keek ik op YouTube naar de lezingen van Frédéric Leguédois over agile werken. In 2026 had ik het geluk dat hij me zelf opleidde in adaptief projectmanagement: kosten en kwaliteit vastleggen, en de klant de scope laten bepalen. Daarmee had ik eindelijk antwoord op mijn budgetvraag: het budget is wat een bedrijf wil investeren om zijn software te bouwen en door te ontwikkelen, afgewogen tegen wat het onopgeloste probleem kost. Een deel van deze methoden paste ik al toe; de training gaf me het volledige kader. Op die basis heb ik het aanbod van DEVEDANOS opgezet.

Daarom koos ik, in plaats van schattingen en vaste planningen, voor een andere standaard: een adaptieve aanpak met continuous delivery. Ik wil dat meer bedrijven daar baat bij hebben: projecten die slagen, geld dat goed besteed wordt, teams die niet voortdurend brandjes blussen, ontwikkelaars die hun gezondheid niet langer opofferen, en dat we allemaal voldoening en trots halen uit goed werk.

Dat betekent softwarekwaliteit, beveiliging inbegrepen. Omdat schattingen nooit worden gehaald, dwingt dit model tot opnieuw onderhandelen over het budget of minder opleveren, vaak allebei. Lijkt een schatting toch gehaald, dan zat het mee. Zelfs met een marge worden deadlines alleen gehaald door ongemerkt kwaliteit en beveiliging op te offeren. En een functionaliteit die zo is opgeleverd, pas je niet meer aan: ze blijft zoals ze is, en als te veel functionaliteiten zo zijn opgeleverd, moet de software opnieuw worden gebouwd. Dat kost veel geld. De kwaliteit krijgt de eerste klap: hoe makkelijk de software aan te passen blijft, en hoe veilig ze is. Er blijft dan geen budget over om experts in te schakelen, en geen tijd voor ontwikkelaars, die geen beveiligingsonderzoekers zijn, om beveiliging in hun eigen werk goed aan te pakken. De standaard die DEVEDANOS op elk project toepast, doet geen enkele concessie aan kwaliteit en beveiliging: het is een vast onderdeel van onze deliverypipeline, bij elke wijziging aan uw software.

Stelt u zich een bouwplaats voor die wordt geleid als een softwareproject. De loodgieter legt zijn leidingen, daarna metselt de metselaar de muur dicht. Dan komt de elektricien: “O nee, daar moeten mijn kabels ook nog doorheen.” De metselaar breekt de muur weer open, en misschien moet de loodgieter terugkomen. In software gaat het vaak zo. Het is normaal geworden, en niemand wil zien hoe absurd het is. In dit vak zitten velen vast in een systeem waarin je je mond moet houden en niet moet opvallen, anders lig je eruit. Uit lijfsbehoud, omdat hun hele inkomen ervan afhangt, zwijgen ze. Anders zijn en vragen stellen wordt je niet in dank afgenomen. Ik heb besloten nooit meer een voet te zetten in zulke organisaties, voor mijn mentale gezondheid en om geen slechte ontwikkelgewoonten over te nemen.

Uit liefde voor goed werk neem ik nu alleen nog projecten van begin tot eind aan. Want ik wil dat elke euro, elke inspanning en elk uur dat in mijn werk gaat zo snel mogelijk een resultaat oplevert, een resultaat dat blijft en waar mijn klanten en ik trots op zijn.

Een functionaliteit gaat in productie zodra die is goedgekeurd.

Een vast budget voor de ontwikkeling van uw applicatie en het blijvend afstemmen ervan op de veranderingen in uw bedrijf, zo lang als u wilt, maandelijks gefactureerd voor het werk van die maand. U bepaalt de scope, naarmate de omstandigheden veranderen.

Die rust op twee dingen. Echte agility, de adaptieve aanpak: het product afstemmen op wat de gebruikers nodig hebben en hen centraal houden. En continuous delivery (Farley, Humble): code van hoge kwaliteit die makkelijk te veranderen is. Het een kan niet zonder het ander. De beste ideeën zijn niets waard als de code moeilijk te veranderen is: dat is een coureur achter het stuur van een tuktuk. En uitstekende code is niets waard als je je gebruikers niet begrijpt: dat is een Ferrari in handen van iemand die nooit iets anders dan een tuktuk heeft bestuurd. Onze Aanpak-pagina legt de werking uit.