Agil arbejdsmetode møder AI: Hvorfor klassiske metoder fejler i automatiseringen

Hvorfor Scrum og Kanban fejler i KI-projekter

Scrum blev opfundet til softwareudvikling.

KI følger andre spilleregler.

At ignorere det er den hyppigste fejl, jeg ser hos mine kunder.

Sprint-problemet: KI udvikler sig ikke lineært

En sprint varer 2 uger.

Et machine learning-model kan tage 3 uger, før det giver brugbare resultater.

Hvad laver du i uge 1 og 2? Skal Vi træner stadig præsenteres som sprint-resultat?

Jeg har oplevet det selv.

Et udviklingsteam producerede nærmest intet synligt i 6 sprints – selv om de lavede fremragende arbejde.

Problemet: KI-udvikling har andre tidsrytmer.

Nogle gange tager databehandlingen 4 uger, og første model fungerer derefter perfekt.

Nogle gange træner du 50 forskellige approaches, før én lykkes.

Det passer ikke ind i 2-ugers rytmer.

Backlog-kaos: Når algoritmer ændrer prioriteterne

Product backlog fungerer til features.

I KI ændres prioriteringerne løbende, som man får ny indsigt.

Eksempel fra min praksis:

Vi ville bygge et sentimentanalyse-værktøj til kundefeedback.

Planen var 5 features:

1. Positiv/negativ klassificering
2. Emotion-genkendelse
3. Udtræk af emner
4. Trend-analyse
5. Dashboard

Efter første data exploration viste det sig: 60% af vores data var ubrugelige.

Pludselig var datarensning topprioritet.

Det stod ikke i backloggen.

I KI-projekter styrer dataene ofte næste skridt – ikke product owneren.

Daglige standups bliver til ugentlige standups (og det er helt okay)

Hvad lavede du i går?

Hyperparameterne blev optimeret.

Hvad laver du i dag?

Optimerer hyperparametre.

Er der blokeringer?

Træningen kører i 12 timer endnu.

Sådan lyder daglige standups i KI-teams.

Meningsløst.

KI-udvikling har længere feedback-loops.

At træne en model kan tage dage.

At analysere et A/B-test kræver statistisk signifikans – ofte uger.

Daglig synkronisering giver ikke mening, hvis der ikke sker noget væsentligt hver dag.

De tre fundamentale forskelle mellem software- og KI-udvikling

Softwareudvikling: Du ved, hvad du bygger.

KI-udvikling: Du ved, hvad du prøver af.

Det er selve forskellen.

Uforudsigelighed frem for planlægbarhed

Med software skriver du kode – det virker (eller ikke).

Med KI træner du en model, den virker 73% – og du ved ikke helt hvorfor.

Ikke pga. dårlig kode.

Men pga. uforudsete dataproblemer eller modelperformance.

Du kan ikke planlægge, hvornår en model opnår den ønskede nøjagtighed.

Du kan kun eksperimentere og iterere.

Det gør klassisk projektplanlægning umuligt.

Eksperimentel vs. lineær udviklingsproces

Softwareudvikling har en lineær proces:

Requirements → Design → Implementation → Testing → Deployment

KI-udvikling er et eksperimentelt loop:

Hypotese → Eksperiment → Evaluering → Læring → ny hypotese

80% af min tid i KI-projekter går med eksperimenter, der ikke virker.

Det er normalt.

Og det er faktisk godt.

Hvert mislykket eksperiment bringer dig tættere på løsningen.

Med software ville 80% fejlrate på kode være uacceptabel.

Med KI er det vejen til succes.

Datakvalitet som kritisk succesfaktor

Software virker med syntetiske testdata.

KI afhænger helt af ægte og høj-kvalitets data.

Jeg har set projekter, hvor teamet har skrevet perfekt kode i 6 måneder.

Modellen var stadig ubrugelig.

Fordi dataene var dårlige.

I KI-projekter bruger du 60-80% af tiden på dataarbejde:

• Indsamle data
• Rense data
• Labeling af data
• Validere data
• Bygge datapipelines

Det står ikke i en software-sprint-plan.

Men uden sker der intet i KI.

AI-first arbejdsmetoder: Hvad der følger efter Scrum

Jeg har arbejdet med forskellige tilgange for KI-teams i 3 år.

Her er hvad, der faktisk virker.

Hypothesis-driven Development frem for User Stories

Glem user stories.

Som bruger vil jeg gerne … virker ikke i KI.

Brug i stedet: Hypothesis-driven Development.

Hver udviklingsfase starter med en målbar hypotese:

Hvis vi tilføjer feature X, forbedres modelnøjagtigheden med mindst 5%.

Eller:

Hvis vi bruger algoritme Y, halveres træningstiden.

Hver hypotese har:

• En målbar metrik
• Et måltal
• Et tidsestimat for eksperimentet
• Kriterier for succes/fiasko

Så bliver Vi optimerer modellen til et konkret eksperiment med et klart resultat.

Continuous experimentation som kerneproces

I software bygger du features.

Med KI laver du eksperimenter.

Den vigtigste proces er ikke sprint planning, men eksperimentdesign.

Vores standard-eksperiment-workflow:

1. Hypotese-definition (1 dag)
2. Opsætning af eksperiment (2-3 dage)
3. Eksekvering (variabelt: 1 dag til 2 uger)
4. Evaluering (1-2 dage)
5. Beslutning (fortsætte, kassere eller pivot)

Vigtigt: Hvert eksperiment dokumenteres.

Også de mislykkede.

Især de mislykkede.

Vi kører en eksperimentlog med:

• Hypotese
• Fremgangsmåde
• Resultat
• Læringer
• Næste skridt

Det bliver til teamets mest værdifulde ressource.

Datacentrerede workflows for KI-teams

Softwareteams organiserer sig om features.

KI-teams skal organisere sig om data.

Vores workflow styres ikke via et Kanban-board, men via en datapipeline:

Hver fase har klare overdragelseskriterier.

Intet færdigt uden målbar kvalitet.

Konkrete arbejdsmetoder for KI-drevne teams i praksis

Nu bliver det praktisk.

Her er de arbejdsmetoder, jeg bruger hver dag.

3-fase-metoden for KI-projekter

Jeg deler ethvert KI-projekt i 3 faser:

Fase 1: Discovery (25% af tiden)

Mål: Forstå, hvad der er muligt.

Aktiviteter:

• Data exploration
• Proof of Concept
• Feasibility assessment
• Første baseline-modeller

Succesmåling: Kan problemet løses med KI?

Fase 2: Udvikling (60% af tiden)

Mål: Bygge den bedste model.

Aktiviteter:

• Iterativ modelforbedring
• Feature engineering
• Hyperparameteroptimering
• Cross-validation

Succesmåling: Målopnået accuracy.

Fase 3: Deployment (15% af tiden)

Mål: Få modellen i drift.

Aktiviteter:

• Model packaging
• API-udvikling
• Opsætning af monitoring
• A/B-testing

Succesmåling: Modellen kører stabilt i produktion.

Vigtigt: Faserne er ikke lineære.

Du hopper frem og tilbage mellem discovery og development.

Det er helt normalt.

Agil Data Science: Sprints tænkt på ny

Vi bruger stadig sprints – blot anderledes.

Vores KI-sprints varer 3-4 uger (ikke 2).

Hver sprint har et eksperiment-mål, ikke et feature-mål.

Sprint-planen ser sådan ud:

1. Eksperiment-review: Hvad lærte vi i sidste sprints?
2. Hypotese-prioritering: Hvilke eksperimenter er mest lovende?
3. Ressourceallokering: Hvem arbejder på hvad?
4. Succeskriterier: Hvordan måler vi succes?

Sprint-review viser ikke features, men indsigter:

• Hvilke hypoteser blev be- eller afkræftet?
• Hvilke nye learnings fik vi?
• Hvordan har model-performance udviklet sig?
• Hvilke eksperimenter er nu de logiske næste skridt?

Sådan organiserer du tværfaglige KI-teams rigtigt

Et KI-team kræver andre roller end et software-team.

Vores standardset-up for et KI-projekt:

Vigtigt: Product Manageren er IKKE Scrum Master.

De definerer forretningsmål, ikke sprint-mål.

Prioritering af eksperimenter sker i fællesskab i teamet.

Tool-stack og processer: Hvad virker faktisk

Værktøjer til KI-teams er ikke de samme som til software-teams.

Her er vores afprøvede stack.

Projektstyringsværktøjer til KI-teams

Jira er fint til software.

Til KI bruger vi en kombination af:

Eksperiment-tracking: MLflow

• Alle eksperimenter logges automatisk
• Parametre, metrikker, artefakter i ét overblik
• Sammenligning af forskellige model-versioner

Task management: Notion

• Hypotese-backlog
• Eksperimentdokumentation
• Team learnings
• Data quality dashboards

Kommunikation: Slack + daglige data-rapporter

• Automatiserede rapporter om model-performance
• Alarmer ved datakvalitetsproblemer
• En kanal for hvert igangværende eksperiment

Det vigtigste værktøj er dog en delt eksperimentlog.

Vi dokumenterer ALLE eksperimenter – uanset om de lykkes eller ej.

Versionsstyring af modeller og data

Kode versionerer du med Git.

Men hvad med modeller og data?

Sådan gør vi:

Data versioning: DVC (Data Version Control)

• Hver datasæt har et versionsnummer
• Reproducerbare datapipelines
• Automatisk tracking af data lineage

Modelversionering: MLflow Model Registry

• Alle modeller versioneres automatisk
• Staging-/produktionsmiljøer
• Mulighed for rollback ved performance-drop

Kodeversionering: Git + pre-commit hooks

• Automatiske kodekvalitetstjek
• Eksperiment-metadata committes automatisk
• Jupyter Notebooks renses inden commit

Uden versionsstyring er KI-udvikling ikke reproducerbar.

Og ikke reproducerbar betyder ikke til at debugge.

Testing og deployment i KI-miljøer

Unit tests for KI-kode er anderledes end for normal software.

Du tester ikke kun funktioner, men også datakvalitet og modelperformance.

Vores test-framework:

Datakvalitetstests

• Schema-validation (er alle kolonner til stede?)
• Data freshness (er data opdateret?)
• Statistiske tests (har datadistributionen ændret sig?)
• Fuldtællings-tjek (hvor mange manglende værdier?)

Model performance tests

• Accuracy-thresholds
• Latency-tests
• Memory usage-tests
• Bias-detection

Integrationstests

• End-to-end-pipeline-tests
• API svartidstests
• Load-tests

Deployment kører via blue-green deployment med automatisk rollback.

Hvis model-performance falder mere end 5%, rulles der automatisk tilbage til forrige version.

Typiske fejl ved overgang til KI-drevne arbejdsmetoder

Jeg har set de samme fejl hos næsten alle kunder.

Her er de mest almindelige – og hvordan du undgår dem.

Scrum Master bliver til AI Product Owner

Klassisk fejl:

Organisationen vil forblive agil og gør Scrum Master til AI Product Owner.

Problemet: En Scrum Master forstår processer, men ikke data science.

De kan ikke prioritere eksperimenter, fordi de ikke kan vurdere, hvad der er realistisk.

Løsningen: AI Product Owner skal have teknisk baggrund.

De skal forstå:

• Hvordan machine learning fungerer
• Hvad datakvalitet betyder
• Hvor lang tid model-træning kræver
• Hvilke metrikker der er relevante

Hos os er AI Product Owner altid en data scientist eller ML engineer med forretningsforståelse.

Aldrig en ren projektleder.

Hvorfor klassisk Definition of Done ikke virker

Software: Feature virker som specificeret = Done.

KI: Model opnår 85% accuracy = Done.

Men hvad, hvis modellen kun når 84%?

Er vi ikke færdige?

Klassisk Definition of Done fører til endeløse optimeringsloops i KI.

Vores tilgang: Probabilistisk Definition of Done.

I stedet for Model skal opnå 85% accuracy siger vi:

Model opnår mindst 80% accuracy og er bedre end hidtidig baseline.

Plus tidsgrænse:

Hvis der efter 4 ugers optimering ikke nås væsentlig forbedring, er modellen klar til produktion.

Det forhindrer perfektionisme og åbner for løbende forbedring efter produktion.

Change management for traditionelle teams

Det sværeste er ikke teknikken.

Det er change management.

Softwareudviklere er vant til deterministiske systemer.

KI er probabilistisk.

Det kræver et nyt mindset.

Hvad jeg altid gør i overgangsfasen:

1. Forventningsafstemning

• Kommunikér ærligt: 80% af eksperimenterne mislykkes
• Det er normalt og værdifuldt
• Succes måles anderledes

2. Pair programming for KI

• Erfarne data scientists arbejder sammen med softwareudviklere
• Knowledge transfer via code review
• Fælles eksperimentplanlægning

3. Løbende læring

• Ugentlige ML learning sessions
• Case studies af succesfulde eksperimenter
• Post-mortems for fejlslagne approaches

Overgangen tager 3-6 måneder.

Planlæg det ind.

Og fejr de små sejre – også fejlskuddene, der gav vigtige indsigter.

Ofte stillede spørgsmål

Hvor lang tid tager det at skifte fra Scrum til KI-drevne arbejdsmetoder?

Efter min erfaring tager omstillingen 3-6 måneder. Teamet skal lære nye tankesæt og etablere processer. Det er vigtigt at gennemføre skiftet gradvist og ikke ændre alt på én gang.

Kan Scrum og KI-udvikling slet ikke kombineres?

Jo, men du skal tilpasse Scrum markant. Længere sprints (3-4 uger), eksperiment-baserede mål i stedet for feature-mål og fleksibel tidsplanlægning. En ren Scrum-implementering virker ikke til KI-projekter.

Hvilke roller er helt nødvendige i et KI-team?

Minimum: Data Scientist, Data Engineer og ML Engineer. I små teams kan én have flere roller, men alle områder skal dækkes. En Product Manager med forståelse for KI er også vigtig.

Hvordan måler man succes med KI-eksperimenter?

Via foruddefinerede, målbare metrikker som accuracy, precision, recall eller forretnings-KPI’er. Vigtigt: Også mislykkede eksperimenter er en succes, hvis de giver læring. Vi dokumenterer systematisk alle eksperimenter.

Hvad er de største udfordringer i overgangen?

Change management er sværere end teknikken. Teams skal lære at håndtere usikkerhed og tænke probabilistisk i stedet for deterministisk. De behøver også nye værktøjer og versioneringsstrategier for data og modeller.

Hvilke værktøjer er uundværlige for KI-teams?

MLflow til eksperiment-tracking, DVC til data-versionering, en cloud-udbyder til compute og et godt dokumentationsværktøj som Notion. Git alene er ikke nok – du behøver værktøjer, der er udviklet til data science.

Hvordan tackler man uforudsigeligheden ved KI-projekter?

Med timeboxed eksperimenter og klare Go/No-Go-kriterier. Sæt tidsgrænser for optimeringsloops og definer minimum performance thresholds. Planlæg med buffere og kommuniker usikkerhed åbent til stakeholders.

Virker klassiske projektstyringsværktøjer til KI-teams?

Kun delvist. Jira kan bruges til task management, men du behøver ekstra værktøjer til eksperiment-tracking og data lineage. Vi bruger en kombination af forskellige specialiserede værktøjer.

Hvordan organiseres code reviews for machine learning-kode?

ML code reviews adskiller sig fra software code reviews. Du tjekker ikke kun kodekvalitet, men også eksperimentdesign, datakvalitet og modelvalidering. Pair programming mellem erfarne data scientists og softwareudviklere fremmer knowledge transfer.

Hvad gør man, hvis et KI-projekt fejler totalt?

Det sker i 15-20% af tilfældene og er helt normalt. Vigtigt er at spotte det tidligt, hvis en approach ikke virker, og hurtigt lægge kursen om. Dokumentér alle learnings – de er værdifulde for kommende projekter. Et fejlslagent projekt kan spare andre for samme fejl i fremtiden.