Hur är det att jobba enligt SAFe och med ett agilt arbetssätt?

Vilka roller har ni i nuvarande konsultuppdrag?

Fredrik: Jag arbetar i dag som Product Owner (PO) för flertalet produkter inom "Cloud Infrastructure" för den uppkopplade bilen på Volvo Car Group. Det området innefattar digitala produkter och plattformar och namnges Consumer and Enterprise Digital (CED). Inom CED är jag verksam inom produktarean "Own", vars huvuduppgift är att stödja kunderna att hantera sin relation till sin bil och dess uppkopplade tjänster samt kundens relation med Volvo.

Hans-Peter: Jag har hos min kund Volvo Cars haft SAFe rollerna Scrum Master (ScM) och Product Owner (PO). Detta inom en SAFe ART vilken utvecklar, driftar och supportar applikationer som stödjer el och mjukvaruutvecklingen för Volvos Cars bilplattformar.

Vilka är fördelarna eller den största vinsten med att gå över från en mer vattenfallsorienterad approach till ett agilt arbetssätt i stora och komplexa organisationer?

Fredrik: En stor fördel är att vi har sk. PI-planering (Program Increment), som är en "big room face-to-face planning" var 12:e vecka där vi planerar tillsammans med alla andra team i vårt Agile Release Train (ART). I dag är det mellan 15-20 team i vår ART. Utöver detta synkroniseras arbetet med ytterligare ART´s som är beroende av de produkter jag och andra med mig ansvarar för. Förhoppningen och målet är att samtliga inblandade får en gemensam bild och plan för när respektive utveckling av dennes produkt behöver ske för att få en sammanhängande tjänst som fungerar End to End (E2E). Ett konkret exempel skulle kunna vara då jag vill dela min bil med en vän - men via en digital nyckel i stället för en fysisk. Den digitala nyckeln skickas på ett säkert sätt till till min väns mobiltelefon som i sin tur ger rättighet att låsa upp och köra bilen.

Hans-Peter: Den främsta vinsten är att tiden från idé till färdig produkt i händerna på slutanvändarna kortas. Detta då man skiftar fokus från projekt till produkt minskar man antalet tidskrävande faser/gater som finns i traditionella projekt där man jobbar med en mer vattenfallsorienterad approach. Med det agila arbetssättet fokuserar man på att kontinuerligt kunna leverera värde till slutanvändaren. Lyckas man med att jobba bort flaskhalsar som hindrar kontinuerlig leverans, ökar både hastighet och kvalitet i leveranserna.

Vilket ser ni är den största utmaningen med att implementera det agila arbetssättet fullt ut? Några vanliga fallgropar?

Fredrik: Att implementera SAFe är inget man gör i en handvändning. Enl. den utbildning jag själv genomförde för Product Manager/Product Owner (PM/PO) i SAFe-metodiken krävs det ett antal PI´s för att få "snurr" på det hela. Jag har deltagit på 4 sådana PI´s (3 mån per PI) och det blir bättre och bättre, men att få riktigt flyt i denna process tar enligt min uppfattning 1-3 år beroende på organisation och det är viktigt att ha uthållighet i den processen. Sedan är det en hel del "ceremonier" i SAFe såsom Daily Standup, Iteration planing, Iteration review, Scrum of Scrums, Inspect & Adapt m.m.

Det jag har noterat runt detta är att det kan upplevas som att vissa delar tar för mycket tid från själva utvecklingen, samtidigt som det såklart är viktigt. En annan del som jag uppfattar det finns utmaningar med är att få alla att komma till demos, vilka sker varannan vecka fredag förmiddag. Där är tanken att alla team skall visa och demonstrera det de utvecklat under den innevarande iterationen (sprinten), dels för Business Owners och PM/PO´s men också för andra team mfl. Såväl kvalitén som deltagandet på dessa demos är inte uppe på den nivån som jag tror behövs för att det skall ge tillräcklig effekt än, men som jag sa tidigare så kräver det kulturförändring, tid, bra coachning från agila ledare samt ett något annorlunda "mindset" mot utveckling enl. vattenfallsmodell.

Det handlar heller inte enbart om att anamma ett agilt arbetssätt, viket i sig kräver rätt människor på rätt plats, utan även att se till att det som kallas DevOps skall fungera, dvs. att när produkterna sätts i produktion så är det teamen som skall hantera de ev. incidenter/fel som deras produkt genererar ("Eat you own dog food", lite förenklat). Det kan nog till en början ta mer tid tid från teamen, vilket i sin tur kan komma att ge mindre tid för att utveckla ny funktionalitet på. I SAFe tycker jag att denna DevOps-del är något skral och har potential till förbättring. Att arbeta med att få dessa processer på plats är något jag också påbörjat att arbeta med parallellt som PO, även om det kanske inte riktigt är en PO´s ansvar enligt SAFe.

Hans-Peter: Största utmaningen skulle jag vilja säga är den kultur förändring som måste till. Organisationen måste anamma ett agilt mindset för att kunna lyckas. Hur bra agila metoder man än använder måste alla vara med på tåget och engagera sig i den ständiga förändringsprocess det innebär. Det är tyvärr mycket lättare att fortsätta jobba som man alltid gjort istället för att våga förändras. Sedan skall man inte förminska den synkningsproblematik som finns när man skalar upp det agila arbetssättet genom att t.ex. använda sig av SAFe ramverket. Jobbar vi alla tillsammans mot samma mål?

Mer information om SAFe: https://www.scaledagileframework.com/