Den Agile Agenda

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.

Sådan skalerer man KanbanKan 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.

Lad os nu få punkteret nogle af de sejlivede myter om SAFeHer 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.

Rundt omkring på de sociale medier florerer en fortælling om, at NU er de agile rammeværk og metoder på vej i graven. Er der hold i det, eller er historien om den snarlige agile død stærkt overdrevne?Denne gang tager jeg fat i, hvad det er, folk er skuffede over og trætte af efter at have brugt de gængse agile metoder, som Scrum og SAFe i årevis. Du hører også om, hvorfor de faktisk er svære at få til at virke. Men jeg fortæller også hvorfor agil tænkning er mindst lige så relevant nu, som da jeg startede som IT-projektleder for mere end 35 år siden, og hvorfor jeg mener, at der heldigvis er håb forude.Vejen til større agilitet er faktisk overraskende enkel, hvis ellers man gider at lægge vanetænkningen til side. Svaret er Kanban, og hvorfor lige præcis Kanban er en enkel og ukompliceret vej, fortæller jeg også om i denne episode. Så velkommen til!

Få indsigt i, hvorfor agile frameworks som Scrum og SAFe er så svære at få til at fungere ordentligt, og hvorfor det er tæt på umuligt i offentlige organisationer. Hør også, hvad I kan gøre i stedet, hvis I også føler jer som medvirkende i et agilt teaterstykke. Vi dykker ned i:• Flow som er nøglen til agil effektivitet• Hvorfor det ikke skaber agilitet at ændre sin organisation• Hvad agil modenhed er og hvad det ikke er• Hvorfor Scrum-møderne ofte ender som det rene agile teater• Hvorfor det er nærmest umuligt at planlægge præcist, når man arbejder med viden• Hvorfor det gør en afgørende forskel at man begrænser igangværende arbejde i stedet for at begrænse tid. • Hvorfor sprints i virkeligheden spænder ben for effektiviteten• Hvorfor Kanban som alternativ til Scrum og SAFe er en mere sikker og effektiv vej til at opnå flow og agilitetJeg stiller skarpt på disse ting for at trække vanetænkningen ud af det agile og i stedet prøve at se objektivt på, hvad det egentlig er, der foregår derude.

This is the 3rd and last episode in this mini-series, and I am extremely proud to once again present you to a very special guest, namely, David J Anderson, the pioneer of the Kanban Method.In episode 3 you can look forward to getting David's answer to the big question: Why are organizations still reluctant to work with Kanban despite the significant, well-documented, and proven results? David will also share his insights on why Kanban is adopted eagerly in some countries and less eagerly in others. We talk about the enormous costs of agile transformations, and why leadership maturity plays an enormous role when choosing the path to agility. I am sure that you will be surprised when you hear this.We will also talk about the new book, Discovering Kanban, that David published recently. I guess you might call it a sequel to the famous Blue Book. You will also hear David’s thoughts about the future of Kanban, and last but not least you will get his recommendations on working agile in general.If you are interested in Kanban, you don't want to miss this mini-series, where I interview the very person who made Kanban for knowledge work one of the most used agile approaches globally.

This is the second episode of three in this Kanban mini-series, and I am extremely proud to present you with a very special guest. None other than David J. Anderson, the pioneer of the Kanban Method.In this episode, you can among other things look forward to hearing David talk about the effort it took to write one of the most important books in the agile space, namely, the "Kanban Maturity Model" (KMM), and the purpose of writing it. You will hear what improvement gains you can expect as you move from one maturity level to the next. You will also get exciting news about Kanban+, and you will get David’s answers to some of the questions I have repeatedly been asked by students and clients about the higher maturity levels in Kanban, i.e., what to strive for, what is feasible, and why.Just to give you a heads up on the topics of episode 3 in this mini-series, you can look forward to hearing us talk about why organizations do not "go Kanban", when there is such strong, well-documented evidence that it pays off big-time. David will talk about his work with the new book, Discovering Kanban that he published very recently. I guess you might call it a sequel to the famous Blue Book. You will also hear David’s thoughts about the future of Kanban, and last but not least you will get his recommendations on working agile in general. So, stay tuned.If you are interested in Kanban, you don't want to miss this mini-series, where I interview the very person who made Kanban for knowledge work one of the most used agile approaches globally.

This is the first episode of three in this mini-series, and I am extremely proud to present you to a very special guest. None other than David J. Anderson, the pioneer of the Kanban Method.In this episode, you can look forward to hearing David's views on the geographic spread of Kanban, where there is most traction, and details about the Kanban adoption in the Nordics. We will also discuss the increased focus on flow, and why you would do yourself a favor if you manage capacity rather than time. Another classic we will talk about is physical boards versus software boards and much more. Just to give you a heads up on the topics of episode 2 in this mini-series, you can look forward to hearing about the Kanban Maturity Model aka KMM, and the purpose of writing the book. You will also get exciting news about Kanban+, and David will give his answers to some of the questions that I have been asked over and over again about the higher maturity levels in Kanban, i.e., what to strive for, what is feasible, and why. If you are interested in Kanban, you don't want to miss this mini-series, where I interview the very person who made Kanban for knowledge work one of the most used agile approaches globally.

Der er opstået en slags blind tro på, at hvis man skal arbejde med noget IT-relateret, så skal man død og pine arbejde agilt. Mange vælger Scrum helt pr. automatik eller SAFe, hvis man er en stor virksomhed, der skal skalere. Men mon ikke sandheden er noget mere nuanceret? Giver det overhovedet mening i alle sammenhænge at arbejde agilt, eller er der situationer, hvor man næsten lige så godt kunne have smidt sine penge ud ad vinduet? Dette er et af de emner jeg kommer til at diskutere med dagens gæst, Annie Stahel, som er CIO i Danmarks Statistik.Annie og jeg taler også om, hvilke tanker hun har gjort sig om det agile, om hvad forskellene er på at arbejde i en offentlig virksomhed ift. vilkårene i private virksomheder, og hvordan det påvirker mulighederne for at arbejde agilt. Annie deler også de overvejelser hun gør sig, når hun vælger til og fra i det store agile landskab.Hør hvad denne ualmindeligt vidende og erfarne CIO har at sige om de agile sager med mere.

Der er så mange pudsige tolkninger af, hvad det vil sige at arbejde agilt, og hvad man kan forvente sig at få ud af en agil transformation. Jeg har nok set og hørt de fleste. Men det er faktisk som regel de ledelser, der beslutter sig for at ”gå agilt”, der har et noget skævt billede og nogle urealistiske ideer om, hvad de kan forvente at få ud af at kaste sig ud i de agile farvande.En trend imod det agile har været i gang gennem de seneste mindst 20 år. I mange organisationer, offentlige som private, har man naturligt nok været irriterede over, at ens projekter jævnligt overskrider både deadlines og budgetter, og de agile organisationer har ikke været sene til at synge deres sirenesang: ”Bare se, hvor hurtigt og effektivt alting går, hvis bare man bruger ”min metode” eller ”mit rammeværk”. Der er simpelthen blevet bygget en falsk fortælling op, og det er nærmest blevet gjort til en vedtagen sandhed, at hvis bare man arbejder agilt, så har man straks en kur mod fejlslagne projekter. Men velkommen til virkeligheden! Der findes ingen simple løsninger på komplekse problemer.I denne episode fortæller jeg, hvor hunden ligger begravet, og hvorfor ledelserne i de organisationer, der virkelig ønsker agilitet, må se at komme ind i kampen. Det er nemlig dem, der står med de gyldne agile nøgler i hånden.

I denne episode kigger jeg på forskellen mellem team or organisatorisk agilitet. Det er bestemt ikke det samme, og selvom det selvfølgelig er bedre at få nogle teams til at være mere agile, så batter det slet ikke i nær samme grad, som hvis hele ens organisation er det.Mens det ikke er så svært endda at skabe agilitet på team-niveau - i hvert fald ikke, hvis de teams, der er involveret, kan se fidusen i det og har lyst til at spille med - så er det en helt anden sag at skabe organisatorisk agilitet.Når jeg snakker formål med lederne i de organisationer, der vælger at sætte gang i en agil transformation, så drømmer de fleste om at få organisatorisk agilitet. I de to ord ligger i sagens natur, at hele organisationen er med ombord på den agile båd. Det er godt nok nemmere sagt end gjort og det kræver medspillere i ledelsen. De medspillere findes så langt fra altid.Derfor er dét, som disse ledelser får, sjældent det, de drømte om. Her fortæller jeg, hvad de så får og, hvorfor f.eks. organisationsændringer, ikke er vejen frem, når man skal skabe agilitet.

Vi er kommet godt i gang med sæson 2 af ”Den agile agenda”, og det er tid til at gå nye veje. Det betyder, at jeg med jævne mellemrum vil invitere gæster med i mit agile show, og første gang er i dag! Jeg er simpelthen så pavestolt over at kunne præsentere Afdelingsdirektøren for Strategi og Innovation hos Knowit/Miracle, nemlig Ursula Krogsbøll. Ursula Krogsbøll er en voldsomt erfaren kvinde, der ligesom jeg er glad for at dele ud af sine erfaringer. Hun ynder også at kalde en spade for en spade. Det ved jeg, fordi jeg har haft fornøjelsen af at holde foredrag sammen med hende bl.a. hos Dansk IT og itSMF, hvor vi har hørt om, hvordan hun sætter ”Turbo på det agile”. Det har været nogle stærkt inspirerende oplevelser. Hendes omdrejningspunkt var ved disse lejligheder at sætte et stort, fedt spørgsmålstegn ved nogle af de mærkelige ting, der sker på den agile front. Det er jo lige vand på min mølle, og derfor var det lige til højrebenet at invitere Ursula med i Den agile agenda, så I, der lytter med, også kan få glæde af hendes – til tider provokerende – perspektiver.Jeg kommer til at tale med Ursula om det agile overhovedet kan betale sig, og hvad kunderne egentlig siger plus meget mere. Hun fortæller også om Miracles agile opfindelse ”Fast-track Development”, der sørger for at Knowit/Miracles kunder hurtigt og tæt på risikofrit kan få rigtige leverancer baseret på rigtig udvikling på bare 12 uger.Vi kommer vidt omkring i de agile farvande, vi snakker om agile fiaskoer såvel som agil succes, og hvis du efter at have hørt os, synes at det kunne være spændende at vide mere om Fast-track Development, Kanban eller andet så er du velkommen til at kontakte Ursula her: Ursula.Krogsboll@knowit.dk eller mig selv her: annette@agilagenda.com.

I denne episode tager jeg fat i SAFe frameworket og det spørgsmål, jeg stiller mig selv er, om SAFe overhovedet kan siges at være et agilt framework. Det andet spørgsmål jeg tager fat i er, om det ikke også kan være ligegyldigt, om SAFe er agilt eller ej. Jeg fristes næsten til at sige, at jeg denne gang stikker næsen meget langt frem, for jeg er fuldt ud klar over, at mange føler meget stærkt for SAFe, og jeg har ind imellem fået kærligheden at føle, når jeg har forsøgt at få en nogenlunde objektiv og udogmatisk snak med folk, der er stærkt SAFe-forelskede.Men her i den Agile Agenda er formålet lige netop at tage fat i nogle af de myter og vedtagne sandheder, som florerer i det agile landskab. Jeg stikker derfor ikke halen mellem benene, men er dog ikke mere modig end, at jeg har forsøgt at grave i, hvad andre agile specialister mener om sagerne. Bl.a. den agile alliance, som var de folk, der i sin tid underskrev ”Det agile manifest”. I det gravearbejde 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 nogle af de folk, der har udtalt sig, er Al Shalloway, Mary Poppendieck, Jeff Sutherland, Mike Beedle, Ken Schwaber, Martin Fowler, Alistair Cockburn, Ron Jeffries, Dave Snowden og adskillige flere. Her kan du også 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å ligger mine konklusioner baseret på mine mange års praktiske erfaring med agile transformationer fuldstændig på linje med de holdninger, som disse verdenskendte agile folk giver udtryk for.Som jeg nævner i episoden, så er mit formål ikke at skulle overbevise nogen om, at skal eller ikke skal arbejde med SAFe. Det skal jeg jo ikke blande mig i. Mit formål er at tage et rationelt og objektivt kig på sagerne og et opgør med nogle af de vedtagne sandheder, der findes derude i det agile landskab. Det synes jeg nemlig, at der er alt for få, der gør.

Denne gang punkterer jeg myten om, at hvis vi bare gør et eller andet agilt, så sker der mirakler, og pludselig bliver selv de mest udisciplinerede teams til de rene eksekveringsmaskiner. Den slags ønsketænkning er mere udbredt, end man skulle tro, og hvor ville det da også være dejligt, hvis man bare kunne organisere sig ud af alverdens dårligdomme. Det kan man bare ikke, for hunden ligger begravet et helt andet sted. Hør, hvad der skal til for at skabe agilitet, hvorfor ledere, der udviser lederskab er altafgørende, og hvilken vej, I under alle omstændigheder kan vælge. Også selvom I har både uforudsigelighed, flaskehalse og andre slags "flowstoppers" i massevis i jeres organisation.

Når jeg denne gang snakker om Kejserens agile klæder, så er det fordi jeg tit føler mig som den lille dreng i eventyret, der peger og siger: ”jamen, Kejseren har jo intet tøj på”. Oversat til agilt sprog, peger jeg og siger: ”jamen, det agile kan jo aldrig komme til at virke på den måde”.Der er en del populære usandheder om det agile, som bare ikke har nogen rod i virkeligheden. Jeg har sat mig for at kigge nærmere på de vigtigste af dem, men vil også vende tingene på hovedet og tale om nogle af de upopulære sandheder. Dem som mange ikke har lyst til at høre, men som bare ikke bliver mindre sande af den grund.Der spildes ufattelige summer på at ændre den måde, man arbejder på i rigtig mange virksomheder. Man begynder at bruge en eller anden agil metode eller framework i håbet om, at miraklet så vil ske, og ens organisation begynder at levere deres projekter, initiativer eller hvad man nu kalder dem, i en ordentlig kvalitet, til tiden og uden at budgettet sprænges til atomer.Der laves mange agile fejlskud ”derude”, og som agil specialist gør det mig ærgerlig at se, hvordan mange – ofte store – konsulentvirksomheder lover guld og grønne skove helt uden at have noget at have de løfter i.Virksomhederne og medarbejderne betaler dyrt for det, og det kunne have været undgået, hvis bare man havde taget et fordomsfrit kig på realiteterne. Man skal i øvrigt altid være skeptisk, når nogen lover det hele for det halve.

Når jeg denne gang tager de 6 problemer, der forhindrer Scrum teams i at levere stabilt og effektivt, under kærlig behandling, så er det fordi, det faktisk er dagens uorden i virkelig mange teams. Men selvom disse 6 anti-patterns er ualmindeligt almindelige, så er det jo ikke ensbetydende med, at man ikke skal gøre noget ved dem. Især fordi der faktisk findes løsninger på alle disse problemer, hvis ellers man vil parkere ”plejer” på sidelinjen og erkende, at der findes andre veje til agilitet end Scrum. Når alt kommer til alt, er det jo resultaterne, der tæller, og hvis man ikke kan få Scrum til at virke ordentligt - sandsynligvis fordi forudsætningerne ikke er til stede, så er det da smartere at prøve noget andet end at blive ved med at humpe videre. Dette andet, der kan reparere den kuldsejlede Scrum-skude, er Kanban. Metoden er skabt til at håndtere uforudsigelighed og foranderlighed, og kan bruges overalt, hvor man laver videnarbejde. Af enhver art.

Når nu jeg siger, at Kanban er befriende let at gå til, så er det ikke fordi jeg har fået en fiks ide. Det er fordi jeg er belastet af konkrete erfaringer fra transformationer med både Kanban, Scrum og SAFe og har mærket på min egen krop, hvor fuldstændig forskelligt det er at arbejde med de forskellige tilgange. Når jeg bidrager på Scrum eller SAFe transformationer, så er løbende, tæt coaching tvingende nødvendigt for at få tingene til at flytte sig. Men når jeg sætter gang i Kanban teams, så går der ikke lang tid før de er langt mere selvkørende. Sådan har det været hver eneste gang hos hver eneste kunde, jeg har samarbejdet med gennem åreneHer kan du høre, hvorfor det er sådan. Og lad mig bare afsløre, at det ikke er fordi de Kanban teams, jeg har coachet, var foran på point, da de startede. Det ligger simpelthen i selve Kanban-metoden.