Agil transformation skal besluttes af topledelsen

af Annette Vendelbo, Agil Agenda

Den agile specialist, Annette Vendelbo, gennemgår agil udvikling i to artikler. Den første handler om, at topledelsen skal ind over, før man for alvor kan lykkes. Den anden kigger på økonomien omkring det agile. Kan det overhovedet betale sig?

Der er ikke mange virksomheder, der i disse tider kunne drømme om at sige, at: ”hos os arbejder vi ikke agilt, og vi har heller ikke tænkt os at gøre det”. Det ville sende et signal om, at her er vi gammeldags og ude af stand til at følge med tiden.

Det er nærmest blevet en absolut sandhed, at hvis man skal være effektiv, skal man arbejde agilt, og det gælder uanset om det er i offentlige eller i private virksomheder. Det, der er mit budskab, er, at der er nogle forudsætninger der skal være på plads for at få det agile til at fungere. I alle tilfælde, hvis man taler om Scrum, SAFe eller for den sags skyld Spotify-modellen.

Når jeg ikke nævner Kanban i denne sammenhæng, er det fordi denne metode ikke kræver, at virksomheden omorganiserer sig og indfører nye roller og ansvarsområder. Det gør de øvrige nævnte tilgange.

Agile transformationer er blevet en vare, som alle store konsulenthuse har på hylderne. De laver fine præsentationer, der fortæller om, hvordan en organisation nemt bliver agil og alle de økonomiske gevinster det fører med sig, hvis man ”bare lige” omkalfatrer sin organisation. Men papir og power points er taknemmeligt, og det man typisk glemmer at fortælle om, er præcis hvilke forudsætninger, der skal være på plads for at få Scrum og SAFe til at virke bare nogenlunde ordentligt.

Velkommen til virkeligheden

Ser man på en oversigt over Scrum processen eller SAFe frameworket, ser det tilforladeligt ud på overfladen. Man kan næsten forestille sig beslutningstagerne sige ”nå, er det ikke andet? Det skal vi da bare gøre, hvis det kan gøre os mere effektive.”

Men graver man bare et enkelt spadestik dybere, vil man hurtigt opdage, at det er komplekse sager, man kaster sig ud i, og det burde egentlig ikke overraske nogen. At arbejde med IT og IT-projekter har alle dage været komplekst.

I de mere end 30 år jeg selv har arbejdet med IT-projekter, har man ønsket sig at levere få sine løsninger til den aftalte tid, inden for budgettet og i en ordentlig kvalitet. Det er det, man altid har jagtet og præcis det virksomhederne, ifølge rapporten ”State of Agile,” ønsker at opnå, når de hopper ud i det agile.

Men tænker man lidt nærmere over det, er det helt meningsløst at forestille sig, at fordi man omorganiserer og kalder sin kravspecifikation for en product backlog og indfører nogle nye roller, så skulle det i sig selv sikre, at man bliver mere agile og får has på den kompleksitet, som altid har kendetegnet IT-projekter, hvor der er mange ukendte ubekendte. Dem bliver der altså hverken flere eller færre af, fordi man omorganiserer. En organisations modenhed, kompetencer eller disciplin vil heller ikke ændre sig det mindste, og det er i virkeligheden dér, man skal have fat, hvis man vil opnå højere agilitet.

Det agile er ikke en team-sport, det er en firmasport

Som agil rådgiver og coach oplever jeg, at agile initiativer som regel starter i IT-afdelingen. Det er måske meget forståeligt, når nu de IT-projekter, som man bakser med at gennemføre, i høj grad trækker på netop IT-afdelingens ressourcer. Det er bare det forkerte sted at starte.

Hvis man omlægger sin arbejdsform til f.eks. Scrum, hvad mange gør, så er det en stor forandring, der bør involvere hele organisationen, hvis man skal have det til at virke. Scrum er ikke kun en team-ting, men kræver, at alle der samarbejder med de nye Scrum-teams, gør det på en måde, der sikrer, at Scrum-processen kan fungere smidigt. Frem for alt kræver det, at man har ledelsens opbakning.

Det er også værd at holde sig for øje, at det system, de store projektlederorganisationer har forsøgt at skabe omkring projekters gennemførelse igennem de sidste mere end 50 år, er skabt af en årsag. De enkelte elementer i disse metoder går ikke væk bare fordi, man begynder at arbejde agilt.

Man kan naturligvis sagtens argumentere for, at de klassiske projektmodeller var blevet for tunge, men uanset hvordan man gennemfører sine projekter, initiativer eller hvad man vælger at kalde det, får man en given – tit en større – pose penge til det, som sponsorerne gerne vil have bliver brugt fornuftigt. De vil også altid gerne vide, hvornår de kan regne med, at løsningen bliver færdig. Sådan er det også, selvom man arbejder agilt.

Det kræver en planlægnings- og governance-struktur, som man tit glemmer i farten, når man beslutter sig for at arbejde med Scrum i sine teams, for hvem påtager sig lige ansvaret for det, når nu man har smidt sine projektledere på porten?

Snakker vi Scrum, er det faktisk Product Ownerens (POens) opgave at have styr på økonomien og de langsigtede planer. Men POen skal ideelt set komme fra det lidt elastiske begreb ”forretningen”, og hvis man endelig får overtalt nogen til at påtage sig PO-rollen (eller tvinger nogen til det), så handler det som regel om folk, der er blevet ansat til noget helt andet. F.eks. marketing eller salg af det produkt, de nu bliver ”ejere” af.

Man ser ofte i den type projekter Denne slags POer har ikke altid hjertet med og forstår ikke altid, hvad der ligger i rollen, og det, der lugter af god gammeldags projektledelse, dvs. administration, planlægning og opfølgning, er tit det sidste, de har lyst til.

Dertil kommer, at man skal have alle interessenterne til de nye agile teams til at ændre adfærd. Dem kan der være mange af, og de kan ovenikøbet have modsatrettede interesser. Hvis de ikke køber ind på den kulturforandring det er at arbejde med Scrum eller endnu værre med SAFe, men fortsætter med at gøre det, de plejer at gøre, så kan det kun blive en humpende affære.

Mange organisationer – også de mest succesfulde – er ikke nødvendigvis særlig modne i den måde de fungerer på. Man ser ofte folk have sine yndlingsudviklere, yndlings-supportere, yndlings hvem-det-nu er, som de går direkte til, for så ved man, at der sker noget. Dén går bare ikke, når man arbejder agilt. Her må man tilpasse sig den struktur og proces, der ligger omkring den agile tilgang, man har valgt. Ellers knækker den agile kæde.

Det er derfor, jeg siger, at det er en firmasport at arbejde agilt. Der kommer ikke en pind ud af at introducere en ny arbejdsmetode på team-niveau i IT-afdelingen, hvis ikke resten af organisationen forstår og formår at spille sammen med disse teams, som det er tænkt.

Topledelsen skal med

Jeg har prøvet lidt af hvert som agil rådgiver, coach og underviser igennem de seneste 12-14 år, men fællesnævneren for de agile transformationer, der er lykkedes bedst er, at det har været topledelsen, der har truffet beslutning om, at der skal arbejdes agilt, og udviser vedholdenhed i deres opbakning omkring den agile vej, man har valgt.

Den fejlagtige tro på, at det agile skal vokse nedefra og gro organisk, kan måske være sympatisk nok. Det kommer bare aldrig til at ske. Store kulturmæssige forandringer, de adfærdsforandringer og forandringerne i de organisatoriske værdier, der skal til, kan kun startes oppefra.

Det er ledelsen, der skal gå forrest, når der skal skabes transparens, nye værdier, en åben feedback-kultur, mere ansvarstagen, uddelegering med videre. Dvs. alt det, der gør det muligt at få de agile frameworks og metoder til at fungere så godt, det kan lade sig gøre.

Det er temmelig usandsynligt, at man på team-niveau møder op en mandag morgen og bliver enige om, at ”vi trænger da vist til at give vores adfærd et kærligt eftersyn”. Eller ”skulle vi ikke tage og justere vores kultur”. Den slags forandringer drives top-down, og evnen til at lykkes med det, vil være afgørende for, hvor langt man kan drive den organisatoriske agilitet.

En anden ting, der er afgørende for sandsynligheden for at lykkes med at skabe agilitet, er modenheden i organisationen og de enkelte teams. Har man med en rodebutik at gøre, vil der ikke blive mindre rodet af, at man prøver at arbejde agilt. Det kan endda gøre tingene værre, fordi man lægger en masse nye tankegange, processer og teknikker oven i rodet. I stedet skulle man hellere bruge sine kræfter på at få ryddet op.

Hvis man har en række teams, der består af en flok individualister, der gør tingene på hver deres måde, vil det i sagens natur være mindre sandsynligt at man får succes med det agile, som i sin natur er meget metodisk, disciplineret og systematisk.

Før man overhovedet går i gang, betaler det sig derfor at tage et grundigt kig på sin organisation og spørge sig selv: ”Hvem er vi? Hvor modne er vi? Hvor forandringsparate er vi? Hvor dygtige er vi?” og mere i den boldgade. Hvis svaret viser, at modenheden er lav og det halter lidt med kompetencerne og disciplinen, så er den ubekvemme sandhed, at dette ikke vil ændre sig en tøddel fordi man begynder at arbejde agilt. Produktiviteten bliver akkurat lige så svingende og ustabil, som den hele tiden har været.

Det man trods alt får er lidt mere transparens, og det er naturligvis bedre end ikke at have transparens. Man skal bare forberede sig på, at man får nogle ting at se, som man ikke nødvendigvis bryder sig om. Det afgørende i den forbindelse er, om man handler på det, man ser.

Her vil jeg i forbifarten nævne, at hvis man har med en umoden organisation eller umodne teams at gøre, så er der kun en god agil vej at tage, og det er at vælge Kanban-metoden. I kraft af Kanbans 7-trins modenhedsmodel, der går fra niveau 0 til 6, kan man basere sin Kanban-implementering på det modenhedsniveau, ens organisation og teams nu engang befinder sig på.

Dén går ikke, hvis man vælger Scrum eller SAFe, der er ”alt-eller-intet” modeller, men det siger næsten sig selv, at man ikke kan trykke en model, der kræver stor modenhed ned over en organisation eller en række teams, der ikke er det. Både Scrum og SAFe kræver ret høj modenhed, hvis man skal have målbare positive resultater.


Forudsætningen for agil succes er ledelsens vilje og evne til at se fordomsfrit på organisationen og de agile modeller, der findes, og vælge den, der passer til konteksten.

Automatpiloten, der uden særlig omtanke nok ville vælge Scrum eller SAFe, fordi det er det, de andre gør, skal pakkes væk. Ikke to organisationer er ens, og det der kan virke det ene sted, kan bringe en total fiasko og et kæmpe spild med sig det andet sted.

Be the first to comment

Leave a Reply

Din email adresse vil ikke blive vist offentligt.