Agile arbeidsmetoder møter KI: Hvorfor tradisjonelle metoder feiler i automatisering

Hvorfor Scrum og Kanban mislykkes i KI-prosjekter

Scrum ble laget for programvareutvikling.

KI følger helt andre spilleregler.

Å overse det er den vanligste feilen jeg ser hos kundene mine.

Sprint-problemet: KI utvikler seg ikke lineært

En sprint varer i 2 uker.

Et maskinlæringsmodell kan ta 3 uker før det gir noenlunde brukbare resultater.

Hva gjør du i uke 1 og 2? Skal du presentere vi trener fortsatt som sprintresultat?

Jeg har vært vitne til det selv.

Et utviklingsteam leverte nesten ingenting synlig på 6 sprinter – selv om de gjorde utmerket arbeid.

Problemet: KI-utvikling har andre tidssykluser.

Noen ganger tar datarensing fire uker, og så fungerer den første modellen med en gang.

Noen ganger må du prøve 50 ulike tilnærminger før en av dem lykkes.

Det lar seg ikke presse inn i 2-ukers rytmer.

Backlog-kaos: Når algoritmene endrer prioriteringene

Produkt-backlog fungerer for features.

Innen KI endrer prioriteringene seg underveis – drevet av innsikt i dataene.

Et eksempel fra min praksis:

Vi skulle bygge et sentiment-analysator-verktøy for tilbakemeldinger fra kunder.

Planen inkluderte 5 funksjoner:

1. Positiv/negativ klassifisering
2. Følelsesgjenkjenning
3. Temauttrekk
4. Trendanalyse
5. Dashboard

Etter første datautforskning oppdaget vi at 60 % av dataene var ubrukelige.

Plutselig ble datarensing prioritert øverst.

Det sto ikke nevnt noe sted i backlog.

I KI-prosjekter er det ofte dataene som bestemmer neste steg – ikke Product Owner.

Daglige standups blir ukentlige standups (og det er helt greit)

Hva gjorde du i går?

Optimaliserte hyperparametre.

Hva gjør du i dag?

Optimaliserer hyperparametre.

Har du blokkere?

Treningen varer fortsatt i 12 timer.

Slik ser daily standups ut i KI-team.

Ikke særlig nyttig.

KI-utvikling har lengre tilbakemeldingssløyfer.

Trening av et modell kan ta flere dager.

Å analysere et A/B-testresultat krever statistisk signifikans – ofte snakker vi uker.

Daglig synkronisering gir ikke mening når lite endrer seg fra dag til dag.

De tre grunnleggende forskjellene mellom programvare- og KI-utvikling

Programvareutvikling: Du vet hva du skal bygge.

KI-utvikling: Du vet hva du skal utforske.

Det er det største skillet.

Uforutsigbarhet i stedet for forutsigbar planlegging

Med programvare skriver du kode – den virker (eller ikke).

Med KI trener du en modell, den virker 73 % – og du vet ikke hvorfor.

Ikke på grunn av dårlig kode.

Men fordi dataene eller modellens ytelse overrasker.

Du kan ikke planlegge når en modell vil oppnå ønsket nøyaktighet.

Du kan bare eksperimentere og iterere.

Derfor fungerer klassisk prosjektplanlegging dårlig her.

Eksperimentell vs. lineær utviklingsprosess

Programvareutvikling følger en lineær prosess:

Krav → Design → Implementasjon → Testing → Produksjonssetting

KI-utvikling er en eksperimentell sirkel:

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

80 % av tiden i KI-prosjekter bruker jeg på eksperimenter som ikke lykkes.

Det er normalt.

Faktisk er det bra.

Hvert mislykket eksperiment trekker deg nærmere en løsning.

I programvare ville 80 % mislykket kode vært uakseptabelt.

Innen KI er det veien til suksess.

Datakvalitet som kritisk suksessfaktor

Programvare kan fungere med syntetiske testdata.

KI står og faller på ekte og reelle data av høy kvalitet.

Jeg har sett prosjekter der teamet skrev feilfri kode i seks måneder.

Modellen var likevel ubrukelig.

Fordi dataene var dårlige.

Innen KI bruker du 60–80 % av tiden på dataarbeid:

• Innhenting av data
• Datarensing
• Merking av data
• Validering av data
• Bygging av datapipeliner

Det finnes ikke i noen programvaresprintplan.

Uten dette fungerer ikke KI.

AI-first arbeidsmetodikk: Hva kommer etter Scrum

Jeg har jobbet med forskjellige tilnærminger for KI-team de siste tre årene.

Her er det som faktisk fungerer.

Hypotesedrevet utvikling i stedet for brukerhistorier

Glem brukerhistorier.

Som bruker ønsker jeg… fungerer ikke i KI.

Erstatt det med hypotesedrevet utvikling.

Hver utviklingsfase starter med en målbar hypotese:

Hvis vi legger til funksjon X, forbedres modellens nøyaktighet med minst 5 %.

Eller:

Hvis vi bruker algoritme Y, reduseres treningstiden med 50 %.

Hver hypotese har:

• En målbar metrikk
• En målverdi
• Et estimat for eksperimentet
• Kriterier for suksess/fiasko

Slik blir vi optimaliserer modellen til et konkret eksperiment med et tydelig resultat.

Kontinuerlig eksperimentering som kjerneprosess

I programvare utvikler du features.

I KI gjennomfører du eksperimenter.

Den viktigste prosessen er ikke sprintplanlegging, men eksperimentdesign.

Standard flyt for eksperimenter hos oss:

1. Hypotesedefinisjon (1 dag)
2. Eksperimentoppsett (2–3 dager)
3. Gjennomføring (varierer: 1 dag til 2 uker)
4. Evaluering (1–2 dager)
5. Beslutning (Gå videre / Forkaste / Pivotere)

Viktig: Hvert eksperiment dokumenteres.

Også de mislykkede.

Fremfor alt de mislykkede.

Vi fører en eksperimentlogg med:

• Hypotese
• Tilnærming
• Resultat
• Læringspunkter
• Neste steg

Dette blir teamets mest verdifulle ressurs.

Datadrevne arbeidsflyter for KI-team

Programvareteam organiserer seg rundt features.

KI-team må organisere seg rundt data.

Arbeidsflyten vår er ikke basert på et kanban-board, men på en datapipeline:

Hver fase har tydelige overleveringskriterier.

Ingen ferdig uten målbar kvalitet.

Konkrete arbeidsmetoder for KI-drevne team i praksis

Nok teori.

Her er metodene jeg bruker hver eneste dag.

3-fasers metode for KI-prosjekter

Jeg deler hvert KI-prosjekt i tre faser:

Fase 1: Discovery (25 % av tiden)

Mål: Forstå hva som er mulig.

Aktiviteter:

• Datautforskning
• Proof of Concept
• Mulighetsvurdering
• Første baseline-modeller

Suksessmetrikker: Kan problemet løses med KI?

Fase 2: Utvikling (60 % av tiden)

Mål: Bygge den beste modellen.

Aktiviteter:

• Iterativ modellforbedring
• Feature engineering
• Optimalisering av hyperparametre
• Kryssvalidering

Suksessmetrikker: Oppnådd mål-nøyaktighet.

Fase 3: Produksjonssetting (15 % av tiden)

Mål: Sette modellen i produksjon.

Aktiviteter:

• Innpakking av modell
• API-utvikling
• Overvåking
• A/B-testing

Suksessmetrikker: Modellen kjører stabilt i produksjon.

Viktig: Fasene er ikke lineære.

Du hopper frem og tilbake mellom discovery og utvikling.

Det er helt vanlig.

Agil data science: Sprints tenkt på nytt

Vi bruker fremdeles sprinter – men annerledes.

Våre KI-sprinter varer 3–4 uker (ikke 2).

Hver sprint har et eksperimentmål – ikke et feature-mål.

Slik planlegger vi en sprint:

1. Eksperimentgjennomgang: Hva lærte vi i forrige sprinter?
2. Hypotesepioritering: Hvilke eksperimenter er mest lovende?
3. Ressurstildeling: Hvem jobber på hva?
4. Suksesskriterier: Hvordan måler vi suksess?

Sprint review viser ikke features, men innsikt:

• Hvilke hypoteser ble bekreftet eller avkreftet?
• Hvilke nye funn har vi gjort?
• Hvordan har modellens ytelse utviklet seg?
• Hva er de neste logiske eksperimentene?

Organisere tverrfaglige KI-team riktig

Et KI-team trenger andre roller enn et programvareteam.

Standard teamoppsett for et KI-prosjekt:

Viktig: Product Manager er IKKE Scrum Master.

De definerer forretningsmål – ikke sprintmål.

Hele teamet prioriterer eksperimentene sammen.

Verktøystakk og prosesser: Hva fungerer i virkeligheten

Verktøyene for KI-team er andre enn for programvareteam.

Her er vår gjennomtestede stack.

Prosjektstyring for KI-team

Jira fungerer for programvare.

For KI bruker vi en kombinasjon:

Eksperimentsporing: MLflow

• Alle eksperimenter logges automatisk
• Parametre, måleverdier, artifakter samlet
• Sammenligne ulike modellversjoner

Oppgavehåndtering: Notion

• Hypotesebacklog
• Eksperimentdokumentasjon
• Teamlæring
• Dashbord for datakvalitet

Kommunikasjon: Slack + daglige data-rapporter

• Automatiserte rapporter om modellens ytelse
• Varsler ved datakvalitetsfeil
• Egen kanal for hvert eksperiment

Det viktigste verktøyet er uansett en delt eksperimentlogg.

Vi dokumenterer ALT av eksperimenter – uansett om de lykkes eller ikke.

Versjonering av modeller og data

Kode versjoneres i Git.

Men hva med modeller og data?

Vår løsning:

Data-versjonering: DVC (Data Version Control)

• Hver datasett har et versjonsnummer
• Reproduserbare datapipelines
• Automatisk sporing av datalinjer

Modellversjonering: MLflow Model Registry

• Alle modeller versjoneres automatisk
• Staging/produksjonsmiljøer
• Rull tilbake hvis ytelsen forverres

Kodeversjonering: Git + pre-commit hooks

• Automatisk kodekvalitetssjekk
• Metadata fra eksperimenter committes automatisk
• Jupyter Notebooks renses før commit

Uten versjonering blir KI-utvikling ikke reproduserbar.

Og ikke reproduserbar betyr ikke mulig å feilsøke.

Testing og produksjonssetting i KI-miljøer

Unittester for KI-kode er annerledes enn for vanlig programvare.

Du tester ikke bare funksjoner, men også datakvalitet og modellens ytelse.

Vår testrammeverk:

Datakvalitetstester

• Skjemavalidering (finnes alle kolonner?)
• Datastatus (er dataene oppdaterte?)
• Statistiske tester (har datastrukturen endret seg?)
• Fullstendighetssjekker (antall manglende verdier?)

Modelltesting

• Threshold-tester for nøyaktighet
• Test av responstid
• Test av minnebruk
• Bias-detektering

Integrasjonstesting

• End-to-end pipeline-tester
• API response time-tester
• Lastetesting

Produksjonssetting skjer via blue-green deployment med automatisk tilbakekobling.

Hvis modellens ytelse faller mer enn 5 %, rulles det automatisk tilbake til forrige versjon.

Vanlige feil ved overgang til KI-baserte arbeidsmetoder

Jeg har sett de samme feilene hos nesten alle kunder.

Her er de vanligste – og hvordan du unngår dem.

Scrum Master blir AI Product Owner

Klassisk feil:

Selskapet vil forbli agilt og gir Scrum Master rollen som AI Product Owner.

Problemet: En Scrum Master kan prosesser, men ikke data science.

Hun klarer ikke prioritere eksperimenter fordi hun ikke kan vurdere realismen.

Løsningen: AI Product Owner må ha teknisk bakgrunn.

Hun må forstå:

• Hvordan maskinlæring virker
• Hva datakvalitet faktisk innebærer
• Hvor lang tid modelltrening krever
• Hvilke metrikker som teller

Hos oss er AI Product Owner alltid data scientist eller ML engineer med god forretningsforståelse.

Aldri bare prosjektleder.

Hvorfor klassisk definition of done ikke fungerer

Programvare: Feature fungerer som spesifisert = Done.

KI: Modellen når 85 % nøyaktighet = Done.

Men hva om modellen får bare 84 %?

Er vi da ikke ferdige?

Klassisk definition of done gir evige optimaliseringssløyfer i KI.

Vår løsning: Sannsynlighetsbasert definition of done.

I stedet for modellen må nå 85 %, definerer vi:

Modellen oppnår minst 80 % nøyaktighet og er bedre enn baseline-metoden.

Pluss tidsbegrensning:

Hvis det ikke oppnås betydelig forbedring etter 4 uker med optimalisering, er modellen klar for produksjon.

Det hindrer perfeksjonisme og gir rom for videre iterasjon i produksjon.

Endringsledelse for tradisjonelle team

Den vanskeligste delen er ikke teknologien.

Det er endringsledelsen.

Utviklere er vant til å bygge deterministiske systemer.

KI er probabilistisk.

Det krever et skifte i tankesett.

Hva jeg alltid gjør i slike overganger:

1. Forventningsavklaring

• Vær tydelig: 80 % av eksperimentene feiler
• Det er både normalt og verdifullt
• Suksess måles annerledes

2. Parprogrammering for KI

• Erfarne data scientists samarbeider tett med utviklere
• Kunnskapsoverføring gjennom code reviews
• Felles eksperimentplanlegging

3. Kontinuerlig læring

• Ukentlige ML Learning Sessions
• Case studies av vellykkede eksperimenter
• Post-mortems av mislykkede tilnærminger

Overgangen varer 3–6 måneder.

Beregn det inn.

Og feir små seire – selv mislykkede eksperimenter gir verdifull læring.

Ofte stilte spørsmål

Hvor lang tid tar det å gå fra Scrum til KI-baserte arbeidsmetoder?

Ut fra min erfaring tar overgangen 3–6 måneder. Teamet må lære nye tankesett og skape nye prosesser. Det viktigste er å ta det trinnvis og ikke forsøke å endre alt på én gang.

Er det umulig å kombinere Scrum og KI-utvikling?

Nei, men Scrum må justeres kraftig. Lengre sprinter (3–4 uker), eksperimentbaserte mål i stedet for feature-mål, og fleksibel tidsstyring. En ren Scrum-implementering fungerer ikke for KI-prosjekter.

Hvilke roller må et KI-team ha?

Minimum: Data Scientist, Data Engineer og ML Engineer. I små team kan én person fylle flere roller, men alle områdene må være dekket. En Product Manager med KI-forståelse er også viktig.

Hvordan måles suksess for KI-eksperimenter?

Ved forhåndsdefinerte, målbare metrikker som nøyaktighet, presisjon, recall eller forretnings-KPI-er. Viktig: Også mislykkede eksperimenter er verdifulle hvis de gir læring. Vi dokumenterer alt systematisk.

Hva er de største utfordringene med overgangen?

Endringsledelse er vanskeligere enn teknikken. Teamet må lære å nærme seg usikkerhet og tenke probabilistisk, ikke deterministisk. Du trenger også nye verktøy og versjoneringsstrategier for data og modeller.

Hvilke verktøy er essensielle for KI-team?

MLflow for eksperimentsporing, DVC for dataversjonering, en skyløsning for regnekraft og et godt dokumentasjonsverktøy som Notion. Git holder ikke alene – du trenger verktøy laget for data science.

Hvordan håndterer man uforutsigbarhet i KI-prosjekter?

Gjennom tidsavgrensede eksperimenter med klare go/no-go-kriterier. Sett tidsfrister for optimaliseringssløyfer og definer minstekrav til ytelse. Planlegg med margin og kommuniser usikkerhet tydelig til interessenter.

Fungerer tradisjonelle prosjektstyringsverktøy for KI-team?

Bare delvis. Jira kan brukes til oppgavehåndtering, men du trenger tillegg for eksperimentsporing og datalinjer. Vi kombinerer ulike, spesialiserte verktøy.

Hvordan organiserer man code review for maskinlæringskode?

Code reviews for ML er annerledes enn for programvare. Du må ikke bare kvalitetssikre kode, men også eksperimentdesign, datakvalitet og modellvalidering. Parprogrammering mellom dyktige data scientists og utviklere gir best kunnskapsoverføring.

Hva gjør man hvis et KI-prosjekt feiler helt?

Det skjer i 15–20 % av tilfellene – og er helt normalt. Det viktigste er å gjenkjenne det tidlig, snu raskt og dokumentere alle erfaringer. Læring fra feilslåtte prosjekter kan spare andre for de samme feilene i fremtidige prosjekter.