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å info@agilagenda.com. 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.

Uanset om du arbejder i en lille, stor eller gigantisk virksomhed, så foregår alt det arbejde I laver i 3 forskellige flyvehøjder. Der er simpelthen 3 forskellige niveauer. Nemlig det strategiske, det koordinerende og det udførende.

Uhyggeligt tit er der ikke sammenhæng mellem disse 3 niveauer, og den ene hånd ved ikke, hvad den anden laver. Derfor ser man tit, at teams på det udførende niveau arbejder på ting og sager, der ikke har rod i strategien, men stikker af i alle mulige andre og mere tilfældige retninger.

Det er selvfølgelig ikke særlig smart, for man kan kun bruge sine ressourcer 1 gang, og det skulle da helst være på noget, der hænger sammen med strategien. Og lige netop dét skulle det koordinerende lag helst sikre. Det gør de bare langt fra altid.

Men der findes en løsning på, hvordan man kan skabe den sammenhæng, der bør være mellem de 3 niveauer. Den løsning hedder Kanban, og i denne episode fortæller jeg om, hvordan det så lige hænger sammen.