2009-01-20 — Tobias Fors
Ett av nyckelvärdena i Scrum är att undvika att försöka öka hastigheten genom att göra kontraproduktiva kompromisser med produktens interna kvalitet. Tobias Fors har tagit en titt på varför kvaliteten på insidan av mjukvaran ibland får ge vika i utvecklingsprojekt, och vilka konsekvenser det kan få.
“If you don't care about quality, everything else is trivial"
-- Jerry Weinberg´s First Law of Software Engineering
Kvalitet är ett begrepp som väcker känslor. Ordet kvalitet kan användas som ett moraliskt slagträ, som i “Du är ju inte intresserad av kvalitet". Omvänt fungerar också. “Inget mer finslipande, nu är det fulhack som gäller", som jag fick höra av en projektledare en gång.
Den typen av helt öppna försök att öka farten genom att sälja ut kvaliteten är nog ganska ovanliga, tack och lov. Vanligare är att kvaliteten blir lidande eftersom det ses som den enda snabba vägen framåt. Om tid, kostnad och omfång är fixerade i en ouppnåelig målbild måste någon annan parameter ge vika. Då blir det kvaliteten som får böja sig.
Det farliga med att använda kvaliteten som ett styrverktyg är att det resulterar i extremt svårförutsägbara konsekvenser. Konsekvenserna är svåra att förutsäga av minst två anledningar. Dels kan det dröja innan de manifesterar sig, så när de väl dyker upp är det sällan uppenbart vad som orsakat dem, och därför svårt att veta hur man ska angripa dem. Dels hopar sig problemen inte med en långsam linjär takt, utan snabbt och icke-linjärt - med andra ord blir det snabbt värre när det väl blir värre.
Systemtänkare har ett namn för det fenomen som inträffar när vi prutar på kvaliteten för att öka hastigheten. De kallar det för “shifting the burden", och det fungerar så här: ett symptom på ett problem uppenbarar sig, och det är tydligt att något måste göras. Två olika lösningsalternativ finns tillgängliga, det ena med en uppenbart snabbare effekt än det andra. Detta alternativ ger en mer eller mindre omedelbar lindring av symptomen. Det andra alternativet går på djupet, och angriper själva källan till problemet, men har den svagheten att det tar längre tid att genomföra. Ofta väljer vi det snabbare, ytligare, alternativet. När vi på det sättet lindrar symptomen minskar vi också trycket att gå på djupet och lösa grundorsaken till problemet - problemet är ju ur världen just nu, och vi har andra mer akuta saker att ägna oss åt. Som om inte detta vore nog har den snabba lösningen ofta en sideffekt - den minskar ofta vår förmåga att ta oss an det underliggande problemet.
Ett exempel kan vara följande. Tänk dig att du lever ett aktivt liv med en fullbokad kalender, men tyvärr då och då drabbas av ryggont - en inte helt ovanlig situation. Du vet att du borde gå till botten med problemet, träffa en doktor, kanske träna mer och stressa mindre, men att göra alla de sakerna kräver både tid och energi som du inte har just nu. Istället äter du en kraftfull smärtstillare när värken slår till, och den ger dig lindring nästan omedelbart. När väl det onda är borta för tillfället försvinner dina tankar på att du borde träffa en doktor, och du kan ta dig an din fulla kalender med ny kraft. Värktabletten har en bieffekt också. Ju oftare du äter den, desto lägre blir din tolerans för att ha ont i ryggen, vilket gör dig ännu mer benägen att snabbt äta en värktablett när du får ont, och ju snabbare du äter tabletten, desto snabbare försvinner inte bara ryggvärken, utan också dina tankar om att verkligen gå till botten med problemet.
“Shifting the burden"-fenomet är en typ av beroendemönster. På samma sätt som vi kan bli beroende av värktabletter när vi egentligen borde stressa mindre kan vi bli beroende av andra saker. En sådan sak är att använda kvalitetsgenvägar som ett sätt att snabba upp utvecklingsarbetet. Det fungerar nämligen utmärkt. En kort stund. På lång sikt är det en förödande strategi, av samma anledning som det är dumt att använda värktabletter för ofta.
Att bli beroende av att sänka kvaliteten för att öka hastigheten är något som sker över en längre tid.
Tänk dig att du jobbar i ett projekt. Ni har ont om tid i projektet, men leveransdatumet kan inte ändras. Inte heller kan leveransens omfång ändras, och budgeten ligger fast sedan länge. Något måste göras, men vad? Utan att egentligen fatta ett explicit beslut börjar ni skära ned på aktiviteter som att städa i koden, att tänka igenom era designbeslut och att testa det ni bygger. Det ger resultat snabbt. Ni hinner med fler saker än vanligt de närmaste veckorna. Er signal till omvärlden är tydlig. Hann ni med fler saker än vanligt i den här sprinten borde ni kunna göra det i nästa också, och det visar sig stämma. Diskussionen om att projektet hade problem börjar nu dö ut - ni har ju visat vad ni går för. De som satte tryck har fått vatten på sin kvarn, det behövdes ju vare sig en kapning i omfånget eller mer tid och pengar. Allt som behövdes var lite gammalt gott jädrar anamma.
Tyvärr blir glädjen inte så långvarig. I nästa iteration tar ni som vanligt på er ett rejält sjok arbete, plus lite till (utmanande mål är ju bra). Men den här gången blir det inte som tidigare. När ni ska implementera den nya funktionaliteten stöter ni på patrull. Stora delar av koden är kopierad istället för återanvänd, och ni måste lösa samma problem på flera olika ställen. När ni försöker lösa problemen märker ni att nya problem dyker upp på till synes helt orelaterade platser i koden. De dyker upp i en sådan takt att ni snart förstår att ni orsakat många fler defekter som ni ännu inte upptäckt. Vissa saker ni tar er an klarar ni inte av att avsluta över huvud taget, så ni blir tvungna backa ur vissa ändringar ni påbörjat.
Resultatet är förödande. Från toppfart till snigelfart på kort tid, men ni förstår vad som har hänt. För varje genväg ni tog ökade komplexiteten i produkten en smula. I början ledde det inte till några större problem, och eftersom ni minskat på testningen för att kunna bygga fler funktioner kunde dessa små problem smita mellan springorna. Allt eftersom de blev fler ökade problemen tyvärr snabbare och snabbare. Varje ny ökning av komplexiteten interagerade med tidigare försämringar så att effekten blev icke-linjär. Det var därför ni blev så överraskade när problemen plötsligt verkade hopa sig.
Nu när ni äntligen insett vad ni ställt till med vill ni sänka tempot och återställa kvaliteten i produkten. Dessvärre har ert laborerande med kvaliteten fått en bieffekt. De ni jobbar åt har lärt sig att om man ber om högre hastighet så får man det. När ni försöker förklara vad som hänt stirrar de bara förbluffat på er. Ni har ju bevisat flera gånger tidigare att ni kan hålla ett högt tempo. Uppenbarligen, säger man, har ni haft vissa tillfälliga problem den senaste tiden, men ni har ju visat tidigare att det går att lösa om ni ger er sjutton på det. Håglösa kavlar ni upp tröjärmarna och beger er tillbaks till era arbetsplatser.
Historien kanske låter överdriven, och det är den i varje fall i en aspekt. I normala fall tar det många månader innan problemen med det vi kan kalla kvalitetsskulden blir så tydliga att man inser att något måste göras - och då är det ibland redan försent.
Ett av målen med Scrum är att förhindra att vi hamnar i denna prekära situation till att börja med. Detta är anledningen till att vi trycker så hårt på att definiera ett tydligt och överenskommet klarkriterium. Vårt mål är att hålla kvalitetsribban högt, så att vi undviker att hamna i den dåliga kvalitetens nedåtspiral.
Klarkriteriet är inte statiskt, utan behöver förädlas över tiden. Ett team som precis börjat använda Scrum kanske är nöjda om den första sprinten resulterar i lite mjukvara som man hjälpligt testat manuellt, särskilt om det är mer än vad man åstadkommit det senaste året. Det är en bra start, men om projektet ska kunna leverera en kvalitetsprodukt i tid måste man snart höja ribban och inkludera mer ambitiös testning och automatisering i klarkriteriet. Detta kallar vi för “det växande klarkriteriet" - man kan alltid bli lite mer klar redan i sprinten.
Om en sprint slutar i funktionalitet som inte är helt levererbar återstår arbete att göra. Allt detta arbete är oklart. Det måste göras förr eller senare. Det förrädiska med oklart arbete är, att ju längre vi väntar med att göra arbetet, desto längre dröjer det innan vi får reda på exakt hur mycket arbete det rörde sig om, och exakt vilken ny information som uppenbarar sig när arbetet väl görs. Dessutom riskerar vi som historien ovan försökte illustrera att övertyga omgivningen om att vi kan jobba snabbare än vad vi faktiskt mäktar med. Även om vi förklarar så tydligt vi kan under sprintuppföljningen att systemet inte är fullständigt testat riskerar vi detta. Vi må vara experter på mjukvaruutveckling som förstår konsekvenserna av att inte testa tidigt, ordentligt, och frekvent, men det finns en överhängande risk att de vi jobbar åt inte har samma förståelse - och ska väl knappast behövas? I vårt jobb som profesionella utvecklare måste ingå att förklara vad som krävs för att framgångsrikt utveckla mjukvara.
Om vi visar mjukvara för personer som inte själva utvecklar, och mjukvaran ser ut att fungera, då är sannolikheten hög att de kommer att minnas en demonstration av klar mjukvara. Våra krångliga förklaringar om vad som inte var klart kommer inte fastna på samma sätt. Det är därför vi har som tumregel att bara presentera mjukvara som verkligen är potentiellt levererbar - alltså mjukvara som kan levereras ut för användning med relativt lite efterarbete efter sprintens slut.
Det vanligaste argumentet för att inte göra vissa moment i sprinten, till exempel skriva användarmanualer eller onlinehjälp, är att det inte lönar sig, eftersom omarbetet blir så stort (“då måste vi ju skriva om manualen i varje sprint"). Det första vi ska komma ihåg är att iterativt arbete i viss mån är en strategi för hantering av omarbete. Vi väljer att ta en viss kostnad för att göra om saker, och för det priset får vi snabbare en potentiellt leverbar produkt plus mer fullständig information om hur arbetet går, två mycket viktiga faktorer för framgång som vi inte vill vara utan.
Om vi vill kunna svara på om något inte lönar sig att göra i sprinten måste vi alltså dels fundera på om vi verkligen kan ta hem nyttan när vi vill göra det, dels på om vi utsätter oss för en risk genom att vi inte lär oss om saker vi borde lära oss om redan idag.
Lyckligtvis behöver valet sällan vara svart eller vitt. Vi kan arbeta fram förnufitga medelvägar där vi gör en del av arbetet i sprinten, och en del av arbetet precis innan leverans. Detta är en mer konstruktiv väg framåt än att helt utelämna en viss typ av aktivitet ur sprinten.
Att till exempel utelämna skrivandet av manualer helt ur sprinten leder till att vi kan ha väldigt mycket oklart skrivarbete att göra innan vi har en produkt som slutanvändaren kan dra nytta av. Arbetet med att skriva dokumentation hamnar dessutom på den kritiska linjen om vi lägger det sist, och löper nu mångfalt större risk att kapas för att leveransdatumet ska hållas. Det gäller förstås inte bara dokumentationsarbete. De som har jobbat med testning i traditionella sekventiella projekt brukar vara smärtsamt medvetna om fenomenet att det aldrig finns tillräckligt mycket tid för test.
Att exkludera arbete ur sprintarna leder också till en ökad risk att vi lär oss viktiga saker för sent. En teknisk skribent som tar sig an manualskrivandet sent i utvecklingen kan upptäcka att produkten är nästan obeskrivbar. Om skrivandet åtminstone hade gjorts på utkastnivå som en del av arbetet i sprinten så hade vi kunnat styra utvecklingen i rätt riktning - mot en mer lättanvänd produkt. Precis innan leverans hade vi sedan kunnat göra den slutliga formateringen av manualerna i enlighet med produktens grafiska profil - och vi hade på det viset undvikit kostnaden för att göra om åtminstone det sista momentet i varje sprint.
Genom att som Scrum Master bjuda in hela teamet och produktägaren till ett arbetsmöte där vi resonerar kring vad som går att göra inuti sprinten för att vi ska få maximal leveransförmåga och lära oss maximalt varje sprint, så kan vi lättare etablera ett effektivt klarkriterium som alla faktiskt tror på och accepterar att arbeta mot. Detta klarkriterum kan vi sedan vidareutveckla genom att dra in mer och mer arbete i sprinten.
Det svåra är inte att skriva ned ett perfekt klarkriterium, det behärskar de flesta med några års erfarenhet. Det svåra är att faktiskt jobba så att man lever upp till sitt klarkriterium. Vad som kommer att göras i sprinten styrs av vad vi är villiga att göra och av vad vår förmåga faktiskt är, och dessa två faktorer samspelar. Genom att till exempel automatisera våra byggprocesser kan vi kontinuerligt bygga hela vår produkt fortlöpande under sprinten. För ett team som behärskar konsten är detta trivialt och självklart. Ett team som inte gör det kan å andra sidan argumentera länge och väl för varför det är en dum idé att inkludera fullständiga integrationsstester i sprinten, eftersom det skulle kosta så mycket. Lösningen här måste inkludera en höjning av teamets kompetens på något sätt, kanske genom en kombination av utbildning, coaching och inhyrd expertis. Alternativet är att sprint efter sprint bygga en produkt som inte är klar, och att satsa sina pengar på att den verkligen går att göra klar någon gång i framtiden. Ibland visar det sig stämma, ibland inte, men gissningar och hopp är ingen bra strategi för framgångsrik utveckling.
