AI har ændret, hvor flaskehalsen er i softwareudvikling. De praksisser vi byggede op omkring langsom kodeskrivning klarer ikke alle skiftet. Her er hvad der stadig holder og hvad der bør gentænkes.
Jeg har arbejdet med mange udviklingsteams gennem årene — som udvikler, som lead, som product owner. De fleste af dem var “agile” på en eller anden måde. Scrum, Kanban eller noget der startede som Scrum og gradvist tilpassede sig virkeligheden. Og det virkede for det meste.
Men på det seneste er der noget, der føles lidt skævt.
Ikke fordi Agile er forkert. Men fordi den måde mange teams praktiserer det på, ikke rigtig matcher den måde vi bygger software på i dag — især nu hvor AI er en del af billedet.
Kernen holder stadig
Nogle af ideerne bag Agile er solide og har ikke mistet deres relevans.
At bygge i små trin. Vise fremgang hyppigt. Holde sig tæt på rigtige brugerbehov. Justere efterhånden som man lærer. Hvis noget, betyder det mere nu end det gjorde før.
Men noget føles forældet
Hvor det begynder at gå galt er i den måde Agile typisk implementeres i praksis.
Tag sprintplanlægning. Jeg har siddet i mange af de møder — to timer med at nedbryde arbejde, estimere opgaver og diskutere edge cases. Halvvejs igennem sprintet ændrer tingene sig alligevel. Det gav mening dengang kodeskrivning var den langsomme del. Det giver mindre mening, når man kan gå fra idé til fungerende prototype på et par timer.
Det samme gælder detaljeret opgavenedbrydning. Vi brugte tidligere meget tid på at splitte arbejde op i meget små stykker. Nu kan man ofte bare beskrive, hvad man vil have, og komme overraskende langt med AI inden man overhovedet er færdig med at skrive subtasks. Planlægning er stadig vigtig — men detaljeringsniveauet er det ofte ikke.
Velocity er et andet eksempel. Det var aldrig et perfekt målepunkt, men det gav i det mindste et signal. Nu kan én udvikler med det rette setup pludselig gøre flere gange mere end tidligere. Det gør velocity svær at fortolke på nogen meningsfuld måde.
Og så ceremonierne. Stand-ups, retros, reviews — de kan alle være nyttige. Men jeg har også set masser af teams der holder dem, fordi frameworket siger det. Det er som regel et tegn på, at noget bør ændres.
Hvad AI faktisk ændrer
Det største skifte handler ikke rigtig om hastighed, selv om det er det der oftest tales om.
Det handler om, hvor flaskehalsen er.
Før var det at skrive kode. Nu handler det i langt højere grad om at finde ud af, hvad der faktisk giver mening at bygge — og om det løser et rigtigt problem. Man kan bygge ting meget hurtigt nu, hvilket også betyder, at man kan bygge den forkerte ting meget hurtigt. Prisen for en dårlig beslutning er steget, selv om prisen for implementering er faldet.
Hvad jeg ville gøre anderledes
Jeg ville ikke smide Agile ud. Men jeg ville forenkle det og fokusere på, hvad der faktisk hjælper teamet fremad.
Retning frem for detaljer. I stedet for tung sprintplanlægning ville jeg fokusere på spørgsmålet: hvad forsøger vi at opnå i denne uge, og hvad er de vigtigste ting at flytte? Resten kan man finde ud af undervejs.
Hurtigere feedback-loops. Hvis noget tager to uger at vise til en bruger eller interessent, er det sandsynligvis for stort. Den rigtige læring sker, når man ser, hvordan noget faktisk virker i praksis — ikke i et planlægningsmøde.
Stand-ups om problemer, ikke status. Hvad blokerer os? Hvor har vi brug for hjælp? Hvad lærte vi i går, der ændrer, hvad vi gør i dag? Det er en nyttig stand-up. En runde-bordet statusopdatering er det ikke.
Ship når det er klar. Faste sprint-grænser gav mening, da det var dyrt at release. At vente på, at kalenderen siger det er tid, tilføjer sjældent værdi i dag.
Retros er stadig det hele værd — hvis de gøres ordentligt. Et spørgsmål jeg ville tilføje som tilbagevendende prompt:
Hvor arbejder vi stadig, som om AI ikke eksisterer?
Eller mere direkte: hvad brugte vi tid på denne uge, som vi sandsynligvis ikke burde gøre manuelt længere? Bliv ved med at stille det spørgsmål, og den måde teamet arbejder på vil gradvist ændre sig af sig selv.
Dette handler ikke om at erstatte Agile
Agile forsvinder ikke. Men vi er nødt til at holde op med at behandle frameworks som Scrum som noget fast. De var altid tænkt til at blive tilpasset.
Lige nu ændrer den måde vi bygger software på sig ganske meget. Det giver ikke megen mening at ignorere det og fortsætte præcis som før.
Man kan bevæge sig hurtigere end nogensinde. Men hastighed hjælper kun, hvis man bevæger sig i nogenlunde den rigtige retning.
Så hvis jeg skulle koge det ned: brug mindre tid på at planlægge opgaver, mere tid på at forstå problemer. Byg hurtigt, se hvad der sker, juster. Det er stadig Agile — bare uden nogle af de dele, der ikke længere trækker deres del af lasset.