R3 – den agila formeln

För ett halvt decennium sedan när jag skulle börja som utvecklingschef på Polopoly kände jag att jag behövde ett verktyg som hjälpte mig att sammanfatta andemeningen och de praktiska konsekvenserna av Agile, Scrum, XP och Lean. Var och en av dessa innehåller en rad – i viss mån överlappande – begrep, som är tydliga och om man kan dem inte så svåra att förklara – om man har många timmar på sig. Men hur minns man hela denna komplexa väv? Hur kan man uttrycka den enkelt, snabbt och koncist?

Något av det roligaste som finns är att skapa nya namn. Det kan vara allt från egennamn på en sak eller produkt till liknelser som beskriver en hel företeelse. Nya namn får bara betydelse om andra accepterar dem. Att namnge tingen och företeelserna runt oss är således i högsta grad också en social aktivitet. Samtidigt som vi skapar ett symboliskt universum binder det oss samman.

När jag först kom i kontakt med eXtreme Programming var en av aspekterna som tilltalade mig mest just den djupa epistemologiska och sociologiska lärdomen som ligger i betoningen av att utveckla en gemensam vokabulär som team och tillsammans med kund. Det är nu snart ett decennium sedan och jag har allt sedan dess försökt att vara medveten om hur viktigt det är att tillsammans namnge den gemensamma verkligheten.

Under flera år har till exempel metaforen “Go Green” haft en stor betydelse i mitt arbetsliv. Uttalad i rätt sammanhang var den fylld av mening, så som fokus på kvalitet, tester, visuell feedback, hårt arbete, ja, den fick till och med en historia, så som “Go Green III” (vilket i sig bar ytterligare mening och sammanhang som illustration av både allvar och frustration över hur svårt det är att alltid ha gröna tester). I vår grupp och i vårt sammanhang blev metaforen en del av vår kultur, som påverkade både vår mentala bild av verkligheten och vårt handlande i den.

Ett av skälen till att Scrum fungerar så bra och är så användbart är just den enkla och väl utvecklade och genomtänkta vokabulären. Ta ordet “Product Owner”. För det första fungerar det som ett abstrakt begrepp. Alla som lärt sig Scrum kan använda det i gemensamma diskussioner och mena (ungefär) samma sak. Men ordet är också en trop – en retorisk figur (antagligen en metonym) – som pekar ut över sig själv: begreppet i sig bär på en betydelse och pekar därmed utanför sig själv och in i ett större sammanhang: den som antar rollen att äga produkten i relation till de andra rollerna. Scrum har skapat ett begreppsligt universum som gör det enklare att flytta aktiviteten mellan olika grupper och sammanhang.

Ja, Scrum är på många sätt skapat som skelettet till en klassisk berättelse. Det finns en fix uppsättning roller, händelser och utkomster. Det gör det lätta att både minnas, föra vidare och använda för att koordinera och styra gemensamt handlande.

Enligt den alltid lika spännande kognitionsforskaren Peter Gärdenfors hänger antagligen berättande nära hop med uppkomsten av den moderna människan. Vi är inte Born to run utan Born to tell: “människans minne är gjort för att komma ihåg berättelser. Berättelser hjälper oss att få vår kunskap att hänga samman”. Kanske var det när vi samlades i värmen runt lägerelden som vi började berätta för varandra. Och det visade sig vara en evolutionär fördel.

Själv är jag också väldigt förtjust i att sammanfatta ett större komplext sammanhang i en formel eller ordlek. Genom att sammanfatta något i ett fåtal ord som också gå att minnas som ett eget uttryck eller just en formel skapar man stöd för minnet. Formeln blir som skalmans fantastiska skal, ur vilken en hel värld tycks gå att ta fram.

En populär och, tycker åtminstone jag, nyttig ordlek är uttrycket “SMARTA mål”. Poängen är att mål blir smarta om de är formulerade på ett sätt som karaktäriseras av de enskilda begrepp som tillsamman bildar ordet smart (Specifikt, Mätbart, Realistiskt, Tidsatt och Accepterat). Tack vara ordleken kan jag både komma ihåg att mål bör ha vissa egenskaper, komma ihåg vilka dessa är, och dessutom använda dem som måttstock när jag formulerar mål.

Sett ur det här perspektivet är således detta sätt att sammafatta något ett verktyg. Ett verktyg är något som gör det enklare att utföra en uppgift. Att skapa en nytt verktyg är därför en innovation som förenklar och förbättrar verkligheten. Drar vi detta till sin spets inser vi således att sätta ord på verkligheten och att sammanfatta komplexa sammanhang i begrep, ordlekar och formler är en social innovation, som är med och omformar vår verklighet.

Jag minns inte längre hur jag kom fram till metaforen R i kubik (R3) . Antagligen inspirerades jag av någon annan. Men sedan dess har formeln – utläst som en mening: “Rätt sak, på Rätt sätt, Regelbundet” – varit ett viktigt verktyg för att minnas, begripa, förklara och vägleda hur man bäst genomför en agil förändring och vad den går ut på. Jag tycker den fångar andemeningen i en agil organisation: att på ett uthålligt och repeterbart sätt skapa saker inriktat på högt affärsvärde (och en kvalitet som lever upp till alla aspekter av detta). Som sig bör med en fungerande formel går den att veckla ut.

Med Rätt sak fångas den centrala kundaspekten i alla de olika processerna och att de alla är värdedrivna: man tillverkar bara något som någon vill ha (Lean), det är produktägaren som prioriterar (Scrum) och behovet av ett nära samarbete med kunden (Agile och XP).

Men det går också att veckla ut ytterligare. Hur ska man exempelvis veta att man hela tiden skapar rätt saker? Jo, genom att ha korta feedbackloppar. Ju mer detaljerad man blir, desto mer pekar de olika R:en in i varandra. Korta feedbackloopar är ju också en viktig grund till att kunna utföra något Regelbundet. Jag tycker det är en fördel att begreppen länkar in i varandra, det gör dem starkare.

Under en period hade vi regelbundna kvalitetsseminarier. Under en sådan session tog vi hjälp av filosofen Imanuell Kant. Kant levde i Königsberg under 1700-talet. Tillsammans med Platon och Aristoteles är han antagligen tidernas mest inflytelserika filosof. Vid sidan av sina regelbundna promenader genom staden – så extremt regelbundna att det sägs att folket i staden ställde sina klockor efter dem – ägnade han sin kraft åt att reda ut vad man egentligen kan ha kunskap om. Detta formulerade han främst i sina tre “Kritiker”: Kritik av det rena förnuftet (naturvetenskap), Kritik av det praktiska förnuftet (etik) och Kritik av urskiljningskraften (estetik) – det sanna, det goda och det sköna eller ändamålsenliga.

Förenklat menade Kant att kunskapen inom olika typen av områden ser olika ut. Att till exempel ha vetenskaplig kunskap om något gör inte att samma kunskap legitimt kan användas för att motivera moraliska ställningstaganden. Eller omvänt: bara för att något är vackert behöver det inte vara sant. Genom avgränsning kunde Kant därmed – trodde han åtminstone, och många efter honom – skapa olika områden för kunskap med egna villkor för vad som gör kunskapen valid.

Jag tycker man ganska tydligt man kan koppla de olika kunskapsdimensionerna till kvalitativa aspekter hos respektive R-ord. Vi kan formulera en ny mening: “Någon vill använda det vi gör, det fungerar, vi kan göra det igen”

Varför vill någon använda det vi göra? Finns det en kvalitativ egenskap som gör till vi tillverkar till något åtråvärt? Jag tror man kan använda Kants koncept om sublimitet, åtråvärdhet och ändamålsenlighet här. Den kvalitativa aspekt vi till slut vill åt är kundens eller användarens känsla av att det vi gjort är bra. Ur ett systemutvecklarperspektiv sammanfattas detta i den dubbla omfattningen av att inte göra något som inte behövs (minimalism) och en upplevd integritet hos användaren (allt hänger ihop). (Jag erkänner dock villigt att man mycket väl skulle kunna tillämpa också det praktiska förnuftet här, och betonad begäret och, i senare praktiskt filosofiska tradition, nyttoaspekten).

Att det vi producerar också fungerar hänger starkt ihop med att vi arbetar på Rätt sätt. När vi pratar om kvalitet ur detta perspektiv menar vi således delvis något annat än ovan. Jag kopplar det starkare till den naturvetenskapliga dimensionen hos Kant. Att det vi gör hänger ihop, är stabilt, robust och mätbart. Att arbeta på Rätt sätt är därmed kopplat till många av de ingenjörsmässiga praktiker som utgör viktiga inslag i exempelvis XP: parprogrammering, testdriven uteckling och kontinuerlig integration. Betoningen på att inom bestämda tidboxar leverar användbara inkrement inom Scrum passar också väl in under begreppet, likväl som fokusen inom Lean på att bygga in kvaliteten i själva processen och stoppa bandet så fort en defekt dyker upp.

Om jag skulle sammanfatta den kvalitativt viktigaste kärnan i Rätt sätt i en enda fras skulle jag lyfta fram Fred Brooks gamla formulering “konceptuell integritet”. Precis som för upplevt integritet ur ett användarperspektiv handlar detta om enkelhet och att hänga ihop. Om upplevd integritet är den “yttre” kvaliteten i ett system, handlar konceptuell integritet om den “inre” kvaliteten i ett system. Den är både förutsättningen och slutmålet med alla andra aktiviteter vi ägnar oss åt för att skapa ett robust och hållbart system.

Regelbundet är ju närmast ett mantra inom Agile, Lean och Scrum. En aspekt av att kunna utföra något regelbundet är försås att det över huvud taget är möjligt att repetera uppgiften. Ju mer standardiserad eller automatiserad eller automatiserbar den är, desto enklare blir det att utföra något regelbundet. Just regelbundenheten är också kärnan i dessa empiriskt och adaptivt inriktade processer. Genom att utföra något i korta cykler genererar man hela tiden ny kunskap och information genom en tight feedbackloop, vilket i sin tur är förutsättningen för att hela tiden kunna göra Rätt saker, på Rätt sätt.

På ett djupare plan finns en etiskt dimension i detta, som för oss tillbaks till Kant och det praktiska förnuftet. Kant är antagligen mest bekant för sin formulering av det kategoriska imperativet: “Handla endast efter den maxim genom vilken du tillika kan vilja att den blir en allmän lag”. I kärnan av detta ligger repeterbarhet: om du beter dig på ett sätt som inte är hållbart om andra också beter sig på samma sätt så undergräver du till slut möjligheten att handla på just det sättet.

Om utvecklare – till exempel – konstant jobbar övertid kommer de till slut bli för utmattade för att utföra sitt arbete. Eller om vi hela tiden producerar defekt mjukvara, så kommer vi till slut inte ha tid för annat än bugghantering. Här kan vi också se en givande korskoppling med Rätt sätt. För om ingen vill ha det vi gör är det ju i slutändan svårt att få resurser till att forsätta göra det man gör. Fokus på kvalitet och inte minst in inriktningen på att hålla ett uthålligt tempo inom XP och Scrum är aspekter av Regelbundet.

Kant formulerade varianter av sitt imperativ. Till exempel skrev han: “Handla alltid så att du behandlar mänskligheten – dig själv och andra – som ett mål och aldrig som ett medel”. Det är svårt att hitta ett bättre uttryck för kärnvärdet i Agile och Lean: “Respect the people”.

Hållbar utveckling, kan vi väl kalla det.

Som jag redan skrivit har den agila formeln varit ett nyttigt verktyg när vi genomförde den agila förändringsprocessen på Polopoly. Man kan till och med att se hur de olika aspekterna dominerat under olika tidsperioder. Här är några exempel.

  • Regelbundet
    • Repeterbar process
    • Scrum
    • PO/SM
    • Retrospektiver
    • T3 – supportteam
    • Go green
    • Självorganiserande team
  • Rätt sätt
    • Förfining med Lean och XP
    • Tidboxade releaser
    • Arkitektroll och -grupp
    • Kodfokus och kodseminarier
    • Fixpacks
  • Rätt sak
    • Professionalism och domänkunskap
    • Kundvärde
    • Product Champions
    • Kundmöten
    • Fler involverade i backlog

Är R3 den enda formeln man behöver för att genomföra ett agilt förändringsarbete? Förstås inte. Den är som verktyg är mest, ett av flera möjliga för att lösa en uppgift och måste ofta kompletteras med fler verktyg. Ta en sådan enkel uppgift som att såga en planka. Personligen användar jag nästan alltid minst fyra verktyg: en tumstock, en vinkelhake, en penna och en såg. Så är det med den agila verktygslådan också. Även den enklaste uppgift kan kräva många verktyg, perspektiv eller infallsvinklar.

En sak som med tiden blivit tydligt med R3 är att den inte i tillräcklig utsträckning ger utrymme åt det oväntade och innovativa. Jag tycker samma problem delvis finns inbyggt i både Lean och Scrum. Det blir lätt ett väldigt fokus på att optimera själva processen, men för att lära sig något nytt måste man också få göra fel. Det är som Donald G. Reinhertsen skriver om informationsteori: “we can not maximize information generation by maximizing the success rate”. Eller med andra ord: en lärande organisation måste i betydande utsträckning misslyckas och göra fel. Och sedan systematisk tillämpa detta. Men det får jag nog återkomma till en annan gång.

Trots att detta minskar formelns universella giltighet kommer den fortsätta vara ett viktigt i min agila verktygslåda.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.