Transkribering: Agilt och traditionell projektledning - Tomas Gustavsson ger vetenskapens svar på hur detta fungerar! (avsnitt 6)

Detta är en maskinell transkribering (KB-Whisper) av avsnittet som publicerades 2020-09-11. Fel kan förekomma.

Lyssna på avsnittet: 6: Agilt och traditionell projektledning - Tomas Gustavsson ger vetenskapens svar på hur detta fungerar! Läs sammanfattningen: Agil projektledning – Forskningsbaserade insikter för praktisk tillämpning (6)

Transkribering

Visualisering är ju väldigt ofta ett svar på lösningen att det blir en tydlighet i allt man gör, att man på tavlor och annat, visar upp hur saker och ting hänger ihop för att inte behöva ha allt i möten. Den som du har pratat med där är Thomas Gustavsson En av Sveriges främsta forskare på kombinationen mellan agila metoder och traditionell projektledning. Jag som pratar heter Mattias Ejbe och det här är Projektledarpodden. Nu kör vi! Välkomna till denna på Projektledarpodden. En podd för dig som gillar att leda projekt och vill lära dig mer av andra om projektledning.

Författare, föreläsare, konsult och så undervisare och forskare på Karlstads universitet. Jag anser att Tomas, med hans ena fot i praktisk verklighet och den andra i vetenskaplig verifiering av vad som är den sanna verkligheten, är Sveriges främsta inom området agilt inom projektledning. Jag är mycket glad att Tomas tar sig tiden att vara med här i Projektledarpodden. Välkommen! Tack så mycket! Så vi sätter väl igång med en gång?

Det tycker jag. Vad är projekt för dig? Alltså, att gå från idé till färdigt, verkligt resultat. Det tycker jag räcker ganska långt till att definiera projekt som. Kollar man från akademin så vill man nog säkert lägga in orden att det är en temporär organisation också. Att det är människor som träffas under temporära former.

Och det håller jag med om. Det kan ju variera. faktiskt hur mycket temporärt det där är. Och det har ju blivit väldigt aktuellt när man pratar om agilt då. Och vad är agilt för dig då? Ja, alltså… För mig är det agilt att vara realistisk.

Det vill säga att man dels är realistisk vad gäller människors beteende. Vi vill ju ha inflytande i vårt jobb. Så vi vill ju att människor får säga till om saker och ting. Vi vill ju inte vara slavar under någon sorts fördefinierad process. Utan vi vill kunna påverka. Men även realistiskt, kring vad man kan ha för förväntningar.

Jag tycker att mycket av projektledningen tidigare har fokuserat väldigt mycket på långsiktiga planeringar och löften som har varit långt in i framtiden där vi vet att det där är bara gissningar. Och så ställs stackars projektledare mot väggen när de säger: har vi gått från Gestimeds till Estimeds nu? Och såna saker. Men vi vet ju att det är svårt att förutsäga saker och ting. Och det är ju mycket vad agilt är. Att vara realistisk.

Om inte annat så märker vi det under den här coronapandemin nu att Rätt många stackars projektledare som inte har kunnat hålla vad de lovar det här året. När du nämner agila så finns det ju även något annat ord, och det är projektledare som kanske inte finns agila. Nej Alltså jag tänker så här kring projektledare, jag tänker på två sätt. Det ena är att en projektledare i många verksamheter är en utpekad roll. där man har en viss sorts befogenheter och ansvar och det är det ju på många ställen idag. Samtidigt så tänker jag att Att vara projektledare, det är ju någonting som många är.

Jag tycker inte man ska förminska det till att bara peka till projektledare som en enda individ som har fått den hatten. De individer som tar initiativ för att driva idéer framåt så att det blir ett verkligt resultat det är ju projektledarna. Jag tänker på ett sånt exempel när jag själv var som IT-konsult på ett danskt företag, eller jag kom från ett svenskt konsultföretag och var hos en dansk kund. Och då hade jag tagit hit en teknisk projektledare, och så hade vi en projektledare. Ja, jag var där på plats, och projektledaren kom dit en gång i månaden ungefär och var med på styrgruppsmöten, och passade på under dagen att stämma av status och sånt och sen hade möte.

Jag skulle inte vilja påstå att det där var en projektledare faktiskt. Det var någon som hade den hatten men inte gjorde det det är att vara projektledare. Det var ju vi. satt där och var på plats? Vi var ju projektledarna. Så ser jag på projektledar termen. Och ser du att den termen har en plats i det agila?

Ja, det tycker jag. Kanske inte lika mycket som utpekad roll internt. Många har ju anammat de här rollnamnen som kommer från Scrum, oavsett hur de jobbar agilt så har de pekat ut Scrum mastrar och produktägare och så vidare. Men från kundsidan till exempel är det ganska naturligt att Att man vill ha en person att prata med. Och att man då säger att det här är projektledaren vi möter. Det skulle ju på insidan lika väl kunna vara någon som har hatten produktägare eller hatten Scrummaster.

Men att kunden vill veta vem som är projektledaren det tror jag inte vi kommer ifrån. Jag tror inte att det namnet är på väg att försvinna alls. Intresset för projektledning i sig ökar ju hela tiden. Här på Karlstads universitet, där vi har magisterprogrammet i projektledning. Vi har ju ökande mängd folk som söker det hela tiden. Så där ser vi ju inte att termen eller arbetssättet att våra projektledare är på väg bort.

Tvärtom. Du har ju skrivit boken ”… Agil projektledning”. Ja, precis. Där kombinerar du de orden. Gör ni det även när ni har kurserna?

Absolut. Och det är ju för att göra en poäng av att det agila är ett arbetssätt. Det är någonting som kan placeras in på olika… Det kan placeras in i projekt, som är det jag beskriver i min bok. Och det kan placeras in i typisk processorienterad verksamhet också. Så det är vettigt att kombinera, tycker jag.

Och när ett företag säger att de jobbar agilt kan man då veta hur de arbetar? Nej, det kan man ju inte. Alltså, till att börja med, det agila i sig är ju väldigt öppet. Det är ju öppet i sitt grundutseende med bara ett antal värderingar och principer som kommer från Agila-manifestet. Men sen även om man har valt att ha en specifik metod eller ramverk, som SCRUM till exempel så kan vi ändå inte veta exakt hur de jobbar. Jag tycker inte att det är så konstigt.

Jag tycker ibland att det lyfts upp lite väl kraftigt. För jag tycker att det är precis samma sak med projektorienterade verksamheter överlag. Om ett företag säger att de jobbar enligt PPS-modellen så kan det betyda allt ifrån att de faktiskt följer den rätt så noga. till att de har gått kursen någon gång på 90-talet där det följer med en diskett med mallarna för projektplan och slutrapport. Och det är de mallarna som är kvar i verksamheten. Och i övrigt så gör man ingenting enligt de exakta rollerna eller faser eller så. Så jag tycker inte att det är så konstigt egentligen att det går inte att helt och hållet veta vad det innebär när ett företag jobbar agilt eller projektorienterat eller följer en viss projektmodell.

Jag håller helt med, framför allt om det här som Som du säger, om att ett företag säger att de har en projektmodell. Men det är så otroligt stor skillnad på hur den är implementerad och hur aktivt de arbetar med den. Boken Agil projektledning skrev du för många år sedan. Vad har ändrats? Ja, två saker kan man säga. När jag skrev den, 2011 kom första ut.

Jag skrev den mest under 2009-2010. Då var det väldigt mycket fokus bara på att jobba agilt i det lilla tidet. i det lilla projektet. Till och med såna som Kent Bäck, som var en utav de där som skrev manifestet. Han sa ju själv att han trodde inte att man kan jobba agilt om man är mer än hundra utvecklare. Så synsättet var ju förr väldigt mycket på det lilla, det småskaliga. Och det har ju ändrats enormt.

I dag är det ju många storföretag som jobbar agilt och ser inte att det skulle vara nåt motsatsförhållande att man, både för att man är effektiv i det lilla och tänker på ett visst sätt, att man inte skulle ha det i det stora också Så det är väl en stor skillnad i boken, att jag har lyft in mer och mer av uppskalning och hur man ska tänka i större verksamheter. Sen det andra som jag har ändrat, det är att… Vad ska man säga? När jag skrev den från början så var jag ganska trött på att det var så mycket engelska termer i allting. Så jag tänkte att jag ville hellre ha en genomgående svensk terminologi.

Men där har jag fått backa. Så nu är jag tillbaka på ganska mycket engelska termer. Man märker ju vad det är som har satt sig. Sprintar och Scrum master, det har blivit självklara ord, även i helsvenska verksamheter. Så det har jag gått tillbaka till, vad ska man säga, gängse terminologi i branschen. Du nämner uppskalning, och jag funderar ju alltid på hur man undviker att synkningen mellan teamen tar all tid när man jobbar agilt.

Ja, precis. Det är en väldigt bra fråga, och utmaning överhuvudtaget om man tittar med mina forskarglasögon på så är det ju nästan Jag ska inte säga uteslutande, men väldigt mycket handlar ju om koordineringsfrågor i forskning idag kring det agila. Hur man gör det som du säger, effektivt, och inte äter upp all tid eller att det inte blir bra. Man kan väl säga så här: Det finns inget enkelt svar på den saken. Ett enkelt svar är att labba sig fram, se vad som behövs och prova med mycket eller lite. Tvär kommunikation mellan team och mellan olika roller.

Men visualisering är ju väldigt ofta ett svar. svar på lösningen, att det blir en tydlighet i allt man gör. Att man på tavlor och annat visar upp hur saker och ting hänger ihop för att inte behöva ha allt i möten. Sen kommer man inte ifrån möten. Och vi vet ju att en del av det agila manifestets principer är ju att vi ska ha mycket face-to-face-kommunikation. Men att lägga en hel del energi på att visualisera hur saker och ting hänger ihop och beroenden som finns mellan team och så, det är väldigt viktigt. I min forskning just nu så har jag varit ute på tre olika stora företag.

Och man kan väl säga att de två som det gick riktigt bra för, det var för att visualiseringen var i kärnan av hur teamen samarbetade. Den organisation som inte lyckades lika bra med sin implementering, det var just för att de inte lyckades visualisera på rätt sätt egentligen. Jag vet att du både har jobbat med sjukhus och byggbolag. Kan du ta några exempel där de lyckades eller gjorde, Men även där det inte gick så bra. Mm, man får vara försiktig med vad man säger om företag och annat här då. Men jag ska försöka anonymisera det så mycket som möjligt i alla fall.

Om vi tar ett stort fordonsföretag som på en av sina avdelningar införde det här sättet att arbeta. Där la man mycket energi på att först låta teamen vara väldigt självgående och bestämma mycket själva. Och genom att ge dem den friheten de hade, så accepterar man ju mycket bättre vad som förväntades i tvärkommunikation. Och jag tror det är en nyckel i många verksamheter. Man har i stället för att se det agila som regelbok i att det är precis så här man ska införa det. Och där har vi en utmaning med det här storskaliga ramverket Safe då.

Att det kanske är lite för detaljerat och beskriver för mycket i detalj hur man ska göra. Och inför man det för mycket till punkt och pricka, då får man problem. Om man ser det som, vad ska man säga, reglerna i hur man ska göra i stället för att lyssna mer till teamen och behoven, då har man en utmaning. Men det gjorde man inte här, utan här var man så pass… Vad ska man säga? Såg de verktygen från Safe som verktygslåda snarare.

Där lyckades man mycket bättre. Ska jag ta en… En svensk myndighet då som försökte att skala upp sin verksamhet och som hade lite större utmaningar med det. Flera myndigheter har lyckats väldigt bra men på det här stället i deras pilotinstallation utav att försöka skala upp agilt arbete. Där så hade man många coacher inblandade. Många externa som hjälpte till och gav de råd i hur de skulle göra.

Det blev inte att de ägde sin egen förändringsprocess. Coacherna, för att de skulle hitta en gemensam bild av vad som var rätt och fel då tog man Safe som regelbok. Om nån har sagt en sak och nån sagt nåt annat så visar man att så här säger Safe, och det är ju rätt. Och det där blev inte så bra Det blev att man körde ner principer och sätt och göra i halsen på de här personerna istället. Det är inte rätt väg. Så man kan väl säga överlag att om man tittar på det i stort är skillnader mellan bolag som lyckas bra och inte är väl lyhördhet ett rätt så bra ledord.

Är det en verksamhet som faktiskt lyssnar på behoven som finns bland sina team och sina projektmedlemmar på olika sätt kontra de som tror att vi kan nog ge dem rätt verktyg utifrån vad vi ser. Det är en stor skillnad i det. mycket likheter med när man inför Lean. Att lyhördhet är det viktigaste i den här biten. Det finns ju många roller. Du nämner att Safe är kanske för reglerat. Skram har också sina roller.

Hur viktiga är de i det här Gila? Att veta vem som har vilken roll? Först vill jag säga att jag vill inte att… Det här är ingen kritik mot Safe, tycker jag. Jag tycker att Safe är en jättebra utgångspunkt för att göra saker och ting. Det ger mycket alternativ. till hur man kan göra det.

Det är när man läser det för bokstavstroget som det kan bli problem. Så det är väldigt mycket upp till hur man ser det. Om man säger de här rollerna då Hur viktiga de är. Det är en svår fråga tycker jag. Men om man säger Så länge vi har sett till att teamen får mycket självbestämmande kring hur Och så länge vi ser till att de får stöd i form av roller runt omkring Som kan hjälpa till med vad. Om du är produktägare eller produktledare som håller samman ett gäng produktägare eller vad det nu är för roller.

Det tycker jag i sig inte spelar så stor roll. Det kan man skära och dela på olika sätt. Inte så att jag har sett något som är bättre än något annat. Men så länge man har en sådan bra uppdelning i att tillåta mycket av teamen och att man hittar roller som hjälper dem med vad. Då kommer man ganska långt. Då tycker jag sen inte att rollerna i sig är särskilt avgörande.

När man kommer in på vadet så tänker man på produktägaren. Eller är det väldigt enkelt, för produktägaren vet ju alltid allting. Nej, precis. Men i verkligheten, så är det ofta så att det inte är en produktägare. Nej, exakt. Utan det finns många.

Hur hanterar man det här? Ja, om vi backar lite grann där, tror jag. Om man tänker hela Scrums upplägg innan man beskrev produktägaren, det är väl en sak som de själva, Schwaber och Sutherlands, som gjorde det från början, insett att de kanske gjorde en lite för enkel bild av det hela där. Och mycket av… Hur Scrum har förändrats under åren? Det handlar ju faktiskt om att involvera produktägaren mer i det.

Man säger att ungefär 10 % av jobbet ska vara till att förfina kommande krav. Att vi som team är inblandade i vad produktägaren vill ha. Och även att involvera andra intressenter så att inte produktägaren gör nåt sorts solojobb. Man ska lägga mycket tid på att möta och diskutera och få fram kraven på rätt sätt. Så jag tror det var svaret på din fråga. I att produktägarens jobb måste bli ett teamjobb på ett annat sätt.

Ja. Och där tror jag att många har gått fel helt enkelt. Många som har sett det som att det ska vara den ensamma hjälten. I stället för att det är en teaminsats även där. För att få fram vad? Vad?

För mig är det produktägaren. Hur är teamet. Kan du se någon koppling till de traditionella effektmålen och projektmålen? Alltså, lite är det ju det. Jag förstår hur du tänker. Att det är teamet snarare tänker på projektmål, och att vi har en produktägare som tänker effektmål.

Men jag tycker inte att det stämmer helt, för att ska det bli bra beslut från ett team, då behöver de också förstå effektmålen. Sen behöver kanske produktägaren jobba mer med effektmål, och förstå vad det är vi vill åstadkomma. Men även för att fatta bra huvudbeslut så behöver teamet förstå mer av effektmålen, Det tror jag. Så jag tror inte att man ska skära det för klart, för distinkt. Jag håller helt med dig. Vad är då agila metoder i en mening?

Alltså, ja, en mening det är alltid svårt att få till. Men jag tycker att jag har hittat rätt i att uttrycka det ungefär som att det vi gör idag gör vi ännu bättre imorgon. Och det gäller ju på båda planen det vill säga både att vi hittar ett bra sätt för att se att vår produkt eller vårt projektresultat blir bra. Vi tänker ut hur vi kan imorgon göra så att de får se sakerna i tid och ge oss rätt feedback i tid. Kan vi hitta smarta sätt för att få ut delar av resultatet till en testgrupp som ger oss feedback? Och även åt andra hållet, det vill säga hur funkar vi som jobbar tillsammans.

Hur blir vi bättre imorgon jämfört med hur vi gör idag? Och man kan väl säga att Det tycker jag ibland glöms bort ganska ofta i att det där är ett långsiktigt tänk, att det där måste vara kvar. Man möter ju ibland förändringsledare som visar upp någon sorts modell av att man gör en förändring och sen, vad ska man säga, fryser man det till att nu har vi uppnått det nya läget. Den synen gillar inte jag. Att vi kan göra större förändringar ibland och visst lugna ner det hela. Vi ska inte se det som att när vi är klara med det här så är vi klara.

Vi måste landa i att det naturliga är att vi hela tiden tittar på vad vi kan göra ännu lite bättre. Inte att vi… Nu har vi passerat den här förändringspuckeln, så nu är det slappna av och andas ut. Nu är den stora skillnaden mot innan att vi hela tiden diskuterar förbättringar och hela tiden ifrågasätter om det vi gör ger nytta. Nu kanske jag svajar ut långt bortom en mening där, men det kanske var svar på frågan i alla fall. Absolut.

Det jag tänker på är PDCA. från början på 1900-talet. Vad är det som skiljer? Alltså, det är ju samma tänk, PDCA. Man kan väl säga så här. Mycket av det agila generellt är inte så himla nytt. Det finns ju mycket av det tänket både att man plockat in från Lean och att man, som du säger, ännu längre tillbaka med Total Quality Management och så vidare.

Men det är ju att det formaliseras på ett tydligare sätt. Jag tror att det som har varit en styrka med agila metoder och fått det att bli så pass populärt som det är idag. Att det blir en väldigt tydlig process i vad man gör för att få till och med PDCA. Vi ska ha det här mötet med intressenterna i slutet på sprinten. Vi ska sitta ner som team och diskutera och ta upp förbättringssaker. Och det ska vi sätta en timma till och vi gör det varje gång.

Jag tror inte att det är en skillnad. Utan snarare att det har blivit ett förtydligande. Lätt att ledstångla Rätt att hålla i. Ja, jag håller helt med. Och när man tittar på de här en av de här metoderna, då, alltså SCRUM, så tycker jag att det väldigt ofta ses som det samma, som det agila. Men det finns ju fler metoder.

Hur tänker du kring det här? Ja, så är det ju. Över huvud taget ibland, så till och med har jag fått svaret att nej, inte agilt, men vi jobbar med SCRUM här. Och det har blivit så vedertaget som det enda sättet. Det finns ju en brist i att man stirrar sig blind bara på scrum. Å andra sidan, i grunden så vill vi ju att det är ett förbättringstänk.

Och om nu det förbättringstänket kommer sig av att vi använder metoder som är, tekniker från extreme programming, eller DSDM, eller om vi hittar på dem själva. Det spelar ju inte så stor roll, tycker jag. Har man scrum och har infört scrum, då har man ju, på ett bra sätt, Då har man ju förstått att vikten av det här är att vi diskuterar nya sätt att göra saker bättre på. Och vad vi då stoppar in om det är inspiration från att jag läste en bok om XP eller att det är för att jag kom på en bra grej som vi kunde prova. Det spelar inte så stor roll tycker jag.

Jag tycker inte att det är så farligt att de flesta pratar om Scrum när de säger agilt. Det är bara att det har blivit så vedertaget. Jag ser det lite grann som språkutveckling. Alltså… normalt sett Språkutveckling har ju alltid varit sådan att det började med dialekterna. Och sedan när människor från norra Sverige insåg att de behöver kunna prata med folk i södra Sverige då hittade man på någonting gemensamt. Och så formaliserade man lite grann till vad man nu skulle kalla en normalsvenska.

Och lite så tror jag det har varit här. Att det började med de här olika, man pratade om Scrum och XP var ju bäst i ropet i början. Och sedan dök det upp några andra varianter. Och nu när man säger agilt så blir det nästan Scrumd heller. terminologin som man använder. Det låter faktiskt väldigt rimligt. Och jag vet att du har hjälpt många företag att bli agila.

Hur går det till? Jag kan säga så här: Jag vill ju verkligen att den organisation som vill jobba agilt själva ska driva sin egen process. Jag blir ibland nästan ledsen när jag ser hur en del sitter i knäna på coacher där jämt och hjälper dem i allt. Jag har alltid haft en mycket, vad ska man säga, jag ska inte säga mjukare approach, men däremot att jag inte har varit lika mycket på plats. Jag har kanske varit där och hållit i inledande utbildningar, fått dem att förstå grunderna. Och sen har jag låtit dem vara ett tag.

Sen har jag kommit tillbaka och kanske haft workshops eller liknande. Men jag har alltid sett det som en poäng i att ska man bli agil, då måste man själv äga hur man gör man vill jobba. Det är lite av grunden i det. Och jag brukar ibland skämta om att vad en agil coach ska göra är att så lite som möjligt. Och det är väl kanske att ta det till sin spets. Och nu får jag många arga motståndare.

Men det är en risk, precis som jag pratade om förut, att har vi för många coacher som driver det så blir vi inte själva lika innovativa. Och det blir lätt att coacherna tar hjälp av nåt ramverk för att stärka det de säger är sant. Det finns många jättebra coacher där ute, som har sunt förnuft och lyssnar. Men det finns tyvärr lätt en risk att man fastnar i att ta en metod som stöd till att det här är den sanna vägen. Så, när jag hjälper företag så är det med små punktinsatser, hellre under en längre tid än att jag håller i handen, helt enkelt. Du nämner det här med coacher, att om de blir företag För styrande kan det vara en utmaning.

Vilka andra problem finns det vid införandet, som du har sett, och vad kan man göra åt dem? Om vi börjar i den här änden, med hur företagskulturen är kring att vara… tillåtande och experimenterande. Om inte… Eller överhuvudtaget att man har förtroende för sina anställda i att de får fatta mycket egna beslut. Finns inte det, då är det en svår uppförsbacke från staten. i att införa agera-metoder, för det bygger ju helt och hållet på mycket förtroende helt enkelt. Och det handlar ju om en långsam förändring.

Det är inget som man får till snabbt om det är en sån kultur som finns i företaget utan det måste tas några steg för steg framåt helt enkelt. Och det är ju, som jag ser det, det är helt enkelt att prova sig fram. Att man får visa upp resultaten, se här hur bra det blir. nu när den här sprinten vågade släppa taget så att vi fattar besluten själva. Vi kanske ska göra det i nästa team också. Ett annat problem är ju att det finns för mycket av det gamla kvar. Alltså att man har, inte bara kultur, utan att man har svårt att släppa det som man gör sen innan.

Det vill säga, vi säger att ni ska sätta igång med de här sakerna. Men man har inte bestämt vad man tar bort. Då blir det dubbelarbete av allting. Det innebär att vi både ska göra en produktlogg och en sprintplanering men sen vill de dessutom ha en heltäckande projektplan. Och det är en svår nöt att knäcka, tycker jag. Att få organisationen att våga…

Att man går ifrån saker och ting från det man hade innan. Det är en svårighet. Och hur ska man klara av det när det ändå ska göras en kvartalsrapport och en årsbudget? Lätt svar på det: Man får ta det steg för steg. Man får prova, helt enkelt, sig fram till att… Under en kort tid får det vara lite dubbeljobb men sen får man se att det går ändå, helt enkelt.

Och när du säger så så får man lite grann bilden av att bara för att de gick över till agila så blev det mindre säkert. Det blev mindre tydligt i vad man gör och så. Men det är inte riktigt sant. Alltså visst, vi får ju mycket bättre möjlighet till att justera och förändra oss i saker och ting när vi jobbar agilt. Men om man följer upp och har team som jobbar tillsammans under längre tid, då blir man också pricksäkrare. Det är nåt vi ser i forskningen rätt tydligt framför allt när man har infört lite medeldistansplanering där man i Safe kallar PA, att det är ungefär ett kvartal i taget som man gör ganska detaljerad planering av.

Då blir man pricksäkrare än man var innan. Man lär sig vad hela verksamheten klarar av att producera. Och det blir bättre än de här gissningarna som är för året framåt. Men nånstans kvartalet gör att vi lätt sen duplicerar det till halvår och årsbasis. Man ser vad man faktiskt mäktar med. Så det är nånting som vi ser tydligt, att planeringsprecisionen blir bättre, helt enkelt.

Och du nämner det här ordet mäkta med. Min erfarenhet är att när man tydligt… vad man mäktar med, så ser man att man inte mäktar med så mycket. Och det vill man inte höra. Hur hanterar man det här? Alltså, än en gång… Det som agilt är att vara realistisk…

När man väl kan visa upp vad det är man faktiskt klarar av… Även om det är jobbigt, så blir det ju verkligheten. Det är ju när det finns så mycket saker som är under bordet eller under radarn eller vad man vill kalla det. När det dyker upp en massa extrajobb som inte syns. Det är ju det som är… är det stora problemet. Om man däremot kan visa upp det, då blir det lättare att diskutera vad man faktiskt ska göra och inte.

Därav den ökade planeringsprecisionen också, att när vi får det både visuellt och tydligt och allt arbete syns, då kan vi ju bli pricksäkrare. Du har sagt att det traditionella sättet att leda är att göra det enligt vattenfallsmodellen, medan agila är det nya. Är det inte tvärtom, tänker jag, med att jägare, folk och jordbrukare jobbar väldigt agilt? Ja, det är helt sant. Jag har använt termen traditionella projekt eller traditionell projektledning. För att det är det som har varit.

Vad ska man säga? Det man har beskrivit kring projektledning sedan termen kom till runt 40-talet. Vi har ju alltid drivit projekt, men just projektledning som egen disciplin, Project Management, myntade man inte förrän på 40-talet och från det till nu har ju innan agila metoder så har det varit det traditionella. Så det är rent termmässigt har det blivit, att man kallar det traditionellt. Men du har helt rätt i att självklart har man längre bak i tiden haft en agil approach. Det är inget snack om det.

Att man har varit tvungen att hantera förändringar och så. Det kommer ju mer från hela ”Scientific management” hållet med att man har tydliga planer som man kan se exakt hur lång tid saker och ting tar, som formade prodic management från början. Då kan man säga att Vattenfallsmodellen har varit en parentes i historien. Om jag hårdrar det lite, så hävdar du att det agila arbetssättet är bättre än det traditionella? Ja. Alltså, det agila arbetssättet i ett team, skulle jag hävda alltid är det bästa sättet.

Att vi har, och med det menar jag att vi har mycket självbestämmande i teamet och att vi ärligt tittar på delmål och fattar nya beslut löpande. Det kommer alltid att trumfa med att ha en tänkt plan som inte följer upp så ofta, på riktigt, som är svår att ändra i och så vidare. Det är klart att det inte blir lika bra. Men därav så är det ju med det sagt så kan man väl säga att det är inte det är inte så att det traditionella sättet att driva projekt är fel. Har vi till exempel projekt där det är väldigt höga kostnader för förändring. Då är det klart att vi inte kan vara hur flexibla som helst i vår långsiktiga planering.

Vi kan inte plötsligt riva upp hela den här asfalten som vi har lagt två mil av, för att vi kom på att det vore bättre att dra vägen runt det här berget i stället. Så för en del projekt med höga kostnader för förändring så är det klart att vi behöver ett traditionellt projektplaneringsstöd Men därav kan vi ju ändå ha team som jobbar agilt. Vi kan ha samma struktur i att jobba oss framåt och lösa små problem, och hur vi åstadkommer saker och ting. Men den planeringen för hela projektet, om det är dyrt att ändra på, det måste vi ha ett traditionellt, långsiktigt tänk i.

Så om du skulle råda det kommande Marsprojektet, vore det att ha en Vattenfall-modell på toppen, och sedan jobba agilt ute i delprojekten? Ja, det tror jag. Men vad man då vill kalla traditionellt tänk i toppen det är väl snarare i så fall att ha, vad ska man säga, att ha en tydligare… Gå lite längre i detaljeringen av sina planer tidigt, det tror jag ju, absolut Men sen att ha ett agilt sätt i att man utvecklar Marssonden, eller raketen, eller vad det nu är Det tror jag på. Och det är ju så Nasa jobbar redan idag. Det är ju så det funkar där.

Jag upplever att det precis… så många företag alltid har gjort och kommer att göra. Är man ute på en byggarbetsplats, så har man gjort en plan för bygget, medan gubbarna, de har jobbat agilt i sina team med om ett kök ska sättas upp eller liknande. Precis. Precis. Jag håller helt med. Finns det något som inte är agilt i det agila?

Finns det någonting vi inte får röra? Alltså, jag ser inte som att det finns något inte agilt i det agila i sig. Men precis som det jag nämnde, förut i att det finns en del ramverk och metoder som är väl detaljerade. Där finns det ju en risk i att man blir mer slav under det. Och då har man ju tappat grundtanken med det agila. Så på det sättet kan man säga att det finns en risk att det blir icke-agilt om man blir för bokstavstrogen överhuvudtaget.

Att man gör agila processer och verktyg för detaljerade. Där finns ju en risk. Och i det agila manifestet finns det ju de som var med och skrev det, som har tankar om att vissa saker man absolut inte får röra. Mm. Nej, det tror jag inte på. Jag tror…

Alla de som var med och skrev manifestet kan nog fundera ibland kring en del utav formuleringarna där och om de verkligen står för det idag. Vi kan väl säga så här, att det typiska synsättet med att införa agera metoder som det var i början från 2000-talet, om de åren där, det var ju att man måste införa helheten för att det är ett systemtänk. Vi kan inte bara ta några små bitar av Scrumm. Ska vi få nytta av Scrumm måste vi införa hela Scrumm i sin helhet för att det är ett systemtänk. Det har vi ju i forskningen sett att det inte är sant. Så länge man har rätt värderingar och det här tänket kring att ständigt förbättra sig och sånt så finns det inget som visar att ett företag som inför Scrumm till punkt och pricka funkar bättre än som har tagit vissa bitar.

Men om inte värderingarna finns där, då blir det inte bra. Så skulle man kunna säga. Så det finns inget heligt egentligen. Det kan vara flera skäl till att de här metodgrundarna uttryckte det på det här sättet. Det kan ju ha ett vinstsyfte i bakgrunden också. Det är inte omöjligt.

De sålde ganska mycket på utbildningar och sånt till att folk ville hålla på med det de gjorde. Så då kunde det ha funnits ett egenvärde i det. Det misstänker jag i alla fall. Intressant. Jag vet en konsult som berättade för mig att när han tittar på om han har infört Lean på ett bra sätt i en organisation. Så frågar han alltid om de ser att det är en metod eller en filosofi.

Om de säger att det är en metod, så är det inte bra infört. Säger de att det är en filosofi, så är det bra infört. Ja, just det. Jag brukar säga så här. Om jag går till ett företag som säger att de jobbar i en Scrum. Och så tittar jag hur de gör.

Och så kommer jag tillbaka om ett halvår. Om det då ser likadant ut. Då kan jag säga att ni är inte agila. Så ser jag det. För då har man ju inte förstått ständig förbättring och att man ifrågasätter och förändrar. Då följer man bara SCRUM.

Hur får man då ett team att hålla deadlines? Jag tänker till exempel när vi har beställare och leverantör. När vi har sålt något med en deadline. Alltså, hela upplägget kring det agila handlar ju om att vi har tillräckligt täta kontakter och stämmer av att det blir rätt. Och det är egentligen ingen skillnad från agilt till om man nu kallar det Vattenfalls tänk heller i att vi måste se om det inte blev exakt enligt plan så måste vi göra någonting åt det. Och jag tycker det är en nidbild ibland man får av agilt i att det inte behöver vara särskilt tydligt planerat och så vidare.

Så länge vi har en helhetsplan som vi bryter ner under vägen och att vi har leverantörer som är med och ser eller kunder som är med och ser att det blir det de ville ha då har vi ju tvärtom bättre möjligheter styra rätt? Det behöver inte… Ibland tror man att… Att jobba agilt, då har man ett helt tomt ark i att nu ska vi se vad vi ska sätta igång att göra. Och så är det ju inte. Utan det där kan ju vara olika tydligt ark beroende på typ av projekt.

Så vill vi ha en ganska tydlig beställning, ja då kan vi göra det. Vi kan lägga lite mer energi på att göra den ganska detaljerad. Och framför allt lägger vi mer energi på att ses ofta. Så att vi ser att nu blev det efter de här två veckorna precis det vi har tänkt oss. Är det inte så? På det viset kan man styra in det mycket bättre.

Och än en gång: Det är inget motsägelsefullt i att ha en tydlig, långsiktig plan och ändå vara agil. Det kan vi ju ha. Om man tittar på de här fordonsföretagen, och över huvud taget stora företag som jobbar agilt i dag, det är klart att de inte har ett tomt ark. De har tänkta projekt fem eller kanske tio eller femton år fram i tiden. Det är vad de tänker göra. Jag tror det var svar på din fråga.

Det var det. Och det får mig att tänka på… Om ett team då har ett självbestämmande så får de då strunta i dokumentation om de tycker att det är onödigt i ett sånt där beställa-/leverantörsprojekt? För det var ju hur? Ja, precis. Exakt.

Det där är en jättebra fråga. Och det är en typisk sådan fråga man får när man håller en utbildning och folk är oroliga i lokalen över om man kan tillåta vad som helst i teamet. Då kommer det ofta dokumentation. Tänk om de inte vill dokumentera, då kan vi inte göra någonting. Men det är inte sant. Hur man utför sitt jobb, det vill säga löser uppgifterna och vilka verktyg man tar till för att åstadkomma den här funktionen eller den här väggen, eller vad det nu är som vi ska göra.

Det vill vi att teamet bestämmer. Men vad det är som görs det är ju produktägaren som tillsammans med teamet ska bestämma vad det är alltså vad är det som innebär att det här är klart? Och då är det ju helt upp till produktägarna att säga antingen, ja ni måste dokumentera alltihop för att vi ska säga att det är färdigt. Och då måste teamet göra det. Eller så säger produktägaren I och med att vi har det långsiktiga ansvaret för det här. Vi bygger ett system som vi fortsätter att förvalta och drifta så kanske vi inte ska lägga så mycket energi och tid på att dokumentera.

Vi tar bara det absolut mest nödvändiga för Du vet ju, precis som jag och Mattias, att ibland finns det en del dammiga dokument där ute, där folk har dokumenterat väldigt mycket av vad de har gjort. Men ingen använder det. Och om vi då har ett agilt mer processtänk av att det är samma team som använder, förvaltar och vidareutvecklar det vi bygger kanske vi inte behöver lägga så mycket på det. Det kanske bara är det mest centrala vi ska dokumentera, egentligen. Det är en jättebra diskussion som man kan ta. Kanske Spara pengar för att du ser ser hela processen, inte ser det som ett enskilt projekt som bara levererar och sedan går därifrån.

Precis. Det tycker jag är intressant. Jag upplever dock att ibland, i Ragila, så glömmer man gruppdynamiken, som utgår från att den här diskussionen ska kunna ske i teamet och med produktägaren. Hur tänker du kring det här med gruppdynamik? Peter: Ja, det är helt sant. Man kan väl säga så här, att det här med servant leadership, brukar man kalla det, det som en Scrum master ska göra.

Att man hjälper teamet att fatta egna beslut och så där. Och bilden av ett väl fungerande agilt team, eller Scrum-team kanske man till och med ska säga, för att det är mest i Scrum man uttrycker det så tydligt, i hur det ska se ut, det är lite grann, som du säger, implicit att teamet redan fungerar. Att det är en bra gruppdynamik i det. Men vi vet ju från gruppforskning att i början när vi formar som nytt team? Om vi inte har jobbat ihop förut, då vill vi ju som teammedlemmar ha mer tydlighet. Vi vill ju veta vad vi ska göra och vad som är tänkt.

Det trivs vi bäst av och utvecklas snabbast av. Det är först när vi har börjat bli bra och fungerar bra ihop som vi kan släppa på det där. Och där är ju Scrum masterns jobb lika viktigt som det är när vi är ett fungerande team. Bara att då måste Scrum mastern hjälpa teamet genom att vara tydligare. att vi måste vara tydligare, I början. Då måste Scram-Mastern vara mer drivande helt enkelt i att komma igång med vem som ska göra vad. Allt eftersom lämnar jag över till att fatta hela teambeslut.

Det här lyfts sällan. Det är väldigt ofta man hör om hur det ska funka när vi redan är team. Och tack och lov har många av de som har bestämt sig för att gå till att bli agila redan team där de fungerar bra ihop. Så där är det ju inte lika stort problem. Men för de där som skapar team från scratch och ska börja jobba agilt, då är den här saken väldigt viktig och lyfts inte särskilt ofta fram, tyvärr. Är det här svaret på frågan också om Scramousterns roll är stöttande eller drivande i ett självorganiserande team?

Ja, till viss del. Man kan väl säga så här, att vi vill ju att… En Scramouser ska vara både stöttande och drivande under vägen. Ju mer vi funkar som team, och att människor i teamet är kreativa och komma med förslag om vad vi ska göra. Då behöver inte Scrum mastern vara särskilt drivande. Då är det mest stöttande.

Men vi vet ju alla hur det funkar med team som blir fat and happy. Det finns alltid en risk att vi slutar att ifrågasätta om det vi gör är det effektivaste. Då behöver Scrum mastern bli mer drivande. Så det är inte bara en fråga om utveckling av när teamet är från scratch och när de är mogna. Utan det kan variera hela vägen. Och man ser ju att en del agila team har skippat Scrummaster.

De har gått över till att bara vara ett självorganiserande team. Och det kan fungera. Men det kan ganska ofta, eller kan. Vi ser att ganska ofta så hamnar teamet i att de slutar att vidareutveckla sig. Att förbättra sig helt enkelt. Så jag tycker att Scrummaster-rollen är viktig.

Framför allt på det långsiktiga planet. i att man har någon som dedikerat ska tänka på om det vi gör är rätt eller om vi kan göra det ännu effektivare. Ifrågasätter teamet i att: varför gör vi så här egentligen? Kan vi inte prova på ett nytt sätt? Där har en Scrum master en väldigt viktig funktion. Vem är det då som bestämmer? Är det Scrum mastern?

Teamet? Chefen? Produktägaren? Givetvis är det olika frågor. Jag tycker att just det du sa med olika frågor. Det är det viktigaste svaret på den frågan.

Vi vill ju att alla är med och bestämmer. Men jag brukar… För att få lite tydligare brukar jag säga så här att Teamet fattar ju beslut om hur vi gör saker. Men Scrum mastern har ett rätt att fatta beslut i den dagliga processen. Till exempel om vi har ett möte här och Kalle pratar för länge. Så kan Scrum mastern avbryta och säga, Nej men du, nu har du sagt tillräckligt.

Men också att Scrum mastern är den som som ska komma med förslag Då blir det hela teamet som har rätt att besluta. Men att man som Scrowmaster jobbar på att föreslå nya saker men vi vill få hela teamets beslut kring det. Och när det gäller HR-frågor då? Ja, det är svårare. Ofta har inte teamet någonting att besluta kring utan ofta är det en chef som har som har mandat där. Och cheferna är ju viktiga i den agila organisationen också.

Vi som självorganiserade team får inte bestämma om att anställa fler till vårt team till exempel. Så det, HR-frågorna ser jag som faktiskt utanför den agila team och produktägarkontexten. Men det är ju som vanliga projekt brukar fungera också. Som projektledare får jag ju oftast inte heller anställa eller utan att jag måste ta hjälp av chefer kring sådana frågor. Jag vet att jag har läst om Agila Team som har tagit över lönesättningen i interna team. Ja, det är friskt vågat.

Det kan säkert fungera. Jag har inte stött på dem. Jag tänker så här. Det är inget självändamål att man som Magila Team ska ta över HR-delar. Sen är det klart att det är väl möjligt. Man kan ju laborera på alla möjliga. kring hur mycket självbestämmande man får ha.

Man kan väl säga att det var redan… Det kom ju från gruvindustrin från någonstans 50-60-talet. Man insåg de stora skillnaderna i de team som fick bestämma mer hur mycket bättre de fungerade än de som inte fick det. Det har man ju sen dess laborerat med på rätt många olika sätt från att man hade bevis på att det funkar bättre med självorganiserande team. Jag blir ibland lite förvånad. Jag blir förvånad när jag hör om team där man har väldigt lite inflytande.

Att man inte känner till att det är kraftigt bevisat sedan lång tid tillbaka att vi vet att det funkar bättre där. Absolut ingen passus. Grunden för att det här ska fungera och att det ska införas är att det genererar mer pengar till aktieägarna på slutet, eller på någon annan nytta. Precis. Och nytta… Då pratar vi också om olika verktyg som finns i inom det agila.

Vilka tycker du att man ska låna till projekt som drivs enligt Vattenfallsmodellen? Jag tycker egentligen att allt som har med visualisering och tydlighet, det tycker jag man ska använda rakt av. Eller rakt av, man ska i alla fall ta inspiration av. Sen är det ju inte säkert att de ska se likadana ut. Men då tänker jag på sånt som väggtavlor som visar arbete. Vad vi har tänkt att göra närmsta tiden, vad vi håller på med, var och en, och vad vi är klara med.

Sån enkel visualisering av jobb gör att vi inte behöver ha så många statusrapporteringar och sånt. Vi kan se det. Vi kan direkt gå in och titta på hur status är genom en sån visualisering av jobb. Så den typen av visualiseringar tycker jag är väldigt viktiga. Och det ser man ju väldigt tydligt nu när det blir allt vanligare med safe implementationer alltså att man blir agil även på högre nivå, att det införs på alla nivåer uppåt också. Från de långsiktiga affärsbesluten så har man även där tavlor på väggarna med post-it lappar som visar vad vi har tänkt oss göra och så vidare.

Så visualiseringar är väl det enkla svaret. Sen sånt där som stå-upp-möten och demonstrera eller granska resultat och ha erfarenhetsmöten eller retrospektiv, det kan ju också alla traditionella projekt använda sig av. utan problem, och med stor framgång. För det ger väldigt mycket att vi får en tydligare puls. Vi vet om hur mycket vi siktar på, och vi vet om att vi får bra feedback lagom ofta. Och vi har en arena för att diskutera hur vi blir bättre. Det är inte särskilt komplicerade saker, men ger stor skillnad.

Bland den här visualiseringen så brukar det ingå just att man ska mäta att man blir bättre och bättre. Det jag har sett är att det går ibland en inflation. i den här mätningen. Så egentligen blir vi inte bättre. Det är bara att vi poängsätter på ett annat sätt. Berätta lite om det. Ja.

Det blir rätt inflation i mätpunkter och uppföljning. Det tror jag tyvärr är mänskligt. Jag tycker inte att det är något man ska lägga för mycket energi på. Hellre att vi ser att vi blir pricksäkrare mot vad kunden eller beställaren vill ha. Men lägga mer energi på det än att: Att mäta så mycket kring att vi är i detaljerna så exakta. Då är det risk annars att vi är tillbaka i vårat micromarrangement igen, ifall vi lägger för mycket tid på det.

Så hellre i de stora penseldragen, tänker jag. Är det bara gula lappar som gäller, eller finns det andra sätt att jobba med visualisering? Nej, men alltså… Att ha analogt sätt att visualisera saker och ting, det är ju väldigt kraftfullt. Kan man det är det ju en fördel. enkelt. Men sen är det klart att vi kan ju ha motsvarande system även digitalt.

Är det bara enkelt som man lätt kan komma åt och förstå hur det hänger ihop, då är det ju bra. Särskilt i de här coronatiderna som är just nu så är det ju väldigt tydligt hur hur vi måste ha saker digitalt. Men det jag menar egentligen, det viktiga är att det är enkelt att få en överblick av det. Sedan spelar inte så stor roll om det är plansch på väggen eller om det är verktyget Trello som ser ut som en vägg med post-it-lappar eller så. Det viktiga är att det är enkelt och överblickbart helt enkelt. Du nämner Trello, och det finns ju många andra verktyg.

Var kan jag hitta mer att läsa? Har du några rekommendationer? Kan jag hitta mer information om jag skulle vilja införa det här? Finns det någon bok, till exempel? Agil projektledning: Övningsbok till exempel finns det ju med. Jag tar upp olika exempel, dels i min textbok men även i den som heter övningsbok, som är olika varianter på saker och ting man kan göra, och där man kan testa själv på olika sätt att jobba agilt.

Det kan jag rekommendera. Ja. Och om man vill få tag på dig och få kontakt med dig, hur gör man då? Ja, jag är just nu på Karlstads universitet, så enklast är att mejla mig. Och det är: thom@gustavsson@vt.se kau.se Och vad tror du? Finns det plats för en projektledare i framtiden?

Även om många organisationer fortsätter, börjar jobba agilt eller fortsätter jobba agilt. Framför allt ser man ju många företagare som kanske varit agila på IT-avdelningen så sprider det sig i resten av företaget. Jag tror ändå att vi kommer ha kvar projektledaren på många ställen. Alltså rollnamnet projektledare. Typiskt i branscher där man som kund köper in saker från leverantör. Man vill ha ett ansikte som man pratar med och det kallar man för projektledaren Jag tror inte att projektledaren är på väg att försvinna Tack Thomas, för att du tog dig tid att vara med här i Projektledarpodden Jag har lärt mig jättemycket i dag Framför allt har du satt igång ett antal tankar som du behöver tänka vidare på Jag önskar dig lycka till med promoveringen som du har senare i höst Stämmer!

Vi hoppas få möjlighet att återkomma till dig när du är doktor. Stort tack! Tack så mycket! Talman: Tack för att du har lyssnat på Projektledarpodden. till oss med idéer, tips och förbättringsförslag. Det gör du enklast via mejl på Lyssnare@Projektledarpodden.se Eller via det sociala nätverk du föredrar.