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.

Infografik: Agil förändringsledning

Infografiken kan laddas ner HÄR

Detta är en liten minnestavla för att minnas hur man kan bedriva förändringsledning på ett agilt sätt. Jag tycker att detta arbetssätt fungerar som en bra teknik vid införande av lean och agila arbetssätt, eller för att bättra processen som efter ett retrospektiv eller annat förbättringsmöte, eller för att införa andra förändringar,

Man utgår från effektmålen man vill uppnå.

För att uppnå effektmålen hittar man på konkreta förändringar i arbetssätten. Hypotesen är att de konkreta förändringarna leder till effektmålen, men det är bara en hypotes. För att veta behöver vi mäta och följa upp.

En förändring som tar upp till ett kvartal att genomföra behöver brytas ner till några delmål som vart och ett kan utföras inom som högst en månad. Varje månadsärende behöver brytas ner till några delmål som vart och ett kan utföras inom högst en vecka.

För att uppnå en förändring hittar man på experiment, det vill säga konkreta förändringar i arbetssätten att testa och som man hoppas kunna ge mer information om och hur de ska permanentas.

Mindre arbetsgrupper hittar på och utför och följer upp experimenten, på vanligt retrospektiv/PDCA/kaizen-sätt.

En synkmästare följer upp och hjälper arbetsgrupperna att göra sitt jobb.

Förändringsägare prioriterar mellan de föreslagna åtgärderna, baserat på uppföljningen.

Ha allt synligt på en tavla, och tillämpa regelbundna förbättringsmöten så att även själva förbättringsprocessen förbättras.

Infografiken kan laddas ner HÄR

Teknik: Agil PO

En annan teknik är den agila "PO":n. PO-rollen har fått sitt namn efter begreppet "Product owner" som är lite problematiskt. Det finns nämligen redan en massa "produktägare" i olika verksamheter som uttryckligen inte gör det som en agil PO ska göra, om man till exempel tittar på beskrivningarna av "Scrum Product Owner" i Scrumguiden.

En agil PO tar ansvar för att alla förändringar i ett förvaltningsobjekt är ekonomiskt optimala över hela objektets livscykel. När objekten är tekniska, till exempel mjukvara och IT-tjänster, så handlar det om att väga de marknadsmässiga och verksamhetsstödjande aspekterna av objektet mot tekniska hänsyn. En agil PO har ansvar för alla aspekter: ekonomin, tekniken, marknadsmässigheten, och att objektet är verkligen stödjer de mänskliga aktiviteter som det ska stödja.

I många verksamheter är det istället så att "produktägaren" bara tar några av dessa hänsyn, ofta några av de verksamhetsmässiga. Det tekniska antas antingen sköta sig själv eller så är verksamheten så okunnig om tekniska realiteter att man helt enkelt inte förstår att sätta upp rutiner för att hantera det. Det är helt sant att för ett litet objekt är det rimligt för en PO att lämna över handhavandet för alla tekniska aspekter av objektet till ett arbetslag av tekniskt kunniga. Men eftersom PO:n är den som bestämmer vad som ska göras med ett objekt, så förblir PO:n i slutändan ansvarig även för tekniken. När verksamheten vill ha en sorts förändring av objektet och teknikerna en helt annan så måste någon välja väg och ta ansvar för det valet.

För att lösa problemet med att ingen tar helhetsansvar för ett objekt föreslår Ken Schwaber och Jeff Sutherland i sitt metodramverk "Scrum" att det ska finnas en PO så att prioriteringsordningen alltid är klar: för detta objekt vet vi alltid vad som är det mest nödvändiga att göra just nu. Det kan vara så att den ni idag kallar "produktägare" är rätt person att även axla rollen som agil PO. Men det är inte säkert.

Men det finns ett problem till som PO:n löser. Det handlar inte bara om att optimera det ekonomiska värdet av ett objekt genom att prioritera mellan de förändringar man vill göra i objektet. Det handlar även om att optimera det ekonomiska värdet av ett arbetslag.

Antag att vi har tre objekt, t ex tre tekniska system, och ett arbetslag om fem personer. Arbetslaget kostar fem miljoner kronor om året. Det blir viktigt hur vi prioriterar arbetslagets arbete.

Om vi nu tillsätter en PO per objekt blir det arbetslagets uppgift att prioritera mellan objekten. Prioriterar de objekt A under en månad kommer förändringarna i B och C att få vänta. Hur vet vi att väntekostnaden (cost of delay) för A, B och C är sådana att detta är det mest optimala? Prioriterar de att försöka hjälpa A, B, och C kommer alla tre att få vänta eftersom kalendertiden för att en förändring ska bli klar blir åtminstone tre gånger så lång för var och en, förutom att de alla tre får dela på merkostnaden för uppgiftsväxling mellan tre initiativ (som lätt kan uppgå till 50% av kostnaden utan uppgiftsväxling).

Man kan förstås utrusta arbetslaget med verktyg (förmåga och mandat) att rätt prioritera mellan A, B, och C. Men en agil PO, så som Scrum beskriver den, är också en lösning. Samla förändringarna för alla objekt i en och samma lista, och gör löpande en optimal prioritering mellan dem. Det är därför som Scrum föreskriver att det är PO:ns ansvar att ekonomiskt optimera utvecklingslagets arbete, för det kommer i slutändan att vara optimalt även för varje enskilt objekt ("produkt").

En kursdeltagare föreslog en gång att man borde kalla den agila PO:n för "prioriteringsombudsman" ("Prioritization Ombudsman") för det är vad det ytterst handlar om, snarare än ett produktägarskap.

Teknik: tvärfunktionellt arbetslag

En agil teknik är det tvärfunktionella arbetslaget. Vilket problem vill man lösa genom att ha tvärfunktionella arbetslag?

Att ett arbetslag är tvärfunktionellt innebär att det innehåller en blandning av kompetenser som krävs för att skapa ett visst värde. Motsatsen, ett enfunktionellt arbetslag, består av specialister på en del av arbetet. Som till exempel vid vissa systemutvecklingsmetoder: en grupp lösningsarkitekter som utifrån en beskrivning av verksamhetslogiken och informationsmodellen skapar en övergripande teknisk lösningsskiss som de skickar vidare till de som arbetar mer kodnära.

De enfunktionella arbetslagen uppstod ur en idé om specialisering och enkelriktade arbetsflöden: inom tillverkningsindustrin är det rationellt med specialiserade arbetsstationer och så låter man arbetspaketet flöda genom systemet från den ena stationen till den andra. Problemet var att utvecklingsarbete handlar om att tillsammans förfina information om både problem och möjliga lösningar. Att generera beskrivningar av verksamhetslogik, av lösningsarkitekturer, och av kod är bara utflödet av denna informationsförfining.

Enkelriktade flöden mellan specialiserade grupper är bara ekonomiskt effektiva om transaktionskostnaden mellan grupperna är låg och inget värdeutbyte sker mellan grupperna. I utvecklingsarbete är det värdeskapande med ett kontinuerligt utbyte (inte ett enkelriktat flöde) mellan olika kompetenser så att man kan skapa en gemensam bild (inte olika sorters dokument som ägs av helt olika personer). Utvecklingsarbete måste därför optimera informationsutbytet och kunskapsförfiningen.

Detta kan göras om personer med olika kompetenser arbetar tillsammans i ett litet samkört arbetslag med att förfina och till slut kodifiera samma kunskapsmängd och på så sätt skapa en gemensam leverabel. Ett tvärfunktionellt arbetslag.

I grunden är det ett leanverktyg från tillverkningsindustrin: gruppera människorna runt samma arbetspaket så att de kan blir experter på att samarbeta om att skapa en leverabel så fort de får en förfrågan. I lean kallas det en "cell", till skillnad från en station vid ett löpande band.

Om du nu inte har tvärfunktionella arbetslag, hur anpassar du metoden då? Du behöver titta på det bakomliggande syftet med det tvärfunktionella arbetslaget, nämligen kommunikation och kunskapsförfining, och se hur man kan åstadkomma detta även när nyckelkompetenser befinner sig på olika platser i organisationen. Kan de dela möten med varandra? Kan deras respektive grupper samplanera? Kan de olika enfunktionella grupperna arbeta runt samma flödestavla där de har arbetspaketens hela flöde i centrum, och inte bara den egna lilla delen av processen?

Det är nyckeln i all anpassning av agila metoder när du inte kan anpassa dig till att använda en viss teknik: se till teknikens bakomliggande syfte och försök uppfinna en egen teknik som uppfyller syftet. Pröva lite olika varianter, mät för att se vilka tekniker som innebär bäst förbättring hos er, och besluta er runt dem.

Vad ni inte ska göra är att behålla arbetssätten oförändrade jämfört med så som de beskrivs i de agila ramverken, när förutsättningarna hos er faktiskt inte är uppfyllda. Har ni inte tvärfunktionella arbetslag ska ni inte låta era enfunktionella arbetslag imitera hur de tvärfunktionella brukar arbeta. Ni kommer inte att få några bra resultat då. Det blir bara en rituell imitation av agila arbetssätt och ingenting som kommer att leda till större agilitet.

Vad vill metoden lösa?

När man inför agila metoder i olika samarbeten dyker man alltid på spänningsfältet mellan de som vill följa metoderna till punkt och pricka och de som vill anpassa dem. Och bland dem som vill slaviskt följa efter finns det de som vill följa av rätt anledningar och de som vill göra det av fel anledningar. Precis som hos de anpassliga: vissa vill anpassa utifrån ett verkligt behov av anpassning, medan andra vill anpassa för att undvika någon av de förändringar som metoden kan komma med.

Så hur vet man hur man ska förhålla sig till anpassningar av agila metoder då? Hur vet vi om vi ska följa slaviskt eller om vi ska ändra i metoden? Genom att man förstår hur metoderna fungerar.

Metoderna är påsar med tekniker i. Även om det står olika namn på påsarna innehåller de påfallande ofta samma tekniker, och det är teknikerna som påverkar samarbetet till att bli mer agilt om man tillämpar teknikerna rätt.

Varje teknik finns där för att lösa ett specifikt problem. Folk har erfarit strukturella hinder mot större agilitet, och så har de experimenterat fram en teknik som hjälpt deras samarbete att ta sig över det specifika hindret. Metoderna är inte magiska och teknikerna är inga ritualer som fungerar oavsett förutsättningarna. Om du inte har den situation som tekniken är tänkt att hantera, så ska du inte använda dig av just den tekniken.

Så står ni med en frågeställning rörande ett visst arbetssätt så börja med att undersöka om ni verkligen förstått hur det nuvarande arbetssättet påverkar den aktuella situationen, och vilka alternativa arbetssätt som skulle kunna påverka på ett annat vis. Sedan bör ni experimentera med arbetssätten för att validera de här hypoteserna, utvärdera på empirisk grund, och bestämma er för förhållningssätt därefter.

Det viktiga med införandet av agila metoder är att ni hela tiden är öppna för det här prövande förhållningssättet. Det kräver att ni aldrig standardiserar runt en viss metod eller teknik utan optimerar organisationen för förändring. Agilitet är ett lärande.

Kravkurs GBG den 30 mars!

Jag håller, tillsammans med Informator, en kurs i agil kravhantering i Göteborg den 30 mars 2016.

I kursen provar vi på olika tekniker hämtade från det verksamhetsfält som kallas för Lean UX: Personas och Impact Mapping / effektkartläggning, samt typiska agila kravtekniker som CCC-kompletta User Stories och Story Mapping.

Det hela synkas ihop med backloggarbete i en tredelad backlogg som är kompatibel både med SAFe (portfölj-, program-, och teambackloggarna) och med vår kurs i agilt produktägarskap.

Är du beställare, kravfångare, eller produktägare i en agil organisation så kommer du att ha nytta av den här kursen!

Oförutsägbara framtid

Den amerikanska ekonomiprofessorn Don Reinertsen har helt rätt i att produktledningsbeslut, till exempel om en systemförändring i en IT-tjänst eller IT-produkt, måste följa ett ekonomiskt ramverk. Hans förslag är att man kvantifierar väntekostnaden, vad det kostar att inte ha något på plats, för de olika alternativen och prioriterar utifrån det. Det blir då ganska uppenbart att man för systemförändringar som är ungefär likvärdiga ska man prioritera den förändring som man snabbast får ut i produktion så att det kan börja hämta hem värde. "Prioritize the Weighted Shortest Job First (WSJF)".

Man kan ganska enkelt göra spel och simuleringar som visar nyttan av detta.

Men man får samtidigt inte glömma bort att värdet av en systemförändring framförallt är kvalitativ. En IT-tjänst ingår i flera värdeströmmar. Varje förändring i tjänsten förändrar samtidigt flödet på ibland oförutsägbara sätt. Ny utformning av verktygen kommer att påverka hur själva arbetet går till. Ny utformning av tidsfördriven förändrar hur vi fördriver vår tid. Kanske till och med förändrar IT-tjänsternas utformning hur vi definierar både arbete och fritid.

Eftersom effekterna på hela flödena är oförutsägbara kan man ofta inte kvantifiera någon väntekostnad. Men hur ska vi då veta om vi ska försöka oss på den snabbaste förändringen först? Om vi inte vet om förändringarna är likvärdiga?

Svaret är att vi ska bli ännu mer angelägna om att prioritera utifrån snabbhet. Med snabb förändring får man snabbt svar på vad förändringen innebär i en komplex och oförutsägbar verklighet. En snabb förändring är en billig förändring så även förändringar som visade sig vara dåliga bör vara snabba att få ut i produktion.

I komplexa och adaptiva system, vilket nästan alla värdeströmmar är (om man tar hänsyn till människors beteende vilket man måste), är det förmågan att få snabb återkoppling på en prövande rörelse som är den avgörande, inte förmågan att förutse. Det ekonomiska ramverket vi beslutar utifrån måste därför vara inriktat på att minska risk och omfattning, och på att snabbt mäta utfall av olika förändringar. Inte vara inriktat på förutsägbarhet om förutsägbarhet ändå inte finns.

Don Reinertsen tar upp även denna aspekt i sin bok om produktutvecklingsekonomi, Flow och Eric Ries bygger hela tankegången i Lean Startup på principen om prövande förändring till låg risk och snabb återkoppling. Tyvärr har inte Dean Leffingwell i SAFe betonat värdet av utforskning tillräckligt hårt, utan lyfter framförallt principen om Weighted Shortest Job First, en princip som bygger på att man faktiskt kan vikta värdet av förändringarna på förhand (och korrekt estimera deras längd/kostnad). Man riskerar att gå miste om potentiellt väldigt höga värden bara för att man inte vågar utforska det okända.

Återigen alltså en risk med SAFe när det tillämpas utan en ifrågasättande självständig tanke. Det är alldeles för frestande för många, gärna i stora organisationer, att försöka optmimera för förutsägbarhet. Det logiska felslutet att påstådd förutsägbarhet är verklig förutsägbarhet, eller att förutsägbarhet alltid innebär låg risk, eller att låg risk alltid innebär god ekonomi, ligger nära oss, i synnerhet i organisationer som har lätt för att straffa.

Det är viktigt att snabbt få ut förändringar i produktion, men inte baserat på en falsk känsla av förutsägbarhet och kontroll utan baserat på vårt behov av att testa oss fram i en oförutsägbar verklighet.