Vi skal blive bedre til at tale om produktivitet i de agile programmer

Klumme: Økonomistyring i agile forløb er en udfordring for de fleste. Efterlader vi penge på bordet ved at lade teams, hvis produktivitet ikke lever op til tilsvarende teams, fortsætte uden ledelsesmæssig indgriben? Det bør vi tage en diskussion om med vores leverandører

Artikel top billede

(Foto: Dan Jensen)

Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter

Har du helt styr på økonomien i dine agile udviklingsprojekter?

Hvis nej, så er du ikke alene, for generelt er økonomistyring i agile projekter en vanskelig disciplin.

Typisk er der kun meget usikre estimater for, hvor meget det faktisk vil koste at nå et ”acceptabelt slutprodukt” – hvis man overhovedet kan tale om dette.

Der er sat penge af til et antal ”Agile Release Trains”, og hvad end man får ud af dette, det er resultatet.

Finder man undervejs ud af, at man skal i en anden retning, så kan både budget og scope ændre sig.

Tæt på uacceptabel

Set fra nogle CFO'ers stol er denne usikkerhed ofte tæt på uacceptabel.

Dette skyldes, at man udfordrer en grundlæggende præmis i mange organisationer, nemlig at man har valgt at iværksætte et initiativ ud fra en vurdering af omkostning i forhold til gevinst.

Der findes i agile rammeværk forskellige redskaber til at inddæmme problemstillingen, men en af de helt store udfordringer bringer rammeværkerne ikke løsningen på: Den manglende indsigt i faktisk produktivitet i de teams, der er sat til at løse opgaven.

For udviklernes produktivitet er en nøgleparameter for succes i det agile forløb og dermed også for økonomistyringen af dem.

Det gælder, hvad enten man har insourcet eller outsourcet udviklingsopgaven, men kan være særligt udfordrende i outsourcede scenarier, hvor adgangen til indsigt i team-produktivitet kan være mere besværlig.

Vores analyser af agile forløb viser, at produktiviteten varierer meget mellem udviklere og mellem agile teams.

Hvis man sætter fem udviklere i et rum med nogle brugere i to uger, kan der komme meget forskellige mængder af output, afhængig af hvem man har sat sammen, hvordan de er ledet, deres erfaring, metodekendskab og kulturen i teamet.

Det handler om ledelse

At få styr på disse ubalancer i de forskellige teams har alt med ledelse at gøre. Man skal identificere de teams, der har problemer, og hjælpe dem.

Det kan være gennem uddannelse, nye team-medlemmer, aflastning af opgaver og mange andre greb.

Tilbage står imidlertid, at man kun kan afhjælpe problemer, hvis man rent faktisk ser dem – altså har indsigt i faktisk produktivitet, og set fra et økonomisk perspektiv har indsigt i, om de udviklerteams, der er på opgaven, leverer en performance, som rent faktisk modsvarer prisen, der betales.

Det er faktisk muligt.

Den faktiske produktivitet i udviklingsopgaven kan udtrykkes i tid forbrugt per produceret enhed.

”Enheden” kan være storypoints, function points eller andre sammensatte værdier, der er udtryk for den faktisk implementerede funktionalitet.

Udfordringen ved alle disse mål er, at det kræver en selvstændig optælling, hver gang man har udviklet noget nyt.

Det er mildest talt et omfattende stykke arbejde, og det er der derfor ingen organisationer, der gør.

Til gengæld er antallet af kodelinjer (SLoC – Source Lines of Code) et umiddelbart tilgængeligt output-mål.

Mens det ikke umiddelbart lader sig oversætte til for eksempel function points, er det imidlertid muligt at finde FP/SLoC ratio for en udvikler eller et team, og det kan bruges til at triangulere en værdi for produktiviteten i et enkelt sprint for et givent team.

Disse kan så igen tjene som benchmark for relativ produktivitet i de enkelte teams målt i forhold til hinanden og absolut produktivitet målt i forhold til omverden.

Økonomistyring i agile forløb er som sagt i begyndelsen en udfordring for de fleste, men vi bør være villige til at indlede diskussionen om, hvorvidt vi efterlader penge på bordet ved at lade teams, hvis produktivitet ikke lever op til tilsvarende teams, fortsætte uden ledelsesmæssig indgriben.

Og det kan vi kun gøre ved at søge indsigt og ikke mindst ved at blive bedre til at tage samtalen om produktivitet med vores leverandører, når vores agile forløb er outsourcet.

Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.

Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?

Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.

Læses lige nu

    Event: Computerworld Summit 2026 - Aarhus

    Digital transformation | Aarhus C

    Styrk din digitale strategi med konkret brug af AI og ny teknologi. Mød 200 it-professionelle, få indsigter, løsninger og netværk på én dag. Computerworld Summit i Aarhus viser hvordan teknologi skaber forretningsværdi – her og nu.

    21 april 2026 | Gratis deltagelse

    Navnenyt fra it-Danmark

    Mikkel Hjortlund-Fernández, Service Manager hos Terma Group, har pr. 26. januar 2026 fuldført uddannelsen Master i it, linjen i organisation på Aarhus Universitet via It-vest. Foto: Per Bille. Færdiggjort uddannelse
    Immeo har pr. 1. marts 2026 ansat Theo Lyngaa Hansen som Consultant. Han kommer fra en stilling som Data Manager hos IDA. Han er uddannet i Business Administration & Data Science. Nyt job
    Renewtech ApS har pr. 1. marts 2026 ansat Emil Holme Fisker som Customer Service Specialist. Han skal især beskæftige sig med at levere høj kvalitets kundeservice og hjælpe Renewtechs kunder med at få de rette løsninger til deres behov. Han kommer fra en stilling som Key Account Manager hos Camro A/S. Han er uddannet som salgselev hos Camro A/S. Han har tidligere beskæftiget sig med at udvikle gode kunderelationer, opsøgende salg og udvikling af salgsaktiviteter. Nyt job

    Emil Holme Fisker

    Renewtech ApS