Ja, goddag og velkommen til det her spændende boginterview. Vi har inviteret Annette Vendelbo i studiet. Hun er agil ekspert og agil coach. Og hun har skrevet en bog, der handler om agile transformationer i praksis. Og den vil hun fortælle lidt om i dag. Velkommen, Annette. Tak skal du have. Det er meget spændende med din nye bog. Hvad er det egentlig, den handler om, det med agile transformationer? Hvad er det for noget? Agile transformationer er i virkeligheden, hvis nu jeg skal sige det ganske kort, den tid, det tager, fra en ledelse beslutter sig til, at nu vil man gerne skabe nogle forbedringer eller optimere et eller andet ved at trække sin organisation i en mere agil retning. Og så den tid, det tager at komme derhen, eller i hvert fald komme nogle skridt på vejen. Ja, ja. Bare sådan helt kort. Altså den bog, du nu har skrevet, hvem har du tænkt dig skulle læse og kunne have nytte af at læse den bog? Ja, det kan i virkeligheden være ganske bredt. Altså det kan være ledere, der overvejer at netop skulle starte på en agil transformation. Det kan også være ledere, der er gået i gang med det, men som måske er kørt lidt fast og godt vil have noget inspiration til, hvordan de kan komme ud af den her fastkørthed og komme videre. Det kan også være agile coaches, altså folk, der arbejder ligesom jeg selv gør. Jeg har, dengang jeg startede, der savnede jeg faktisk, at der var en bog eller den her, der kunne give mig lidt begreb om, hvad det var, man kastede sig ud i. Når man kastede sig ud i sådan en agil transformation. Ja. Så det kan være projektledere måske, som overvejer at gå i en mere agil retning. Det kan faktisk være ganske bredt. Nu ved jeg, at du har jo mange års erfaring som projektleder, og du kan jo hele området både i teori og i praksis. Og nu har du skrevet en bog. Der findes jo masser af bøger om projektledelsesmetoder, så hvad er det, der er det unikke ved denne her bog? Ja, den her bog, den er ganske særlig, fordi jeg forsøger at fortælle hele historien om, hvad det er, man kaster sig ud i, når man vil det agile. Den er skrevet i tre dele, og den første del, det handler om alt det organisatoriske, kan man sige. Alt omkring adfærd, omkring mindset, om kultur og forandringsparathed og modenhed og alle de her ting, som i virkeligheden er det, der er det svære ved det. Altså metoderne er i og for sig det nemmeste af det hele, men det at få ændret organisationen, få dem til at skifte vaner, det er en helt anden snak, fordi de her vaner, som folk arbejder med, der har jeg ofte været ud for, at det er folk, der måske har 10, 20, 30 års ansignitet. Og det er altså lige sin sag at vippe de vaner om til at blive nogle andre. Og det er det, der er vanskeligt. Så det er så den første del, jeg beskæftiger mig med de her lidt organisatoriske, komplekse ting. Og midterdelen af den, den handler om den model, som jeg selv bruger. Igen baseret på de erfaringer, som jeg har gjort mig, der savnede jeg at få noget mere håndfast og læne sig opad. Og det blev med tiden til den her seks-trims-model, som starter med, at man finder ud af, hvorfor vil man det her agile? Den dårligste begrundelse, det er fordi alle andre gør det, eller ens konkurrenter gør det, eller ham, man spiller golf med på banen, gør det. Man skal gøre det af nogle bestemte grunde, fordi der er nogle bestemte ting, man gerne vil forandre. Og det er det, vi snakker om i udgangspunktet. Og så noget af det, som tit sker, det er, at tingene sander til, når der er nyhedens interesse, den ligesom er dampet af. Så det at gøre, det er at planlægge det og transformere organisationen i den retning, man har tænkt sig. Og så i den sidste ende sikre, at man også skal få vedvarende forbedringer, som bare kan blive ved og ved og ved og ved. Og det er der, hvor man tit ser de bøger, der bliver skrevet. Det bare handler om et enkelt udpluk af agile metoder og nogle glansbilleder, som i virkeligheden ikke har rodet i virkeligheden. Okay, så denne her bog, den går bredt. Men jeg hører jo også, at du bruger ord som organisation, kultur, vaner, forandring. Så tænker jeg jo forandringsledelse og ledelse generelt. Så hvor er ledelsessegmentet i forhold til den bog, du har skrevet her? Altså ledelsen er jo fuldstændig alfa og omega for at få sådan nogle agile transformationer til at lykkes. Tidt så er det dem selv, der beslutter sig til at trække organisationen i den agile retning. Men det er ikke kun et spørgsmål om at sige, at nu skal I være agile alle andre. Man er nødt til som leder også at kigge sig selv i spejlet og prøve at se, hvad er det, jeg skal forandre? Hvad er det for nogle vaner, jeg har? Hvad er det for en ledelsestil, jeg har? Og stemmer den overens med den kultur, der ligger indbygget i agile systemer? Hvad er det, jeg skal forandre og gøre anderledes i morgen i forhold til det, jeg gjorde i går? Så ledelsen har en kæmpe rolle at spille, og det kræver også forandring på ledelsesplan. For eksempel i den måde, man leder sine medarbejdere, hvor teamet jo i agile systemer er meget, meget væsentligt. Der er større autonomi, og der er selvorganisering, selvstyring og alt det her, som mange taler om, men som kan være svært at få sat i spil. Det er ledelsens opgave at sætte rammerne for den her autonomi og for den her selvstyring, sådan at man er sikker på, at det sker inden for nogle afgrænsede områder, der gør, at man kommer det rigtige sted hen, og tingene ikke stikker af i alle retninger. Okay, så hvis vi lige kigger på ledelsesdelen igen, hvad er det så, ledelsen, når vi taler agile transformationer, skal begynde at gøre, og hvad skal ledelsen eventuelt holde op med at gøre? Altså noget af det, ledelsen definitivt skal, det skal kunne finde sig i transparens. Transparens, det ligger så indbygget som en del af alle agile metoder og frameworks DNA, men bagsiden af transparensmedaljen, det er jo, at man får nogle ting at se, man ikke bryder sig om. Og hvis man nu forestiller sig, at man er en leder, der ikke er særlig fejltolerant, så er det meget, meget vanskeligt at skabe transparens, fordi medarbejderne, hvis man er vant til at få, nu siger jeg det lidt populært, men en på kassen hver gang, man begår en fejl, så er lysten til at være transparens, den er virkelig meget begrænset. Så det gælder om, at ledelsen, hvis man har de tendenser, begynder at acceptere, at der begås fejl, altså vi er jo alle sammen mennesker, alle begår fejl, det er klart. Og det er det, der kommer med transparensen, man får en masse at se, man ikke bryder sig om, men det er jo så også muligheden for at skabe forandringer, fordi man kan jo ikke forandre det, man ikke kan se. Og pludselig kommer der noget op i lyset, det kan være intimiderende, og det er der, hvor lederen bliver nødt til at acceptere, at man får nogle ting at se, som man ikke lige havde regnet med måske. Ja, okay. Men nu er det jo ikke kun en bog for ledere, det her, faktisk slet ikke. Hvem ellers kunne have gavn af at læse den? Skulle det være projektledere for eksempel? Det kunne det sagtens. Altså nu er der det at sige til, for lige at vende tilbage til, hvad bogen handler om, at der er også et afsnit med de tre mest anvendte agile metoder, det er Scrum, Kanban og Safe. Og alt efter hvilken metode, der er tale om, så er der måske slet ikke nogen projektledere. Det er der ikke i Scrum, det er der ikke i Safe. Men det er jo ikke ens betydende med, at projektledere ikke kan have en rolle at spille. Der er nogle projektledere, der nærmest er spillende trænere, og der vil være nogle roller, der er naturlige for dem at tage på sig i de her agile frameworks. Og andre igen er måske mere produktfixerede eller strategisk fokuserede. Og de kan så påtage sig nogle andre roller igen. Så som regel er der et eller andet sted, hvor de passer ind. Men hvis vi taler Kanban, som tager udgangspunkt i den organisation, man nu engang har, og så skaber et system, hvor man sørger for, at tingene, det kunne være projekter, kommer så smidigt igennem som overhovedet muligt. Der kan man sagtens have projektledere, som man altid har haft. Og der har projektlederen den rolle, de nu engang har. Så det kommer lidt an på, hvor det er, man ligger sig henne rent metodemæssigt. Ja. Nu du siger metode, så kommer jeg jo til at tænke på, at Digitaliseringsstyrelsen har faktisk for nylig publiceret en nyhed med en status over statens IT-projekter. Og der er heldigvis, må man sige, en del grønne trafiklys. Men der er faktisk også nogle røde trafiklys på nogle af statens IT-projekter. Blandt andet nogle af dem, der har med skatter at gøre. Hvad siger du til det her med agile projektmetoder? Vil den slags være en slags quick fix, som kunne gå ind og ændre de her røde trafiklys til grønne? Jeg synes, der er to spørgsmål i det. Det ene er, om det er et quick fix. Og det er det aldrig, fordi der er en kompleksitet i det, som jeg snakkede om lige før, omkring den forandring, der skal ske rent organisatorisk. Og der er jo ingen metode i hele verden, der kan ændre en skidtkultur eller kan ændre kompetencerne hos ens medarbejdere. Så det er selvfølgelig, som det er. Men kun statslige projekter har glæde af at arbejde agilt. Der vil jeg sige ja til hver en tid. Det er klart, at der er nogle omstændigheder omkring organisationer, der er offentlige, som er anderledes end det er, hvis vi taler private organisationer. Altså der er et politisk element i det, der gør, at der kan komme noget lige pludselig, så uanset hvor meget man ellers havde planlagt, så kan man blive overhalet af en politisk virkelighed. Det er der jo ikke noget at gøre ved. Men det er noget, der i virkeligheden er i modsætning til den måde, man tænker planlægning i agile systemer. Så igen, der skal man så vælge sin agile vej med omhug og sørge for at trække det ind, der kan leve i den organisation, man er i. Og der er også en tendens til siloopbygning, hvor man, det er min oplevelse, jeg har jo arbejdet meget både i det offentlige og det private, at der er silotankegangen måske lidt mere, hvad kan man sige, fasttømret i det offentlige i forhold til det, man ser i det private. Og der vil man med fordel kunne prøve at se, om man kunne skabe nogle systemer, hvor man kom lidt ud over den her silotænkning, som man tit ser. Kan man magte det, så vil man med sikkerhed få nogle rigtig fine forbedringer ved hjælp af agile teknikker. Det er der ingen tvivl om. Okay, så du siger også lidt, at man kan nedsætte sin risiko for failure og at projekter går i hegnet med det her? Ja, det kan man. Det er en anden måde at risiko styre på, end man typisk er vant til. Men en af de måder, som bestemt reducerer risici, det er, at man ikke tager for meget ind ad gangen. Man har bedre overblik over nogle mindre klumper af ting, man skal udvikle eller arbejde med, frem for at have de her meget, meget lange stræk, som så viser sig at være planlagt på en måde, der ikke holder vand, når det kommer til stykket. Så det er simpelthen den måde, man planlægger på, der er ganske anderledes, og man med fordel ville kunne trække ind. Men nu var du ganske kort nævnt, du er jo sådan nogle ting som virkeligheden. Ja. Og det er jo sådan med virkeligheden, at når man er i projektarbejde, så kommer der lige pludselig en hasteopgave ind fra venstre. Hvordan er det med hastende opgaver, der maser sig på i de tre agile projektmetoder, du snakker om her? Ja, der kan man så sige, at der er større eller mindre mulighed for at hive ting ind sådan ekspres. Og i det, du spørger om her, der kan man lægge lige til højre benet, fordi man planlægger ud fra, hvad der er det allervigtigste, men man rummer også plads til, at der kan komme de her hasteopgaver ind fra venstre, uden at det på nogen måde skaber, ja, det vil altid skabe lidt disruption, hvis man kan sige det sådan, men det er ikke noget, der ødelægger det hele, hvorimod man i henholdsvis skrømmer safe planlægger i sprints, der har længere vejhed. Og der vil sådan nogle hasteopgaver kunne forstyrre den planlægning, man har lagt, fordi der kommer noget ind, der viser sig bare at være vigtigere end noget som helst andet, man kunne foretage sig eller i øvrigt havde planlagt. Ja, når nu du så taler om det her med planlægning og lange forløb, er der så også noget om, hvor store eller hvor små projekterne må og kan være, når man taler om de her metoder? Nej, det er der faktisk ikke. Altså, der vil være nogle metoder, Scrum for eksempel, som er mest egnet, hvis man snakker i enkelte teamsammenhænge eller bare nogle få teams. Ja. Hvorimod safe, det er beregnet til skalering, hvor man har adskillige teams, der arbejder på at skabe en løsning, der er målrettet det samme produkt, hvis man kan sige det sådan. Ja. Og kanbanen, som er meget fleksibel, det kan skalere lige så meget, som man har brug for, at det skal skalere. Det er et system, man lægger ned over den måde, man arbejder med sine ting på, og der kan man have et eller flere kanbanesystemer ved siden af hinanden, der så igen ryger op på det strategiske niveau. Så der er eksempler på kæmpe store organisationer, der har lagt kanbanen ind fra top til to. Og man kan også se det lagt ind fra bare på enkelte teams, fordi man har ønsket at arbejde med kanbanen bare på teamniveau. Så det kan blive så stort eller småt, som man har brug for, at det skal være. Ja. Med den erfaring, du har i bagagen, synes jeg, det kunne være interessant at høre om din erfaring med danske virksomheder. Har du set alle tre projektmetoder, altså Scrum, Safe og Kanban, implementeret i danske virksomheder? Ja, det har jeg da bestemt. Det har været lidt af hvert. Ja, og hvordan har det været med ledelsesinvolveringen de steder, du så har oplevet det? Altså det har været meget forskelligt, og der er ikke nogen tvivl om, at de steder, hvor ledelsen er gået i takt med de medarbejdere, der også skulle foretage den her transformation, de har været langt mere succesfulde end dem, hvor ledelsen holder sig lidt i baggrunden og lader det være op til teams. Fordi man der har så en disconnect imellem den adfærd, som forventes af både team og ledelse i sammenhæng. Der vil være en disconnect der, fordi ledelsen fortsætter, det er i hvert fald, hvad jeg har set nogle steder, fortsætter med at gøre det, de hele tiden har gjort, samtidig med, at de regner med, at de her nye agile teams, de kan trække hele transformationen. Og det kan ikke lade sig gøre. Men jeg har et andet spørgsmål, som jeg rigtig gerne vil stille dig, og det er, at du har sådan et skægt eksempel i din bog med, hvor du laver en sammenligning til, hvis nu man skulle ud og lave en lasagne, så er der noget med ingredienserne. Hvad er det? Jamen det handler jo altså om, at hvis vi står med en eller anden lækker opskrift på ens yndlingsmål, yndlingsmiddagsret, og man så begynder at hakke en hel og klippe en tog, for eksempel lasagne, når man siger, at det her med ost, det er ikke lige mig, og pastaplader, ah, heller ikke, det er ikke så sundt. Jamen det kan godt være, at man har noget, der på overfladen ligner en lasagne, men en lasagne er det altså ikke. Og det er det samme, der sker, og det er det, jeg ser rigtig mange steder, at man ligesom tager og plukker det, man ligesom kan se for sig, kan leve der, hvor man er, frem for at sige, at nu tager vi opskriften på den her agile metode. Og så bruger vi opskriften, som den er tænkt hele vejen rundt. Fordi, ja, der er jo tænkt over dem. Der er en grund til, at de ser ud sådan, som de ser ud. Ligesådan som der er en grund til, at Claus Meyers opskrifter ser ud, som de gør. Så man gør ikke sig selv en tjeneste, hvis man går ind og hakker og hugger for meget. Men meget ofte så gør man det, fordi man ikke kan se for sig, hvad de ting, man vælger fra, hvad de skal til for. Eller man synes, de er for besværlige til, at man kaster sig ud i det. Fordi det kræver ganske meget, som jeg sagde før, af vaner, arbejdsvaner, ledelsesvaner osv. At der er der altså nogen, der vælger at sige, at vi gør lige det her, for det er nemt nok. Men det her, der begynder at krasse lidt og blive lidt besværligt, det dropper vi lige. Og så får man altså ikke de resultater, man kunne få. Så man kan også sige, at hvis man vil vide lidt om agile transformationer, så har man nogle af ingredienserne i din bog? Ja, det vil man have, fordi jeg er hudløst ærlig. Altså igen, jeg beskriver nogle af de ting, som jeg har oplevet. Altså der er eksempler fra min praktiske virkelighed, som jeg deler her. Og det er både godt og skidt. Noget af det, som jeg er lidt ked af ved mange, jeg skal ikke kritisere noget, som helst, det er ikke det. Men mange af de bøger, der bliver skrevet, de tegner efter min mening et lidt for rosenrødt billede af, hvor nemt det hele er. Og jeg vil gerne, baseret på de her 10-12 års erfaring, jeg har efterhånden, skrive, at det er altså ikke det, man møder derude. Vi står ikke altid med et topmotiveret team og en ledelse, der bakker op, og folk er simpelthen så kompetente, som man finder nærmest ikke nogen mere kompetente i hele fædrelandet. Det er ikke altid de teams, man arbejder med. Det kan være en blandet landhandel af folk, der er supermotiverede og dygtige, og nogen, der er knap så motiverede, men dygtige, og nogen, der slet ikke hverken er motiverede eller dygtige. Men man har jo de ansatte, man har, og man skal få det til at spille så godt, man kan. Og det, jeg forsøger at gøre i min bog, det er at skabe et realistisk billede af, hvad man kan forvente, og hvad der skal til for at skabe succes med agile transformationer. For det er ikke, som du sagde før, et quick fix. Nej. Og jeg ved også, at du har nogle pointer omkring det, hvis man gerne vil teste det agile område af og lige nedsætter et pilotprojekt. Hvad er det så, der kan risikere at ske? Ja, altså det, jeg har set nogle gange, det er, at man bliver interesseret i det her agile, fordi der er jo sådan en eller anden, hvad kan man sige, vedtaget tro på, at bare man er agile, så bliver alting bare meget mere effektivt. Så bestemmer man sig til, at nu skal man prøve det af i en pilot, og man tager nogen, der virkelig er motiveret for det. Og hvis vi nu siger, at vi er i en skrumverden, det er der mange, der har hørt om og måske været en del af, at vi har noget, der hedder en product owner, som kommer fra det her lidt elastiske begreb, forretningen. At der kan man sagtens have en person fra den her forretning, der siger, nej, hvor kunne det være spændende at være product owner her, det vil jeg være med på. Så man sammensætter et team af knalddygtige mennesker, der bare er virkelig motiveret for at få det her til at ske. Og selvfølgelig går det godt. Så får man nogle super gode resultater, og så siger man, det skal vi bare have meget mere af. Og så forsøger man at smøre det ud over resten af organisationen, uden at lige se på, hvem er det egentlig, vi har siddende resten af, eller overalt. Det er ikke de her topmotiverede mennesker. Det vil sige, folk bliver nogle gange frygteligt skuffet, når de ser, at det, de har opnået i deres pilot, det kan man ikke gentage, når man forsøger at multiplicere det og sprede det ud over resten af organisationen. Så jeg vil hellere anbefale, at man tager et ganske plat almindeligt team, der består af lidt af hvert, og så prøver at se, hvordan det spænder af. I hverdagen. I hverdagen, ja. Lige præcis. Vi skal til at runde af, Anette. Jeg vil høre, om der er nogle ting, du gerne vil have bragt frem her, inden vi siger farvel. Åh ja, hvad skal det snart være? Det, jeg måske kunne bringe frem, det er, at jeg har simpelthen skrevet den her bog, fordi jeg synes, den manglede. Jeg kunne godt have tænkt mig, dengang jeg selv startede som Agile Coach, og det er jo altså også noget, som sagt, jeg deler her, ting, der er gået godt, ting, der er gået skidt. Der kunne jeg godt have tænkt mig at have noget at læne mig op af. Det havde jeg ikke. Så jeg håber jo altså også, det kan være både en hjælp for ledere, projektledere og andre Agile Coaches, at læse den her, og så prøve at se, hvordan man udsætter sig selv for. Og så vil jeg også til sidst nævne, at når jeg gennemgår de her tre mest anvendte Agile metoder, og det var Scrum, Kanban og Safe, så fortæller jeg både om de fordele, der er ved dem, og de ulemper, der er ved dem, men også de forudsætninger, der er for at få dem til at virke. Så man kommer væk fra det her glansbillede og begynder at få et realistisk syn på, hvad de hver især kan. Der er gode ting ved dem hver, der er også dårlige ting ved dem hver. Så man prøver at tage en afvejning af, hvad tror vi kan passe her hos os, i stedet for at bevidstløs gå efter det, man hører mest om, hvis man kan sige det sådan. Ja, og det er jo også derfor, det er så dejligt, at din bog hedder Agile Transformationer i Praksis. Ja, det er lige præcis det. Jeg spiser min egen medicin. Jeg er ude og undervise rigtig mange steder i både Kanban og Scrum, men jeg går ikke ud og undervise i noget, jeg ikke har prøvet med mine egne hænder. Det er en praksisbog, der er skrevet af en praktiker, som baserer det på mange års erfaringer. Ja, det er rigtigt. Vi siger tak herfra, og vi siger tak til Annette, og så ønsker vi held og lykke med den nye bog, Agile Transformationer i Praksis. Mange tak skal du have, Annie. Tak.