Agile project management: Scrum in large project - how is the internal communication affected?

Agil projektledning - Scrum i större projekt

Hur påverkas den interna kommunikationen?

Agile project management - Scrum in large

project

How is the internal communication affected?

Handledare: Helena Holmström Olsson

Agil projektledning - Scrum i större projekt

Hur påverkas den interna kommunikationen?

Kandidatuppsats

Brandt, Jenny, IT och ekonomiprogrammet, Malmö Universitet, Sverige Ostréus, Amelie, IT och ekonomiprogrammet, Malmö Universitet, Sverige

Sammanfattning

Idag använder de flesta mjukvaruföretag agil utveckling och en av de vanligaste agila metoderna är Scrum. Under de senaste åren har det blivit vanligt att använda Scrum i större projekt trots dess anpassning för mindre projekt. Följaktligen har olika ramverk utvecklats för att skala Scrum till mer än ett team och för att stödja metoden i större projekt. Det finns flera kommunikativa utmaningar i denna transformationen som har resulterat i en förändring i det smidiga arbetet som påverkar teamets sätt att kommunicera och samverka. Detta ställer nya krav på samarbete och samordningen mellan de olika team som arbetar med samma projekt. I denna studie har målet varit att med hjälp av en kvalitativ ansats undersöka hur kommunikationen påverkas av det faktum att något som ursprungligen var anpassat för mindre projekt, nu ska användas för stora projekt där många parter är involverade och beroende av varandras arbete. Slutsatserna har dragit utifrån kombinationen av en teoretisk referensram och sex intervjuer med Scrum masters och teammedlemmar. Studien visar på att en stor kommunikativ utmaning är att ha en fortlöpande kommunikation mellan teamen och att uppnå en samverkan trots den distanseringen som följer vid skalning. Strategier för hur skalningen av Scrum ska ske på bästa sätt skiljer sig åt, men det finns en enighet om att strukturer, ett gemensamt “språk” och vision krävs för att samarbetet mellan teamen skall fungera effektivt och för att den interna kommunikationen ska bli lyckad.

Nyckelord: Kommunikation, Scrum, skalad Scrum, Information och kommunikationsteknologi, IKT, Scrum transformation

Abstract

Today, most software companies use agile development instead and one of the most common agile methods is Scrum. In recent years, it has become common to use Scrum in larger projects despite its adaptation for smaller projects. Consequently, different frameworks have been developed for scaling Scrum to more than one team and to support the method in larger projects. There are several communicative challenges to this transformation and the transformation has resulted in a change in the agile work that affects the team's way of communicating and interacting. Which puts new demands on collaboration and coordination between the different teams working on the same project. The aim in this study has been to investigate how communication is affected by the fact that something that was originally adapted for smaller projects should now be used for large projects where many different parties are involved and dependent on each other´s work using a qualitative approach. The conclusions have been based on the combination of a theoretical framework and six interviews with Scrum Masters and team members. The study shows that a major communicative challenge is to have continuous communication between the teams and to achieve a collaboration despite the distancing that comes with scaling. Strategies for how to scale Scrum separates, but there is a consensus that structures, a common “language” and vision are required for an effective collaboration between the teams and for internal communication to be successful.

Keywords: Communication, Scrum, Scaled Scrum, Information and communication technology, ICT, Scrum transformation

Förord

Vi vill framföra ett stort tack till alla som har stöttat oss i vårt arbete och möjliggjort denna uppsats. Vi vill rikta ett stort tack till vår handledare Helena Holmström Olsson, för stödet och de goda diskussioner vi haft under studiens gång. Vi vill också tacka våra respondenter som ställt upp på intervjuer och bidragit med kunskap samt delat sina erfarenheter.

Slutligen vill vi passa på att tacka våra opponenter för den konstruktiva kritik samt för de goda råden som vi har fått.

Malmö Universitet, Juni 2020 Amelie Ostréus och Jenny Brandt

Begreppslista

● Agil utveckling – Användarcentrerad utveckling som är ändamålsenlig, genom ett nära

samarbete med korta iterationer under hela utvecklingstiden

● Autonomiprincipen - Självbestämmanderätt, syftar här till teamens rätt att bestämma

själva

● IKT - Informations- och kommunikationsteknik

● IMGD modellen - Modell för grupputveckling

● Lean UX - Metod som används i agil utveckling

● LeSS - Large Scale Scrum, ramverk för skalad Scrum

● Product backlog – Består av en lista som innehåller alla utvecklingspunkter som krävs

för slutprodukten

● Product backlog refinement - Moment i Scrum, utvecklar Product backlog

● Release sprint - Släppa resultat som går att leverera

● Remote-möten - Möten där deltagarna ej sitter tillsammans fysiskt

● SAFe - Scaled Agile Framework, ramverk för skalad Scrum

● Scrum – En etablerad metodik för systemutveckling

● Skalad Scrum - Scrum för två eller fler team

● SoS - Scrum of Scrums, ramverk för skalad Scrum

● Sprint - Korta iterationer

● Sprint Demo - Förklarar vad som har gjorts och inte gjorts i slutet på varje sprint

● TEAMS Microsoft - Online arbetsyta för alla teamkonversationer, filer, möten och

Innehållsförteckning

2.1. Scrum som Agilt ramverk ... 4

2.2. Olika ramverk inom Scrum ... 5

2.2.2. Scaled Agile Framework (SAFe) ... 5

2.2.3. Scrum of Scrums (SoS) ... 5

2.2.4. Lean UX ... 6

2.3. Organisation och gruppdynamik ... 7

2.3.1. Betydelse av organisationens struktur ... 7

2.3.2. Integrerad modell för grupputveckling (IMGD) ... 8

2.4. Kommunikation ... 9

2.4.1. Två syner på kommunikation ... 9

2.4.2. Inkodning och avkodning ... 9

2.4.3. Informations och kommunikationsteknik (IKT) ... 10

2.5. Sammanställning av teori ... 11

3. Metod ... 12

3.1. Val av forskningsstrategi ... 12

3.2. Hermeneutisk ansats ... 12

3.3. Datainsamling via intervjuer ... 12

3.3.1. Urval ... 13

3.4. Datainsamling genom litteraturundersökning ... 14

3.5. Kvalitativ innehållsanalys ... 14

3.6. Etiska utmaningar ... 15

4. Empiri ... 16

4.1. Presentation ... 16

4.2. Skalning av Scrum med stöd av ramverk ... 17

4.2.1. Skalning av Scrum utifrån Scrum Masters ... 17

4.2.2. Skalning av Scrum utifrån teammedlemmar ... 18

4.3. Kommunikationen vid skalning ... 18

4.3.1. Scrum Masters syn på kommunikation vid skalning ... 18

4.3.2. Teammedlemmarnas syn på kommunikationen vid skalning ... 20

4.4. Gruppens samverkan ... 21

4.5. Strategier för att lyckas med skalning av Scrum ... 22

4.5.1. Strategier för att lyckas med skalning av Scrum utifrån Scrum Masters ... 22

4.5.2. Strategier för att lyckas med skalning av Scrum utifrån teammedlemmar ... 23

5. Diskussion ... 24

5.1. Skalad Scrums påverkan på den interna kommunikationen ... 24

5.2. Ramverkens betydelse vid skalning ... 26

5.3. Hantering av de kommunikativa utmaningarna ... 27

6. Slutsats ... 29 6.1. Framtida forskning ... 30 Referenser ... 31 Bilagor ... Bilaga 1 Intervjufrågor ... Bilaga 2 Samtyckesblankett ...

Bilaga 3 Sammanfattning av studiens resultat ...

1.

Inledning

1.1 Bakgrund

Det äldre och mer traditionella sättet att driva projekt på som var enligt en planbaserad utveckling benämnt som vattenfallsmodellen, konkurreras nu allt mer ut av dagens agila sätt att utveckla mjukvara på (Srivastava et al., 2017). Då vi lever i en föränderlig värld, krävs utvecklingsmetoder som kan hantera förändring som en del av verkligheten. Den agila projektledningen har kommit till att bli en trend för att utveckla mjukvara globalt (Pardo-Calvache et al., 2019). Det som är utmärkande för agil projektledning är den iterativa processen där man arbetar nära kunden, genom en kontinuerlig uppföljning och kommunikation som ska

möjliggöra för förändring och flexibilitet i projektet.Agila metoder passar speciellt för projekt

som har hög osäkerhet och lämpar sig därför bra för mjukvaruprojekt (Paasivaara et al., 2008).

Agila metoder har flera olika arbetssätt, ett av de populäraste är Scrum som nästintill kommit till att bli en norm när man pratar om metoder för systemutveckling (Techworld IDG, 2015). Scrum används idag av företag världen över och implementeras i både små och stora

verksamheter. På grund av metodens popularitet så är det denna agila metod som studien

kommer att rikta in sig på. Scrum har lyfts fram som en framgångsrik metod med ett antal olika moment anpassade för mindre projekt som kräver ett agilt verkningssätt. Scrum är en metod som från början var tänkt att användas för små enskilda projekt (Dikert et al,. 2017), men trots det så har det på senare tid blivit vanligt att skala upp Scrum, (Kapitsaki & Christou, 2014). Vid uppskalning av Scrum (i resten av uppsatsen benämns detta som skalad Scrum) blir fler än ett team involverade i projektet, vilket innebär att strukturen måste förändras. Enligt Rising & Janoff (2000) så måste hela teamet ha ett och samma fokus, det måste vara klart vilka prioriteringar som är, speciellt när det är flera team involverade i Scrum. Scrum är en metod som kräver en bra samverkan och en öppen intern kommunikation, vilket även sätter krav på att det finns tillfällen och en struktur för detta, speciellt när Scrum skalades till flera team.

Enligt Robinson (2019) så är kommunikationen en avgörande del inom Scrum och möjliggör ett samarbete och samverkan mellan och inom team. Då flexibilitet är viktigt inom Scrum för att möjliggöra för förändring så krävs det en fortlöpande kommunikation. Kommunikationen är relaterad till allt arbete och genomsyrar hela organisationen. Inom Scrum är kommunikationen nödvändig för att projektet ska drivas framåt. När Scrum skalas till flera team så behövs det möjliggöras för nya sätt att kommunicera på och den förändrade strukturen som följer vid skalning sätter ökade krav på kommunikation mellan agila aktörer (Robinson, 2019).

En fallstudie utförd av Jensen (2017) visar på att en skalning av Scrum medför flera utmaningar inom en organisation. Studien visar på att de områden som påverkas mest under en skalning är

koordinationen, kommunikationen och processer inom en organisation. Det råder en utmaning i att samordna team, då det blir svårare med rollfördelningen över flera team och anpassning till vissa moment inom Scrum (Jensen, 2017). En skalning kräver ett förändrat arbetssätt av hur man vanligtvis arbetar inom Scrum och nya strukturer behöver arbetas fram.

1.2 Problemdiskussion

Robinson (2019) tar upp den interna kommunikationen som en primär utmaning vid skalning av agilt. En misslyckad kommunikation kan leda till missförstånd, projektfel och en försämrad gruppdynamik. Vidare anger Kapitsaki & Christou (2014) även i sin studie att projektets storlek har en avgörande roll för kommunikationen och projektet i sig. Fallstudien av Jensen (2017) visar på att det som orsakar kommunikationssvårigheterna i större projekt är gapet mellan agila aktörer som är involverade i processen, där det ofta kommuniceras dåligt mellan dessa på grund av den distansering som skalningen medför. Vilket även visat sig leda till projektfel i vissa fall (Jensen, 2017). När projektet blir större så blir även kommunikationsaktiviteterna mer komplexa då fler deltar i projektet (Kapitsaki & Christou, 2014). De deltagande i projektet blir beroende av varandras arbete vilket i sin tur sätter större krav på det interna samarbetet och dess kommunikationsförmåga för att projektarbetet och resultatet ska bli lyckat.

Förmågan för agila metoder att anpassa sig till storskaliga projekt har identifierats som ett prioriterat område för forskare (Bass, 2016). Trots att Scrum är en metod framtagen för mindre projekt så väljer många organisationer att implementera metoden även i större projekt, bestående av flera team. Enligt Bass (2016) så kan teamens samverkan fara illa av att man skalar Scrum till större projekt. Större och globala projekt kan alltså bli lidande på grund av att man ignorerar det faktum att Scrum faktiskt är en metod som är framtagen och anpassad för mindre projekt. Utifrån detta har vi valt att räkna större projekt (skalad scrum) när scrum-användare ingår i olika Scrum team eller när det ingår mer än ett Scrum team i projektet.

1.3. Syfte

Syftet med denna studie är att undersöka transformationen från små Scrum projekt till skalad Scrum ur ett kommunikationsperspektiv, för att förstå vilka kommunikativa utmaningar som följer med en sådan transformation. Genom att undersöka hur kommunikationen och teamets samverkan påverkas av transformationen få en ökad förståelse för vad som utgör dessa kommunikations- och samarbetssvårigheter vid större projekt. Studien ämnar till att bidra till ökad kunskap om kommunikativa utmaningar vid en skalning av Scrum samt belysa eventuella lösningar i form av strategier och förhållningssätt.

1.4. Forskningsfrågor

För att uppfylla syftet kommer följande forskningsfrågor att undersökas:

- Hur påverkas kommunikationen av transformationen från små Scrumprojekt till skalad

Scrum?

- Vilka kommunikativa utmaningar följer transformationen från små Scrumprojekt till

skalad Scrum?

- Hur används befintliga ramverk i en skalning av Scrum och hur främjar dessa

kommunikationen?

2. Teori

2.1. Scrum som Agilt ramverk

Den agila metoden Scrum består av tre roller, tre artefakter och fem aktiviteter även kallade ceremonier, vilka alla hänger ihop och binder samman det arbete som utförs (Comstedt, 2017). Scrum är inte stramt utformad överallt utan det går att anpassa till olika processer och ändå jobba enligt Scrum. De tre rollerna består av utvecklingsteamet, Scrum Master och produktägaren (Comstedt, 2017). Teamet består av yrkeskunniga medlemmar som utvecklar och levererar ett produktinkrement (ScrumAlliance, 2012). Teamet är själva ansvariga för att tillsammans organisera allt arbete under sprinten (ScrumAlliance, 2012) En Scrum Masters roll handlar om att se till att ramverket för Scrum följs. Detta innebär åtagande mot både utvecklingsteam och produktägare (Comstedt, 2017). Scrum Mastern behöver ha en god förståelse för det ramverk som används inom Scrum och förmågan att peka ut de viktigaste aspekterna för de andra. Rollen innebär även att arbeta tillsammans med hela teamet för att kontinuerligt utvidga definitionen av färdigt och se till att alla hinder (interna som externa) röjs undan. Scrum Mastern har även som ansvar att hjälpa alla utanför teamet att förstå processen och hur de på bästa sätt kan agera för att stödja och hjälpa teamet (ScrumAlliance, 2012). Produktägarens uppdrag är att maximera det värde som utkommer av det utvecklingsteamet levererar (Comstedt, 2017).

De fem aktiviteterna som ingår inom samma iteration är Sprint, Sprintplanering, Daily Scrum, Sprint Demo samt Sprint Retrospective. Sprint är Scrums benämning för iteration, vilken alltid är tidsbestämd (mindre än fyra veckor) och innehåller planering, utveckling och utvärdering (Comstedt, 2017). Fördelen med Sprint, som är som korta iterationer, är att möjligheten för att förändra är större. Sprintplaneringen är det som inleder en Sprint. Teamet går igenom Product Backlog tillsammans med Produktägaren. Under Sprintplaneringen skapas även Sprintmål för vad utvecklingsarbetet i Sprinten ska leda till. Daily Scrum är ett dagligt återkommande planeringsmöte för teamet vilket inte får överstiga 15 minuter i längd. Varje deltagare skall redogöra för vad som gjorts sedan senaste mötet, vad deltagaren planerar att göra idag och möjliga hinder som kan finnas. Scrum Master och Produktägare får vara med på mötet men bör inte ha en aktiv roll. Sprint Demo sker i slutet av varje Sprint och ämnar förklara vad som gjorts, inte gjorts och hur detta påverkar nästa Sprint. Under Sprint Retrospective samlas hela Scrum teamet (utvecklingsteamet, Scrum Master och Produktägare) och utvärderar den senaste Sprinten utifrån arbetssätt, verktyg och relationer (Comstedt, 2017). De högst prioriterade kraven väljs och feedbacken från kunder och användare samlas in inför nästa sprint (Bass, 2016).

De tre artefakterna inom Scrum är Product backlog, Sprint backlog och inkrement (Comstedt, 2017). Product backlog består av en lista som innehåller alla utvecklingspunkter som krävs för slutprodukten. Product backlog refinement syftar till att lägga till detaljer till product backlog. Sprint backlog består av de uppgifter som teamet bedömt att de kommer leverera inom ramen för en sprint. För varje uppgift måste det vara tydligt i vad som förväntas av uppgiften och hur den definieras som färdig. Ett inkrement är kort och gott den samlade produkt som uppstår efter en sprint. Produkten uppdateras med sprintens uppgifter (Comstedt, 2017).

2.2. Olika ramverk inom Scrum

Det finns många olika sätt att skala Scrum på. Vilken metod man väljer att göra detta med tycks variera lite från företag till företag. Några vanliga ramverk som används vid en skalning av

Scrum är Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe) och Scrum of Scrums

(SoS). Det finns även andra ramverk som kan användas vid skalning som inte tas med i denna

studie, bland annat Nexus, Scrum@scale och Spotify Engineering Culture (Serious Scrum, 2019, A).

En annan populär metod för att utveckla design inom Agil utveckling är Lean UX som används för att mäta och validera det man utvecklar, denna metodik används för att säkerställa att man inte bygger något som ingen vill ha (Interaction Design Foundation, 2019).

2.2.1. Large-Scale Scrum (LeSS)

LeSS är ett ramverktyg som håller sig nära Scrums syfte (Serious Scrum, 2019, B). När det agila arbetssättet förändras och fler team blir involverade är detta ramverk utformat för att med lite extra komplexitet klara av små eller medelstora skalningslösningar. LeSS kräver förståelse från organisationen för att man ska uppnå samma syfte vid skalning som vid Scrum för ett team. Man behöver ha en klar förståelse för de olika elementen och hålla sig inom de standard som finns inom Scrum. LeSS har precis som Scrum tre roller: produktägare, utvecklingsteam och Scrum Masters. Det finns en product-backlog som bryts ner till flera backlogs som tilldelas vardera team. Daily Scrum fungerar i samma mening - personer från olika team kan delta och observera. Sprint Demo sker också på samma sätt, här inkluderas alla team som har arbetat på samma produkt, från samma Product Backlog. Product Backlog Refinement är ett tillägg för att förädla de saker som påverkar flera scrum team. Detta tillägg i LeSS är just för att förbättra samarbetet och dela kunskap mellan teamen.

2.2.2. Scaled Agile Framework (SAFe)

SAFe är ett ramverk för att skala Agile till stora organisationer (Serious Scrum, 2019, C). SAFe ramverket skiljer sig ganska mycket från Scrum och har många roller som inte finns enligt traditionella sättet att arbeta med Scrum (Serious Scrum, 2019, C). Ramverket arbetar till exempel med designsprints som inte stöds av Scrum då sprintarna inte blir lika frigörande från varandra. SAFe lägger till händelser, roller och artefakter till Scrum och är ett vanligt ramverk bland stora organisationer där anpassning är nödvändigt. Det är den mest kända skalningsramen inom agilt (Serious Scrum, 2019, C).

2.2.3. Scrum of Scrums (SoS)

SoS är en metodik för att skala upp team som utvecklades med mål att samordna flera affärsenheter med fler produktlinjer per affärsenheter och synkronisera de enskilda teamen med varandra (Atlassian u.å.).

Det är i SoS vanligtvis Scrum Mastern som deltar i möten med Scrum Masters från de andra teamen. Mötena syftar till att stödja teamen och främja samarbete och samordning mellan de olika teamen. Detta är tänkt att vägleda teamet mot slutmålet och identifiera eventuella hinder.

SoS möjliggör problemlösning mellan de olika teamen och metoden syftar till att hålla de totala leveranserna på rätt spår, något som blir nödvändigt när flera team är involverade.

SoS har på senare år ökat i popularitet och blivit en praxis som är nära förknippad med skalning av Scrum. För att stödja denna metod så är gruppens storlek kritisk. Enligt Hackman & Vidmar (1970) så påverkas teamets effektivitet av teamets storlek och ett team fungerar som bäst på 4-5 personer. Team som är för stora eller små kan få det svårt med komplexa produkter. När kommunikationslinjerna mellan teammedlemmarna blir större så blir det svårare att skapa ett gemensamt syfte och förtroende, något som ofta sker vid skalning av Scrum. För att upprätthålla önskade resultat kan man då dela ett mycket stort team i två eller tre mindre delar. Scrum of Scrums är huvudsakligen skapat för att samordna stora team på detta sätt.

2.2.4. Lean UX

Då ständig förbättring, kontinuerligt lärande och smidighet idag sätts i fokus inom mjukvaruutveckling så måste även designpraxis ändras på för att åstadkomma en mer effektiv utveckling (O'reilly, 2017).

Lean UX är en metod som används i syfte att arbeta iterativt, leverera smidigt och upprätthålla ett kundcentrerat perspektiv i beslutsfattandet. Lean UX används i Agile-utveckling och är fokuserad på själva upplevelsen under design (Interaction Design Foundation, 2019). Detta ger en ökad förståelse för varför en funktion existerar, dess funktionalitet och de fördelar som följer med den. Genom en direkt återkoppling från kund kan man fatta snabba beslut i sin utveckling. Lean UX har precis som i Agil utveckling målet att arbeta smidigt med iterativa cykler i syfte att säkerställa att data som genereras kan användas i varje iteration. På detta vis kan man även eliminera slöseri. Genom att använda digitala designverktyg och tekniker efter behov så optimerar Lean UX design för en Agil värld.

En av principerna inom Lean UX är att agera som ett team (O'reilly 2017). Tillsammans åstadkomma en gemensam förståelse kring kunder och deras behov. Samarbete är här nyckeln för att detta ska fungera. Teammedlemmar kan med denna delade kunskap snabbt fokusera på vad de ska göra åt ett problem. En annan princip som finns är att designa tillsammans, återigen att samarbeta. Om man inte arbetar fysiskt ihop, arbetar och kommunicerar man genom digitala verktyg (O'reilly 2017).

Design thinking är en annan metod som delar en evidensbaserad strategi för produktdesign med Lean UX. Dessa två metoder delar några gemensamma element tillsammans, såsom observation av kund, kundförståelse, samarbete och brainstorming (O'reilly 2017).

2.3. Organisation och gruppdynamik

Då Scrum är en metod som appliceras på grupper, blir gruppdynamiken en central del att undersöka för att få en förståelse för dess innebörd för kommunikationen vid skalning av Scrum.

2.3.1. Betydelse av organisationens struktur

Den enskilda arbetsplatsens historia, struktur och ansvarsfördelning påverkar grupper i hög grad (Granström, 2006). När en organisation sätter käppar i hjulet för samarbete är det lätt att man tillskriver bristerna på en individ istället för organisationen. Den vanligaste organisationsmodellen i det västerländska samhället är den hierarkiska. I en hierarkisk organisation är ordningen uppifrån och ned, grupparbeten bygger på att deltagarna i gruppen beter sig enligt givna order, gör sin uppgift och inväntar nya anvisningar (Granström, 2006). Ansvaret för verksamhetens mål och inriktning ligger på ledaren, vars främsta uppgift är att fatta beslut. Det finns flera olika brister med denna typ av struktur, bland annat kompetensen för beslutfattande. Det är inte alltid den största kompetensen finns högre upp i hierarkin, i vissa speciella frågor kan denna hittas på de lägsta nivåerna. En annan svaghet med strukturen är bristen på demokrati och medinflytande (Granström, 2006).

För att möta en del brister som kommer med den hierarkiska modellen har en annan typ av modell formats som kallas för teamorganisation. I denna modell är grundtanken att komma bort från snäva arbetsspecialiseringar där var och en har sin bestämda uppgift (Granström, 2006). I teamorganisationen är målet att skapa en struktur som förutsätter och utnyttjar effekterna av samarbete och ansvarstagande hos de anställda. Huvudprincipen är att en grupp människor och inte en enskild individ har ansvaret för olika arbetsuppgifter. Dessa uppgifter är komplexa och handlar om ett totalt ansvar för en färdig produkt och inte en enskild detalj. Teamorganisationens verksamhet är uppdelad i ett antal produktionsenheter där varje enhet har totalansvaret för framställningen av en viss produkt (Granström, 2006). En nödvändighet är att det finns en ledningsgrupp med ansvar för samordning och utvärdering, för målsättnings- och resursfrågor för organisationen i sin helhet. För att denna modell ska fungera krävs bland annat ett horisontellt ansvarstagande, en problem- och uppgiftsstyrning, gruppspecifika lösningar samt att varje individ vet gruppens uppgift och kan rycka in där det behövs. En svaghet med teamorganisationen är risken för att produktionsenheterna blir så pass autonoma att de börjar formulera sina egna produktionsmål som avviker från företagets eller organisationens mål. Här är det viktigt med samordning i ledningsgruppen där teamen kan delta för att formulera etappmål för hela organisationen. För att på så sätt hålla fokus på organisationens mål (Granström, 2006).

2.3.2. Integrerad modell för grupputveckling (IMGD)

IMGD är en modell för grupputveckling utvecklad av Susan Wheelan (Sandblom & Larsson, u.å.). Den beskriver fyra stadier i en grupps utveckling och ytterligare ett stadie för att åskådliggöra gruppens upplösande. Modellen sammanfattar aktuell forskning och har inslag från andra modeller inom området för grupputveckling. De fyra faserna de går igenom tills upplösningen är:

Fas 1: Tillhörighet och trygghet Fas 2: Opposition och konflikt Fas 3: Tillit och struktur Fas 4: Arbete och produktivitet

Enligt Wheelans forskning finns dessa utvecklingsstadier i alla arbetsgrupper. Att förstå vad som sker i en grupps olika stadier är viktigt både för ledare och medarbetare (Sandblom & Larsson, u.å.).

För att överleva grupputveckling behöver vi gå igenom olika stadier som inte alltid är lätta. Att utvecklas till ett högpresterande team tar minst ett halvår och kräver tålamod samt förståelse för oklarheter och konflikter. Det är viktigt att uppmuntra feedback och regelbundna avstämningar (Sandblom & Larsson, u.å.).

Nedan följer en beskrivning av de fyra faserna som en arbetsgrupp går igenom enligt Sandblom & Larsson (u.å.):

I den första fasen är gruppen beroende ledaren. Trygghet i form av att man förstår vad som händer, vilka andra som ingår i gruppen och vilka förväntningar som finns är viktigt i denna fasen. I den andra fasen försöker gruppmedlemmarna göra sig fria från beroendet av ledaren. Ledaren ifrågasätts samtidigt som medlemmarna själva börjar kämpa och ifrågasätta inbördes om varandras tolkning av uppgifter och mål för gruppen. Konflikter är vanligt här och vissa grupper fastnar i denna fas. Målet under denna fas är att klargöra gruppens mål och skapa en gemensam struktur och kultur inom gruppen. I den tredje fasen har medlemmarna hittat former för god konflikthantering. Relationerna kännetecknas av tillit och förtroende, behovet av att markera revir och egna positioner avlägsnas. Genom att utveckla strukturer, mål och fördelning av arbetet hamnar fokus på själva uppgiften. Kommunikationen i denna fas är öppnare och mer inriktad på uppgiften. När en grupp når till fas fyra kan de ses som ett högpresterande team. Rollerna i gruppen är klara, kommunikationen är öppen och samarbetet blir effektivt och intensivt. Ansvarstagandet från alla i gruppen gentemot uppgiften är maximal.

2.4. Kommunikation

Kommunikation studeras i olika sammanhang och uppträder på många olika ställen, vilket resulterar i att det finns många olika sätt att se på kommunikation. Nedan redogörs några av dessa som upplevs relevanta för området som studien behandlar.

2.4.1. Två syner på kommunikation

Enligt Carey (2009) så finns det två sätt att se på kommunikation. Dessa beskriver han som

transmissionsperspektivet och ritualperspektivet. Transmissionsperspektivet syftar till själva

överföringen av kommunikationen mellan sändare och mottagare på ett visst avstånd. En aktiv sändare sänder över ett meddelande i en kommunikationskanal som tas emot av en passiv mottagare i en annan destination där syftet är kontroll. Det primära målet i transmissionsperspektivet är själva spridningen av informationen och hur informationen skapar kontroll i samhället. Detta är det traditionella sättet att se på kommunikation samt den vanligaste i vår kultur.

Ritualperspektivet som är den mindre kända definitionen av kommunikation syftar till att

kommunikationen för människor samman och på så vis skapas en tillhörighet. Här är kommunikationen snarare en process där delade trosuppfattningar samlar människor och en gemenskap bildas då man delar samma övertygelser. Denna syn kan man se på sociala medier där grupper bildas av människor som delar gemensamma intressen, värderingar eller åsikter. I denna kommunikationsprocess möjliggörs och förverkligas samhällsomvandling. Delad tro och ceremoni är fundamentet i ritualperspektivet och samhörighet mellan personer bringas till existens.

2.4.2. Inkodning och avkodning

Hall kommunikationsmodell (refererad till i Durham och Kellner, 2001) som beskrivs i form av inkodning och avkodning av ett meddelande, där mottagarens sätt att avkoda ett meddelande har stor påverkan på meddelandets effektivitet. Enligt Hall så är det en mängd olika faktorer som påverkar läsarens tolkning. Det kan vara faktorer som sammanhang, kultur och social klass. Han menar att kontexten kommer att påverka hur meddelandet kommer att avkodas och att kommunikation mellan kodare och avkodare inte är någon självklar överenskommelse.

Enligt Hall (refererad till i Durham och Kellner, 2001) så ligger tre attityder till grund och blir avgörande för hur ett meddelande tas emot och för vilket förhållningssätt man då tar gentemot meddelandet.

Den första kallar han för dominanta tolkningen, här avkodar mottagaren meddelandet exakt som det kodades. Det uppstår en acceptans i läsningen vilket gör att den känns naturlig. Detta är ett idealexempel på en fullständigt genomskinlig kommunikation.

Den andra attityden han beskriver är den förhandlade tolkningen, här är det inte klart hur mottagaren ska ställa sig till meddelandet. Mottagaren har här svårt att förstå hur meddelandet ska tolkas. Avkodaren erkänner budskapet men skapar utifrån en mer individuell nivå egna

grundregler, vilket gör att budskapet inte riktigt når fram som det var tänkt. Detta kan då anses som att kommunikationen har misslyckats.

Han beskriver sedan den oppositionella tolkningen. I den oppositionella tolkningen så förstår avkodaren budskapet både bokstavligt och på en konnotativ nivå men intar en motsättande attityd gentemot det som kommuniceras ut i meddelandet. Vilket också leder till en misslyckad kommunikation.

2.4.3. Informations och kommunikationsteknik (IKT)

Något mycket användbart inom projektledning är Informations och kommunikationstekniken (IKT). IKT handlar om kommunikationen mellan människor som möjliggörs av IT. IKT är uppbyggt av komponenter som möjliggör datoranvändning genom en infrastruktur (Search CIO, 2019) så att vi kan interagera med varandra genom det digitala på ett effektivt och smidigt sätt. För ett projektarbete kan kommunikationstekniken möjliggöra exempelvis planering, strukturering och annan nödvändig informationsdelning på ett smidigt sätt som kan föra projektet framåt.

De framsteg som gjorts inom tekniken har lett till att vi har förändrat vårt sätt att arbeta och hur vi lever våra liv. Allt fler anställda får idag delar av sitt arbete gjort utanför det traditionella kontoret. Användningen av IKT har lett till att organisationer får ökade förväntningar på anställdas tillgänglighet (Kollega, 2017). Något som kan göra det svårt för den anställde att begränsa sitt arbete till de faktiska arbetstimmarna.

I en studie gjord av Braukmann (2017) kom man fram till att användningen av IKT kan vara fördelaktig men också skadlig. IKT tillför en ökad flexibilitet, underlättar för kommunikationen och samarbetet, men kan också komma att bli skadligt när det gäller balansen mellan arbetsliv och privatliv.

Trots de positiva effekterna som IKT medför så finns det en del fallgropar (Braukmann, 2017). Då arbetet blivit alltmer gränslöst i tid och rum på grund av den avancerade tekniken blir balansen mellan arbete och privatliv en utmaning för många. Användning av IKT kan resultera i stor press och den anställdes välmående kan äventyras. På detta vis har man ständigt arbetet med sig och kan därför känna ett stort krav på tillgänglighet. Men studien visar även att de anställda uppskattar flexibiliteten och kontrollen som IKT medför och att de mindre tänker på de nackdelarna såsom att det blir skadligt på välbefinnandet. Det ger även positiva effekter på den anställdes motivation och prestanda. Det kan alltså vara till en fördel när det kommer till att uppnå kortsiktiga mål men ge negativa effekter på längre sikt för individen (Braukmann, 2017).

2.5. Sammanställning av teori

Då studiens fokus ligger på att undersöka skalad Scrum ur ett kommunikationsperspektiv så har vanliga ramverk inom skalad Scrum presenterats för att ge en förståelse för de som är utgörande respektive ramverk. Genom att presentera betydelsen av organisationsstrukturen kan man identifiera olika kommunikativa hinder som kan medfölja vid skalning då strukturen sätter grunden för sättet att kommunicera inom organisationen. Grupputvecklingen blir även en central del då Scrum appliceras på team och fasen gruppen befinner sig i blir avgörande för hur kommunikationen ter sig. Genom att använda Halls kommunikationsmodell och Careys två sätt att se på kommunikation tillsammans med teorin ovan, möjliggörs ett sätt att studera kommunikationen från att den sänds ut till att den mottags, det vill säga hela kommunikationsprocessen vid uppskalning.

3. Metod

3.1. Val av forskningsstrategi

Studien utgår från ett kvalitativt perspektiv, med fallstudier som forskningsstrategi. Det kvalitativa perspektivet studerar hur människan uppfattar och tolkar den omgivande verkligheten, vilket är nödvändigt för att kunna studera ett så pass komplext studieobjekt (Backman, 2011) som kommunikationen är. Alternativet är det traditionella förhållningssättet där den omgivande verkligheten betraktas som mer eller mindre objektiv. Den kontextuella ansatsen som används för att tolka sammanhanget kan medföra svårigheter i hur pass generaliserbart resultatet kan bli (Backman, 2011) något vi är medvetna om.

För att göra projektet trovärdigt är det viktigt att vi är transparenta och tydligt redogör forskningsprocessen så att läsaren kan ta del av hur vi har tänkt och resonerat kring metodval. Studien har gjorts under samma period som COVID-19, vilket har medfört att detta har fått bli en del i det vi studerar. Pandemin har tvingat många till att förändra sitt arbetssätt, många sätts på remote, vilket även förändrar sättet att kommunicera internt. Detta skulle även kunna bli framtidens sätt att arbeta på varav vi ser det som en relevant aspekt att titta på.

3.2. Hermeneutisk ansats

Hermeneutiken är en självständig tolkningslära som kan användas på alla typer av texter. Man vill förstå texten som ett uttryck för bland annat avsikter och livsinställningar och inte bara registrera dess bokstavliga betydelse (Hansson, 2011). Då studien använder sig utav semistrukturerade intervjuer och intresserar sig för hur kommunikationen påverkas vid skalning så har denna ansats valts att appliceras, då det är tolkningen som ligger till grund för det komplexa ämnet kommunikation som studeras i denna studie.

3.3. Datainsamling via intervjuer

Intervjuerna som hålls är semistrukturerade (se bilaga 1), vilket faller inom ramen för kvalitativa intervjuer (Ahrne & Svensson, 2011). Intervjuerna planerades att hållas i cirka 30– 40 minuter, tidsramen är för att undvika allt för långa intervjuer och istället ha möjligheten till fler intervjuer och på så sätt få en bredare bild. Enligt Ahrne och Svensson (2011) är det en fördel med att använda kvalitativa intervjuer då man har möjligheten till att anpassa frågorna och ordningen efter situationen på ett annat sätt än om man är bunden till ett helt standardiserat frågeformulär. Detta ger i sin tur en bredare bild med fler nyanser och insikter än vid standardiserade frågeformulär (Ahrne & Svensson, 2011). Det öppnar upp för möjligheten att fånga fler aspekter samt minskar risken för bortfall och den intervjuades begränsade möjlighet att svara utförligt. Med ett utgångsfokus i kommunikationsaspekten och transformationen av Scrum så arbetades några öppna intervjufrågor fram som handlade om respondentens roll-, den

interna kommunikationen- och ramverken vid skalning av Scrum. Viktigt att ha i åtanke under

analyseringen av intervjuerna är att vissa inriktningar inom varje tema kan lika gärna bero på att de ”provoceras” fram av oss som intervjuare (Ahrne & Svensson, 2011). Inför varje intervju skickades det ut en kort beskrivning av studien till respondenterna för att förbereda dem inför

intervjun. Med detta ville vi se till att de på förhand fick en förståelse för studiens syfte samt en förståelse för vad vi ansåg vara väsentligt att undersöka under intervjun.

På grund av den rådande situationen med covid-19 hölls intervjuerna via Skype och Jumpchat, beroende på vad företaget stödjer. Genom att använda en webbkamera och ett datorprogram som Skype kunde intervjuerna genomföras mycket likt en intervju ansikte mot ansikte vilket gav oss samma fördelar och nackdelar beträffande personlig interaktion (Denscombe, 2018).

Intervjuerna som hölls hade som mål att spelas in med den intervjuades samtycke. Det finns både för- och nackdelar med att spela in intervjuer. En nackdel är att inspelningen kan störa den intervjuade och kännas som en begränsning i hur öppen hen kan vara (Alvehus, 2013). Här var vi noga med att informera om de etiska principerna vi ämnade följa för att den intervjuade skulle kunna känna sig så bekväm som möjlig. Fördelen med inspelade intervjuer är att vi som intervjuare inte behöver lägga allt för stort fokus på att anteckna ner allting, utan kan fånga upp andra aspekter som inte fångas av en ljudinspelning (Alvehus, 2013). Under varje intervju var standarden att en av oss höll själva intervjun medan den andra förde anteckningar. Den som förde anteckningarna höll även koll på vilka teman som täcktes upp.

Intervjuerna transkriberades löpande för att undvika en alltför stor arbetsbörda på en och samma gång. Alla preliminära analyser (analyser under intervjuernas gång) sparades för att i ett senare skede kunna jämföras/kompletteras med analyserna av de transkriberade intervjuerna.

För att komplettera intervjuerna fanns tanken att genomföra observationer under ett eller flera Scrum of Scrums för att på så sätt studera samspelet mellan teamen, hur kommunikationen behandlas och vilken roll den spelar. Covid-19 ledde till att många företag upprättade besöksförbud samt arbetade hemifrån vilket försvårade för detta. Alternativet var att observera under ett digitalt möte, då som en deltagande observatör, observatören är känd för gruppen med främsta syfte att observera men deltar ej i gruppens arbete (Denscombe, 2018). Den negativa aspekten av detta, påverkan av närvaron vilken kan leda till en snedvridning av resultatet samt bortfallet av de aspekter som fångas upp vid en fysisk observation så som kroppsspråk mellan de olika deltagarna (Denscombe, 2018) gjorde att denna metod valdes bort.

3.3.1. Urval

Utifrån vår kvalitativa ansats har ett strategiskt urval gjorts (Alvehus, 2013). I vår studie har ett tvåstegsurval gjorts utifrån Ahrne och Svenssons (2011) princip. Första urvalet har fokuserat på vilken organisation som skall väljas. Vi har valt att rikta in oss på globala mjukvaruintensiva företag, då vi anser att dessa är mest relevanta och har en högre trolighet att besitta mer kunskap inom Scrum, då Scrum från början är tänk för mjukvaruutveckling (Visma Blogg Sverige, 2019). Utifrån urvalskriterierna ovan så valdes två olika företag ut för att göra resultatet mer generaliserbart. Det ena företaget är inom säkerhetsbranschen och det andra företaget är inom förpackningsbranschen. Nästa steg är vilka individer som skall intervjuas. Här har vårt mål varit två till tre Scrum Master, några från utvecklingsteamet samt en projektledare eller produktägare. På så sätt får vi både ett homogent och heterogent urval. Ett homogent urval gör

ger en bredare insikt i det fenomen som studeras och bidrar till ökad nyansrikedom (Alvehus, 2013). Fokus har legat på att hitta personer som varit med under skalning av Scrum för att på så sätt kunna få insikt i deras syn på transformationen. På grund av snabb och bra återkoppling från Scrum Masters, resulterade det i att vi genomförde fyra intervjuer med Scrum Masters och två intervjuer med utvecklare. Efter att ha genomfört dessa intervjuer togs ett beslut att stryka produktägare och istället fokusera på Scrum Masters och teammedlemmar. Valet grundades på att vi sökte projektledarkompetens men även ren utvecklingskompetens på den dagliga basen från en teammedlem.

3.4. Datainsamling genom litteraturundersökning

Till studien har vetenskapliga artiklar använts för att komplettera intervjuerna och fördjupa det teoretiska ramverket kring scrum och de ramverk som finns för skalning av Scrum. Dessa har inhämtats via sökdatabaserna Google Scholar, IEEE Xplore Digital Library samt Libsearch. Sökord har använts för att smalna av sökningen och identifiera relevanta artiklar, exempel på dessa var “Large Scale Scrum”, “Scaled Scrum + communication” “Large Scrum + communication problem”, “Large Scale Scrum”. Från de vetenskapliga artiklarna som hittades har även deras källor använts för att på så sätt bredda vår litteraturöversikt.

3.5. Kvalitativ innehållsanalys

I arbetat att bearbeta och koda den insamlade data användes en kvalitativ innehållsanalys. En kvalitativ innehållsanalys hjälper till att systematiskt analysera data utifrån kategorier som satts och hjälper till att identifiera likheter och skillnader i det insamlade materialet (Bryman, 2018).

Tabell 1. Matris över kodningsprocess Meningsbärande

enhet

Kondenserad meningsenhet

Kod Kategori

Oftast löser man inte de problemen utan man bara tar sig förgivet att man ska skala och då går man in på det traditionella sättet att skala på med hierarkier.

Fokus ligger inte på själva problemen, utan man vill bara skala Scrum.

Kunskapen om skalning av Scrum.

Skalning av Scrum.

Denna analysprocess genomfördes först individuellt där det centrala från datainsamlingen sammanställdes för att senare ytterligare en gång tillsammans diskutera samband och skillnader muntligt tillsammans. Analysen gjordes på så vis att när texten lästes igenom markerades det som upplevdes relevant för studien, de meningar som ansågs skapa värde för vad studien undersöker. De utgjorde vad Graneheim & Lundman (2004) kallar för meningsbärande enheter som sedan kortades ned till en kondenserad meningsenhet där meningen tolkades och sedan

applicerades under en kategori för att sedan identifiera koden som blev själva “nycklarna” från den transkriberade texten.

3.6. Etiska utmaningar

Inför varje vetenskaplig undersökning ska den ansvariga forskaren göra en vägning av värdet av det förväntade kunskapstillskottet mot möjliga risker i form av negativa konsekvenser för berörda undersökningsdeltagare (Vetenskapsrådet, 2003). Enligt Vetenskapsrådet (2003) finns det fyra grundläggande individskyddskrav vilket studien ämnar följa. Följande är informationskravet, samtyckeskravet, konfidentialitetskravet och nyttjandekravet. Namn, kön och åldern på den intervjuade kommer inte att nämnas i studien. Inför varje intervju har en samtyckesblankett (se bilaga 2) skickats ut för att få underskrift och visat samtycke från den deltagande.

4. Empiri

I detta avsnitt kommer den empiri som de sex respondenterna har bidragit med att presenteras. Detta avsnitt är tematiskt uppbyggt utifrån de teman som utgör intervjuguiden för att ge en så strukturerad och klar bild som möjligt. Beskrivningar tillsammans med citat varvas om för att göra texten lättläst och ge den flyt. För att avidentifiera respondenterna kommer de att presenteras som intervjupersoner i form av Ip1, Ip2, Ip3, Ip4, Ip5 och Ip6. De olika företagen benämns som Företagen inom förpackningsindustrin benämns som företag A och företaget inom säkerhetsindustrin benämns som företag B.

4.1. Presentation

Intervjuperson 1 (Scrum Master, Företag A):

Ip1 har rollen Scrum Master och anser att hens främsta uppgift handlar om att bygga högeffektiva team där Scrumprocessen är ett tillvägagångssätt tillsammans med gruppdynamiken. Ip1 har jobbat inom Agil utveckling i 20 år och haft alla större roller och positioner som finns. Just nu jobbar hen med fyra team och är noga med att betona att hen aldrig leder teamen, utan är en coach som hjälper teamen att växa.

Intervjuperson 2 (Scrum Master, Företag B):

Ip2 har rollen som Scrum Master och ansvarar för två team med fyra och fem personer i vardera. Började rollen som Scrum Master år 2013 då hen också arbetade deltid som utvecklare. Gick senare över till att bli Scrum Master på heltid ett år senare. När de skalade upp till fler team så utvecklades rollen till snarare någon slags Agile coach som försökte agera som en slags processkoordinator som såg till att båda scrumteamen fungerade självgående. Större delen av fokusen fick då läggas på att koordinera teamen.

Intervjuperson 3 (Scrum Master, Företag A):

Ip3 har rollen Scrum Master men anser sig även kunna ses som en Senior Agile coach. I det dagliga arbetet hjälper hen team med bland annat problemställningar som behöver lösas, oftast av den organisatoriska typen. Lite in på 2000-talet började Ip3 jobba med Scrum och för tillfället arbetar hen med två team som jobbar mot samma produkt. Ip3 betonar vikten av att först och främst jobba med teamen och utveckla grupper för att sedan utveckla hela avdelningar för att i sista skede påverka avdelningar omkring. Inom teamet upplever Ip6 att det finns en bra teamkänsla och respekt för varandra.

Intervjuperson 4 (Scrum Master, Företag A):

Ip4 började jobba som Scrum Master för drygt 2 år sedan. Rollen har under denna tid förändrats en del då de från början hade mycket support av agila coacher utifrån och hade konsulter inom mjukvaruutveckling då denna kompetensen då inte fanns internt i företaget. Rollen som Scrum Master har handlat mycket om att sätta sig in i det agila arbetssättet. Hålla fast vid de agila principerna. Ip4 har huvudsakligen ansvar för ett team men som är i en skalning, där de är beroende av ett annat team i sin utveckling. Ip4 jobbar mycket med att coacha och pusha teamet till att själva agera, att få dem att självmant kommunicera med det andra teamet.

Intervjuperson 5, (testare, Företag B):

Ip5 har rollen som testspecialist i ett featureteam och besitter en lång erfarenhet av Scrum som sträcker sig bak till 2010. Ip5 var med när Scrum skalades från ett team till flera team och fick se hur detta påverkade teamet och sättet att arbeta. Ip5 är mycket mån om kommunikation och även noggrann med att det finns en struktur vid skalning av Scrum.

Intervjuperson 6, (utvecklare, Företag A):

Ip6 har rollen som utvecklare i ett Scrum team. Hen började jobba med Scrum för 1,5 år sedan och anser sig fortfarande som relativt ny inom ramverket men har jobbat som utvecklare i flera år. Deras team består av 6–7 personer där de strävar efter att ha högt i tak och ett gemensamt ansvar att leverera. I ett tidigare projekt arbetade ip6 med sitt team i skalad scrum där de var två olika team som arbetade mot samma produkt.

4.2. Skalning av Scrum med stöd av ramverk

4.2.1. Skalning av Scrum utifrån Scrum Masters

Respondenterna från företag A jobbar alla främst efter ramverket Lean UX. Valet har grundat sig i fokusen på grupputveckling, att skapa högeffektiva autonoma team och vilken människosyn man har. Ip4s grund till valet av Lean UX var ett sökande efter effektivitet i organisationen, de ville bli snabbare och våga ta beslut. Ip4 brukar se till att köra två veckors sprintar då det är vad som har visat sig vara mest effektivt. När de haft längre sprintar har det resulterat i att de sällan blir klara. Ip4 tror att det kan bero på att man faller lite till ro när man inte känner någon känsla av brådska.

Ip1 främsta mål är att undvika hierarki. Detta är även något som Ip3 strävar efter. Ip1 och Ip3 anser att det är viktigt att inte använda metoderna från ett ramverk rakt av, utan istället ta inspiration från dem.

“Används metoderna rakt av går man in på det traditionella sättet att skala på med hierarkier. Då går man ifrån det agila sättet att arbeta på och Scrum Mastern går in som en Team Leader istället.” (Ip1, Företag A)

Ingen av respondenterna använde något ramverk rakt av för att skala processen, utan tog istället inspiration från de olika.

Ip2 från företag B, tog mycket inspiration från ramverket SAFe. De hittade en idé om att införa produktägare i varje team (fast i praktiken blev dessa mer sin team-scrum-masters) vilka skulle verka som en slags kontaktperson och coacha teamet för att minska gapet som uppstod mellan teamen och mellan team och produktägare när de skalade upp. Produktägaren skulle då träffas i en grupp med team-produktägare, liknande koncept som SoS i sin koordinering av teamen. Detta visade sig göra stor nytta vid skalningen. På senare år insåg Ip2 att de borde ha infört en Scrum Master då team-produktägarna hade större fokus på produkt och prioritering och tappade därför lite i sitt grupp-coachande och främjande av gruppdynamik. Ip1 ser SAFe som ett hierarkiskt ramverk med många roller vid sidan av som inte ingår i teamet, vilket då tappar

mycket av det agila och hen vill därför inte använda det. Ip3 var också negativt inställd till SAFe och benämnde det som ett skräckramverk.

Ip1 från företag A har arbetat i en halvvariant av SoS när 15 team jobbade tillsammans, men anser att det stora problemet med SoS är antagandet om att alla teamen måste prata med varandra. Hen har istället utgångspunkten att bryta ned och jobba i mindre enheter som kan jobba mer fristående från varandra och på så sätt komma bort från koordineringsproblemen. Ip3 arbetar inte med SoS då hen anser att det är mer effektivt att teamen lär sig produkten tillsammans men sedan kan jobba självgående och oberoende av de andra teamen. För detta använder hen grupputvecklingsmetoder.

Den största utmaningen enligt Ip1 med att skala Scrum är att behålla autonomin i teamen och skala på rätt parametrar. Enligt Ip3 är främsta skillnaden vid en skalning av Scrum att man blir mer påverkad av problemen runt om teamen. Den företagsstruktur som råder begränsar teamen i en skalning.

4.2.2. Skalning av Scrum utifrån teammedlemmar

När Ip5s organisation (företag B) började skala Scrum så fanns det ingen direkt struktur, vilket resulterade i att det inte blev så ordentligt gjort. Ip5 upplevde att när de tog inspiration från ramverket SAFe fick de mer struktur, alla team levererar sina funktionalitets-tester vidare till det teamet som tar över och testar helheten. I början för Ip5 arbetade de mycket framför en tavla vilket inte blev hållbart när de var så många. De kom fram till att de behövde dela upp sig i mindre team och ha mindre folk på mötena. De började då strukturera sig i olika teams och använde sig av SoS, vilket enligt Ip5 ger en mer övergripande syn om vad som försiggår inom alla teamen. Ip6 från företag A är relativt ny inom Scrum är fokuserad på teamets uppgifter och menar att metoden för processen ligger på Scrum Mastern. Ip6 upplever den största utmaningen med en skalning av Scrum att skapa utrymme för varandra mellan teamen till att ställa de frågor som kan krävas.

4.3. Kommunikationen vid skalning

4.3.1. Scrum Masters syn på kommunikation vid skalning

Ip1 från företag A, lägger stor vikt vid skalning att team ska kunna lära av varandra och att teamet ska klara sig själva utan Scrum Masterns hjälp. Ip2 från företag B tror snarare på en koordinering och att man konstant arbetar nära teamen. När Scrum skalades fick Ip2 jobba på en högre nivå och hann inte längre vara lika insatt i teamets dag-till-dagverksamhet. Därav införde hen som tidigare nämnt team-produktägaridén, i syfte att de skulle arbeta nära teamen och vara införstådda i deras verklighet. På så vis skulle team-produktägaren kunna paketera information så att teamet tar emot budskapet, de skulle förklara för teamet varför det som de skulle göra är viktigt. Detta visade sig fungera rätt bra ur ett kommunikationsperspektiv. Man krympte på så vis avståndet genom att ha någon som är närmre teamen och aktivt arbetar med dem och att även den produktägaren jobbar nära huvudproduktägaren. Nackdelen med produktägaridén som Ip2 upptäckte med tiden var att det var fler steg för kommunikationen att gå genom vilket gjorde att det tog längre tid, budskapet gick inte lika direkt.

“Den största utmaningen vid skalning av Scrum är att få nödvändig kommunikation att effektivt flyta mellan” (Ip2, Företag B)

Ip3 vill att sina utvecklingsteam ska känna att det är deras möte. Hen vill att dem själva ska driva kommunikationen och komma bort från hierarki. Vid skalning anser hen att det är viktigt att teamen lär sig produkten tillsammans. Ip4 är precis som de andra mån om att det är en cirkulation på deras möten och att alla är aktiva.

“Den största utmaningen med att jobba med fler team är just kommunikationen” (Ip4, Företag A)

Ip4 upplever att hen får pusha teamet ibland till att kommunicera över gränsen med det andra teamet då de behöver gå utanför sin trygghetszon. Detta beskriver Ip4 som viktigt för att åstadkomma en transparens mellan teamen och därav en viktig utmaning vid skalning. Hen beskriver att det är viktigt för teamen att kunna dela skärmar om man inte förstår saker och fråga om det man inte förstår.

Ip1 gillar inte offentliga boards i kommunikationstekniken där chefer kan se siffror, då hen beskriver det som att det kan leda till en felaktig diskussion och rikta fokus på fel väg. Hen beskriver att det bästa exemplet på denna typ av kommunikationsprocess är om alla teamen som arbetar ihop delar samma övertygelser om vad som ska och behövs göras samt hur de bör arbeta.

Nu när studien utfördes under COVID-19 satt samtliga respondenter remote i det dagliga arbetet. För Ip1 har detta gjort att allt tar ungefär dubbelt så lång tid och det har krävt ett extra Daily Scrum möte om dagen för teamen. De måste under remote-arbetet helt förlita sig på kommunikationstekniken. Ip3 konstaterar samma sak då de också jobbar remote under denna tid vilket har gjort att teamets hastighet har sänkts. Hen beskriver även det som bättre när alla sitter remote, än när några i teamet sitter tillsammans och några på remote.

“De som sitter tillsammans i de fallen har ett kommunikativt övertag.” (Ip3, Företag A)

Ip4 upplever också att allt tar längre tid när de sitter remote då det nu tar mellan 30-40 minuter att ha ett Daily Scrum vilket vanligtvis brukar gå på 15 minuter. Det sätter större krav på att vara lyhörd gentemot sitt/sina team så att man inte missar på viktiga signaler som kan vara lättare att upptäcka i det fysiska mötet. Ip2 från företag B har under COVID-19 valt att slå ihop sina två team, så att de jobbar i samma sprint, då de var osäkra på hur det skulle fungera med skalningen under denna tid. Nu när de arbetar remote är det Ip2 som styr mötet helt vilket inte alls blir lika effektivt.

Både Ip3 och Ip4 från företag A, tror mest på den fysiska kommunikationen. Enligt Ip3 så uppstår en bristfällig kommunikation lättare om kommunikation sker digitalt. Det krävs enligt hen ett gemensamt språk och mål för att lyckas med kommunikationen. Ip2 beskriver att

tidigare bristfällig kommunikation har resulterat i att realese sprinten blivit längre och att atmosfären påverkats negativt då det blivit en stressig miljö.

Trots att Ip4s team kommunicerar bäst fysiskt så har de fått stor nytta av kommunikations- och informationstekniken då de använder sig mycket av TEAMS [Microsoft; min anm.] ifall man behöver säkerställa något. De är även måna om att använda chattfunktioner istället för mail så att allting är öppet och så att alla involveras. På så vis kan alla följa upp vad som sker.

4.3.2. Teammedlemmarnas syn på kommunikationen vid skalning

Ip5 anser att det är viktigt med en fast struktur vid skalning och att kommunikationen är strukturerad så att alla får chansen att höras på möten när det är många delaktiga.

“Den största skillnaden vid små och stora Scrumprojekt är just det att

strukturen förändras” (Ip5, Företag B)

Ip6 från företag A, har gjort det motsatta och istället gått mot ett mindre strukturerat sätt att kommunicera då de i början hade de många möten, men med tiden under skalningens gång blev de mindre och mindre strukturerade i sin kommunikation.

Ip5 bidrar på de dagliga mötena genom att vara kort och koncist och förhålla sig till de frågorna som ska besvaras på Daily Scrum. Hen tycker om när det är strukturerat. Ip5 berättar även att hen var på SoS förra veckan då de brukar rotera vem som får gå. Det är alltså inte alltid Scrum Mastern som går. Något som också uppskattas mycket av Ip5. I SoS får man får höra vad de andra gör och vilka problem som finns för att sen ta med sig den informationen ner till sitt team.

Det är också viktigt vid skalning att Scrum Master för ner viktig information från exempelvis SoS till teamet så att all information blir tydlig för alla och delas med alla. Om informationsspridningen är dålig så påverkas i sin tur även projektet. Det skapas en frustration hos teammedlemmarna om de känner att de inte får ta del av information och projektet tar då längre tid. Ip5 beskriver information som makt och att det blir en så tydlig hierarki om det inte sprids nedåt i organisationen.

COVID-19 har lett till att blivit mer användning av Microsoft TEAMs enligt Ip5. De kommunicerar nu mycket där, både inom- och mellan team. De sitter i vanliga fall i ett öppet landskap i samma våningsplan som de andra teamen, vilket gör det lätt att kommunicera direkt mellan teamen. Nu under COVID-19 kör även dem remote-möten. Nu kan alla vara med på demo där man får feedback för sin funktionalitet, något som inte gick innan när de hade fysiska möten. Vanligtvis har varje team separat en demo. Ip5 ser fördelar med nuvarande situation eftersom att alla kan koppla upp sig på varandras demo för att sitta med och lyssna. Informations- och kommunikationstekniken har alltså bidragit till en ökad transparens och delaktighet i denna situation.

Ip6 kommunicerar precis som Ip5 inom och med de andra teamen via en chatt i Teams [Microsoft; min anm.]. Ip6 föredrar att kommunicera via chatt framför mail då hen upplever

att det är lätt att missa saker när kommunikation sker via mail, men föredrar främst fysiska träffar när de kommunicerar.

” Vi har lärt oss att det är lättare om man sitter i samma rum och har ett möte,

eller i alla fall ser varandra än att skicka alla förbaskade mail.” (Ip6, Företag

A)

Den rådande situationen med COVID-19 har tvingat alla i teamet att sitta remote. Ip6 ser precis som Ip5 fördelar med detta. I vanliga tider är det lätt hänt att någon tar ordet och fortsätter och nu blir det mer struktur i vem som pratar under Daily Scrum mötet. Det gör även alla mer delaktiga då de nu har planning board där alla arbetsuppgifter är strukturerade som de tillsammans går igenom på mötet.

4.4. Gruppens samverkan

4.4.1. Gruppens samverkan utifrån Scrum Masters

På företag A inom teamen som Ip1 arbetar med har grupputveckling och människosyn stort fokus.

”För att bygga ett högeffektivt autonomt team måste man hitta balansen mellan

skyldigheter och rättigheter.”(Ip1, Företag A)

Enligt Ip1 handlar skyldigheterna om att teamet ska leverera och rättigheterna om att teamet ska få bestämma hur de vill arbeta själva så att de kommer bort från det hierarkiska. Det är teamen själva som sköter koordineringen och kommunikationen mellan dem. Viktigaste för Ip1 som Scrum Master är att se till att det inte blir några personkonflikter under fas två [IMGD modell; min anm.] i grupputvecklingen. Ip2 från företag B, nämner också de olika faserna som teamen går igenom, vilka hen anser stämma väldigt bra. Ip2 beskriver det som en utmaning att nå fas 4 [IMGD modell; min anm.] där teamen blir stabila.

“Man måste låta teamet vara och lära sig hitta varandra” (Ip2, Företag B)

Ip2 tycker detta är viktigt, för om man flyttar och lägger till folk kommer teamet aldrig ens komma ur fas 1 eller fas 2.

Ip2 arbetar mycket med en nära-kontakt mellan och med teamen, därav tog hen fram produktägare-idén. Hen tycker det är viktigt att alla har en gemensam bild av vad som ska göras och att man diskuterar med varandra. För Ip3 från företag A, styrs samverkan och kommunikationen mellan teamen av hur mogna de är. I början anser Ip3 att det är jätteviktigt med Scrum möten, där Ip3 som Scrum Master hjälper till så att det blir någon kommunikation överhuvudtaget. Ip3 menar att när teamen kommit längre i sin utveckling sker kommunikationen mer spontant, vid behov och koncentrerat på vad som behövs. Även samverkan digitalt blir bättre. Precis som Ip2 från företag B, anser Ip3 att teamet måste få sin tid, cirka sex månader, för att detta ska kunna ske.

problemen man har. Ip4 hade tidigare ett dysfunktionellt team där arbetet skedde mycket individuellt och där det saknades både tillit och samarbetsförmåga. Projektet far illa och Ip4 blev tillslut tvungen att byta ut hela teamet. Ip4 försöker coacha teamet att själva se vad som behövs göras och fatta beslut om detta, till exempel; nu borde vi parprogrammera. Hen anser att teamet blir mer effektivt när de faktiskt får driva sitt eget. Ip4s mål är att finnas där som stöd och även påminna dem om detta när det behövs. Ip4 anser att desto mognare teamen är desto effektivare kan de vara och desto lättare blir samarbetet inom teamet och med de andra teamen.

4.4.2. Gruppens samverkan utifrån teammedlemmar

I Ip5s team på företag B, råder det idag tydliga strukturer på vad som ska göras och en öppen informationsspridning mellan teamen. Detta är något som har förbättrats under skalningsprocessen. För Ip5 är det strukturerat så att inte för många ska gå på samma möten för att alla ska få sin chans att hinna prata. Ip5 är nöjd med sin Scrum Master då hen delegerar ut mycket ansvar till teamet och har en rotation om vem som får gå på SoS, inte endast Scrum Mastern. Ip6s team från företag A, jobbar mycket med teamkänslan, men hen upplever ibland att det saknas ett gemensamt språk. Det händer att dem pratar förbi varandra för att man tror att man menar samma sak trots att man inte gör det, då olika individer besitter olika kunskaper. När de jobbade tillsammans med ett annat team litade inte Ip6 riktigt på att få det utrymme som kunde krävas för att leverera och det fanns en osäkerhet i hur man skulle bemöta varandra.

”I början var allting så nytt så då visste man inte riktigt vad man skulle fråga.

Man får bygga upp lite kunskap själv innan man kan ställa relevanta frågor.”

(Ip6, Företag A)

4.5. Strategier för att lyckas med skalning av Scrum

4.5.1. Strategier för att lyckas med skalning av Scrum utifrån Scrum Masters

Ip1s strategi för att hantera de kommunikativa utmaningarna som följer med Scrum är att vara närvarande och jobba med autonomiprincipen.

”Många riktar in sig på att lösa koordineringsproblemet, vilket inte är ett

problem om teamen kan vara autonoma.” (Ip1, Företag A)

Ip1 är noga med att kommunikationen inte får byggas via Scrum Mastern utan hens jobb är att se till att teamen får den styrka det går för att kommunicera självständigt med varandra.

Ip2 från företag B, beskriver två huvudtaktiker som har fungerat bra. Den första är hierarkiska möten, att ha med sig det till toppen där det finns ytterligare en liten grupp, som SoS. Den andra är att arbeta med visualisering, tavlor och diagram som är synligt tillgängliga vilket ger alla samma bild av den verklighet de befinner sig i. Ip2 tycker det är viktigt vid skalning att de lärdomarna som görs i teamet visas upp så att hela organisationen kan ta värde av detta. Ip2 hade velat se en informationsspridning högre upp i organisationen för att möjliggöra detta.