Problemlistan nedan är en sammanställning av tidigare forskares problemdefinitioner kopplade till Scrums praktiska användning.
För att kunna definiera problemen har grundliga litteraturstudier gjorts och specifika problem har handplockats och presenterats nedan. Samtliga studier är kopplade till Scrums praktiska användning och tillämpning och är relevanta för studien. Det finns med största sannolikhet fler problem kopplade till området, men med tanke på tidsomfattningen har inte fler hunnit konkretiserats.
Nedan följer en lista med problemen, samt en kort sammanfattning från studien de är hämtade från. Förklaringen ger en insikt kring forskarens tankegångar gentemot definitionen.
Problemdefinition Författare/forskare Förklaring 1. Avsaknad av studie
gällande kravinsamling
Amiri (2012) Scrum saknar en omfattande studie om användarens krav och metoden tar inte heller någon hänsyn till användarens behov av användbarhet. Amiri menar på att utvecklingsteamet på grund av detta har svårt att få en helhetssyn på produkten och den önskade statusen på den.
2. Stöd för långsiktigt fokus
Fogelström et al. (2009) Scrum saknar stöd för ett övergripande långsiktig fokus på produktutvecklingen, då detta inte finns med som en konkret punkt att utgå ifrån.
3. Låg synlighet utanför sprintrarna
Ionel (2008) Metoden har en låg synlighet över projektet utanför sprintrarna. Konsekvensen blir att det är svårt att uppskatta hur lång tid ett projekt kommer att ta eller hur mycket det kommer att kosta.
4. Relaterat till timeboxing Pitchler (2010) Eftersom Scrum använder sig av timeboxing har produktägaren en möjlighet att släppa fler funktioner genom att dra ner på kvaliteten. Tidigare har detta varit ett vanligt sätt att nå snabba framsteg; dra ner några hörn och
28 göra lite mindre testning. Problemet uppstår då i ett senare skede när det väl kommer till underhåll och påbyggnad. 5. Metoden kräver stor
erfarenhet
Mustaq & Quereshi (2012),
Khan et al (2011), Cohn (2012)
Det krävs professionellt yrkesverksamma personer med erfarenhet om byggandet av utvecklingsteam för att Scrum ska fungera optimalt och kunna levereras i tid. Scrum kräver en viss nivå av utbildning för samtliga användare, och detta medför att den totala kostnaden för projektet ökar. Detta gäller framförallt scrummästaren och/eller produktägaren då de är kärnan i projektet.
6. Svårt att få med kunskaper hos en liten grupp människor
Björkholm & Brattberg (2012)
Det är svårt att få med alla kunskaper hos en liten grupp människor, vilket medför att arbetsbelastningen för ett litet team blir stor. Detta är oftast fallet i scrumprojekt då teamen i flertalet av fallen inte är speciellt stora.
7. Många möten på kort tid Björkholm & Brattberg (2012)
Scrum använder sig av många möten på kort tid och många av dem drar ut på tiden på grund av att den röda tråden inte följs. Ett resultat av detta är kortare arbetstider för utförande av arbetsuppgifterna.
8. Ingen testning under sprintens gång
Cohn (2012) Det är svårt att värdera ifall en funktion är klar eller inte då det inte planeras in någon testning under sprintens gång enligt Scrums praxis. I många fall leder detta till att någon del anses vara klar trots att den inte är det. Detta medför att arbetsprocessen drar ut på tiden och att tidsramen blir svår att hålla.
9. Kundens tillgänglighet Ionel (2008) Ifall projektet är för en extern kund, krävs det stor involvering från dennes sida. Kunden måste
29 vara tillgänglig och testa de periodiska delresultaten. Genom att använda Scrum påverkas synen på kunden mycket av utvecklingen, vilket visar på att en av de största svagheterna även är dess största styrka, nämligen kundens involvering i utvecklingsprocessen.
10. Produktägarens tillgänglighet
Cohn (2012) I många fall är produktägaren inte involverad genom hela arbetsprocessen, vilket leder till att kraven efterhand blir oklara. Risken finns att teamet misstolkar vissa delar och producerar felaktiga funktioner i systemet.
11. Högra krav och snabba iterationsfaser
Bergander & Dubén (2009),
Cervone (2010)
De snabba utvecklingsfaserna ställer högra krav på utvecklarna. På grund av den korta iterationstiden föredrar teams ofta att kommunicera direkt med varandra istället för att hänvisa till ett dokument. Detta leder till att det uppstår osäkerhet gällande vad som egentligen ska levereras och testas, och det blir dessutom svårare att förvalta systemet i slutändan. Det är lätt att tappa greppet om målet om den enskilde inte har tillräcklig inblick i projektet.
12. Kunskap och expertis Khan et al. (2011) Ytterligare en faktor som påverkar produktutvecklingen är ifall någon medlem lämnar eller tillkommer under projektets gång. När en person lämnar tappas det expertis gällande ett specifikt område, och det är viktigt att dokumentation finns gällande vad som gjorts. I många fall är det svårt för nästa person att börja jobba på samma sak.
30 13. Strukturering vid stora
projekt
Schwaber (2004) Vid användning av Scrum i större projekt krävs det att flera teams arbetar parallellt med varandra. Detta medför att projektet i stort skalas ner och varje del får sin egen struktur och komplexitet. Samtliga delar kommer att utarbeta en egen lösning, vilket innebär att det redan från början krävs en strukturerad uppdelning mellan teamen.
14. Kommunikation vid outsourcing
Schwaber (2004), Kerzner (2009)
Det uppstår ett dilemma vid projekt med större teams rent geografiskt sätt, gällande kommunikationen och hur mötena ska gå till. Det finns alltid risk för
missuppfattningar som kan leda till felaktiga arbetsuppgifter. 15. För mycket arbete för ett
individuellt team vid stora projekt
Schwaber (2004) Det kan krävas större arbetsinsatser än vad ett enskilt scrumteam klarar av att göra vid arbete i större projekt. Detta kan i slutändan resultera i att projektet i stort misslyckas. 16. Svårt att anpassa till
större organisationer
Leffingwell (2011) Det är svårt att anpassa Scrum till företagsnivå. Metoden i sig självt är anpassad för små och medelstora företag som arbetar med systemutveckling, men den har inte struktur gällande anpassning till stora verksamheter.
31
5 Presentation av empirisk undersökning
I kapitlet presenteras resultatet från den empiriska studien, där djupintervjuer används som metod för datainsamling. Resultatet presenteras utifrån respektive företag och deras förhållning till Scrums praxis, samt kopplat till de intervjufrågor som finns med i bilaga 1. Den teoretiska referensramen som finns med under punkten 3 Scrums praktiska användning har används för att konstruera resultatet. Nedan följer en presentation av de intervjuer som har gjorts med de tre fallföretagen enligt 2.4.1 Intervjuer.