ProduktutviklingHafsteinn Runarsson · AI Konsulent04 Oct 2026 · 10 min

Smidig metodikk for AI- og programvareteam: En praktisk guide

Smidig metodikk er en måte å organisere produktutvikling på når teamet må lære underveis. I stedet for å detaljplanlegge hele leveransen på forhånd, jobber teamet i små steg, viser frem det som er laget, henter tilbakemeldinger og justerer neste prioritet. Målet er ikke å jobbe fortere for enhver pris, men å oppdage feil retning tidlig og bruke kapasiteten på det som gir mest verdi.

For AI- og programvareteam betyr det vanligvis korte læringssløyfer, én tydelig prioritering, hyppige demonstrasjoner og kvalitet som en del av hvert steg. Scrum og Kanban kan gi struktur, men smidighet kommer først når teamet faktisk bruker ny kunnskap til å endre planen.

Hva er smidig metodikk?

Smidig metodikk er en iterativ og læringsdrevet tilnærming til komplekst arbeid. Teamet deler et stort mål i mindre leveranser, tester antakelser og tar nye beslutninger på grunnlag av det som er observert.

Det norske manifestet for smidig programvareutvikling fremhever fire prioriteringer:

• personer og samspill fremfor prosesser og verktøy
• programvare som virker fremfor omfattende dokumentasjon
• samarbeid med kunden fremfor kontraktsforhandlinger
• å reagere på endringer fremfor å følge en plan

Punktene til høyre har fortsatt verdi. Forskjellen er hva teamet velger når hensynene kolliderer. En plan er nyttig, men den skal ikke hindre teamet i å reagere når brukere, data eller tekniske funn viser at planen bør endres.

De tolv prinsippene bak manifestet gjør dette mer konkret: lever tidlig og hyppig, samarbeid tett, hold et bærekraftig tempo, prioriter teknisk kvalitet og bruk regelmessig refleksjon til å forbedre arbeidsmåten.

Smidig kontra fossefall

Velg smidig når løsningen er usikker, og en mer sekvensiell modell når både behov og løsning er stabile. Det er ikke et spørsmål om at én metode alltid er best.

• Smidig: Arbeidet organiseres i korte læringssløyfer. Omfang og rekkefølge kan endres når teamet lærer mer.
• Fossefall: Analyse, spesifikasjon, design, bygging og testing følger i større grad en planlagt sekvens. Endringer sent i løpet er vanskeligere å håndtere.
• Hybrid: Faste krav til styring, sikkerhet eller milepæler kombineres med iterativ utvikling innenfor rammene.

Smidig passer ofte når:

• brukernes behov må utforskes
• det finnes flere mulige tekniske løsninger
• tilbakemeldinger kan hentes før hele produktet er ferdig
• prioriteringer kan endre seg underveis
• teamet kan levere små, sammenhengende forbedringer

En mer sekvensiell tilnærming kan være riktig når:

• leveransen har et stabilt og komplett kravgrunnlag
• endringer etter oppstart er svært kostbare eller praktisk umulige
• arbeidet må passere faste, avhengige faser
• læring underveis i liten grad påvirker løsningen

Mange produktteam trenger begge deler: tydelige rammer for budsjett, ansvar og risiko, men smidige sløyfer for å finne den beste løsningen.

Scrum, Kanban og smidig er ikke det samme

Smidig er tankesettet; Scrum og Kanban er ulike måter å gjøre arbeidet synlig og styrbart på. Et team kan følge alle seremoniene i Scrum uten å være smidig, og et team kan arbeide smidig uten å bruke Scrum.

Scrum

Scrum passer når et tverrfaglig team kan samle arbeidet rundt ett produktmål og skape et brukbart inkrement i en fast rytme. Den offisielle Scrum-guiden beskriver Scrum som et lett rammeverk for adaptive løsninger på komplekse problemer.

Kjernen er:

• et produktmål og en prioritert produktkø
• sprinter på én måned eller kortere
• tydelige ansvar for Product Owner, Scrum Master og Developers
• planlegging, daglig koordinering, gjennomgang og retrospektiv
• et ferdig inkrement som kan inspiseres ved slutten av hver sprint

Scrum er nyttig når en fast rytme hjelper teamet med å samle fokus og hente tilbakemeldinger regelmessig.

Kanban

Kanban passer når arbeid kommer kontinuerlig, prioriteringer endres ofte eller teamet må forbedre flyten i en eksisterende prosess. Kanban-guiden beskriver Kanban som en strategi for å optimalisere flyten av verdi gjennom en prosess.

Kjernen er:

• definer og visualiser arbeidsflyten
• kontroller hvor mye arbeid som er startet samtidig
• håndter aktive oppgaver og blokkeringer
• mål flyt og forbedre systemet fortløpende

Et Kanban-brett er derfor mer enn kolonnene «skal gjøres», «pågår» og «ferdig». Teamet trenger også tydelige regler for når arbeid kan flyttes, og en bevisst grense for arbeid under utførelse.

En enkel tommelfingerregel

• Velg Scrum når teamet trenger en felles leveranserytme og tydelige hendelser for inspeksjon og tilpasning.
• Velg Kanban når teamet trenger kontinuerlig flyt og bedre kontroll på køer og kapasitet.
• Kombiner dem bare når hver praksis løser et konkret problem. Flere ritualer er ikke et mål i seg selv.

Slik bruker AI- og programvareteam smidig metodikk

Start med én verdifull usikkerhet, ikke en lang funksjonsliste. Den viktigste oppgaven er å gjøre neste læringssteg lite nok til at teamet kan levere, observere og justere uten å vente på hele løsningen.

1. Formuler et produktmål

Beskriv hvilken endring dere ønsker for brukeren eller virksomheten. Et godt mål gir retning uten å låse løsningen.

Eksempel: «Kundeservice skal kunne finne et relevant svarutkast med tydelig kildegrunnlag.» Det er mer styrende enn «bygg en chatbot», fordi flere løsningsalternativer fortsatt er åpne.

2. Gjør antakelsene synlige

Skill mellom det dere vet, det dere tror og det dere må teste. For et AI-produkt kan usikkerheten ligge i datakvalitet, modellatferd, brukerflyt, responstid, kostnad eller behovet for menneskelig kontroll.

Prioriter antakelsen som kan gjøre resten av løsningen irrelevant. Test den før dere investerer i brede integrasjoner eller et polert grensesnitt.

3. Del arbeidet i vertikale steg

Et godt steg går gjennom nok av løsningen til at en bruker eller interessent kan vurdere det. Unngå å dele planen i lange, isolerte faser for design, backend, modell og frontend.

Et første steg kan for eksempel være:

1. hent inn et avgrenset sett med godkjent innhold
2. generer et svarutkast for én konkret oppgave
3. vis hvilke kilder utkastet bygger på
4. la en fagperson godkjenne eller avvise
5. registrer hvorfor svaret ble avvist

Da lærer teamet om både teknologi, kvalitet og arbeidsflyt i samme sløyfe.

4. Definer hva «ferdig» betyr

«Ferdig» må beskrive kvalitet, ikke bare at koden er skrevet. Definisjonen bør være kort, synlig og streng nok til at teamet kan stole på leveransen.

For et AI- eller programvareinkrement kan den omfatte:

• akseptansekriterier er verifisert
• relevante tester er kjørt
• sikkerhet og personvern er vurdert
• logging og overvåking er på plass der det trengs
• endringen kan demonstreres i et realistisk scenario
• kjente begrensninger er dokumentert
• ansvar for videre oppfølging er tydelig

5. Vis frem faktisk produkt

En gjennomgang bør handle om det som virker, ikke om prosent ferdigstilt. La brukere og beslutningstakere prøve eller se en realistisk arbeidsflyt. Samle konkrete observasjoner og oppdater prioriteringene etterpå.

6. Forbedre arbeidsmåten

Retrospektivet skal ende i en liten endring teamet faktisk prøver. Det kan være en lavere grense for arbeid under utførelse, raskere tilgang til en fagperson eller en tydeligere kvalitetskontroll før demonstrasjon.

Smidig arbeid med AI krever en egen evalueringssløyfe

Et AI-team må evaluere både produktet og modellatferden. En funksjon kan være teknisk komplett og likevel gi svar som er irrelevante, inkonsistente eller uegnede i den faktiske situasjonen.

Bygg derfor evaluering inn i hver iterasjon:

• lag et representativt sett med oppgaver eller eksempler
• beskriv hva et godt og uakseptabelt resultat er
• vurder kvalitet, responstid og kostnad sammen
• registrer versjoner av modell, instruksjoner og datagrunnlag
• bruk menneskelig kontroll der konsekvensen av feil krever det
• gjenta evalueringen når en av komponentene endres

En demo med noen få gode svar er ikke det samme som en robust evaluering. Teamet trenger en repeterbar måte å oppdage om en endring faktisk forbedrer helheten eller bare flytter problemet.

Roller og beslutninger i et smidig team

Smidighet krever tydeligere beslutningsmyndighet, ikke mindre styring. Teamet må vite hvem som prioriterer verdi, hvem som avgjør faglig kvalitet, og hvem som håndterer teknisk risiko.

En praktisk ansvarsdeling kan være:

• Produkteier: setter mål, prioriterer produktkøen og avklarer hva som gir verdi.
• Tverrfaglig team: finner ut hvordan målet kan nås og leverer et ferdig steg.
• Fagpersoner og brukere: vurderer om løsningen fungerer i praksis.
• Tekniske ansvarlige: ivaretar arkitektur, sikkerhet, drift og vedlikeholdbarhet.
• Leder eller sponsor: setter rammer, fjerner organisatoriske hindringer og følger opp effekt.

Unngå en styringsgruppe som detaljprioriterer hver oppgave. Ledelsen bør holde teamet ansvarlig for mål, risiko og læring, mens teamet får handlingsrom til å løse problemet.

Hva bør dere måle?

Mål om arbeidet flyter, om kvaliteten holder og om produktet skaper ønsket effekt. Aktivitet alene sier lite om verdi.

Bruk et lite sett med signaler:

• Effekt: fullfører brukeren oppgaven, og oppstår den ønskede endringen?
• Kvalitet: hvilke feil når brukeren, og hvilke typer feil gjentar seg?
• Flyt: hvor lang tid går fra arbeid starter til det er ferdig?
• Pågående arbeid: hvor mange oppgaver er startet samtidig?
• Forutsigbarhet: blir de fleste oppgaver ferdige innenfor en rimelig og kjent variasjon?
• Læring: hvilke antakelser ble bekreftet, avkreftet eller stående åpne?

For AI bør dere i tillegg følge produktspesifikke kvalitetskriterier. Ett samlet gjennomsnitt kan skjule alvorlige feil i viktige situasjoner, så se også på kategorier og avvik.

Vanlige feil når team innfører smidig metodikk

De fleste problemer skyldes at teamet kopierer ritualene uten å endre beslutningene. Et daglig møte gjør ikke en lang og låst leveranseplan smidig.

Unngå disse mønstrene:

• Sprinten er en minifossefallmodell: analyse først, så utvikling, så testing helt på slutten.
• Alt haster: produktkøen er ikke prioritert, og teamet starter mer enn det avslutter.
• Ingen ekte brukertilbakemelding: interne statusmøter erstatter observasjon av faktisk bruk.
• Teknisk kvalitet utsettes: test, sikkerhet og drift blir en egen oppryddingsfase.
• Produkteier mangler mandat: prioriteringer må godkjennes i flere ledd.
• Planen endres hver dag: smidig blir brukt som unnskyldning for tilfeldig styring.
• Seremoniene blir målet: teamet måler oppmøte og hastighet, men ikke effekt eller læring.

En enkel plan for de første fire ukene

Begynn lite, lever noe ekte og bruk erfaringen til å velge neste steg. Ikke start med en omfattende omorganisering.

Uke 1: mål og flyt

• velg ett avgrenset produktmål
• kartlegg veien fra idé til ferdig leveranse
• opprett en prioritert produktkø
• bli enige om hva «ferdig» betyr
• velg Scrum, Kanban eller en enkel kombinasjon ut fra arbeidsformen

Uke 2: første leverbare steg

• velg den viktigste usikkerheten
• del arbeidet i et lite, vertikalt steg
• begrens antall oppgaver som kan være i gang
• avklar hvem som kan gi rask tilbakemelding

Uke 3: demonstrasjon og læring

• demonstrer en fungerende arbeidsflyt
• registrer observasjoner, ikke bare meninger
• oppdater produktkøen
• fjern eller nedprioriter arbeid som ikke lenger er relevant

Uke 4: forbedre systemet

• gjennomfør et retrospektiv
• velg én forbedring av arbeidsmåten
• se på flyt, kvalitet og effekt
• planlegg neste læringssløyfe

Etter fire uker bør dere ikke først og fremst spørre om teamet «gjør smidig riktig». Spør om dere leverer mindre steg, lærer tidligere og tar bedre prioriteringsbeslutninger.

Hva betyr smidig metodikk kort forklart?

Smidig metodikk betyr å utvikle i små steg, hente tilbakemeldinger ofte og justere planen når teamet lærer noe nytt. Retningen er tydelig, men veien dit er ikke detaljlåst.

Er Scrum det samme som smidig?

Nei. Scrum er ett rammeverk som kan støtte smidig arbeid. Smidig er et bredere sett med verdier og prinsipper. Kanban, Extreme Programming og andre praksiser kan også brukes.

Betyr smidig at man ikke planlegger?

Nei. Smidige team planlegger ofte, men på flere nivåer og med ulik detaljgrad. Nære oppgaver er konkrete, mens arbeid lenger frem holdes mer åpent slik at ny kunnskap kan påvirke valgene.

Hvor lang bør en sprint være?

Scrum-guiden setter sprinten til én måned eller kortere. I praksis velger teamet en fast lengde som gir hyppig inspeksjon uten unødvendig administrasjon. Lengden bør ikke endres fra sprint til sprint for å passe mengden arbeid.

Når bør man ikke bruke smidig metodikk?

En fullt smidig modell gir mindre verdi når krav, løsning og rekkefølge er stabile, endringer er svært dyre, og det ikke finnes meningsfulle del-leveranser. Da kan en sekvensiell eller hybrid modell være bedre.

Hvordan fungerer smidig metodikk for AI-prosjekter?

AI-prosjekter bruker de samme korte læringssløyfene, men må i tillegg evaluere modellatferd systematisk. Teamet bør teste representative eksempler, definere akseptabel kvalitet, spore endringer i modell og datagrunnlag og bruke menneskelig kontroll der risikoen krever det.

Kom i gang med en arbeidsform som passer produktet

Smidig metodikk virker først når mål, ansvar og tilbakemeldinger henger sammen. Velg praksiser som løser de faktiske flaskehalsene deres, og behold bare ritualer som gir bedre beslutninger eller bedre flyt.

Trenger dere hjelp til å strukturere et AI- eller programvareinitiativ rundt små, målbare leveranser? Start en samtale om mål, risiko og en passende arbeidsform.