Hold dig opdateret

Debat, Henrik Zangenberg

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

Ø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.

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.

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.