Hvad er 5S? Metoden forklaret og brugt i udviklingsteams

Hvad er 5S?

5S er en Lean-metode med fem trin, der skaber orden, standarder og mindre spild i arbejdet. I udviklingsteams bruger du 5S til at rydde op i digitale artefakter som backlog, repos og dokumentation, så teamet bruger mindre tid på at lede og mere tid på at levere.

Metoden kommer oprindeligt fra japansk industri og Toyota Production System og er tæt knyttet til Lean-tænkning om at fjerne spild og skabe flow. De fem trin fokuserer på at:

• skille det vigtige fra det uvigtige
• give alting en fast plads
• holde tingene rene og gennemsigtige
• lave simple standarder
• bygge vaner, så det holder i længden

I en fabrik handler det om værktøj, arbejdsstationer og gulvmarkeringer. I et udviklingsteam handler det om issues, branches, dokumenter, miljøer og møder. Pointen er den samme: mindre rod og søgetid, mindre variation i kvalitet, og et mere forudsigeligt workflow.

Det er vigtigt at se 5S som et middel, ikke et mål i sig selv. Målet er ikke en pæn Jira eller et “smukt” repo, men at gøre det nemmere og hurtigere at finde, forstå og ændre ting uden fejl.

Hvad betyder de fem S’er?

De fem S’er er japanske ord: Seiri, Seiton, Seiso, Seiketsu og Shitsuke. På dansk bruges ofte varianter som sortér, sæt i system, systematisk rengøring, standardisér og selvdisciplin. I praksis er det vigtigere, hvad du gør, end den helt præcise oversættelse.

Om du kalder trin 3 for “rengør” eller “systematisér”, er mindre vigtigt. Det afgørende er, at teamet deler samme forståelse: vi fjerner støj, gør struktur tydelig, og gør det let at se, når noget er galt eller gammelt.

Hvordan bruges 5S i udviklingsteams?

I et udviklingsteam handler 5S om at skabe orden i digitale arbejdsflader: backlog, repos, dokumentation, miljøer og møder. Målet er kortere søgetid, færre fejl fra gamle ting og mindre mental støj, når du skifter kontekst.

En praktisk måde at tænke det på er:

• Fysisk 5S: værktøj, hylder, gulvet
• Digital 5S: filer, systemer, dashboards
• Udviklingsteam-5S: issues, branches, kode, docs, beslutninger

Nedenfor er eksempler på, hvad hvert S kan betyde for et softwareteam.

1. Sortér: skær støjet fra

• Backlog: Luk gamle tickets, der ikke længere er relevante. Mærk tvivlsomme som “parkering” og beslut en dato, hvor de ryger ud, hvis ingen har savnet dem.
• Repos: Arkivér inaktive projekter, og saml små-biblioteker, hvor det giver mening. Hvis du vil rydde grundigere op, kan du hente inspiration fra at bygge et lille monorepo.
• Dokumentation: Slet eller arkivér forældede dokumenter tydeligt (fx med en “/archive”-mappe), så nye ikke drukner i gamle beslutninger.
• Miljøer og secrets: Luk ubrugte testmiljøer og API-nøgler. Det reducerer både støj og risiko. Mange teams opdager først rodet, når nogen har lagt en nøgle det forkerte sted.

2. Sæt i system: giv ting en fast, logisk plads

• Repo-struktur: Aftal en simpel, genkendelig struktur for projekter og mapper. Her kan en gennemgang som “projektstruktur og arkitektur” under kategorien Projektstruktur og arkitektur være god inspiration.
• README: Gør README til indgangen til hvert repo: hvordan kører jeg projektet, hvor ligger tests, hvor ligger mere dyb dokumentation. Se fx guiden til at skrive en README der faktisk bliver læst.
• Backlog: Aftal få, klare kolonner og labels, og hvad der skal til for at et issue må flyttes. Meget mere end det skaber ofte bare ekstra klik.
• Secrets og miljøvariabler: Saml standarder for, hvordan I håndterer secrets og miljøvariabler. Artiklerne om miljøvariabler og hvorfor secrets skal være kedelige er gode steder at starte.

3. Systematisk rengøring: fjern dødt kode- og konfigurationsrod

• Ryd op i gamle feature flags, testdata, scripts og pipelines, der ikke længere bruges.
• Fjern døde links og afsnit i dokumentationen. Hvis du har mange README’er, er dette guld værd.
• Opdatér lockfiles og afhængigheder på en kontrolleret måde. Læs gerne om, hvorfor lockfiles både hjælper og driller.
• Fjern “eksperiment-mapper” og midlertidige noter, eller flyt dem ind i et tydeligt “/playground”-område.

4. Standardisér: lav lette regler for gentagne ting

• Git og branches: Aftal en enkel branch-strategi og navngivning. Fx “feature/…”, “bugfix/…”. Du kan hente idéer fra Git-guiden om at overleve Git uden at kende hele værktøjet eller kategorien Versionsstyring og Git.
• Package managers: Vælg én package manager per sprog, så du undgår kaos. Se fx diskussionen om at vælge din package manager.
• Miljøer: Standardisér lokale miljøer, så “det virker på min maskine” hører fortiden til. Fx med virtuelle miljøer som i guiden om at tæmme Python-kaos med venv.
• Tests og kvalitet: Definér, hvad “klar til merge” betyder: testtyper, code review, linters. Du kan finde konkret inspiration i artiklerne under Test og kvalitet eller fx guiden til test uden tårer i Vite-projekter.

5. Selvdisciplin: gør det til en vane (ikke en kampagne)

• Lav små, faste 5S-øjeblikke, fx 15 minutter til backlog-oprydning før sprintplanning.
• Byg 5S ind i retrospectives: Hvad blev rodet siden sidst? Hvad kan vi forenkle?
• Automatisér så meget som muligt, fx med CI, så standarder håndhæves uden manuelt politiarbejde. Se fx historien om, hvordan små ændringer i CI kan gøre en stor forskel eller om at lade GitHub klare deployment.
• Fokuser på adfærd, ikke plakat-5S. Hvis standarderne ikke bruges i hverdagen, er de for tunge eller for uklare.

Et konkret eksempel på 5S i et udviklingsteam

I et udviklingsteam viser 5S sig typisk som færre uklare dokumenter, bedre struktur i repo og backlog, hurtigere onboarding og færre overraskelser i drift. Lad os tage en kort, realistisk før/efter-case.

Udgangspunkt: et klassisk rodet setup

Forestil dig et team på seks udviklere:

• Backloggen har 800 tickets, hvoraf ingen ved, hvad de nederste 500 handler om.
• Der er fem aktive repos for samme produkt, med forskellig mappe-struktur og forskellige README-niveauer.
• Dokumentation ligger spredt i Confluence, Google Docs, Notion og i tilfældige markdown-filer.
• API-nøgler ligger både i miljøvariabler, .env-filer og et par gamle scripts (ja, det sker), som i eksemplerne på tilfældig token-håndtering.
• Nye udviklere bruger de første uger på at spørge “hvor ligger…?” og “hvad er den nyeste version af…?”

5S-tiltag

• Sortér: Teamet lukker ældre backlog-items uden klar ejer, arkiverer to gamle repos og samler fælles hjælpefunktioner i ét bibliotek.
• Sæt i system: Der vælges én primær platform til dokumentation, med README’er som indgang. Artiklen om at skrive en README der bliver læst bliver reelt brugt som skabelon.
• Systematisk rengøring: Gamle API-nøgler lukkes og erstattes med en fælles, sikker løsning. De mest oplagte hotspots afdækkes med hjælp fra artikler som gemmer du også dine API-nøgler det forkerte sted.
• Standardisér: Der besluttes branch-konventioner, simpel PR-tjekliste og naming for services, så databaseændringer ikke længere bliver til “det virker på min maskine”-katastrofer. Du kan se paralleller til rådene om database-migrationer i teams.
• Selvdisciplin: Teamet sætter et kvartalsvist 5S-tjek ind i deres retrospectives og laver små, konkrete forbedringer hver gang.

Forventet effekt

Teamet måler ikke på alt, men ser efter få, konkrete ændringer:

• Onboarding-tid til første reelle feature falder fra fx 4 uger til 3.
• Udviklere rapporterer færre afbrydelser for at spørge efter docs og beslutninger.
• Antallet af fejl, der skyldes gamle dokumenter eller scripts, falder markant.

Det er ikke magi, og tallene varierer meget fra team til team, men erfaringen er, at en seriøs 5S-indsats ofte kan give produktivitetsløft i størrelsesordenen 10 procent eller mere. Det afhænger dog stærkt af udgangspunktet og hvor konsekvent, I følger op.

Hvordan måler man effekten af 5S i videnarbejde?

I udviklingsteams måler du effekten af 5S bedst på færre søgninger, hurtigere onboarding, færre fejl fra forældet dokumentation og mindre tid brugt på at finde beslutninger og artefakter. Du får sjældent perfekte tal, men simple før/efter-målinger er nok til at se, om det går i den rigtige retning.

En praktisk tilgang er at definere få, klare mål og tilhørende “proxy-metrics” (noget du kan måle på, der afspejler målet rimeligt godt). Her er en vejledende model:

Du behøver ikke gøre det avanceret. En simpel “før og efter”-note i jeres retrospectives, kombineret med objektive data hvor I har dem (fx logins, CI-fejl, incidents), er ofte nok.

Hvis I i forvejen arbejder med logs og observability, kan de også bruges til at se, om antallet af fejlrelaterede deploys falder. Der er fine perspektiver på den tilgang i artikler som logs vs mavefornemmelse og hvorfor mange udviklere stoler mere på logs end på hukommelsen.

Hvordan undgår man, at 5S bliver bureaukrati?

5S bliver til bureaukrati, når standarder erstatter dømmekraft, og når orden bliver mål i sig selv. Du undgår det ved kun at standardisere det, der tydeligt reducerer søgetid og fejl, og lade resten være fleksibelt.

Hvad bør man standardisere?

Som tommelfingerregel: standardisér det, som er fælles, gentages ofte og har høj konsekvens, hvis det går galt.

• Branch-struktur, release-proces og database-migrationer.
• Hvordan secrets og miljøvariabler håndteres.
• Krav for “klar til produktion” (tests, review, logging på plads osv.).
• Hvor centrale dokumenter og beslutninger bor.

Her er konsekvensen af variation høj: det kan betyde nedetid, sikkerhedsbrud eller dyre fejl. En let, fælles standard hjælper mere, end det skader.

Hvad bør man ikke standardisere hårdt?

• Personlig editor-opsætning, temaer og tastaturgenveje.
• Detaljeret commit-sprog (med mindre I har et stærkt behov for maskinel parsing).
• Små præferencer i mappestruktur i interne eksperiment-projekter.
• Hvor ofte man “må” refaktorere småting, når man alligevel er i filen.

Her kan for stramme regler dræbe flowet og skræmme folk væk fra at forbedre ting spontant.

Typiske anti-patterns

• Plakat-5S: Der er flotte diagrammer og policies, men ingen ændret adfærd.
• Kontrol for kontrollens skyld: Lange processer og formularer uden tydelig gevinst.
• Ordensmenneskernes takeover: Standarderne sættes af dem, der elsker orden, uden blik for andres arbejdsmåde.
• Dokumentationsstøj: Hver lille ting skal nedskrives, så ingen orker at læse noget.

Hold jer til “lightweight standards”: kort beskrevne, let forståelige regler, der er nemme at efterleve og ændre. Og vær eksplicit om, at standarden er et udgangspunkt, ikke en religiøs sandhed.

Hvordan kører man en 5S-workshop og audit i et udviklingsteam?

En god 5S-workshop for et udviklingsteam er kort, konkret og ender med tydelige aftaler om standarder, ansvar og næste lille audit. Du behøver ikke en stor transformation – start med 60-90 minutter og få få, men skarpe forbedringer.

Forslag til 60-90 minutters 5S-workshop

1. Vælg fokus (10 min)
   • Vælg 1-2 områder: fx “backlog og issues” eller “repos og dokumentation”.
   • Notér kort, hvad der irriterer flest: “vi kan aldrig finde X”, “ingen ved, hvilken version der er gyldig” osv.
2. Scan nuværende tilstand (15-20 min)
   • Lav en hurtig tur gennem Jira, GitHub, dokumentationsplatform mv.
   • Skriv konkrete problemer på post-its eller i et delt dokument.
3. 5S gennem området (25-30 min)
   • Gå de fem S’er igennem ét for ét og beslut:
     • Hvad kan vi sortere væk nu (lukke, arkivere, slette)?
     • Hvad skal vi sætte i system (ny mappe, nyt label, fælles placering)?
     • Hvad kræver rengøring (opdatere, rydde op i navne, fjerne døde links)?
     • Hvilke få ting skal vi standardisere (navne, processer, tjeklister)?
     • Hvordan holder vi det – hvilken selvdisciplin bygger vi ind i hverdagen?
4. Prioritér og udpeg ejere (10-15 min)
   • Vælg 3-4 konkrete tiltag, I faktisk kan gennemføre inden for de næste 2 uger.
   • For hvert tiltag: én ansvarlig, en simpel “done”-definition og en deadline.
5. Aftal opfølgning (5 min)
   • Aftal en kort 5S-audit om 4-6 uger: 15-20 minutter på et teammøde, hvor I tjekker, om de nye standarder bliver brugt.

Enkel audit-struktur

Til audits kan du bruge en lille tjekliste med ja/nej-spørgsmål:

• Kan en ny udvikler finde den nyeste beslutning om X på under 2 minutter?
• Er der stadig åbne tickets ældre end X måneder uden ejer?
• Er README’erne opdaterede nok til, at en ny kan køre projektet i gang?
• Håndterer vi secrets og tokens efter vores aftale, eller har vi undtagelser?

Her er idéen ikke at “bestå en eksamen”, men at spotte, hvor virkeligheden og standarderne er gledet fra hinanden – og så justere enten adfærd eller standard.

Hvis dit team i forvejen arbejder med retrospectives og procesforbedringer, kan du tænke 5S-workshops som en mere struktureret variant inden for kategorien samarbejde og workflows.

Hvad er forskellen på 5S og almindelig oprydning?

Almindelig oprydning fjerner rod her og nu. 5S skaber et vedvarende system, der gør det nemt at arbejde, finde ting og fastholde kvalitet – også om tre måneder, når hverdagen igen er travl.

I et udviklingsteam kan du sagtens lave en “ryd op i repo’et”-dag og få det til at se pænt ud. Men hvis du ikke samtidig:

• indtænker faste pladser (hvor ligger hvad?)
• beskriver lette standarder (hvordan navngiver vi, hvor skriver vi beslutninger?)
• og aftaler, hvordan I holder det ved lige (små audits, vaner)

– så er du bare tilbage i samme rod om få uger.

5S kobler oprydning med struktur, fælles standarder og opfølgning. Det er forskellen på at rydde op i skuffen én gang og at indrette den, så den faktisk forbliver overskuelig.

Typiske fejl, når man bruger 5S i udviklingsteams

De mest almindelige fejl med 5S i udviklingsteams er at standardisere for meget, involvere for få og glemme opfølgning. Resultatet bliver pæne slides og døde dokumenter, men ingen reel effekt i hverdagen.

Fejl 1: 5S som ordensprojekt

Fokus ender på, at ting “ser pæne ud” i Jira eller GitHub, i stedet for at gøre arbejdet nemmere. Du kan mærke det, hvis teamet sukker, når “5S” bliver nævnt.

Modtræk: Mål på søgetid, onboarding og fejl – ikke på antal labels eller regler.

Fejl 2: Overstandardisering

Hver lille detalje får en regel. Det skaber træthed og får folk til at omgå systemet.

Modtræk: Brug beslutningsreglen: fælles + hyppigt + høj konsekvens = standardisér. Resten kan være vejledende eller helt frit.

Fejl 3: Topstyring uden inddragelse

Standarderne skrives af ledelse eller “procesfolk” uden tæt involvering af dem, der faktisk arbejder i koden.

Modtræk: Lad teamet selv formulere standarder, gerne i en kort workshop. De ved bedst, hvor spildet er.

Fejl 4: Ingen audit – eller kun én gang

Der laves en stor 5S-indsats, men ingen simple mekanismer til at holde det ved lige. Efter et kvartal er alt tilbage ved det gamle.

Modtræk: Byg små 5S-tjek ind i retrospectives eller faste møder og hold dem korte. Hellere 10 minutter hver måned end en halv dag en gang om året.

Fejl 5: Dokumentation som dumping ground

Alt skrives ned, for “så har vi det da et sted”. Ingen rydder op, og ingen kan skelne vigtigt fra uvigtigt.

Modtræk: Tænk dokumentation som et produkt: nogen er ansvarlig, og forældede ting arkiveres aktivt. Artiklen om at holde dokumentation og links brugbare rammer netop den udfordring.

Hvis du vil dykke dybere ned i, hvordan man ændrer vaner og processer uden at tabe folk på gulvet, kan du med fordel kigge på flere artikler under samarbejde og workflows.