Hvis I oplever, at udviklingsorganisationen har travlt, men at tingene alligevel tager for lang tid at få færdige, så prøv at kigge på én ting: Hvor meget har I gang i samtidig?
Ikke kun på teamets board, men på tværs af hele organisationen. Hvor mange større initiativer, projekter, features og forbedringer konkurrerer lige nu om de samme mennesker og den samme kapacitet? Lav listen. Tæl dem. Og prøv så at halvere antallet af aktive initiativer uden at reducere kapaciteten.
Det lyder næsten for simpelt, men det er et af de mest effektive greb til at forbedre flowet i en softwareorganisation. Færre samtidige initiativer betyder mindre koordinering, færre afhængigheder, færre kontekstskift og mere kapacitet på det arbejde, vi faktisk har besluttet os for at færdiggøre. Det svære er ikke at forstå mekanismen. Det svære er at acceptere konsekvensen: Noget vigtigt må vente. Det er også her, forskellen på at prioritere og faktisk at prioritere bliver tydelig.
Vi har prioriteret, men vi arbejder stadig på det hele
De fleste organisationer, vi møder, prioriterer allerede. De har roadmaps, porteføljestyring, business cases, strategiske temaer, OKR’er eller andre mekanismer, der skal sikre, at de vigtigste ting kommer først. Men prøv at kigge på resultatet af prioriteringen. Hvis I havde 30 aktive initiativer før prioriteringen og stadig har 30 aktive initiativer bagefter, har I ikke prioriteret jeres kapacitet. I har prioriteret rækkefølgen på de ting, I allerede har besluttet at arbejde på. Det er ikke det samme. En organisation får ikke mere kapacitet, fordi initiativerne bliver placeret i en prioriteret rækkefølge. Hvis de samme mennesker fortsat skal bidrage til mange af dem samtidig, bliver kapaciteten bare fordelt i mindre bidder.
Det kan eksempelvis ende med, at et team bruger 40 procent på produkt A, 20 procent på et strategisk initiativ, 20 procent på teknisk gæld og resten på support, drift og diverse hasteopgaver. På papiret går regnestykket op. I praksis gør det sjældent. For de 20 procent kommer ikke i sammenhængende blokke. Der kommer møder, afhængigheder, afklaringer og ventetid oveni, og mennesker skal hele tiden genetablere konteksten, når de bevæger sig fra det ene problem til det andet. Det er WIP: Work in Progress. Og WIP er ikke kun noget, der findes på et Kanban-board.
WIP skalerer med organisationen
På teamniveau har vi efterhånden lært mekanismen. Hvis der allerede er fem User Stories i gang, og ingen bliver færdige, er løsningen sjældent at starte nummer seks. Vi prøver i stedet at få noget færdigt. Det mærkelige er, at denne logik ofte forsvinder, når vi bevæger os et par niveauer op i organisationen. En afdeling med fem teams kan sagtens have 20 eller 30 større initiativer i gang. Hvert initiativ er vigtigt, hvert initiativ har en stakeholder, og hvert initiativ har en fornuftig begrundelse for at være startet. Men kapaciteten er stadig begrænset. Little’s Law beskriver sammenhængen mellem WIP, throughput og lead time:
WIP = Throughput × Lead Time
Det betyder i praksis, at hvis vores evne til at færdiggøre arbejde er nogenlunde konstant, mens vi hælder mere arbejde ind i systemet, så stiger den tid, arbejdet befinder sig i systemet. Vi får altså ikke nødvendigvis mere ud af at starte mere. Vi får bare mere, der er startet.
Det giver nogle ret genkendelige modenhedstrin.
Niveau 1: Everybody Happy
“Sig ja og start.”
En stakeholder kommer med et vigtigt behov. Vi siger ja. En anden stakeholder kommer med noget andet vigtigt. Vi siger også ja. Direktionen beslutter et nyt strategisk initiativ. Selvfølgelig skal vi også i gang med det. Det er egentlig en meget forståelig mekanisme. At sige “vi er gået i gang” føles handlekraftigt, og stakeholderen går fra mødet med en oplevelse af, at organisationen har reageret. Problemet er, at det er billigt at starte arbejde. Det dyre er at færdiggøre det. Efterhånden har vi derfor mange projekter og initiativer, som alle bevæger sig lidt. Folk er travle, kalenderne er fyldte, og der bliver rapporteret fremdrift mange steder. Men meget lidt kommer helt ud på den anden side. Den mentale model er: Activity = Progress.
Niveau 2: Everything is Priority
“Vi prioriterer alt det, vi allerede har sagt ja til.”
På et tidspunkt bliver problemet tydeligt, og organisationen begynder at arbejde mere systematisk med prioritering. Vi får roadmaps, scoringmodeller, porteføljemøder, strategiske temaer og måske OKR’er. Det er et skridt i den rigtige retning. Men der er en vigtig test:
Hvad blev stoppet som konsekvens af prioriteringen?
Hvis svaret er “ikke rigtig noget”, har prioriteringen sandsynligvis ikke ændret WIP nævneværdigt. Vi ved nu, at initiativ A er vigtigere end B, og at B er vigtigere end C. Men A, B og C kører stadig.
Niveau 3: Less is More
“Noget vigtigt må vente.”
Her sker den væsentlige ændring. Organisationen begynder at forstå, at prioritering først får reel effekt, når den påvirker, hvad vi bruger vores kapacitet på lige nu. Hvis A er vigtigere end B, kan konsekvensen derfor være, at vi arbejder på A og ikke arbejder på B. Det betyder ikke, at B er ligegyldigt. B kan have en rigtig god business case. Det kan være vigtigt for en stor kunde. Det kan være noget, vi med sikkerhed skal lave. Men det behøver ikke betyde, at vi skal lave det nu. Her begynder WIP limits at flytte sig fra teamets board til porteføljen. En afdeling kan eksempelvis beslutte, at der maksimalt må være seks større initiativer aktive. Hvis ledelsen vil starte nummer syv, skal et af de seks andre først færdiggøres eller stoppes. Så ændrer samtalen sig. Fra: “Er det her vigtigt?” til: “Er det her vigtigere end noget af det, vi allerede arbejder på?” Det sidste spørgsmål er langt mere interessant.
Niveau 4: Finish Before Start
“Færdigt arbejde skaber værdi. Påbegyndt arbejde gør ikke.”
Næste skridt er at begynde at styre efter færdiggørelse frem for igangsættelse. Hvis noget er blokeret, leder vi ikke straks efter noget andet, folk kan starte på. Vi forsøger at fjerne blokeringen. Hvis et vigtigt initiativ mangler en bestemt kompetence, spørger vi ikke kun, om de øvrige mennesker kan begynde på noget andet. Vi spørger, hvordan organisationen kan hjælpe det vigtigste arbejde videre. Det er forskellen mellem at optimere ressourceudnyttelsen og optimere flowet. Hvis målet er, at alle mennesker skal være 100 procent beskæftigede hele tiden, er det rationelt at have ekstra arbejde liggende klar. Så snart nogen venter, kan de starte på noget andet. Problemet er, at organisationen gradvist fyldes med igangværende arbejde. En motorvej fungerer på nogenlunde samme måde. Vi kan øge antallet af biler og dermed udnytte vejen bedre indtil vi når et punkt, hvor bilerne begynder at påvirke hinanden. Herefter falder hastigheden, og på et tidspunkt har vi opnået meget høj udnyttelse af vejen og meget dårligt flow. En motorvej med 100 procent udnyttelse er ikke nødvendigvis en effektiv motorvej. Det samme gælder en softwareorganisation.
Niveau 5: One-Piece Flow
“Én ting ad gangen. Små bidder. Hurtigt videre.”
One-Piece Flow er den yderste konsekvens af tankegangen. Det betyder selvfølgelig ikke, at en softwareorganisation med 500 mennesker bogstaveligt kun skal arbejde på én User Story ad gangen. Pointen er at komme så tæt på princippet som praktisk muligt: færre samtidige initiativer, mere kapacitet på hvert initiativ og mindre leverancer, der kan færdiggøres hurtigt. Forestil jer to organisationer med samme kapacitet og ti initiativer. Den ene fordeler kapaciteten nogenlunde ligeligt mellem alle ti. Den anden koncentrerer kapaciteten omkring få initiativer, får noget værdifuldt færdigt og flytter derefter kapaciteten videre. Efter en periode kan den første organisation have ti initiativer, der hver er 70 procent færdige. Den anden kan have syv færdige initiativer og tre, der endnu ikke er startet. På papiret kan den udførte mængde arbejde være den samme. Forretningseffekten er ikke den samme. Syv færdige leverancer kan bruges af kunderne. De kan skabe omsætning, reducere omkostninger eller give os feedback. Og måske lærer vi undervejs noget, der betyder, at initiativ nummer otte, ni og ti slet ikke længere er de rigtige ting at bygge. Det er også derfor, lav WIP ikke behøver at gøre organisationen mindre agil. Tværtimod. Hvis vi arbejder i små bidder og færdiggør dem hurtigt, kan vi hurtigere flytte kapaciteten til den næste kunde, det næste problem eller den næste strategiske prioritet.
Det er ikke et Kanban-problem
WIP limits bliver ofte betragtet som et værktøj for teams. Men den største effekt ligger ofte højere oppe. For hvis ledelsen sætter 25 initiativer i gang, hjælper det kun begrænset, at teamet har en WIP limit på tre User Stories. Det er derfor værd at starte et andet sted. Lav listen over de større ting, organisationen arbejder på lige nu. Spørg, hvor mange der reelt får den kapacitet, der skal til for at komme hurtigt i mål. Og prøv derefter det ubehagelige spørgsmål:
Hvad ville der ske, hvis vi halverede antallet af aktive initiativer og brugte den frigjorte kapacitet på at færdiggøre resten hurtigere?
Det er i virkeligheden den mentale rejse:
Everybody Happy → Everything is Priority → Less is More → Finish Before Start → One-Piece Flow
Fra en organisation, hvor fremdrift handler om, hvor meget vi har fået startet, til en organisation, hvor fremdrift handler om, hvor hurtigt vi får den vigtigste værdi helt igennem systemet.
Fra Activity = Progress til Flow = Progress.
Hvor meget WIP har I egentlig?
Hvis I kan genkende billedet af en organisation, hvor mange initiativer er i gang, men hvor for få kommer hurtigt i mål, så start med at gøre jeres WIP synlig.
Hvor mange større initiativer arbejder organisationen faktisk på lige nu? Hvor mange teams og mennesker er involveret i flere af dem samtidig? Og hvad ville der ske med jeres lead time, hvis I halverede antallet og koncentrerede kapaciteten om resten?
I Empiric hjælper vi softwareorganisationer med at finde de steder, hvor for høj WIP, afhængigheder og organisatoriske flaskehalse bremser flowet – og omsætte det til konkrete ændringer i måden, arbejdet prioriteres og organiseres på.
Kan I genkende problemet, tager vi gerne en snak om, hvor jeres største begrænsning ligger – og hvad I konkret kan gøre ved den.
Kontakt Empiric → På tlf 50112644 eller mail rk@empiric.dk
