Fra agile glansbilleder til agil realisme

Jeg har netop har læst en top-interessant artikel af Jan Wischweh. Den handler om “The agile crisis” og blev offentliggjort på Medium.

Artiklen af Jan W. er krydret med en række citater fra agile sværvægtere, bla. nogle af dem, der i sin tid underskrev det agile manifest. Her er to af de citater, som jeg er vildest med. De er af Robert C. “Uncle Bob” Martin:

1. “An efficient business discipline coupled to an undisciplined engineering team will very rapidly make a mess”

2. “An Agile team will be Agile no matter how the project is managed. On the other hand, a team that is not Agile will not become Agile simply by virtue of a new and fancy project management strategy”

Er det ikke bare rigtigt?

Hvor tit har man ikke set at fokus ift. IT-projekter nærmest kun har været på projektlederen og projektmetoden? F.eks. PRINCE2, PMI eller hvis vi er i den agile verden (der er jeg selv mest) så Scrum?

Tager vi Scrum, så er man tit mest optaget af, om man pænt afholder de Scrum-møder, man skal. Pænt udnævner en Scrum Master og en Product Owner, og i det hele taget kører ”mekanikken” slavisk.

Men, spørger jeg bare, hvad med de værdier og det mindset, der ligger i Scrum, og som primært ligger på IT-udviklernes skuldre? Jeg nævner i flæng:

  • Technical excellence!
  • Respekt
  • Kundefokus – ja faktisk bare fokus
  • Åbenhed
  • Commitment – f.eks. til et sprintmål
  • Ansvarstagen
  • Transparens

Benhård prioritering baseret på værdi er også mega-vigtig. Her kommer Product Owneren og det meget elastiske begreb, ”forretningen” også ind i billedet.

Og skulle man lige i forbifarten nævne ledelsen, som jo helst skulle understøtte deres Scrum teams, og give Product Owneren mandat til at træffe bl.a. prioriteringsbeslutninger?

Alt dette handler om, hvordan værdier, mindset, kultur og alt det bløde i det hele taget spiller ind, når man skal have et framework som Scrum til at fungere.

Fik jeg sagt, at jeg er glad for Scrum og underviser i det?

Ingen metode kan redde en skidt kultur eller dårlig adfærd

Men – og nu kommer den ubehagelige sandhed – mekanikken er i bund og grund ligegyldig, hvis det er det eneste, man håndhæver. En halvfundamentalistisk øvelse bare for øvelsens skyld bringer nul agilitet. Dette synspunkt understøttes så fint af de 2 citater af ”Uncle Bob” ovenfor.

Kunne vi ikke snart få lidt mere fokus på udvikler- og ledelsesadfærd, når nu det er det allervigtigste, hvis man vil have damp under de agile kedler?

Jeg har i flere år været dybt irriteret på de Scrum-religiøse, der holder stædigt fast i, at hvis Scrum ikke virker, så er det fordi ”man gør Scrum FORKERT”. Det er noget sludder. Scrum kan bare ikke virke alle steder. Det kan SAFe forresten heller ikke.

I begge tilfælde skal der være nogle forudsætninger til stede. Her er de vigtigste forhold, som afgør, om Scrum og/eller SAFe er en realistisk mulighed:

  • Forandringsparathed
  • Modenhed
  • Kompetenceniveau
  • Organisationsstruktur
  • Kultur
  • (Ledelses)adfærd
  • Processer
  • Typen af opgaver og diversiteten
  • Vedholdenhed
  • Kvalitetsbevidsthed

Jeg elsker ”agile”, jeg har absolut set det virke, men det er ikke nemt. ”Agile” er i høj grad en ”mennesketing” og det er en stor forandring at skulle bevæge sig i en mere agil retning, hvis man slet ikke er det i forvejen.

Afgør man, at organisatorisk agilitet er en realistisk mulighed, der er værd at forfølge, så skal man også grundigt undersøge hvilken agil vej, man skal vælge. Konteksten bør afgøre det. Selvom man gerne vil være mere agile, så er der, alt efter konklusionen på ovenstående punkter, mere eller mindre frit slag i den agile bolledej.

En “one-size-fits-all” metode findes ikke. Et ”easy fix” findes heller ikke, men hvis man gerne vil den letteste (og billigste) vej, så er der nogle metoder og frameworks, man skal gå i en stor bue udenom. Også selvom de er populære og det, ”de andre gør”. Det betaler sig at undgå den agile lemmingeffekt.

Det eneste, som jeg, ud fra lang, praktisk erfaring (og min faglige stolthed i behold) tør anbefale overalt, hvor man laver videnarbejde, er Kanban-metoden. Den tænker i systemer, styrer aktiviteter og optioner, og optimerer gennemløbstider (aka flow).

Man kan starte småt, og så gør man Kanban-kniven skarpere og skarpere efterhånden, som man får styr på sine processer, afhængigheder, blokereringer og andre effektivitetsdræbere, som vi kender alt for godt. Altså evolutionær, langtidsholdbar forandring.

Kanban tager udgangspunkt i jeres nuværende situation, og kræver ingen organisationsændringer. Kanban kan kombineres med alle mulige andre metoder inklusive Scrum. og skalerer op og ud.

Vil du lære Kanban på Kanban University måden, så hop på mit certificeringskursus ”Team Kanban Practitioner”. Den 25/2-20 skal vi nørde ”agile”! Midt i København. Men indtil da, så kan artiklen om ”The agile crisis” varmt anbefales! (Den fik mig til at tænke KANBAN!!)

Skriv dig også på mit nyhedsbrev, så er du den første, der får at vide, hvornår jeg holder Scrum eller Kanban-kurser. Begge dele med internationale certificeringer. Og ikke mindst hvornår jeg starter min nye agile master class op. Og så får du selvfølgelig også bare tips, tricks og nyheder om “agile”, og hvad der sker derude på den agile front. Nul spam. Det lover jeg!

Posted in Agil god praksis, Agil ledelse, Agil modenhed, Agil realisme, Agile, Kanban, Scrum, Transparency, Uncategorized | Tagged , , , , | Leave a comment

Agil dit og agil dat – agil ”buzz buzz” – agil mig her og der… Den usminkede sandhed om ”agile” set gennem en agil coach’s øjne

Jeg vil lige starte med at lufte min glæde over at være kommet igennem den hårde akkrediteringsproces for Kanban coaches (AKC) for et par dage siden! Jeg blev akkrediteret af den internationale organisation, Kanban University, der kører de nok mest kradsbørstige uddannelsesforløb inden for det agile felt, som man kan finde på kloden. Det kan måske overraske, hvis man er en af dem, der tænker, at Kanban bare er en opgavetavle. Det er det så langt fra, og jeg er stolt af at være kommet igennem nøglehullet. Det er nemlig ret snævert.

Dér stod jeg så med min AKC, og så var det, at jeg kom til at tænke på en række avisartikler og LinkedIn opslag, som har gjort nar af, at alting skal være åh så agilt i dag. I en af artiklerne får vi oven i købet at vide, at ordet ”agil” er gået hen og blevet et bandeord. Og flere kendisser har harceleret mod begrebet efter at have læst et jobopslag, hvor ordet var gentaget igen og igen og igen. De syntes, at brugen af ”agil” i jobopslaget – og i det hele taget – tangerer kvalmegrænsen og er blevet latterligt. Man bruger begrebet i sammenhænge, hvor det ikke giver mening overhovedet.

Måske bliver du overrasket, men jeg er faktisk tilbøjelig til at give disse debattører ret i nogle af deres synspunkter. Det, der på den anden side ærgrer mig, er, at denne skeptiske holdning til alt, hvad der lugter agilt, kan gøre det svært for agile nørder som mig selv. Lad mig uddybe hvorfor:

Jeg er agil ekspert, underviser, coach, konsulent, foredragsholder og forfatter. Jeg lever af at hjælpe virksomheder med at få sat skub til deres agile ambitioner og finde den vej, der er bedst, enklest og billigst for dem. Derfor kan jeg ikke komme udenom at bruge ”A-ordet”. Hvad skulle jeg ellers kalde det?

De sidste mange år har jeg brugt det meste af min vågne tid og en ordentlig sjat penge på at uddanne mig og sætte mig dybt ind i, hvordan agile systemer og de mest anvendte metoder virker, og hvad der skal til, for at de overhovedet kan virke. Denne støvsugning af ny agil viden stopper aldrig, for jeg kan ikke lade være! Dét er til mine kunders absolutte fordel.

Jeg afskyr enhver form for agilt plattenslageri. At arbejde agilt er hverken let eller intuitivt, og enhver, der påstår, at det er ”bare lige” at ændre DNAet i en organisation og gå fra en klassisk til en agil eller for den sags skyld fra én agil til en anden agil arbejdsform, burde smides på porten.

Hvad betyder det egentlig, at være agil?

Lad mig lige give dig en definition på, hvad agilitet er: ”Agilitet er at levere det rigtige stykke arbejde på det rigtige tidspunkt”. Det lyder da meget fornuftigt, ikke? Det lyder måske ligefrem som logik for burhøns, men det er beklageligvis alt andet end nemt. Det er bl.a. fordi, de fleste virksomheder er organiseret på en måde, der i stor stil spænder ben for at arbejde på en måde, hvor man rent faktisk leverer de rigtige ting til den rigtige tid.

De fleste organisationer er bygget som siloer med afdelinger, teams eller projekter, der får lov til at suboptimere på livet løs: ”Så længe det går godt hos os, så pyt med, hvad der sker i de andre teams eller projekter”. Man gør det ikke, fordi man er ond, eller ønsker noget dårligt for sine kolleger, man gør det af gammel vane og fordi, der slet ikke er nogen incitamenter til at tænke på tværs. Der måles ofte på en måde, hvor man kan blive straffet på sin egen økonomi, hvis man tænker på tværs, og så er man jo nærmest idiot, hvis man gør det alligevel. Også selvom man selv kan se, at det ville være for det fælles bedste. ”Money talks”, som man siger.

Selv et agilt framework som Scrum belønner i udgangspunktet ingen for at tænke ud af sit eget team. Man fokuserer på sit eget teams mål og ikke, hvad der sker til højre eller til venstre for ens team. Det er godt nok meningen, at man ”by-the-book” skal være krydsfunktionel, og at man i sit team skal kunne lave alt fra start til slut. Men velkommen til virkeligheden. Det er nemt på papiret, men sådan foregår det sjældent. Jeg tør ikke skrive ”aldrig”, selvom jeg aldrig selv har set eller hørt om andre, der har set sådan et team med deres egne øjne. Der skal jo nok sidde et enkelt team eller to derude et sted, som faktisk er lykkedes med at blive krydsfunktionelle.

Så længe der ikke er styr på, hvordan man får en opgave eller et projekt hele vejen igennem, fra det tidspunkt, hvor en eller anden får en lys ide, til han eller hun står med resultatet i hånden, så vil man løbe ind i myriader af forsinkelser. F.eks. når en opgave skal overleveres fra det team, som er færdige med deres del, til det næste team, der ikke er klart til at tage imod og arbejde videre med opgaven. Eller når man skal bruge ham Peter fra den anden afdeling, som ikke har tid lige nu.

Det er typisk et vilkår, at man er afhængig af flere teams’ bidrag til festen, og bl.a. dér ligger en stor hund – formentlig en Grand Danois – begravet. I snitfladerne, hvor halvfærdige ”dimser” ligger og venter – eller endnu værre – sander til. Eller aller værst: aldrig bliver brugt. Det giver et vanvittigt spild af tid og knappe ressourcer, og det værste af det hele er, at det kan undgås.

Ikke ved at ”disrupte” (et andet modeord) sin organisation, og omorganisere den til ukendelighed – det giver utryghed og forvirring, og kommer sjældent til at virke ordentligt. Simpelthen fordi det ikke føles som en logisk måde at arbejde på, selvom det måske ser logisk ud ved første øjekast, når man sidder og kigger på modellen ved sit skrivebord.

Tag i stedet et grundigt kig på Kanban-metoden, som ikke kræver, at man laver noget som helst om i udgangspunktet. Man interesserer sig udelukkende for, hvordan man arbejder med sine aktiviteter, og har fokus på at minimere risici. Bl.a. ved at kigge aktivt på tværgående afhængigheder og interessere sig for, hvordan nye ønsker systematisk og aktivt disponeres og prioriteres i et ”upstream” system. Det sikrer nemlig, at man udnytter sine specialister og andre knappe ressourcer optimalt. (Upstream Kanban er muligvis et nyt begreb, men mere om det en anden gang 😊). Kanban tænker med andre ord i end-2-end systemer.

At organisationer ønsker at blive mere agile og dermed bedre til at ”levere det rigtige stykke arbejde på det rigtige tidspunkt” er vel meget forståeligt. Ville man det modsatte, så ville det først være mærkeligt. Problemet i den sammenhæng er bare, at de færreste virksomheder er klar over, hvad der står på det agile prismærke. Lad mig nævne 2 af de absolut vigtigste ting:

Accept af transparens

Du bliver måske overrasket, men det er langt fra alle – hverken chefer eller medarbejdere – der er vilde med transparens. Det er hamrende svært at skjule dårlige beslutninger, tossede processer, arbejds- og beslutningsgange, eller for den sags skyld dovenskab eller manglende kompetencer og disciplin, i et transparent system. (Alle disse dårligdomme findes både i offentlige og private virksomheder. De private virksomheder har bare et større incitament til at gøre op med dem. De kan nemlig risikere at måtte dreje nøglen om, hvis de ikke er effektive nok.)

Transparens er til gengæld helt afgørende for at kunne foretage de løbende forbedringer, som jo også er en del af det agile DNA. Men man får så ikke kun de velpudsede og nydelige ting at se, man får også alt det, der er mindre kønt – endda decideret grimt. Men at skjule det, man ikke er så stolt af, er en rigtig skidt ide. Man kan nemlig ikke forandre eller forbedre det, man ikke kan se. Punktum!

Accept af at have eksplicitte regler

Det er nemt nok at sige, men tænk lidt over, hvor meget autonomi der ryger sig en tur, når man pludselig skal være helt enige om, hvilke spilleregler der gælder i ens virksomhed. F.eks.:

  • Hvordan skal man prioritere og arbejde med sine opgaver?
  • Hvordan bryder vi tingene ned, så vi kan være sikre på, at vi har fået det hele med?
  • Hvordan kan man fastholde fokus på det, man har igang, så man undlader at shoppe rundt imellem de mange aktiviteter på ens to-do-liste?
  • Hvordan skal man visualisere, hvad der foregår?
  • Hvordan sikrer man kvaliteten i det, man laver?
  • Hvordan arbejder vi med afhængigheder og flaskehalse?
  • Fortsæt selv listen – den kan blive lang!

I sådan et system, kan man ikke bare vågne op om morgenen og spørge sig selv: ”Nå, Annette, hvad har du så lige lyst til at arbejde med i dag?”. Det er nemlig fastlagt på forhånd af de regler og (nye) vaner, der omkranser det agile system.

Her mens jeg er i Kanban-humør, så lad mig lige i forbifarten gentage mantraet ”Stop starting – start finishing”. Hvis dette princip var synligt fra ens skrivebordsstol, så ville det pirke til ens tilbøjelighed til at task switche, hvilket de fleste gør hver dag og hele tiden, selvom det er verdens dårligste ide.

Nu har jeg nævnt 2 helt konkrete ting, som jeg ved, notorisk er svære at tage til sig, med mindre man da arbejder i et miljø med høj tillid, forandringsvillighed, stor fejltolerence, uddelegering af ansvar, aktivt lederskab og ansvarlige medarbejdere. Oven i det kommer så alt det bløde med vaner, mindset og værdier, som faktisk er det sværeste af det hele. Fordi vi er mennesker og forskellige.

Prøv at tænke over virksomheden, hvor du er nu eller grav i dine erfaringer. Hvornår har du arbejdet i en organisation, hvor man har kunnet sætte hak ved selv få af disse ting?

Det er bestemt muligt at blive mere agile, og det virker forrygende. Det er bare ikke en gratis omgang, og det er man nødt til at se i øjnene, hvis man skal lykkes med det.

Hvad synes du selv, og hvordan synes du selv, at det går?

Mine kunder siger, at de snakker med mig, fordi de ved, at jeg ved, hvad jeg taler om, og fordi de får rene ord for pengene. Selv har jeg taget en aktiv beslutning om aldrig bare at snakke mine kunder efter munden og give dem det, de tror, at de har brug for. Det mister jeg somme tider opgaver på, for hvem vil ikke gerne have et ”easy fix”? Der er bare det ved det, at der ikke findes noget ”easy fix”. At blive mere agil kræver ”De 3 V’er”:

1. Vilje

2. Vedholdenhed

3. Vaneændringer

Selv når det gælder Kanban, som er den simpleste vej til den agilitet, som så mange stræber efter, så kræver det en anden og mere struktureret OG disciplineret måde at arbejde med sine aktiviteter på. Altså ikke det man konkret gør. Det siger Kanban selvfølgelig intet om, men det system, som man lægger ned over sine aktiviteter, kræver tilvænning. Men nul ændringer giver nul forbedringer.

Jeg har indimellem haft diskussioner med andre agile coaches, der synes, at jeg ’styrer’ for meget, og at forandringer skal opstå spontant i teams eller hos ledelser. Men hvordan forestiller man sig, at nogen skal regne ud, hvad der forventes af en agil medarbejder eller leder, som måske har mange års erfaring med at arbejde på en helt anden måde?

Det er ikke alle i kongeriget, der gider eller har tid til at nørde med agile metoder m.m. Det er som regel heller ikke det, folk blev ansat til. Derfor bliver det langsommeligt, ineffektivt og dyrt, hvis man skal vente på, at vaneændringer og forandringer opstår spontant. Det kræver et blidt skub i ryggen. Lidt ligesom da man skulle tage kørekort, hvor det trods alt var rart, at der var en kørelærer til stede.

Mange ville i øvrigt helst være fri for at arbejde agilt, hvis de selv kunne vælge. Det kræver nemlig en vis anstrengelse at forstå, hvad det skal være godt for, og hvis man oven i købet selv synes, at ”det går da meget godt”, så kan man slet ikke se, hvad alt det agile pjat skal til for.

A close up of a sign

Description automatically generated

Derfor er jeg tilbøjelig til at anvise alternativer og facilitere, at der kommer fart på forandringen, men i en hastighed, hvor folk får sjælen med. Jeg er den største fan af evolutionær forandring (Kanban igen), for den slags forandringer sætter sig som nye gode vaner. Revolutioner sander til.

Jeg vil naturligvis gerne høre, hvordan mine kunder selv synes, at det går, hvad de gerne vil have skal ske og, hvilke ideer de har. Derefter fortæller jeg, hvordan jeg ser på verdenen med den viden og de erfaringerer, som jeg har i bagagen, og så finder vi vejen frem sammen. Det er vel det, man har en ekstern agil coach til.

Hvordan ser man forskel på en halv- og en helstuderet agil røver?

Nu skal jeg pibe lidt: Et af de problemer, som jeg og andre kvalificerede agile coaches har, er bl.a. at enhver halvstuderet røver kan kalde sig agil coach, og det er der også mange, der gør. Men…

  • Hvordan kan man kende forskel på de agile coaches, undervisere og konsulenter som virkelig ved noget og dem, der kun har kradset lidt i overfladen? D.v.s. dem, der måske kan de rigtige agile ord, men ikke forstår agile begreber og systemer i dybden, og derfor får trukket deres kunder eller deres organisation i en dårlig og dyr retning.
  • Hvis “agil” bare er blevet et meningsforladt buzz-word, hvordan skal man så kunne tro på, at der virkelig er noget at hente f.eks. i Kanban-metoden, som jeg selv er vild med, fordi den forandrer og forbedrer uden at ødelægge, og desuden er så langt fra buzz og så tæt på sammenpresset sund fornuft, som man overhovedet kan komme?
  • Hvad når de fleste hellere vil dejse om end at sige: “Næh, vi er faktisk ikke særlig agile”, og i stedet siger: ”Vi er skam vældig agile” uden at være det? Så bliver det at være agil pludselig noget alle kan være, hvis bare de selv synes, at de er det, og det er jo noget vrøvl

Her fristes jeg til at bruge et citat, som jeg virkelig elsker tårnhøjt – jeg mener, at det var Peter Plys, der sagde:

Man kan ikke vide det, man ikke ved!

Godt sagt, Plysbjørn, men hvad har det med ‘agile’ og Kanban at gøre? Det skal jeg fortælle dig:

Hvis man som kunde skal undgå at købe varm agil luft, hvis man skal kunne se forbi alt buzz’en og undgå at blive en del af den lemming-effekt, som desværre er omsiggribende, så kræver det, at man søger viden og sætter sig lidt ind i, hvad ”agile” er for en fisk. Men det burde jo ikke være så meget anderledes end når man skal købe enhver anden vare, hvor man sætter én, der ved noget om den slags varer til at vurdere, hvilken der vil være bedst at investere i.

I stedet for bare at gøre det, som naboen eller konkurrenten gør, og håbe at de har tænkt rigtigt, så skal man aliere sig med én, der kan fortælle, hvad der er op og ned i det agile landskab og fortælle ærligt, hvad det kræver af en organisation at blive agil. Så kan man nemlig træffe nogle langtidsholdbare beslutninger og valg, der passer til ens organisation og kontekst.

Det er i alle tilfælde vigtigt, at man fra starten erkender, at en agil implementering vil være en stor forandring for mange. Formentlig de fleste. Og folk ”regner den ikke ud”. Man skal være virkelig eksplicit omkring, hvad man ønsker, at folk konkret skal gøre anderledes i deres hverdag. Det er ikke nok at sige, at: ”Ja, nu skal du så være med i et selvstyrende team”. For hvad er dét lige? Selvstyrende hvordan? Selvstyrende hvor meget? Hvad betyder det, at den enkelte skal gøre?

Der bruges uhyggeligt mange penge og busser fulde af konsulenter på ”at blive agile”. Jeg er ked af at måtte sige det, men det er ofte skønne spildte kræfter, for de agile initiativer sander ofte til, så snart konsulenterne forlader butikken. De sander til, fordi den vej, man har valgt, simpelthen er så voldsomt anderledes og kompliceret, at den ikke kan holdes i live uden kunstigt åndedræt fra en masse (dyre) konsulenter.

Den valgte metode kan også føles så kontra-intuitiv, at man straks vender tilbage til ”plejer”, så snart man kan slippe afsted med det, og fokus har flyttet sig et andet sted hen. Derfor skal man gå efter en metode, som man selv synes lyder enkel og logisk. Den som man bedst kan se sig selv i, og som ikke ødelægger alt det gode, som man selvfølgelig også gør. Det kræver, at man undersøger, hvad der i det hele taget findes derude, så man kan vælge rigtigt i første hug. Forkerte valg koster kassen, og resulterer i, at man får kastet gode penge efter dårlige, hvis man stædigt holder fast i en metode, som bare ikke kan virke i éns virksomhed p.g.a. kulturen, adfærden, konteksten m.v.

Heeeelt ærligt! Er det ikke en konsulent, der snakker?

Måske tænker du: ”Jamen, hvad med dig selv? Du er da også agil konsulent. Er du måske gratis?”, og ja! Jeg er agil Konsulent med stort K, og nej, jeg er selvfølgelig ikke gratis. Jeg skal jo også have løn. Men konsulenter som mig har kun én dagsorden. At finde den mest gangbare agile løsning til de kunder, der vælger at samarbejde med os. Dét er vores drivkraft.

Jeg er ikke gift med andre end min mand. Jeg har ingen virksomhed bag mig, der hvisker i mit øre, at jeg skal huske at sælge mine kolleger ind. Jeg har kun én vare på hylderne og det er mig selv, og jeg skal ikke stå til ansvar for andet end min egen integritet, og den er høj.

Så for at vende tilbage til starten om ’agil mig her og der’ og ’agil buzz buzz’, så bliver jeg på samme tid voldomt irriteret over, at der bliver gjort grin med agile, for jeg ved, at ”skidtet virker”, når man griber det rigtigt an. Det giver enorme gevinster hele vejen rundt. Det er ikke noget jeg tror, det er noget, jeg ved, for jeg har selv haft hænderne i bolledejen så mange gange.

Men på den anden side, så kan jeg også selv blive træt af, at man bruger ordet agil i flæng. Alt kan og skal ikke være agilt. Det er meningsløst, og for at sige det ligeud – noget forsimplet fis. At forstå agile systemer er en færdighed, som man må bruge energi på at lære sig. Ellers får man kun mere af det, man hele tiden har haft. Bare med nogle andre navne.

Nu er det snart nytår, så hvis jeg kunne få et par nytårsønsker opfyldt, så ville det være, at folk kun brugte ordet agil, når det var relevant, og lod være med ukritisk at hoppe på den agile vogn, før man har undersøgt, om den kører den vej, som man gerne vil bevæge sig hen.

Til slut en lille test til dem, der har lyst

Du har måske opdaget, at jeg har fremhævet de ord, hvor ”agil” indgår i en eller anden form. Jeg har forsøgt at undgå ordet mest muligt, men det er hundesvært, når nu man gerne vil fortælle om fortræffelighederne ved den måde at tænke og arbejde på. Dette på trods af de mange negative vibes, der har været omkring ”agile” på det seneste.

Jeg har talt, at jeg har brugt en eller anden form af ordet 42 gange. Det er trods alt ikke helt så slemt som det jobobslag, som de førnævnte kendisser harcelerede imod.

Hvis jeg nu har talt forkert, selvom jeg har talt efter flere gange, og du kan fortælle mig, at 42 x agil ikke er det rigtige tal, så skriv det, du mener, er det rigtige tal i tråden på Facebook (eller LinkedIn for den sags skyld). Du må også gerne give mig ret i, at ordet står 42 gange. Det er bare for sjov.

Til gengæld vil jeg så tilbyde dig at være med til en premiere til ren indbrudspris. Jeg er nemlig også Akkrediteret Kanban Træner:

Kom med på mit første Team Kanban Practitioner kursus i Danmark den 21/1-20. Din pris er 4.800 kr. excl. moms men inkl. al forplejning OG certificerings-omkostninger. Normalprisen er 6.800 kr. excl. moms, så lige nu kan du springe på et akkrediteret Kanban-kursus med 30% rabat. Jeg oplyser dig din unike rabatkode, som du skal bruge, når du melder dig til. Du kan læse mere her:
Team Kanban Practitioner 21-1-2020

Kurset afsluttes med en internationalt anerkendt certificering fra Kanban University, og du vil stå med rigtig Kanban viden, som du straks kan tage i brug plus et styrket CV.

Alt det her bare fordi nogle havde set sig sure på ”agile” 😊

Posted in Agil implementering, Agil modenhed, Agil realisme, Agile, Agile transformationer, Forandringsledelse, Kanban, Ledelse, Ledelsesansvar, Uncategorized | Tagged , , , , | Leave a comment

Agil lemming eller agil leder?

Jeg har arbejdet med agile transformationer i mange år. Jeg elsker den agile tilgang, og kunne ikke drømme om at anbefale andet. Jeg bruger næsten alle mine vågne timer på at nørde agile metoder, skalering mv., så jeg kan være en kvalificeret og seriøs rådgiver for mine kunder.

Jeg ved, hvad der virker hvor, og hvorfor det virker. Jeg ved også præcis, hvornår man ikke kan få agile metoder til at fungere, og hvorfor resultaterne lader vente på sig. Det gør de desværre tit. Det er bare ikke metodens skyld.

Det sidste nogen med agile planer, har brug for, er et fundamentalistisk syn på hvilken metode ”man” bør bruge, for enhver organisation har sin egen kultur og organisatoriske opbygning og ikke mindst agile parathed.

Bl.a. disse faktorer er afgørende for, hvilken metode, der vil være bedst egnet, og om agile overhovedet kan bringes til at virke. Det ville være dejligt nemt, men der findes desværre ikke en ”one-size-fits-all” agil model. Man er nødt til at kigge på sin kontekst, og ville gøre sig selv en tjeneste ved at finde ud af, hvad der driver ens agile ambitioner og modstå fristelsen til bare at gøre det, som alle de andre gør.

Her kommer lemmingeanalogien ind i billedet. For hvis man i stedet for at sætte sig ordentligt ind i de agile sager, bare følger i fodsporene fra alle de andre, der heller ikke har sat sig grundigt ind i tingene, så risikerer man at ende med den samme halvdårlige og heldyre løsning, og med minimale, overfladiske forbedringer som resultat.

 

Agile som modgift til møgprojekter

Mange ser de agile metoder som den store modgift mod møgprojekter, men projekter bliver som regel møgprojekter af alle mulige andre grunde end projektmetoden. It-projekter fejler typisk pga. organisationskulturen, projektmodenheden, ledelsesstilen, politik, silotænkning og andre af disse “usynlige” ting, som gennemsyrer en virksomhed.

Det føles selvfølgelig mere behageligt at skifte metode, end at skulle se sig selv og sine kolleger i øjnene og erkende, at man har en uheldig kultur, skal gøre op med silotænkning og flaskehalse eller tage et par primadonnaer ved vingebenet og bede dem om opføre sig ordentligt.

Så man hopper på det agile tog med bind for øjnene og uden at vide, hvor det kører hen. Man disrupter sin organisation, som sidder fortumlet tilbage og ikke rigtig kan regne ud, hvad der skete, og hvad der nu forventes af den. Ofte mister man oven i købet gode medarbejdere på den konto. Det er dyrt, ærgerligt og ofte helt unødvendigt.

At arbejde agilt er et paradigmeskift. Også på ledelsesfronten!

Nogen lover dig måske guld og grønne skove, “hvis bare du følger vores vej”. Det kan lyde besnærende, men helt så nemt er det desværre ikke. Ingen metode kan fjerne kompleksiteten fra jeres it-projekter eller dæmme op for en uhensigtsmæssig kultur, manglende kompetencer eller en fraværende ledelse.

At arbejde agilt er et paradigmeskift, og succesen afhænger af jeres vilje til forandringer, kompetenceniveauet, og din egen (hvis du er leder) og dine lederkollegers vilje og parathed til at sætte jer ind i, hvad agile systemer kræver, og hvordan den gode agile leder samarbejder med sine agile teams.

Alting har en pris, og dette er prisen for at rykke i en mere agil retning. Dertil kommer, at man på alle niveauer skal begynde at gøre noget andet end man plejer. Selvfølgelig! Det er jo det, der er fidusen, hvis man vil se nye resultater.

Nu skal det ikke kun handle om, hvad man ikke skal gøre, så her får du 5 konkrete anbefalinger baseret på mine mange dyrekøbte erfaringer:

  1. Stik hovedet op over lemmingeflokken og træd i karakter som en ægte agil leder. Tag et realistisk kig på din organisation, og hvad den kan magte
  2. Sæt dig ind i, hvilket agilt system, der vil virke bedst i jeres kontekst
  3. Sæt konkrete mål for jeres agile transformation. Man kan sagtens planlægge sin transformation og måle, hvad man får ud af den
  4. Udstik synlige rammer for dine teams
  5. Puf blidt men vedholdende mod løbende forbedringer

Følger du denne 5-trins raket, så lægger du i kakkelovnen til voldsomme og langtidsholdbare forbedringer.

Nye agile arbejdsformer skal blive til nye vaner

Når du indfører en ny agil metode, skal der følge en brugsanvisning med. Alle involverede skal undervises i hvordan metoden virker, og hvordan den skal udmøntes hos jer. Folk ”regner den ikke ud”.

Agile systemer er ganske komplekse, det er IT-projekter også, så fortæl jeres teams, ledere, interessenter m.fl., hvad de konkret skal gøre anderledes i morgen ift. det, de gør i dag. Gør metoden operationel og afstem forventningerne hele vejen rundt.

SÅ skal I øve jer, og øvelse gør med tiden mester. Vær pragmatiske, tålmodige og vedholdende, så kommer de positive resultater som perler på en snor.

Vil du have flere agile goodies, så velkommen til mit nyhedsbrev her: http://www.xvoto.dk

Posted in Adopting agile, Agil god praksis, Agil ledelse, Agil modenhed, Agil realisme, Agile, Agile implementation, Uncategorized | Tagged , , , , | Leave a comment

Agile transformation is all about the willingness to change, but let me tell you a secret: not everyone or every organization embrace that change

For many years we have heard about the good things that will happen if organizations start increasing their agility, if projects become more agile, and if old habits are replaced with an agile mindset. The evidence is convincing. There are plenty of white papers, reports, research etc. that will support the viewpoint that the higher organizational agility the shorter lead times, faster time-to-market, higher customer and employee satisfaction.

In other words, ‘going agile’ seems like a no-brainer, and many companies do the attempt. However, many of those that try, are failing miserably. Not because they are different. Not because the agile method/framework could not work. Not because it’s particularly difficult. So why do they fail?

No management support – no significant agile change

To be blunt it does not matter what method you choose. It will not work if there is no management support and clear leadership, if the culture is bad, the behavior stinks, bad habits are accepted, and change is not welcome.

I know that there are “method fundamentalists” that firmly believe, that if only you use their method, everything will change automatically, but I must disappoint you. Nothing changes automatically, and no method will save you from failure, but a method can indeed help you succeed if you use it as intended.

Change feels dangerous and creates…. FEAR!

‘Going agile’ results in transparency, and it often means that people have to change working habits that are 5-10-20 years old. That’s not easy, and it may affect their self-perception. You may be a current-state-champion but will be a novice just like everybody else when new agile principles are introduced. You may have been a command-and-control type manager, and it may feel like an attack on you, when servant leadership becomes the new norm, and the bearing idea of self-organizing teams is introduced.

Such changes may trigger fear, but not until you get beyond that fear will agile change be possible. But of course, it is possible.

shutterstock_237341221

What happens in the real world?

I don’t suggest that my experiences are the only valid experiences, but after having lead a number of agile transformations in both big and small companies, public and private, and having coached many managers and teams on how to transform from classic silo thinking to agile systems, I have experienced the importance of management support again and again. If it’s there, magic may happen, if it’s not you cannot release the improvement potential that lies right in front of you.

It may be easy enough if you are a new company, that have made the decision to work agile from the very beginning. You can just insist that anyone that wish to be employed must work according to agile principles, or else they cannot work in your company.

It’s a very different matter to turn around a super tanker, that has been working according to non-agile principles for many years. Old habits must change. Both on the individual level and the organizational culture on the whole. That’s hard work! And it takes time and persistence.

You also need to determine how you will react if individuals start opposing the new agile structures and mindset. What will you do, if all agree to the rules that everyone should play by, and then you see colleagues neglecting or even obstructing those rules? What will you do if people refuse to be transparent and visualize what they are working on? What if inappropriate behavior and mindset remains unchanged?

These are not examples, that I just imagine might happen. I see them every day, and this has made me realize that unless you have strong management support and sponsorship, you may see minor improvements, but they may not even be worth the investment and the disruption that the agile transformation has caused.

Don’t despair and don’t drop your agile ambitions

Agile change is worth the while, and of course you can make it work, but first you need to ask yourselves:

  • What do we want to gain from an agile transformation?
  • How can we make sure we choose the right method that fits our context?
  • How will we plan the transformation and how will we implement? (Yes! Agile implementations can be planned)
  • What will we measure, and how will we determine if we are on the way to reaching our goals?
  • What will we do to those colleagues that cannot accept our new agile ways?
  • How can we ensure that continuous improvement does indeed become continuous?
  • How can we prevent ourselves from falling asleep, when we reach a certain level?

Once you have answered those questions, you are ready to start your agile journey. Full speed ahead!

Want to know more about me and Xvoto? Check us out here: http://www.xvoto.dk

shutterstock_350353085

Posted in Adopting agile, Agile, Agile failure, Agile implementation, Agile management, Agile transformation, Change Management, Organizational agility, Uncategorized | Tagged , , , | Leave a comment

How lack of real management support can kill agile ambitions

These days agile is the new black, and thanks for that! Having been an IT Project Manager for around 30 years, I have seen too many classic-style projects fail, because the budget or the time allocated to do the project did not match the scope, because of late or poor decision-making from the steering committee, or simply because the competencies to do the project were not available.

A lot of wishful thinking was forming our projects, and if you protested, you often got a direct order to go and fix the unfixable. You were the Project Manager, after all… I’m thankful that I had my crystal ball and magic wand, since I was often asked to be a magician 😊

_MGL1399 - Annette with crystal ball

Did these bad things go away with agile approaches?

Well, the answer is a definite maybe!

If we look at the Cynefin framework (By Dave Snowden) below, I guess that anyone with project experience can agree that we are usually in the complicated and/or complex area, sometimes even in the chaotic area, but seldom in the simple area where everything is perceivable, predictable and repeatable.

Therefore, we can forget the idea that the command-and-control style of management will work in these scenarios or insisting that as long as we plan long enough or try to standardize complexity – which by the way is impossible, we will achieve project success.

This has been experienced by many organizations, who have started to transform in a more agile direction. Usually they start up agile teams believing that their problems will then go away. Well, they may – but only if you are willing to pay the full price. Agile systems are not a team-thing only. They require a different management style too.

Cynefin Framework by Dave Snowden

3 ways that managers obstruct agility

When you move in an agile direction you will indeed see improvements. Mainly due to:

  • Increased transparency
  • A more frequent dialogue with your customer = earlier feedback

However, the big-scale improvements you were looking for, remain a dream only until you fix what impedes your agile system. Often the biggest impediment is the lack of real and consistent management support of your agile ambitions based on sound decisions.

  1. Mid-level managers do not really want to delegate decision-making authority to agile teams. Are they not managers after all!
  2. Both top- and mid-level managers return to “good old” waterfall habits as soon as difficulties arise. Even if experience shows that waterfall will not give them the results they seek
  3. They pick the agile elements they intuitively like but leave out what they don’t. This way your agile recipe will never work as intended

Changing your management style based on a shallow understanding of agile is not likely to happen. You must dig deeper!

For many years I have been coaching, training and working with organizations, large and small, to plan and execute their agile transformations so the new ways could turn into new good habits that stick.

We may as well face it: There is no easy fix. Again, look at the Cynefin framework. We are working in complicated or complex circumstances with known or even unknown unknowns. How could there be an easy fix?

“Going agile” is a change project that introduces paradigm shifts in the way you collaborate, manage and support agile teams. This requires effective, continuous communication and training at all levels in the organization.

Yes! Managers, even top-level managers, must be trained too. How else would they know how to best support their agile teams? This also sends a strong signal: “We believe in this transformation, it will not go away, and we are willing to change too”.

Scratching the surface is not enough. E.g. looking at the Scrum process which fits nicely to one single piece of paper, could never give you a deep understanding of the prerequisites to making Scrum work. The apparent simplicity of Scrum has generated numerous waterfall managers in disguise. They may use agile words, but they act as they always did.

Knowing this, we should recognize that:

  1. Changing old habits is a big thing that will not happen overnight. We need to be pragmatic and patient
  2. Many managers may intuitively feel that that they have more to lose that to gain working in agile systems. We must be able to explain what’s in it for them
  3. Old ways offer a false sense of security. They don’t work too well, but are known and feel comfortable. We must prove that agile systems are more predictable and more fit-for-purpose in complicated/complex scenarios

Analyze what agile framework or method is the best fit. Don’t forget Kanban. It is the alternative path to agility that works even where there is a lot of unpredictability.

Allow time to practice and make agile collaboration become a good habit. Then you will see benefits that will just keep growing

Posted in Adopting agile, Agil implementering, Agil realisme, Agile, Agile implementations, Agile management, Agile transformation, Change Management, Good practice, Management, Organizational agility, Transparency, Uncategorized | Tagged , , , , , , | Leave a comment

Lad os få realismen tilbage omkring Scrum. Glem Spotify. Glem “Scrum Nirvana”

Jeg har i efterhånden 10 års tid arbejdet med agile transformationer fra diverse vinkler. Jeg blogger, jeg underviser i Scrum og Kanban, holder foredrag om agile, coacher agile teams og rådgiver de ledere, som også må lægge deres ledelsesvaner om, hvis de skal kunne spille godt sammen med deres agile teams.

Ude i virkeligheden hos kunder, kursister m.v. hører jeg meget tit noget i denne retning:

  • “Jamen jeg har hørt at Spotify gør sådan og sådan, det vil vi også gerne”
  • “I Spotify fungerer selvorganisering perfekt! Sådan skal vi også være”
  • “Nogen, der arbejder for Spotify siger eller gør dit eller dat”

Det er ikke fordi, jeg vil være en æggeknuser, en party spoiler eller bare småirriterende. Men nogen er nødt til at sige det højt:

Vi kan ikke alle være som Spotify. Kun én organisation kan, og det er Spotify selv.

Scrum Nirvana findes ikke – jeg har i alle tilfælde aldrig set det…

Glem Scrum Nirvana – det findes alligevel ikke. Og hvis det skulle gøre i enkelte tilfælde, så er det fordi, man har arbejdet benhårdt på at komme derhen.

Scrum, Kanban m.v. er ikke en gratis omgang. Det kræver hårdt arbejde med virksomhedskulturen, medarbejdernes – og ledernes – mindset, at man tager de agile værdier til sig og arbejder efter dem. Og selve metoden? Den skal naturligvis følges, hvis man skal have noget ud af at bruge den. Sådan er det bare, og det er da bare almindelig sund fornuft.

Det jeg ser mange steder, er ledere og såmænd også medarbejdere, der tror, at man bliver agil sådan nærmest af sig selv. Men der findes desværre ikke en agil skjorte, man kan tage på en dag og BUM så er man agil. Sådan spiller det agile klaver desværre ikke. Hvis det gjorde, ville jeg gå ind i manufakturbranchen 🙂

Men det er ikke ens betydende med, at man ikke skal tage skridtet mod en agil samarbejdsform. Tvært imod, så er det noget af det smarteste man kan gøre, hvis man vil have mere gennem pølsemaskinen samtidig med at folk bliver mindre ophængte og stressede. Men man skal gøre det med omtanke og man skal have et formål og en plan med det.

Vigtigst af alt, så skal man være realistisk. Ingen organisation, der er siloorganiseret (krydret med personsiloer), har arbejdet vandfaldsagtigt i mange år, har mange tværgående afhængigheder og mere i den boldgade, vil kunne komme fra dette ståsted over til et nyt agilt fra et øjeblik til det næste. Man må indse, at der nemt kan gå et par år, før de nye vaner og tankesæt er blevet en del af organisationens DNA. Uanset hvad man ellers måtte love jer. (Mange lover lidt rigeligt).

De 3 vigtigste grunde til at agile transformationer tager tid

  1. Når man skifter til en agil arbejdsform, kan man ikke bare skifte organisationen ud samtidigt. Man har de medarbejdere, man har. Nogle er topentusiastiske, nogle kan ikke se, hvad agile skal til for, og andre er et sted midt imellem. Det er et forandringsprojekt, der tager tid, når alle skal med på den agile vogn. Modsat Spotify, hvor man slet ikke kan være, hvis man ikke er vild med at arbejde agilt
  2. Etablering af nye vaner tager mere tid, end mange har tålmodighed til at vente. At gå fra vandfald til agile er et paradigmeskift. Både for medarbejderne og for lederne. Måske især mellemlederne, som pludselig mister noget beslutningskompetence, som nu delegeres nedad.
  1. Mellemlederne og projektlederne er dem, der – i hvert fald med Scrum – bliver ramt hårdest af skiftet til agile. Jeg oplever jævnligt at blive modarbejdet af disse to grupper. Langt fra altid i det åbne – det kunne jeg forholde mig til. Topledelsens evne til at håndtere denne vigtige medarbejdergruppe er afgørende for, hvor godt en agil transformation lykkes og hvor længe den tager.

Tilbage til starten: Selv efter et par år er man næsten med statsgaranti ikke i nærheden af at ligne Spotify på den agile front. Men man kan med god planlægning og fokus på, hvor man vil hen og med en god portion vedholdenhed rykke sig skridt for skridt i en mere agil retning.

Agile metrikker

Jeg kan også kun anbefale at måle jævnligt, hvor meget I rykker jer, og hvor langt I er kommet. (Nu får jeg nok nogle stykker på nakken). Ja, jeg sagde måle! Man må gerne måle sine agile teams, og hvornår ville I ellers foretage en investering uden at se efter, om I får noget ud af den?

Vil I vide mere om, hvordan I får styr og retning på jeres agile transformation, så kontakt mig endelig på 51519297 eller skriv til info@xvoto.dk. Jeg svarer altid i løbet af nul-komma-fem.

P.S. Agile virker, så tøv ikke med at gå i gang. Men gør det først, når I ved, hvor I vil hen

Posted in Agil god praksis, Agil implementering, Agil modenhed, Agil realisme, Agile, Agile målinger, Agile transformationer, Agilt mindset, Forandringsledelse, Kanban, Ledelse, Organisatorisk agilitet, Scrum, Scrum Nirvana, Uncategorized | Tagged , , , , , , , | Leave a comment

PMI EMEA 2018 – here I (and Kanban) come!!

Nu har jeg fået fornøjelsen af at tale på PMI EMEA 2018 Conference i Berlin. Juhuuu!!! Mit foredrag, som jeg glæder mig meget til at gøre knivskarpt, hedder: “Improve Organisational Flow and Performance by Climbing Kanban’s Maturity Ladder”.
 
Det bliver så godt at rykke fra at tale om det, der foregår på team-niveau op til det strategiske, som i virkeligheden er dér, hvor man kan få tingene til at rykke og skabe vedvarende forandring. Ikke for forandringens skyld, men for at skabe hurtigere og bedre resultater = flere $ og større arbejdsglæde.
 
Det er blevet mere og mere tydeligt for mig i de efterhånden mange agile transformationer, som jeg har været en del af, at ledelsens aktive medvirken – eller det modsatte – er det, der får en transformation til:
1. at lykkes
2. at sande til eller
3. at køre direkte i hegnet.

Hvorfor kører agile transformationer i hegnet?

At en transformation kører i hegnet, har intet at gøre med den agile metode, f.eks. Kanban. Det har kun noget med viljen til forandring, lysten til transparens, og evnen til at kigge indad at gøre. Hvis dette mangler på ledelsesniveau, ja, så vil tingene sande til, lige så sikkert som at 2+2=4.
 
Og så har det selvfølgelig også noget at gøre med den agile coach’s evne til sammen med ledelsen at skabe struktur og retning for transformationen, så de forskellige teams ikke stikker af i alle mulige retninger. Det er beklageligvis noget, som mange glemmer i begejstringen over selvstyrende teams, og tværfaglighed. 2 ting, som i parentes bemærket, ikke bare kommer af sig selv.
 
Jeg arbejder løbende med at skabe balance mellem selvstyring og governance, som jo faktisk er en integreret, men lidt glemt, del af alle agile metoder. Vi har jo stadig en vare, der skal leveres.
Annette Vendelbo - dependency board
Men alt det vil jeg komme ind på i mit foredrag i Berlin, hvor jeg vil vise, hvordan Kanbans modenhedsniveauer giver klare anvisninger og retning på, hvordan man rykker sig fra et ofte (for) primitivt team Kanban board til det strategiske niveau, hvor man har styr på og balance i sin portefølje. Og så er det ikke engang særligt besværligt, når først man har sat sig for at gøre det. Det kræver bare min hjælp i nogle dage og lidt løbende coaching.

Undgå de værste fejl og book mig til et foredrag om f.eks. Kanban, Ledelsens ansvar i agile transformationer eller Sådan klarer I skiftet til agile med succes

Hvis nu du ikke skal til PMI EMEA konferencen i Berlin den 7-9 maj, men er blevet nysgerrig efter, hvordan Kanban gør dig og din organisation mere agil, så kan I booke mig til at holde dette foredrag – eller et særligt tilpasset til jer – hos jer. I kan altid kontakte mig på info@xvoto.dk, så er jeg på vej.

P.S. Kanban kan bruges overalt, hvor man leverer services. Det er ikke kun en IT-ting.

P.P.S. Hvis I bruger Scrum, men synes, at det er svært at få det til at virke, så skift til Kanban. Alle de teams, jeg har arbejdet med, har været i gang i løbet af nul komma fem og har skabt overbevisende resultater!
Posted in Adopting agile, Agil modenhed, Agile implementation, Agile transformationer, Kanban, Ledelse, Ledelsesansvar, Organisatorisk agilitet, Transparency, Uncategorized | Tagged , , , , | Leave a comment

SUCCESFULDE AGILE TRANSFORMATIONER KRÆVER ÆNDRET MINDSET, ADFÆRD, KULTUR OG DEN SLAGS BESVÆRLIGE TING

At gå fra en klassisk arbejdsform til en agil er en stor forandring. Man skal ændre vaner, der måske er 5-10-20 år gamle, og agile er ikke intuitivt. Mange undersøgelser beskriver gevinsterne ved agile, og på et enkelt A-4 papir kan man se, hvor simpelt det agile system er skruet sammen, men man kan hverken proppe Scrum eller andre agile metoder ind i en organisation og regne med at det virker, uden følgende forudsætninger er opfyldt:

  1. Man skal vide, hvor man vil hen med sin agile transformation
  2. Organisationen skal være forberedt på denne forandring
  3. Organisationen skal være moden til den

Lyder det som en ”no-brainer”? Jeg kan kun sige, at mine erfaringer fra mange års arbejde som agil coach og underviser viser, at:

  1. Mange virksomheder kaster sig ud i agile initiativer uden at gøre sig klart, hvad man vil opnå
  2. De færreste gennemtænker konsekvenserne for organisationen, og hvordan forandringen skal håndteres
  3. Systematik findes på personniveau, men sjældent som team-disciplin. Modenheden tænkes ofte højere, end den er i virkeligheden

At tænke modenheden op sker ikke fordi, man er urealistisk som sådan, men fordi man kun har sin egen organisation at spejle sig i og måle sig op imod. Man mangler sammenligningsgrundlag, og man ved ikke, hvad det er, man ikke ved.

Mange teams er ikke vant til at arbejde bevidst inden for rammerne af en metode. Ens projektleder kommer bare og udstikker aktiviteter og deadlines. Dette står i skærende kontrast til f.eks. Scrum hvor projektlederen er væk og teamet har stor autonomi.

Det betyder, at de enkelte teams evne til at tage ansvar og føle sig forpligtede for sine leverancer, kvaliteten og hinanden, vil være afgørende for, om jeres agile tiltag vil flytte jer særlig meget.

OG glem ikka, at en ændret tilgang til ledelse faktisk også en nødvendighed.

Det er lidt krævende, men lad det ikke stoppe dig. Agile betaler sig

Agile er hverken kontur- eller rammeløst, men man glemmer ofte bagsiden af ”selvorganiseringsmønten”, som er den styring, der skal til for at synliggøre, hvor organisationen bevæger sig hen og om den agile investering kaster noget af sig. Det får I ved at sætte netop de rammer og målinger op, der viser, om I rykker jer og er på rette vej ift. det, I gerne vil opnå.

Jeg har aldrig oplevet et nyt agilt team, der af egen drift sætter den slags målinger op, men jeg har bestemt set teams, hvor det bliver en sport at jagte forbedringer baseret på deres måleresultater.

Sætter I overordnede rammer på tværs af agile teams, får I en vis standardisering plus et sammenligningsgrundlag. I får større transparens og dermed basis for de justeringer/optimeringer, der giver størst resultater.

Små forandringer giver små gevinster. Tilfældige forandringer giver næsten ingenting

At agile metoder virker og giver øget produktivitet og kvalitet er for længst dokumenteret.

Alligevel vælger man ofte at plukke det i metoden, man synes bedst om og som nemmest glider ned. Man fravælger det besværlige – f.eks. det, der handler om ledelsesprincipper, samarbejdsform, adfærd og gamle/dårlige vaner.

Dette gøres med argumentet: ”Vi er helt anderledes hos os, så derfor vil ”princip X” slet ikke virke her. Her må jeg altid skuffe folk og sige, at nej, de er ikke en pind anderledes end andre organisationer i samme branche, hvor de stryger afsted på den agile bølge.

Nøjes I med at plukke enkelte dele ud, vil I alligevel se forbedringer. Typisk får I lidt større transparens og tættere dialog mellem team og kunde. Det alene betyder, at I rammer rigtigere i.f.t. jeres kunders behov. I bruger måske nogle nye begreber, men gør ikke for alvor op med jeres gamle ledelsesform og silotænkning. I kommer derfor ikke i nærheden af det optimeringspotentiale I har, men lidt sker der da.

Det kan blive værre: Lader I jeres nye agile teams køre uden styring og retning, og har I ikke tilknyttet en Product Owner, som virkelig kender de forretningsmæssige behov og udfylder rollen, så vil det være helt tilfældigt, hvor jeres teams bevæger sig hen, og I vil ikke vide, hvad der kommer ud af jeres agile initiativ, hvilket tit er ingenting.

Der findes desværre ingen hurtige genveje til organisatorisk agilitet

Lad mig opsummere: Når I går igang med jeres agile transformation:

  1. Gør jer klart, hvad I vil opnå
  2. Sæt nogle pejlemærker op, så alle ved, hvor I vil hen
  3. Mål om tingene går den rigtige vej
  4. Accepter, at denne forandringsproces er kompleks og tager tid

Men hvordan kommer vi igang med alt dette? tænker du måske. Her er svaret:

Kontakt mig på info@xvoto.dk, hvis I vil have adgang til en velafprøvet vej mod organisatorisk agilitet inkl. målinger. Så sparer I besværet med at opfinde dem selv.

Posted in Agil god praksis, Agil modenhed, Agile, Agile implementation, Agile transformationer, God praksis, Ledelsesansvar, Organisatorisk agilitet, Projektmetode, Uncategorized | Tagged , , , , , , , | Leave a comment

I HATE Transparency!!!

When I work with clients to help them transform towards higher organizational agility, I get lots of negative reactions to agile key principles. To many, these principles seem counter intuitive to their current way of working. But what disturbs the agile opponents the most is the need for transparency, which is one of the fundamentals in e.g. Scrum and Kanban. And, by the way, a prerequisite for improvement.

Even if most buy in to the idea that if you cannot see what happens in your system, i.e. your project, your department, your team, etc., you do not have a baseline for improvements and you cannot react sensibly and timely to whatever is disturbing the flow (=progress) in your system. I often experience that people resist to show what they are working on and how. This happens at the individual, the team, and the managerial level. But why?

Well, mainly out of fear of making it visible that:

  • All – managers too – make mistakes
  • We may not handle dependencies very well
  • We do things that don’t really make sense
  • Some are not as busy as they should be (and pretend to be)
  • We are not in control of our processes
  • We do not produce the results we could

To cut a long story short, many don’t want to know, and are afraid of discovering what is really going on. When you can see the “bad stuff” in your system, it will most likely point to something you or your team could actively do something about. Transparency makes it difficult not to react on what you discover and just let the “bad stuff” continue. It’s much easier to pretend that everything is OK.

Where does fear of transparency come from?

Well, 3 answers apply:

  1. Culture
  2. Culture
  3. Culture

If errors are not accepted in your company, you will most likely want to hide your mistakes. Transparency makes that impossible.

If top-down management is the norm in your company, you are not expected to question the orders you get. Even if you can clearly see that they will lead in the wrong direction. Managers that thrive on this management style will work against transparency, as this would put a big finger on the sore spots of their decisions, strategies etc.

If it is (silently) accepted in your company that not all employees are equally busy, and that some do not assume responsibility or show leadership, then your not-so-busy colleagues will oppose to transparency. They don’t want to be “found out”.

If any of these three situations apply, agile will probably not be the right choice anyway, so don’t waste your time and money.

The Spice Girl Question: “Tell me what you want, what you really, really want!”

If, on the other hand, you have decided that you do want improvements in:

  • productivity
  • time-to-market
  • employee satisfaction
  • customer satisfaction
  • quality

which are examples of good things that an agile approach usually brings, you need to carefully think about and understand what is driving your wish for higher agility. It might be one or more of above examples.

And WHEN you know what is driving the decision, you need to decide what method and approach can best get you to the desired end-point.

Agile looks deceivingly simple, but….

Whether you will succeed in making e.g. Scrum, Kanban, or SAFe work in your context will depend on whether you and your colleagues succeed in changing the company culture, old habits, and – not least – your mindsets.

You don’t put on an agile shirt on Monday morning, and “bang!” you are agile. Changing behavior is a big thing, and affect people on the personal level. You might need to change habits that are 5-10-20 years old. This does not happen overnight. It takes practice, will, courage, and time.

Once you know why you want higher agility and how you intend to get there, you need to train people. No matter how simple Kanban, Scrum, or SAFe looks on the surface, they are all quite complicated systems. Getting a new method to work requires training at all levels in the organization.

Don’t fall into the trap of educating only a few Scrum Masters or Product Owners, or sending a few on a Kanban or SAFe training course. A few people don’t stand a chance when it comes to changing a company’s culture, habits etc.

Agile systems only work when managers know how to interact with their agile teams, when business people understand the need for their availability for prioritization, direction, etc., and agile teams know what is expected from them.

Going agile requires investments, stamina, and time. But the investments will be paid back many times, if only you have a bit of patience.

So to sum up: Do ‘go agile’ – it really works! – but do it consciously!

Posted in Adopting agile, Agil god praksis, Agil modenhed, Agile, Agile implementation, Agile transformation, Change Management, Good practice, Management, Organizational agility, Transparency, Uncategorized | Tagged , , , , | Leave a comment

Debunking 3 big myths about Kanban

Yesterday one of my guest post was published on the Kanbanize blog. The post was inspired by some real-life experiences I have had working on agile transformations for various clients but certainly kick-started by an incident on the private level.

At a small birthday party we all had to present ourselves and what we were doing professionally. When it was my turn, I told the other guests that I was writing a book about Kanban. One of the guests being an IT professional said:

“But how can you write a whole book about Kanban – surely this must be a very thin book!”.

That made me think about the many misunderstandings about what Kanban is and the lack of knowledge of what it can do to improve service delivery. It also made me think about the myths that I have had to debunk over and over again during my Kanban training and coaching activities.

I decided to focus on the 3 biggest myths that I have been presented to over the years:

  1. Kanban is just a few columns on a whiteboard where a lot of sticky notes are moving back and forth at random.
  2. Kanban only works in small support teams.
  3. Kanban is not “real Аgile”

You can find my guest post here: Debunking 3 big myths about Kanban and read about why these three myths are…. only myths.

 

Posted in Adopting agile, Agile implementation, Agile transformation, Kanban, Uncategorized | Tagged , , , , , | 2 Comments