Dit is mijn verhaal over hoe we bij Blis Digital naast onze klanten zitten als bijrijder. Niet om ja te knikken en uren te schrijven, maar om op de juiste momenten in te grijpen, te challengen en samen voor het beste resultaat te gaan.
Van PRINCE2 naar Agile
Mijn carrière als projectmanager begon in het tijdperk van PRINCE2. Een voordeel van die methodiek, grotendeels vergeten, is de absolute focus op de businesscase. Het motto: als je er geen geld mee verdient, moet je ermee stoppen.
Ook de helderheid over verantwoordelijkheden vond ik prettig: je weet altijd wie de budget-eigenaar is, wie de gebruikers vertegenwoordigt en wie welke waarde moet leveren.
Daarna maakte ik de verschuiving naar Agile (Scrum) mee. Agile draait om snel waarde creëren en iteratief naar een goed product toewerken. Krachtig, maar zeker geen silver bullet. Bij grote organisaties zag ik dat teams al snel vervielen in een tweewekelijks ritme, zonder nog te weten waarom ze dat eigenlijk deden.
De valkuil van ‘oneindige’ budgetten
In veel Agile-trajecten voelt het budget in het begin als een onuitputtelijke bron. Daardoor worden iteraties uitgevoerd die achteraf weinig waarde leveren. De verzuchting “daar hadden we kritischer naar moeten kijken” komt je dan bekend voor.
Zelfs als de product owner gewaarschuwd wordt dat een bepaalde richting onhandig is en eerst de MVP prioriteit moet krijgen, sluipt er toch de neiging in om features nét mooier, completer of uitgebreider te maken. Het gevolg: aan het einde van het project, wanneer het geld bijna op is, kan er ineens veel minder dan gedacht.
Een onderliggend probleem is dat tijdens het traject niet altijd duidelijk is wie precies eigenaar is van het budget. In de praktijk bemoeit een lijnmanager zich soms ineens met de uitkomst, waardoor de product owner wordt gepasseerd. Dat leidt tot onduidelijkheid, vertraging en keuzes die niet meer in lijn liggen met de oorspronkelijke visie.
Frameworks worden soms gepresenteerd als dé oplossing voor elk projectvraagstuk. In de praktijk ligt dat veel genuanceerder. Er bestaat geen methode die altijd en overal werkt.
Wat wél altijd werkt? Boerenverstand.
Je boerenverstand en je MVP
Ik kom van Goeree-Overflakkee, en daar zit ‘boerenverstand’ in de volksaard. Flakkeese boeren zijn ‘zuunig’: ze vragen zich altijd af of iets echt nodig is en of de investering het waard is. Datzelfde zit in mijn visie op softwareontwikkeling. Ik stel altijd die ene vraag: waarom doen we dit eigenlijk? En het antwoord moet altijd te maken hebben met waarde voor de gebruiker.
Die gebruiker ziet namelijk maar één ding: wat er vandaag live staat, niet wat er gepland staat, niet wat er op de roadmap staat, niet wat er “binnenkort komt”. Een gebruiker wil kunnen werken. Punt. En die heeft gelijk: na een ‘eerste versie’ is het budget vaak op, of de prioriteit verschoven.
Daarom moet een MVP écht een Minimum Viable Product zijn: niet het minimale excuus om live te gaan, maar een volwaardig werkend product dat voldoet aan de functionele eisen én aan de eisen voor performance, beschikbaarheid en veiligheid.
Daar kom je alleen door te durven schrappen. Veel schrappen. Dat is lastig, zeker met veel stakeholders. Maar precies daar komt boerenverstand om de hoek kijken: keuzes durven maken en vooral keuzes durven laten.
De rol van de product owner
In theorie ligt dit volledig bij de product owner: die bepaalt prioriteit, die beheert de backlog, die verdeelt het budget. Maar in de praktijk is dat een zware verantwoordelijkheid voor één persoon. Zeker als iemand min of meer “tot PO is gebombardeerd” zonder ervaring met complexe trajecten.
Daar komt nog iets bij: vaak ontbreekt het mandaat. Dan heb je officieel een product owner, maar feitelijk ligt de beslissingsbevoegdheid bij een lijnmanager of budgethouder die veel later in het proces ingrijpt.
We hebben dit meerdere keren meegemaakt. In één project hadden we het MVP samen met de PO scherp gemaakt, inclusief het schrappen van features, maar tijdens de implementatie bleek dat de PO intern helemaal geen mandaat had om zulke beslissingen te nemen. Gevolg: vertraging, onrust, extra werk.
Daarom zijn duidelijke verantwoordelijkheden en mandaat cruciaal, maar in veel organisaties nog verre van vanzelfsprekend.
Het concept ‘bijrijder’ in actie
Binnen die dynamiek speelt Blis Digital een belangrijke rol. We zijn geen leverancier die uitvoert wat er gevraagd wordt, maar een bijrijder die meedenkt, tegengas geeft en de juiste vragen stelt.
Onze kracht is het herkennen van doodlopende wegen, onnodige complexiteit en keuzes die te veel kosten opleveren voor te weinig waarde. Daarom denken we niet alleen mee over het product, maar ook over de portemonnee van de klant.
Bij elke requirement stellen we twee simpele vragen:
- Is dit echt nodig?
- Is dit de meest efficiënte oplossing?
Soms is iets technisch prachtig maar praktisch gezien een slecht idee. Dan kies je beter voor een eenvoudig alternatief, bijvoorbeeld een tijdelijke handmatige actie in de backoffice, zodat eindgebruikers wél op tijd waarde krijgen.
Dat is niet beknibbelen, dat is boerenverstand.
‘Bedankt voor het testen, maar we fixen het niet’
Ook bij testen moet je goed afwegen wat écht belangrijk is. Onze testers kunnen bijna elke applicatie laten crashen, dat is hun vak, maar dat betekent niet dat elke gevonden bug automatisch gerepareerd moet worden. Fixes kosten tijd en geld, en vragen altijd aandacht van het team. Soms is het slimmer om een klein risico te accepteren.
We hadden bijvoorbeeld een feature waarbij de app crashte als iemand extreem snel op een toggle switch tikte. Natuurlijk konden we dat oplossen, en dat hebben we ook gedaan, maar achteraf bleek het over-engineered. We hadden beter kunnen zeggen: hoe vaak gebeurt dit nou echt? En als het gebeurt: een gebruiker kan een app prima opnieuw opstarten.
Boerenverstand dus.
Niet alles fixen omdat het kan, maar fixen wat ertoe doet.
Pragmatisme bij multi-tenant toepassingen
Nog een voorbeeld. Wij werken veel aan multi-tenant applicaties. Dat brengt extra complexiteit met zich mee: features moeten naar meerdere tenants worden uitgerold en integraties vaak per tenant geconfigureerd.
Vanuit MVP-perspectief moet je daarmee slim omgaan. Misschien hoeft een nieuwe feature niet direct naar elke tenant. Misschien kun je tijdelijk één API-sleutel delen zodat de feature snel live kan en direct waarde oplevert.
In één project bespaarde dit pragmatisme meerdere dagen werk en konden we, op uitdrukkelijke wens van de klant, de feature nog net vóór Pasen live zetten in plaats van pas weken later.
Dát levert voorsprong op. En dat creëert waarde.
Waarin we geen concessies doen
Verwar deze aanpak niet met slordigheid. Boerenverstand betekent níét dat we dingen half doen of technische schulden negeren. Integendeel: bepaalde principes zijn heilig.
Security is er één van. Alles wat we bouwen voldoet aan strenge veiligheidseisen, daar bezuinigen we niet op. Daarnaast lossen we technische schuld consequent en snel af. Refactoring staat prominent op de backlog, juist omdat tech debt op de lange termijn innovatie afremt en zelfs stabiliteit en veiligheid in gevaar brengt.
Onze bijrijdersrol betekent ook: duidelijke grenzen stellen. Als wij weten dat iets schadelijk is voor de business van de klant, trekken we aan de noodrem.
Dat is geen koppigheid.
Dat is verantwoordelijkheid.
Af en toe uitzoomen – en wat het betekent om ‘AI-first’ te zijn
Blis Digital is geen detacheerder en geen ‘urenfabriek’. Nu we AI-first werken, wordt dat alleen maar duidelijker. Uren worden minder relevant, omdat AI veel uitvoerend werk overneemt en wij ons volledig kunnen richten op de rol die het verschil maakt: die van bijrijder.
Bij fixed-price projecten delen we het budgetrisico met de opdrachtgever. Dat maakt verantwoordelijkheid helder: als wij verkeerde keuzes toestaan, kost het ons allemaal tijd én geld. Daarom is invloed op strategie, backlog, kwaliteit en beslissingen geen luxe, maar noodzaak.
Dat vatten we samen in twee woorden: own it.
Niet “hun project”, maar “ons project”.
Dat betekent: goed voorbereid zijn. Afspraken nakomen. Op tijd hulp vragen. Eerlijk aangeven wanneer iets niet haalbaar is. En continu zoeken naar manieren om sneller en slimmer te werken. AI hoort daar vanzelfsprekend bij.
En ook dat is boerenverstand: af en toe uitzoomen en eerlijk kijken of je nog steeds de juiste dingen doet, op de juiste manier.
Kop koffie?
Benieuwd wat ‘boerenverstand’ voor jouw project kan betekenen? Laten we eens sparren over jouw uitdaging en kijken waar het slimmer, eenvoudiger of sneller kan. Stuur me een bericht (a.vandervelde@blisdigital.com), dan drinken we binnenkort een kop koffie.
.jpg)
