Transkribering: Agilt - tips och erfarenheter från införande och nystart i agila team av Nathalie Heisner och Torbjörn Dahlström (avsnitt 39)

Detta är en maskinell transkribering (KB-Whisper) av avsnittet som publicerades 2023-06-04. Fel kan förekomma.

Lyssna på avsnittet: 39: Agilt - tips och erfarenheter från införande och nystart i agila team av Nathalie Heisner och Torbjörn Dahlström Läs sammanfattningen: Agila arbetssätt – Från komplexitet till värdeskapande (39)

Transkribering

Vi tänker att vi ska jobba baklänges, vi låser ner tid och kostnad och sen blir kraven rörliga. Det blir vad det blir. Den som pratar är Torbjörn Dahlström. Han och Natalie Heisner kommer idag ge tips och tricks gällande att arbeta agilt. Dagens avsnitt är idag sponsrat av Onbird. De kan hjälpa till inom kunskapsområdena Agile, DevOps, LineIT och ITSM.

De har också ett grymt kunskapscenter med gratis dokumentation att ladda ner. Jag rekommenderar verkligen att ni besöker onbird.se-kunskapscenter. Där kan ni ladda ner allting ni behöver. Stort tack till Onbird som sponsrar detta avsnitt. Det är nu dags att planera höstens avsnitt så mejla gärna gällande vad ni tycker har varit bra och vad som kan förbättras med Projektledarpodden. Det är nu över 3000 lyssnare per månad så jag hinner fortfarande svara på alla mejl som kommer.

Stort tack för att ni hör av er och att ni lyssnar. Jag som har podden heter Mattias Ejbe och nu kör vi. Du vill lyssna på Projektledarpodden. En podd för dig som gillar att leda projekt och vill lära dig mer av andra om projektledning. Idag har vi med oss Nathalie och Torbjörn från Onbird. De kommer att berätta om agilitet.

Det kommer bli kanonbra. Välkomna. Ja men tack så mycket. Tackar. Kan ni berätta kort om er bakgrund? Ja, Torbjörn Dahlström heter jag och jobbar i det här bolaget som heter Onbird.

Jag har jobbat som konsult i ganska många år. Jag jobbar mycket med verksamhetsutveckling för äldres ledning. Men har förflutet också som linjechef och it-chef inom it-organisationer. Natalie Heesner heter jag också från Onbird. Förflutet som att jobba inom produktutveckling och marknadsföring Jag blev nyfiken på projektledning och på agila metoder som vi använder väldigt mycket i produktutvecklingsteamet. Vi lärde mig mer om det helt enkelt, började jobba på Onbird och nu är det min vardag att konsulta inom projektledning och agila metoder i utbildningsformat och vanliga konsultuppdrag.

Vi ska prata om agila metoder idag. Kan inte ni berätta lite hur det här växt fram? Det är en ganska intressant fråga. Man kan titta på det kort och säga att det var några killar som för drygt 20 år sen samlades på något berg i Utah. Och så hade de get together och med tidigt så trillade det ut någon slags agilt manifest. Men jag tror att det är viktigt att man tittar lite på historikerna.

Man måste komma ihåg var man kom ifrån. Hur världen såg ut runt 2000 och var vi it kom ifrån. Men innan 80-talet jobbade vi med stordatorer och det var slutna system. Det var lätt att hantera, för de hanterade inte så mycket olika saker. De var egentligen maskiner som var specialiserade på att utföra enstaka uppgifter. Sen i slutet på 80-talet kom de här plattformarna som är programmeringsbara.

Framför allt är det operativ system från Microsoft som skapar helt nya mällor. Då ökar komplexiteten i de här olika systemlösningar otroligt mycket. Det blir väldigt svårt att veta hur man ska få ihop saker och ting när det inte längre är integrerat avgränsade systemet. För de som är lika gamla som jag så fanns det nåt som heter millennium-buggen som man skulle hantera som innebar en total explosion av hur mycket pengar som företag plöjde in i IT. Lite grädde på moset på det var det naturligtvis internet- framväxten Det är att man helt plötsligt hade en helt annan nivå av att börja sammankoppla system.

Jag kommer ihåg att när jag var ansvarig system så hade vi tre uppdrag med systemet. Vi skulle sköta matchning, faktur och lön. Men med tiden skulle vi sköta inte bara matchning, faktur och lön utan det var integration och B-lösningar. Det var säljsstöd, det var rapporter, det var analyser. Det var växt och växt och växt. Och allt eftersom det där hände så ökade trycket på it-organisationer att leverera.

Problemet var att man försökte köra med projekten ungefär som man har köpt tidigare. Det fungerade inte. Man brände ut folk till höger och vänster. Det här med att i förväg kunna detaljera ner krav för en mängd med stora och komplexa lösningar visade sig svårare och svårare. Då var det här gänget som samlades som så att vi behöver kunna hitta andra bättre sätt att jobba med det här. Vi måste hitta nya vägar att jobba med.

Då växte det här Agila-manifestet fram. Det intressanta är att det inte växte fram från intet, utan det fanns flera olika ramverkmodeller som hade börjat växa fram under 90-talet som var tänkt att hantera det här. Den allra första exemplet på tanken om att jobba iterativt som är grundpelande i Agila finns redan då. som kommenterats från 50-talet, japan ska utveckla och så. Vi behöver tänka annorlunda när vi jobbar med IT för det är andra typer av problem som vi har där gentemot när man annars jobbar med logistikfrågor eller när man ska bygga hus eller vad det kan vara.

Så någonstans 2001 så kom det här Agila-manifestet och det tog fäste ganska snabbt i framförallt där det kom ifrån det vill säga Silicon Valley och USA. och spred sig, tycker jag, upplevde jag i alla fall först till typiskt media och internetsidan. Där man byggde mycket nya snabba appar och man skulle ha mycket nya, appar kom ju senare då, men mycket nya hemsidor och sådant där som skulle vara väldigt drivet av en användarnära upplevelse och att man hade väldigt stor osäkerhet och jättemycket knutet till alla start-ups som kom som skulle försöka hitta nya modeller och affärsidéer som de skulle realisera. Då bör de ha ett annat sätt att jobba på som om man hade jobbat tidigare. Hur skulle du beskriva den övergripande filosofin bakom det här?

Det är några olika saker. Det första är att man på något sätt grundläggande accepterar att utveckla IT-system är förbundet med en annan typ av komplexitet än vad vi haft tidigare. Då behöver vi jobba på ett annat sätt. Det andra sättet är att jobba i korta iterationer och mindre plandrivet. Man försöker hitta vägen framåt när det finns den här komplexiteten att hantera. Man grundade också väldigt mycket på att det finns akilat team.

Man har teambaserat arbete och inte jobbar som man har gjort med specialister- inom sina avgränsade skrån och sammankoppla dem till en produktionsedja som ser ut i en fabrik. Istället vill man ha avgränsade team som tillsammans delade uppgifter och tillsammans helst skulle vara så frikopplade så att de skulle kunna skapa värden direkt till verksamheten från det här teamet. Och sen att ha fokus på att teamet skulle inte ha fokus på att producera det som beställdes utan de skulle ha fokus på att producera det resultat eller det värde som man beställde. Där finns det ju mycket diskussioner hela tiden om att lyckas vi få till beställningar som är rätt på rätt sätt eller beställer vi så att säga uppgifter som ska utföras men inte resultat som ska uppnås.

Och det är en av de här centrala pelarna att ha värdefokus hela tiden att hela tiden mäta och följa upp och liksom titta på har vi skapat värde eller har vi mest sysslat med aktiviteter. Det låter väldigt mycket som lean. Det kan även finnas mer traditionella planstyra metoder. Men vad är det som skiljer det här? Framför allt när du kommer att hantera komplexitet. Stark underliggande del av den agila metoden är inspirerat eller byggt på lean-principer om hur man skapar flöde i en organisation.

Det finns jättemycket i det nya agila manifestets olika principer och värderingar. merparten handlar om hur vi kan skapa bra flöde. Det är inte så konstigt, för om man tänker på det så egentligen alla organisationer eller team eller enheter finns ju till för att ta någon form av inflöde av godsvaror och tjänster och sedan förädla det och skicka ut det i andra änden så snabbt som möjligt till de som tar emot den. Och då den där förädlingsprocessen att den är liksom optimerad utifrån att den ger mesta möjliga pang för pengarna på kortast möjligast tid, ja men det blir det naturliga följden. Det kan man se att det finns mycket av utav lin i det där.

Tittar vi på komplexitet kan man fundera på vad som är komplext, hur svårt kan det vara? Det består egentligen utav två olika problemställningar. Den ena är att det är inte alltid säkert eller särskilt självklart är det uppenbart lätt för den som beställer någonting att veta vad man ska beställa. Det är inte heller så att det bara finns ett enda sätt att realisera lösningen. Så vi har ett vad och ett hur. Ju längre ut i skalan vi blir på osäkerhet, desto högre komplexitet har vi.

Den värsta nivån är när vi har ingen aning om vad vi behöver eller hur vi ska göra. Då kommer ingen plan i världen att lösa det. Då måste man hitta ett sätt att känna sig fram, att träva sig fram. Det är där, när vi befinner oss i den komplexitet-zonen, det är där det agila, den agila zonen har hemma och där att skapa värdet. Kan du ge några exempel på typiska projekt som passar till Agit arbetssätt och typiska som kanske passar bättre åt klassiskt traditionell projektledning? Ja, det finns ju lite olika skolor där.

Det blir lite beroende på hur religiös man är kring metodik. Typiskt är det ju… När man köper standardsystem så tenderar man att fastna i att man behöver tänka i mer traditionella steg. Därför att man menar på att det finns det kända praktiskt kring som vi kan tillämpa. Det är inte så hög komplicitet i det. Tyvärr visar det sig ofta att det finns en massa dold kompliciteter där som man inte räknar med.

För att sättet som det ena företaget har tillämpat ett standardsystem jämfört med nästa, det kan skilja sig väldigt mycket beroende på affärsmodeller eller kultur eller någonting annat kan finnas i det. Eller så fastnar man i fällar om att man försöker räkna på det och det gör man alldeles för länge. Att man försöker mappa ut den här komplexiteten som man blir oöverskådlig på grund av alla olika typer av vägval man kan göra hela tiden. Och man fastnar i så enorma förstudier. Eller hur? Ett av problemen är det där i natur, att man bygger antagande på antagande så får man en högre grad av osäkerhet och komplexitet på vägen.

Men sen är det klart också, när man driver IT-projekt som är relaterade till någonting som har en stor fysisk komponent i sig, det är att man ska bygga en fastighet, en logistiklager eller man ska göra annat. Där det ligger utanför IT-delens kontroll då krävs det oftast mer traditionell styrning och avstämning för att kunna hålla ihop det. För att man kan inte påverka de yttre faktorerna. Det är så många rörliga delar i det. Det kan vara alltifrån att när man ska bygga den där rälsen, så visar det sig att det finns någon grönöggsalamander som endast lever på den vägsträckan som gör att man måste dra om hela vägsträckan med 4,5 kilometer.

Det kan man inte veta i förväg och då måste man kunna sköta den strukturerade planeringen på det sättet. Sen finns det ju andra projekt där kompliciteten kanske är ganska låg, även om det bara är en it-komponent. Det kan handla om att det inte är så svårt. Vi implementerar ett nytt system som kanske är väldigt avgränsat och litet. Har inte en komplexitet i sig utan det kanske… Jag vågar inte säga tidrapporteringssystem eller tidplaneringssystem.

Det har varit mycket skrivande om det på det sista tiden. Men jag vet att när jag har satt som ansvar för det här och vi ska implementera vår tidrapporteringssystem och det inte fanns någonting annat utan vi skötte all tidrapportering på papper. var det ganska låg komplicitet och vi kunde liksom sköta det där. Det gick ganska fort och gick svint liksom. Och då funkar det de traditionella modellerna liksom alldeles utmärkt. Du pratade om den gröna salamanden här och det blir ju en typ av feedback eller iteration. Hur hanterar man det här i dina magila metoder?

Jo men det där är ju också en av de centrala aspekterna med att jobba med korta iterationer. Det är ju just för att få den där snabba feedbacken, för att få en känsla av är vi på väg i rätt riktning. Idén är att man i en iteration ska bli klar med någonting som Noro kan ge feedback på. Säga att det där verkar inte stämma efter mina behov eller att det är precis vad vi behöver. Eller att det är bra men kan ni lägga till den här grejen. Det kommer nya saker.

Och utan den där feedbacken när vi har komplexitet så är vi vilsen. Så vi behöver hela tiden känna oss fram. Det gör det möjligt att man anpassar projektet baserat på feedback som kommer tillbaka i de korta cyklerna. Det kommer förändrade krav och man får nya insikter hela tiden under arbetsgång. Man lär sig under tidens gång också. Man kan ofta tycka att man slösar väldigt mycket tid på att planera allt när man kan, som minst under då till exempel förstudier när det gäller såna här komplexa projekt.

Jag brukar jämföra det med att åka på Rells eller att segla över ett hav. Så åker du på Rells och vet att det finns inte så många olika alternativ och du kan inte dra. Du kan inte dra 90 grader vänster när du känner för du behöver liksom följa den spåren. Medan om du åker från sig källorna till till Madagaskar. Jag hoppas att det inte är alldeles för lång resa. Då behöver man ta ut riktningen och räkna med avdrift och se vad som händer.

Hur mycket vågor har gått, hur mycket strömmar har gått, hur ligger vinden? Så man stämmer av att man är på väg i rätt riktning. Speciellt om man har begränsat resurser på båtan. Då kan man inte frisegla tills man råkar komma fram. Då behöver man stämma av om man är på väg i rätt riktning. Det är samma typ av principer som vi tänker på i de agila projekten.

Hur ska man kunna övertyga en ledning som är van vid att vara på järnväg? Det kanske blir försenat, men det kommer alltid fram jämfört med att vara på öppet hav. Vi tror att vi kommer fram. Det där är jättesvårt. speciellt om det kanske finns en kommersiell komponent i det. Att du har ett annat företag som ska leverera till det. Det vi förespråkar i Agila metoder är att man ska skapa en acceptans för att det… finns komplexitet och därmed så är det mer lönsamt och mindre riskfyllt för oss att faktiskt träva oss fram snarare än att lägga långsiktiga planer.

Det andra är ju att det är superviktigt att det kommer löpande någonting för beställare att faktiskt utvärdera. Alltså det hela tiden kommer. Det är den här feedback lopet. Och då alla agila metoder för oss bråkar i någon form av eller demo eller tillfällen när man faktiskt visar de senaste grejerna som vi gjort. Att skapa så hög transparens som möjligt på att det taktar ut saker ur det här tidet hela tiden. Sen tror jag att man behöver prata om, för att överta en företagsledning så är det jättemycket som man måste prata om då.

Men ännu tar man ju och tittar på historiken. Hur framgångsrika har vi varit när vi försökt bedriva komplexa projekt? Hur har det gått för oss? Google man på det så får man upp en del siffror som ibland visar horibla resultat. Det finns exempel på nyheterna. Vi genomäljar dem med företag som organisationer som försöker implementera olika form av systemnösningar där det får precis motsatt effekt.

Men måttom och önskar sig. Så då får vi prata om det. Vilken risk ser vi det här? Är det mindre eller mer risk om vi jobbar kort och får snabb feedback och får möjlighet att utvärdera? eller är det bättre att jobba i de här planerna? Man får illusion lätt av kontroll varför man har lagt en plan. Men om världen är förändring, då är det svårt.

I militären pratar man mycket om att planering är allt, men är det världsöda kriget? Därför jobbar man mycket mer. Det är intressant, för även inom den militära jobbar man i teambaserat och uppdragsbaserat. Man är ställd för att säga att här i dina år du väljer att exekvera dem så vill man ha resultatet. Ser du kullen där borta? Det vore fiffigt om vi kunde ta det lösproblemet.

Så får man hitta vägen fram. Det finns också en till del som jag tänker är viktigt. Det är ju att man i Rageela så förutspråkar man inte att man kommittar för tid och evighet till ett projekt. Där förspråkar man att man kommitter till en avgränsad period. Man ska bara fortsätta att utveckla på den här produkten så länge man tycker att det ger ett tillräckligt värde. När man tycker att det inte längre kommer ut så ska man kunna stänga av.

Därmed kan man kommersiellt förändra sig fram. Man kanske inte ligger på ett treårsavtal, utan man ligger på nån slags rullande tre till sex månader. Så att man inte sitter inlåst i att nu måste vi göra det här. Där kommer vi nästa fall naturligtvis vilket är när sankkost faller sig. Har vi väl börjat investera i någonting så har vi oran svårt att ge upp den tanken att det här var ingen bra idé. Vi kommer inte få ut någonting.

Sen när vi har plöjt in 100 miljoner så måste vi plöja in 100 miljoner till för annars är de första 100 miljonerna förlorade. Och så går det på och så fortsätter det. riktigt kostsamt. Ser du någon skillnad där mellan det agila och det traditionella gällande sankosttanken? Jag tror att det är mer en mänsklig problemställning. Man vill inte ge upp det man har påbörjat. Då blir det där arbetet förjävs.

Sen finns det naturligtvis utifrån hur man jobbar med budditering och budgetplanering. Det skapar också inlåsningseffekter. Men om jag inte gör det nu Vad vi gör nu så kanske aldrig mer får pengar till det här. Eller jag kan inte gå till styrelsen och säga att vi har plöjt in 100 miljoner i någonting som inte är klart. Då måste jag gå vidare. Jag vet att det är många som känner igen problemet att man fastnar i ett måste göra klart saker och ting.

Men i slutändan är det inte så lönsamt. Det finns exempel som jag har hittat hos kunder ibland. Där vi plöjde ner, värsta tror jag var det var någon par säsonger som plöjt ner flera miljarder i en produkt. och vi fick mer än en enda kund till, sen laddar hela linjen helt av. Det är ett svårt beslut, det krävs mycket mod för att fatta ett sånt beslut. Men det företaget gjorde det och det har lönat så bra för dem efteråt. Men en ledning som ska starta nånting och så säger vi att vi ska driva agilt och så frågar man, vad blir slutprislappen på det här?

Här tänker vi lite annorlunda. Istället för att man, som den traditionella projekttiraggen, förskriver att man på något sätt först låser ner alla krav och sen estimerar hur lång tid och vilken kostnad det kommer vara för att ta fram det här. Så tänker vi i Eaglil att vi ska jobba baklänges, det vill säga att vi låser ner tid och kostnad och sen blir kraven egentligen rörliga. Det blir vad det blir. Det där kan ju låta förskräckande naturligtvis, men det som är bra med det är att det blir ju inga obehagliga budgetöverraskningar. Du vet precis hur mycket pengar du tilldelar.

Du vet också vilken tid… Det kommer att ta därför att varannan vecka eller vad fjärde vecka eller vad man nu har satt för iterationslängd så kommer det komma ut ett resultat som man kan värdera och se att man är på väg i rätt riktning eller inte. Och på det sättet så kan man ju hitta ett sätt att reducera risken. För att få med sig ledningen här så då kanske man inte ska ta det största monströsa projektet som man har framför sig som är absolut kritiskt för företagets överlevnad utan då ska man naturligtvis börja med något litet. Man ska hitta något avgränsat område, känna sig för, bygga kunskaper och erfarenheter och utifrån det sen se hur vi kan tillämpa mer av det här inom flera andra områdena.

Det har visat sig vara mer och mer framgångsrik. Man kan absolut gå vilsig i det här ändå. Det är inte så att det blir automatiskt bra bara för man har satt en agilstämpel på det. Men det har visat sig gång efter annan att det här har varit ett effektivt sätt att reducera komplexiteten och skapa en bättre framdrift. Det var inte alldeles alla som upptäckte att de saker som man trodde att man skulle göra från början visade sig inte alls vara särskilt bra. Det var bra att man inte gjorde dem för att man valde en annan väg att gå av med det integrativet.

Jag har jättemånga exempel från det jag satt ansvarig för. Vårt affärssystem i det bolaget jag jobbade i. Vi hade en massa bra idéer. Men när man realiserade dem var det ingen som använde dem. De fungerade inte alls utifrån hur verksamheten hade sitt upplägg. Jag jobbade i ett bemanningsbolag och vi tog fram en lösning för ett affärssystem för vår del.

En av de delarna som vi hade mest krut och kraft på var att ta fram en mycket avancerad kalendermatchningsfunktion som gjorde att vi kunde se vilken konsult som var tillgänglig vid vilket tillfälle och kunna tetrispussla in dem. Det var ingen som använde den funktionen över huvud taget. Vi mätte det efterhand och var i totalt slöserivet pengar. Det beror på att man inte jobbar på det sättet i verksamheten. Man vill inte jobba på det sättet. Man har ett annat sätt att jobba med kortsiktiga rapporter och mycket dialog med konsulterna.

Frågar de helt enkelt, är du tillgänglig på tisdag eller inte? Ja, det funkar det bättre. Det kanske utvecklas nu, det vet jag inte. Jag är inte aktiv i den branschen längre. Men då var det i alla fall totalt specifikt pengar. Natalia, kan du ge några exempel på hur man kan implementera det här i praktiken? på ett helt nytt företag, nytt som i att vi inte använder agila metoder utan vi kanske är mer fast i projektledning eller projektmetodiker eller kanske inte ens det över huvud taget.

Man säger att man jobbar i projekt men inte tillämpar någon projektmetodik. Det finns många som sitter fast i det också. Där kan det ju vara lite lättare då att komma in med approachen och låta oss prova någonting nytt. Det som vi gör just nu funkar inte. Det har ingen struktur. för då kommer ändå agiliteten med en bra struktur. Så vad är det första du gör på det första mötet?

Det första mötet handlar om att förstå varför de vill införa agila metoder. Vi måste ta reda på vad effekterna av det ska bli. Vad har man för vision? Vad har man för problem som man vill lösa med att applicera agila metoder? Det är första vägen vi måste ta. Att bara implementera ett nytt ramverk och tro att det ska lösa alla problem helt magiskt, då lurar man sig själv lite.

Där vill inte vi vara. Vi vill verkligen förstå vad vi ska lösa med de här metoderna. Hur går det till? Nästa steg. Det här ramverket. Hur får man folk med sig?

När det gäller teamen, om vi låter dig, Tobbe, prata lite mer om ledningen. och hur man jobbar med ledningsmässigt i det här gila. Det första vi gör är att titta på vilken nivå man är på. Ofta kommer vi till företag som har arbetat agit ett tag och som fortfarande kämpar lite mer. Man jobbar… Vi brukar kalla det som zombiescrum. Man följer de här olika cyklerna eller cykeln med de olika ceremonierna.

Man förstår inte varför man har de olika ceremonierna och vad syftet med det faktiskt är. Vi har en del utbildningar på olika nivåer för olika typer av roller i teamen. Det allra första vi gör är en agiv introduktion och back to basics. Varför har vi de här olika metoderna i ramverket? Och varför appliceras de? Så man verkligen får en baseline rakt genom företaget.

Man förstår varför man jobbar på det här sättet. Sen har vi skrammasutbildningar, vi har produktägarutbildningar och vi har också olika typer av ledarskapsutbildningar. Vi stöter också på mellanchefer som undrar vart de ska ta vägen nånstans i det här. På teamnivå handlar det om att komma in och förstå var de är och se till att man landar. Vi gillar att observera och titta på teamen. Först att vara med och förstå och inte bara komma in och säga här kommer ett nytt rånverk, kör in det. utan att hitta vägen inre.

Pratar vi om att organisationen vill göra en större transformation och att de kommer till oss och säger att de har bestämt sig för att hela avdelningen eller hela den här organisationsenheten eller kanske till och med hela företaget ska bli mer lättröriga. Då trillar man ju rakt in i någon form av förändringsledning som man behöver hantera. Då är det ju precis som Natalia säger, då börjar vi med att försöka förstå varför ni vill bli agila, vad är det ni vill uppnå med det där? Ett vanligt svar som tyvärr vi får är att vi måste vara moderna. Då får man börja om lite.

Det kommer inte att hjälpa oss att guida oss framåt. Jobbar man med förändringsledning, och det är mycket det som det handlar om här, då finns det flera olika ramverk, eller man kan använda stöd. Vi gillar att jobba med kottor, men det finns fler andra. De är alla på ganska likart. vilket är problemet, hur skapar vi en sensor, vad är det som är en känsla av att det här är viktigt för oss? Vad har vi för vision, precis som man säger, vad vill vi uppnå? Och sen behöver man sätta ihop någon form av förändringsledningsgrupp som kan ta det här framåt.

En viktig poäng är dock att man kanske inte lägger en detaljad plan över vad som ska ändra under de närmaste 6-19 månaderna. Även här jobbar vi hellre iterativt på samma sätt. Det finns många exempel på implementerade agila metoder. Det verkar skitenkelt. Om det finns nåt mer komplext än människor och organisationen… Det är sinnebilden av kompliciteten.

Många tycker att vi är rationella, men vi är ju människor. Vi är inte superrationella, utan vi är inte maskiner. Därför är det en bra idé att börja i nåt hör. Man hittar nånstans där man kan pröva ut, skapa kunskaper och erfarenheter, bygga förmågor och organisationer, välja ett team, hitta en produkt som avgränsar, jobba med den, skapa lite erfarenheter och kunskaper och sen bygga vidare. En annan viktig grej är att, som Natalie säger, vi pratar om nya sätt att tänka. På ytan kan det se väldigt enkelt ut, Men fundamentalt finns det ett antal underliggande principer som är helt annorlunda mot hur de flesta organisationer driver sin verksamhet.

Då behöver man ta till sig det bit för bit. Då är att faktiskt utbilda sig, förkovra sig, lära sig nya saker, en av de viktiga komponenterna. Där kan man ibland göra misstaget att korvstoppa. Men nu kör vi in här, alla får en veckas utbildning, vi trycker in det snabbt och sen kommer folk att komma därifrån och vara helt nya människor. Det är inte en bra lösning, utan då behöver man jobba med att vi serverar lite i taget. Vi startar med lite grundläggande och bygger på lite på vägen.

Det brukar vara vettigt att göra en omform av grovskissad utbildningsplan. Vilka är mottagande av den här kompetensen? Vilka behöver få den i organisationen? Vad är det de behöver lära sig? Hur taktar vi ledarskapet med teamen så vi inte får att teamen är super agila men ledarna står kvar och liksom följer traditionella styrstrukturer som inte funkar kring det här eller vice versa. Det måste gå jämnt.

Och centralt för att vara framgångsrik i en transformation är att lägga mycket krut på de här nyckelrollerna som finns i alla agila modeller som ju är någon form av coach, scrum master Kamban, Mastry hör man ibland, som ska hjälpa teamen med huret. Och också se till att de här produktägarna eller motsvarigheten till produktägarna beror på vilket ramverk de pratar om. Och så får en ordentlig skjuts till sin kompetens, så de känner sig komfortabla och säkra på sin uppgift. För gör de det så kommer de där två att tillsammans krokna arm och faktiskt kunna driva väldigt mycket i teamets utveckling och därmed organisationens agila förflyttning.

Man bör ha någon form av vision, en idé vart man vill, man kan inte bara skrämma upp folk och säga att allting funkar dåligt. För då får man ingen riktad energi utan då får man bara en massa puffar som springer i olika riktningar. Och det är vettigt att göra någon form av grovskissad roadmap liksom. Ungefär de här grejerna tror vi att vi behöver göra. Vi tror inte att vi vet exakt när det kommer hända men vi har en idé om ungefärliga vilka saker vi behöver. Hela tiden komma tillbaka till att utvärdera vad vi behöver förändra här.

Vad behöver vi utveckla och anpassa så att det passar de förutsättningar som vi faktiskt befinner oss i just nu. Förändringsledningen har ju de som sitter i en sådan konstellation och tittar på den här förändringen har en jätteviktig roll i att kolla takta vid mot de målen som vi satt upp. Då sätter vi oss där upp då tillsammans. Vi har en sammanspegel med ledning. Varför gör vi det här? Vi tittar på varför vi vill applicera de här agila metoderna.

Vi har ett antal styrmedel som man hela tiden kan titta och följa. Är vi på väg åt rätt håll med den agila transformationen? Superviktigt. Det är en klassisk fälla i förändringsledningen. Men så är det stället göra förändringen som blir målet. Och så har många gillar transformationer, tyvärr Buklandet, för att de har klart bort det där.

Och så blir det, men vi har ju sagt att vi ska göra det här och fattar inte allihopa varför vi gör det här. Nej men alltså det här måste man ju repetera tusen gånger liksom. Och när man själv tycker att man har tjatat hål i huvudet på budskapet och varför. Ja, de har bara precis börjat skrapa på ytan liksom. Det är lite som… Det är ett nötre.

Man sitter med nån powerpoint-mall som man kör internt. Och så jobbar man med den hela dagarna. Och så blir man skittrött på den. Man orkar inte se den längre. Men kunderna ser inte den hela tiden. För de blir det naturligtvis en ny upplevelse.

Och samma sak gäller för prioritetionen när vi håller på med den här förändringen. Det är nästan… Jag personligen tycker att det är extra viktigt att hela tiden påminna om varför. Varför vi gör olika saker. Varför har vi retro? Och hamra in det också.

Hela tiden jobba med teamen. Så att det landar i teamen. Man har så många olika beteenden som kommer från att man har jobbat på ett visst sätt. Tobbe, du brukar prata mycket om att man trygglar in i sina mentala modeller. Visst är det så du kallar det för? Kan du beskriva vad du brukar säga?

Det finns ett antal underliggande mentala modeller. I Agila pratar man mycket om den här command and control-modellen. Att ledarskap historiskt har utgått ifrån. Att ledare kan lite mer, vet lite bättre. De ger order till medarbetarna att utföra det. Det ser vi mycket mindre ut av nu.

Det finns mycket även utanför Agila där man pratar om självledarskap och att lita på teamen och kollektiv intelligens. Men att ha idén att det är mitt uppdrag att se till att saker och ting blir gjort genom att ge dem order blir fel. Sen har jag en annan sak som är vanligt att förekomma när man pratar om Contract-to-control-modellen. Den förskriver att mellan verksamheten och IT finns det någon slags kontraktuellt förhållande. där verksamheten ställer kraven och sen ska IT leverera det som en slags färdigt paket från tomteverkstaden sex månader senare.

Det är en jättekonstig idé. Vi har inte IT för att det är roligt. Vi har ju IT för att vi ska realisera verksamhetsresultat. Antingen genom att tillföra nya möjliga funktioner eller möjligheter eller genom att säkerställa att verksamhetsproduktion och verksamhetsuppgiften faktiskt fortgår hela tiden. Att hålla IT på någon slags armlängdsavstånd och bara involvera dem när man behöver, det blir jättekonstigt. Men tittar man på hur folk agerar så är de ofta fast i idén om att IT är leverantörer och verksamheten är kund och där emellan finns den typen av relation.

Ännu värre blir det när man börjar tänka att IT är inte riktigt som vi. De har lite andra ambitioner, målsättningar och värderingar. De jobbar ju i samma organisation. De måste ha samma värderingar och ambitioner och målsättningar som verksamheten är stort. Man kan ju inte titta på på någon anfall. Det värsta exempelet är när man börjar mäta, IT mätts bara på dess kostnad.

Och när man kanske till och med sätter upp någon sån här, IT får inte kosta mer än 25% av företagets omsättning. Det kan vara, nej kanske inte 25%, men ni förstår vad jag menar. Och så värderar man inte alls IT utifrån att de affärsresultat man vill uppnå faktiskt uppnås. Utan det blir bara kostnadsbilden som är dyrande. Det ligger på inget sätt bara på verksamhetssidan. Det är lika många på IT-sidan som har samma bild av relationen.

Den är intressant, den relationen. Hur hanterar man om IT jobbar agilt och verksamheten inte gör det? Det är lilla gränssnittet däremellan. Ja, den är lite lurig. Oftast när jag är ute så ser jag att man faller i fällan och att verksamheten vill skriva och be om alla kraven och få allt färdig produkt. en stor smäll på en gång helst. Det kan vara svårt att övertala kravställena ute i verksamheten.

Att få dem att förstå. Jag kommer att komma och be dig om vad är viktigast just nu? Om vi ska ha en leverans om en månad? Vad är det ni behöver nu? Jag lovar, kära beställare, kravställare, verksamheten- i nästa planering kommer du att få nåt att säga om igen. Du kommer att få lägga till fler saker i vår kravmängd.

Den är jättelurig, faktiskt, och tar en stund för dem att förstå. Men det gäller att stå på sig och vara envis där. Som projektledare hamnar man i den agila världen och tar ofta rollen som en Scrum Master slash-produktägare. Har man någon form av projekt, agil hybrid, så är det bara att sätta på sig den här produktägare-hatten och gå ut och samla kraven. Och då få verksamheterna att förstå att vi tar en kaka i taget. Agenda modeller föreskriver rollen produktägare.

Ibland får vi frågan så här… Var hör en produktägare hemma? Är det en IT-roll eller en verksamhetsroll? Svaret är ja. Den är inte det ena eller det andra. Det här är bryggan mellan verksamhet och IT.

Det här är den som ska hålla ihop det och ta bort och riva de gamla modellerna utav att IT är någon slags leverantör till kunden. För man ska ha samma mål och samma målsättningar och man ska mäta på samma resultat om det ska bli i någon slags idealtillstånd. Men det finns andra aspekter att tänka på. Om man har en IT-organisation som jobbar i iterationer om två veckor och det taktar ut små saker hela tiden. Och de verksamheter som jobbar med verksamhetsplanarbetet som är på årsbasis eller kanske längre då får du en otakt. De pratar mycket i Agina Mentura om kadens, alltså rytmen, för hur man gör saker och ting.

Då får du helt plötsligt en svår situation när verksamheten förväntar sig av detaljerade årsplaner från IT. Men IT jobbar i två veckor cykler. Eller annat motsvarande. Men vi kan inte fatta beslut i frågan för nästa verksamhetsmöte som kommer att ske den 23 oktober. Vi behöver få ett svar nu för att komma vidare. Annars kommer inte vi kunna bli klara.

Det handlar om att tajta till det. Jag sitter i ett projekt just nu där Norge stationer får testa ut att jobba mycket mer lättrörligt och lägilt i en avgränsad mängd. Vi gjorde en liten retro, en reflektionsrunda med styrgruppen. Vi har kört några. Vad upplever ni som styrgrupp nu när vi jobbar på det här sättet? Det finns ingen kravlista, ingen detaljerad tidplan.

Det finns en mycket gröver ramare som vi utgår ifrån. Men det finns också feedback varannan vecka. Då reflekterar styrgruppen över att det här känns bra. Vi är jättenöjda, det känns skönt, det kommer mycket ur det här. Men oj vad mycket mer tid vi måste lägga. Och då frågade jag så här, men är det mycket mer tid i total tid?

Nej, men det är oftare. Så det är kortare möten, men de sker oftare. Det betyder att du får en ökad tempo på det sättet. Och det var en otroligt viktig insikt för dem. Det räcker inte att vi som styrgrupp, det är inte en timme i månaden för styrgruppsmöte och fattar alla beslut, utan vi behöver faktiskt vara mer närvarande i det här för att hela tiden veta att vi får den feedback och den möjligheten som vi behöver att säga ja eller nej, eller höger eller vänster eller vad kan vara. Så det är också en viktig aspekt.

Man måste jobba med de här rytmerna på verksamhetssidan och på itensidan. Och ledningsgruppen gillar ju ofta att mäta saker. Och hur mäter man då framgång i det agila och hur mäter man att vi verkligen gör maximalt? Ja, men då trillar vi tillbaka lite till det här som vi pratade om tidigare. Historiskt har man oftast bara mätt på kostnad och inte så mycket på vädraresultat. Det där är lite intressant.

När det kommer ett krav eller behov från verksamhetssidan och så ser jag inte ut. Vi behöver det här. Då kan man ibland få en intressant diskussion när IT-sidan svarar vad det är värt för er. Om ni får den nya funktionen som innebär att ni kan uppdatera priserna på er webbshop Liksom såhär mycket snabbare och lättare i samband med kampanjer. Vad är det värt för er? Ibland får man faktiskt riktigt bra svar.

Ibland så är det såhär, men vi har gjort en prognos att vi kommer kunna öka kundkorgen, storleken såhär mycket. Eller att vi kommer kunna Sälja såhär mycket mer utav de här produkterna. Eller att vi kommer kunna korta ledtiden på hanteringen utav den här typen. Och ibland så får man mer såhär, ja det är ju svårt att säga för det beror på tusen olika faktorer. Och när man får det svaret, då vet vi att då finns, då är vi i komplexitetzonen. Då behöver man hitta ett sätt att takta mot det.

Ideellt ska verksamheten kunna beskriva vilka verksamhetsmål de har och använda dem som mätpunkt för det. Men sen tycker jag att det finns en poäng att titta på. Vi jobbar gärna utifrån nåt som kanske är flow framework som vi tycker ger en bra ram till det här. Vi tror att det finns mätning på tre nivåer. Det finns dels de här verksamhetsresultatsnivåerna som vi pratade om. Där kan vi mäta på genuina direkt affärsnyckeltal, vi kan mäta på kundnöjdheten, det är Netpromotorskors och sådana saker.

Och vi kan naturligtvis mäta på kvaliteten i den här produkten. Hur ofta står den stel för att när den är i ett produktstel, då står också verksamhetsproduktionens del. Så det där kan man ju mäta på. Historiskt har det ofta funnits mycket bra mätningar kring just incidenthantering och nedtid. Det brukar vara vanligt. Men sen tror vi att man måste mäta på vad fördelar teamet sin tid på?

Hur mycket av sin tid lägger man på att skapa nya grejer? Hur mycket av sin tid lägger man på att rätta fel? Hur mycket av sin tid lägger man på teknisk skuld? Och det kan försälla sig två olika poddar för att lösa ut det. Men det handlar egentligen om gamla it-lösningar. Eller det som var bra it-lösningar kanske inte längre är bra it-lösningar. som skapar hinder för vår flexibilitet.

Jag såg nån… Amazon CTO, tror jag, varje år sen läste jag. Jag skrev så här. När jag ser att teamen lägger mindre än 20 % av sin tid på ett tekniskt skuld så sover vi inte på nätterna. Jag vet inte om det stämmer, men… Och jag vet inte om 20 % är relevant för Amazon eller nån annan organisation, men det handlar om att förstå att vi måste lägga tid på det för att inte bygga in oss i tröghet framåt.

Att välja bort teknisk skuld är att välja bort affärsmässig flexibilitet och ingenting annat. Nån gång i tiden, längre framåt, kommer vi att komma till ett läge där nån säger att de vill ha en blå knapp. Då kommer IT-sidan att säga att de förstår poängen med den blå knappen. Problemet är att om vi lägger till den blå knappen kommer hela världen att dö. Vi måste bygga om hela vårt AD-register, hela vår back-endlösning, de här femton integrationer och så vidare så att det faktiskt går att realisera. Så själva behovet kanske egentligen inte kostar mer än sig tre veckors jobb men följdeffekten av att vi inte hanterar teknisk skuld innebär att det där kommer att behöva 9-23 månader på oss för att leverera.

Så se till att ha koll på hur mycket teamen lägger på teknisk skuld och se till att vi har koll på hur mycket teamen lägger på att hantera riskfaktorer alltså säkerhet, kapacitet, tillgänglighet, de här ganska traditionella drivetsorienterade problemen. Ja, första stegen är att mappa ut vilka olika typer av arbete har vi i vårt team. Eller hur? Och gör det synligt på något sätt. Och sen sista delen är att titta på hur ser teamens flöde ut. Hur mycket tid trillar ut ur teamen och där har man ju lite olika begrepp som man jobbar med som är vanligt förekommande.

Och på ett eller annat sätt, Velocity som på något sätt motsvarar ungefär vilken produktionskapacitet eller hastighet har teamet. Man tittar på hur mycket work in progress eller hur mycket samtidigt pågående arbete man har. För vi vet ju att om man försöker jobba med tio saker samtidigt då är man varken effektiv eller gör någonting utan kvalitet utan då hoppar man ju fram och tillbaka med andra grejer och tappar trådar och så där. Och så är det naturligtvis lentiden också. Hur lång tid tar det för oss att gå från, liksom, bo till något slags? Färdigt alls.

Det kan också vara svårt för det är inte alla som har förmåga att mäta det. Men då mäter man ju på de letider man försöker att man kan. Så man liksom bit för bit förbättrar det. Det finns också ett väldigt intressant mått som väldigt få mäter. Och som är ganska komplext att mäta. Men här ligger mycket tralin som det pratade om.

Och det är ett mått som man kan, som kallas för process cycle efficiency i linsammanhang. Det är egentligen skillnaden mellan nedlagd arbetstid kontra förfluten kalendertid. Det togs bara fyra timmar att göra själv och skriva koden, checka in den och produktionssätta den. Men det tog oss två månader och får det klart därför att den fastnade och vi började lämna oss över och vänta på beslut. Då kan man ju se att när man gör den här mätningen brukar man ju trilla ut i ganska tråkiga siffror. Det brukar visa sig att man ligger på mindre än 5 procent effektivitet.

För att det är någon slags liten idealtillstånd. Ja, då ska ju helst liksom nedlagda arbetstid och kalendertid vara i princip tillsammans. Det gäller ju inte när man jobbar. Om man inte jobbar tre skift och så vidare. Men liksom för den arbetstiden som finns så borde de där vara så lika vän. Har ni begått några misstag som ni vill dela med er av som andra kan lära sig av?

Jag har själv varit i den här fällan att ramverket är målet och inte medlet. Framförallt under mina första år som konsult så blev det så om och om igen. Det står så här i ramverket, ni måste göra så här annars gör ni fel. Och inte anpassa utifrån förutsättningarna. Jag skämtar ibland om att skillnaden mellan en ramverksfascist och en terrorist är att med terroristen kan vi förhandla. Det finns för många som är förtrogen mot ramverket.

Jag tänker att teamet är så oerhört viktigt oavsett om det är ett projektteam eller ett agit team. Ett av mina misstag i början var att inte förha den insikten, att inte förstå hur viktigt det är att man faktiskt jobbade ihop. Att man hade gemensamma värderingar. Man jobbade och hade gemensamma beteenden- som styrdes av våra värderingar som vi hade satt upp. Det blir extra viktigt om man jobbar deltid och inte har ett fast team. Man kanske har plockat ihop ett team från olika avdelningar.

Det är så viktigt att lägga tiden på att utveckla teamdynamiken på ett bra sätt. och att alla förstår varför vi jobbar som vi gör just nu. Oavsett om vi jobbar i en projektmetodik eller i en agil metodik. Absolut. Byggarna grundlägger det till lite med teamet så att de kan faktiskt fungera effektivt tillsammans. Och att de förstår också varför vi jobbar på det här sättet. Jag tror det finns en fäll också att man kan tycka att det är så roligt och lätt att jobba med teamen, så man glömmer bort ledarna.

Det är de som jobbar med det värdeskapande arbetet, det som kommer ut i verksamheten att användas. Ledarna ska skapa förutsättningar för teamen, inte att göra jobbet. Då är det lätt att glömma bort dem och inte fokusera på dem. Det har vi också blivit mycket bättre på. I våra transformationer som vi har jobb till att driva och kompetenspaket och så vidare så tar vi fram att se till att vi taktar både mot ledarna och mot verksamheten och mot teamet. De tre måste bli ihop för att det ska bli bra.

Om man vill veta mer om det här och få lite mer hjälp, var kan man göra det någonstans? På vår hemsida har vi ett helt gäng av teamövningar som man kan browsera lite på och få dels inspiration eller kontakta oss för att lära sig mer om dem. Då kan man gå in på onbird.se slash team-ovningar. Så teamövningar med o i ett ord. Jag lägger den i anteckningen till avsnittet också. Jag ska nämna att utöver de rena direkt teamövningar.

Vi har lagt ut jättemycket material om man vill lära sig mer om det här. Man vill läsa själv, ta till sig. Det finns olika form av bloggar, inlägg. Downloadables som vi erbjuder som hjälper till. Med såna här saker som hur ska man tänka kring agitledarskap eller vad betyder det att jobba som produktägare? Vad är fem smarta tips för att få igång ett bra team eller vad det kan vara?

Sju smarta tips är det tydligen. Otroligt bra. Idag har vi fått höra massor med tips och tricks gällande agila arbetssätt från Natalie och Torbjörn. Stort tack för att ni tog er tid att vara med i Projektledarpodden. Tack för att vi fick komma. Tack för att du har lyssnat på Projektledarpodden.

Hör gärna av dig till oss med idéer, tips och förbättringsförslag. Det gör du enklast via mail på www.lyssnare.se eller vid det sociala nätverk du föredrar.