Af Annette Vendelbo, Agil agenda
Er der egentlig en positiv Return on Investment (ROI) på agile transformationer? Når det handler om Scrum og SAFe, blæser svaret simpelthen i vinden. Begge frameworks kræver store investeringer, når man skal i gang. Der skal omorganiseres – mere voldsomt ved SAFe end ved Scrum. Begge introducerer en række nye roller og ansvarsområder, og det kræver, at man uddanner store dele af organisationen, og det er dyrt.
Som jeg skrev i den første artikel, er det afgørende ved at indføre den agile metode, at ledelsen står i spidsen for virksomhedens agile transformation og sætter en tydelig retning. Det kræver, at virksomhedens ledelse også har mere end bare et overfladisk kendskab til de rammeværk, som de har valgt at bruge.
Der findes en række nye roller og ansvarsområder i både Scrum og SAFe, og de er faktisk ikke særligt intuitive. Det er årsagen til, at der typisk er behov for løbende agil coaching. I SAFe ligger etableringen af et Lean Agile Center of Excellence (LACE) sammen med en række andre ikke-værdiproducerende roller som en del af modellen, og i både Scrum og SAFe er der en række møder integreret omkring hvert Sprint eller Program Increment, som alle – ja alle i de agile teams skal deltage i.
Både organiseringen og møderne genererer en stort overhead. Et ganske voldsomt overhead i SAFe sammenhænge, og knap så voldsomt, men stadig stort i Scrum.
Dertil kommer de ofte store omkostninger ved at etablere Scrum eller SAFe. Jeg tør næsten sige, at en Scrum- eller SAFe-implementering altid involverer eksterne aktører, og oftest nogle dyre nogle af slagsen. Store transformationer kan nemt løbe op i større millionbeløb, så det er ikke småpenge, der skal hentes hjem på optimeret eksekvering.
Jeg har stadig til gode at se et regnestykke, der viser en positiv ROI i Scrum eller SAFe sammenhænge. Et hvor alle etableringsomkostningerne og overhead regnes med. Måske findes disse regnestykker – jeg har bare ikke set dem.
Begge frameworks har stort fokus på de agile teams, der oftest er Scrum teams. I Scrum er der fokus på at stabilisere “velocity”, men hvad fortæller det egentlig om effektivitet og evnen til at eksekvere? Hvis man tænker nærmere over det, så siger “velocity” kun noget om, hvorvidt der er stabilitet eller ej. Sagen er bare, at det kan lige så godt handle om at være stabilt elendig, stabilt OK eller stabilt fantastisk til at eksekvere.
Hvis vi kigger videre til Kanban, som er databaseret, så måler man hele tiden på den virkelige produktivitet. Kongemålingen er gennemløbstiderne, der viser hvor lang kalendertid det har taget at gennemføre en aktivitet fra start til slut, og dette er inklusive ventetider, flaskehalse, blokeringer og andet, der forhindrer det frie flow. Det gør man så for hver eneste aktivitet, man gennemfører.
Formålet er at skabe sig et overblik over den historiske produktivitet, hvilket giver viden om præcis, hvad man med stor sandsynlighed vil være i stand til at præstere, når man kigger fremad. Man bruger historisk data til at vise fordelingen af sine gennemløbstider, som alt efter hvor meget ustabilitet der er i ens organisation, vil være en bredere eller mere smal fordeling.
Her taler vi ikke om estimater, og det handler ikke om mavefornemmelser eller krystalkugler, det handler om virkeligheden. Alt i Kanban handler om at optimere flow ved at reducere sine gennemløbstider, og man bruger data til at afgøre hvor sundt ens Kanban-system er, så man kan sætte ind der, hvor man kan se, at tingene halter.
Kanban har fokus på at optimere sit organisatoriske system, så man reducerer ventetider, fjerner unødvendige møder, reparerer dårlige processer og andet, der tager tid væk fra det egentlige arbejde med at producere værdi. Man kigger derfor ikke kun på det, der sker i de enkelte teams, men også alt det, der sker i organisationen omkring disse teams.
Med tilladelse fra Kanban-huset, Squirrel North fra Canada, ses nedenfor et eksempel, der viser, hvordan koordinationsomkostningerne, der i stor stil udgøres af møder, blev halveret i de afdelinger, der brugte Kanban-metoden. I dette tilfælde blev koordinationsomkostningerne reduceret fra 20 pct. af de samlede omkostninger til 10 pct. på mindre end seks måneder.
Nøglen til denne type optimeringer er at reducere antallet af de initiativer, projekter eller aktiviteter, man har i gang samtidigt. Jo mere, man har i gang på en gang, des større overhead vil der være ved at prioritere opgaverne, koordinere ressourcer på tværs af teams, følge op på fremdrift og få sine ting sat i produktion. Dette gælder både på team-niveau og på organisationsniveau.
Om disse reduktioner bliver større eller mindre, vil altid afhænge af modenheden og forandringsviljen i organisationen og i de berørte teams og ikke mindst af ledelsesopbakningen, men potentialet ligger der og venter på at blive forløst.
Oven i det skal man så lægge, at det er nemt (og billigt) at komme i gang med Kanban. Både fordi man starter dér, hvor man er, og derfor slipper for at omorganisere og indføre en masse nye roller og ansvarsområder. Desuden er overhead i form af Kanban-møder reduceret til et absolut minimum og har et eneste omdrejningspunkt, nemlig flow.
I en evt. ROI-beregning ligger der altså en kæmpe gevinst i at kunne komme i gang i en fart plus en gevinst i form af at reducere overhead til et minimum. Dvs. et minimum af ikke-værdiskabende roller og møder, vel og mærke samtidig med at man hurtigt ser produktiviteten stige. Det er således ret nemt at udregne RoI på en Kanban-implementering, da man i forvejen måler løbende på produktiviteten, og ved, hvad det har kostet at komme i gang.
Kan det agile betale sig?
Svaret er, at det kommer an på organisationens udgangspunkt, den agile vej, man vælger og ledelsens vilje til at involvere sig. Er organisationen umoden og uvant med at arbejde struktureret og metodisk, skal man undgå de agile tilgange, der kræver stor modenhed. Er ledelsen ikke interesseret i transformationen, så er det begrænset, hvor langt man kan komme uanset metodevalg.
Alting har en pris, og intet kommer af sig selv. Det er komplekst at arbejde med IT og levere IT-projekter. Det kan en omorganisering eller indførelse af nye roller og ansvarsområder ikke ændre på. Der findes ingen nemme løsninger på komplekse problemer.
Det agile er ikke kun en team-sport. Hvis man virkelig ønsker at opnå markante resultater, så skal man have resten af organisationen med om bord, og det opnår man kun, hvis ledelsen spiller med.
Glem alt om en one-size-fits-all tankegang. Selvom andre virksomheder lykkes med en bestemt agil tilgang, så er der absolut ingen garanti for, at I kan kopiere den. Ikke to virksomheder er ens. Værdier, kultur, adfærd m.v. vil være (vidt) forskellig fra organisation til organisation. Man er nødt til at se sig selv i spejlet og være realistisk omkring hvad ens organisation kan rumme af forandring.
Målinger af ROI er ikke særlig nemme at finde. Man vil helt sikkert kunne finde business cases, der viser store gevinster – hvorfor skulle man ellers gå i gang med en agil transformation? Men det er knap så nemt at finde konkrete målinger på, om disse business cases holdt i virkeligheden.
ROI vil altid være kontekstafhængigt. Selvom det kan være besnærende at lade sig forblænde af flotte præsentationer, der lover det hele for det halve, så må man ikke parkere sin sunde fornuft. Fornuften, der siger, at hvis noget lyder for nemt eller for godt til at være sandt, så er det det nok også. Der findes ikke noget agilt ”easy fix”.
Mit personlige motto er ”Virkeligheden vinder hver gang”, og det passer faktisk strålende i denne sammenhæng.
Kontakt: annette@agilagenda.com
Bio: Annette er agil ekspert, forfatter, foredragsholder og podcaster. Hun rådgiver virksomheder om agile tilgange og har stået i spidsen for en længere række agile transformationer
Be the first to comment