Veel overheidsorganisaties worstelen met deze uitdagingen. Softwareprojecten bij de overheid worden uitgevoerd binnen een bepaald kader, wat ze vaak complex maken. De projecten vragen samenwerking tussen verschillende leveranciers en interne teams, terwijl ze tegelijk onderworpen zijn aan aanbestedingswetgeving, budgettaire beperkingen en strikte deadlines.
In zo’n context is het essentieel om op een manier te werken die voorspelbaarheid combineert met wendbaarheid. In dit artikel beschrijven we drie elementen die je kan toepassen om weer controle te krijgen.
Softwareprojecten lopen vaak vast door gebrek aan overzicht. Veel projecten beginnen met een uitgebreide lijst van requirements zonder prioritering. Hierdoor wordt het moeilijk om te bepalen wat essentieel is voor een snelle eerste oplevering. Het gevolg is dat alles als prioritair wordt beschouwd, waardoor teams hun focus verliezen en er uiteindelijk niets wordt opgeleverd dat end‑to‑end echt bruikbaar is.
Hierbij is het essentieel om de mindset te richten op de ontwikkeling van een Minimum Viable Product (MVP). Helaas heeft een MVP vaak een slechte connotatie, maar het is zeker geen uitgeklede versie van het eindproduct. Het is een eerste bruikbare versie die waarde levert en nieuwe inzichten brengt. MVP-denken zorgt ervoor dat:
Om een succesvolle MVP-mindset om te zetten in praktische uitvoering, kan je gebruikmaken van storymapping. Het is een visuele methode om het hele project overzichtelijk te maken: welke functionaliteiten zijn nodig, hoe hangen ze samen en wat is de volgorde van ontwikkeling.
Het helpt teams om te denken in termen van:
De storymap fungeert als een kompas dat richting geeft tijdens het hele project.
Nu je zichtbaarheid hebt gecreëerd over je project, kan je story points gebruiken om ook effectief controle over oplevering en budget te bewaken. Tijdens het project groeit de backlog door nieuwe inzichten en feedback. Door story points toe te kennen aan taken:
Binnen de overheid werk je bijna altijd met gemengde teams: interne medewerkers, meerdere IT-leveranciers, externe experts, business stakeholders, enzovoort. Een geïntegreerd team dat ownership kan nemen is hierbij essentieel.
Cruciaal in een geïntegreerd team is dat je de businessexperten mee betrekt in de dagelijkse projectwerking. Domeinexperten kennen de processen, regels en uitzonderingen door en door. Dat zorgt voor snellere feedbackloops, betere validatie en een algemeen hogere kwaliteit. Omgekeerd kunnen functioneel analisten businessexperten uitdagen om te kiezen voor een minder complexe oplossing.
Een sterke manier om geïntegreerd te werken en commitment vanuit je team op te bouwen, is via een gezamenlijke planningsworkshop.
Tijdens een gezamenlijke planning voor ongeveer vier sprints van twee weken breng je alle teams samen om te bepalen wat de doelstellingen zijn voor de komende periode. Iedereen – van business tot functioneel analisten, developers en projectmanagers – moet hierbij betrokken worden.
Elk team werkt zijn eigen plan uit en concretiseert:
Door deze manier van werken is het voor elk teamlid duidelijk wat de verwachtingen zijn. Dit zorgt voor een hogere bereidheid om de opgestelde planning te halen en zelfs te overtreffen.
Demo’s worden in een agile werking vaak gezien als een formaliteit waar simpelweg wat nieuwe schermen getoond worden. Maar als je een demo ten gronde neemt, kan het dienen als een tool om de kwaliteit te verhogen en vertrouwen te bouwen in de voortgang van het project.
Een goede demo toont voortgang, zorgt voor alignment, geeft richting en versterkt vertrouwen. Hierbij geven we drie tips om je demo’s succesvoller te maken:
In een demo gaat het om gebruikers die hun werk beter willen doen. Persona’s helpen om de demo tastbaar te maken. Een persona is een korte beschrijving van een type gebruiker.
Bijvoorbeeld: Sarah, dossierbeheerder, werkt dagelijks met tien verschillende systemen. Haar grootste frustratie is dubbele ingave.
Persona’s geven de demo een narratief in plaats van een technische rondleiding: “We tonen vandaag hoe Sarah, onze dossierbeheerder, voor het eerst een dossier kan openen zonder dubbele ingave.”
Dit maakt de demo concreet en begrijpelijk. Je legt functionaliteit uit in mensentaal, niet in IT-termen, en je toont alleen datgene wat waarde heeft voor die gebruiker.
Gebruik het demomoment om actief vragen te stellen:
Wanneer stakeholders zien dat hun opmerkingen worden opgenomen in de backlog en effectief worden gerealiseerd, groeit hun betrokkenheid en stijgt het vertrouwen in het team. Bovendien evolueert de toepassing zo steeds sneller richting wat de business écht nodig heeft.
Demo’s creëren een continue feedbacklus: je ontdekt niet pas op het einde van het project dat iets niet klopt, maar al vanaf de eerste sprint. Het is ook veel eenvoudiger om kleine, gerichte aanpassingen tijdig door te voeren, in plaats van na maanden ontwikkeling een grote herwerking te moeten doen omdat feedback te laat kwam.
Tijdens de demo benoem je dat ook best expliciet. Bijvoorbeeld: “In de vorige demo gaven jullie deze feedback. Op basis daarvan hebben we dit nu op deze manier aangepakt.” Door dat concreet te tonen, zien stakeholders dat hun input écht impact heeft.
"Deze projectaanpak hanteren we consistent overheen al onze projecten, zo zijn we er recent nog in geslaagd om op zes maanden een MVP op te leveren, waar de vorige dienstverlener al twee jaar aan het worstelen was om iets in productie te krijgen."
Fabio Mouro - Program Manager