Fem misstag ni INTE behöver göra vid agil transformation

SAFe | 21 juni, 2018 | Håkan Lövén

Fem misstag ni INTE behöver göra vid agil transformation

Jag får ofta äran att dela med mig av mina erfarenheter från agil transformation, alltså där man tar det agila arbetet ut till en större del av organisationen. Jag kommer ofta och gärna in på de organisationspsykologiska utmaningarna, som jag tycker är viktigast att förstå och därmed kunna hantera. Är du nyfiken på dessa, kolla vår screencast här!

Därtill finns det ett antal mer praktiska fällor som man lätt hamnar i och som man kan undvika om man känner till dem.

#1: Att jobba mer med planen än med människorna

Agil transformation handlar i första hand om att förändra människors arbetssätt (läs: beteende) och i andra hand om förändrad organisationsstruktur. Ändå fastnar man ofta i planering, modeller och metoder snarare om varför människor ska jobba annorlunda och vad man vill uppnå. Ofta har organisationen kompetenta förändringsledare som är bra på att få med sig medarbetarna i förändring, men dessa involveras alldeles för sällan. Kommentarer som ”nu får de ju som de vill” eller ”de har ju fått läsa boken” kan vara tecken på just detta.

Lösning: Tillämpa agil förändringsledning i fem steg: planera, informera, justera, träna och implementera. Steg 3 – 5 sker aggregerat i iterationer.

#2: Att slarva med syfte och motivation

En av flera önskvärda effekter av en agil transformation är ökad integration mellan olika funktioner i organisationen i syfte att underlätta och effektivisera samarbeten. Om man utan att ta hänsyn till olika funktioners förutsättningar och behov tvingar in alla i en allomfattande agil kostym, kan effekten snarare bli kontraproduktiv.

Jag brukar illustrera detta genom att hålla två knutna nävar en bit ifrån varandra (isolerade funktioner med samarbetsmässigt långt avstånd) för att sedan slå ihop dem, knogar mot knogar (isolerade funktioner med samarbetsmässigt kort avstånd). Det är här många hamnar, fast man egentligen vill integrera funktionerna, vilket jag illustrerar genom att öppna händerna och fläta ihop fingrarna.

Lösning: Utifrån funktionens (läs: människors) motivationsfaktorer och förutsättningar visa hur det nya arbetssättet gagnar dem. Först då kommer den önskade integrationen att ske.

#3: Att likställa Scrum med agilt arbetssätt

Scrum har fått stor genomslagskraft inom agil systemutveckling i Sverige och har därmed fått en tydlig kvalitetsstämpel. Men det agila arbetssättet är så mycket mer än Scrum. Jag vet att inte alla håller med mig, men jag menar att Scrum hör hemma i en miljö för utveckling. Har man en väl fungerande agil utveckling utifrån Scrum, ska man givetvis ta med sig erfarenheter när man skalar upp det agila arbetssättet. Men att köra copy-paste är mer eller mindre dömt att misslyckas.

Lösning: Förstå och utgå från det allmänt agila snarare än det Scrum-specifika när du skalar upp ditt agila arbetssätt.

#4: Allt eller inget

Det agila arbetssättet passar dom flesta. Alla behöver dock inte jobba agilt för att man ska få ut nyttan av arbetssättet i en hel organisation. Det bör finnas grader i agil transformation. Jag, och många med mig, har sett hur ett slaviskt införande av agilt arbetssätt kostat mer än det smakat. Ta en klassisk ekonomiavdelning, som med stor sannolikhet arbetar plandrivet. Måste de arbeta agilt för att kunna stötta en applikation eller produkt som utvecklas agilt? Nej. Däremot bör de ha en förståelse för det agila arbetssättet, på samma sätt som det agila teamen bör ha en förståelse för sina plandrivna kollegor. Det här handlar inte om agilt, utan om effektivt samarbete mellan olika funktioner i organisationen.

Lösning: Att få alla funktioner att förstå varandras arbetssätt och utifrån det utveckla en effektiv form för samarbete.

#5: Att inte ta tillvara på agila gränsytor

När man genomför en förändring bör man passa på att ta tillvara på alla möjligheter att effektivisera samarbetet med övrig organisation. Detta kan göras genom att tillsätta rätt agila roller. I agila utvecklingsteam i allmänhet, Scrum-team i synnerhet, finns en så kallad produktägare. Dennes primära roll är att vara gränssnittet mellan utvecklingsteam och beställaren/kunden. Produktägaren står med en fot i varje ”läger”, vilket gör rollen utmanande, men också så oerhört värdefull för alla parter.

Lösning: Tillsätt agila roller och funktioner som underlättar integrationen med den övriga verksamheten.

 

Vill du veta mer om hur man skalar upp det agila arbetssättet? Välkommen på våra frukostseminarier!

Är du i Stockholm är du varmt välkommen den 23 augusti:

Frukostseminarium i Stockholm
Snabbintroduktion till SAFe®
23 augusti kl. 08-10.
Ta mig till eventet >>

Är du i Malmö är du varmt välkommen den 13 september:

Frukostseminarium i Malmö
Så lyckas du med SAFe® – erfarenheter och lärdomar
13 september kl. 07.30-09.00.
Ta mig till eventet >>


Visa alla blogginlägg

Senaste blogginläggen