5 varför

Grundidén

När något har gått fel är det lätt att laga symptomet och gå vidare. 5 varför (5 Whys) tvingar teamet att gräva djupare: ni skriver ner problemet och frågar varför hände det? Svaret blir nästa fråga: och varför hände det? Efter ungefär fem varv brukar ni ha nått rotorsaken — det som faktiskt måste ändras för att problemet inte ska komma tillbaka.

Siffran fem är en tumregel, inte en lag. Ibland räcker tre varv, ibland behövs sju. Ni är framme när svaret är något ni kan göra något åt.

Vad används det till?

Efter en incident — en deploy som gick fel, en server som låg nere
I en retrospektiv — när samma problem dyker upp sprint efter sprint
Vid buggar som kommer tillbaka — laga orsaken, inte bara buggen
Att undvika skuldbeläggning — frågan är varför processen tillät felet, inte vem som gjorde det

Delarna och vad de heter

Del	Hur den ritas	Vad den betyder
Problemformulering	Översta rutan	Vad som hände, konkret och mätbart: vad, när, hur mycket
Följdfråga	“Varför?” mellan rutorna	Samma fråga varje gång, ställd till det senaste svaret
Varför-kedjan	Rutorna Varför 1–5	Varje svar är orsaken till svaret ovanför. Läs den baklänges med “därför” — då ska den hänga ihop
Rotorsak (root cause)	Markerad ruta efter kedjan	Den djupaste orsaken som teamet själva kan ändra på
Åtgärder (corrective actions)	Sista rutan	Vad som ska ändras, vem som gör det och när. Ofta en ändring i processen, inte bara i koden

Exempel — deployen som misslyckades

Ett litet IT-konsultbolag deployar en ny version av en kunds bokningssystem en fredag eftermiddag. Deployen kraschar och sidan ligger nere i en timme. På måndagens retro gör teamet en 5 varför.

Kontrollera kedjan genom att läsa den baklänges: pipelinen har inget sådant steg → därför testar ingen mot realistisk data → därför syntes inte felet i den tomma testmiljön → därför kraschade migreringen → därför misslyckades deployen. Det håller.

Lägg märke till vad teamet inte skrev: “Ali glömde standardvärdet”. Det är sant, men det går inte att åtgärda — alla glömmer ibland. Det som går att åtgärda är att processen inte fångade det.

Åtgärd	Ansvarig	Klart
Lägg till ett pipeline-steg som kör migreringen mot en anonymiserad kopia av produktionsdatabasen	Sara	Sprint 7
Lägg till “nya kolumner har standardvärde eller tillåter NULL” i checklistan för kodgranskning	Ali	Nästa vecka
Ingen deploy till produktion efter kl 15 på fredagar	Hela teamet	Direkt

Använd anonymiserad data i testmiljön — riktiga kunduppgifter hör inte hemma där.

Fiskbensdiagrammet — när orsakerna är flera

5 varför följer en kedja. Ibland har ett problem flera orsaker som samverkar, och då riskerar ni att bara hitta en av dem. Då passar ett fiskbensdiagram (även kallat Ishikawadiagram, efter Kaoru Ishikawa) bättre. Problemet sitter i huvudet, och varje ben är en kategori av möjliga orsaker.

Del	Hur den ritas	Vad den betyder
Huvud	Ruta längst till höger	Problemet — samma problemformulering som i 5 varför
Ryggrad	Vågrät pil mot huvudet	Binder ihop alla orsaker till problemet
Ben	Sneda linjer från ryggraden	En kategori av orsaker. Vanliga i IT: Människor, Metod, Verktyg, Miljö (ibland även Mätning och Material)
Orsak	Kort linje på ett ben	En möjlig orsak inom kategorin. Den viktigaste kan ni sedan gräva i med 5 varför

De två verktygen fungerar bra ihop: fiskbenet ger bredden (alla tänkbara orsaker), 5 varför ger djupet (varför just den orsaken uppstod).

Mall att kopiera

## 5 varför: <kort rubrik>

**Problemformulering:** <Vad hände? När? Hur stor blev effekten?>

1. **Varför?** <svar>
2. **Varför?** <varför hände svar 1?>
3. **Varför?** <varför hände svar 2?>
4. **Varför?** <varför hände svar 3?>
5. **Varför?** <varför hände svar 4?>

**Sammanfattning av rotorsaken:** <den djupaste orsaken som vi själva kan ändra på>

### Åtgärder

| Åtgärd | Ansvarig | Klart senast |
|--------|----------|--------------|
|        |          |              |

När ska du välja 5 varför?

Välj 5 varför när…	Välj något annat när…
Problemet är tydligt avgränsat och har hänt	Orsakerna verkar vara många och samverka → fiskbensdiagram (ovan)
Ni vill komma förbi symptomet till något ni kan ändra	Ni vill se läget framåt, inte förklara något som hänt → SWOT
Ni har en retro där samma problem återkommer	Ni vill samla idéer brett utan att leta orsak → tankekarta
	Ni har hittat åtgärderna och vill göra dem till tydliga mål → SMART-mål

Vanliga misstag

Att stanna vid en person. “För att Ali glömde” är aldrig en rotorsak. Fråga varför processen lät det hända.
Att hoppa i kedjan. Varje svar måste vara orsaken till svaret precis ovanför. Läs baklänges med “därför” och kontrollera.
Att gissa. Svaren ska bygga på det ni faktiskt vet — loggar, commits, tidslinjen. Skriv “vet inte, ta reda på” hellre än att hitta på.
Åtgärder utan ägare. “Vi ska testa mer” blir aldrig av. Skriv vem och när.

Övning

Tänk på ett problem från ett projekt ni gjort — en missad deadline, en bugg i en inlämning, ett möte som inte ledde någonstans. Skriv en problemformulering med vad, när och hur mycket, och gör fem varv. Läs kedjan baklänges med “därför”. Håller den? Skriv sedan en åtgärd med ansvarig och datum.

TL;DR

Begrepp	Vad det är
5 varför	Fråga “varför?” upprepade gånger tills ni når rotorsaken
Problemformulering	Konkret: vad, när, hur mycket
Rotorsak	Den djupaste orsaken som går att åtgärda
Åtgärder	Vem gör vad, när — oftast en ändring i processen
Fiskbensdiagram (Ishikawa)	Alternativ när orsakerna är flera: huvud = problem, ryggrad, ben = kategorier