Att lyckas med agila transformation har visat sig vara en stor utmaning för organisationer och team. Det är en stor förändring och det gäller att inse att man står inför ett långt och strukturerat arbete framöver och att det inte är något som sker över en månad. För att hjälpa er på vägen har jag tagit fram fem tips där jag sett att organisationer som jobbar med dessa bitar får väldigt stor nytta av dem och gör att de lyckas med sin resa att bli agila.
Jag hoppas att de ska vara till hjälp för er också!
En sak som de flesta agila metoder misslyckas med är att gå på djupet kring hur viktig kulturen och beteendet från ledarna i bolaget är – i synnerhet hos stora bolag med många nivåer av hierarki där flera olika organisationer och verksamheter ska samarbeta för att tillsammans skapa både affärsnytta och kundnytta. Fel attityd från ledare kan förstöra en organisation snabbt, hur välfungerande eller välmående den än är. Det agila ledarskapet lägger mycket stor vikt vid att leda genom exempel och att agera som möjliggörare som eliminerar hinder för medarbetare, team och verksamheten. Till skillnad från traditionellt chefskap där man ofta fokuserar på att bestämma, kontrollera och dominera sina ”undersåtar”.
Att släppa chefsrollen och den typen av leveransansvar som kommer med den och istället bemäktiga sina medarbetare att kunna göra sitt yttersta och bästa genom att leda och coacha är en stor utmaning för många som endast levt i den mer traditionella kulturen. I vissa fall kan det räcka med att genomgå ledarutbildningar som baseras sig på modernt ledarskap men ibland kan man tyvärr behöva byta ut ledare som saknar rätt mindset och som trots upprepade försök att coacha och träna inte kan släppa ”command & control”-attityden. Det är sällan folk hamnar där av illvilja eller uppsåt men vi måste inse att personligheter, kulturer och attityder är svåra att förändra och ibland finns inte tillräckligt starka incitament hos individen att göra det enormt utmanande arbetet som krävs för att byta inställning.
Om ledarskapet lägger fokus på att medarbetarna kan göra sitt bästa och har rätt förutsättningar för att göra det, slipper ledarna lägga tid på att ha kontroll och kan nöja sig med att bara ha koll – inte nödvändigtvis på produkten, utan mer på teamet, deras välmående och deras framsteg. Våga delegera teknik- och produktansvar neråt i hierarkierna! Sluta vara chefer och börja agera som ledare!
Kommunikation är en nyckel för att alla relationer ska fungera och arbetsplatsen är inget undantag. Jag brukar säga att en överväldigande majoritet av de problem vi möter i det dagliga arbetet inom produktutveckling (eller vilken verksamhet som helst för den delen) är kommunikationsproblem. Brist på förståelse, missuppfattningar, otydlighet, dåliga krav, avsaknad av samarbeten etcetera. Symptomen är många och de flesta av dem grundar sig i att vi antingen har kommunicerat ineffektivt eller inte kommunicerat alls. För att förbättra kommunikationen finns ett antal metoder som kan vara värdefulla att använda och ett tips är att prova dig fram för att hitta rätt mix som passar din organisation.
Det är viktigt att alla förstår alla begrepp och tolkar dem på samma sätt när ni använder olika uttryck. Se till att det är lätt att hitta era definitioner på begreppen och att de verkligen sprids och förankras. Dessutom är det viktigt att man har rätt krav på produkten eller tjänsten och att detta ligger på en ”good enough”-nivå, alltså en nivå som är lagom för teamet, så det inte blir för otydligt eller för djupgående. Involvera rätt personer och intressenter tidigt i kravställningen och visualisera er dokumentation så mycket ni kan, det blir lättare att hålla en bild i huvudet än ett textdokument.
Kommunikation sker inte av sig själv, det behöver faciliteras. Genom att välja arbetsmetoder som främjar kommunikation mellan olika roller blir risken mindre att missuppfattningar sker. En metod jag förespråkar starkt är Acceptanstestdriven utveckling som går ut på att kravskrivandet sker i samarbete mellan roller som kravare, designers, utvecklare och testare vilket gör att alla är med från början och får samma bild av behovet. Tillsammans skapar man både krav (behovet) och acceptanskriterier (det önskade beteendet från produkten). Har ni svårt att enas om hur ni ska jobba, både inom team eller mellan team eller organisationer, sätt upp tydliga Definitions of Ready (vad ska vara gjort när vi tar emot en uppgift) och Definitions of Done (vad ska vara gjort när vi lämnar vidare en uppgift). Dessa går att tillämpa på olika nivåer inom kraven, mellan verksamheter och mellan olika roller/ansvar inom team.
”One size does not fit all” - ett av mina ständiga mantran inom agilt. Scrum och SAFe passar inte alla organisationer, försök inte tvinga in det. Det är bättre att anpassa en metod till organisationen eller produkten genom att titta på vilka byggstenar som finns i olika metoder och plocka russinen ur kakan. Här är det självklart väldigt användbart att ta hjälp av en erfaren agil coach, för det finns många metoder att hålla koll på. Jobbar ni med hårdvara kanske kanban passar bättre än scrum. Jobbar ni inte med regelbundna releaser var tredje-till fjärde vecka kanske en hybridmetod som Scrumban passar bättre. Det är bättre att börja med små steg och införa fler metoder efter hand än att slå på stora SAFe-trumman på en gång och hoppas att allt faller på plats. På så vis får ni även tid att skräddarsy efter era behov, ni hinner prova, justera och förbättra metoderna och även anpassa efter er leveransmöjlighet.
Våga prova på olika metoder, eller rentav bygga egna. Om ni väljer den vägen kan jag även här tipsa om att titta på Definition of Ready och Definition of Done. De skapar en tydlig förståelse för värdekedjan och vilka aktiviteter ni behöver göra för att få saker gjorda och därmed blir det lättare att bygga en process.
Teamen behöver ha rätt storlek för att kunna jobba effektivt. För stora team tenderar att skapa ledtid och för små team blir lätt överbelastade och stressade. Dessutom behövs rätt kompetenser för att kunna leverera med rätt kvalitet utan att bli beroende av externa team, organisationer eller intressenter. Då är det viktigt att alla kompetenser som ingår i teamets leverans finns tillgängliga på daglig bas - allt ifrån krav, användarupplevelse, design, utveckling, test och så vidare behöver finnas tillgängligt. Huruvida alla dessa kompetenser sitter hos olika individer med avgränsade roller eller om man har tvärfunktionella individer som besitter flera av dem är en annan diskussion som är mer situationsberoende.
Det är också viktigt att acceptera att olika team har olika förutsättningar och kan behöva olika verktyg, metoder och roller, även om de sitter i samma organisation och jobbar med liknande arbetsuppgifter. Jämför inte olika team med varandra, exempelvis genom att jämföra velocity/story points mellan teamen (helt godtyckliga och subjektiva siffror). Låt teamen styra sig själva och ge dem mandat att fatta beslut om produkten de levererar och sättet de jobbar på.
De flesta agila ramverk missar att prata om en av de viktigaste aspekterna för att bli agila – nämligen kulturen. Det finns dock undantag: Modern agile pratar mycket om trygghet och kreativ frihet. Transparens är något som bidrar till agilitet och att veta vilka beslut som tas, av vem och i vilket syfte gör att det är lättare att känna sig inkluderad och ha koll på läget, oavsett om det är ledningsbeslut eller tekniska beslut hos olika team. Trygghet gör att folk vågar sticka ut hakan, utmana och ifrågasätta utan att känna att de riskerar negativa konsekvenser. Att man vågar lyfta svåra frågor, ta upp problem och ifrågasätta saker skapar möjligheten att lösa problem, hitta nya vägar och till och med skapa innovationer som ger starka konkurrensfördelar. Det bör också finnas olika typer av skyddsnät för att misslyckas utan för stora konsekvenser, så att man vågar prova nya sätt att lösa problem eller testa nya idéer, både rent tekniskt/produktmässigt och organisatoriskt.
Men kultur är ingen metod, utan det är ett sätt att vara på, ett beteendemönster och ett mindset som behöver genomsyra hela företaget. Det gäller att få med alla organisationer och hela hierarkin på en kulturell förändring för att kunna nå hållbara och mätbara framsteg. Det är den i särklass svåraste aspekten att förändra eftersom det ofta ”sitter i väggarna” men behandlas som något som skrivs på väggarna. Eftersom kultur är oerhört beroende av ledarskapet hänger detta starkt samman med punkt 1 på denna lista och tyvärr är ledningen ofta flaskhalsen i kulturförändringar. Kanske för att ledarskap beror mindre på metodik och mer på individuella faktorer, kanske för att de flesta agila ramverk och metoder pratar väldigt lite om ledarskapet. Det tar tid att förändra en kultur till det bättre men det kan gå väldigt fort att förändra en kultur till det sämre. Därför är det viktigt att alla blir medvetna om hur deras individuella agerande påverkar kulturen och att kartlägga den önskade kulturen samt vilka beteenden som är synonymt med den för att kunna leda kulturförändringen i rätt riktning. Jobbar man ihärdigt med detta, med tålamod, empati och långsiktighet brukar det ofta bli väldigt mycket bättre än förr, så ge inte upp!
Sammanfattningsvis så vill jag att ni ska ta med et att ni ska leda medarbetare, team och verksamheten på rätt sätt - agera som en möjliggörare och skapa förutsättningar för att de ska kunna göra sitt bästa istället för att bestämma och kontrollera dem. Lägg stort fokus på kommunikationen och att alla tolkar de begrepp som används på samma sätt. Tvinga inte in metoder som inte fungerar utan välj rätt metoder som funkar för just er. Sätt ihop team med omsorg, sammansättning och storlek har stor betydelse på prestationen. Och det kanske viktigaste delen för att bli agila - glöm inte kulturen!
I en organisation med flera utvecklingsteam finns en risk att varje team skapar sina egna arbetssätt och kommunikationsvägar, vilket inte är till en fördel. Olika arbetssätt kan skapa missuppfattningar, längre utvecklingstider och sämre kvalitet i leveranserna
Just detta var Cerners problematik och de behövde hjälp med att sätta en gemensam arbetsprocess för hela organisationen. Lösningen blev att tillsätta en Agil Coach som jobbade i samtliga team vilket resulterade i ökad produktkvaliteten, bättre metod för kravdokumentation samt kortare ledtider på utvecklingsärenden. Här kan du läsa om hela caset!