ProjektledarDetta är en maskinell transkribering (KB-Whisper) av avsnittet som publicerades 2024-01-04. Fel kan förekomma.
Lyssna på avsnittet: 46: Kombinera agilt och projekt - så här gör man! Nathalie, Jeffrey och Martin från Onbird förklarar. Läs sammanfattningen: Agilt och traditionellt projekt tillsammans – Så får du metoderna att samexistera (46)
Transkribering
En sprint på 30 dagar är rätt lång för många, men det passar rätt väl in i den 12 månaders kalendern. Vi kanske kan föreslå… Den som du har pratat är Jeffrey. Han kommer idag tillsammans med Nathalie och Martin från Onboard. Berätta om hur man får det här med agilt att fungera tillsammans med traditionella projekt. Jag heter Mattias Ejbe som har den här podden och nu kör vi!
Du vill lyssna på Projektledarpodden. En podd för dig som gillar att leda projekt. Vi lärde mer av andra om projektledning. Idag har vi med oss Jeffrey, Nathalie och Martin från Onboard. Vi kommer prata om agilitet och projekt och hur man kombinerar det här. Martin, du kanske kan berätta vad vi ska prata om idag?
Tanken är väl att vi ska prata lite grann om hur man kombinerar agila arbetssätt med traditionella projekt utan att egentligen behöva slå ihop de här metodikerna och kalla det agila projekt eller så där. Utan att de faktiskt har sina styrkor och kan leva på varsitt håll, men att det går att få dem att sammexistera. Berätta kort om vem du är och hur det kom så att du kan berätta om det här då. Ja, Martin Komstert heter jag dock som sagt och jobbar på Onbird. och har väl kommit ifrån den agila skolan, egentligen större delen av mitt yrkesliv, men har väl i min konsultroll sett att det här med projekt och agilt, det är liksom två nästan religioner som finns på väldigt många ställen och det blir en form av schism de är mellan.
De ska inte gå och kombinera och det ska vara en lite tuff fight mellan dem Men ingen av de här kommer någonsin att vinna den här fighten. Utan projekt kommer att finnas kvar för att det finns en massa styrkor i projektmetodik. Och Agilt kommer att finnas kvar därför att det finns jättemycket bra grejer i Agilt också. Så då behöver vi kunna hantera att de sammexisterar och går parallellt och inte håller på och tjafsar hela tiden. För det är i slutändan så de som vi gör saker för, våra kunder eller verksamheten eller beställarna, De struntar lite grann i vilken typ av metodik vi jobbar med utan de vill ha resultat och inte tjafs.
Jeff, berätta lite om dig själv och du kanske berättar lite om de största frustrationerna. Ja, ja tack. Roligt att vara med Mattias. Jeff Schmitzert och jag grundade Onward för 15-16 år sedan. Vi jobbar med förändring och förbättring helt enkelt. Och där i kanske ligger Om jag får representera verksamheten lite grann i diskussionen idag.
Frustrationen är ofta, verksamheten, syftet med våra förändringar är just resultat i verksamheten. Och vad vi ofta, när vi jobbar med våra programkontor och projektledare och Scrum Teams och så vidare. Det kan bli ganska mycket fokus på metoden över resultatet. Så vad vi tänkte prata om idag är lite den där balansering mellan metod och resultat. Och jag kommer att slåss mycket för resultatet, förbättringen idag som vi vill åstadkomma oavsett metod. Nathalie, du har ju varit med tidigare.
Du kan berätta lite kort om dig själv. Och sen de vanligaste utmaningarna som man stötte på som projektledare i samarbetet med Agila Team. Tack för att jag får vara med igen. Jättekul. Nathalie Heisner heter jag. Om Martin kommer från den Agila skolan och Jeff kommer lite mer från det projektskolan skolan så kommer jag nog från den dysfunktionella skolan.
Jag var med och har arbetat på platser med zombie-scrum, man inte vet varför man arbetar agilt. Jag har också arbetat i dysfunktionella projektorganisationer och upplevde väl länge en oerhörd frustration över att liksom ingenting gick som det ska. Och jag själv var inte utbildad i något av det så att jag Jag passade på att säga upp mig och gå till skolbänken igen för att lära mig mer om de här metoderna för att kunna göra ett bra jobb som också känns tillfredsställande. Vanligaste utmaningarna man stöter på som projektledare i just samarbetet med Agila Team det är en rätt spännande fråga med många bottnar i.
Jag har väl ungefär tre sådär som jag kan plocka från minnet. Nummer ett är att man inte förstår varandras arbetsmetoder fullt ut, vilket i sig får många följd konsekvenser. Om man tänker att man är som en verksamhet som använder både projektmetodik och agilmetodik så ställer det egentligen högre krav på alla individer att förstå de här olika modellerna. att man faktiskt kan ha ett bra samarbete mellan varandra. förstår vad syftet med respektive metod ger. Den andra då som jag stöter på i de vanligaste fallen är att man har en beställar och en leverantör eller beställar mottagar mindset mellan projekt och Agila team.
Ett exempel på det kan ju då vara att projekten skickar över kram till de Agila teamen i ett projekt språk. Man då inte stipulerar behoven som de Agila-teamen gärna vill förstå för att kunna utveckla ordentligt. Man beskriver inte heller riktigt vad det är till för. Och med det tar de inte heller hänsyn till de Agila-teamens backlog eller till och med ännu svårare, ännu mer komplext, i och med att ett krav måste ha flera av de Agila-teamen för att faktiskt realisera. Och om man då inte är med och förstår det här, Då kan man inte heller koordinera mellan de här teamen och faktiskt hjälpa till att dela upp det här arbetet.
Man kan inte förstå då de agila modellerna. Så det är liksom den andra utmaningen som jag ser uppstår allra oftast. Och sen den tredje och sista då som jag vill få in i den här frågan är från det agila teamens håll. och det är att de är väldigt rädda för att göra lite mer långsiktiga planeringar som projekten faktiskt behöver ha för att kunna redovisa. Så det är de tre vanligaste utmaningarna som jag stöter på i mina uppdrag. Man blir ju sugen på att fråga redan nu vad man ska göra åt dem, men vi tar det lite senare. Från ett agilt perspektiv, då.
Vilka är de största missuppfattningarna eller problemen som ni möter i samspelet med projektledning? Jag tycker Natalie sammanfattar väldigt mycket, väldigt bra. Alltså det här att man inte riktigt förstår varandras metodiker är ju ett stort problem. Man tänker att det finns någon form av naturlag på båda sidorna så att säga. Det blir en viktig del att följa metodiken och om det krockar med samarbetet så blir det där problemen uppstår. Från erfarenhetsmässigt, en klassiker från ett agilt team är att man kommer in alldeles för sent i ett projekt.
Det har gjorts mycket av det som vi vill tycka och tänka till om, har redan beslutats och budgeterats och tidsats utan oss egentligen. Vilket gör att det kan komma alla möjliga konstiga krav med alla möjliga konstiga deadlines. Det blir mer att vi ska utföra och inte tillföra, vilket är lite osexigt om man är människa. Det är ingenting med utvecklare att göra, men det är inte tokpepp. Så det finns en form av övertro på metodiken i att vi måste hålla vår metodik, annars kommer allt bli helt kaiko, som att man aldrig har genomfört varit sig agilt arbete eller projekt tidigare, utan att det blir en massa fel.
Man kan inte planera sig ur hur mycket som helst. Man kan inte förutse allt hur mycket som helst. Det vet alla. Men ändå ska projekten planera och förutse och ha hängslunden vid den på allting ändå. Medan Stegila håller på att härja jättemycket om att nej men det kommer att förändras, det kommer att förändras. Vi kan inte planera någonting.
Det blir jättedåligt. Så det blir ett problem i samarbetet för att vi liksom vill, vi vill inte titta på rent empiriskt, historiskt hur det har gått när vi har jobbat tidigare. Vi behöver lära oss helt enkelt. Det blir lite jobbigt att komma med den här stora svarta hatten och vara jävelens advokat när det kommer ett projekt och säger hej, hej, här har vi planen, här är budgeten, gör. Och att varje gång då säga att fast ni kommer ändra saker och får svaret, nej nej nej inte den här gången, allt är förberett. Det är skittråkigt att ha en stor svart hatt jämnt.
Jag menar, om det värsta som kan hända, om vi har lagt lite tid på att förbereda för förändring i ett projekt och så kommer ingen förändring, okej då har vi gjort något möte eller två i onödan. Däremot, om vi inte välkomnar förändring i processen och den välkommer, för det gör den, då har det kostat oss betydligt fler mötes och väntetimmar. Det stora problemet är att man blir lite religiös och att man tvångsmässigt ska hålla fast vid sin metodik. På vilket sätt kan verksamheten bidra till en smidigare samexistens? Här tänker jag att både själv komma ihåg som verksamhet, men påminna alla deltagare i förändringen att det är syftet.
Det är inte metoden, det är resultatet, det är syftet. Så man bär ett ganska stort ansvar att fortsätta att tjata om det eller påminna om det. Om man vill använda bättre ord. Sen tror jag att det är viktigt att komma ihåg att Båda för sig själv och alla som deltar, att de här två metoder behöver inte vara så olika. Det handlar mer om själva utförandet än metoden. Och som det ofta blir, inte vad vi säger, men hur vi säger saker och tänker.
Inte vad vi gör, men hur vi gör blir väldigt viktigt. Så att bidra till en sådan, låt oss plocka det bästa från båda skolor. Sen sist men inte minst, verksamheten behöver vara med. Det har vi sagt i alla år när det gäller projekt och förändringar. Och när vi har blivit agila så har inte det förändrats. Vi behöver ha ett aktivt deltagande från verksamheten i de önskade förändringar som de vill ha.
Hur har ni lyckats involvera verksamheten på ett effektivt sätt? Jag tänker att dels finns det faktiskt delar av verksamheten som inte är intresserade av att vara involverade. Det är liksom ett första steg. Man agilt utgår väldigt mycket ifrån att kunden är involverad. Alla vill vara involverade. Alla vill ha drivkraft.
Alla vill ha ansvar. Så är det ju inte i verkligheten. Utan man måste försöka hitta någon form av minimum. Om det sitter ett gäng på verksamhetssidan och tycker att vi är den närande sidan av organisationen och nu kommer den här tärande sidan av organisationen och vill saker av oss. Nej, det vill inte vi. Då behöver vi från vår sida hitta ett absolut minimum för vad vi faktiskt behöver från verksamhetssidan.
Vad är det vi behöver från kunderna? Oftast någon form av feedback. Och vi kanske inte kan få alla på verksamhetssidan och vara jättelyckliga och boka bort allting annat för att gå på sprintdemos. Men däremot kanske vi kan hitta en person som är lite engagerad eller tycker det är lite kul och som kan få vara vår speaking partner i så fall. kan vi anpassa kommunikationen till verksamheten så att vi så till den milda graden att vi kan lura ur dem vad det är vi vill ha för information från dem. Det handlar om att anpassa mycket. För vi kan inte utgå från att alla är lika engagerade i det vi gör dagligen som vi är.
Men ofta är verksamheten mer sugen på vad vi involverar än vad man tror. Så det handlar primärt återigen om att kunna kommunicera med dem på ett sätt som de känner sig bekväma och inkluderade i. För att de vill vara med men de fattar inte den här tekniska mumbo jumboen som vi kommer med. Så då behöver vi hitta ett gäng individer igen då som vi kan prata med och så kan vi faktiskt ha en ärlig diskussion med och säga vad är det ni inte förstår i det vi säger. Hur kan vi förklara vad vi gör och vad vi vill på ett enklare sätt för att det är liksom…
Vi vill ju trots allt ha dem som vollplank och rådgivare i det vi gör för att de ska bli nörda till slutändan. Vi behöver vara beredda att förändra vår kommunikation, förduma vår kommunikation om man vill se det på det viset, eller förenkla, eller försvenska, eller prata på affäriska, eller vad man nu vill se det som. Och så bör vi verkligen se till dem som en tydlig och viktig intressent, för det blir lätt att verksamheten… De är inte lika viktiga som slutkunden, men ofta är det verksamheten som är mottagade av det vi gör. Så vi behöver behandla dem som den viktiga intressent de är och visa att vi behöver leverera på deras feedback.
Den feedback vi får och tvingar oss fram till eller lurar ur dem eller hur vi nu vill göra det. De behöver vi leverera på. Vi behöver tidigt se till att det de säger till oss faktiskt fastnar och slår rot och händer och förändrar någonting. Och sen att vi behöver kommunicera med dem på deras villkor och vet vi inte hur så måste vi fråga. Och vi måste kommunicera ofta. Vidare så behöver vi också förbättra hur vi jobbar utifrån deras input.
Låt dem vara med i retros. Fördelen med att jobba mot verksamheten i en organisation är att de oftast finns i samma Outlook-system, kanske i samma hus, och har möjlighet att boka möte med dem. Det är långt ifrån alla kunder eller slutanvändare som man kan göra det med. Låt dem vara med i retros, inte alla retros, men vissa, och ta det de säger på allvar. Det är ett sätt att involvera som jag har sett är effektivt. Jag tänkte bara säga att en av de saker som vi också kan göra som förändringsagenter, oavsett vad vår skola är, är att vi kan kräva deras involvering.
Det är konstigt ibland hur en allmän skärpning också får en respons ibland från verksamheten. De är olyckligtvis ganska vana vid lite Latch- och lojförändringar-projekt som alltid blir sena och alltid blir dyra. Men när vi kommer in i styrgruppsrummet eller i första mötet och säger följande kan ni förvänta er av mig. Vad kan jag nu förvänta mig av er som delaktighet, deltagare? Det är ganska viktigt att… att ställa krav på verksamheten och deras delaktighet. Och galet nog så får den där skärpningen ofta en väldigt positiv respons.
Istället för skärpning så kan det också handla om att de ska förstå vad vi gör och varför vi gör det. Om man tittar på de vanligaste projekten där verksamheten är mottagare så är det ofta införande av ett nytt system. Det gör vi åt dem. Jag kan tycka att ett problem är att vi ofta, i min erfarenhet, inte börjar med att titta på själva verktyget och vilka processer som ska stödjas för att kunna göra en förändringsresa i organisationen där det här verktyget ska ofta förändra och förbättra effektiviteten ofta där vi landar. Jag kan tycka att att involvera verksamheten och få dem att uttrycka sitt behov som man inte utvecklar eller gör fel system åt dem.
Då kan man också få dem att bli mer involverade. Det finns ju företag där kanske ledningen beslutar att vi ska ha ett nytt system. Men om vi nu säger att verksamheten kanske inte är så intresserade. Hur jobbar man då? Eller hur? Det ser man också.
Då finns det säkert 70-11 till projekt i pipeline som ska vara klara. Så man ska bara trycka ut det här så snart som möjligt. Då hamnar man i det problemet att det inte finns tillräckligt mycket tid, vilket gör att man får trycka in det. Det är supersvårt att göra någonting bra av det, tycker jag. Man kan få ut systemet. Men man förlorar hela den här förändringsresan, man förlorar drivet som kan skapas i organisationen för ett nytt verktyg.
Vad man ska göra åt det? Jag brukar prata om att man kan bilda sig som små task forces i verksamheten som faktiskt får vara med och driva det här projektet. Och är det olika affärsområden eller olika delar i verksamheten som ska arbeta i applicationen eller systemet sedan? Se till att ha en medlem i taskforce från varje avdelning som kan sprida information på ett snabbt sätt. Vi pratar om språk mellan verksamhet och agila teamen eller projekten. Men den finns även mellan agila teamen och projektledare.
Hur tänker ni där? Det här är en liten del av att lösa problemet kan jag se det som. Man behöver ha en gemensam förståelse, både över metoderna. I metoderna använder man olika definitioner och olika språk. Till och med på det agila, på den svenska marknaden, använder man alla engelska termer. Det är viktigt att man förstår vad man pratar om, teamet och projektets insid.
Bland det viktigaste man kan göra i uppstarten av ett initiativ är att ta tjuren vid hornen på en gång. Att ha uppstartsdagar, att prata om hur man ska arbeta eller att man ska ta fram en gemensam struktur där vi kan dra nytta av båda de här modellerna och prata om vilka styrmodeller som finns, hur man budgeterar, vilka roller och vilka mandat som faktiskt finns i de här metoderna, hur man planerar, det har vi pratat om mycket, att det skiljer sig, och vilken leveransmodell som man ska använda sig av. Att man faktiskt sätter sig ner tillsammans och definierar och kommer överens om det här. Och sen kontinuerligt under initiativets gång, Man har mikroutbildningar, man pratar om varför man gör på det här sättet.
Det hålls fräscht i huvudet. Ofta är projektgruppen och teamet inte lika intresserade ofta av allt det här som vi förändringsledare är, vi som har de här ramverkenmodellerna i huvudet. Vi pratar mycket om att man måste förstå varför man gör nåt. Ofta ser vi att de säger bara vad jag ska göra. Vi vill få alla att förstå vad jag gör på det här sättet så att bli fiktiva. Det ställs rätt stora krav på vår pedagogiska förmåga hela tiden.
Inte bara vad vi ska göra, men varför. Och att kunna förklara det där om och om igen under resan. Vi har sett att det här är ett så viktigt steg. Vi har också gjort en liten lathund som finns att tanka ner på vår webbsida. Just för projektledare som ska jobba med Agila Team. Vi kan lägga länken i anteckningen till avsnittet.
Jättebra. –Den är gratis. –Det är den. Som så mycket på vår webbsida, där finns det massa bra material. Fler konkreta exempel, hur ni har lyckats integrera agila metoder i traditionella projektstrukturer utan att kompromissa med kärnvärldernas, men det finns ju metodikerna. Ja, men det är intressant. Det kanske inte alltid känns naturligt heller när man får den här kombinationen. Det kommer…
Men vi kanske inte behöver göra en så stort väsen av det här. Jag tror, jag talar till, baka till Natalie, vi behöver vara pedagoger, i kunskap ligger repetition och tid. Men jag tänker ofta att ansvaret ligger på den agila skolan, eftersom man är the new kid in the black. Då är det viktigt att hitta till traditionens takt i en verksamhet. Den mer traditionella metoden har funnits där i ett 50-hundratal år, säkert, ute hos kund. Då är det viktigt att vi hittar den takten och sen att vi kommer med våra bidrag.
Om traditionens takt är 12 månader, månadskalender, budget, processer, hierarki, etc. Då får vi hitta till det. Då kanske vi kan föreslå exempelvis en 30-dagers cykel. En sprint på 30 dagar är rätt lång för många, men det passar rätt väl in i den 12-månaderskalendern. Vi kanske kan föreslå att styrgruppen utser, som Martin sa tidigare, en person som är lead person, det vill säga en produktägare, att delta i den här förändringen mera regelbundet. Då bjuder vi in den traditionella hierarkin till lite mer av en lättrörlig iterativ metod.
Utan att vi ställer krav på det ena eller det andra. Så det gäller att hitta den traditionella takten och föreslå lämpliga anpassningar till den takten. Som inte slår sönder det men snarare hakar på. Idit är, som antyddes tidigare, att inte ställa krav på nomenklatur. Vi väljer den nomenklaturen som passar kunden. Det måste inte heta sprint, det kan heta en cykel.
Det måste inte heta agile, det kan heta lättrörligt. Eller vad som nu passar. Så att vi inte bygger de språkbarriärer som du pratade om tidigare. Det är också ett jättebra sätt. Vi brukar prata ofta om att vara agnostiska och plocka russinen ur kakan ur båda ramverken eller modellerna. Ta bort de här regida ramarna runt båda ramverken.
Nåt som kanske också är lite förvånande är att en sak som jag sett mycket är att man blir tvungen att förklara att det finns en schism mellan projekt och agilt. För det är inte alla helt överens om. Antingen för att man är blind i sitt eget, i sin egen metodik och tycker att här har vi hittat sanningen vägen i livet. Eller så att man bara inte tänker på att det finns en problematik i samarbetet utan det verkar bara gå trögt eller det är så himla jobbigt att jobba tillsammans bara. Om man på något vis lyckas hitta en sjukdomsinsikt att det är svårkombinerat där.
Vi behöver hitta ett sätt att ta oss förbi den. Vad härligt! Då har vi en problemdefinition. Och ett problem kan man lösa. Att bara inse att det finns någonting som skaver, om man ska vara bokstavstrogen i sina respektive metodiker, det är ett stort steg framåt. Så om jag ger exempel på två situationer då.
Det ena är att vi behöver en snabb respons på marknadsförändringar. Men projektplanen, den är ju redan fast. Och den andra är att vi får ett lagkrav som måste vara infört till ett specifikt datum. Medan Magila-teamen säger att vi kommer jobba på. Vad säger ni? Hur gör man?
Spontant så tänker jag just den här marknadsförändring. Vi kräver en snabb respons från projekthållet. Steg ett förstå förändringen. Steg två förstå hur det påverkar lösningen man behöver göra. informera till de som ska flatta besluten, ofta styrgruppen, för projekt. Om ska vi göra det här för att passa marknadsförändringen så måste vi exkludera x, y, z. Det påverkar projektet på det här sättet och effekterna på det här sättet.
Och sen få hjälp med att göra den prioriteringen. För ofta är det inte det man gör egenmäktigt som projektledare, utan där har man sin styrgrupp att buta sig mot. Så det behöver inte vara mer komplext än så egentligen. Ja lagkravsbiten så hade jag ett långt uppdrag på en i en större organisation som hade inte löst den men de hade en ganska pragmatisk lösning och de satte helt enkelt som någon form av strategisk prioritering. Man hade tydliga att lagkrav trumfar allt. Det får hända vad som helst.
Lagkrav är någonting vi följer. Punkt slut. och som Prio 2 hade de så här, men lights on, ingenting vi gör får sabba det vi redan har. Sen kom på plats tre, så här, nyutveckling, förflyttning, sånt där. Men det hjälpte ju produktägare och projektledarna för all del att slippa en del av det här chasset, för att det fanns ett dekret som sa att lagkrav, det prioriterar vi, punkt. Så det tycker jag är en ganska smidig lösning, att man liksom faktiskt Eskalerade redan innan genom att inte eskalerar utan det finns Det finns ett direktiv där redan Så den typen av generell super överbryggande Prioritering tycker jag är ett ganska smidigt En smidig väg framåt Jag tycker att det är lite spännande med lagkrav eller ibland får vi höra i IT-sammanhang Säkerhet, säkerhet kräver att vi gör de här saker Precis som Martin säger, de är fantastiska prioriteringsknivar att ta fram och säga ok men nu måste vi, hur viktigt är det här?
Jag har också råkat ut för lagkrav som egentligen spelas mer som en osann trumpkort för att få vad man vill istället för att det verkligen är avgörande. Så jag brukar skämtsamt säga att följa lagen är även upp för debatt. Det blir ju konflikter mellan projektets leveransmål och agila värderingar. –Är det verkligen så olika? –Exakt så. Är det verkligen så olika, egentligen? Här behöver vi också lite grann… Jag vill återkoppla till det som har sagt tidigare.
Vi behöver utbilda, särskilt från Agiltal, Being the New Kid on the Block– –vad det är vi vill. Det är faktiskt i slutändan samma sak. Ett projekt vill tillfredsställa en kund, en beställare, någon. Ett agilt team vill också tillfredsställa en kund, en beställare, någon. Så egentligen behöver det inte vara så olika. Om vi översätter leveransmål till det mer hypade definition of done och ser projektet som ett stort arbete som behöver brytas ner i små bitar så går det inte mycket på tvärs med agila värderingar.
Det är det här med deadlines som kan sabba lite, men det behöver inte sabba så mycket som man tror. Det hänger förstås mycket också på projektets och vår vilja som Agile Team och möjlighet att tillsammans definiera och bryta ner arbete i mindre bitar. För det är där tricket ligger. Vi vill ha det i cykelstora chanx och projektet vill ha det i en jättestor klump. Det är lite det det kommer till i slutändan. Hur vi tar oss till målet.
Men målet är detsamma. Sen är det också viktigt att ingen av metodikerna är målet i sig. Agila värderingar eller en strukturerad projektmetodik ska hjälpa oss att uppnå målet. Det är det som är syftet. Om vi ska genomföra nånting och agila metoder konstaterar att inte hjälper oss behöver det hanteras. Vi kanske inte behöver jobba agilt.
I vissa fall är det inte agilt någon silverbullet. Eller det är aldrig en silverbullet. Men i vissa fall är det inte en silverbullet, utan snarare nånting som sabbar. Beroende på om det är ett projektteam som ska genomföra nånting eller om man behöver utföra muskeln i en agil organisation så behöver man hantera det på lite olika sätt. Men jag tror inte man ska dramatisera det mer än vad som behövs. För i slutändan vill vi samma sak.
I slutändan jobbar alla mot målet, också människor, och ser till att bygga på människorna och få dem att vilja nå det här målet. –Vill jag flika in? –Snyggt. Annars är det lätt att om det är ett agit-team som har drift, lights on-arbetet, som nämnde Martin, nyutveckling, att de har sitt hjärta i det, Då kommer vi från projekthållet och ska försöka samarbeta mot ett nytt mål, en ny funktion som de i slutändan ska hjälpa till att drifta och förvalta. De måste också känna det här i hjärtat, att det är det här vi ska göra, det är det här vi vill göra. Annars kommer det inte bli bra ändå, tycker jag.
Kan ni ge exempel på hur ni har övervunnit motstånd inom organisationer mot det ena eller andra sättet att jobba? Kanske en av de största motståndskrafter är just att komma igång. Det kan vara bra för oss som förändringsagenter att komma in och bidra med lite energi. noterat. Men nu ska det hända någonting här och vi kanske inte behöver göra den här förändringen större än vad den behöver vara där traditionella metoder dominerar. Låt oss fokusera på del projekt. Det kan vara lite ofarligt där det saknas bra involvering från verksamheten där vi inte har utsett en så kallad produktägare men smyg involvera folk folk genom att ta dem som gissland på fika.
Du, jag har tre frågor. Kan jag få svar på de här frågorna? Synka teamet med projektet om Agila-teamet inte är i synk med projektets planering. Involvera då båda i varandras olika möten, ceremonier. Planering sker på båda sidor. Se till att man är bekant varandras planering.
Och sen, vi har redan pratat om att vara pedagogisk, att inte välja fel nomenklatur, etc. Saker att tänka brygga över motstånd. Låt oss göra det här lite lättare. Ett vanligt missförstånd är väl lite grann att om man kallar projektet fragilt- så får det automatiskt ut alla fördelar från det agila arbetssättet. Och då… Agile in name only på något vis.
Och… Det är lite att… Som den religiösa schismen vi pratade om tidigare så blir det lite grann att man gärna förminskar den andra sidan och att om vi bara döper saker till sprintar och jobbar lite cykliskt så är vi agila. Det är en missuppfattning och Jag tror att väldigt få som har tagit det pyttelilla steget tycker att det här var ett jättebra steg. Det kräver en lite större uppoffring från bägge sidor. Men den stora uppoffringen heter kommunikation.
Vi är tvungna att prata med varandra på ett sätt som vi inte har behövt göra förut. Jag tror att det är ett av de vanligaste missförståndarna. Det går att lösa med någon form av annan metodik än att bara… Ja, motstånd och missförstånd, det grundar sig lite att man i det här fallet kanske inte har full insikt och insyn i vad de här ramverken ger för någonting. Så jag kommer också tillbaka lite till utbildning, kommunikation, gemensamma mål och se till att ha gemensamma värderingar. Det är ju någonstans grunden.
Det slår mig, Mattias, när du ställer frågan om missförstånd istället för motstånd. Det kanske är ett mer konstruktivt sätt att se på motstånd. Det är snarare ett missförstånd eftersom som Natalie säger vi vill ju åstadkomma samma sak. Vi vill uppnå det här målet. Då kommer vi tillbaka till om vi ska bearbeta missförstånd. Jag säger ordet igen, pedagogik.
En av våra viktigaste roller är att vara en lärare i den här förändringen. Är det givet vilken metodika använder i vilka fall? Jag skulle säga nej, eller baserat på erfarenhet. Det jag ser ute i branschen mycket är att man använder sig av agilt till exempel, där man kanske inte behöver använda agilt. Agila metodiker är främst bra när man befinner sig i en snabbrörlig, en volatil, komplex värld med många typer av kunder, många typer av konkurrenter. Man måste kunna agera snabbt.
I många delar av verksamheter så är det ganska mycket repetitivt arbete. Man gör saker man har gjort förut. Man vet ungefär hur lång tid de tar. Därmed är det inte sagt att de inte är viktiga eller coola eller bra. Men i sådana lägen så blir det här experimentiella och utforskande arbetssättet agila metoder, förespråkar, kanske mer tidsödande än effektivt. Så att det är lätt att man hamnar i att agilt alltid är bra.
Nej, det är det inte. Det är inte alltid bra. Vi gjorde en genomlysning hos en kund på deras 140 mest använda system i deras systemflora och vi konstaterade att sju av dem skulle må bra av att använda ett agilt arbetssätt. ungefär 40 av dem skulle må bra av att ha koll på sina flöden inom en form av lintänk. Och resten, hur som helst, vattenfall, projektmetodik, you name it, det spelar ingen roll. Därför att det är sådana systemen uppbyggde på ett sådant sätt att det inte spelar någon större roll. De är inte kundnära, vissa fall fanns inte ens utvecklingen internt.
Det blev en bisbesvikelse hos dem som vi bedömde att du kan fortsätta jobba vattenfall, det går bra. Nej, jag vill jobba agilt. Fast då får du byta system i så fall. För att det gör inte så mycket skillnad om du jobbar agilt. Tvärtom. Kan du ge djupare exempel på vad som avgjordes i en eller andra?
I det här fallet så var det ju… att kundnära system som webben till exempel och e-handel ligger ju väldigt bra till för kandidater att vara agila för där finns det där finns det nära tillgång till slutkunder, det finns en teknik som gör att det är snabb uppdaterat det finns konkurrenter som man måste kunna hantera på ett eller annat sätt så att webben, e-handel, delar av marknad hamnade också i någon form av, där behöver vi vara explorativa för där händer det mycket saker. Mycket av det som ligger på back-end sidan däremot, de ska vara så stabilare det bara går. Och det är väldigt lite innovation som sker där, utan stabilitet är liksom det allra viktigaste och då då är det nästan enklare att köra kanske inte rakt av projekt eller vattenfall, men åtminstone någon form av kan man för att strukturera upp sin planering av förändringarna men inte så mycket mer än så. Man behöver inte vara tokagila och söka feedback i allt.
Hur ser ni på det här med det agila att nu visar jag på mina fördomar att kanske en marknadsavdelning vill jobba agilt för att vara lättrörliga men egentligen är det för att de inte vill planera. Oerhört. Det finns så många fördomar i metoder. En av de sakerna är att vi är agila för att vi inte vill planera. Eller för att vi inte kan planera en lång horisont. Jag brukar komma tillbaka till att låta oss inte glömma bort vad mycket disciplin som finns i en agil cykel.
Det må vara en kortare planeringshorisont på ett sätt, men time boxing och tydlighet blir desto viktigare. Så när man jobbar med den där marknadsavdelningen så är man tillbaka till lite av att Fine, let’s do it. Och så kommer man igång och skolar dem i den där timeboxen och att kunna åtminstone se tre veckor framåt eller vad vi nu väljer för cykellängd och att hålla de tre veckorna och då börjar man slipa på en förändringsförmåga Med hjälp av korta cykler. Visionen, roadmapen, planen brukar växa fram om de svarar på utmaningen. Man behöver kanske inte detaljplanera precis allting, men att ha ett övergripande kontroll på vad det är man ska få ut.
Sen kan man göra själva detaljplaneringen mer i cykler. Det hörde oss en kund för ganska många år sen, men så här. Sen var vi planerar mycket nu för tiden, när man hade gått över till nån form av agilt arbetssätt. Kom från ledningen. Så helt plötsligt var det en massa planeringsmöten var tredje vecka. Det var de inte alls förberedda på, utan det var mer…
Vadå, vi planerar väl mindre när vi är agila? Nej. Vi planerar oftare men mindre. Jag får koppla tillbaka till just det du säger, Martin, och din tidigare fråga, Mattias, om att välja det ena eller andra. Många gånger har man inte lyxen att kunna välja metod, men väldigt många gånger, tyvärr, så gör man varken det ena eller andra. Så att bara implementera en modell eller metod eller ett ramverk, Det skulle höja produktiviteten och samhörigheten enormt.
Det är nånting som jag ser ofta. Man gör varken eller. Man gör projekt där… Greta, du kan lita om det här. Kan inte du bara driva det här? Sätt ihop nånting.
Och har inte verktygen i sin egen verktygslåda att faktiskt realisera ett projekt- efter konstens alla regler, eller att vara agil? Hur jobbar ni med beroenden? I traditionell projektledning så jobbar jag med arbetsstrukturer, jag bryter ner, jag gör en nätplan och liknande. Medan när jag jobbar agilt så kanske jag är på Epix, jag kanske jobbar med Features. Och så börjar jag titta in i framtiden så ser jag att det jag bygger idag, det har ett beroende någonting långt in i framtiden. Men det ska vi inte titta på än.
Hur tänker ni kring det här och hur jobbar ni med sådana beroenden? Där har jag ett exempel på ett uppdrag som jag hade när jag klev in mitt i ett projekt som hade drivits lite med vänsterhanden av en individ som inte hade tid egentligen. Och klev in där och såg att det inte finns en projektplan, man har inte definierat vad det är man ska göra. Det var, själva projektet bestod av ett företag som hade köpt upp. och skulle nu integreras i alla företagets olika fler. och det var orderflöden. Alla system skulle den integreras i för att uppleva och få stordriftsfördelarna.
Men det första jag fick göra var att titta på vilka involverade. Då såg jag att det var olika personer i organisationen som satt i silos. Det fanns ett agilt team som höll på med webbsidan för den här kunden. De skulle integreras. Det allra första jag fick göra var, vad är det vi gör för någonting? Vart är ni respektive del?
De här människorna hade knappt pratat med varandra ens. Det första var att göra utbildning i, så här kommer vi försöka driva projektet fram. Funkar det för er? Mikroutbildning var en VBS, så vi gjorde gemensamma övningar. Nu bryter vi ner arbetet i er respektive del. Skriv mer.
Vad är det för nånting? En breakdown structure. Vi för upp allting i en gemensam miro-tavla eller på en whitesport-tavla. För att illustrera beroenden som du pratade om, så gjorde vi en logisk nätplan. Då var ingen som hade gjort det förut. Då fick man verkligen se hur saker hängde ihop.
Man kunde också göra en plan och bryta ner det i månadsplaneringar som skulle komma framöver. Man skulle se vad man behövde göra för att kunna realisera nästa steg. Då kunde man plocka i den här logiska nätplanen kanske nånting längst fram och nånting som var längre bak i den. fick man faktiskt ta och göra under samma iteration. För vi gjorde något typ av hybridprojekt då, eftersom det var så ostrukturerat och man inte hade jobbat med något av de här olika modellerna. Så då var en rätt lyckad väg framåt i det. Jag tänker utifrån beroendepunkten lite grann, som du sa, Mattias, så Agila-teamer väl inte titta så långt framåt, så de vill inte ens prata om vad som händer om ett halvår.
Det är någonting som egentligen inte tvingas in i någon form av agil metodik. Att man inte får planera framåt. Man pratar väldigt gärna om roadmaps. Man pratar väldigt gärna om att ha koll på vägen mot visionen. Så jag tänker beroenden och sånt där. Och jobbar man i en struktur av epics och features så kan man mycket väl se till att de här beroendena finns dokumenterade någonstans.
För att man ska kunna ta dem med, så här, hörrni, vi kommer att ha ett beroende till er om ett halvår. Ni behöver inte göra något nu, men bara så att ni vet. Ni behöver en liten heads-up på att vi kommer att komma. Vill ni veta vad beroendet är, kan vi inte ta en kaffe och prata om det. Så kan ni bara så, så kan ni sova lugnt på nätterna tills vi kommer. Men att bara ha det på kartan och på radarn, tror jag, är otroligt viktigt.
Och de agila team som vägrar att ta emot sådana information, är, är, kommer att få problem. utan tvekan för sånt uppstår. Jag brukar alltid ställa frågan om man har gjort något misstag som någon annan kan lära sig av. Har ni gjort några misstag som ni skulle vilja berätta om och som någon annan kan lära sig någonting av? Jag tänker på att min roll som förändringsagent är att komma med en erfarenhet och även kunskaper, låt säga metod, kring förändring. Och det händer även mig. Att jag sugs in i en kultur, en tradition, ett sätt att vara ute i en given kontext.
Och att jag lite grann tappar bort mig och mitt bidrag. Så det är inte fel som förändringsagent tycker jag att gå tillbaka till vissa strukturella saker. Att vara lite mer av den PT som ropar ut vad som göras. Istället för att åka med dem, men det är tungt, det är svårt, det är komplext. Ja, precis. Jag vill haka på det där lite grann.
Jag tror att tydligheten är lätt att tappa bort. Säkert när man sitter som konsult i någon form av uppdrag i en organisation. Det är lätt att fastna, som Jeff sa, i företagets kultur och sätt att prata och sätt att röra sig och företagets momentum. Medan man behöver kunna vara tydlig och vara lite mer jobbig som förändringsledare. Jag känner mig lite nöjd när jag får frågan, men ska vi göra det här igen? Vi hade ju ett sånt här möte för ett tag sedan.
Ja, det ska vi. Tiss ni kan det. Jag kan väl jacka in lite i temat. Någonting som jag nämnde tidigare var ju det här att det är viktigt och tar tjuren vid hornen på en gång. Ofta så kliver jag in i projekt som kommer tillbaka. konsult mitt i ett projekt och att istället för att flyta med och försöka göra bäst av det som det som finns är att jag har precis som som nämnde tar suren vid hornen ser till att prata om arbetsmetoder med modell. Även om det känns ologiskt att göra det mitt i så kommer det hjälpa en oerhört mycket.
Ja det misstaget har jag gjort många gånger att tro att Det går att styra upp det här och bara flyta med som man har gjort och jobbat tidigare. Det funkar ofta inte bra. Det ger också ett tillfälle att lära känna alla och hur man tycker och tänker. Att få ut någonting bra av projektet, till och med i samarbete och arbetsmodeller, det brukar vara väldigt uppskattat. Ett misstag som är lätt att göra är också att gå in och vara lite för peppig i förändringen. Det är inte alltid att organisationen är väldigt, väldigt mottaglig för att nu ska det förändras någonting.
Och så går man in i sig, hej, nu ska vi göra jätteroliga, agila saker. Och så får man alla emot sig. Det har jag varit med om och det är jättetråkigt. Så att, så här, kommunicera med folk på deras villkor, det är liksom det som är grejen. Hitta någon kvart och prata med någon om, så här, okej, är ni redo för pepp eller ska jag vara lite pragmatisk och gubbig här? Kan vara väldigt bra att veta innan.
Jag hittar er genom att jag googlade lite och hittade att ni hade en kurs som var att kombinera agilt och projekt. Berätta mer om den. Ja men det här har vi ju sett allihopa hos våra kunder. Vi började spåna lite grann på vad är det för kurser vi borde, vad är det folk behöver utbilda sig i här nu? Och så var vi relativt överens om att alla hade varit med om att det här med kombinationen av agilt och projekt är lite strävt i de flesta organisationer. Det finns mängder av utbildningar i form av agil projektledning eller hybridprojekt.
Men jag tror att det som vår kurs som vi har byggt gör hanterar snarare att försöka få dem att sammexistera och inte slå ihop. Så att det inte bara blir en blandning av de olika metodikerna. För då tar man spetsen från bägge två. Vi låter båda metodikerna finnas kvar. Vi erkänner dem bägge två som existerande och bra på sitt sätt. Och hur vi försöker få dem att samexistera utan att bygga en gemensam metodik.
Det är själva syften. Vad behöver man ha för förkunskaper för att gå kursen? Måste man vara projektledare eller Scrum Master? Nej, det behöver man inte. I innehållet i kursen är första delen att vi går igenom ett vad och varför och grunderna i respektive projektmetodik och agila arbetssätt. Just för att oavsett vilket håll du kommer ifrån eller från inget håll alls så kommer du att förstå hur den andra sidan tänker och varför.
Så vi utgår ifrån att du inte kan någonting om någonting. Men de flesta av deltagarna kommer ju oftast från ena eller andra hållet. Vi kan lägga en lägg i anteckningarna till den här kursen också. När vi hade kontakt innan så pratade vi om fem konklusioner som man kunde dra över det här. Är det någon som skulle dra de konklusionerna? Jag tycker de var riktigt bra.
Vi har ofta kommit tillbaka till i det här samspelet att det är viktigt att komma ihåg Det finns en samma existens. Vi är inte ute efter det ena eller det andra, men samspelet mellan de här två. Vi tycker att det finns utrymme att jobba i förändring i mindre bitar. Oavsett vad vi kallar de här bitarna för, jobbar vi mot målet i små cykler eller bitar. Nummer tre, låt oss gemensamt utforma våra krav. Det är viktigt att förändringsteamet har samspel med verksamheten.
Om förändringsteamen är fler, det agila teamet och projektteamet– –behöver också se till att kravutformningen är tydlig och gemensam. Nummer fyra, vi tycker att det är okej med planering. Vi är det enda djuret på det här jordkloket som kan nyttja vår framtid som en tillgång. Vi kan titta framåt och planera och nyttja det som en tillgång. Så det är okej att göra det. Vi ska inte ha övertro till planering, men vi ska nyttja den superkraften som är planering.
Och vi är tillbaka till att involvera verksamheten i det vi gör. Resultatet blir bäst när vi har en co-creation eller en samskapelse här- –mellan förändringsteamen och den som tar emot förändringen, förhoppningsvis. Om man skulle vilja få kontakt med er… Efter att ha lyssnat med det här avsnittet, hur gör man då? Enklast är väl att surfa till onboard.se. O-N-B-I-R-D.se.
Där har vi en hel del information som Nathalie nämnde tidigare. Och lite kontaktuppgifter för att nå var och en av oss. Då lägger vi länk till det i anteckningarna. Idag har vi fått höra att traditionell projektledning och agilt arbetssätt Det kan samexistera. Ibland lite agnostiskt, ibland lite pragmatiskt. Men det kan samexistera.
Det är härligt att höra. Stort tack, Jeffrey, Natalie och Martin- för att ni kunde ta er tid att vara med i dagens Projektledarpod. Jättekul. Tack, Mattias. 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å lyssnare, snabbelag, Projektledarpodden.se eller vid det sociala nätverk du föredrar.