Vilken resa vi gjort inom svensk mjukvara! För bara något dussin år sedan härskade fortfarande två lika dåliga sätt att leda utvecklingsarbete på: Antingen tungt och byråkratiskt eller helt ad hoc. Antingen ”inget är tillåtet om inte processpolisen godkänner det” eller ”anything goes”.
Nu har vi en mellanväg: planera tillräckligt bra och jobba sedan på ett sätt som låter oss tydligt se resultaten och justera längs resans gång – och vi anpassar inte bara produkten vi bygger, utan också vårt arbetssätt. Detta kallar vi för att utveckla agilt.
Har vi löst alla problem? Knappast. Är det ofta så att vi utropar att vi är agila när vi egentligen bara bytt namn på roller och ceremonier? Ja, det händer ganska ofta. Är det likväl så att vi genomgått ett paradigmskifte, från konstant eldsläckande-multitaskande-resursplanerande-uppgiftstilldelande-business as usual – till att se att det i många organisationer idag är fullständigt självklart att odla upp långlivade-fokuserade-kundorienterade-featureteam. Till exempel.
Eller det här med att det faktiskt är både ekonomiskt smart och psykologiskt tillfredställande att leverera tidigt och ofta, snarare än sent och sällan. Får alla till detta? Nej, verkligen inte, men de som lyckas kan vinna storslaget.
Stora fördelar med agilt
På en kurs jag körde för en tid sedan berättade en av deltagarna om hur de jobbade med kontinuerliga leveranser i sin verksamhet. Två kurskamrater lyssnade storögt. När berättelsen var slut utbrast en av dem: ”Men det här låter ju skitsvårt! Hur har ni lyckats med det?” Svaret var lika kort som tydligt: ”Vi har jobbat för att få till det i sju år”.
Vissa som har satsat på agilt på allvar har vunnit rejäla fördelar. Motiverade team, tajtare leveranser, nöjdare kunder, högre transparens och ett tydligt budskap till nya potentiella kollegor: ”Kom till oss, vi skeppar faktiskt grejor och vi har kul när vi gör det”.
Ändå är agilt bara början. I sin grund är agilt reaktivt. Det handlar om att vara lättrörlig. Att bygga transparens och lyssna på sin omgivning för att flexibelt kunna anpassa sig till förändringar och dra nytta av nya lärdomar. Däri ligger utmaningen: anpassning räcker inte hela vägen. Världen är för snabb. Hur flexibla vi än är riskerar vi att för sent upptäcka att vi utvecklat en produkt och format en organisation som är gamla i samma stund som vi börjar tycka oss bli klara. Som en deltagare i en workshop uttryckte det: ”Vi har beskrivit den nya produktplattform som vi borde haft redan idag.”
Höj blicken och skapa en idealdesign
Vad ligger bortom agilt? Jag tycker att Russ Ackoff fångade det bäst när han rekommenderade en idealiseringsprocess. När små stegvisa förbättringar inte räcker, eller går för långsamt, byter vi fokus. Istället för att beskriva nästa delmål höjer vi blicken rejält och skapar en idealdesign. En idealdesign beskriver vår organisation eller lösning som vi skulle vilja att den var om det inte fanns några begränsningar. Vi designar den bästa helhet som vi kan tänka oss just nu. Det ger oss möjligheten att identifiera och hantera de systemiska problem och möjligheter som är så svåra att komma åt i en inkrementell approach.
Implementerar vi hela idealbilden i ett svep? Absolut inte. Det vore förmodligen katastrofalt. Ackoff kallar sin approach för ”approximering”: ett gradvis närmande. Hmm. Kan vi något sätt att göra ett sådant gradvis närmande? Precis: agile. Match made in heaven.
Jag tror att Ackoffs idealiseringsteknik är det logiska nästa steget för organisationer som börjat få agile att fastna i sitt DNA. Som börjat få en agil kultur men undrar hur man kommer vidare. Hör av dig om du tycker idéen låter intressant och vill diskutera den med mig!