Hvorfor smidig?

Planstyrt (fossefall) gjennomføring bygger på at kravene kan spesifiseres ferdig før arbeidet starter: analyse → design → utvikling → test → overlevering. Modellen fungerer godt når leveransen er kjent og forutsigbar, for eksempel et bygg med detaljprosjektert tegningsgrunnlag. Den fungerer dårlig når kunden ikke vet nøyaktig hva hun vil ha før hun ser noe, og når teknologien endrer seg raskere enn prosjektplanen.

Smidig (agil) gjennomføring snur logikken: i stedet for å låse omfanget og la tid og kostnad flyte, låses tid og kostnad (faste team, faste sprinter), mens omfanget prioriteres løpende. Det smidige manifestet setter opp fire verdipar der venstresiden vektlegges tyngst:

Individer og samspill framfor prosesser og verktøy
Fungerende programvare framfor omfattende dokumentasjon
Samarbeid med kunden framfor kontraktsforhandlinger
Å reagere på endringer framfor å følge en plan

Merk formuleringen: høyresiden har fortsatt verdi. Smidig betyr ikke «ingen plan» eller «ingen dokumentasjon» — det betyr at planen revideres når ny kunnskap kommer.

Scrum-rammeverket

Scrum er den mest utbredte konkretiseringen av smidig. Rammeverket består av tre roller, tre artefakter og fire faste møter.

Roller

Produkteier eier produktkøen, prioriterer hva som gir størst verdi, og er teamets ene kontaktpunkt mot forretningssiden. Produkteieren bestemmer hva.
Scrum master er en tjenende leder som sikrer at rammeverket følges, fjerner hindringer og skjermer teamet mot forstyrrelser. Scrum master er ikke sjef og fordeler ikke oppgaver.
Utviklingsteamet (typisk 3–9 personer) er tverrfaglig og selvorganiserende. Teamet bestemmer hvordan og hvor mye det tar inn i en sprint.

Artefakter

Produktkø (product backlog): prioritert liste over alt som ønskes, uttrykt som brukerhistorier («Som saksbehandler vil jeg … slik at …»). Alltid åpen for endring.
Sprintkø (sprint backlog): det utsnittet teamet forplikter seg til i inneværende sprint. Denne fryses — ny funksjonalitet må vente til neste sprint.
Inkrement: et potensielt leveringsklart produkt ved slutten av hver sprint, som tilfredsstiller lagets definisjon av ferdig (kodet, testet, dokumentert, godkjent).

Møter

Sprintplanlegging i starten av sprinten: produkteier presenterer prioritet, teamet estimerer og velger omfang.
Daglig scrum, maks 15 minutter, stående: hva gjorde jeg i går, hva gjør jeg i dag, hva hindrer meg. Dette er et koordineringsmøte for teamet, ikke et statusmøte til lederen.
Sprintdemo (review) ved sprintslutt: inkrementet vises fram for produkteier og interessenter, som gir tilbakemelding som påvirker prioriteringen videre.
Retrospektiv etter demoen: teamet forbedrer sin egen arbeidsmåte, og velger typisk ett til to konkrete tiltak til neste sprint.

Sprintlengden er fast, oftest to til fire uker. Den faste rytmen er selve poenget: den gir hyppige kontrollpunkter der kunden kan korrigere kursen med lav kostnad.

Eksempel 1 — Fartsmåling (velocity) og prognose

Et prosjekt har estimert produktkøen til 480 storypoeng. Sprintlengden er to uker. Etter tre sprinter har teamet levert henholdsvis 52, 44 og 48 poeng.

Levert så langt: \(52 + 44 + 48 = 144\) poeng på 6 uker

Gjennomsnittlig fart: \(\frac{144}{3} = 48\) poeng per sprint

Gjenstående: \(480 - 144 = 336\) poeng

Antall sprinter som gjenstår: \(\frac{336}{48} = 7\) sprinter \(= 14\) uker

Forventet total varighet: 6 + 14 = 20 uker

Fordi farten varierer, bør prognosen gis som et spenn. Med den laveste observerte farten (44) trengs \(336/44 = 7{,}6 \rightarrow 8\) sprinter (16 uker), med den høyeste (52) trengs \(336/52 = 6{,}5 \rightarrow 7\) sprinter (14 uker).

Konklusjon: prosjektet ferdigstilles om lag i uke 20–22.

Kontroll: dersom produktkøen vokser med 60 nye poeng underveis, blir gjenstående \(336 + 60 = 396\) poeng, altså \(396/48 = 8{,}25 \rightarrow 9\) sprinter. Omfangsvekst slår rett ut i tid når farten er gitt — det er nettopp derfor produkteieren må fjerne noe fra køen hvis noe nytt skal inn.

Eksempel 2 — Nedbrenningsdiagram (burndown)

En sprint har 90 poeng i sprintkøen og varer ti arbeidsdager. Idealkurven faller da med \(90/10 = 9\) poeng per dag. Etter dag 6 er 42 poeng gjort.

Ideelt gjenstående etter dag 6: \(90 - 6 \cdot 9 = 36\) poeng

Faktisk gjenstående: \(90 - 42 = 48\) poeng

Avvik: \(48 - 36 = 12\) poeng bak plan

Nødvendig fart de siste fire dagene: \(\frac{48}{4} = 12\) poeng per dag mot 9 i planen

Tiltak: teamet må enten øke farten (sjelden realistisk), eller sammen med produkteieren ta ut lavest prioriterte historier av sprinten. Å ta ut omfang er det normale og legitime svaret i Scrum — det er kvaliteten og sprintlengden som er fast.

Scrum, Kanban og hybride løsninger

Kanban har ingen sprinter og ingen faste roller. Arbeidet trekkes gjennom en tavle med kolonner, og styringsmekanismen er en grense for arbeid under utførelse (WIP-grense) i hver kolonne. Kanban egner seg for jevn strøm av oppgaver med varierende hastegrad (drift, forvaltning, brukerstøtte), mens Scrum egner seg for utvikling mot et mål der man vil ha faste leveransepunkter.

	Scrum	Kanban
Rytme	Faste sprinter	Kontinuerlig flyt
Styringsmekanisme	Sprintforpliktelse	WIP-grense
Roller	Tre definerte roller	Ingen påkrevde
Endring underveis	Ikke i inneværende sprint	Når som helst
Nøkkeltall	Fart per sprint	Gjennomløpstid

I praksis er de fleste store prosjekter hybride: et planstyrt hovedløp med faseoverganger og beslutningsporter, der utviklingsleveransene kjøres smidig innenfor hver fase. Et byggeprosjekt kan ikke støpes iterativt, men de digitale delene av det (varslingssystem, adgangskontroll, driftsovervåking) kan utmerket godt utvikles i sprinter.

Når egner smidig seg — og når gjør det ikke det?

Smidig fungerer best når (a) kravene er uklare eller vil endre seg, (b) leveransen kan deles i verdifulle biter, (c) kunden kan stille med en tilgjengelig og beslutningsdyktig produkteier, og (d) teamet kan jobbe dedikert. Smidig fungerer dårlig når leveransen er udelelig, når kravene er fastsatt av lov eller kontrakt, eller når kunden ikke har kapasitet til å delta hyppig.

Den vanligste innføringsfeilen er «scrum uten produkteier»: teamet holder daglige møter og kaller iterasjonene sprinter, men ingen prioriterer køen, og alt haster. Da mister man den viktigste gevinsten — at det viktigste blir gjort først.

Smidig i kontrakt og i prosjekter på tvers av organisasjoner

En smidig leveranse passer dårlig med en fastpriskontrakt på detaljert kravspesifikasjon. Vanlige tilpasninger er målpris med deling av avvik, betaling per sprint (regningsarbeid med tak), eller en trinnvis kontrakt der første trinn er en avklaringsfase. Kontrakten må dessuten regulere hvem som fyller produkteierrollen, hvor ofte kunden må delta, og hva «ferdig» betyr — ellers blir definisjonen av ferdig en tvist ved sluttoppgjøret.

Når teamet er delt mellom flere organisasjoner, gjerne i ulike land og tidssoner, må rammeverket suppleres: overlappende arbeidstid for det daglige møtet, felles digital tavle som er eneste sannhetskilde, videokamera på i demoene, og et fysisk oppstartsmøte hvis det i det hele tatt er mulig. Uten dette forsvinner den uformelle kommunikasjonen som smidig arbeid bygger på.

Studieguide: Smidig prosjektledelse (Scrum)