Utveckling är lärande

Utvecklingsarbete är att aktivt arbeta med att skapa ny kunskap och kan bara ske som gemensamt lärande genom en serie experiment. Annars är det inte utveckling. Tänk om vi bara kunde förstå det!

/Peter Tallungs, IRM, 2024-01-11

Synen på vad utveckling är har förändrats

Synen på hur verksamhets- och it-utveckling ska drivas har genomgått en omvälvning de senaste decennierna. Tidigare skulle man gå fram i avgränsade etapper med tydliga gate points. Först en ordentlig analys (vad vill vi ha), sedan en design (hur ska det se ut), för att först därefter bygga och sätta i drift. Man behövde således redan från början ta reda på inte bara vad man ville åstadkomma utan även hur det skulle förverkligas.

(Anmärkning: Jag skriver ”verksamhets- och it-utveckling” för att vara tydlig trots att it-utveckling aldrig kan vara något eget utan egentligen alltid bör ses som en integrerad del av verksamhetens utveckling.)

På avstånd kan detta linjära synsätt se ut som det enda rätta. I varje fall om man aldrig reflekterat över vad utvecklig egentligen innebär och hur det går till. “Tänk först, gör sen!” och ”Ta först noga reda på vad som behövs!”, kan låta vettigt. Problemet är att denna vattenfallsprocess inte fungerar när man ska förändra en verksamhet. Anledningen är att en verksamhet är ett komplext tekno-socialt system. Ett sådant har många aspekter och intrikata beroenden som vi aldrig helt och hållet kan känna till. Varje analys leder till nya frågor och behov av ytterligare analys. Om vi framhärdar hamnar vi i diagnosen ”analysis-paralysis”, där ingen utveckling sker.

Det är helt enkelt inte är möjligt för oss att i förväg till fullo greppa vad en förändring av ett komplext system innebär. Vi kan ha hypoteser, men de behöver verifieras. Och det kan göras först när en förändring väl är genomförd.

Experimentera

Vi behöver i stället experimentera. Vi behöver göra utvecklingen i små men fullständiga steg där vi i varje steg går från idé till genomförande. Och där vi efter varje steg (som kan kallas sprint eller iteration) tar in vad vi lärt oss och tar ut en ny kurs från det kunskapsläge där vi nu står. Varje iteration är på så sätt ett experiment, med målet att bygga ny kunskap. Kunskap om vad som fungerar, hur det fungerar, och om vi verkligen vill ha det.

Skiftet är ofta bara på ytan

Men skiftet från det linjära synsättet till det iterativa har ofta bara skett på ytan i våra organisationer. Vi ser överallt hur de gamla tankesätten hänger kvar. Vattenfallstänkande sitter hårt vad gäller hur man styr och driver projekt, och hur man driver förändring generellt.

Det är lätt att förstå varför man kan ha svårt att lämna detta gamla tänkesätt. Man vill ha kontroll och kunna ställa krav på projekten så man vet vad man håller på med. Det nya synsättet känns som ett osäkert gungfly. Hur ska vi kunna leva med att vi inte vet vad vi får, när vi får det, och vad det kommer att kosta?

Djupare förståelse

Jag tror att vi behöver förmedla en djupare förståelse av vad utvecklingsarbete egentligen är. Hur arbetet med verksamhetens utveckling skiljer sig från det rutinmässiga arbetet i våra verksamheter, det som verksamheten finns till för och som vi vanligen kan repetera i tydliga processer. Det som vi kan kalla för drift eller operativ verksamhet, som till exempel tillverkning eller tjänsteleverans i någon form.

Utvecklingsarbete är alltid lärande genom experiment

Utvecklingsarbete innebär per definition att vi skapar något som ännu inte finns i sinnevärlden, i varje fall inte på just det sättet och i just det sammanhanget. Det gäller idag, och har egentligen alltid gällt, och i alla sammanhang. Annars är det inte utveckling, utan det vi kan kalla för operativ verksamhet eller drift, det vill säga produktion av varor eller tjänster i någon form då vi gör mer av samma, att vi upprepar något vi redan gjort tidigare.

Det vi vill utveckla finns inte i verkligheten och (detta är viktigt) egentligen inte heller i våra huvuden, annat än som en hypotes. Vi har en idé, men kan inte i förväg riktigt greppa den i alla sina aspekter. Vi skapar alltså något vi i detta nu inte helt kan förstå eller lita på vad det är. Det är inte bara medlen som är osäkra, vi vet egentligen inte heller vilka effekter vi verkligen vill ha. Effekterna av en förändring är alltid mångfacetterade och olika hos olika intressenter. Vissa effekter visar sig mindre viktiga, andra effekter som vi inte ens föreställt oss visar sig riktigt värdefulla, i efterhand.

Det här gör många nervösa. Hur kan vi ta fram något som vi inte vet om det funkar eller ens om vi vill ha det? Men lugn, det här är faktiskt något vi gör ofta som en naturlig del av våra liv, både privat och i yrkeslivet.

Ett enkelt exempel

Låt mig visa med nedan exempel hur utveckling skiljer sig från drift:

Drift: Du är kock och ska laga en maträtt. Du följer ett recept. Du kan och bör veta både vad du behöver, hur lång tid det tar, vad det kostar och vad resultatet blir. Hela processen och resultatet är, och bör vara, förutsägbart och i hög grad säkert och repeterbart. Allt annat skulle vara oprofessionellt.

Utveckling: Du är kock och vill skapa en ny rätt eller en variation på en rätt. Rätten finns bara som en idé i ditt huvud. Hur gör du? Jo, du har alltså en hypotes, du testar den genom att gå hela vägen från idé till färdig rätt. Du smakar av och konstaterar att kryddpeppar till laxen inte var en så bra idé som du föreställt dig. Du får prova något annat. Det var alltså ett experiment, och märk att det faktiskt var ett lyckat experiment. Kanske inte vad vi i dagligt tal menar med lyckat experiment, men faktiskt lyckat på riktigt. Lyckat för att det gav dig ny kunskap: Kryddpeppar på lax funkar inte. Din hypotes blev falsifierad och du behöver modifiera den. Kanske lite svartpeppar skulle vara en bättre idé?

Ett misslyckat experiment däremot, det vill säga misslyckat på riktigt, kunde ha sett ut så här: Du hällde på lite av varje på laxen, det blev utsökt, men du noterade inte vad du gjorde. Du har alltså inte skapat ny kunskap. Det är ett misslyckande.

Ett lyckat experiment är alltså ett som ger ny kunskap, oavsett resultat i övrigt. Ett misslyckat experiment är på motsvarande sätt ett som inte ger någon ny kunskap, oavsett resultat i övrigt.

Utveckling är hypotesdriven

Utveckling är därmed något helt annat än operativ verksamhet. En särskild form av mänsklig verksamhet, som skiljer sig kraftigt från vad vi gör när vi gör mer av samma. Det är inte för att utveckling är flummig och ostyrd, utan för att den måste styras på ett helt annat sätt än operativ verksamhet. Vi behöver steg för steg sätta upp en tydlig hypotes, och utforma ett experiment för att verifiera eller falsifiera hypotesen. Experimentet ska vara utformat så att det så snabbt och effektivt som möjligt ger oss den kunskap vi söker. Det behöver därmed vara så avgränsat som det bara går utan att det blir meningslöst. Därefter genomförs experimentet noggrant. Till sist undersöker vi vad vi lärt oss och utformar nästa, nu modifierade, hypotes. Ofta pratar man om resultatet av ett delvis utfört utvecklingsarbete som Minimal Viable Product. Men det skulle vara tydligare om vi kunde se att det verkligen bara är experiment vi gör.

Utveckling är design

Inom designteori pratar man om ”design” och menar samma som jag här kallar för utveckling, det vill säga den typ av verksamhet som människor gör när de skapar något som inte finns i sinnesvärden (utom som en ren kopia på något som redan finns).

Utveckling sker genom PDCA-cykeln

Den snabba cykel av aktiviteter som behövs för att utveckla något (Utforma – Verifiera/Falsifiera – Modifiera hypotes) beskrivs ofta som PDCA-cykeln, Plan – Do – Check – Act, eller varianter på denna.

Utveckling måste styras på annat sätt än drift

Jag menar att mycket av det vi upplever inte fungerar vad gäller utvecklingsarbete i våra organisationer i botten beror på att man inte förstått den här grundläggande skillnaden mellan ordinarie operativ verksamhet (drift) och utveckling.

Många chefer kommer från operativ verksamhet, det vill säga där man alltid planerar och levererar enligt plan. När denne sedan blir chef över utveckling i någon form så vill hen styra på samma sätt, det vill säga att hen vill veta vad som levereras när och vad det kommer att kosta. Att inte kunna svara på dessa frågor ses som inkompetens. Därför ser sig inblandade tvungna att ge estimat och målbilder som ger sken av att de är validerade, för det är vad som förväntas, trots att det är omöjligt. Ofta tror de inblandade själva att de borde kunna ge tydliga korrekta estimat. Och låtsas för att inte verka inkompetenta.

Vi kan förstås gissa, ge så kallade ”guesstimates”, men gissningar är hypoteser. Projektledning ses ofta som en krockkudde mellan två bilder av verkligheten; å ena sidan vad som händer i projektet, som med nödvändighet måste vara hypotesdrivet (verkligheten), å andra sidan styrgruppens fejkade bild, som kräver att man levererar vad man i förväg lovat, på lovad tid och budget.

Diskrepansen kan sedan projektledaren alltid skylla på; att nya krav och omständigheter dykt upp på vägen. Skulden hamnar då på beställarsidan, som inte har specat tillräckligt noggrant. Men sanningen är att om det är utveckling det handlar om så kommer ny kunskap fram på vägen. Det är det naturliga och inte en olycka i arbetet. Om inte ny kunskap kommer fram under arbetet har ingen utveckling skett. Då visste vi allt redan som vi nu vet. Ju mer som ändras på vägen desto mer lyckad utveckling.

Jämförelse mellan operativ verksamhet och utveckling

I följande matris sammanfattas hur utveckling skiljer sig från operativ verksamhet.

Skiljelinjen är dock inte så strikt i alla lägen

Med detta sagt går skiljelinjen inte alltid precis mellan operativ verksamhet och utveckling. Det finns undantag. Skillnaden hittar vi egentligen mellan det vi kan räkna ut i förväg och det vi inte kan hantera på det sättet. Utvecklingsarbete har på metanivå aspekter som liknar operativ verksamhet, och som behöver styras på samma sätt. Man producerar experiment med tydliga beställningar och resultat. Det kräver också strikt planering och tydliga leveranser.

Och omvänt; operativt arbete kan ofta innehålla moment eller aspekter som är mer av utvecklande karaktär, där man måste prova sig fram. Det finns till och med operativ verksamhet där så mycket är osäkert att det är mer likt utveckling. Detta gäller i volatila miljöer där man hela tiden behöver anpassa sig till förändrade hot och möjligheter. Ett tydligt exempel är krigföring, både på det strategiska och taktiska planet.

Det finns även sådant som ofta kallas utveckling men som är nästan helt och hållet att betrakta som tillverkning/operativ drift, det vill säga där vi bara gör mer av samma. Som att vi har en fabrik, men vill utöka genom att bygga en till, som ska vara precis likadan och förhållandena är mer eller mindre precis de samma.

Men dessa är som sagt undantag och inget som kullkastar den här dikotomin. I de allra flesta verksamheter går den stora skiljelinjen mellan vad vi kan se som operativ verksamhet (att göra det som man normalt gör, repetitivt och förutsägbart) och utveckling (att förändra verksamheten).

”Fail fast”

Om våra verksamhets- och it-ledningar till fullo kunde förstå denna agila och flexibla process där vi ständigt lär oss skulle vi sluppit dessa havererade jätteprojekt som vi sett så många av. Som Rikspolisstyrelsens Pust, Stockholms stads skolplattform och SEB:s One IT Roadmap. Dessa är bara toppen av isberget. Alla som jobbat i olika organisationer vet att det finns många liknande fall som inte kommit fram till allmänhetens ljus. Ty det vanliga är maskera misslyckande som framgång. Ingen inblandad vill att sanningen kommer fram.

Det återkommande och gemensamma med dessa typer av projekt är att alla inblandade redan tidigt ser att man är på väg i diket, men det går inte att vända om eller byta riktning. De som tagit beslut, både på beställar- och leverantörssidan, har lovat för mycket och fortsättningen blir bara en enda dödsmarsch och ”blame game” där vardera parten bara jobbar på att själv gå skadeslös.

Om man gör utvecklingen i små steg, och med öppna ögon utvärderar och omprövar efter varje iteration kan inte detta hända. Principen heter ”fail fast”; Hur kan vi på snabbast få reda på om detta är en bra idé? Om inte vill vi upptäcka det tidigt och ha ett upplägg där vi inte sitter fast i löften som vi inte kan hålla.

Den största tragedin med dessa haverier är inte bortslösade pengar utan bortslösad tid och möjligheter. Vanliga medarbetare och kunder i våra verksamheter får inte det it-stöd de behöver utan får dras med sorgligt dåliga lösningar.

Utvecklig är lärande. Låt oss jobba för att sprida den insikten.