Succesvolle softwareontwikkeling binnen de overheid door zichtbaarheid, samenwerking en wendbaarheid

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.

1. Breng projectnoden en prioriteiten in kaart met storymapping

2. Bouw een geïntegreerd team en creëer commitment bottom-up

3. Gebruik demo’s als een bouwsteen voor vertrouwen

Breng projectnoden en prioriteiten in kaart met storymapping

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:

• teams niet werken aan hypothetische behoeften;
• budget wordt ingezet op onmiddelijke waarde;
• de organisatie sneller kan bijsturen.

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:

• Horizontale flows (end-to-end): De end-to-end stappen die de gebruiker doorloopt om zijn doel te bereiken.
• Verticale slices: kleine, volledig werkende functionaliteitsblokken die getest en bruikbaar zijn.

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:

• ontstaat transparantie over de voortgang;
• kan het budget beter worden ingeschat;
• kunnen objectieve discussies over prioriteiten plaatsvinden.

Bouw een geïntegreerd team en creëer commitment bottom-up

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:

• Teamcapaciteit: Beschrijf je team en wie allemaal in je team zit tijdens de komende sprints. Maak een berekening van het totaal aantal story points dat je beschikbaar hebt.
• Doelstellingen: In samenwerking met de businessexperten en analisten bespreek je welke voortgang je wil maken.
• Uitdagende doelstellingen: Waar je bij de doelstellingen beschrijft wat haalbaar is, vul je bij de uitdagende doelstellingen ambitieuzere doelen aan. Tijdens een sprint kan tijd vrijkomen en wil je hierop voorbereid zijn.
• Risico’s: Breng de risico’s in kaart zodat je een plan kan maken om ze te beperken.
• Afhankelijkheden: Welke afhankelijkheden kan je tegenkomen tijdens het uitvoeren van taken en wie moet je hierbij betrekken?

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.

Gebruik demo’s als een bouwsteen voor vertrouwen

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:

Tip 1: Werk met persona’s 

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.

Tip 2: Vraag actief naar feedback 

Gebruik het demomoment om actief vragen te stellen:

• Wat viel je het meest op in deze demo?
• Wat ontbreekt er volgens jou om deze functionaliteit bruikbaar te maken in de praktijk?
• Was er iets dat verwarrend of niet duidelijk overkwam?
• Sluit wat je zag aan bij hoe jullie vandaag werken? Waarom (niet)?
• Wat moet voor jou absoluut meegenomen worden naar de volgende versie of demo?

Tip 3: Verwerk feedback altijd tegen de volgende demo 

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