Agil arbetsmetodik möter AI: Varför klassiska metoder misslyckas inom automatisering

Varför Scrum och Kanban misslyckas i AI-projekt

Scrum är uppfunnet för mjukvaruutveckling.

AI följer andra lagar.

Att ignorera det är det vanligaste felet jag ser hos mina kunder.

Sprintproblemet: AI utvecklas inte linjärt

En sprint är två veckor lång.

En machine learning-modell kan ta tre veckor innan den ger användbara resultat.

Vad gör du vecka ett och två? Ska Vi tränar fortfarande vara ett sprintresultat?

Jag har sett det själv.

Ett team kunde efter sex sprintar nästan inte visa upp något – trots riktigt bra arbete.

Problemet: AI-utveckling följer andra tidsmönster.

Ibland tar databehandlingen fyra veckor, sedan fungerar den första modellen direkt.

Ibland behöver du testa 50 olika tillvägagångssätt innan något funkar.

Det passar inte i tvåveckorscykler.

Backlog-kaos: När algoritmer styr prioriteringen

Product Backlog fungerar för features.

I AI-projekt ändras prioriteringar av nya insikter.

Ett exempel från min praktik:

Vi ville bygga ett sentimentanalysverktyg för kundfeedback.

Planen: Fem features:

1. Positiv/Negativ klassificering
2. Känsloigenkänning
3. Temanextraktion
4. Trendanalys
5. Dashboard

Efter första datakartläggningen stod det klart att 60% av datan var oanvändbar.

Plötsligt blev datarensning prio ett.

Det stod inte någonstans i backloggen.

Ofta avgör datan nästa steg i AI-projekt – inte Product Owner.

Daily Standups blir Weekly Standups (och det är helt okej)

Vad gjorde du igår?

Optimerade hyperparametrar.

Vad gör du idag?

Optimerar hyperparametrar.

Finns det några hinder?

Träningen kör i 12 timmar till.

Så här ser standups ut i AI-team.

Meningslöst.

AI-utveckling har längre feedbackcykler.

Att träna en modell kan ta dagar.

Att utvärdera ett A/B-test kräver statistisk signifikans – oftast veckor.

Daglig synk funkar inte, om inget väsentligt händer varje dag.

De tre grundläggande skillnaderna mellan mjukvaru- och AI-utveckling

Mjukvaruutveckling: Du vet vad du bygger.

AI-utveckling: Du vet vad du prövar.

Där sitter skillnaden i kärnan.

Oförutsägbarhet istället för planbarhet

I mjukvara skriver du kod; den funkar (eller funkar inte).

I AI tränar du en modell, den fungerar till 73% – och du vet inte varför.

Inte på grund av dålig kod.

Utan på oväntade dataproblem eller modellprestanda.

Du kan inte planera för när en modell når önskad accuracy.

Du kan bara experimentera och iterera.

Det gör klassisk projektplanering omöjlig.

Experimentell kontra linjär utvecklingsprocess

Mjukvaruutveckling följer en linjär metod:

Krav → Design → Implementation → Test → Driftsättning

AI-utveckling är ett experimentcykel:

Hypotes → Experiment → Utvärdering → Lärdomar → ny Hypotes

80% av min tid i AI-projekt lägger jag på experiment som inte fungerar.

Det är normalt.

Faktiskt är det bra.

Varje misslyckat experiment för dig närmare lösningen.

I mjukvara vore 80% misslyckad kod oacceptabelt.

Inom AI är det vägen till framgång.

Datakvalitet som kritisk framgångsfaktor

Mjukvara funkar med syntetisk testdata.

AI står och faller med riktiga, högkvalitativa data.

Jag har sett projekt där teamet skrev felfri kod i sex månader.

Modellen var ändå värdelös.

För datan var dålig.

I AI-projekt lägger du 60–80% av tiden på dataarbete:

• Samladata
• Rensa data
• Labela data
• Validera data
• Bygga datapipeplines

Det finns inte med i någon mjukvarusprintplan.

Men utan det funkar inte AI.

AI-first-arbetssätt: Vad kommer efter Scrum

Jag har jobbat i tre år med olika sätt att organisera AI-team.

Det här fungerar på riktigt.

Hypotesdriven utveckling istället för User Stories

Glöm User Stories.

Som användare vill jag … fungerar inte för AI.

Använd istället: hypotesdriven utveckling.

Varje utvecklingsfas startar med en mätbar hypotes:

Om vi lägger till feature X förbättras modellens accuracy med minst 5%.

Eller:

Om vi använder algoritm Y halveras träningstiden.

Varje hypotes har:

• En mätbar metrisk
• Ett målvärde
• En tidsuppskattning för experimentet
• Kriterier för framgång/misslyckande

Så blir Vi optimerar modellen ett konkret experiment med tydligt resultat.

Kontinuerliga experiment som kärnprocess

I mjukvara bygger du features.

Inom AI genomför du experiment.

Den viktigaste processen är inte sprintplanering, utan experimentdesign.

Vårt standard-workflow för experiment:

1. Hypotesdefinition (1 dag)
2. Experimentuppsättning (2-3 dagar)
3. Genomförande (varierar: 1 dag till 2 veckor)
4. Utvärdering (1-2 dagar)
5. Beslut (Fortsätt/Avbryt/Pivot)

Viktigt: Alla experiment dokumenteras.

Även de som inte lyckas.

Framför allt de som inte lyckas.

Vi för en Experimentlogg med:

• Hypotes
• Tillvägagångssätt
• Resultat
• Lärdomar
• Nästa steg

Det blir teamets största kunskapsbank.

Datacentrerade arbetsflöden för AI-team

Mjukvaruteam organiserar sig kring features.

AI-team måste centrera arbetet kring data.

Vi arbetar inte med ett Kanban-board, utan med en datapipeline:

Varje fas har tydliga acceptanskriterier.

Inget är klart utan mätbar kvalitet.

Konkreta arbetssätt för AI-drivna team i praktiken

Nu räcker det med teori.

Här är arbetsmetoderna jag använder varje dag.

3-fasmetoden för AI-projekt

Jag delar upp alla AI-projekt i tre faser:

Fas 1: Discovery (25% av tiden)

Mål: Förstå vad som är möjligt.

Aktiviteter:

• Datarensning och utforskning
• Proof of Concept
• Förstudie
• Första baselinemodeller

Framgångsmätare: Går det att lösa problemet med AI?

Fas 2: Development (60% av tiden)

Mål: Bygga bästa möjliga modell.

Aktiviteter:

• Iterativa modellförbättringar
• Feature engineering
• Hyperparameteroptimering
• Cross-validation

Framgångsmätare: Målaccuracy uppnådd.

Fas 3: Deployment (15% av tiden)

Mål: Distribuera modellen till produktion.

Aktiviteter:

• Paketera modell
• API-utveckling
• Monitorering
• A/B-testning

Framgångsmätare: Modellen körs stabilt i produktion.

Viktigt: Faserna är inte linjära.

Du hoppar mellan Discovery och Development om vartannat.

Det är helt normalt.

Agile Data Science – Sprints omdefinierade

Vi använder ändå sprintar – men på annat sätt.

Våra AI-sprintar är tre–fyra veckor (inte två).

Varje sprint har ett experimentmål, inte ett featuremål.

Sprintplaneringen ser ut så här:

1. Experimentgenomgång: Vad lärde vi oss förra sprinten?
2. Hypotesprioritering: Vilka experiment är mest lovande?
3. Resursfördelning: Vem jobbar med vilket experiment?
4. Succékriterier: Hur mäts framgång?

Sprint Review visar inte features, utan insikter:

• Vilka hypoteser har bekräftats eller avfärdats?
• Vilka nya insikter har vi fått?
• Hur har modellens prestanda utvecklats?
• Vilka logiska experiment är nästa steg?

Så organiserar du tvärfunktionella AI-team

Ett AI-team behövs med andra roller än ett mjukvaruteam.

Vår standarduppställning för ett AI-projekt:

Viktigt: Product Manager är INTE Scrum Master.

Hen definierar affärsmål, inte sprintmål.

Experimentprioritering görs av hela teamet tillsammans.

Tool-stack och processer: Vad fungerar faktiskt

Verktygen för AI-team är annorlunda jämfört med mjukvaruteam.

Här är vår beprövade stack.

Projektstyrningsverktyg för AI-team

Jira funkar okej för mjukvara.

För AI kör vi en kombination:

Experimentspårning: MLflow

• Alla experiment loggas automatiskt
• Parametrar, metrik och artifacts i en vy
• Jämför olika modellversioner

Uppgiftshantering: Notion

• Hypotesbacklog
• Experimentsdokumentation
• Teamets lärdomar
• Dashboards för datakvalitet

Kommunikation: Slack + dagliga data-rapporter

• Automatiska rapporter om modellprestanda
• Notifieringar vid datakvalitetsproblem
• En kanal per pågående experiment

Det viktigaste verktyget är ändå en gemensam experimentlogg.

Vi dokumenterar VARJE experiment – oavsett om det lyckas eller inte.

Versionshantering för modeller och data

Kod versionshanterar du med Git.

Men hur gör du med modeller och data?

Vår lösning:

Dataversionering: DVC (Data Version Control)

• Varje dataset får ett versionsnummer
• Reproducerbara datapipelines
• Automatisk härledning av datans ursprung

Modellversionering: MLflow Model Registry

• Alla modeller versionshanteras automatiskt
• Staging/Production-miljöer
• Automatiskt rollback om prestandan försämras

Kodversionering: Git + pre-commit hooks

• Automatiska kodkvalitetstester
• Experimentmetadata committas automatiskt
• Jupyter Notebooks rensas före commit

Utan versionshantering blir AI-utveckling inte reproducerbar.

Och icke-reproducerbart går inte att felsöka.

Testing och distribution i AI-miljöer

Unittester för AI-kod är annorlunda jämfört med vanlig mjukvara.

Du testar inte bara funktioner, utan även datakvalitet och modellprestanda.

Vårt testframework:

Tester för datakvalitet

• Schemavalidering (finns alla kolumner?)
• Datakontroll (är datan aktuell?)
• Statistiska tester (har datans fördelning ändrats?)
• Fullständighetskontroller (hur många saknade värden?)

Tester av modellprestanda

• Test av accuracy-gräns
• Latenskapstest
• Minnesanvändningstest
• Bias-detektionstest

Integrationstester

• End-to-end-pipeline-tester
• API-responstidstester
• Load-tester

Distribution sker via blue-green deployment med automatsikt rollback.

Om modellens prestanda sjunker med mer än 5% görs rollback till föregående version.

Vanliga misstag vid övergången till AI-baserade arbetssätt

Jag har sett samma misstag hos nästan alla kunder.

Här är de vanligaste – och hur du undviker dem.

Scrum Master blir AI Product Owner

Klassiskt misstag:

Bolaget vill vara agilt och gör Scrum Master till AI Product Owner.

Problemet: En Scrum Master kan process, men inte data science.

Hen kan inte prioritera experiment, eftersom han/hon inte vet vad som är rimligt.

Lösningen: AI Product Owner måste ha teknisk bakgrund.

Måste förstå:

• Hur machine learning fungerar
• Vad datakvalitet innebär
• Hur lång tid modellträning tar
• Vilka metrik som är relevanta

Hos oss är AI Product Owner alltid en Data Scientist eller ML Engineer med affärsförståelse.

Aldrig enbart projektledare.

Varför klassisk Definition of Done inte fungerar

Mjukvara: Feature fungerar enligt spec = Done.

AI: Modellen når 85% accuracy = Done.

Men vad om modellen bara når 84%?

Är du inte klar då?

Klassisk Definition of Done leder till oändliga optimeringsloopar i AI.

Vårt grepp: probabilistisk Definition of Done.

Istället för modellen måste nå 85% accuracy anger vi:

Modellen uppnår minst 80% accuracy och är bättre än baseline.

Samt tidsgräns:

Om modellen inte förbättrats betydligt på fyra veckor är den redo för produktion.

Det motverkar perfektionism och ger utrymme för iterativa förbättringar i produktion.

Change Management för traditionella team

Det svåraste är inte tekniken.

Det är förändringsarbetet.

Mjukvaruutvecklare är vana vid deterministiska system.

AI är sannolikhetsbaserat.

Det kräver ett nytt tankesätt.

Vid varje övergång gör jag:

1. Förväntanshantering

• Ärlighet: 80% av experimenten misslyckas
• Det är normalt och lärorikt
• Framgång mäts annorlunda

2. Pair Programming för AI

• Erfarna data scientists jobbar ihop med mjukvaruutvecklare
• Kunskapsöverföring genom code reviews
• Gemensam experimentplanering

3. Kontinuerligt lärande

• Varje vecka: ML Learning Sessions
• Case studies av lyckade experiment
• Post-mortems för misslyckade försök

Övergången tar 3–6 månader.

Planera för det.

Och fira små framsteg – även misslyckade experiment som leder till viktiga insikter.

Vanliga frågor

Hur lång tid tar övergången från Scrum till AI-drivna arbetssätt?

Av egen erfarenhet: tre till sex månader. Teamet måste lära sig nya tankesätt och etablera nya processer. Viktigast är att ta det stegvis och inte ändra allt på samma gång.

Är det omöjligt att kombinera Scrum och AI-utveckling?

Nej, men Scrum behöver anpassas rejält: längre sprintar (3–4 veckor), experimentbaserade mål istället för feature-mål och flexibel tidsplanering. Renodlad Scrum funkar inte för AI-projekt.

Vilka roller måste ett AI-team ha?

Minst: Data Scientist, Data Engineer och ML Engineer. I mindre team kan en person ha flera roller, men alla områden måste täckas. En Product Manager med AI-förståelse är också viktig.

Hur mäts framgången för AI-experiment?

Med fördefinierade, mätbara metrik som accuracy, precision, recall eller affärs-KPI:er. Viktigt: även misslyckade experiment är en framgång om de ger lärdom. Vi dokumenterar alla experiment systematiskt.

Vilka är de största utmaningarna vid övergången?

Change management är svårare än tekniken. Teamet måste hantera osäkerhet och lära sig tänka i sannolikheter istället för determinism. De behöver också nya verktyg och strategier för versionering av data och modeller.

Vilka verktyg är essentiella för AI-team?

MLflow för experimentspårning, DVC för dataversionering, molntjänst för datorkraft och ett bra dokumentationsverktyg som Notion. Git räcker inte – du behöver verktyg anpassade för data science.

Hur hanterar man AI-projektens oförutsägbarhet?

Med tidssatta experiment och tydliga Go/No-Go-kriterier. Sätt tidsgränser för optimeringsloopar och definiera minsta prestandakrav. Planera in buffert och kommunicera osäkerhet öppet till stakeholders.

Fungerar klassiska projektstyrningsverktyg för AI-team?

Delvis. Jira kan användas för uppgiftshantering, men du behöver extra verktyg för experimentspårning och datalinjering. Vi använder en kombination av flera specialiserade verktyg.

Hur organiserar man code reviews för machine learning-kod?

ML-code reviews skiljer sig från vanlig kodgranskning. Du granskar inte bara kodkvalitet, utan även experimentupplägg, datakvalitet och modellvalidering. Pair Programming mellan data scientists och utvecklare är effektivt för kunskapsöverföring.

Vad händer om ett AI-projekt misslyckas helt?

Det sker i 15–20% av projekten och är helt normalt. Viktigt är att upptäcka om något inte fungerar i tid och byta strategi snabbt. Dokumentera alla lärdomar – de är värdefulla för nya projekt. Ett misslyckat projekt kan rädda andra från samma misstag.