Sprint pågår — Dag 1 av 10 — Startdatum 2026-04-13
Sundsvalls kommun

Innovations­sprint
— ett nytt arbetssätt

En tvåveckors sprint för att utforska och testa ett snabbare, närmare och mer tvärfunktionellt sätt att utveckla digitala tjänster. Denna sida dokumenterar processen steg för steg — som en levande instruktion.

Varaktighet 2 veckor (10 arbetsdagar)
Teamstruktur Tvärfunktionellt
Metod Prototypdriven utveckling
Bakgrund

Varför behövs ett nytt arbetssätt?

Sundsvalls kommun har historiskt arbetat med traditionell agil utveckling inspirerad av stora ramverk som SAFe, utan att ha valt ett specifikt ramverk. Utvecklingsteamen har delats upp utefter kompetensområde — backend och frontend — med flera lager av roller mellan verksamheten och utvecklarna: projektledare, verksamhetsutvecklare, lösningsarkitekter och teamledare.

Verksamheten, som är ovan vid teknisk utveckling, har ofta svårt att formulera krav tidigt i processen. Kravbilden förändras löpande, vilket skapar osynk som leder till förseningar, budgetöverskridanden och resultat som inte möter verksamhetens faktiska behov.

Tidigare utmaningar
  • Projekt drar ut på tiden och håller inte budget
  • Uppdelning i backend- och frontend-team skapar beroenden och väntetider
  • Flera lager mellan verksamhet och utvecklare försvårar kommunikation
  • Verksamheten har svårt att uttrycka krav tidigt — kravbilden ändras löpande
  • Resultaten uppfyller inte verksamhetens faktiska behov
Nytt angreppssätt
  • Tvärfunktionella team som kan lösa hela uppgiften
  • Direktkontakt mellan verksamhet och utvecklare — inga mellanlager
  • Snabbare leveranscykler och kortare feedbackloopar
  • Prototypdriven utveckling som validerar hypoteser tidigt
  • AI som verktyg för att accelerera utvecklingsprocessen
Processöverblick

Innovationssprintens faser

Sprinten är uppbyggd i tre faser: en förberedande fas innan sprinten startar, själva genomförandefasen på två veckor, och en avslutande fas med utvärdering och kunskapsöverföring.

Fas 0 — Förberedelse
Prototyp, arkitektur, deploykedja & verksamhetsroller
Innan sprinten påbörjas tas en fungerande prototyp fram i nära samarbete med verksamheten. Prototypen är en vibekodad webbapp som körs i en containerbaserad miljö så att verksamheten kan testa och ge input på funktion. Därefter genomförs en övergripande dialog kring lösningsarkitektur och tekniska förutsättningar. Teamet säkerställs även full access till en egen deploykedja mot en dedikerad testbädd (sundsvall.dev), utan beroenden till andra team. Slutligen görs en medveten bedömning av hur verksamhetsspecialister ska involveras under sprinten — baserat på funktionens karaktär och behovet av domänkunskap.
Fas 1 — Genomförande
Tvåveckors utvecklingssprint
Tvärfunktionellt team arbetar i täta cykler med en daglig standup som nav — genomgång av gårdagens utveckling, demo av ny funktionalitet, och synk kring frågor och hinder. Direktkontakt med verksamheten och löpande leveranser till testbädden. AI används som verktyg i utvecklingsprocessen.
Fas 2 — Utvärdering
Reflektion & kunskapsöverföring
Resultat utvärderas mot hypotesen. Lärdomar dokumenteras och processmodellen förfinas för framtida användning.
Fas 0

Förberedelser innan sprinten

Förberedelsefasen syftar till att skapa rätt förutsättningar så att teamet kan vara produktivt från dag ett. Fyra centrala delar genomförs:

1

Prototyp i samarbete med verksamheten

En fungerande webbapplikation tas fram genom vibekodning — systematiskt och kontrollerat — och deployas i en containerbaserad miljö. Verksamheten testar prototypen och ger tidig input på funktion och flöden. Detta validerar hypotesen och bekräftar att det finns ett värde i att gå vidare med sprinten.

2

Arkitektur- och teknikdialog

Veckan innan sprinten genomförs en övergripande dialog kring lösningsarkitektur och tekniska förutsättningar utifrån prototypen. Teamet alignar kring teknikstack, miljöer och övergripande designbeslut så att alla är redo att börja direkt.

3

Egen deploykedja till testbädd

Teamet säkerställs full access att själva deploya ändringar direkt till en dedikerad testbädd (sundsvall.dev). Inga beroenden till andra team, som exempelvis IT-produktion, för att löpande kunna leverera och verifiera förändringar under sprintens gång. Autonomi i hela kedjan är en förutsättning för sprintens tempo.

4

Bedöm verksamhetens involvering

Graden av verksamhetsinvolvering under sprinten måste bedömas utifrån vad som ska byggas. Handlar sprinten om en verksamhetsspecifik funktion som kräver särskild domänkunskap är det oerhört viktigt med nära, dagligt samarbete med verksamhetsspecialister. Handlar det istället om en funktion med strategisk och taktisk bredd — mer tekniskt driven — kan verksamheten vara mindre involverad i det dagliga arbetet. Det finns inget standardsvar; varje sprint kräver en medveten bedömning av hur och hur ofta verksamheten ska delta.

Daglig rytm

Standup — sprintens dagliga nav

Varje dag genomförs en standup som fungerar som teamets gemensamma synkpunkt. Standupens syfte är tvådelat: att röja hinder för utvecklingen och att synka frågor och funderingar inom teamet och med verksamheten.

1

Genomgång av gårdagens utveckling

Teamet går igenom vad som gjorts sedan förra standupet — vad är klart, vad pågår, och var står vi i förhållande till sprintens mål?

2

Demo av ny funktionalitet

Om ny funktion har levererats körs en kort demo så att hela teamet ser framstegen och kan ge direkt feedback.

3

Frågor, hinder & synk

Öppen dialog där teammedlemmar lyfter blockeringar, frågor till verksamheten eller tekniska funderingar som behöver lösas för att arbetet ska flyta vidare.

Principer

Bärande principer för sprinten

Dessa principer vägleder teamets arbete genom hela sprinten.

Noll avstånd

Alla mellanlager mellan verksamhet och utveckling elimineras. Direkt dialog, direkt feedback.

Snabba leveranser

Korta cykler, dagliga leveranser och snabba feedbackloopar som fångar förändrade behov.

Tvärfunktionellt

Ett team som täcker alla kompetenser. Inga beroenden till andra team, ingen väntan.

AI-accelererat

AI används som verktyg i utvecklingen för att öka tempo och frigöra utvecklarnas kreativa kraft.

Hypotesdriven

Prototypen validerar en hypotes innan resurser investeras. Vi testar innan vi bygger klart.

Löpande anpassning

Processen utvecklas under sprinten. Vi lär oss och justerar dagligen.

Dagbok

Dag för dag

En löpande logg av aktiviteter, insikter och lärdomar under sprintens gång.

Dag 1 — Uppstart & första nedbrytning 2026-04-13

Aktiviteter

uppstart demo nedbrytning

Dagen inleddes med ett uppstartsmöte där hela teamet samlades för en genomgång av hypotesen och målbilden — vad är det vi ska åstadkomma? En live-demo av prototypen genomfördes så att alla fick se och förstå den lösning som verksamheten redan gett input på.

Därefter öppnades för dialog och frågor kring lösningen. Syftet var att bygga en gemensam förståelse i hela teamet — inte bara kring vad som ska byggas, utan varför.

Avslutningsvis bröts första dagens utveckling ned i mindre, hanterbara aktiviteter. Teamet identifierade konkret vad de skulle börja med och fördelade arbetet.

Steg dag 1

1. Uppstartsmöte med genomgång av hypotes och målbild
2. Demo och genomgång av befintlig prototyp
3. Öppen dialog — frågor och förtydliganden kring lösningen
4. Nedbrytning av arbete i konkreta, startbara aktiviteter

Dag 2–10 Kommer att fyllas i löpande

Denna sektion uppdateras efter varje avslutad dag i sprinten med aktiviteter, insikter och lärdomar.

Deltagarguide

Vad innebär det att delta i en innovationssprint?

Att delta i en innovationssprint är inte som vanligt projektarbete. Tempot är högre, avstånden kortare och förväntningarna annorlunda. Den här guiden beskriver det mindset och de beteenden som krävs av varje deltagare — oavsett roll — för att sprinten ska lyckas.

Mycket av det som beskrivs här kan kännas självklart. Men erfarenheten visar att det är just i gapet mellan att veta vad som krävs och att faktiskt agera därefter som de flesta sprintar fallerar. Läs med öppet sinne — inte för att lära dig nya saker, utan för att kalibrera ditt förhållningssätt.

En sprint lyckas inte för att teamet har rätt kompetens — den lyckas för att teamet har rätt inställning.

Princip 1

Ta ägarskap — inte instruktioner

01

Du är inte här för att utföra uppgifter. Du är här för att lösa ett problem.

I en sprint finns det ingen produktägare som talar om exakt vad du ska bygga. Det finns inget kravdokument som beskriver varje detalj. Istället finns det ett problem som behöver lösas, och du är en del av det team som ska lösa det.

Det innebär att du behöver förstå varför vi bygger det vi bygger — inte bara vad. Om du ser att något inte stämmer, att en lösning inte fungerar, eller att vi är på väg åt fel håll — då är det ditt ansvar att säga ifrån. Inte någon annans.

Det här vill vi se
  • Du ställer frågor när något är oklart — direkt, inte efter mötet
  • Du föreslår alternativ om du ser en bättre väg
  • Du tar initiativ att lösa problem utan att vänta på instruktioner
  • Du hjälper teammedlemmar som fastnat, även om det inte är ditt ansvarsområde
Det här bromsar oss
  • Väntar på att bli tilldelad arbete istället för att ta det
  • Ser problem men säger inget — "det är inte mitt bord"
  • Följer instruktioner blint trots att resultatet uppenbart blir fel
  • Skjuter frågor framför sig — "jag tar det imorgon"
Princip 2

Kommunicera direkt och ofta

02

Kort avstånd kräver frekvent dialog. Tystnad är det största hindret.

En av sprintens viktigaste egenskaper är att avstånden mellan alla deltagare är minimala. Det finns inga mellanlager som filtrerar eller fördröjer information. Det betyder att du har direkt tillgång till alla — verksamheten, utvecklarna, alla i teamet.

Men kort avstånd är bara värdefullt om det faktiskt används. Om du sitter tyst med en fråga, om du inte delar framsteg eller om du undviker att ge direkt feedback — då förlorar vi sprintens viktigaste fördel.

Feedback ska ges direkt — inte sparas till nästa möte

I en sprint med dagliga leveranser hinner saker bli fel snabbt om feedback inte kommer i tid. Om du ser något som inte stämmer — i en demo, i en lösning, i ett beslut — säg det direkt. Att vara rak är inte oartigt. Att vänta tills det är för sent att ändra — det är problemet.

Det gäller alla riktningar: utvecklare mot verksamhet, verksamhet mot utvecklare, och kollegor sinsemellan. Sprinten lever på ärlig, omedelbar kommunikation.

Princip 3

Håll tempot — varje dag räknas

03

Tio arbetsdagar är inte mycket. Det som inte händer idag, händer kanske aldrig.

En tvåveckorssprint har ingen buffert. Det finns ingen "nästa sprint" att skjuta saker till. Det som inte görs idag minskar direkt vad vi kan åstadkomma totalt. Det betyder inte att du ska stressa — det betyder att du ska vara fokuserad och medveten om att din tid har direkt påverkan på resultatet.

Praktiskt innebär det: kom förberedd till standup. Lyft hinder direkt istället för att försöka lösa dem ensam i timmar. Fatta snabba beslut med tillräckligt bra information istället för att vänta på perfekt information som aldrig kommer.

Det perfekta är det godas fiende. Vi bygger för att lära — inte för att leverera en slutprodukt.

Princip 4

Omfamna förändring — det är meningen

04

Det vi bygger idag kommer att ändras imorgon. Och det är precis rätt.

I traditionellt projektarbete ses ändringar som ett problem — ett tecken på dålig planering eller otydliga krav. I en sprint är ändringar ett bevis på att processen fungerar. Vi bygger, vi testar, vi lär oss, och vi justerar. Det är själva poängen.

Det kräver att du släpper tanken på att "din del" ska vara perfekt och färdig. Var beredd på att det du byggt kan kastas om, att prioriteringar ändras och att lösningen utvecklas i en riktning du inte förutsåg. Det handlar inte om att ditt arbete var dåligt — det handlar om att vi vet mer nu än vi visste igår.

Rätt förhållningssätt
  • "Vi lärde oss att det inte fungerade — bra, nu vet vi mer"
  • "Verksamheten vill ha det annorlunda — då bygger vi om"
  • "Jag hade fel om det här — tack för feedbacken"
Vanliga fällor
  • "Men vi bestämde ju redan att det skulle vara så här"
  • "Det kan vi inte ändra nu — jag har redan byggt klart det"
  • "Det borde verksamheten ha sagt från början"
Princip 5

Teamet framför individen

05

Din viktigaste uppgift är inte att vara bra på ditt — det är att göra teamet bättre.

I en innovationssprint arbetar alla tätt tillsammans. Det innebär att om du är klar med din uppgift men en kollega sitter fast, så är din nästa uppgift att hjälpa den kollegan. Det spelar ingen roll att det inte är "ditt område". Sprintens framgång mäts i vad teamet levererar — inte vad du personligen åstadkom.

Det innebär också att du behöver vara transparent med var du står. Att erkänna att du fastnat är inte en svaghet — det är att ge teamet möjlighet att lösa problemet snabbare. Att dölja problem för att "lösa det själv" är den dyraste misstaget i en sprint.

Alla roller är jämlika under sprinten

Under sprinten finns inga hierarkier. En verksamhetsspecialists observation väger lika tungt som en senior utvecklares tekniska bedömning. Den som har rätt information i stunden har mest att bidra med — oavsett titel. Det förhållningssättet kräver att alla lyssnar aktivt och respekterar varandras perspektiv.

Princip 6

Ha mod att vara obekväm

06

Tillväxt sker utanför komfortzonen — det gäller både produkten och dig.

En sprint pressar gränser. Du kommer att arbeta med människor du inte brukar samarbeta med. Du kommer att fatta beslut med ofullständig information. Du kommer att visa halvfärdigt arbete. Du kommer att få feedback som utmanar dina antaganden.

Allt detta är obekvämt. Men det är i det obehagliga som de verkliga genombrotten sker — både för produkten och för dig som deltagare. De sprint som producerar bäst resultat är de där deltagarna vågade vara osäkra, ställa dumma frågor och prova saker som kanske inte fungerade.

Den som aldrig visar halvfärdigt arbete lär sig aldrig om det var rätt väg. Våga visa, våga fråga, våga ändra dig.

Sammanfattning

Sex principer — ett mindset

Allt kokar ner till en enda sak: du är här för att bidra till att teamet löser ett verkligt problem på kortast möjliga tid. Det kräver ägarskap, rakhet, tempo, flexibilitet, laganda och mod.

Ägarskap

Förstå varför, inte bara vad. Ta ansvar för helheten.

Kommunikation

Prata direkt, ge feedback omedelbart, dölj ingenting.

Tempo

Varje dag räknas. Agera nu med tillräckligt bra information.

Förändring

Ändringar är bevis på framsteg. Omfamna dem.

Laganda

Teamets resultat är ditt resultat. Hjälp andra först.

Mod

Visa halvfärdigt. Ställ frågor. Våga ha fel.