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

Vidste du, at Kanban skaber de hurtigste agile resultater uanset hvilken metode, I i øvrigt bruger? Se myterne + en løsning

Jeg har nemlig et engangstilbud på en Kanban-pakke til dig

I de sidste +11 år har jeg nørdet agile metoder og frameworks. Jeg underviser i dem, og jeg bruger dem i praksis på de agile implementeringer, som jeg er en del af. Jeg spiser min egen medicin og mærker på min egen krop, hvad der virker og hvad der ikke gør.

Det jeg ser ”derude” er, at der florerer en masse misforståelser om, hvad Kanban-metoden går ud på. Det er ærgerligt og jeg gør alt for at ændre det. Ikke bare fordi jeg er blevet tilfældigt forelsket i Kanban, men fordi jeg har været hele vejen rundt i det agile univers og set (og selv bevist), hvor overbevisende resultater man kan skabe ved at arbejde systematisk med sine opgaver “the Kanban way”.

Kanban-metoden går ud på at sætte et system op omkring sine teams og aktiviteter og den måde, man arbejder med dem på. Enten i enkelte teams eller i hele organisationen og det er ligegyldigt hvilken slags viden man arbejder med, eller hvilken metode, man har valgt. Scrum, SAFe, PRINCE2 osv.

Men så længe myterne om Kanban er i live, så forhindrer det faktisk folk i at vælge den ultimativt letteste (og faktisk også billigste) vej til organisatorisk agilitet. Simpelthen fordi de (endnu) ikke ved, hvad Kanban i virkeligheden går ud på. Derfor skal du ikke lade dig nøje med en halvkvædet vise. Du skal have alle versene med.

Lad mig fortælle, hvad der overrasker folk mest om Kanban

De fleste af mine kursister m.fl. bliver overraskede over at høre at:

”Kanban er en management metode”

Måske er du også en af dem, der tror, at Kanban kun handler om at skrive sine aktiviteter på Post-its og plante dem på en stor tavle. Så kan man se, hvad der er i gang, og derefter kører tingene, som de nu engang gør. Det er der faktisk mange, der tror.

Faktum er bare, at en Kanban-tavle, hvad enten den er fysisk eller virtuel, er så meget mere end en opgavetavle. Selvom den er super vigtig, fordi den er med til at skabe transparens, så er den faktisk kun en mindre del af Kanban-metoden.

Med Kanban kan I nemlig styre hele jeres arbejdssystem på en ultrastruktureret måde. I systematiserer den måde, I prioriterer og kommunikerer på og ikke mindst behandler jeres blokeringer og flaskehalse på. Alt sammen på tværs af teams.

Jeg tør næsten vædde på, at de fleste af jeres flaskehalse handler om et eller andet, som ikke virker optimalt i jeres eget organisatoriske system. De skaber selvpåførte forsinkelser. Det kunne man jo vælge at gøre noget ved, hvis ellers man kunne se det. Med Kanban får I denne transparens.

Som jeg plejer at sige til mine kursister: ”Kanban sætter et stort spejl op foran jeres organisation og viser jer, hvordan tingene (d.v.s. arbejdet i jeres teams inden- og udenfor IT) egentlig går”. I får ingen skønmalerier at se, som I alligevel ikke kan bruge til noget. I får den rå virkelighed serveret, så I kan tage stilling til, hvad det ville være smart at ændre.

Det er ikke nødvendigvis rart at se sig selv i spejlet, for man får også øje på sine mindre flatterende sider. Men det er jo virkeligheden, og den skal man kende, hvis man vil forandre noget.

En anden ultra-sejlivet myte

Den nok mest sejlivede myte om Kanban er, at metoden kun virker i små support-teams. Det er simpelthen så forkert som det kan være, og jeg har tit tænkt på, hvordan sådan en røverhistorie opstår.

Jeg er kommet til den konklusion, at det må være fordi Scrum, som primært bruges til software-udvikling, definitivt ikke kan bruges i support-teams. Simpelthen fordi man ikke kan forudse, hvilke supportopgaver, der dukker op. Selv i løbet af en dag. Så tanken om at planlægge aktiviteterne i et support-team bare en uge frem i et såkaldt sprint, er jo i sagens natur dødfødt.

Kanban, som er et flow-system, kan sagtens håndtere uforudsigelighed. Derfor virker Kanban også perfekt i support-teams. Det har så fået nogen til at konkludere lidt bagvendt, at så kan det nok kun virke i support-teams. Det er ærgerligt, og det er som sagt skrupforkert.

Sidder du og tænker:“Hey, vi kan da heller ikke planlægge bare en enkelt dag frem med sikkerhed. Der dukker altid et eller andet op, som vi ikke havde forudset, og som absolut skal laves her og nu – faktisk helst i går!”, så kan jeg fortælle dig, at det er en klassiker. Sådan er det faktisk de fleste steder.

Det er derfor, jeg gør meget ud af at fortælle, at det er hamrende smart at kombinere Kanbans principper med Scrum, så nogle af begrænsningerne i Scrum bliver fikset. Og da Kanban er en stor og integreret del i SAFe, så er det da ubetinget smart at blive god til Kanban og dermed få SAFe til at virke ordentligt. (Kanban virker selvfølgelig strålende helt alene. Det er jo en metode i sig selv).

Forestil dig det her:

“Hvad nu, hvis du og dit team kendte Kanbans praksisser og teknikker til bunds og med dem i værktøjskassen kunne gøre det, I allerede gør godt (måske med Scrum eller SAFe), bare endnu bedre?”

Især i disse tider gælder det om at arbejde så effektivt som muligt. Derfor er det en “easy win”, at bruge Kanban til at få mere fart på jeres leverancer, mere værdi til jeres kunder og mindre stress til jer. Det tør jeg godt at love, for jeg har set det ske så mange gange.

Kanban kræver overhovedet ikke, at I laver alt muligt om. Ingen omorganisering og ingen forvirring om roller og ansvar. I skal kun lære Kanbans ret så enkle regler at kende. Og så selvfølgelig følge dem. Ellers sker der jo ingenting.

Måske kan du se for dig, at det ikke ville være værst, hvis I selv uden de store anstrengelser kunne skabe forbedringer. Men hvordan skal du gribe det an?

Det er her, mit helt særlige tilbud kommer ind i billedet

Du kan lære præcis, hvordan du kommer i gang med Kanban hos jer eller optimere det gode, I allerede gør ved at springe på vores Kanban Management Professional (KMP) forløb på 2 x 2 dage. Det afholdes på Ecopark i Århus hhv. den 16. og 17. september og den 30. september og 1. oktober.

Det første kursus hedder ”Kanban System Design”, og du kan læse meget mere her >>

Det sidste kursus hedder ”Kanban Systems Improvement” og du kan se detaljerne her >>

Efter kursus nr. 2 får du en international certificering fra den førende globale Kanban-organisation, Kanban University. Bortset fra at komme hjem med en agil værktøjskasse, der nu bugner af nye værktøjer, så står du også med et stærkere CV.

Og nu til mit særlige tilbud: Jeg tilbyder dig lige nu (og kun denne ene gang) den mest attraktive Kanban-pakke, som du finder noget sted på kloden. Den består af:

1. De to KMP-kurser, som du kan købe samlet med en klækkelig rabat. Jeg giver dig simpelthen et afslag på 4.000 kr., så din samlede pris bliver 15.600 kr. + moms

2. En fri adgang til mit online kursus ”Bliv agil med Kanban”. Så kan du friske din Kanban-viden op når som helst. Jeg plejer naturligvis ikke at forære mine kurser væk, og alle andre må betale 4.400 kr. + moms

3. Et eksemplar af min bog, Kompakt basis-guide til Kanban”, som du kan bruge som opslagsværk. Den koster normalt 195 kr. + moms.

Samlet set står du med en foræring på 8.600 kr. + moms, og jeg ved, at det er værdi for alle pengene. Du bliver i dén grad klædt på til at komme godt og sikkert fra start med Kanban eller optimere, hvis I allerede er i gang.

Men hvorfor denne gaveregn?

Det er simpelthen fordi jeg er så glad for at komme ud af min hule og møde agile entusiaster igen ansigt til ansigt. Det er fordi, vi tager til Jylland med KMP-kurserne for første gang, og så er det selvfølgelig også fordi jeg glæder mig til at vise styrken i Kanban-metoden.

Har du spørgsmål, så kontakt mig gerne direkte her: annette@xvoto.dk

Det ville glæde mig sådan at møde dig den 16. september i Århus.

P.S. Der er ikke voldsomt mange pladser tilbage

Posted in Agil god praksis, Agil implementering, Agil realisme, effektivitet, God praksis, Kanban, Kommunikation, Ledelse, Management, Organisatorisk agilitet, Projektledelse, Transparens, Uncategorized | Tagged , , , , , , , , , | Leave a comment

How Scrum and agile teams can benefit from Kanban

Setting the scene

The agile wave has been rolling for more than 20 years now. It probably started as a reaction to the “old” bureaucratic, and heavy-weight project management methods and standards that at the end of the day could not guarantee project success despite their clear guidelines and roadmaps.

For many years Scrum has been the most widely used agile approach. Personally, I started on my own agile journey more than 10 years ago, and at that time, when someone mentioned agile, Scrum would be the next word coming up.

Back in the nineties when the agile movement started to gain momentum, Scrum was not the only method or framework, but it ended up being the one making it big on the global scene.

During the past many years, I have spent thousands of hours teaching Scrum, Kanban, and agile project management. I have written books and articles, given public speeches, and not least worked on numerous agile assignments i various roles.

I mention this to emphasize that I am not “married” to any particular method or framework (though I do have my preferences). I understand most of the ins and outs of “agile”, and I know from hard-earned practical experience that a one-size-fits-all model does not exist. Even if zealots may insist otherwise.

History repeating itself?

In the past few years SAFe has become increasingly popular, and I can understand why it seems so compelling. If you experience many of your projects failing, being delayed, or breaking the budgets, it is very tempting to start using a framework that seems to have everything covered. In SAFe most of the clever thoughts that have been thought over the past decades in the lean-agile space have been combined.

Lean, Scrum, Kanban, XP, DevOps, Lean Start-up are all part of SAFe, just as it has borrowed the Scrum Master and Product Owner from Scrum. On top of that, several new concepts and titles have been introduced. E.g. “Agile release trains”, “Solution trains”, “Release train engineer”, “Program Increments”, “Innovation and planning sprint”, and more.

This makes SAFe a highly complex model, and in fact it adds significant complexity on top of something that is already complex, namely, IT projects and programs. I would argue that this can only work in high-maturity organizations. To be honest, I still have not seen any organization applying more than a few of the elements from SAFe. They use those that are easiest to grasp.

These days I hear people asking questions about Scrum. Why is Scrum not the easy fix, that we hoped it would be? Why do we not see continuous improvement, as we expected? Why has our Scrum come to a stand-still, even though we are doing everything “by the book”? “Why do we have to go to all these meetings. We feel that we are wasting our time? Why are we still late? Etc. etc.

I have no doubt that similar questions will be asked about SAFe sooner or later, when people realize that they have bought into a wonderful but highly complex dream that cannot be put to life unless you (as mentioned before) are working in a highly mature organization.

Just as the agile pioneers turned their backs to the classic methods, I could imagine that there might be a movement away from agile frameworks that are either too loose, so you have to figure too much out for yourself or to rigid and complex, which makes it too demanding for organizations to make it work.

I am not implying that Scrum and SAFe cannot work, they absolutely can. However, there are several organizational requirements and prerequisites that must be met to get success with Scrum or SAFe. Most being of the more invisible kind such as culture, maturity, behavior, discipline, habits, change readiness, politics, values, and such. But what to do if these prerequisites are not met?

Well, luckily there are other (and simpler) paths to agility. More about that in a short while.

How do you get from feeling agile to knowing that you are?

As mentioned, IT projects are almost by definition complex. Therefore, you should do all you can to minimize this complexity, as it makes it easier to keep your projects, programs, or assignments under control. Again, this is where Kanban comes into the picture.

One of the main reasons to “go agile” is often poor project performance, and the classic way of managing projects is often blamed for this situation. However, projects do not fail because of the method you use or your Project Managers for that matter. They are probably well-trained individuals. It is more likely due to lack of organizational or team discipline, lack of needed competencies, and low project maturity, probably combined with several of the other aspects I mentioned above.

However, no agile method or framework can change or improve that. Only people can. But changing organizational culture, behavior, habits etc. is not easy. Most people would prefer to avoid changes if they could choose because it is hard work and requires conscious action. It is much easier to keep on doing what you always did.

That is why simplicity is key. It is much more likely that you will see changes happen if you take a simple path. It also helps if you are very explicit about what you want people to change. What do you want your colleagues to do tomorrow that they did not do today? The Kanban method offers this simplicity, and clear directions, and it offers a path to agility that can start small on the team level and expand to cover the whole enterprise as you become more ambitious.

On social media you often see people cheer about their agile achievements, and I have been working with quite a few agile teams that claim that now they are much more agile than they used to be. I can’t help but ask them: “How do you know? Did you measure it, and can you compare old and new results?”. Sadly, the answer has never been “yes!”.

Feeling agile is probably a rewarding feeling, but if you cannot back-up that feeling with data, there may not be so much to celebrate. If you can back it up, I will be the first to cheer with you. But how to get to the point where you know that you are moving in the right direction, and not just feeling it?

Again, I will point to the Kanban method, and let me explain why.

How Kanban can facilitate improvements in Scrum or agile teams

I have mentioned that it is quite easy to get started with Kanban. First of all, you do not have to change your organization, and that alone makes it simpler. So, if you are organized according to Scrum or SAFe, you just stick to that organization. But you top it up by working with some (or all) of the 6 general practices in Kanban:

  • Visualize
  • Limit work in progress (wip)
  • Manage flow
  • Make policies explicit
  • Establish feedback loops
  • Improve collaboratively, and evolve experimentally

If you are producing knowledge work, i.e. something that is not a physical thing, you can use Kanban to control and improve your services delivery.

Let us take Scrum as an example and look at how a few of the Kanban practices can be put to use to improve performance. Scrum Teams usually work with a minimal workflow. Often: “To do”, “Doing”, and “Done”. Kanban takes the workflow several steps further and visualizes what is actually happening end-to-end.

Are you analyzing what to do before you really start working on your task? Do you have a QA or testing procedure? Does it involve your users? If yes, your workflow might look like this: “To do”, “Analyze”, “Develop”, “Internal test”, “UAT”, and “Done”. This is one example of visualization. In this case an invisible workflow has become visible.

You might also visualize what is blocking your progress, and whether you can do something about it or not. You might visualize how long time an item has been blocked, what actions you have taken etc. This also helps create transparency which in turn gives you a healthy basis for decision-making. Decisions that will help you minimize the negative consequences of your blocked items, and result in reduced lead times, which ought to be what any team or organization should strive for.

Limiting wip is also a key to shorter lead times. The fewer activities you have in progress, the quicker everything goes. You can simply complete more in less time if you facilitate focus and less task switching by limiting wip. This can be done in any kind of team, and you can still work with time boxes, such as sprints if you prefer to. That is your own decision.

The same is true for the practice, manage flow. If you keep an eye out for tasks that are sitting idle in your Scrum board or have been blocked for some time, and manage these tasks proactively, you will …. Yes, you guessed it.… reduce lead times. In fact, this is also one of the ways that Kanban manages risk.

It would be taking it too far to go through all 6 practices, but they all boil down to the fact that there is much to gain if you succeed in reducing (project) lead times. Stable velocity or good estimates that drown in organizational “dirt” do not tell you much about your performance whereas lead times do. They clearly indicate if things are moving in the right direction. In a more agile direction.

With Kanban there is no wishful thinking, no crystal balls, or wild guesses. Kanban is data-based, which means that you act on facts and with your eyes open. Facts like actual lead times, facts about how long activities have been blocked and why. E.g. when waiting for a specialist, a decision, a 3rd party vendor etc. Applying good Kanban practice to your Scrum or Agile Team will help you increase transparency and improve efficiency.

I think of it as holding a mirror up in front of your team or even the entire organization, so you can see what is actually going on. Both god and bad. This makes it possible to determine where you would benefit from adjusting your system, your behavior etc. and improve one step at the time. Evolutionary change is more likely to stick and become good new habits.

High transparency can be scary for some, and it can be difficult to accept that there will always be something to improve. Reality may show that you are not as efficient that you would like to think, but the good thing is, that now you know so you can do something about it. Ambitious agile teams should welcome transparency and be ready to fix what does not work without annoyance, finger-pointing or blame games.

A few final words

I have given you a few examples of how the use of some of the 6 general Kanban practices can help Scrum or agile teams to improve their efficiency. There is much more to Kanban than this, but it would be very efficient first steps to bring these practices into play.

It would be a powerful yet simple path to higher productivity and agility without stressing or disrupting your team or organization. Why not give it a try?

P.S. This article has been published on the Digité blog too. Her you can find articles about Lean, Agile, Kanban and Successful Project Management see more on: https://www.digite.com/blog/

Read my new post about how Scrum and Agile Teams can benefit from using Kanban

Posted in Adopting agile, Agile failure, Agile implementation, Agile management, Agile maturity, agile realism, Agile transformation, Uncategorized | Tagged , , , , | Leave a comment

From idealized agile pictures to agile realism

A few days ago I read a really interesting article by Jan Wischweh. The topic was “The agile crisis”. (It was published on Medium.)

Jan W.’s article was spiced up with quotes by some of the agile heavyweights who back in 2001 signed the agile manifesto. Here are the two quotes, that I love the most. Robert C. “Uncle Bob” Martin says:

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”

Isn’t that so very true?

How often have your experienced that the focus when it came to IT-projects was almost solely on the Project Manager and the project method? E.g. PRINCE2, PMI or if we are in the agile world (this is where I am most of the time) then Scrum? As if this was the determining factor of project success…

If we take a look at Scrum, the main concern of many (managers and Scrum Teams alike) is to ensure that the Scrum events are held as they are supposed to. They focus on appointing a Scrum Master and a Product Owner (often any will do), and on doing ”the mechanics” slavishly.

But I have to ask: What about the values and the mindset that play such an important part in making Scrum work, and which also, if not primarily, lies on the shoulders of the IT developers? Just to mention a few:

  • Technical excellence!
  • Respect
  • Customer focus – well, in fact just focus
  • Openness
  • Commitment – e.g. to a sprint goal
  • Assuming responsibility
  • Transparency

Tough value-based prioritization is also ultra-important. This is where the Product Owner and the somewhat extendable concept of ”the business” come into the picture.

And while we are at it, let’s not forget “the Management”. Managers should respect the framework, support their Scrum Teams, and give their Product Owners the mandate to make decisions e.g. about priorities, as they are supposed to know best. (This is only rarely the case).

This is all about how values, mindset, culture, and all the “soft stuff” play an essential part in making Scrum work. But changing habits – sometimes very old habits – is extremely difficult. It is very hard work.

Did I mention, that I like Scrum a lot (when it works), and deliver Scrum training too?

No method (or framework) can save a poor organizational culture or prevent non-constructive behavior

But – and here comes the unpleasant truth – “the mechanics” don’t really matter, if they are all you enforce. A “fundamentalist” practice just for the sake of the practice will give you zero agility. This viewpoint is very well supported by the 2 ”Uncle Bob” quotes above.

Please, could we start increasing our focus on developer and management behavior? The sooner the better, because this is probably the most important part, if you want to get your agile motor running.

For several years I have been deeply annoyed with Scrum zealots, stubbornly insisting that if Scrum doesn’t work, it’s because ”you are doing Scrum WRONG”. This is nonsense. Scrum just doesn’t work everywhere. Neither does SAFe by the way.

In both cases there are prerequisites that must be met. Here are some of the most important points that will determine if Scrum and/or SAFe are realistic options:

  • Willingness to change
  • Maturity
  • Level of competence
  • Organizational structure
  • Culture
  • (Management)behavior
  • Processes
  • The types of work you do and the diversity
  • Stamina
  • Level of quality

I love ”agile”. I have absolutely seen it work and made it work with my own hands. But it’s not easy. ”Agile” is very much a ”people-thing” and it’s a big change to move in a more agile direction, if you are not the least bit agile already.

If you do decide, that organizational agility is a realistic possibility, and worthwhile pursuing, then you should carefully examine, which path to agility would be the best choice for you. There are several to choose from, but it should be your context that determines the way.

Although you may have a desire to become more agile, the conclusion you reach regarding the above points will determine if it makes sense to go ahead, or if you might as well save your time and money. Depending on the conclusion, some agile options might work, but some will not.

A “one-size-fits-all” method does not exist. Nor does an ”easy fix”. But if you want to take the simplest (and cheapest) path, then there are some methods and frameworks you should simply avoid due to their complexity. Even if they are popular and seem like “the thing to do” because that’s what others do. It pays to not be like agile lemmings.

The only method that I – based on my long, practical experience with “Agile” (and my professional pride and integrity intact) – dare recommend for any organization, team or project delivering services and doing knowledge work, is Kanban. Kanban facilitates systems thinking, systematically manages work and options (not people), and optimizes lead times (aka flow).

Let me tell you a bit more about Kanban for service delivery:

Independent of maturity, you can start small and then sharpen the Kanban knife as you move along and get your processes sorted out, together with your dependencies, blockers, and other killers of efficiency that we all know too well. In other words, Kanban facilitates evolutionary, sustainable change.

Kanban is the “start with what you do now” method. You don’t have to change your organization or fire your Project Managers. Kanban can be combined with basically any other method including Scrum, it scales up and out, and is flexible. But of course you must follow a few (simple) rules to make your Kanban system work.

If you want to learn Kanban, the Kanban-University-way, I invite you to jump on my certification course ”Team Kanban Practitioner”. The 25th February 2020, we are going to nerd ”agile” in the middle of Copenhagen. But until then, I can highly recommend you to read about ”The agile crisis”! (It made me think KANBAN!!)

You can also subscribe to my news letter, (for the moment only in Danish). Then you will be the first to know, when I offer Scrum or Kanban certification courses, etc. And not least when I start up my new agile master class. Of course you will always receive tips, tricks and news about “agile”, and what happens on the agile forefront. No spam. I promise!

P.S. I certainly deliver my courses in English too, so let me know, if you need a company course or just a course in English. I would absolutely love to!

Warm regards,
Annette Vendelbo
Xvoto

Posted in Adopting agile, Agile, Agile management, Agile transformation, Agilt mindset, Change Management, Kanban, Organizational agility, Scrum, Transparency, Uncategorized | Tagged , , , , , | Leave a comment

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