Det inledande arbetet med studien var att företag kontaktades, första kontakten som nämnts tidigare. Drygt 30 företag kontaktades och cirka 13 företag svarade på första mailkontakt och ur dessa valdes 6 företag, som arbetade enligt Scrum och hade en Scrummästare eller projektledare för eventuell intervju. Förhoppningarna var att fler företag skulle svara och visa intresse för studien, men så var inte fallet. Det svaga intresset medförde att tidsplaneringen ändrades vid det inledande förberedande ar-betet med intervjuer. Det tog längre tid att genomföra intervjuerna eftersom att da-tum för intervjuer skulle bokas in och passa både mig och respondenterna. Planen var att samtliga intervjuer skulle genomföras första veckan, men det tog istället cirka tre veckor innan de var genomförda.
Planen för intervjuerna var att de skulle utföras på plats hos olika företag, men på grund av rådande situation kring COVID-19 ändrades planerna och intervjuerna ge-nomfördes via kommunikationsprogrammet Zoom. Trots COVID-19 intåget kunde intervjuerna genomföras på ett smidigt och bra sätt. Detta medförde att jag på ett enkelt sätt kunde genomföra intervjuer med respondenter på andra orter i landet. Enligt min teori bidrog situationen till att fler företag hade respondenter med lite tid över för intervjuer. Med tanke på det relativt svaga intresset för intervjuer bidrog detta till att studien kunde genomföras med intressenter på andra platser i landet. Syftet med arbetet var att få ut information om hur metoden används i praktiken för att sedan göra en jämförelse med teorin. Valet av intervjufrågor var mycket bra och gav konkreta svar angående hur metoden används i praktiken. Intervjuerna blev väl-digt omfattande eftersom att en hel metod skulle studeras och trots detta skulle fler frågor behövts ställas angående slutresultatet. Respondenterna gav ingen större in-blick i resultat från varje projekt. Om respondenterna hade varit villiga att lämna mer information om resultat, hade studien blivit bättre med mycket information kring resultatet för en bättre summering. Samtliga deltagande respondenter var soci-ala, vilket medförde att det blev bra intervjuer med mycket information från varje person. Valet av metoden för studien var ett bra val för att få ut den viktiga inform-ationen.
Resultaten som samlats in via intervjuer och kring metoden var sådant som var för-utsatt. Innan studien påbörjades fanns det en aning om att metoden Scrum används där större delar implementeras, men att det skulle bestå av modifieringar och resul-tatet av studien visade just det.
5.1 Diskussion av resultat
5.1.1 Roller i teamen
Enligt teorin som beskrivits tidigare i rapporten skall ett team i Scrum bestå av cirka 7 personer +/- 2 personer för bästa möjliga resultat och varje person skall ha en egen roll. Om ett team består av färre medlemmar blir slutsatsen att de olika med-lemmarna måste ta sig an nya roller. Ett team skall enligt teorin bestå av en produkt-ägare, en Scrummästare och ett antal utvecklare.
Samtliga företag som deltagit i studien har gett olika siffror på antalet medlemmar i varje team och det varierar med några personer. Företag A1 har team bestående av 5-9 personer, varav en produktägare, en Scrummästare och resterande utvecklare med bestämda roller. Medlemmarna i teamet har rollen som utvecklare, men agerar även testare när det krävs. Teamet har även en projektledare, trots att målet är att arbeta sig ifrån det. Företag A2 har olika teams, men respondentens team består av 7 personer, varav en projektledare. Detta team har bestämda roller för medlemmarna eftersom att företaget satsar på utvecklare med olika expertis för bästa möjliga resul-tat. Företaget har även en produktägare som ser till att specificera upp produktspeci-fikationen. Företag A3 har teams bestående av 11-12 personer varav en projektle-dare och övriga utvecklare med bestämda roller. Projektleprojektle-daren uttrycker att han är projektledare, men gör det arbete som Scrummästaren gör och agerar även produkt-ägare genom att specificera upp produktspecifikationen. Roller är uppdelade ef-tersom att de besitter olika kompetenser, men samtliga har dock ansvar att testa så-dant som utvecklas. Företag A4 har idag ett team bestående av 20 medlemmar, trots rekommendationer från ledningen om en uppdelning om två för att underlätta arbe-tet med Scrum. Teamet består av en produktägare, Scrummästare och ett antal ut-vecklare. Rollerna för utvecklarna är olika i olika team, i vissa team är utvecklarna både utvecklare och testare och i vissa team finns det bestämda testare. Företag A5 har olika teams och respondentens team består av 6 medlemmar med bestämda rol-ler som utvecklare. Teamen har även en produktägare, en projektledare och en Scrummästare. Scrummästaren arbetar närmare teamet och projektledare sköter ar-betet i högre skikt mot kund och ledningen. Företag A6 har en Scrummästare som har rollen för tre olika teams och varje team har även en produktägare som ansvarar för produktspecifikationen. Varje team består av 7-8 personer med roller som ut-vecklare, men har även ansvaret för att se till att testning utförs.
Den slutsats som kan dras enligt ovanstående resultat är att samtliga företag har ett team på minst 6 medlemmar. Vissa team har ungefär 8 personer i varje team, som teorin säger, och vissa har fler. Ett företag har även 20 medlemmar, men som re-kommenderats en uppdelning för bästa resultat. Rollerna ser olika ut i teamen, men
Projektledarna i dessa projekt har rollen projektledare, men agerar Scrummästare i det dagliga arbetet. Projektledare eller Scrummästare arbetar ungefär med samma typ av arbetsuppgifter och det är endast benämningen som skiljer de åt. Nästintill alla team har en produktägare som ser till att specificera upp produktspecifikationen, förutom företag A3 där produktägare saknas och arbetet görs av antingen Scrum-mästare eller projektledare.
5.1.2 Metodiken i teamen
För samtliga företag, förutom A3 finns det produktägare som ser till att en produkt-specifikation upprättas innan en sprintplanering. Företag A3 har däremot en projekt-ledare som ser till att specifikationen ordnas. Specifikationen är en viktig del i arbe-tet och samtliga företag ser till att den är färdigställd och genomtänkt. Sprintplane-ring är ett möte som genomförs av samtliga företag, dock är innehållet lite olika. Fö-retag A1 har sprintplaneringar där samtliga deltar om det är ny programvara. Vid befintliga lösningar behöver endast en del av teamet närvara. Teamet har även en kravanalytiker som planerar ett antal sprintar framåt så teamet kan påbörja arbetet så fort det är aktuellt. Resterande företag har liknande sprintplaneringar där teamet tillsammans med Scrummästare och produktägare har en genomgång av kommande sprint. Där diskuteras vad som skall prioriteras och lyftas in och teamet kan även vara med och ge åsikter på sådant som de inte förstår eller kanske inte anser vara mest prioriterad. Företag A5 sätter under sprintplaneringen en procentsats på varje individ som påvisar individens närvaro vid kommande sprint. Detta görs med plane-ringsverktyget Hansoft och detta görs för att få en bild över hur mycket teamet kla-rar av att utföra. Detta är en metod som skiljer sig från resterande.
Även dagliga Scrummöten är ett möte som genomförs av samtliga företag och team. Målet med dagliga Scrummöten är enligt respondenterna att teammedlemmarna pratar om vad som gjorts sedan senast, vad som planeras göras kommande tid och eventuella hinder. Företag A6 har däremot ett annat upplägg av mötet, där väljer teamet att fokusera på varje uppgift från specifikationen, uppifrån och ned istället för varje individ och dess arbete. Diskussion kring olika uppgifter sker och efter mötet diskuterar berörda personer eventuella lösningar.
Företag A2, A4 och A6 har även ett Scrum av Scrum möte för en avstämning tea-men emellan. A2 har en genomgång under mötet för att säkerställa att olika teams inte jobbar på samma funktioner och för att undvika konflikter i olika satsningar. Fö-retag A4 har Scrums av Scrums där Scrummästarna diskuterar arbetet och efter mö-tet träffas en representant från varje team för att diskutera hinder och lösningar mel-lan teamen. Företag A6 lägger stor vikt på det mötet och där deltar projektledare, Scrummästare, chef för utvecklingssektion, chef för produktchefer och även pro-duktcheferna själva. Där diskuteras status på förstudier och även koordinering
mel-Varje sprint skall avslutas med en sprint review, ett granskningsmöte, men även där är det lite olika. Företag A3, A4 och A5 har valt bort granskningsmöten. Företag A4 har inte detta möte då externa deltagare bjuds in vid ett annat tillfälle för demokör-ning. Företag A1håller granskningsmöten där ett demo körs av det som utvecklats. Det är ett obligatoriskt möte för teamet och ibland kan även produktägaren delta. Även företag A2 håller ett sådant möte där teamet diskuterar vad som hade planerats och hur målet uppnåddes. Teamet lägger även ned lite tid på att gå igenom statistisk. Företag A6 har även de ett sådant möte där produktchef, utvecklingsteam, Scrum-mästare enterprise arkitekt och interna användare deltar. Vid mötet hålls en kort de-monstration på det som åstadkommits med hjälp av ett GUI och en kort Power-Point-presentation. En utvecklare får uppdraget att facilitera mötet.
Avslutningsvis skall ett så kallat retrospektivmöte hållas efter en sprint och efter granskningsmötet, och oftast i anslutningen till det mötet. Företag A1, A4 och A6 håller retrospektivmöten där teamet deltar och vid vissa fall även produktägaren, för att utvärdera sprinten och diskutera eventuella förbättringar för nästkommande sprint. Även företag A2 har detta möte men teamet fokuserar på att hitta ”Act-ionspoints”, problemen plockas isär till mindre bitar tills det går att lösa. Detta görs utan att det skall påverka någons arbete för mycket. Företag A3 ägnar inte mycket tid alls åt retrospektivmöten, precis som granskningsmötet. Finns det problem som behöver diskuteras, görs det vid det dagliga Scrummötet. Företag A5 håller retro-spektivmöten med lappar där var och ned skriver ned det som behöver förbättras. De viktigaste lapparna och åtgärderna röstas fram och gås igenom för att åtgärdas, dock finns det ingen som följer upp för att se hur det gått.
Samtliga teams specificerar upp en produktspecifikation och planerar sprintar, vilket är en stor del i Scrum. Dessa teams håller även dagliga Scrummöten som även det är en stor del för att få arbetet att rulla och fungera på rätt sätt. Det som är avvikande gällande metoden är att vissa teams inte lägger ner mycket energi och tid på gransk-ningsmöten och retrospektivmöten. Scrum av Scrum är även ett möte som inte är särskilt aktuellt för alla, och detta för att varje team har tydliga beskrivningar över vad det teamet skall syssla med. På så vis minskar risken för att två teams skall arbeta på samma funktioner, som är något teamet säkerställer under ett sådant möte.
5.1.3 Resultatmätning i teamen
Gällande resultat har samtliga företag någon typ av mätning för resultat och dessa re-sultat skiljer sig åt. Däremot har inga specifika mätrere-sultat i form av siffror presente-rats under intervjuerna. Både företag A1 och A3 har mätverktyg för Burndown chart, men inget de reflekterar över särskilt mycket. A1 mäter resultat även genom självskattningsövningar där medlemmar får chansen att bedöma olika delar i
pro-statistisk över i form av kurvor över timmarna. Däremot har teamet krav från led-ningen inom företaget att studera kundnöjdhet, personalens välmående och lönsam-het i företaget. Även företag A6 har använt sig av Burndown chart, men har numera plockat bort den mätningen eftersom att teamet ägnade mycket tid åt att fokusera på kurvan istället för bra resultat. Idag fokuserar teamet på att poängsätta produktspeci-fikationen och mäta hastigheten och detta ger indikation på om det poängsatta hinner bli klart under avsatt tid.
Företag A2 gör mätningar i form av små lanseringar till användare för att få input och ju tidigare dessa input inkommer, desto mindre tid ägnas åt delar i onödan. Detta har enligt respondenten medfört att slutprodukten blivit mer robust och an-vändarvänlig.
Företag A4 fokuserar på ledtider, och arbetar idag med mindre delar och oftare, vil-ket leder till kortare ledtider. Respondenten har inga specifika siffror, men ut-trycker att de sett en markant skillnad. Företagsledningen har däremot krav på tea-men att mäta hur många features per iteration som teamet klarar av att hantera. En-ligt respondenten utförs detta på olika vis beroende på Scrummästarens intresse. Fö-retag A5 mäter antal felmeddelanden genom procentsats där kravet är att ligga på minst 95 % fungerande system. Liksom många andra finns inga andra mätresultat som Burndown chart eller liknande.
Resultatmätningen är något dessa teams inte lägger ned särskilt mycket tid på. Vissa gör mätningar av olika slag, men det är inget som används i syfte att förbättra eller analysera konkreta resultat. Detta medför att just den biten skiljer sig mycket mellan praktiken och teorin, då den teoretiska biten handlar om att utföra statistik med hjälp av Burndown-chart.