Förslag till införande — Innovationssprint som arbetssätt

Sammanfattning

Fyra principer som bär hela införandet.

Pilotsprinten landade i ett enhälligt ja från verksamheten — och i en gemensam slutsats: vi ska göra det här i ordinarie arbete. Utvärderingen pekar på fyra slutsatser som tillsammans utgör grunden för planen.

Princip 01

Sprinten är ett verktyg — inte en universalmetod.

Det är skarpast när vi ska testa en hypotes, utmana ett pågående arbete som inte går enligt plan, eller starta ett längre projekt med kraft. Formatet anpassas efter frågan — en utredande sprint kan räcka i 2–3 dagar, medan en innovationssprint där en hypotes ska testas och en första version byggas behöver två veckor.

Princip 02

Sprintkapaciteten måste budgeteras.

Vi behöver veta hur många sprintar koncernen klarar per kvartal och säkra dem som resurssäkrade slottar i ordinarie planering — och kunna aktivera dem på begäran när beredning eller projektakuter kräver det.

Princip 03

Arbetssättet ska däremot bli normen.

Alla utvecklingsprojekt framåt — även de som löper över tre månader eller mer — ska arbeta tvärfunktionellt, med prototypdriven start (fas 0), standups, demos och löpande leveranser. Beställning vid start och leverans vid slut fasas ut.

Princip 04

Prototypdriven utveckling — i fler roller än utvecklarens.

Projektledare, verksamhetsutvecklare och kommunikatörer ska tidigt och snabbt forma egna prototyper för att bearbeta behov och tankar — innan ett projekt ens finns. AI gör det möjligt att bygga första klickbara versionen på en eftermiddag.

01 — Tre nivåer av införande

En metodik — tre olika sätt den verkar i organisationen.

Innovationssprinten är inte en sak. Den verkar på tre olika sätt: som det skarpa, tidsavgränsade verktyget, som arbetsprincipen i alla projekt, och som ett lärandeverktyg i beredningen. Att skilja på dem är centralt — det är vad som avgör om införandet landar rätt. Längden på det skarpa formatet anpassas efter behovet: 2–3 dagar för utredande spår, två veckor för en full innovationssprint där en första version också ska byggas.

        Nivå 01
Sprinten som verktyg
— det skarpa formatet
Innovationssprint i skarpt läge — det format som pilotsprinten följde. Tvärfunktionellt team, daglig standup, demo så snart något är värt att visa, prototypdriven start. Två veckor är fullformatet när hypotesen ska testas och en första version byggas; utredande spår kan kortas till 2–3 dagar.
När
Hypotestest, projektomstart, kraftfull projektstart
Tid
2 v full sprint (2–3 d utredande) + ~1 v före + ~1 v efter
Output
Validerad lösning, lärande, kunskapsöverföring
Säkras via
Kapacitetsmodellen — planerade slottar och on-demand


        Nivå 02
Arbetssättet som norm
— hur alla projekt ska arbeta
Innovationssprintens principer applicerade i alla utvecklingsprojekt, oavsett längd. Tvärfunktionellt team, direkt verksamhetskontakt, standup, demos minst varannan vecka — även i 3-månadersprojekt.
När
Alla nya utvecklingsprojekt — alltid när vi bygger digitalt
Tid
Hela projektets längd — t.ex. 3 månader+
Output
Färdig produkt levererad löpande, inte vid projektslut
Säkras via
Ordinarie projektplanering — arbetssätt förvalt


        Nivå 03
Sprinten i beredningen
— sprint som beslutsunderlag
Sprint som lärandeverktyg inför ett strategiskt beslut. När osäkerheten är stor och pappersutredning inte räcker — testa i ett tidsavgränsat format och fatta beslut på en validerad grund. För rent utredande spår räcker ofta 2–3 dagar; ska beslutsunderlaget även omfatta en byggd prototyp behövs två veckor.
När
Stora osäkerheter, två lösningsspår, otydlig kravbild
Tid
2–3 d utredande, upp till 2 v med byggande
Output
Validerad eller falsifierad hypotes — beslutsunderlag
Säkras via
Reserverad andel av on-demand-kapaciteten

      

02 — Prototypdriven utveckling

Prototypdriven utveckling, grunden till allt.

Innovationssprinten startar med en fungerande prototyp redan på dag ett. Men prototypen är inte unik för sprinten — den är det vardagsverktyg som låter oss testa innan vi bygger klart, och som måste finnas i fler roller än utvecklarens.

Förskjutningen

Från kostnad-att-testa → till kvalitet-i-det-vi-väljer-att-bygga.

När en första klickbar prototyp tar några timmar — inte veckor — kan vi testa idéer med faktiska användare innan formell utveckling startar. Det innebär en grundläggande förändring av tidiga skedet: projektledare och verksamhetsutvecklare ska kunna bygga sina egna första versioner, inte beställa dem av andra.

Nivå 01

1–4 timmar

Idé & visualisering

Testa ett flöde visuellt med berörda innan projektet ens startar — bearbeta behov och tankar i klickbar form.

För vem

Alla roller — projektledare, verksamhetsutvecklare, kommunikatörer

Verktyg

Lovable · Claude.ai · v0 by Vercel

Kompetens

Ingen krävs

Begränsning

UI-prototyp — inte data eller integrationer

Nivå 02

1–3 dagar

Körbar lösning

Testa med riktiga data, riktiga användare, riktiga arbetsflöden. Prototyp som klarar verklig friktion.

För vem

Tekniskt intresserade — verksamhetsutvecklare med teknikvana, jr-utvecklare

Verktyg

Claude Code · WSL · Docker / Podman

Kompetens

Tekniskt intresse

Begränsning

Inte produktionsfärdig — saknar säkerhetsgranskning

Nivå 03

Sprinttempo

Produktionsutveckling

Leverera live-lösning genom säkerhets- och kvalitetsgrindar. Detta är Fas 1 i en innovationssprint.

För vem

Professionella utvecklare — i sprintteam eller ordinarie utvecklingsprojekt

Verktyg

Claude Code i VS Code · GitHub Copilot · CI/CD

Kompetens

Utvecklarroll med ansvar för säkerhet och skalbarhet

AI:s roll

Accelerator — inte ersättare. Utvecklaren granskar.

Vi testar innan vi bygger klart — och verksamheten är med från första klick, inte från första kravspec.

Hela metodiken med exempel, verktygsval och stegvisa guider finns i AI-guiden. Läs mer på AI-guiden

03 — Kapacitetsmodell

Hur många sprintar klarar koncernen per kvartal?

Sprintslottar konkurrerar om samma personer som ordinarie utveckling. Utan en kapacitetsmodell blir sprintarna antingen något som "sker när det finns tid över" — i praktiken aldrig — eller en faktor som tränger undan löpande arbete oplanerat. Båda sänker effekten.

En full innovationssprints resursförbrukning · 5–7 personer i ~4 veckor

Fas 0

~1 vecka

Fas 1

2 veckor

Fas 2

~1 vecka

Förberedelse · 10–20 % av teamets tid. Prototyp, arkitekturdialog, deploykedja, verksamhetsroll.

Genomförande · 100 % av teamets tid. Den klassiska sprintrytmen.

Avslutning · 10–20 % av teamets tid. Utvärdering, kunskapsöverföring, processförfining.

Utredande spår är kortare: Fas 1 kan kortas till 2–3 dagar när det främst handlar om att kartlägga eller validera utan att bygga en första version. Fas 0 och Fas 2 förblir liknande till sin karaktär, men skalar ned i omfattning. En slott i kapacitetsmodellen avser fullformatet — utredande sprintar drar mindre av kapaciteten.

Tre spår — hybridmodell

En del av kapaciteten är planerade slottar i ordinarie planering. En mindre del hålls som on-demand. Och allt utvecklingsarbete drivs enligt nivå 2.

Spår 1 · Planerade

2 sprintar / kvartal

Resurssäkrade slottar

Ligger i den ordinarie planeringen. Ämnet bestäms i god tid eller senast vid kvartalsstart. Team allokeras som om det vore ett ordinarie projekt.

Spår 2 · On-demand

1 reserverad / kvartal

Aktiveras vid behov

Kapaciteten reserveras men låses inte. Triggers: pågående projekt går snett, beredningen behöver beslutsunderlag, ny idé behöver valideras snabbt.

Spår 3 · Normen

∞ alla projekt

Sprintinspirerat arbetssätt

Inga separata slottar — det är så projekten arbetar. Standardläge för all utveckling. Hanteras inom ordinarie projektresurssäkring.

Startförslag: 2 planerade + 1 reserverad sprint per kvartal. Efter Q1 och Q2 utvärderas kapaciteten utifrån faktisk efterfrågan och genomförandeförmåga, och justeras uppåt eller nedåt. Det viktiga är inte exakt antal — det är att kapaciteten är resurssäkrad, synlig i den ordinarie planeringen, och att vi inte överbokar oss.

04 — När en sprint är rätt verktyg

Sex situationer som motiverar en sprint.

För att slottarna ska användas på rätt sätt definierar vi tydliga triggers. Det gör det enklare för beredning och projektkontor att avgöra om en idé hör hemma som sprint eller som vanlig projektutveckling.

Hypotestest

"Skulle en AI-assistent på intranätet faktiskt minska handläggningstiden?" — bygg en prototyp och låt verksamheten testa i två veckor.

Projektomstart

Pågående projekt har tappat tempo, kravbilden är otydlig, leveranserna missar målet. En sprint testar ett alternativt angreppssätt.

Projektstart med kraft

Inför ett 6-månadersprojekt körs första två veckorna som sprint. Efteråt övergår projektet till nivå 2-rytm. Sparar månader.

Beredningsunderlag

Två lösningsspår är möjliga. Beredningen kan inte avgöra på papper. En sprint testar — beslutet fattas på validerade grunder.

Verksamhet kan inte formulera kravbild

Verksamheten vet att de har ett behov men kan inte beskriva det. En prototyp i sprintformat hjälper dem att se vad de faktiskt vill ha.

Strategisk eller teknisk osäkerhet

Ny teknik, nytt arkitekturmönster, integration mot okänt system. Sprinten validerar genomförbarhet innan vi binder upp ett helt projekt.

05 — Integration med befintliga processer

Sprintarna ska passa in i det vi redan har.

Sundsvalls kommunkoncern har en utvecklingsprocess med beredning och en teknisk förvaltning. Sprintarna måste haka i — inte ersätta — dessa rutiner.

04.1

Utvecklingsprocessen & beredningen

Beredningen äger fortsatt bedömningen av idéer. Sprinten blir ett verktyg som beredningen kan välja att använda.

Sprint som beslutsunderlag inför stora projekt
Sprint som lärande-investering — målet är lärandet
Minst en planerad slott per halvår reserveras för beredningens behov

04.2

Tekniska förvaltningen & driften

Lärdom från pilotsprintens dag 6: produktion behöver delta när val påverkar IT-infrastrukturen.

Drift på standups när tekniken kräver det
Fas 2 inkluderar formell överlämning till förvaltning
Inga infrastrukturella överraskningar efter sprinten

06 — Roller

Vem gör vad i en sprint.

Varje sprint kan se lite olika ut och kräva olika roller. Nedan listas de roller som normalt är aktuella — men typen av sprint påverkar vilka som faktiskt deltar. Sprintledaren håller ihop rytmen, men inget mellanlager mellan verksamhet och utvecklare.

Det viktiga är att teamet inte blir för stort. Tänk i termer av att alla ska rymmas i samma rum varje dag under sprinten — det är där det intensiva, gemensamma arbetet hela vägen igenom blir möjligt.

Sprintledare

Håller ihop daglig rytm, röjer hinder, äger relationen mot verksamheten. Inte projektledare i klassisk mening — närmare en facilitator/spelande tränare.

Verksamhetsdeltagare

Sitter med i teamet — inte vid sidan om. Tillgänglig dagligen för dialog och beslut. Mängd närvaro avvägs i Fas 0 utifrån vad som ska byggas.

Tvärfunktionellt utvecklarteam

Inga separata backend- eller frontend-deltagare. Var och en kan röra sig över hela stacken. AI används aktivt som accelerator.

UX / design

Sitter i teamet vid behov, särskilt när lösningen har starka användarflöden. Designar i löpande dialog, inte i förskott.

Arkitekt

Säkerställer arkitekturella val i Fas 0. Närvarar löpande på standups eller på frågor under sprinten. Rådgivande deltagare, inte beslutslager.

Produktion / drift

Deltar i standups vid behov — särskilt när val påverkar infrastruktur. Säkerställer att deploykedjor och miljöer fungerar inför Fas 0.

Sprintägare

Verksamhetschef eller motsvarande som äger frågan sprinten ska besvara. Tar emot resultatet och äger nästa steg.

07 — Förutsättningar

Det som måste finnas på plats.

Sprinten lyckas inte med fel förutsättningar — oavsett hur duktigt teamet är. Sex punkter är icke-förhandlingsbara och måste vara säkrade innan sprinten startar.

Egen deploykedja till dedikerad testbädd

Teamet ska kunna deploya förändringar själva, flera gånger om dagen, utan att vänta på andra team. Pilotsprinten använde sundsvall.dev — samma pattern bör skalas.

Tvärfunktionell kompetens i teamet

Backend, frontend, verksamhetsdomän, infrastruktur — allt ska kunna lösas inom teamet utan väntan på andra resurser.

AI-verktyg på plats och accepterade

AI är inte en bonus — det är en del av arbetssättet. Tillgång till relevanta tjänster (Eneo, Claude, Copilot) måste vara säkrad.

Mandat att fatta beslut inom teamet

Sprinten överlever inte om varje val ska eskaleras uppåt. Beslutsmandatet är delegerat innan sprinten startar.

Eliminering av mellanlager

Mellanled mellan verksamhet och utvecklare tas bort — eller minst kortsluts. Projektledaren får en annan roll än beställare-mottagare-tolk.

Verksamhetstid säkrad

Verksamhetsdeltagaren måste vara tillgänglig dagligen. Halv sprinttid räknas inte. Sprintägaren tar ansvar för att frigöra dem.

08 — Stegvis införande

Två steg från beslut till stabilt läge.

Tempot kan justeras uppåt eller nedåt efter varje utvärdering. Stegen är inte fasta storlekar — de är checkpoints.

01

Direkt efter beslut

Arbetssätt på plats — 1–2 sprintar genomförs

Sprintledarroll definierad och bemannad
Deltagarintroduktion (halvdag) framtagen
Prototypintroduktion för PM & verksamhetsutvecklare — nivå 1-verktyg på plats
Deploykedjor och AI-tjänster verifieras
1–2 sprintar genomförs i skarpt läge
Förutsättningar kvalitetsgranskas inför varje sprint
Beredningen kan aktivera minst en sprint

02

När basen ligger

Finjustera och skala vidare

Utvärdering efter första sprintarna — justera vad som behövs
Alla nya projekt startar enligt nivå 2
Andra omgång deltagarintroduktion — bredare deltagarbas
Pågående projekt utan nivå 2 — planera om
Prototypning används i tidigt skede inför beredning
Kunskapsöverföring och insikter dokumenteras systematiskt
Större utvärdering — beslut om strukturella förändringar

09 — Mätning och uppföljning

Få indikatorer — noga valda.

Det här är ett arbetssätt — inte ett system. Mätningen ska därför inte fastna i finmaskig KPI-jakt. Några få indikatorer följs systematiskt; resten samlas som kvalitativ insikt.

Kvantitativt

Det som räknas i siffror

Antal genomförda sprintar per kvartal — planerade respektive on-demand-aktiverade.
Andel utvecklingsprojekt enligt nivå 2 — mål: 100 % över tid.
Tid från idé till verksamhetstest — antal dagar från sprintbeslut till första demo.
Andel sprintar som lett till fortsatt projekt vs avbrytning — båda är värdefulla utfall.

Kvalitativt

Det som lärs systematiskt

Sprintdagbok per sprint — beslut, lärdomar, utveckling dag för dag.
Retrospektiv direkt efter varje sprint — samlat halvårsvis till en organisationsbild.
Verksamhetens upplevelse — uppföljning med sprintägaren två månader efter.
Insikter som påverkar gemensam infrastruktur — samlas och prioriteras separat.

10 — Risker och hantering

Sju risker att aktivt hantera.

Riskerna är mestadels mjuka och kulturella — de som handlar om att arbetssättet glider tillbaka i gamla mönster om vi inte aktivt motverkar det.

R1

Sprint blir det enda verktyget

Långsiktiga, komplexa projekt pressas in i två-veckorsformat och misslyckas.

Hantering

Tydliga triggers för när sprint är rätt verktyg. Beredning och projektkontor utbildas i att skilja på nivå 1, 2 och 3.

R2

Arbetssättet införs inte helhjärtat

Vi inför formellt standups och demos men behåller backend/frontend-uppdelning. Effekten uteblir.

Hantering

Förutsättningarna är icke-förhandlingsbara. De kvalitetsgranskas innan ett projekt godkänns.

R3

Otillräcklig kapacitet

Planerade slottar äts upp av akuta omstarter. Beredningen får aldrig sprintkapacitet.

Hantering

Reservera minst en planerad slott per halvår för beredning. Säg nej till sprintar när kapaciteten är full — vänta är ett legitimt svar.

R4

Verksamheten har inte tid att delta

Sprinten genomförs utan verksamheten och tappar sin kärna. Resultatet träffar inte behovet.

Hantering

Verksamhetens deltagande säkras innan sprinten startar — sprintägaren har detta ansvar. Om verksamheten inte kan delta — skjut sprinten.

R5

Mellanlager återetableras tyst

Direktkontakt ersätts av statusmöten, kravdokument och projektledartolkning. Det viktigaste tappas.

Hantering

Princip "noll avstånd" är explicit del av kvalitetsgranskningen. Halvårsutvärdering granskar specifikt om mellanlager smyger sig tillbaka.

R6

Tekniska förutsättningar saknas

Det saknas förutsättningar för 100 % kontroll i en deploykedja, vilket skapar beroenden till IT-drift och bromsar sprinten.

Hantering

Tydligt uppdrag att säkerställa de tekniska förutsättningarna mot IT-produktion — alternativt säkra alternativa vägar om förutsättningarna inte kan uppfyllas i tid.

R7

Insikter om gemensam infrastruktur tappas

Sprintar genererar generella insikter (frontend-ramverk, arkitekturmönster) som faller mellan stolarna.

Hantering

Etablera ett mottagarforum (utvecklingsråd eller arkitekturråd) som tar emot, prioriterar och äger generella insikter från sprintar.

11 — Beslutspunkter

Sex punkter som behöver beslut innan införandet startar.

Några kan tas i ett enda forum, andra behöver delas upp. Den slutliga retrospektiven från pilotsprinten bör tas in i sista revideringen innan beslut fattas.

1

Bekräftelse av tre-nivå-modellen som det gemensamma ramverket. Sprint som verktyg · Arbetssätt som norm · Sprint som beredningsverktyg.

2

Beslut om kapacitetsmodellen och startnivå. Förslag: 2 planerade + 1 reserverad sprint per kvartal.

3

Beslut om att alla nya utvecklingsprojekt från Q2 ska arbeta enligt nivå 2. Och att förutsättningarna kvalitetsgranskas innan ett projekt godkänns.

4

Bemanningsbeslut för sprintledarroll och utbildningsansvarig. För deltagarintroduktionen som tas fram inför första sprint.

5

Investeringsbeslut för förutsättningar som saknas. Fler dedikerade testbäddar, AI-verktygslicenser, eventuella infrastrukturinvesteringar.

6

Mottagarforum för generella insikter. Vem äger tekniska och organisatoriska insikter när de uppstår i sprintarna.