Hvad AI gør ved Scrum

Det har virket i over tyve år. Det har givet teams et fælles sprog, en rytme og en struktur der holder folk på sporet. Millioner af produktteams verden over kører standups, sprint planning, refinement og retros. Det er ikke tilfældigt. Det løser et reelt problem.

Problemet er bare, at det problem er ved at forsvinde.

Scrums egentlige funktion

Tag Scrums ceremonier fra hinanden og se hvad de faktisk gør.

Daily standup: informationsrouting. Hvad lavede du i går. Hvad laver du i dag. Er du blokeret. Det er en synkroniseringsprotokol forklædt som et møde. Formålet er at alle i rummet ved hvad alle andre laver.

Sprint planning: oversættelse. Tag forretningsbehov, oversæt dem til opgaver, fordel dem mellem folk. Det er koordinering forklædt som planlægning.

Refinement: kollektiv gætteleg. Hele teamet sidder og estimerer ting, ingen ved nok om endnu. Det er usikkerhedshåndtering — dyr usikkerhedshåndtering — fordi vi ikke har et bedre system til at forstå hvor store ting er, før vi bygger dem.

Retro: den eneste ceremoni der handler om noget andet end koordinering. Den handler om læring, refleksion, forbedring. Og det er nok ikke tilfældigt, at det er den ceremoni de fleste teams springer over eller kører halvhjertet.

Pointen er ikke at Scrum er dårligt. Pointen er at Scrum er et koordineringsframework. Det løser problemet “hvordan holder vi styr på hvem der laver hvad, og hvordan sikrer vi at information flyder mellem folk der ellers ikke ville tale sammen.”

Det er en vigtig funktion. Men det er også en funktion der er sårbar.

AI er exceptionelt god til koordinering

Noget af det AI virker til at være allerallerbedst til, er at samle information på tværs, holde styr på hvem der laver hvad, og sætte ting sammen på tværs af al den data en virksomhed allerede har liggende.

Et system der ved hvad alle arbejder på, kan erstatte standups. Et system der forstår kapacitet og afhængigheder, kan erstatte sprint planning. Et system der kan analysere velocity og blokeringer i realtid, kan gøre halvdelen af en retro overflødig.

Det er ikke science fiction. Det er MCP-servere, browser-agenter og kontekstvinduer der vokser måned for måned. Byggestenene ligger der allerede. Orkestreringen mangler. Men den kommer.

Og når den kommer, så sidder Scrum med et problem. Fordi det framework du kører, er designet til at løse et problem som et system snart løser bedre end dig.

Rollerne falder også fra hinanden

Scrum antager faste roller med faste ansvarsområder. Product Owner der prioriterer backlog. Scrum Master der faciliterer processen. Udviklere der bygger.

Men den klassiske produkttrio — PM, designer, udvikler — er ved at falde fra hinanden. Kode er ved at blive en commodity. UI-design ligeså. En PM kan shippe. En udvikler kan designe. Grænserne mellem rollerne er flydende, og de bliver mere flydende for hver måned.

Jeg tror den nye trekant ser anderledes ud. Generalisten der forstår bruger, forretning og kan shippe selv. Arkitekten der ikke skriver koden men validerer at det hele hænger sammen. Compliance-ankeret der holder fast i sikkerhed, GDPR og regulering, fordi risikoen stiger i takt med at kode skrives hurtigere.

Det er ikke tre nye jobtitler. Det er tre nye ansvar. Og de passer ikke ind i Scrums rollekasser.

Outcome, ikke output

Her er det der for alvor udfordrer Scrum: frameworket måler de forkerte ting.

Velocity. Story points. Burndown charts. Det er output-metrics. De fortæller dig hvor meget du har bygget, ikke hvad det førte til.

Men vi starter altid med et outcome i hovedet. Flere konverteringer. Hurtigere onboarding. Færre support-tickets. Og så bruger vi halvdelen af vores tid på at gætte os frem til hvilket output der får os derhen. Så skriver vi det output ned i tickets. Estimerer dem. Fordeler dem. Og måler om vi nåede dem alle sammen til deadline.

Tænk hvis vi sprang det led over.

Tænk hvis du sagde til dit system: “Jeg vil have nye brugere gennem onboarding 30 sekunder hurtigere.” Og systemet gik i gang. Kiggede på flowet. Testede tre varianter. Smed vinderen i produktion. Ingen ticket. Ingen sprint. Ingen refinement.

Ingen spurgte “hvor mange story points er det?”

Det er ikke et argument for kaos. Det er et argument for at den struktur vi har, måler det forkerte.

Hvad er der så tilbage?

Hvis koordineringen forsvinder og rollerne flyder — hvad er der så tilbage?

Det der altid har været det vigtigste, men som vi sjældent har haft tid til.

At forstå kunder dybt. At træffe de beslutninger ingen andre tør tage. At holde fast i en retning når data er uklare. At mærke hvad der foregår i et rum fuld af mennesker. At sige nej til den feature alle vil have, fordi du ved den er forkert.

Det er ikke ceremonier. Det er dømmekraft. Og dømmekraft kan ikke sættes i en sprint.

Scrum forsvinder ikke i morgen. Men dets fundament — at koordinering kræver menneskelig indsats — er ved at forsvinde. Og når fundamentet ryger, så ryger alt det der er bygget ovenpå.

Spørgsmålet er ikke “hvordan bruger vi AI i Scrum?”

Det er “hvad laver vi, som ikke er koordinering?”

Og det spørgsmål bør bekymre enhver der har bygget sin karriere på at facilitere, synkronisere og holde folk alignet. Ikke fordi arbejdet var ligegyldigt. Men fordi det er ved at blive automatiseret.

Det der er tilbage, er det der altid burde have fyldt mest. Nu får det chancen.