Komforan
EN
Alle indlæg

Agile løste en flaskehals, der ikke findes mere

· Henning Kjær

Det er værd at huske, hvad Agile egentlig forsøgte at løse.

Det var ikke et opgør med waterfall, bare fordi waterfall var grimt, tungt og besværligt. Det var et svar på en helt konkret virkelighed: software var langsomt og dyrt at bygge - og dyrt at ændre, når først man havde bygget det forkerte.

En forkert beslutning kunne koste måneder. Derfor blev processen indrettet til at reducere den risiko. Små iterationer gjorde fejl billigere. Korte feedbackloops gjorde det muligt at opdage dem tidligere. Beslutninger blev udskudt, indtil man vidste nok til at træffe dem.

Og omkring det voksede et helt maskinrum frem: refinement, estimering, acceptkriterier, definition of ready og sprintplanning. Alt sammen med et vigtigt formål: at sikre, at en dyr og begrænset udviklingskapacitet hele tiden havde veldefineret arbejde klar til at blive bygget.

Et sprint er i bund og grund en måde at portionere arbejdet på. Og størrelsen på portionerne gav mening i en verden, hvor det tog tid at omsætte en idé til fungerende kode.

Hvis man for bare få år siden fulgte en feature hele vejen fra idé til produktion, fyldte implementeringen typisk den største del af rejsen. En betydelig del af vores processer blev derfor designet omkring netop den fase.

Flaskehalsen har flyttet sig

For en voksende del af softwareudviklingen er det ikke længere selve kodningen, der er den begrænsende faktor.

Anthropic beskriver det samme i deres AI-native SDLC-playbook: Når AI accelererer implementeringen, flytter begrænsningen sig til arbejdet før og efter koden – planlægning, review, test, security og deployment. AI kan producere kode på sekunder, mens mange af de omkringliggende processer stadig bevæger sig i menneskefart.

Anthropic bruger også deres egen udviklingsorganisation som eksempel. Her skriver Claude ifølge dem omkring 80 procent af koden, mens udviklerne producerer markant mere kode end tidligere. Antallet af linjer kode er selvfølgelig et tvivlsomt mål for produktivitet, men udviklingen illustrerer alligevel noget vigtigt: kapaciteten til at producere software kan vokse langt hurtigere end kapaciteten i resten af systemet.

Og det har en konsekvens.

Hvis vi gør implementeringen fem eller ti gange hurtigere, men lader resten af processen være uændret, får vi ikke nødvendigvis et team, der leverer fem eller ti gange hurtigere.

Vi flytter bare køen.

Arbejdet hober sig op foran review, QA, security og deployment. Pull requests venter længere. Flere ændringer er i gang samtidig. Mere arbejde bliver næsten færdigt, men ikke helt færdigt.

Resultatet kan derfor paradoksalt nok være det samme output som før – blot med mere work in progress, mere koordinering og mere stress.

Når flaskehalsen flytter sig, må processen flytte med.

To flaskehalse – og kun den ene er interessant

Den første er mekanisk - review, test, sikkerhedsscanning, godkendelser og deployment. Det er den, vi opdager først, fordi konsekvensen er synlig med det samme. DORA beskriver fænomenet som "downstream disorder" - gevinsten ved, at den enkelte udvikler kan producere hurtigere, bliver opslugt af de processer, arbejdet efterfølgende skal igennem.

Det er en reel flaskehals. Men det er også en flaskehals, vi grundlæggende ved, hvordan vi skal håndtere. Platform engineering, automatiserede gates, små batches, golden paths og paved roads. Ikke specielt revolutionerende. Ikke specielt sexet. Mest af alt et spørgsmål om prioritering, investering og eksekvering.

Den anden flaskehals er langt mere interessant – og den forsvinder ikke med bedre tooling:

At beslutte, hvad der overhovedet skal bygges.

Da implementering var dyr og langsom, var det relativt billigt at bruge tid på at sætte retningen. En uge på at diskutere scope gjorde ikke den store forskel, hvis der bagefter ventede tre måneders udvikling.

Det forhold er ved at blive vendt på hovedet.

Hvis noget kan bygges på to dage, men det tager en uge at beslutte, hvad der skal bygges, er den uge ikke længere en afrundingsfejl i projektplanen.

Den er projektplanen.

Men det handler om mere end hastighed.

Da software var dyrt at bygge, var det også dyrt at tage fejl. Derfor investerede vi massivt i at forsøge at være sikre på forhånd: analyser, discovery, estimater, business cases og lange diskussioner om scope.

Når det bliver markant billigere at bygge, bliver det samtidig billigere at opdage, at vi tog fejl. Det ændrer regnestykket.

I stedet for at bruge stadig mere energi på at træffe den perfekte beslutning, før vi bygger noget, kan vi i flere tilfælde træffe en mindre beslutning, bygge noget mindre, sætte det foran virkeligheden og lære.

Det er måske den vigtigste konsekvens af billigere softwareudvikling: Vi skal ikke bare beslutte hurtigere.

Vi skal ændre måden, vi beslutter på.

Hvad ændrer det så i praksis?

  • Refinement får et nyt formål. Tidligere handlede refinement primært om at gøre opgaver klar til udvikling: bryde dem ned, fjerne uklarheder og sikre, at udviklerne kunne gå i gang. Den del er blevet markant billigere. Hvis refinement fortsat skal gøre sig fortjent til sin plads i kalenderen, skal det derfor svare på sværere spørgsmål: Er det her overhovedet værd at bygge? Hvilken effekt forventer vi? Og hvordan ved vi bagefter, om det virkede?

  • Estimering mister meget af sin værdi. Story points gav mening som et forsøg på at forstå omkostningen ved implementering, da implementeringen var den dyre og usikre del. Men hvis den omkostning falder markant, bliver det mindre interessant at bruge timer på at estimere den. At måle den billige del meget præcist, mens vi knap nok måler kvaliteten af den dyre – beslutningen om, hvad vi bygger – er at optimere det forkerte med imponerende nøjagtighed.

  • Specifikationen bliver den centrale artefakt. Ikke Jira-opgaven. Ikke en liste af acceptkriterier skrevet for at få en ticket over i Ready for Development. Men en præcis beskrivelse af intentionen: Hvad prøver vi at opnå, for hvem, under hvilke begrænsninger, og hvordan ser succes ud?

    Anthropics playbook gør det konkret med en sekvens af artefakter: intention, derefter specification, derefter plan – versionsstyret og læsbart for både mennesker og agenter. Kald dem, hvad du vil. Pointen er, at det, vi formulerer før implementeringen begynder, får større betydning, når en stadig større del af implementeringen udføres af noget, der fortolker vores intention.

  • Prototyper slår analyse. Hvis vi kan bygge tre små versioner på den tid, det tager at holde to møder om, hvad vi skal bygge, er møderne pludselig den dyre løsning.

    Det ændrer selve formålet med at bygge. Kode er ikke længere kun resultatet af en beslutning. Kode kan være en måde at træffe beslutningen på. Vi bygger for at lære – ikke kun for at levere.

  • Review bliver mere værd. Produktion bliver billigere. Den knappe ressource er ikke længere nødvendigvis evnen til at producere noget hurtigt. Det er dømmekraften til at vurdere det, der bliver produceret: Er det korrekt? Er det sikkert? Er det forståeligt? Og løser det faktisk det problem, vi satte os for at løse?

    Når produktion bliver billigere, bliver kvalificeret kritik dyrere.

  • Og product owneren risikerer at blive den nye flaskehals. Det er måske den mest ubehagelige konsekvens – og den, jeg som product owner, software architect eller technical lead selv mærker tydeligst.

    Når teamet kan bygge næsten lige så hurtigt, som jeg kan beslutte, hvad der skal bygges, bliver min tøven en del af teamets lead time.

    Hvis jeg bruger fire dage på at afklare noget, der tager én dag at implementere, er det ikke længere udviklingen, der er langsom.

    Det er mig. Det er en ny – og ret udsat – position at stå i.

Hvad er uforandret?

De grundlæggende agile principper består. Korte feedbackloops, små leverancer, fungerende software frem for omfattende dokumentation og evnen til at omstille sig er lige så vigtig i dag. Som DORA-undersøgelserne peger på, forstærker AI i høj grad det, et team allerede gør. Og det går begge veje: Har I svage feedbackloops, betyder AI ikke nødvendigvis, at I bliver bedre – blot at I kan begå fejl hurtigere og i langt større skala.

Det, der derimod har udspillet sin rolle, er meget af det bureaukrati, vi byggede op omkring en flaskehals, som nu er ved at flytte sig. To-ugers sprint. De endeløse estimeringsmøder. Refinement-sessioner, hvis primære formål var at sikre, at udviklerne hele tiden havde en kø af veldefinerede opgaver klar. Ingen af delene var nogensinde målet i sig selv. De var løsninger på konkrete problemer – løsninger, som vi med tiden kom til at forveksle med selve metoden.

Men der er et vigtigt forbehold. Nogle af de mest bastante påstande kommer fra dem, der lever af at sælge AI-værktøjer – og, hvis jeg skal være fair, også fra folk som mig, der argumenterer for, at AI ændrer måden, vi udvikler software på.

Gevinsten varierer markant. Den kan være enorm i helt nye projekter, mere begrænset i tunge legacy-systemer, og nogle målinger peger endda på negativ effekt for erfarne udviklere, der arbejder i komplekse og modne kodebaser.

Så udsagnet om, at "koden ikke længere er flaskehalsen", rammer noget vigtigt – men det er ikke en universel sandhed. Den afgørende kompetence bliver derfor ikke bare at kunne bruge AI, men at kunne vurdere, hvornår AI faktisk accelererer arbejdet, og hvornår den blot accelererer kompleksiteten.

Gør det, Agile gjorde

Det agile manifest blev skrevet af mennesker, der så nøgternt på, hvor friktionen og omkostningerne i softwareudvikling lå – og indrettede arbejdsformen derefter.

Det mest agile, vi kan gøre i dag, er derfor ikke blindt at holde fast i de processer og ceremonier, der siden voksede frem. Det er at gøre præcis det samme som dengang: se ærligt på, hvor flaskehalsen har flyttet sig hen, og tilpasse måden, vi arbejder på.

Når det bliver billigere og hurtigere at producere kode, flytter en større del af udfordringen over i beslutningerne. Hvad skal vi bygge? Hvorfor? Hvordan ved vi, om det virker? Og hvilke konsekvenser har vores valg?

Det ville være mærkeligt at fortsætte med at optimere den del af processen, der netop er blevet billigere.

Kilder