Jeg har i mange år tænkt dybt og inderligt over, hvorfor det er så svært at komme fra at have agile teams til at blive en agil organisation.

Jeg har taget udgangspunkt i de mønstre, jeg har set, når jeg har rådgivet ifm. agile transformationer og implementeringer, men selvfølgelig også i den teori, jeg underviser i bl.a. på Enterprise Scale Kanban-kurset fra Kanban University. Teorien hænger heldigvis fuldstændig sammen med virkeligheden.

Det viser sig, at der findes 4 afgørende områder, hvor man selv skaber barrierer for, at man kan blive en agil organisation. Dem tager jeg fat på i denne episode.

Vejen til at skabe enterprise agilitet, den findes skam. Den er ikke engang specielt svær at følge, men kræver, at ledelsen ændrer den måde de tænker og leder på. Og den kræver især at man griber tingene anderledes an, når man skal samarbejde på tværs.

Hvor de fleste ledere i dag leder mennesker, der sidder i faste teams, skal ledere, der har agile ambitioner for deres organisation, i langt højere grad tænke i systemer og skabe rammerne for at kunne håndtere leverancer på tværs af teams og afdelinger så smidigt som muligt.

Forleden dag læste jeg Project Management Institutes (PMI) forskningsbaserede ”Manifesto for enterprise agility”, som udkom i marts. PMI driver forskning i et omfang, som vi i Agil Agenda naturligvis ikke har musklerne til at gøre.

Det viste sig til min store glæde, at PMI er nået frem til præcis de samme konklusioner, som jeg selv er i kraft af de observationer, som jeg har gjort mig på mine agile opgaver gennem de sidste 10-15 år.

Det var egentlig ret opløftende, hvis det da ikke lige var fordi, det også var lidt trist. Tænk, at det er de samme mønstre, man ser, uanset hvor i verden man undersøger sagerne. Det er altså ikke kun i lille Danmark, at man selv står og stikker kæppe i sine agile hjul.

Lyt med, når jeg fortæller om de 4 barrierer, som man selv sætter op, og som gør det umuligt at blive agile på enterprise niveau. Jeg er ret sikker på, at du kan genkende nogle af dem.

Er man kun agil, hvis man arbejder i sprints? Det er der nogen, der mener, men kunne det synspunkt mon være en af de mange vedtagne sandheder omkring det agile, som ikke helt holder vand, hvis man tænker lidt nærmere over sagerne?

Det er tit sådan, at hvis der er mange nok, der siger den samme ting, så bliver det pludselig rigtigt, men denne ting skal jo helst også vise sig at være rigtig, når man ser på resultaterne ude i den virkelige verden.

Et eksempel på sådan en næsten vedtagen sandhed, er fænomenet ”et sprint”. Jeg møder igen og igen den holdning, at man ikke kan arbejde agilt, hvis man ikke arbejder i sprints. Nu har jeg sat mig for at se nærmere på den påstand. Hvad sker der egentlig, når man sprinter, og hvad med den proces, der ligger udenom?

Er sprints virkelig så agile, som mange mener, de er, eller kunne det i virkeligheden være sådan, at man faktisk ifører sig en stram, uagil spændetrøje, når man sprinter?

Jeg går til sagen så objektivt, som jeg overhovedet formår, og som altid læner jeg mig op ad den viden jeg har samlet op – nogle gange på den hårde måde - gennem de sidste snart 20 år. Den viden hænger selvfølgelig stærkt sammen mine praktiske erfaringer fra de Scrum, SAFe og Kanban transformationer jeg har stået i spidsen for eller været en del af ude i virkeligheden.

I den sidste ende er det jo det, der tæller, for virkeligheden vinder hver gang.

Er Kanban ikke bare en tavle?

Er Kanban ikke kun for små support teams?

Er Kanban ikke kun noget, man bruger, når Scrum ikke virker?

Svaret på alle 3 spørgsmål – jeg havde nær sagt myter – er et rungende NEJ! Intet kan være mere forkert.

Hvis nu du sidder og tænker: ”ja men, hvad skal Kanban så forestille at være”? Så får du svaret serveret lige her. I denne episode af ”Den agile agenda” tager jeg dig nemlig med på en lidt over 30 minutters overflyvning henover Kanban-metoden.

Jeg fortæller om de overordnede elementer, der udgør hjørnestenene i ethvert Kanban-system uanset på hvilken flyvehøjde man befinder sig. Det handler altså ikke om detaljerne i metoden – dvs. de 6 generelle praksisser og de forskellige Kanban-principper. Denne gang handler det kun om de fundamentale byggeklodser, som ethvert Kanban-system består af.

Uanset branche, uanset sektor og uanset størrelse.

Vi bliver som sagt i helikopteren, og fra denne synsvinkel får du indsigt i, hvorfor det er smart at tænke 3 flyvehøjder og hvorfor Kanbans upstream/downstream-tankegang gør så stor positiv forskel på flow og effektivitet, og gør det muligt for jer at skabe mest mulig værdi, og gøre det hurtigt. Du hører også om Kanbans fokus på service leverancer og feedback loops, som er limen, der får hele balladen til at hænge sammen.

Er du også interesseret i detaljerne, er du meget velkommen på et af vores Kanban-kurser.

Kanban er ”the law of work”, som én i mit netværk sagde. Der er ingen ønsketænkning i Kanban, og som leder skal man helst kunne tåle at se tingene, som de virkelig er. Dem, der tåler det, er til gengæld også dem, der kan flytte deres teams og organisation til nye højder.

Lyt med her og hør om det fundament, som ethvert Kanban-system er bygget på.

Du kan ikke forbedre noget, du ikke kan se. Derfor er continuous improvement – løbende forbedringer – en illusion, hvis du ikke arbejder i et transparent system. Og uden continuous improvement på alle leder og kanter – ingen agilitet

Men hvad er transparens egentlig? Jo, når I har transparens, betyder det, at I kan se, hvad der foregår på alle leder og kanter. I har styr på jeres processer, som er kendte for alle, og I kan gennemskue, hvad der sker på kryds og tværs af teams, projekter, afdelinger osv.

Problemet med transparens er bare, at når først I begynder at få tingene op i lyset, så får I nogle ting at se, som ikke er så kønne, som I måske gik og troede, at de var.

Transparens tvinger én til at se tingene i øjnene. Ting, vi måske helst ville ignorere. Og det er bl.a. her, at ledelsen kommer ind i billedet. Vi vil helst have modne ledere, for umodne ledere er ikke nødvendigvis vilde med transparens.

Præcis som med umodne medarbejdere kan de være nervøse for at få ødelagt deres version af virkeligheden. Modne ledere, derimod, ønsker klarhed, for det giver dem mulighed for at handle på de ting, der ikke fungerer ordentligt.

Det er måske en ildehørt sandhed, men kun modne ledere kan modne deres organisation, og kun modne organisationer kan arbejde agilt i stor skala.

Alt det vil jeg fortælle mere om i denne episode af Den agile agenda. God fornøjelse.

PS: Hvis du har emner, du gerne vil have behandlet i Den Agile Agenda, så kontakt mig meget gerne på [email protected]. Jeg er vild med nye ideer.

Scrum har længe været højt på den agile dagsorden. Det er nok fordi, det var det første agile rammeværk, som for alvor fik fat. Men I kan lige så godt glemme alt om de prædefinerede agile frameworks, hvis målet er enterprise agilitet, eller I bare vil løfte jeres teams til et højere modenhedsniveau.

Det lyder måske lidt barskt, men den er faktisk god nok, for hvis man kigger nærmere efter, så er fokus i Scrum udelukkende på arbejdsprocessen i hvert enkelt team. Scrum er simpelthen ikke bygget til at skalere.

Kigger man på SAFe, så ligger det i selve navnet, at det handler om at skalere det agile. Men gennem årene har der været mange diskussioner om, SAFe overhovedet er agilt. Det virker f.eks. ikke specielt fleksibelt og agilt at låse sine planer 3 måneder frem. Den stive struktur gør tingene statiske og dette i kombination med et kæmpe overhead, var jo bl.a. det, man ville undgå, da den agile bølge begyndte at rulle.

Men hvad gør man så, og hvad er alternativet, hvis Scrum og SAFe ikke er svaret? Det vil jeg tage fat på i denne episode.

Det er værd at lægge mærke til det faktum, at service leverancer typisk kræver en indsats fra mere end et enkelt team, og at de andre teams tit sidder spredt rundt omkring i jeres organisation. De har ofte nogle andre prioriteter end I har, og oveni det har forskellige service leverancer forskellige workflows.

Det er derfor jeres evne til at skabe flow og minimere ventetider, når jeres opgaver flytter sig på kryds og tværs af teams og organisatoriske enheder, der afgør, om organisatorisk agilitet er et fatamorgana eller en praktisk mulighed.

Sådan har det faktisk altid været, men først med Kanban har man fået en metode, der har flow som omdrejningspunkt, og som styrer disse tværgående ting og sager helt systematisk og proaktivt. Det er der heldigvis flere og flere, der får øjnene op for.

Enterprise agilitet er i den grad muligt at opnå, og I denne episode fortæller jeg om hvordan man kan komme derhen. Jeg fortæller om, hvorfor stærk agil ledelse er helt afgørende, og hvorfor Kanban-metoden er det oplagte men også det enkleste valg, hvis man gerne vil fra team til enterprise agilitet.

Ud med agil ønsketænkning og ind med en metode, der er skræddersyet til virkeligheden.

Skulle du blive mere interesseret i Kanban-metoden efter denne episode, så kan du finde en masse om Kanban, vores kurser og bøger med meget mere ved at hoppe ind på vores hjemmeside www.agilagenda.com.

Har du nogensinde deltaget i det daglige Scrum- eller Kanban-møde og hørt nogen sige: ”pu ha – jeg ved ikke lige, hvad jeg skal prioritere, for jeg har simpelthen så mange ting i gang”. Eller har du kigget på jeres agile tavle og tænkt ”hold da helt op – vi har godt nok meget i gang, men det ser faktisk ikke rigtigt ud til, at vi får gjort noget som helst færdigt”.

Hvis du kan genkende de situationer, ja så har du også mødt den snigende produktivitetsdræber, som det jo er, når I har for mange ting i gang på én gang.

Det at begrænse igangværende arbejde (work in progress = WIP) er en af de mest undervurderede men samtidig mest effektive redskaber, som du kan lægge i din værktøjskasse, hvis I gerne vil have mere gjort færdigt hurtigere. Vel og mærke i en ordentlig kvalitet. Det er simpelthen hovedvejen til flow og agilitet.

I denne episode vil jeg først fortælle lidt om, hvor ideen med at begrænse WIP opstod, og hvad fidusen ved det er, når man arbejder med videnarbejde. Derefter giver jeg dig 20 gode grunde til hvorfor, det er en vanvittig god ide at begrænse WIP.

Jeg kommer også ind på de indvendinger der er imod at begrænse WIP, og hvorfor ledelsen også skal slå sig selv over fingrene, når de får lyst til at starte nye projekter eller initiativer i en organisation, der i forvejen ligger vandret.

Skulle du blive mere interesseret i Kanban-metoden efter denne episode, så kan du finde en masse om Kanban, vores kurser og bøger med meget mere ved at hoppe ind på vores hjemmeside www.agilagenda.com.

Jeg kan tale meget længe om teorien i Kanban fra enhver tænkelig vinkel, men dér hvor det for alvor bliver interessant er, når teorien møder virkeligheden. Hvad vinder man ved at bruge Kanban, når man fører teorien ud i livet? Er det svært, og kan det betale sig?

Det er præcis, hvad denne episode i ”Den Agile Agenda” handler om, og det bedste af det hele er, at jeg har en gæst med. En gæst som har stor erfaring med at få Kanban til at virke ude i den virkelige verden.

Jeg har glædet mig sådan, og er stolt over denne gang at kunne præsentere Pia Kjellerup, der er Product Owner i Sydbank. Hun har mange års erfaring med at arbejde med Kanban, og hun og jeg tager en tilbundsgående snak om, hvordan Kanban virker helt konkret i hendes teams og i hendes organisation, og hvordan hun har grebet implementeringen an.

Vi dykker ned i en række perspektiver, som ikke kun handler om Kanban-metoden, men i høj grad om de dynamikker, der sættes i spil, når man går ind i en forandringsproces. For det er jo dér, det kan være svært. Pia deler gavmildt ud af sine erfaringer om:

• Hvad hun og hendes teams konkret får ud af at bruge Kanban.

• Hvorfor man ikke altid kan bruge Scrum, selvom de fleste andre gør det.

• Hvad hendes teams siger til at bruge Kanban.

• Hvad Pias stakeholders og ledelsen synes.

• Hvordan hun og hendes teams kom i gang, og om det var svært.

Lyt med og hør hvad en super-erfaren Kanban-praktiker kan fortælle om Kanban ude i virkeligheden. Der er meget inspiration at hente, bl.a. hvis du også har en uforudsigelig hverdag, hvor Scrum bare ikke kan virke. Og hvis du går med tanker om, hvad du kan gøre i stedet, så får du svaret serveret på et sølvfad af Pia lige her.

Kan Kanban skalere? Er Kanban rigtig agilt? Kan Kanban bruges til andet end i små support teams? De tre spørgsmål har jeg fået mange gange, og svaret på dem alle tre er et stort JA. Det kommer tit som en overraskelse, for der er så mange misforståelser og sejlivede myter om Kanban.

I dag punkterer jeg en af de største og tager fat i, hvordan man skalerer Kanban og skaber organisatorisk agilitet. Nemmere bliver det faktisk ikke at opnå holdbar agilitet i stor skala.

Kanban er en management-metode, der skaber orden i kaos og fjerner uforudsigelighed, og uanset hvilket organisatorisk niveau, man arbejder på, er omdrejningspunktet flow.

Flow på det strategiske niveau, flow på porteføljeniveau og flow på team-niveau.

I denne episode vil jeg fortælle, hvordan man temmelig enkelt og ligetil breder Kanban ud i hele sin organisation – ja, også de allerstørste - helt uden at skulle omkalfatre den. Helt uden nye roller og virkelighedsfjerne processer, og med overhead skåret ned til et absolut minimum.

Jamen hvad så med vores ”sprints”, tænker du måske. Ingen panik – det med at man skal arbejde i sprints for at være agil, er kun en form for dogme eller vedtagen sandhed. Hvis man kigger efter, vil man opdage, at sprints ikke giver nogen form for sikkerhed for, at ens planer holder, eller at man leverer effektivt.

Hvis man tager nok et spadestik, vil man også finde ud af, at hvis man gerne vil have agilitet på kryds og tværs i hele sin organisation, så vil sprints kun være en ulempe. Det er nærmest umuligt at koordinere tværgående issues og afhængigheder mellem mange teams’ individuelle sprints. Det er til gengæld ikke noget problem i Kanban. Her er der nemlig fokus på serviceleverancer og flow – på tværs af teams. Og vi er hoppet ud af sprint-spændetrøjen.

Lyt med og hør, hvorfor Enterprise Scale Kanban er den enkleste, sikreste og mest effektive vej til organisatorisk agilitet. Jeg tror, at du vil blive overrasket over, hvor nemt det kan være.

Der er mange myter om Kanban. Mange sejlivede myter, som ikke desto mindre er helt forkerte. Her kommer nogle stykker af dem:

• Man bruger kun kanban i små support teams.

• Man bruger Kanban, hvis Scrum ikke kan virke.

• Kanban er bare en tavle.

• Kanban kan ikke skalere.

• Man planlægger ikke i Kanban.

Disse myter har jeg lagt ører til mange gange, og hver gang bliver jeg lidt ærgerlig, for disse misforståelser er måske det, der forhindrer folk i at gå i gang med netop den metode, som er den letteste, hurtigste og billigste vej til at skabe målbar agilitet og dramatisk forbedrede resultater. Både i teams men så sandelig også på tværs af teams og organisatoriske enheder og niveauer.

Som akkrediteret Kanban-underviser og konsulent fra Kanban University er jeg dybt inde i detaljerne om Kanban-metoden, og i denne episode vil jeg dykke ned i, hvad rigtig Kanban er for noget og prøve at mane nogle af de bekymringer i jorden, som jeg indimellem hører som begrundelse for ikke at bruge Kanban.

Jeg fortæller om de byggesten, der skal til, når I skal have et godt, robust og effektivt Kanban-system op at stå, og du får også at vide, hvad I konkret vil få ud af at bruge metoden.

Hvis du vil vide endnu mere, kan du finde flere detaljer om Kanban og vores kurser og bøger på vores hjemmeside, www.agilagenda.com.

Her vover jeg pelsen, og tager fat i SAFe frameworket nok engang. Der er jo mange diskussioner i forskellige agile fora, der handler om, hvorvidt SAFe er agilt eller ej, og det er der mange holdninger til. Nu kaster jeg mine holdninger ind i diskussionen.

I de sidste mange år har jeg brugt meget tid på at analysere, hvordan de forskellige såkaldt agile tilgange virker. Både på papiret og ude i virkeligheden. Jeg er nået til den konklusion af nej, SAFe er ikke agilt og skaber heller ikke agilitet.

I denne episode fortæller jeg, hvordan jeg er nået til den konklusion og hvorfor jeg mener, at SAFe er unødigt dyrt og tilmed nærmest umuligt at få til at fungere.

Jeg indrømmer gerne, at jeg stikker næsen meget langt frem, og ved udmærket, at mange føler meget stærkt for SAFe. Jeg vil bare gerne parkere følelserne lidt og tage et nogenlunde objektivt og udogmatisk kig på SAFe og hvad man egentlig kaster sig ud i, hvis man vælger at gå den vej.

Her i den Agile Agenda tager jeg jævnligt fat i nogle af de myter og vedtagne sandheder, som florerer i det agile landskab. I dette tilfælde er det myten om, at SAFe er den eneste vej, hvis men er stor eller skal skalere det agile. I forbindelse med en tidligere episode, som også handlede om SAFe, gravede jeg i hvad andre agile specialister mener om sagerne. Jeg ville nemlig gerne finde ud af, om jeg var ”Annette alene i verden”.

I mit gravearbejde dengang stødte jeg på en hjemmeside, som faktisk har samlet en længere række agile koryfæers holdninger til SAFe. Den hjemmeside hedder: www.safedelusion.com, og her er der mange agile kendisser, der udtaler sig, ligesom du kan finde en række cases med eksempler på store virksomheder, der valgte SAFe til, men senere er gået væk fra det igen, fordi resultaterne udeblev, eller simpelthen gav dårligere resultater, end man havde før.

Summa summarum, så er mine konklusioner baseret på mine mange års praktiske erfaring med agile transformationer og viden om agile systemer fuldstændig på linje med de holdninger, som disse verdenskendte agile folk giver udtryk for.

Jeg vil lige understrege, at jeg ikke forsøger at overbevise nogen om, at de skal eller ikke skal arbejde med SAFe. Det vil jeg slet ikke blande mig i. Mit formål er alene at være rationel og faktuel og opfordre til, at der kommer flere fakta og færre følelser på bordet, når vi snakker agile tilgange.