Scrum är en av metoderna som ingår i agil projektledning och utvecklades i slutet av 1980 talet och början av 1990 talet. Schwaber (2008) som är en av de två personer som ligger bakom Scrum anser att det inte handlar om en metod utan ett ramverk. En traditionell systemutveckling utgår ifrån att arbeta med krav som fördefinierads och som samtidigt fungerar som ett slutligt mål. Scrumramverket arbetar med mål genom att uppfylla prioriterade krav (Schwaber 2009). Det finns olika faktorer som kännetecknar Scrum. En av dem anses vara en hög grad av flexibilitet som präglas i hela utvecklingsprocessen. Det finns redan fastställda förutsättningar för att arbetet som utförs av utvecklingsteamet ska fungera som en enhet. En sådan enhet strävar efter att uppnå gemensamma mål. Enligt Takeuchi och Nonaka (1986) utgör det en viktig aspekt inom Scrum.
Det finns möjlighet att tillämpa Scrum under projektets gång på grund av att det innehåller en stor grad av enkelhet i sin förståelse och uppföljning. Bland andra faktorer som kännetecknar Scrum, ingår att det finns en betoning i att
kontinuerligt kontrollera och granska programvara (Takeuchi & Nonaka 1986). Hur utvecklingsarbetet utförs med Scrum tillämpning, visualiseras genom figur 3.
Att använda Scrum under utvecklingsarbete innebär en tillämpning av ett iterativt och inkrementellt tillvägagångssätt. Det tillhandahåller en kontinuerlig anpassning och inspektering av arbetsuppgifter under hela projektets gång. Arbetet är utfört av tvärfunktionella team, som innebär att utvecklingsteamet innehåller bara den kompetens som behövs för att utföra uppgiften (Schwaber 2009).
Utvecklingsteamet har för syfte att uppfylla krav som anges av kunden. Scrum använder tre viktiga roller som utmärker sig under utvecklingsperioden, Produktägaren, scrummastern och utvecklingsteamet (Schwaber & Sutherland 2011). Rollerna beskrivs i ett senare avsnitt för bättre förståelse av deras
betydelse. Författarna redovisar också att kraven som utvecklingsteamet uppfyller förmedlas genom en omfattande kommunikation mellan själva kunden och rollen som benämns för produktägaren.
Scrums grundare anser även att ramverket är utformat för att öka hastigheten på utvecklingen. Inom ramverket finns möjligheter som att anpassa individuella och organisationens mål, skapa en kultur som drivs av prestanda samt att stödja och skapa aktieägarvärde. Scrum tillhandahåller andra faciliteter som att uppnå en stabil och konsekvent kommunikation av prestanda på alla nivåer och sist men inte minst att öka individens utveckling och livskvalitet. Faktorerna utgör skillnaden mellan Scrum och andra agila metoder, där fokus ligger på hur projektet planeras och organiseras (Sutherland et al. 2007)
Roller i Scrum
Ett sätt som Scrum använder sig för att uppnå en bättre tillämpning, är
indelningen av alla deltagarna i olika roller. Rollerna rör aspekter kring ledning men också övervakning av projekt. Schwaber (2004) påpekar att rollindelning är nödvändigt för att processerna i Scrum ska fungera effektivt. Individerna som deltar i utvecklingsteamet har olika bakgrund och med en nödvändig kunskap som gör möjligt att kunna genomföra projektet. Därmed behöver inte
utvecklingsteamet att förlita arbetet till andra insatser (Schwaber 2004). Nedan beskriv utförligt de tre rollerna i Scrum.
Scrummaster
Det finns en betoning av de olika arbetsuppgifter som en scrummaster har och vilket ansvar denne har under projektarbetet. Beskrivelser av uppgifterna varierar, men de gemensamma faktorerna som tidigare studier redovisar, handlar om att scrummaster bär ansvaret för att se till att Scrum processen tillämpas och en vägledande person för utvecklingsteamet (Schwaber & Sutherland 2011). Skillnaden mellan en vanlig projektledare och scrummastern ligger i att
scrummaster har en mer stödjande funktion i projektet. Bland sina uppgifter ingår att kommunikationen inom laget övervakas, ser till att eventuella hinder tas bort med syfte att laget ska nå uppsatta mål för en sprint eller av projektet i sin helhet. Oenighet som kan förekomma inom utvecklingsteamet eller mellan laget och produktägaren ingår också i scrummasters arbetsuppgifter. Med andra ord ska scrummasters roll skapa förutsättningar för utvecklingsteamet att kunna genomföra aktiviteter som ökar varje inkrement (Sverrisdottirs et al. 2014). Scrummaster fungerar som en hjälpande hand som strävar efter att hitta fokus på projektmålen. Genom att vara en kanal mellan själva organisationen och
utvecklingsteamet, ser rollen efter att företagets politik inte påverkar produktiviteten i utvecklingsprocess (Schwaber & Beedle 2002).
Utvecklingsteamet
Judy och Krummins-Beens (2008) beskriver utvecklingsteamet som
yrkesmänniskor som arbetar ständigt för att leverera ett funktionellt, potentiellt användbart och realiserbart inkrement av en klar produkt i slutet av varje sprint. Individerna som ingår i utvecklingsteamet innehar befogenheter att själva bestämma hur arbetet ska organiseras och styras (Schwaber 2004). Därför anser Schwaber och Sutherland (2011) att utvecklingsteamet är självständigt och har mycket beslutsfattande om hur utvecklingsarbetet ska genomföras. De
befogenheter fastställs av själva organisationen med syfte att skapa förutsättningar till en resulterande energi som leder till effektivitet inom utvecklingsteamet. Produktinkrementet som utvecklas i varje sprint ansvarar utvecklingsteamet det är bara utvecklingsteamet som bidrar till det med sina arbetsinsatser och ingen annan utanför projektet.
Det finns några beskrivande egenskaper som Pichler (2010) har tagit fram som utmärker utvecklingsteamet. Den första är den nämnda självorganisationen i utvecklingsteamet som innebär att kunna garantera bättre effektivitet och
produktivitet under utvecklingsarbete. Det rekommenderas att utvecklingsteamet ska bestå av minst tre och högst nio deltagare. Författaren menar att om
utvecklingsteamet har mer än nio personer, krävs det en stor grad av koordination. Däremot om det finns mindre än tre personer kan det inte garanteras en bra
interaktion mellan varandra och därmed en minskad produktivitet. En annan egenskap för utvecklingsteamet, handlar om att skapa och utveckla
produktinkrement och att individerna innehar de kunskaperna som behövs. Därför sägs det att utvecklingsteamet bör vara tvärfunktionellt.
Det finns ingen betydelse av vilket typ av arbete deltagarna i utvecklingsteamet utför i sina uppgifter, alla är utvecklare. Det innebär att det inte finns individuella titlar. För att kunna göra det ännu tydligare finns det två viktiga regler som bör följas under utvecklingsarbete. Den första är att Scrum inte erkänner några del team inom utvecklingsteamet, vilket innebär att det inte får finnas team inuti utvecklingsteamet. Den andra regeln är att enskilda medlemmar i teamet kan ha specialkompetens och fokusera mer på vissa områden. Men ansvaret för att genomföra hela uppgiften ligger på hela utvecklingsteamet (Schwaber & Sutherland 2011).
Produktägaren
Rollen innefattar olika typer av ansvar under projektets gång. När företag
bestämmer sig för att tillämpa Scrum, tas det mycket hänsyn till att kunden arbetar som aktiv deltagare under hela utvecklingsprocessen. Produktägaren kan fungera som kundens representant, en länk mellan kunden och själva projektets
utvecklingsteam. Produktägaren bär ansvaret för att maximera värdet av
produkten och utvecklingsteamets arbete (Schwaber & Sutherland 2011). Genom en öppen kommunikation med scrummastern, förmedlar de förändringarna i kraven under arbetsgång. Det ligger också över produktägarens axlar att hantera en produktbacklogg som innehåller allt som utvecklingsteamet ska genomföra i
projektet. Med andra ord produktägaren bär ensam ansvaret att bestämma vad som ska göras under utvecklingsarbetet.
Schwaber och Sutherland (2011) hänvisar att produktbackloggen är
produktägarens ansvar. Användningsfall är ett lättare sätt att kunna framställa produktbackloggen, på grund av att det handlar om beskrivelser från aktörernas synvinkel. Beskrivelserna är krav som sedan utgör en samling aktiviteter som ger ett konkret, och påtagligt resultat. Det gäller att användningsfallen ska beskrivas så tydligt som möjligt och på ett lättförståeligt sätt. Användningsfallen ska
prioriteras först för att sedan bearbetas. Produktbackloggen ska vara synlig för alla medlemmar och kunden i projektet och ska visa vad utvecklingsteamet ska arbeta med härnäst.
Författarna poängterar också att produktägaren handlar om enbart en person. Kunden själv kan vara produktägare eller utse någon annan som representerar organisationen. Organisationers styrelse ska respektera alla beslut som intas av produktägaren. Det skapar förutsättningar för framgång med produktbackloggen. Utvecklingsteamet ska genomföra utvecklingsarbete utifrån de krav som finns i produktbackloggen och inte något annat. En annan fördel med att produktägaren själv bär befogenheterna ovan, ligger i att det är lättare att kunna styra projektets riktlinjer genom bättre krav prioritering. Det leder till en balans mellan kraven, fatta ta beslut och därmed bättre resultat (Sverrisdottir et al. 2014).
Det finns olika jämförelser mellan produktägaren och traditionella roller som produktchef eller projektledare. En mer traditionell projektledare tar hand om hela projektet, medan produktbackloggen fungerar som ryggraden i produktägarens aktiviteter för ett bättre samarbete med scrummaster, utvecklingsteamet och projektets intressenter. Sverrisdottir et al. (2004) redovisar att det finns ett behov av ett nära samarbete mellan produktägaren och utvecklingsteamet, på grund av att den ena ska förmedla krav och ändringar i produktbacklogget och den andra ska utföra utvecklingsarbetet.
Produktägarens egenskaper
Pichler (2010) menar att produktägarens roll bör inneha några väsentliga
egenskaper för att lyckas med sitt arbete. Kommunikations förmåga och vara bra i förhandlingar. Dessutom måste rollen inneha tillräckligt med auktoritet och stöd från företagsledningen att leda utvecklingen i projektet. Det kan leda till bättre samordning över intressenternas önskemål. Det nämns också att det ska finnas en stor tillgänglighet från produktägarens sida men också förmågan att förmedla visionen med projektet.
Schwaber (2004) anser att visionen kring produktägaren ska reflektera varför projektet ska genomföras men den speglar också det önskade sluttillståndet. För att lyckas bättre med förmedlingen, bör produktägaren vara konkret i
beskrivningen av gemensamma mål att uppfylla under utvecklingsarbete.
Samtidigt ska produktägaren sträva efter att förmedla visionen i generella termer för att inte hindra kreativitet hos utvecklingsteamet. Pichler (2010) uttalar också att andra aspekter som är tydliggörande av vilka som är kunder, deras behov och hur är det tänkt att möta deras krav ska ingå i visionens beskrivning. Förutom de nämnda egenskaperna ovan, krävs det att produktägaren ska ha breda kunskaper
om teknik, marknad och affärsprocesser (Softhouse 2012). Kunskaperna är användbara för att få en bättre prestanda i de tre nyckelområden som
produktägaren berör; det första nyckelområdet är grundläggande förståelse för kundens behov, den andra är god kommunikation med samtliga intressenter, och den tredje är att produktägaren ska ha grundläggande kunskap om hur
programvara utvecklas och levereras (Pichler 2007).
Artefakter i Scrum
Scrum strävar efter att garantera en hög grad av tydlighet och därmed
tillhandahålla inspektion och anpassning under hela utvecklingsarbetet. Därför anser Schwaber och Sutherland (2011) att aspekterna kan nås genom tre olika artefakter. Produktbackloggen, sprintbackloggen och inkrementen är artefakterna som bidrar till tydligheten i ramverket.
Inkrement
Schwaber och Sutherland (2011) beskriver inkrementet som alla färdiga
aktiviteter från produktbackloggen som utvecklingsteamet har lyckats att utföra under varje sprint. Alla aktiviteter ska uppfylla funktionalitet i mjukvaran som ska vara användbar för produktägaren. Inkrementet är en delleverans som utförs efter att testning och dokumentation genomförts efter varje sprint. Att Scrum levererar ett kontinuerligt produktinkrement syftar till att tillhandahålla värde till kunden. Strävan finns också kring att kunden ska kunna ge återkoppling på det som levereras. Pitchler (2010) hävdar att återkopplingen för varje inkrement möjliggör tidsbesparing, eftersom utvecklingsteamet inte behöver implementera onödig eller felaktig funktionalitet i programvaran.
Dagligt Stå-upp-möte
Mötet kan jämföras som en slags lägesrapport som ska ta upp 15 minuter varje dag. Det är ett sätt att hålla utvecklingsteamet uppdaterad om hur arbetet går framåt. Pope-ruak (2012) redovisar att tre viktiga frågor ställs under träffen: vad gjorde du igår? vad kommer du göra idag? samt har du stött på några hinder? Det strävas efter att få svar bara på de frågorna även om det finns andra relevanta detaljer. Mötet ingår i utvecklingsteamets rutiner vilket innebär att det bör ske kontinuerligt, helst varje dag. Sprintarna innehåller interaktioner på 24 timmar. Det medför att varje interaktion som påbörjas, inleds med ett stå-upp möte (Schwaber 2009). Alla som deltar i utvecklingsteamet ska redovisa hur det går med arbetet. Det betyder att allas närvaro är viktigt för att skaffa en gemensam bild av progress samt att ta vara på information som kommer från kollegorna.
Produktbacklogg
Det är produktägaren som ansvar för upprätthållande av produktbackloggen. Inom traditionell projektledning framställs en kravspecifikation med allt som projektet är menat att leverera. I Scrum kan produktbackloggen jämföras med en sådan specifikation. Backloggen innehåller en lista av allt är mjukvara behöver för att bli användbar. Det fungerar också artefakten som underlag för beslutsfattande
angående förändringar som kan uppstå under projektets gång (Schwaber & Sutherland 2011).
Produktbackloggen tas fram genom att kunden specificerar vilken typ av produkt det är som organisationen behöver. Efteråt presenteras de i en prioriterad lista som scrummaster och utvecklingsteamet tar del av. Produktägaren bygger
produktbackloggen på olika typer av användningsfall om hur produkten ska fungera. Schwaber och Sutherland (2011) menar att användningsfall är ett effektivt redskap för att enklare förklara vad utvecklingsteamet ska utföra under utvecklingsprocessen. Det är ett sätt att kunna ha en övergripande bild av hela projektets livscykel. Det är inte enbart krav som bygger produktbackloggen, utan det olika egenskaper, funktioner och förbättringar att utföra för mjukvaran. En annan aspekt som utmärker backloggen handlar om att den utgår från ett värde, risk, prioritet och behov.
Sprintbacklogg
Produktbackloggen fungerar som utgångspunkt för att kunna framställa
sprintbackloggen. Det handlar om en förteckning över uppgifter, tidsestimering och uppgiftsansvariga individer (Schwaber 2009). Det utgör en plan för alla kommande arbetsuppgifter som ska utföras under en sprint, där det levereras inkrement. En sprint är iterationer som sker under utvecklingsperioden. Längden till varje sprint är normalt fyra veckor men det kan variera beroende på varje enskilt projekt. I varje sprintplanering måste det finnas en anpassning till vad som utvecklingsteamet kan hantera under en sprint. Schwaber och Sutherland (2011) anser att det handlar om en prognos som utvecklingsteamet förutsäger om vilken typ av funktionalitet ska ingå i varje inkrement, samt vilka arbetsuppgifter uppfyller den bestämda funktionaliteten. I själva verket är det utvecklingsteamet som bestämmer vad som ska ingå i varje sprintbacklogg och utgöra förändringar i den.
Sprintplaneringsmöte
Det är ett tidsbegränsat åtta timmars möte som utdelas i två segment på fyra timmar. Alla samtliga roller i projektet deltar i sprintplaneringen. Det finns också möjlighet för andra intressenter att kunna närvara i mötet. Däremot får deras deltagande bara har ett informativt syfte (Blankenship et al. 2011). Författarna redovisar också att inför planeringen har produktbackloggen aktualiseras och prioriteras av produktägaren i samråd med själva kunden och scrummastern. Eftersom mötet är indelat i två segment, används det första segmenten för att föra aktiviteter från produktbackloggen till den kommande sprintbackloggen.
Abrahamsson et al. (2002) hänvisar att under sprintplaneringsmötet väljs uppgifter ut som utvecklingsteamet kommer att implementera under sprinten. Det finns några faktorer att beakta för planering. De bestämda aktiviteterna som ska ingå i sprinten framställs genom en öppen dialog mellan produktägaren och
utvecklingsteamet. Schwaber (2009) redovisar att utvecklingsteamet ska prioritera vad som kan utföras under en sprint där det ska garanteras en inkrementell
funktionalitet. Det med syfte att kunna presentera en klar produktdemonstration i slutet av sprinten. Det är produktägaren som har mandatet att bestämma vilka aktiviteter som ska föras från produktbackloggen till sprintbackloggen. Det finns också utrymme för återkoppling från utvecklingsteamet i form av avsikter och rekommendationer om vad som kan vara bäst att utföra under nästkommande sprint (ibid).
Den andra delen av planerings mötet är ägnat till utvecklingsteamet. Syftet är att kunna föra en intern diskussion om arbetsuppgifterna som ingår i sprinten för att sedan delegera vem som gör vad. Resultatet av segmentet är sprintbackloggen. Schwaber (2009) hänvisar till att under den här delen av möte sker ett ombytes mandat. Utvecklingsteamet bestämmer hur arbetsuppgifter kommer att utlösas.
Sprintgranskningsmöte
Efter att varje sprint avslutas ska ett fyra timmars sprintgranskningsmöte äga rum. Mötet inleds med en timme demopresentation som utvecklingsteamet förbereder. Presentationen ska redovisa de inkrementen av produkten för produktägaren samt andra intressenter och kunden(Schwaber 2009). Däremot hänvisar författaren att “klar funktionalitet” kan innebära olika från projekt till projekt. Det gäller att komma överens med produktägaren vilken typ av nivå den klara funktionalitet ska innehålla. Syftet med överenskommelsen ligger i att på så sätt ge kunden en mer realistisk uppfattning om den nuvarande produkten (Törnkvist & Kjellberg 2013). Under den andra delen av mötet görs det en avstämning om aktiviteterna som fördes från produktbackloggen har utförs och stämmer överens med
sprintbackloggen. Det leder till att få en överblick och kunna jämföra aktiviteterna med det som presenteras i demonstrationen. Mötet avser också att ta fram ifall arbetsuppgifterna som utfördes blev enligt planeringen samt eventuella problem som förekom under sprinten (Schwaber 2009). Författaren hävdar att
granskningsmötet också ger utrymme till återkoppling från intressenter och produktägaren i form av frågor och kommentarer. En sådan återkoppling är utgångspunkten för hur den kommande sprinten ska utformas i form av prioriterade arbetsuppgifter från produktbackloggen.
Sprintretrospektiv
Inom Scrum är återkoppling viktigt för varje interaktion som genomförs under utvecklingsarbetet. Därför är mötet ägnat till att göra en utvärdering om hur det gick under varje sprint. Alla rollerna i projektet deltar i retrospektivet och kommer fram med nya idéer och synpunkter om hur kommande interaktioner kan
förbättras (Schwaber 2009). Derby och Larssen (2007) redovisar att förbättringar kan gälla förhållanden, människor, verktyg eller processer i varje sprint. På så sätt kan diskussionen fungera som ett underlag för eventuella anpassningar i
kommande sprintar beroende på sammanhang. Det rekommenderas att
sprintretrospektiv ska vara i högst tre timmar för bättre diskussion och reflektion. En annan typ av rekommendation som Derby och Larssen (2007) uppger, handlar om att följa fem enkla steg under momentet. Stegen går ut på att skapa stämning för diskussion, datainsamling, insikt skapelse, beslut om vad som ska göras och avsluta retrospektivet.
Det är scrummaster som tar ansvaret för att leda mötet, samtidigt som denne måste vara observant på hur dynamiken utvecklas under momentet. För ett bättre flöde och att alla ska komma till tals, ska scrummaster se till att det ska finnas ett öppet diskussionsklimat där alla har utrymme att uttrycka sig (Derby & Larssen 2007). Det betyder att en balans måste finnas under hela retrospektiv genom att kontinuerlig följa de redan nämnda stegen. När det gäller datainsamlingen ska samtliga individer ta hänsyn till båda hård och mjuk data. Hårddata avser
aktiviteter som utfördes från backloggarna vilket avser olika upplevelser eller känslor från deltagarna i utvecklingsteamet de mjuka värdena.
Derby och Larsen (2007) redovisar också att datainsamlingen är möjligt genom att utvecklingsteamet svarar på sex enkla frågor:
1. Var det något speciellt du uppmärksammade? 2. Vad förvånade dig?
3. Vilka utmaningar mötte du på under sprinten?
4. Vilka erfarenheter samt insikter tar du med dig från sprinten? 5. Vad berättar de om det aktuella projektet?
6. Nämn en sak som du skulle vilja göra annorlunda?
När alla deltagarna har svarat på frågorna kan det göras en sammanställning som bidrar till att skapa en gemensam bild för eventuella problem och hur dem kan påverka kommande arbetet. Att skapa en sådan bild av situationen skapar möjligheten till förändringar som kan tillämpas i kommande sprint samt en förståelse om andras förhållanden (Schwaber 2009). För att sprintretrospektiv ska kunna avslutas är det viktigt att samtliga ska komma överens om vilka åtgärder som ska vidtas samt hur dem ska uppföljas och dokumenteras. Däremot anser Shore (2008) att för att få bättre effekt med åtgärderna ska utvecklingsteamet avgränsa sig till bara implementera för den kommande sprinten.
Fördelar och nackdelar med Scrum
Tillämpningen av agila metoder varierar från metod till metod. Däremot delar de samma fördelar i deras användning gällande kommunikation, kundinvolvering, iterationer och självorganiserade team. Förutom de delade fördelarna med andra