Hvad sker der med arbejdet, når alt det andet ryger?
Når kulturen er flyttet, organisationen er omstruktureret og kompetencerne er pejlet om, hvordan flyder arbejdet så i hverdagen? Hvilke processer overlever, hvilke dør, og hvilke nye opstår?
Min tese: meget af det vi kalder agile praksis i dag, er bygget om at løse et koordineringsproblem der er ved at forsvinde. Mens et nyt problem, beslutningskvalitet under accelereret produktion, vokser i samme tempo. De fleste organisationer løser stadig den gamle udfordring og overser den nye.
AI gør dårlige idéer værre, ikke bedre
John Cutler har skrevet skarpt om det her: AI accelererer eksisterende mønstre. Hvis dine processer var sunde, bliver de bedre. Hvis de var brækkede, bliver de værre. Hans eksempel er et team der ovenpå et i forvejen knækket stage-gate-system bolter en “Governance Agent” og AI-genererede PRD’er. Hver knækket mental model, nu med AI.
Jeg har endnu ikke set det gå galt i en dansk virksomhed, men jeg tror det kommer.
Et tidligt symptom er stillingsopslagene. Pludselig søger alle en “AI Product Manager”. Hvad er det egentlig for en rolle? En produktleder der kan noget med AI? Det er ikke svaret. At skrive AI foran rollebeskrivelserne løser ingenting — det skjuler bare at organisationen ikke har tænkt over hvad der reelt skal ændres.
De fleste organisationer der påbegynder “AI-transformation” lige nu, automatiserer deres knirkende processer i stedet for at undersøge om processerne stadig løser et reelt problem. Fælden er stillet og indbydelser er sendt ud.
Det er den åbne front for hele dette lag.
Faldgruben: Discovery springes over
Den første konkrete fare ligger i discovery. Når prototyping er gratis, og du kan bygge en fungerende løsning på en weekend, opstår en kraftig fristelse: spring discovery over. Steve Blank har advaret mod det i årevis under titlen “fall in love with the problem, not the solution”. Den fare bliver større nu, ikke mindre.
For når en CEO eller mellemleder kan diktere en prototype og se den køre samme aften, bliver vedkommende forelsket i sin løsning. Ikke på grund af den research der underbygger den, men på grund af hastigheden hvormed den blev til. Det er en helt ny form for organisationspolitik. PM’en der argumenterer for at vente og undersøge står pludselig over for en prototype direktøren har bygget i weekenden og er forelsket i.
Der er en ekstra rynke. Når det er hurtigt at bygge, opstår også fristelsen til bare at spørge kunden hvad de vil have. “Vi spørger jo bare, og så bygger vi det.” Det lyder fornuftigt. Det er det ikke. Henry Ford sagde det for over hundrede år siden: havde han spurgt folk hvad de ville have, havde de sagt hurtigere heste. Forskellen i 2026 er at du faktisk kan bygge de hurtigere heste, på en uge, med onboarding-flow oveni.
Rob Fitzpatrick beskriver i The Mom Test hvordan gode discovery-spørgsmål handler om kundens liv og adfærd, ikke om din idé. Hvad gjorde du sidste gang slår ville du købe det her. Den disciplin bliver ikke mindre vigtig af AI. Den bliver den vigtigste.
Den dyreste feature er ikke den der tager lang tid at bygge. Det er den der aldrig skulle have været bygget.
Faldgruben: Tilbage til vandfald
Den anden faldgrube er mere subtil. AI gør det fristende at skrive lange spec-dokumenter og overlade resten til en agent. Du kan indtale specifikationen på en eftermiddag, give den til Claude eller Cursor, og se en hel feature blive bygget i en lang strøm.
Det ligner agile på overfladen, “vi shipper hurtigt”. Det er det modsatte. Det er vandfald i ny indpakning. Den iterative løkke, hvor vi bygger lidt, tester på brugere, lærer noget, og bygger igen, står over for sin største prøvelse i tyve år. Fordi den løkke kræver disciplin, og disciplinen er sværere når alternativet (en stor specifikation der bare bygges) er så nemt.
Det kræver hardere processer end før, ikke blødere. Korte cykler. Hyppige reviews. Eksplicit læring mellem hver iteration. Det modsatte af det man kommer til, hvis man bare lader AI’en køre med specen.
Den forsvindende midte
Karri Saarinen fra Linear har skrevet om en bevægelse han kalder “the disappearing middle of software work”. Pointen er at midten af softwareudvikling, at oversætte intent til implementation, har været kerne-håndværket i årevis. Det er hvor de fleste timer er blevet brugt.
Den midte bliver tyndere. AI-agenter producerer fungerende kode fra mål, kontekst og opgaver. IDE’en bliver mere af en kode-viewer end et kode-skrivende værktøj. Det betyder at presset flytter sig til de to ender:
- Foran: at forme intent. Hvad skal bygges, hvilke tradeoffs er acceptable, hvilke begrænsninger gælder.
- Bagved: review, test, release. At sikre at det der kom ud, faktisk gjorde det det skulle.
Processerne skal designes om de to ender, ikke om midten.
Scrum er et koordineringsværktøj, ikke et produktværktøj
For at forstå hvor hurtigt det her flytter sig, kig på hvad Scrums ceremonier faktisk gør. Daily standup er informationsrouting. Sprint planning er oversættelse fra forretningsbehov til opgaver. Refinement er kollektiv gætteleg om størrelse. Retro er et af de få møder der ikke handler om koordinering, og det er også et af de møder de fleste teams springer over.
Scrum løser et reelt problem: hvordan holder vi styr på hvem der laver hvad, og hvordan sikrer vi at information fløj mellem mennesker der ellers ikke ville snakke sammen.
Det problem er ved at forsvinde. AI er exceptionelt god til koordinering. Et system der ved hvad alle arbejder på, kan erstatte standups. Et system der forstår kapacitet og afhængigheder, kan erstatte sprint planning. MCP-servere, browser-agenter og voksende kontekstvinduer er byggestenene. Orkestreringen mangler. Den kommer.
Når den kommer, sidder Scrum med et problem: frameworket er designet til at løse et problem som et system snart løser bedre. Spørgsmålet er ikke hvordan bruger vi AI i Scrum? Det er hvad laver vi, som ikke er koordinering?
Den nye flaskehals: beslutninger
Når koordineringen automatiseres, og produktionen accelererer, bliver beslutningskvalitet det der adskiller. Forskningen er på vej til at forstå det. Et nyt studie påpeger eksplicit at speed-quality trade-off i AI-drevne beslutninger er fundamental, og at quality-first design er nødvendigt for at håndtere det (Majumdar, 2025).
Jeg taler med danske udviklere lige nu der bekræfter mønsteret i hverdagen. Et eksempel fra en bank: udvikleren sagde til mig at de bare sad og ventede på at en beslutning blev truffet, så de kunne rykke videre. De havde styr på hvad de skulle bygge. Det var beslutningen der haltede.
Det er det nye mønster. Eksekveringen er hurtigere end beslutningerne. Møder bliver til venteværelser hvor folk venter på at en leder afgiver en retning. Sprintet bliver kortere end beslutningscyklussen. Alt det der ligner produktivitet, viser sig at være kø.
Løsningen er ikke flere møder. Løsningen er bedre møder, og fundamentalt anderledes møder. Møder hvor vi specifikt træffer en beslutning, ikke hvor vi koordinerer.
Faciliteringen kommer tilbage, men ikke som før
En personlig observation: Scrum Master-rollen er for ofte endt som mødeindkalder. Hentet kaffe og kage, tidsstyret ståemmøder, tracket impedimenter i et spreadsheet ingen læste. Det er ikke rollen der har svigtet — det er udførelsen. De Scrum Masters jeg har arbejdet tæt med, har sjældent taget ansvar for outcome og transformation. Så fyldte de tiden ud med koordineringsritualer.
Den superkraft der kommer tilbage er beslutningsfacilitering. Håndtere konflikter, samle uenighed til beslutning, presse en gruppe til at vælge i stedet for at snøre. Den evne har altid været værdifuld, altid undervurderet. Den bliver kritisk nu.
Det er coaching, mediation og beslutningskunst i én person. Det er ikke en ny rolle — det er Scrum Master-rollen forsvarligt udført. Den der vil fortsætte i rollen efter koordineringen er automatiseret, skal mestre det. Det er forskellen på at blive overflødig og at blive uundværlig.
Hvilke processer overlever
Jeg er forsigtig med at være for kategorisk her. Mønsteret går ud over Scrum: enhver proces der primært er koordinering, er truet. Enhver proces der lever af refleksion eller beslutning, bliver vigtigere. Min nuværende vurdering:
- Daily standups: dør. AI er på vej til at vide bedre hvad alle laver, og folk skal ikke synkronisere mundtligt når systemet gør det automatisk. Forskningen peger samme vej allerede uden AI: et grounded theory-studie af 60 udviklere og 79 observerede stand-ups på tværs af fire lande finder at de mest negative faktorer er status-rapportering til managers, for høj frekvens og for lang varighed (Stray et al., 2016) — særligt hos senior developers.
- Sprint planning: tyndes ud. Erstattes af kontinuerlig prioritering med AI-støtte og korte beslutningsmøder efter behov.
- Refinement: forsvinder i nuværende form. Estimering bliver mindre vigtigt når byggetid kollapser. Erstattes af intent-shaping: hvad skal opgaven egentlig løse?
- Retros: bliver vigtigere. Det er et af de eneste møder der lever af refleksion frem for koordinering. Det burde have fyldt mest hele tiden.
- PRDs og kravdokumenter: levende dokumenter erstatter statiske. Ingen krav der besluttes én gang og overleveres.
- Roadmaps: kvartalsvise planer erstattes af kontinuerlige prioriteringer. Den årlige roadmap-øvelse er en levn fra en tid hvor det tog seks måneder at bygge ét item på den.
- Discovery-cykler: bliver kortere men hyppigere. Stadig kerne-praksis, ikke fase 0.
- Reviews og evaluation: vokser markant. Den ende af processen der har været underprioriteret, bliver hvor kvaliteten afgøres.
- 1-on-1s og coaching-samtaler: bliver vigtigere, samme logik som retros. Det er der dømmekraft og identitet flyttes — det kan AI ikke automatisere.
- Performance reviews: kollapser i nuværende form. Output-måling holder ikke når alle kan producere mere. Skal redesignes om outcomes og beslutningskvalitet. Skiftet fra output- til outcome-måling er allerede dokumenteret i den offentlige sektor (Mas et al., 2019), og forskningen skelner eksplicit mellem rigide top-down-systemer og dynamiske systemer baseret på outcome-ownership (Liao et al., 2024).
- Stage-gate og governance reviews: ændrer karakter. Konceptet med faste gates er dårligt egnet til høj usikkerhed (Trott et al., 2022). Når byggeomkostninger kollapser, bliver konflikten skarpere: den organisatoriske inerti der holder stage-gate i live, er integration i planlægning og budgettering, ikke at det er det rigtige værktøj. Godkendelsen skal flytte sig til efter byg, på outcome, ikke på den planlagte indsats.
Tidspunktet er en del af beslutningen
Decision quality handler ikke kun om hvor godt du beslutter. Det handler om hvornår.
Et MIT Sloan-studie fra 2025 fulgte 579 teams gennem en intern innovationskonkurrence i en Fortune Global 500-virksomhed (Cromwell & Harvey, 2025). Forskerne forventede at teams der definerede problemet tidligt og klart, ville implementere flest løsninger. Det modsatte viste sig.
Teams der startede med høj problemklarhed havde 50% implementation rate. Teams der startede uklart og opdagede problemet over tid, ramte 80%+. Mekanismen er to-foldet: bredere idé-eksploration og dybere team-commitment, fordi folk er mere committed til ideer de selv har formet.
Men — og det er pointen — kaos er ikke svaret. Teams der ikke konvergerede inden 50%-mærket, faldt til 25% implementation rate. Samme studie. Lederens job er at skifte gear: divergent ledelse i første halvleg, konvergent i anden.
Det matcher godt det jeg ser i praksis. De værste produktbeslutninger jeg har været med til, faldt i to grøfter: enten besluttede vi for tidligt (vi havde ikke forstået problemet) eller for sent (vi diskuterede stadig retning da vi skulle eksekvere). AI gør begge grøfter dybere. Når byggeomkostningerne falder, bliver det fristende at låse for tidligt — fordi vi kan bygge. Og det bliver fristende at udskyde — fordi vi kan generere endnu en variant.
Den nye dømmekraft er ikke bare hvad du beslutter. Det er hvornår. Førsthalvleg: hold problemet åbent længere end du synes er rart. Andenhalvleg: luk det ned hårdere end du synes er rart.
Princippet for laget
Princippet er kort:
Tid til læring. Tid til levering. I rigtig rækkefølge.
Det er den modsatte instinkt af det de fleste agile-implementeringer er bygget på. De er bygget om hastighed til levering. Det var den rigtige optimisering da byggeri var dyrt. Det er den forkerte optimisering nu.
Forskningen peger samme vej. Et fem-årigt multi-site studie af large-scale agile i en multinational telecom-virksomhed identificerer seks pitfalls hvor agile-praksis aktivt skader individuel læring, ideation og exploitation (Annosi et al., 2020). Rita McGrath formulerer det skarpere endnu i Journal of Management: i den digitale økonomi vinder den der lærer hurtigst (McGrath, 2023).
Når byggeri er gratis, er den eneste meningsfulde måling hvor hurtigt I lærer noget. Med ét forbehold: hurtig læring kan ende som mange små eksperimenter på det lette at observere. Felin et al. (2020) advarer mod præcis dén faldgrube — at læringscyklen bliver så hurtig at hypoteserne aldrig bliver dristige. Det skift fra hastighed til levering til hastighed til læring er ikke et frikort til kun at lære småt. Det er et krav om at lære om det der faktisk afgør produktet.
Alt det andet — sprints, ceremonier, ritualer — skal designes om det.