Det kan være svært at få tid i en travl hverdag til at træde et skridt tilbage og tage et kig på hvordan man gør tingene og se om man kan forbedre sig.
Måske kender du denne her:
Manden til venstre har tydeligvis været til en konference/et brugergruppemøde eller læst et blogindlæg og der har han fået et hint om at der måske var en forbedring at hente med runde hjul i stedet for firkantede, men resten af teamet er ikke interessede i at prøve noget nyt. Teamet er overbevist om at “Vi har for travlt til at ændre noget”, “Vi har altid gjort det på denne måde”, “Den slags virker ikke for os”.
Hvad gør man så, hvis man er manden til venstre (m/k) og gerne vil have teamet til at prøve noget nyt?
Mit svar er at man lytter til Linda Rising. Linda har skrevet en bog Fearless Change – Patterns for introducing new ideas, hvor hun beskriver hvordan man kan påvirke sine omgivelser til at acceptere at prøve nye ideer. Det er patterns som “Guru on your side”, “Involve Everyone”, “Dedicated Champion”, “Test the Waters” og min favorit “Do Food“. Simple opskrifter på hvordan man får overbevist sine kolleger og sin organisation om at indføre en ny ide.
Nu tænker du måske at du jo allerede har “de gode argumenter” på din side som kan overbevise ethvert rationelt individ om at du har ret i at netop din gode ide skal indføres. Desværre er mennesker ikke rationelle. Vi gør masser af ting som ikke kan forklares med rationelle argumenter – vi er gode til at rationalisere de ting vi gør, så vi kan overbevise os selv om at vi har handlet rationelt, men forskning viser at vi er langt mere følelsesmæssigt påvirket end vi vil være ved. Hvis du ikke tror på det kan jeg anbefale at følge Dan Arielys kursus på Coursera “A Beginner’s Guide to Irrational Behavior” – det er gratis.
Hvis du løber panden mod en mur, når du forsøger at indføre nyt på din arbejdsplads kan jeg anbefale at bruge Lindas bog og lytte til Linda. Du kan finde en opsummering af hendes patterns i denne pdf, men køb bogen alligevel.
Hvis du nogensinde får muligheden for at se Linda tale til et brugergruppemøde eller en konference, så grib chancen – det er ikke det samme med en video, men jeg har alligevel fundet en frem, som viser lidt af Lindas særlige evner.
Hvis nu ikke Fearless Change-bogen er nok findes der også udvidelser f.eks. artiklen “Extending Patterns for Fearless Change” af Daniel Cukier og Fabio Kon som f.eks. indeholder patternet “Let Them Play”, hvilket man kan se i praksis i f.eks. trenden omkring agile games.
Håber det har inspireret dig til hvordan du kan komme igennem med nye tiltag. Måske har du allerede et godt trick, du gerne vil dele med os andre?
Hvis nu manden til venstre foreslog dem at bruge trekantede hjul, kunne man skrive et helt blogindlæg om hvor meget spildtid det kan koste at afprøve en åbenlyst tåbelig idé. Det er ikke altid givet på forhånd om en idé er god eller dårlig, som din tegning forsøger at illustrere. Og tegningen er i sig selv et letkøbt argument for at tage jahatten på og afprøve nye idéer.
Det er et rigtigt godt input, og derfor handler det om at prøve ideen og se om det virker.
Nogle ideer vil være gode og nogle ideer vil være dårlige, men før vi prøver dem, så ved vi det ikke altid.
En vigtig ting ved at køre agilt er, at man hele tiden eksperimenterer, stopper op, evaluerer og lærer af det.
Var det en god ide, så fortsætter man; var det en dårlig ide, så går man tilbage til der, hvor man var før – eller planlægger et nyt eksperiment på baggrund af sine erfaringer.
Med hjulet er det åbenlyst, men det er de færreste af de ting, som vi arbejder med i IT-verdenen, der er så åbenlyse; de fleste ting er komplicerede eller komplekse. Og det er derfor vi eksperimenterer.
Helt enig Gitte.
Man kan f.eks. ikke kalde sig agil, hvis man ikke har fokus på kontinuert forbedring og det kræver at man eksperimenterer med nye tiltag. Til tider vil nye ideer være en forbering og til tider vil det ikke, men vi kommer ikke videre med “sådan har vi altid gjort”. Mange individer har det svært med forandring, så derfor er det vigtigt at det ikke bliver dikteret ovenfra, men er noget man samarbejder om – som Lindas bog også lægger op til.
Hvad gør man så med de personer som kommer med notorisk dårlige forslag? For at blive i stenaldermetaforen, så er det dem som foreslår at prøve de trekantede hjul fordi de har en sjov farve, eller dem som synes det kunne være sjovt at hælde vand på bålet i stedet for at puste til ilden – bare for at prøve noget nyt.
Det er typisk de mest uproduktive medarbejdere som excellerer i denne disciplin – for at aflede opmærksomheden fra egen utilstrækkelighed – og har man været i IT branchen i nogle år, har man med sikkerhed stødt på disse kegler. Det er typisk personer som bruger halvdelen af arbejdsdagen med at læse tech blogs så de er up to date med nyeste buzz words. Resten af arbejdsdagen bruges gerne med at delagtiggøre de produktive medarbejdere med de nye teknologiers velsignelse.
Den agile metode giver jo carte blanche til at disse medarbejdere kan ytre sine tåbeligheder. Hvordan siger man på en pæn måde at de skal flette næbet? Hvordan forklarer man dem at det ikke er en god idé at omskrive hele kodebasen til andet sprog fordi det har en smart konstruktion? Hvem har nej hatten på?
Hejsa
Det ved jeg faktisk ikke; jeg har aldrig nogensinde oplevet det problem, hverken her eller i udlandet.
Tværtimod oplever jeg, at når folk arbejder i teams, så tager de mere ansvar og arbejder mere. Hvis de ikke producerer noget, vil det blive meget synligt og så er problemet ude i det åbne.
Det handler ikke om, at agile løser alting, men at det gør det synligt, så problemerne kan løses.
Desuden er det hele teamet, der skal være enige om at eksperimentere og ikke bare en.
Så ingen behøver at have nej-hatten på..
Men som sagt har jeg ikke set problemet i praksis.
Jeg bryder mig ikke om udtrykket nej-hatten i denne sammenhæng, fordi det antyder at man siger nej for at sige nej. I de fleste tilfælde er det ikke en god ide at omskrive hele kodebasen til en andet sprog, men der er tilfælde hvor det bør overvejes.
Hvis der er et problem med en medarbejder som forstyrrer de andre medarbejdere, så er det op til teamet at få det problem synliggjort og håndteret – typisk starter det til et retrospective. Det er en del af det at være et selvkørende team og vi er alle voksne mennesker. Jeg siger ikke det er let, men synlighed er vejen frem – hvem ved, hvis det forstyrrende element får at vide at det er forstyrrende, kan det være at problemet retter sig selv. Det er bare vigtigt at gøre det åbent og uden bagtanker – sladder og bag ryggen er ikke godt for noget team. Ofte er problemer ikke så store, som man troede, når man får dem trukket frem i lyset. De fleste mennesker ønsker at bidrage efter bedste evne – jeg har aldrig mødt en der havde en saboterende opførsel med vilje.