Mitt svar på det har varit lika enkelt som nedslående; inget - vad jag vet. Vilket kan kräva sin förklaring.
Som konsult har jag företrädesvis hjälpt organisationer som påbörjat eller misslyckats med sina förändringsprojekt. Det här gör att jag lärt mig ”bakvägen” hur man lyckas med införande av ett agilt arbetssätt, genom att se vad som inte fungerar, och hur man kan korrigera det. Därför är min förhoppning, att som anställd på Avega Group, hamna i projekt där jag får vara med från början. Men det är en annan historia..
Frågan från min omgivning har då formulerats om; vilka är de vanligaste misstagen i samband med en agil transformation? Mot bättre vetande tänkte jag svara på den frågan, utifrån en topp-5-lista. Jag utelämnar den egentliga ”nummer ett” eftersom jag skrivit ett helt brev om det (se ovan): att odla vilja.
Top-5-listan
Innan vi kör listan vill jag nämna lite om olika typer av agil transformation. Grovt sett finns det två varianter med motsvarande källa. Den ena är att utifrån systemutveckling skala upp och innefatta en större del av, eller hela IT-organisationen. Medan den andra är att utifrån IT-organisationen innefatta en större del av, eller hela organisationen. Okej, då kör vi..
#1: Att jobba mer med ”pappret” än med människorna
Man gör sin läxa mycket väl när det kommer till planeringen av förändrings-projektet. (Paradoxalt nog i form av ett vattenfalls-projekt.) Och rullar sedan planenligt ut en perfekt struktur med tillhörande modeller och metoder. Förändringsledning handlar i första hand om förändring i människors arbetssätt (läs: beteende), och i andra hand om förändrad organisationsstruktur.
Ni som var med på 90-talet, när vi gick från linje- till matrisorganisation, fascineras säkert av att vi mer eller mindre upprepar de misstag vi gjorde redan då. Trots att organisationen har kompetenta förändringsledare, involveras dessa alldeles för sällan. Till exempel baserat på att det agila skall vara någon typ av självklarhet för de som kommer att beröras av förändringen. Kommentarer som ”nu får dem ju som de vill” eller ”de har ju fått läsa boken” kan vara tecken på just detta.
Lösning: Agil förändringsledning i fem steg; planera, informera, justera, träna och implementera. Där steg 3 – 5 sker aggregerat i iterationer.
#2: Ett allt för enkelspårigt införande
En av flera önskvärda effekter av en agil transformation, är en tightare integration mellan olika funktioner i organisationen. Vilket hoppas ge ett effektivare samarbete, med kortare ledtider som positiv följd.
När man utan hänsyn tagen till olika funktioners förutsättningar, tvingar in dessa i en allomfattande agil kostym, kan effekten snarare bli kontraproduktiv. Jag brukar illustrera det här genom att först hålla två knutna nävar en bit ifrån varandra; isolerade funktioner med ett samarbetsmässigt stort avstånd. För att sedan slå ihop dem, knogar mot knogar; isolerade funktioner med ett samarbetsmässigt kort avstånd.. och det är här många hamnar. När man egentligen ville något annat, vilket jag illustrerar genom att integrera händerna med varandra, med sammanflätade fingrar.
Lösning: Se till att den isolerade funktionen (knuten näve) först har öppnat upp sig för integration (öppen hand) innan den agila resan tar vid. Att utifrån funktionens (läs: människors) motivationsfaktorer ge incitament till att vilja byta till en passande agil kostym.
#3: Att försöka Scrumifiera organisationen utanför systemutveckling
Det agila arbetssättet är så mycket mer än Scrum. Förvisso har Scrum fått störst genomslagskraft inom agil systemutveckling, vilket tyvärr gett den specifika systemutvecklingsmetodiken en kvalitetsstämpel överordnat det allmänt agila. Jag vet att inte alla håller med mig när jag säger att; Scrum hör hemma i en miljö för systemutveckling. (punkt) Har man sen en väl fungerande agil systemutveckling a la Scrum, så skall 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 hantera det allmänt agila snarare än det Scrum-specifika.
#4: Allt eller inget
Att tro att det agila arbetssättet passar allt och alla är inte bara naivt, det är kostsamt. För att få ut maximal effekt måste alla arbeta agilt. Fel! Det både går och skall 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 säljorganisation, som med stor sannolikhet arbetar plandrivet. Måste dem arbeta agilt för att kunna sälja en applikation som utvecklas agilt? Nej. Däremot bör de ha en förståelse för det agila arbetssättet, på samma sätt bör det agila teamen ha en förståelse för sina plandrivna säljkollegor. Och det här handlar inte om agilt, utan om effektivt samarbete mellan olika funktioner i organisationen.
Lösning: Att få en funktion att förstå andra funktioners arbetssätt, och sedan utveckla en form för samarbete.
#5: Att slarva med införandet av agila roller
Punkt fyra ovan fick mig att tänka på hur en del agila team inte tar tillvara på möjligheter att effektivisera samarbetet med övrig organisation. Alltså, när man ändå genomför en förändring, varför inte göra sin läxa väl och ta tillvara på alla möjligheter till förbättring? I agila utvecklingsteam i allmänhet, Scrum-team i synnerhet, finns en så kallad produktägare. Produktägarens primära roll är att vara gränssnittet mellan teamet och beställaren/kunden, företrädesvis genom att äga produkt-backloggen. Här har jag sett flertalet varianter..
En variant är när produktägaren är en fd projektledare/Scrummaster, som står med båda fötterna i teamet och försöker hantera beställaren/kunden. En annan variant är när produktägaren är en fd produkt/system-chef, som står med båda fötterna hos beställaren/kunden och försöker hantera teamet. Båda de här varianterna fungerar så klart mindre bra. Produktägaren skall stå med en fot i varje ”läger” så att säga. Det är vad som gör rollen så utmanande, men också så oerhört värdefull för alla parter.
Lösning: Se hur agila roller och funktioner kan bli en del i integrationen med den övriga verksamheten.
