PNEHM!

Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling

Tobias Fors som använt, infört och lärt ut Scrum till

dussintals företag och hundratals personer sedan 2003
är en av Sveriges mest erfarna scrumkonsulter och
Certified Scrum Trainer för amerikanska Scrum Alliance.
tobias.fors@citerus.se

Klart och oklart

– om Scrum och kvalitet
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å.

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 reducera den interna produktkvaliteten är nog
ganska ovanliga, tack och lov. Vanligare är att saker som läsbar kod och design som går att underhålla
blir lidande eftersom kompromisser med dessa egenskaper 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ägba-
ra 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 has-
tigheten. 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 ome-
delbar lindring av symptomen. Det andra alternativet går på djupet, och angriper själva källan till pro-
blemet, 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

1 ! Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors www.citerus.se
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling

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 ty-
vä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 tan-
kar 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”-fenomenet ä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 På samma sätt som vi kan bli beroende
kvalitetsgenvägar som ett sätt att snab- av värktabletter när vi egentligen borde
ba upp utvecklingsarbetet. Det funge- stressa mindre kan vi bli beroende av
rar nämligen utmärkt. En kort stund.
På lång sikt är det en förödande strate-
andra saker. En sådan sak är att använda
gi, av samma anledning som det är kvalitetsgenvägar som ett sätt att snabba
dumt att använda värktabletter för ofta. upp utvecklingsarbetet.
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 änd-
ras. 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 sa-
ker än vanligt i den här sprinten borde ni kunna göra det i nästa också, och det visar sig stämma. Dis-
kussionen om att projektet hade problem börjar nu dö ut - ni har ju visat vad ni går för. De som satte
tryck på er 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 implemen-

2 ! Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors www.citerus.se
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling

tera den nya funktionaliteten stöter ni på patrull. Stora delar av koden är kopierad istället för återan-
vä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
I normala fall tar det många månader
som har hänt. För varje genväg ni tog ökade
komplexiteten i produkten en smula. I bör- innan problemen med det vi kan kalla
jan ledde det inte till några större problem, kvalitetsskulden blir så tydliga att man
och eftersom ni minskat på testningen för inser att något måste göras - och då
att kunna bygga fler funktioner kunde dessa
små problem smita mellan springorna. Allt är det ibland redan försent.
eftersom de blev fler ökade problemen ty-
vä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 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. Det-
ta ä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åtspi-
ral.

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 manu-
ellt, särskilt om det är mer än vad man åstadkommit det senaste året. Det är en bra start, men om pro-
jektet ska kunna leverera en kvalitetsprodukt i tid måste man snart höja ribban och inkludera mer am-
bitiös testning och automatisering i klarkriteriet. Detta kallar vi för “det växande klarkriteriet” - man
kan alltid bli lite mer klar redan vid sprintens slut.

3 ! Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors www.citerus.se
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling

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 fak-
tiskt 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. Även om vi själva är experter på mjukvaruutveckling och förstår
konsekvenserna av att inte testa tidigt, ordentligt, och frekvent, finns det en överhängande risk att de vi
jobbar åt inte har samma förståelse - och det kanske vi inte kan klandra dem för. I vårt jobb som profe-
sionella utvecklare måste ingå att förklara vad som krävs för att framgångsrikt utveckla mjukvara. I den
mån de vi arbetar med inte förstår vad som krävs för att lyckas är det vårt jobb att hjälpa dem att lära sig
mer.

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örkla-
ringar om vad som inte var klart kommer inte fastna på samma sätt. Det är därför vi i Scrum 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ändarmanua-
ler 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örnuftiga 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å projektets kritiska linje om vi lägger det sist, och löper
där mångfalt större risk att kapas för att leveransdatumet ska hållas. Det gäller förstås inte bara doku-
mentationsarbete. 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.

4 ! Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors www.citerus.se
PNEHM!
Citerus nyhetsbrev för dig som vill lyckas med mjukvaruutveckling

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 sprin-
ten 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 produk-
tens grafiska profil.

Som Scrum Master kan man bjuda in hela teamet och produktägaren till ett arbetsmöte för att resonera
kring vad som går att göra inuti sprinten. Målet är att etablera ett effektivt klarkriterium som alla fak-
tiskt tror på och accepterar att arbeta mot. Oftast är alla parter överens om att det vi siktar mot är ett
klarkriterum som både ger bra resultat i sprinten och lägger en bra grund för kommande sprintar och
leveranser. Det första klarkriterum vi jobbar fram tillsammans kan vi sedan vidareutveckla sprint för
sprint, genom att hitta nya sätt att minska mängden oklart arbete efter sprinten.

Det svåra med att upprätta ett klarkriterium är inte att skriva ned en teoretiskt perfekt lista. Det be-
hä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ör-
måga faktiskt är, och dessa två faktorer samspelar. Genom att till exempel automatisera våra byggpro-
cesser kan vi kontinuerligt bygga hela vår produkt fortlöpande under sprinten. För ett team som be-
hä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 inte är någon bra idé att inkludera fullständiga integrationsstester i sprinten,
eftersom det skulle kosta så mycket. Lösningen här behöver 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 mjukvaruutveckling.

5 ! Januari 2009. Klart och oklart - Om Scrum och kvalitet. Tobias Fors www.citerus.se