Agile werken ontmoet AI: Waarom traditionele methoden falen bij automatisering

Afgelopen week werd ik bijna gek.

Mijn klant wilde koste wat het kost zijn AI-project in 2-wekelijkse sprints gieten.

Dat hebben we bij de app-ontwikkeling ook zo gedaan, zei hij.

Ik moest hem uitleggen: AI is geen softwareontwikkeling.

Na drie mislukte sprints en een gefrustreerd ontwikkelteam hebben we het roer volledig omgegooid.

Het resultaat: In 6 weken meer vooruitgang dan in de 3 maanden ervoor.

Vandaag laat ik je zien waarom klassieke agile-methodes falen bij AI-projecten – en welke werkwijzen echt werken.

Waarom Scrum en Kanban falen bij AI-projecten

Scrum is bedacht voor softwareontwikkeling.

AI kent compleet andere wetten.

Dit negeren is de meest gemaakte fout die ik bij klanten zie.

Het sprint-probleem: AI ontwikkelt zich niet lineair

Een sprint duurt 2 weken.

Een machine learning model heeft soms 3 weken nodig voordat het bruikbare resultaten oplevert.

Wat doe je in week 1 en 2? We trainen nog presenteren als sprintresultaat?

Ik heb het zelf meegemaakt.

Een ontwikkelteam leverde 6 sprints lang nauwelijks iets toonbaars op – hoewel ze uitstekend werk leverden.

Het probleem: AI-ontwikkeling heeft een eigen tijdsritme.

Soms kost data-preparatie 4 weken, en werkt het eerste model daarna direct perfect.

Soms train je 50 verschillende modellen voordat er één aanslaat.

Dat past niet in een schema van 2 weken.

Backlog-chaos: Als algoritmes de prioriteit bepalen

Een product backlog werkt goed voor functionaliteiten.

Bij AI veranderen de prioriteiten door nieuwe inzichten tijdens het werk.

Een voorbeeld uit mijn praktijk:

We wilden een sentiment-analysetool ontwikkelen voor klantfeedback.

Er waren 5 functies gepland:

  1. Positief/Negatief classificatie
  2. Emotieherkenning
  3. Thema-extractie
  4. Trend-analyse
  5. Dashboard

Na de eerste data-exploratie bleek dat 60% van onze data onbruikbaar was.

Opeens stond datacleaning met stip op 1.

Dat stond nergens in de backlog.

Bij AI-projecten bepaalt de data vaak de volgende stap – niet de product owner.

Daily standups worden weekly standups (en dat is prima)

Wat heb je gisteren gedaan?

Hyperparameters geoptimaliseerd.

Waar werk je vandaag aan?

Hyperparameters geoptimaliseerd.

Blokkades?

De training loopt nog 12 uur.

Zo zien daily standups bij AI-teams eruit.

Onzinnig.

AI-ontwikkeltrajecten kennen lange feedbackloops.

Een model trainen duurt soms dagen.

Een A/B-test heeft statistische significantie nodig – meestal weken.

Dagelijkse afstemming heeft geen zin als er dagelijks niets wezenlijks verandert.

De drie fundamentele verschillen tussen software- en AI-ontwikkeling

Softwareontwikkeling: Je weet wat je bouwt.

AI-ontwikkeling: Je weet wat je probeert.

Dat is het fundamentele verschil.

Onvoorspelbaarheid in plaats van planmatigheid

Bij software schrijf je code: het werkt of het werkt niet.

Bij AI train je een model, het behaalt 73% – en je weet niet waarom.

Niet door slechte code.

Maar door onverwachte data-issues of modelperformance.

Je kunt niet plannen wanneer een model de gewenste nauwkeurigheid haalt.

Je kunt alleen experimenteren en itereren.

Dat maakt klassieke projectplanning onmogelijk.

Experimenteel versus lineair ontwikkelproces

Software volgt een lineair proces:

Requirements → Design → Implementation → Testing → Deployment

AI-ontwikkeling is een experimentele cyclus:

Hypothese → Experiment → Evaluatie → Learnings → nieuwe hypothese

80% van mijn tijd in AI-projecten gaat op aan experimenten die niet werken.

Dat is normaal.

En zelfs waardevol.

Elk mislukt experiment brengt je dichter bij de oplossing.

Bij software zou 80% ‘mislukte code’ onacceptabel zijn.

Bij AI is dat de weg naar succes.

Data als kritische succesfactor

Software werkt prima met gesimuleerde testdata.

AI staat of valt met echte, kwalitatieve data.

Ik heb projecten meegemaakt waar het team 6 maanden perfecte code schreef…

En het model nog steeds waardeloos was.

Omdat de data niet deugde.

Bij AI-projecten besteed je 60–80% van je tijd aan datawerk:

  • Data verzamelen
  • Data schonen
  • Data labelen
  • Data valideren
  • Data pipelines bouwen

Dat komt in geen enkel software-sprintplan voor.

Maar zonder werkt AI niet.

AI-first werkmethodes: Wat na Scrum komt

Ik werk al 3 jaar met uiteenlopende aanpakken voor AI-teams.

Dit werkt echt.

Hypothesis-driven development in plaats van user stories

Vergeet user stories.

Als gebruiker wil ik… werkt niet voor AI.

In plaats daarvan: hypothesis-driven development.

Elke ontwikkelfase begint met een meetbare hypothese:

Als we feature X toevoegen, stijgt de nauwkeurigheid van ons model met minimaal 5%.

Of:

Als we algoritme Y gebruiken, halveert de traingstijd.

Elke hypothese bevat:

  • Een meetbare metric
  • Een streefwaarde
  • Een tijdsinschatting voor het experiment
  • Criteria voor succes/mislukking

Zo wordt We optimaliseren het model een concreet experiment met een helder resultaat.

Continuous experimentation als kernproces

Bij software ontwikkel je features.

Bij AI voer je experimenten uit.

Het belangrijkste proces is niet sprint plannning, maar experiment design.

Onze standaard experiment-workflow:

  1. Hypotheseformulering (1 dag)
  2. Experiment setup (2-3 dagen)
  3. Uitvoering (variabel: 1 dag tot 2 weken)
  4. Evaluatie (1-2 dagen)
  5. Beslissing (doorgaan/stoppen/pivot)

Belangrijk: Elk experiment wordt vastgelegd.

Ook de mislukte.

Vooral de mislukte.

We houden een experimentlogboek bij met:

  • Hypothese
  • Aanpak
  • Resultaat
  • Learnings
  • Next steps

Dat wordt de meest waardevolle kennisbron van het team.

Data-centric workflows voor AI-teams

Softwareteams organiseren zich rond functionaliteiten.

AI-teams moeten zich rond data organiseren.

Onze workflow volgt niet een kanban-board, maar een datapipeline:

Fase Verantwoordelijk Output Kwaliteitscriterium
Data Collection Data Engineer Ruwe dataset Volledigheid, actualiteit
Data Cleaning Data Scientist Opgeschoonde dataset <5% missende waarden
Feature Engineering ML Engineer Feature set Correlatie met target
Model Training Data Scientist Getraind model Streef-nauwkeurigheid behaald
Model Deployment ML Engineer Productiemodel Latency < 200ms

Elke fase heeft duidelijke overdrachtscriteria.

Niet klaar zonder meetbare kwaliteit.

Concreet werken in AI-gedreven teams in de praktijk

Genoeg theorie.

Dit zijn de werkwijzen die ik dagelijks toepas.

De 3-fasenmethode voor AI-projecten

Ik verdeel elk AI-project in 3 fasen:

Fase 1: Discovery (25% van de tijd)

Doel: Begrijpen wat mogelijk is.

Activiteiten:

  • Data-exploratie
  • Proof of concept
  • Haalbaarheidsanalyse
  • Eerste baseline-modellen

Succesfactor: Is het probleem met AI op te lossen?

Fase 2: Development (60% van de tijd)

Doel: Het beste model bouwen.

Activiteiten:

  • Iteratief modelverbeteren
  • Feature engineering
  • Hyperparameter optimalisatie
  • Cross-validation

Succescriterium: Doel-nauwkeurigheid behaald.

Fase 3: Deployment (15% van de tijd)

Doel: Model naar productie brengen.

Activiteiten:

  • Model packaging
  • API-ontwikkeling
  • Monitoring setup
  • A/B-testing

Succesfactor: Model draait stabiel in productie.

Belangrijk: De fasen zijn niet lineair.

Je springt heen en weer tussen discovery en development.

Dat is normaal.

Agile data science: Sprints anders ingevuld

We gebruiken nog steeds sprints – maar anders.

Onze AI-sprints duren 3–4 weken (geen 2).

Elke sprint heeft een experimenteel doel, geen feature-doel.

Sprintplanning verloopt zo:

  1. Experiment-review: Wat hebben we vorige sprint geleerd?
  2. Hypothese-prioritering: Welke experimenten zijn het meest kansrijk?
  3. Resource-allocatie: Wie werkt aan welk experiment?
  4. Succescriteria: Hoe meten we succes?

Sprint review toont geen features, maar inzichten:

  • Welke hypotheses zijn bevestigd/ontkracht?
  • Welke nieuwe inzichten zijn opgedaan?
  • Hoe is de modelperformance veranderd?
  • Wat zijn de volgende logische experimenten?

Cross-functionele AI-teams goed organiseren

Een AI-team heeft andere rollen nodig dan een softwareteam.

Onze standaardbezetting voor een AI-project:

Rol Hoofdtaak Skills % van de tijd
Data Scientist Modelontwikkeling ML, Statistiek, Python 40%
Data Engineer Data-pipeline ETL, Databases, Cloud 30%
ML Engineer Model deployment DevOps, APIs, Schaalbaarheid 20%
Product Manager Business alignment Domeinkennis, Strategie 10%

Belangrijk: De product manager is NIET de scrum master.

Hij of zij definieert bedrijfsdoelen, geen sprintdoelen.

De prioritering van experimenten doet het hele team samen.

Toolstack en processen: Wat werkt echt

AI-teams gebruiken andere tools dan softwareteams.

Dit is onze bewezen stack.

Projectmanagementtools voor AI-teams

Jira is prima voor software.

Voor AI gebruiken we een combinatie:

Experimenttracking: MLflow

  • Alle experimenten worden automatisch gelogd
  • Parameters, metrics, artefacten in één overzicht
  • Vergelijk verschillende modelversies

Taskmanagement: Notion

  • Hypothese backlog
  • Experimentdocumentatie
  • Team learnings
  • Data quality dashboards

Communicatie: Slack + dagelijkse data reports

  • Automatische rapporten over modelperformance
  • Alerts bij datakwaliteitsproblemen
  • Kanaal voor elk lopend experiment

Het belangrijkste tool blijft een gedeeld experimentlogboek.

We documenteren IEDER experiment – geslaagd of niet.

Versiebeheer van modellen en data

Code versieer je met Git.

Maar hoe doe je dat met modellen en data?

Onze aanpak:

Data versioning: DVC (Data Version Control)

  • Elke dataset heeft een versienummer
  • Reproduceerbare datapipelines
  • Automatische data lineage tracking

Modelversioning: MLflow Model Registry

  • Ieder model krijgt automatisch een versie
  • Staging/production-omgevingen
  • Rollback-mogelijkheid bij prestatieverlies

Codeversioning: Git + pre-commit hooks

  • Automatische code quality checks
  • Experimentmetadata wordt automatisch gecommit
  • Jupyter Notebooks worden voor commit opgeschoond

Zonder versiebeheer is AI-ontwikkeling niet reproduceerbaar.

En niet reproduceerbaar betekent niet debugbaar.

Testing en deployment in AI-omgevingen

Unit-tests voor AI-code zijn anders dan voor gewone software.

Je test niet alleen functies, maar ook datakwaliteit en modelperformance.

Ons testframework:

Data Quality Tests

  • Schema validatie (zijn alle kolommen aanwezig?)
  • Data actualiteit (zijn de data up-to-date?)
  • Statistische tests (is de dataverdeling verandert?)
  • Completeness checks (hoeveel missende waarden?)

Model performance tests

  • Nauwkeurigheidsdrempels
  • Latentie-tests
  • Geheugengebruik-tests
  • Bias-detectie-tests

Integratietests

  • End-to-end pipeline testen
  • API-responsetijd testen
  • Load-tests

Deployment loopt via blue-green deployment met automatische rollback.

Als de modelprestatie meer dan 5% inzakt, wordt er automatisch teruggeschakeld naar de vorige versie.

Veelgemaakte fouten bij de overgang naar AI-gedreven werkwijzen

Ik zie bij vrijwel elke klant dezelfde missers terugkomen.

Dit zijn de meest voorkomende – en zo voorkom je ze.

De Scrum Master wordt AI Product Owner

Klassieke fout:

Het bedrijf wil agile blijven en schuift de scrum master door als AI product owner.

Probleem: Een scrum master snapt processen, maar geen data science.

Hij of zij kan geen experimenten prioriteren omdat hij de haalbaarheid niet goed kan inschatten.

De oplossing: De AI product owner moet een technische achtergrond hebben.

Hij/zij moet begrijpen:

  • Hoe machine learning werkt
  • Wat datakwaliteit betekent
  • Hoe lang modeltraining duurt
  • Welke metrics ertoe doen

Bij ons is de AI product owner altijd een data scientist of ML engineer met businessinzicht.

Nooit een pure projectmanager.

Waarom een klassieke Definition of Done niet werkt

Software: Feature werkt zoals gespecificeerd = done.

AI: Model behaalt 85% nauwkeurigheid = klaar.

Maar wat als het model maar 84% haalt?

Is het dan niet klaar?

Een klassieke Definition of Done leidt bij AI tot eindeloze optimalisatielussen.

Onze aanpak: probabilistische Definition of Done.

In plaats van Model moet 85% halen bepalen we:

Het model behaalt minstens 80% nauwkeurigheid en is beter dan de bestaande baseline.

Plus tijdslimiet:

Als na 4 weken optimaliseren geen significante verbetering optreedt, is het huidige model production-ready.

Dit voorkomt perfectionisme en maakt iteratieve verbetering in productie mogelijk.

Change management voor traditionele teams

Het moeilijkste is niet de techniek.

Het is het change management.

Softwareontwikkelaars zijn gewend aan deterministische systemen.

AI is probabilistisch.

Dat vraagt om een andere mindset.

Wat ik bij elke overgang toepas:

1. Verwachtingsmanagement

  • Open communicatie: 80% van de experimenten faalt
  • Dat is normaal en waardevol
  • Succes wordt anders gemeten

2. Pair programming voor AI

  • Ervaren data scientists werken samen met softwareontwikkelaars
  • Kennisoverdracht via code reviews
  • Samen experimenten plannen

3. Continu leren

  • Wekelijkse ML learning sessions
  • Casestudy’s van geslaagde experimenten
  • Post-mortems van mislukte aanpakken

De overgang duurt 3–6 maanden.

Houd daar rekening mee.

En vier kleine successen – ook de mislukte experimenten die waardevolle inzichten opleveren.

Veelgestelde vragen

Hoe lang duurt de overstap van Scrum naar AI-gedreven werkmethodes?

Uit mijn ervaring duurt de omschakeling 3–6 maanden. Het team moet nieuwe denkpatronen leren en processen opbouwen. Belangrijk is de overgang in stappen aanpakken en niet alles tegelijk omgooien.

Kun je Scrum en AI-ontwikkeling echt niet combineren?

Jawel, maar je moet Scrum flink aanpassen. Langere sprints (3–4 weken), doelen per experiment in plaats van features en flexibele tijdsplanning. Pure Scrum werkt niet bij AI-projecten.

Welke rollen zijn onmisbaar in een AI-team?

Minimaal: data scientist, data engineer en ML engineer. In kleinere teams kunnen rollen gecombineerd worden, maar alle gebieden moeten afgedekt zijn. Een product manager met AI-kennis is ook belangrijk.

Hoe meet je het succes van AI-experimenten?

Door vooraf gedefinieerde, meetbare metrics zoals nauwkeurigheid, precisie, recall of business-KPI’s. Belangrijk: ook mislukte experimenten zijn waardevol als ze learnings opleveren. We documenteren alle experimenten systematisch.

Wat zijn de grootste uitdagingen bij de overgang?

Change management is een grotere horde dan de techniek. Teams moeten leren omgaan met onzekerheid en probabilistisch denken in plaats van deterministisch. Daarnaast zijn nieuwe tools en versiebeheerstrategieën voor data en modellen vereist.

Welke tools zijn essentieel voor AI-teams?

MLflow voor experimenttracking, DVC voor dataversioning, een cloudprovider voor rekencapaciteit en een goed documentatieplatform zoals Notion. Alleen Git is niet genoeg – je hebt echt data science-specifieke tools nodig.

Hoe ga je om met de onvoorspelbaarheid van AI-projecten?

Met timeboxed experimenten en heldere go/no-go-criteria. Stel tijdslimieten voor optimalisatielussen en definieer minimale prestatie-eisen. Plan met marge en communiceer onzekerheid duidelijk naar stakeholders.

Werken klassieke projectmanagementtools voor AI-teams?

Slechts ten dele. Jira kan voor taken gebruikt worden, maar je hebt extra tools voor experimenttracking en data lineage nodig. Wij combineren verschillende gespecialiseerde tools.

Hoe organiseer je code reviews voor machine learning code?

ML-code reviews verschillen van reguliere code reviews. Je kijkt niet alleen naar codekwaliteit, maar ook naar experimentontwerp, datakwaliteit en modelvalidatie. Pair programming tussen ervaren data scientists en softwareontwikkelaars draagt bij aan kennisoverdracht.

Wat als een AI-project volledig faalt?

Dat komt in 15–20% van de projecten voor en is normaal. Het is belangrijk om tijdig te zien wanneer een aanpak niet werkt en direct bij te sturen. Documenteer alle inzichten – die zijn waardevol voor toekomstige projecten. Een mislukt project kan anderen juist voor dezelfde valkuil behoeden.

Related articles