Hvad er Work in Progress (WIP)
Definition
WIP (Work in Progress) henviser til antallet af opgaver, der er startet, men endnu ikke afsluttet. En WIP-grænse er en eksplicit regel, der bestemmer, hvor mange opgaver der må være i hver kolonne på en Kanban-tavle på samme tid. Formålet er at forbedre flow og reducere spild ved at sikre, at teams færdiggør igangværende opgaver, før de starter nye.
Hvad er WIP?
Work in Progress (WIP) dækker over alt igangværende arbejde. Det er de opgaver, projekter eller produkter, som er blevet påbegyndt, men endnu ikke er færdiggjort. I en softwareudviklingskontekst kan det være en ny funktion, der er under udvikling, men endnu ikke testet og udgivet. I produktion kan det være en bil på samlebåndet. WIP repræsenterer en investering af tid, penge og ressourcer, der endnu ikke har skabt værdi for kunden. At have overblik over sit WIP er afgørende for at forstå, hvor effektiv en proces er.
Hvorfor bruge WIP-grænser?
Hvis et højt WIP er problemet, er WIP-grænser løsningen. Et højt WIP fører ofte til adskillige problemer: manglende fokus, da teamet jonglerer for mange opgaver på én gang (kontekstskift), skjulte flaskehalse, og en lang gennemsløbstid for hver enkelt opgave. Ved at indføre WIP-grænser – et maksimalt antal opgaver, der må være i gang samtidigt i en given fase – tvinger man teamet til at fokusere på at færdiggøre arbejde frem for at starte nyt. Dette simple princip har en række fordele: det synliggør flaskehalse med det samme, forbedrer flowet, reducerer stress og øger kvaliteten, fordi der er mere fokus på den enkelte opgave. Kort sagt, WIP-grænser hjælper teams med at levere værdi hurtigere og mere forudsigeligt.
Fordele og ulemper ved WIP-grænser
Fordele
- + Viser øjeblikkeligt flaskehalse i processen
- + Tvinger teams til at færdiggøre opgaver
- + Reducerer gennemsnitlig leveringstid (cycle time)
- + Øger forudsigelighed og kvalitet
- + Fremmer samarbejde og ‘swarming’ på blokerede opgaver
Ulemper
- − Kan skabe et midlertidigt stop for nogle teammedlemmer
- − Kræver høj disciplin at håndhæve i starten
- − At finde den rette grænse kræver justering
Praktisk eksempel: Et udviklingsteam
Et udviklingsteam med to udviklere og en tester implementerer WIP-grænser fordi de ofter har halvfærdige opgaver.
Situation 1: Uden WIP-grænse
Flaskehalse og multitasking- • Udvikler 1 starter opgave A, bliver blokeret, og starter opgave B.
- • Udvikler 2 starter opgave C.
- • Testeren har nu 3 opgaver i sin ‘Til Test’-kø.
Situation 2: Med WIP-grænser
Fokuseret samarbejde- • Kolonnen ‘I Udvikling’ har en WIP-grænse på 2. Begge udviklere arbejder på hver sin opgave.
- • Udvikler 1’s opgave bliver blokeret. I stedet for at starte en ny, hjælper hun udvikler 2 med at færdiggøre opgave C.
- • Opgave C rykkes til ‘Test’ (WIP-grænse: 1). Herefter samarbejder teamet om at fjerne blokeringen på opgave A.
WIP-grænsen ændrer teamets adfærd fra individuel travlhed til et kollektivt ansvar for at få opgaver helt færdige.
Typiske faldgruber ved implementering af WIP-grænser
-
En WIP-grænse, der er for høj, er meningsløs. Den ændrer sjældent adfærd og giver ingen af fordelene.
-
Hvis teamet konstant overskrider grænserne ‘bare denne ene gang’ for hasteopgaver, undermineres hele systemet, og man vender tilbage til kaos.
-
At sætte en WIP-grænse pr. person i stedet for pr. processtadie er en klassisk fejl. Det optimerer individuel travlhed, men ødelægger teamets samlede flow.
-
En WIP-grænse er ikke statisk. Den bør evalueres og justeres regelmæssigt, efterhånden som teamet lærer, og processen forbedres.
Hvornår skal du ikke bruge WIP-grænser
Når et team er en gruppe af individualister
Hvis teammedlemmer arbejder på helt separate opgaver, der ikke har nogen afhængigheder af hinanden, skaber en fælles WIP-grænse en kunstig flaskehals. Det tvinger en person til at være inaktiv, fordi en anden er optaget af noget helt urelateret.
Lad hver person styre sin egen opgaveliste. Hvis visualisering er nødvendig, kan man bruge separate ‘svømmebaner’ på et kanban-board uden fælles grænser.
I rent kreative eller udforskende faser
I starten af et projekt, hvor formålet er brainstorming eller research, er målet at generere mange idéer, ikke at færdiggøre en enkelt opgave effektivt. Strikse WIP-grænser kan kvæle kreativiteten og den nødvendige ‘tænketid’, hvor flere idéer er ‘i spil’ samtidigt.
Brug teknikker som timeboxing (f.eks. ‘vi brainstormer i 2 timer’) eller mind-mapping, hvor fokus er på divergens og udforskning frem for et lineært flow.
Når teamet er helt nyt
At indføre WIP-grænser er et optimeringsskridt. Hvis et team endnu ikke har forstået sit workflow, kan grænser virke vilkårlige og frustrerende. Man skal først se problemet, før man kan løse det.
Start med det første princip i Kanban: Visualisér arbejdet. Brug et simpelt board uden grænser i en periode for at indsamle data og identificere, hvor de naturlige flaskehalse opstår.
Når arbejdet primært består af at vente på eksterne parter
Hvis en stor del af dine ‘igangværende’ opgaver reelt set er parkeret, mens du venter på feedback fra en kunde, en chef eller en anden afdeling, kan en WIP-grænse tvinge dig i stå. Du kan ikke færdiggøre noget, men må heller ikke starte på noget nyt.
Du kan oprette en specifik kolonne på dit board til ‘venter’ eller ‘blokeret’, som ikke tæller med i din primære WIP-grænse. Dette visualiserer afhængigheden uden at stoppe flowet af opgaver, du selv har kontrol over.
Oftest stillede spørgsmål
For meget WIP fører til multitasking, længere leveringstider (cycle time) og skjulte problemer. Det giver en falsk følelse af produktivitet, fordi alle ser travle ud, men i virkeligheden bliver intet færdigt hurtigt.
Start konservativt. En god tommelfingerregel er at sætte grænsen til 1-1.5 gange antallet af personer, der arbejder i den pågældende fase. Observer flowet, og juster grænsen op eller ned baseret på data og teamets erfaring. Det er en eksperimentel proces.
WIP-grænser gælder primært for processtadier (kolonner på en tavle), ikke for enkeltpersoner. Målet er at optimere teamets samlede flow, ikke den enkelte medarbejders travlhed. Dette fremmer samarbejde for at få opgaver færdige.