De agila metodernas historia

[Detta är ett kapitel ur en liten skrift om vad organisationsagilitet är, riktad till folk i arbetslivet men utanför IT. Jag är nyfiken på vad en människa som inte kan IT tycker om den här texten. Är den begriplig, eller har jag råkat få med något IT-specifikt? Kommentera gärna]

När datorerna inte var så kraftfulla var det enkelt att skriva datorprogram. De första programmen var enkla beräkningar av missilbanor eller löner. På natten innan den 23:e i varje månad kördes ett enkelt löneprogram på ett magnetband där alla anställda fanns, och dagen därpå fraktades bandet till en bank som gjorde själva löneöverföringen. Det dyra och komplicerade var själva datorn, stor som ett skåp, som stod i källaren. Programmet var inte det krångliga.

Under 1980-talet blev datorerna mindre och fler och tog sig in på kontoren och kopplades samman med varandra och med de gamla stordatorsystemen som hade hand om lönekörningarna (fast numera utrustade med hårddiskar så att man kunde hantera all data parallellt och inte i sekvens som på magnetbandstiden). Man såg enorma nya möjligheter med den nya tekniken och gav sig i kast med att tänka ut nya system. Men mycket snart märkte man att det fanns stora problem. Flera små sammankopplade datorer gav många möjligheter. men också stor komplexitet. Ju fler möjligheter desto svårare att realisera dem. Matematiskt intresserade personer insåg att komplexiteten ökade exponetiellt med möjligheterna. I mitten-slutet på 80-talet hade man insett att om man inte kom på ett sätt att hantera komplexiteten så skulle man aldrig kunna förverkliga alla fina nya möjligheter. Varje ny funktion man ville ha ökade både tiden, kostnaden och risken oproportionerligt mycket. Något måste göras.

Försök med projekt

Ett försök att hantera komplexiteten var att försöka planera bättre. Man resonerade så här: Byggindustrin har kunnat hantera komplicerade och stora byggen i över 150 år. När man reste Eiffeltornet var det ett paradexempel på logistik (järnleveranser från Sundsvall till Seine) och precis tillverkning (balkarna tillverkades till exakt storlek enligt den mycket noggranna ritningen och skickades upp i tornet för att sättas på plats). Kunde man inte först göra en noggrann design där man, precis som på en byggnadsritning, ritade in hela lösningen för att sedan tidsätta varje moment som krävs för att implementera den? Och sedan bara se till att rätt mängd personal fanns på plats som gjorde rätt saker? I enlighet med en plan som följs upp noggrannt? Alltså utveckla IT i form av projekt?

Man försökte börja tillämpa detta inom IT-utveckling. Det svenska företaget Ericsson utvecklade under åren 1987-1989 projektmodellen PROPS, och flera andra organisationer skapade sina varianter. Alla modellerna byggde på tanken att man i en förstudie kunde skapa den rätta ritningen och utifrån den göra en plan som höll både vad gällde tidpunkter, tidsåtgång och kostnader. Man utgick från att det svåra var att göra planen och att se till att alla följde den utan att avvika.

Även om projektmodellerna hjälpte till att skapa ordning och reda så innebar det inte att de löste problemen. Systemutvecklingsprojekt havererade i en aldrig sinande takt. När internet slog igenom i mitten på 90-talet ökade dessutom både komplexiteten, antal ställen i samhället där systemutveckling ägde rum, och antal personer som ägnade sig åt att både beställa och utveckla system. Vad var det som hände? Varför fungerade det inte? Det som man skriver när man utvecklar system, själva koden, är ett mycket exakt designdokument. Utifrån det dokumentet kan en dator bygga själva systemet och även tillhandahålla det för en användare som en tjänst. Alla andra designdokument som beskriver lösningen är översiktliga och inte detaljerade. De går inte att skapa en plan utifrån. För att göra en riktigt bra lösning i en förstudie behöver man alltså egentligen skriva hela koden.

Men problemen med att använda projektmetoder i utvecklingsarbete stannar inte där. Hur vet man att man är på rätt väg, att den lösning man tar fram verkligen möter människors behov, om man inte får stämma av under resans gång eftersom den lösning man ritat inte får ändras? Och om man stämmer av löpande, kanske genom att ge folk prototyper och delar av systemet att prova, hur gör man då med den återkoppling man får? Hur hanterar man informationen att den tänkta användargruppen inte alls kan använda systemet som det är tänkt, att det krävs omtag på kravställningen?

Med systemutveckling är det så att även små förändringar i kravbilden och förutsättningarna kan påverka ganska stora delar av systemet. Och med projekt är det så att förändringar i det man planerar att göra kan kasta omkull hela planen eftersom de olika arbetsmomenten ofta är så beroende av varandra.

Ska man hålla fast vid en plan som inte längre är meningsfull? Ska man ignorera den nya information man fått fram på vägen om hur människors behov kan mötas? Ska man blint hålla fast vid att de antaganden man gjorde under ett tidigt skede stämmer, trots att man under tiden upptäcker hur fel man hade? Eller finns det andra sätt att bedriva utveckling på?

Iterativa arbetssätt

Att utveckla nya saker innebär ett utforskande. Det fanns de som tidigt såg hur projektmodeller inte stödjer ett utforskande arbetssätt, utan tittade på om man inte kunde hämta inspiration från andra ställen än byggindustrin och andra verksamheter som byggde på planering på förhand. Ett sätt att försöka hantera komplexitetsproblem är att bryta ner problemet i mindre bitar. Redan under femtiotalet hade raketindustrin och den amerikanska försvarsmakten experimenterat med att bryta ner komplexa utvecklingsprojekt i mindre delar och låta olika grupper utveckla sina delar parallellt. Med jämna mellanrum, ungefär var åttonde vecka, berättade man för varandra vad man hade kommit fram till och så gjorde man en omplanering utifrån den senaste kunskapen.

Inom systemutveckling finns det en uppsättning tekniker för att bryta ner stora och komplexa datasystem i mindre bitar, dessa tekniker kallas med ett samlingsnamn för objektorientering. För att lösa komplexitetsproblemet inom systemutvecklingen beslöt sig många att satsa på detta. Men några av dem som arbetade med objektorientering gjorde iakttagelsen att det inte räcker med att bryta ner lösningen i mindre delar. För att få till ett utforskande arbetssätt behöver man även kopiera rymd- och försvarsindustrins tanke om att arbeta i korta etapper och ständigt omplanera. Det som också kallas att arbeta iterativt.

Dessa personer testade under 90-talet iterativa arbetssätt, kompletterade med idéer om värdeflöden hämtade från Toyota och idéer om gemensamt beslutsfattande ifrån alternativ­rörelsen. På årliga konferenser träffade de varandra och presenterade vad de hade funnit och med tiden publicerade man sina arbetssätt som olika metoder: Scrum, XP, DSDM med flera.

Det agila manifestet

När man hade hållit på några år funderade man på vad det var man hade kommit fram till egentligen. Man lånade idéer av varandra så ramverken började likna varandra mer och mer.

Vilka var de underliggande tankegångarna man delade med varandra? Frågan ställdes på en konferens år 2000, och man samlades i en särskild konferens år 2001 för att fundera kring detta. Det verkade som om man allesammans hade nått vissa gemensamma insikter om vad som var mer viktigt än annat:

Man hade funnit att det var förmågan för gruppen att kommunicera och samspela som var viktig, inte att följa en viss process eller att använda vissa verktyg.

Man hade kommit på att det var viktigt att fokusera på den värdefulla leveransen, till exempel mjukvara som fungerar. Det är viktigare än att uppfylla alla projektmodellens formkrav.

Man hade sett behovet av att samverka med kunden så att man prövar sig fram till en bra lösning tillsammans, hellre än att låsa både kund och leverantör i ett detaljavtal på tidigt stadium.

Och allt detta gör att förmågan att hantera förändring blir mycket viktigare än att följa upprättade planer slaviskt. Dessa fyra insikter samlades i en liten text som kallas Det agila manifestet. Det, tillsammans med tolv bakomliggande principer, har fått definiera vad som är agilt och inte.

Agilitet idag

Agila metoder har blivit det normala sättet att arbeta inom systemutvecklingen, i alla fall nere “på golvet”. Fortfarande kämpar många IT-utvecklingsorganisationer med att få även finansierings-, kravfångnings- och säljprocesserna lite mer lättrörliga. Och trenden är att fler och fler människor även inom andra verksamheter än systemutveckling provar agila arbetssätt: omsorg, försäljning, marknadsföring, produktutveckling, tjänsteutveckling med flera ställen. Många upplever ett behov av att jobba smidigare, och många tycker att det både är effektivt och befriande med det stora mått av delegering och självbestämmande som många agila tekniker bygger på. Därför kommer resten av skriften helt sakna IT-fokus.