DESIGNPROCESSEN I EN AGIL IT-MILJÖ

DESIGNPROCESSEN

I EN AGIL IT-MILJÖ

Abstract

Förord

Vi vill ge ett stort tack till vår handledare Dan Johansson för hans konstanta stöd, snabb feedback och fantastiska engagemang. You da real MVP.

Innehållsförteckning

2.1 Det agila arbetssättet ... 7

2.2 User Experience och User Centered Design ... 9

3. Relaterad forskning ... 10

3.1 Samarbete mellan designers och utvecklare i agila team ... 10

3.2 Agil design ... 10

3.3 Integration av User-Centered Design och Agil utveckling ... 12

4. Metod ... 14

4.1 Metodval och tillvägagångssätt ... 14

4.1.1 Fallstudie ... 14

4.1.2 Enkät ... 14

4.1.3 Kvalitativa intervjuer ... 15

4.2 Case ... 15

4.3 Datainsamling och urval ... 15

4.4 Litteraturval ... 16 4.5 Dataanalys ... 16 4.5.1 Utförande ... 16 4.6 Metodkritik ... 17 4.7 Forskningsetiska principer ... 18 5. Resultat ... 19 5.1 Enkät ... 19 5.2 Intervju ... 19

5.2.1 När sker designarbetet i relation till utvecklingen? ... 20

5.2.2 Planering av designarbetet ... 22

5.2.3 Projekt och agilitet ... 23

5.2.4 Kommunikation och samarbete ... 24

5.2.5 Överlämning ... 25

6. Diskussion och analys ... 27

6.1 Analys ... 27

6.2 Diskussion ...30

7. Slutsats ... 31

Referenser ... 32

1. Inledning

Agilt arbete innebär i grund och botten att vara flexibel. Tiden i ett projekt delas in i tidsboxar, där cykler av att planera, utföra, kontrollera och sedan handla sker kontinuerligt. (Gustavsson, 2016) I varje cykel skapas något som i nästa cykel förbättras. Agila metoder har i nuläget blivit en paraplyterm som innefattar flera olika arbetssätt som grundar sig i det agila tänket. Löpande kommunikation och reflektion är något som förespråkas inom det agila, i form av korta stå-upp-möten under arbetets gång och erfarenhetsmöten efter varje genomförd cykel.

Det agila arbetssättet som idag används inom många typer av företag blev från början framtaget för arbete inom IT, närmare bestämt utveckling. Den agila metoden innebär att man jobbar iterativt och i sprintar för att konstant ha en leverabel som ska kunna testas och utvärderas. (Gustavsson, 2016) De agila metoderna utvecklades som en reaktion till den traditionella projektledningen. En av de mest etablerade av dessa traditionella projektmetoder är den så kallade vattenfallsmetoden. (Jacobson, Lawson, Ng, McMahon, & Goedicke, 2019) Vattenfallsmetoden består i grund och botten av ett antal faser som infaller linjärt efter varandra. T.ex. så kan den se ut så här: Analys > Design > Utveckling > Test, där varje fas är ett stort projekt i sig som sedan lämnas över till de ansvariga för nästa fas. Problematiken i den typen av projekt är att det i den sena testfasen ofta upptäcks saker som måste ändras och det blir ett stort och dyrt pådrag att göra detta. I de agila projektmetoderna ville man motverka detta genom att hela tiden arbeta mot något konkret som kan implementeras och testas i varje sprint. (Jacobson, Lawson, Ng, McMahon, & Goedicke, 2019)

Design är en integral del av utformning av nya webbplatser och applikationer. Genom

User Experience Design (design av användarupplevelsen) eller interaktionsdesign,

fokuserar designern på användarens behov och mål. (Sharp, Preece, & Rogers, 2019) Likt den agila metoden så sker arbetet med User Experience Design (UX) i ett iterativt flöde, men då detta traditionellt skett som en förstudie där färdiga specifikationer lämnas vidare till nästa fas kan det vara svårt att veta var design hamnar i den agila helheten. Enligt vattenfallsmetoden skapas designen utefter de analyser som gjorts, vilken sedan lämnas över till ett utvecklarteam. (Jacobson, Lawson, Ng, McMahon, & Goedicke, 2019) De agila metoderna har ofta inte en specificerad modell för hur designarbetet ska ske i relation till utvecklingen utan flera, där en bedömning får göras av teamet kring hur de vill arbeta.

1.1 Syfte

1.3 Frågeformuleringar

2. Teoretiskt ramverk

Inom arbete med webbutveckling finns ett antal arbetsmetoder och förhållningssätt till det agila. Här presenterar vi här det ramverk vi utgått ifrån i form av terminologi inom de agila metoderna samt en introduktion till den relevanta designteorin.

2.1 Det agila arbetssättet

Det agila arbetssättet följer fyra kärnvärderingar för att projekten ska fungera så bra som möjligt. Den första är att värdera individer och interaktion framför processer och verktyg, den andra är fungerande programvara framför omfattande dokumentation. Den tredje placerar kundsamarbete framför kontraktsförhandling och den fjärde trycker på anpassning till förändring framför att följa en plan. (Beck, o.a., 2001)

Målet med det agila arbetssättet är att göra det möjligt att ha leverabler tidigare än vad som är möjligt i mer traditionella arbetssätt, detta görs genom att jobba iterativt och med någonting som kallas för sprintar. Kortfattat så kan en sprint beskrivas som en iteration av den slutgiltiga produkten i ett projekt. Dessa sprintar sträcker sig vanligtvis mellan en och fyra veckor. Det är vanligt för företag att ha en förbestämd längd på alla sprintar, sprintarna kan dock i vissa fall vara olika långa. I början av varje sprint bestäms sprintens omfattning samt vad som ska göras under sprintens gång. Målet med en sprint är att i slutet alltid ha en produkt som kan visas upp och demonstreras. Genom arbete med sprintar kan man få en inblick i teamets utvecklingshastighet, detta kan i sin tur hjälpa gruppen att planera omfattningen av framtida sprintar. (Brown, 2013)

I agila projekt arbetar man med någonting som kallas för user stories, eller användarhistorier, istället för att ha en lista över den funktionalitet som ska återfinnas i programmet. Dessa används för att göra det lättare att fokusera på användarens behov, istället för ren funktionalitet i programmet. Dessa user stories är skrivna ur ett användarperspektiv, följande är ett exempel på hur formatet hos en user story kan se ut; ”Som en …, skulle jag vilja ha möjligheten att …”. För att förtydliga ännu längre så kan man även lägga till ”så att jag kan …” . I exemplet byts ”…” ut mot relevant information för det nuvarande projektet. Ett slutgiltigt exempel skulle kunna se ut på följande sätt: ”Som en student skulle jag vilja ha möjligheten att hitta en studiegrupp så att jag kan lära mig lättare”. Här beskrivs vem produkten är riktad mot, vad personen vill göra, samt varför personen vill detta. (Brown, 2013)

en sprint backlog endast innehåller de user stories, epics, uppgifter eller buggar som måste utvecklas/åtgärdas i den nuvarande sprinten. Alla delobjekt som finns i en backlog prioriteras, det vill säga att de viktigaste delarna blir högt prioriterade medan mindre viktiga delar får en lägre prioritering. När en sprint backlog skapas i början av varje sprint så tas objekt från en product backlog, de objekt som blir över i en product backlog omprioriteras sedan för att underlätta planering i nästkommande sprint(ar). För att underlätta arbete med en sprint backlog brukar man vanligtvis endast ha med de delobjekt som omfattar den nuvarande sprinten. (Brown, 2013)

Personen som bär störst ansvar i ett agilt projekt kallas för produktägare. Produktägaren är vanligtvis den produktansvarige alternativt företagsägaren som köper produkten, men om dessa personer ej finns tillgängliga av någon anledning så kan produktägaren även vara någon som är del av produktionsteamet. Om så är fallet är det vanligtvis en utvecklingschef som tar på sig denna roll. Denna person är i slutändan den som är ansvarig för slutprodukten. (Brown, 2013)

Det produktägaren har översikt över är hur user stories ska prioriteras vilket innebär att det är viktigt att denne person förstår vikten av användarfokuserad design. Det är även viktigt att de personer som arbetar med UX i projektet gör så i tät anslutning till produktägaren eftersom det är den som arbetar med UX som är ansvarig för hur produkten designas medan det emellertid är produktägaren som faktiskt ”äger” hela produkten vilket innefattar designen. I slutändan är det även produktägaren som styr över projektets

backlog och hur objekten i den ska prioriteras. (Brown, 2013)

Ett annat verktyg som används för att hantera ärenden och planering i ett agilt projekt är en projekttavla, oftast kallad kanban. Denna tavla är ett verktyg i det agila arbetet där tre kolumner sätts upp; ej påbörjat, påbörjat, klart. Arbetsuppgifter listas t.ex. på post-it lappar som flyttas mellan de olika kolumnerna. Kanban är en mer detaljerad version av detta, där varje steg (ej påbörjat, påbörjat, klart) kan få mer detaljerade punkter, ex. analys och utveckling. Här sätts även ett maxantal för hur många lappar respektive del av tavlan får innehålla, för att förhindra att fler arbetsuppgifter påbörjas utan att något görs klart. (Gustavsson, 2016)

Agila metoder är som vi beskrivit i bakgrunden en paraplyterm som kapslar in en mängd olika former av arbetsmetoder som alla i grund och botten är skapade för att arbeta så flexibelt som möjligt. En av de mest vedertagna av dessa agila metoder är den så kallade

scrum metoden. Scrum är en populär arbetsmetod inom det agila arbetssättet. I ett team

som beskrevs tidigare, dessa kan ses som förvaringsplatser för det som måste genomföras i projektet. (Brown, 2013)

I scrum så bestämmer teamet tillsammans vad som behöver omfattas i varje sprint och skulle någonting behöva ändras när en sprint har påbörjats är det bara teamet själva som har någon talan i vilka ändringar som kan göras, även om förfrågningar på ändringar kommer från någon utomstående part så är det i slutändan alltid teamet själva som väljer hur de fortgår. (Brown, 2013)

För att hålla alla parter inom projektet informerade använder utövare av scrum sig ofta av dagliga stå-upp-möten (daily standups) där endast personer som arbetar i projektet har möjlighet att dela med sig av det som de arbetar med samt de hinder de kan tänkas stå framför. Stå-upp-möten är korta, effektiva möten där deltagarna helst ska stå upp. Vikten ligger på att behålla fokus och att mötet ska orsaka så lite tidsspill som möjligt. Utspridda grupper kan använda sig av digitala verktyg som Skype eller gruppsamtal. (Gustavsson, 2016)

I början av varje ny sprint planeras omfattningen av sprinten och vilka delmoment som den ska innefatta. I slutet av varje sprint görs en återblick över sprinten där teamet går igenom vad som blivit slutfört och vad som ej hunnit slutföras. Detta resultat delas sedan vidare till intressenter. Vid varje sprints slut hålls även erfarenhetsmöten. Dessa är till för att reflektera över det som gjorts för att kunna göra det ännu bättre i framtiden. Genom att hålla erfarenhetsmötena löpande kan misstag korrigeras under projektets gång. (Gustavsson, 2016)

2.2 User Experience och User Centered Design

De som designar interaktiva system finner mer och mer att de inte bara bör designa användbara system utan också bör skapa något som ger dess användare en god användarupplevelse. Hemsidor måste både kunna locka till sig och behålla kunder om de ska vara lönsamma. Det är detta som är User Experience design. En nära term är Customer

Experience, vilket innebär samma sak, men tillåter förflyttning bort från termen

’användare’. (Benyon, 2014)

User Centered Design (UCD) är ett annat sätt att benämna ungefär samma sak som

3. Relaterad forskning

Detta stycke redogör för relaterad forskning samt relevanta texter vi tagit del av i arbetet.

3.1 Samarbete mellan designers och utvecklare i agila team

Vid research har flera olika arbetssätt när det gäller samarbete mellan utveckling och design identifierats. Green (2016) listar i sin bok om scrum tre varianter som har sina fördelar och nackdelar. Ett designteam kan endera arbeta en sprint före utvecklingsteamet, för att kunna isolera designarbetet medan teamet fortfarande är en del av scrum. Problematiken med detta ligger i att en sprint blir dubbelt så lång, kräver mer planering och arbetet blir mindre flexibelt. En annan metod är att bibehålla ett separat designteam som kan kallas in som resurs. Detta team kan delta som gäster i scrumprocessen, men behöver inte delta aktivt. Med fördel kan ett separat designteam använda sig av arbetsmetoden Kanban istället, för att arbeta agilt men med en specificerad arbetsmängd istället för att arbeta mot leverabler. (Green, 2016) Vissa team involverar sina designers i samma sprint som resten av teamet. Fördelen med detta är att designern är involverad i allt och konstant medveten om vad som sker, däremot lägger det väldigt mycket press på designern att konstant kunna leverera och samarbete mellan en designer och utvecklare kan te sig obalanserat på grund av att designerrollen inte är specificerad i scrum.

Jones, Thoma och Newell (2016) gjorde i sin studie ”Collaboration Constraints for

Designers and Developers in an Agile Environment” en undersökning kring begränsningar

i samarbetet mellan designers och utvecklare inom samma företag. Bland annat beskrev båda rollerna att de upplevt att mycket av designarbetet skett innan arbetssprintar vilket lett till att utvecklare inte känner att de kopplats in tidigt nog. De uttryckte även att åsikter och tankar kring designen inte kommer in tidigt nog. Utvecklarna ville bli involverade redan i idéfasen och båda rollerna upplevde en brist på kommunikation och kollaboration. (Jones, Thoma, & Newell, 2016)

3.2 Agil design

Design är ofta en del i en agil process, men designarbetet i sig är inte alltid agilt. Enligt Armitage (2004) är fördelarna med att arbeta agilt även i designprocessen att det som skapas i korta iterationer kan testas av riktiga användare vilket gör att verktyg för användartester kan plockas in tidigare och ge mer data. Kortare sprintar kan också uppmuntra till experimenterande och de omfattande specifikationsdokumenten som annars behövs försvinner. Armitage (2004) listar även ett antal tips kring hur designers kan tänka kring sitt arbete, bland annat att det är viktigt att bedöma framgångar utifrån framgångar i projektet, uppskatta att tidiga men ofullständiga lösningar kan vara viktigare än sena men fullständiga lösningar. Designers bör även kunna skapa lösningar som enkelt kan förändras och kunna börja med att skapa den enklast möjliga modellen av sitt arbete, samt så bör denne snabbt kunna hoppa mellan uppgifter på en lägre till en högre nivå. (Armitage, 2004)

Sharp, Preece, och Rogers (2019) presenterar ett samlingsnamn för att beskriva arbetet med att integrera User Experience (UX) med de agila processerna, nämligen

påverkas sen uppkomsten av de agila arbetsätten. En nyckelaspekt för framgång är att teamen ska förstå att User Experience inte bara är en roll utan en disciplin. AgileUX är i praktiken inte helt enkel, det måste finnas en balans som bevarar både den research och reflektion som behövs för god UX-design, men som även blandar in snabba iterationer med användarfeedback och tester. Istället för att designa allt från början, måste designers lära sig att bara skapa och leverera det som behövs i stunden. Att leverera något som inte känns färdigt kan för UX-designers upplevas som oroande, då designartefakter är huvudleverabeln och de kan betraktas som färdiga, medan för utvecklare skapas något som konsumeras och som måste förändras då implementation och krav specifieras. Sharp, Preece, och Rogers (2019) specifierar att agileUX kräver särskild uppmärksamhet kring tre saker:

• Vilken typ av användarundersökningar man bör göra, hur mycket och när. • Hur man anpassar UX design till agila metoder.

• Vilken dokumentation man bör skapa, i vilken mängd och när.

Med användarundersökningar menas den data som är nödvändig för att definiera användarna och deras användarkontext innan produktutvecklingen drar igång. Utvärderingar av designelement eller klargörande intervjuer kan göras under arbetets gång, men den större undersökningen bör vara gjord i vad Sharp, Preece, och Rogers (2019) kallar sprint noll, alltså innan allt annat arbete.

Sharp, Preece, och Rogers (2019) menar även på att om alla krav är specifierade innan implementation påbörjas, finns det en tendens för UX-designers att skapa en komplett design i början av arbetet för att säkerställa en att den är en helhet. Detta kallas big design

up front vilket inte är optimalt i det agila. För att undvika att detaljer skapas, som sedan

Den tredje saken UX-designers bör vara särskilt medvetna om är mängden dokumentation, då det vanligaste sättet att kommunicera designarbetet har varit genom skisser, wireframes och beskrivningar av dessa. I agileUX bör dokumentation inte ersätta kommunikation och samarbete, men det betyder heller inte att ingen dokumentation alls får eller bör finnas. (Sharp, Preece, & Rogers, 2019)

3.3 Integration av User-Centered Design och Agil utveckling

Chamberlain, Sharp och Maiden har i sin artikel ”Towards a Framework for Integrating

Agile Development and User-Centred Design” (2006) föreslagit ett ramverk tänkt att

hjälpa till med integrationen av designers in i det agila teamet, ramverket är huvudsakligen tänkt att integrera User-Centered Design (UCD) och agil utveckling men mycket av det de kommit fram till kan användas av andra typer av designteam. På grund av att design ofta är en iterativ process så menar de på att det finns många förmånliga likheter mellan hur designers jobbar och hur ett agilt team jobbar vilket underlättar denna integration.

I UCD är huvudsyftet att sätta användaren i fokus, man vill få reda på så mycket information som möjligt kring användaren innan designern skapar en första prototyp. Den första, väldigt enkla, prototypen testas sedan av användaren för att därefter skapa mer sofistikerade prototyper. Denna process, likt den agila processen, är iterativ och fortlöper fram till och med en sista version är skapad.

Redan här kan vi se att det finns likheter i de två arbetsprocesserna, framförallt kan vi se att båda dessa processer är iterativa processer där resultatet från en tidigare iteration hela tiden byggs vidare på. Utöver detta så finns det i båda arbetssätten en tung betoning på användarutvärderingar genom hela processen, jobbar man agilt så användartestar man ofta i slutet av varje sprint och i UCD har man genom hela processen ett fortgående stort fokus på användaren.

Chamberlain et al. har tagit fram grundprinciper som de anser är viktigast i team där UCD och det agila arbetssättet ska integreras. Några av de grundprinciper de tagit fram är dessa:

• Användarinblandning - med detta menar de att användaren är en nödvändig del att ha med genom hela utvecklingsprocessen och bör till och med ses som en del av teamet. • Samarbete och företagskultur - det är väldigt viktigt för designers och utvecklare att

samarbeta väldigt nära genom hela projekt, inte bara i en överlämningsprocess. Med företagskultur menar de att det lätt kan bli en defensiv barriär mellan de olika kompetenserna eller att det blir något av en maktkamp mellan designers och utvecklare. Något de observerat är att de olika kompetenserna skyddar sig själv från att behöva ha att göra med beslut som den andra gruppen tagit fram.

• Prototyping - de designers som arbetar på ett projekt behöver vara villig att fortlöpande mata utvecklarna med både prototyper och användarfeedback. Detta bör ske med jämna mellanrum i cykler som alla inblandade är bekväm med tidsmässigt. • Projekts livscykel - Designers i ett projekt bör ges gott om tid innan utvecklare börjar

att koda för att ta reda på användarnas behov.

4. Metod

I denna del beskriver vi vilka forskningsmetoder vi har valt att använda oss av och varför vi har valt dessa metoder, samt ger en kort beskrivning av vad de innebär.

4.1 Metodval och tillvägagångssätt

Många företag har idag hand om inte bara en del av utan hela processen när det gäller att utforma och implementera en produkt eller en webbplats. Det är ett stort arbete och blandar in många olika kompetenser och arbetssätt. För att kunna sätta oss in i en sådan situation på så relevant sätt som möjligt har vi valt att använda oss av flertalet forskningsmetoder, detta för att säkerställa att vi får ut den information vi behöver och att denna är korrekt. (Bryman, 2012)

För att få så god inblick i denna process som möjligt vill vi intervjua kompetenser som redan arbetar med detta. Genom att göra detta mot ett företag istället för flera kan vi få en mer djupgående inblick i det specifika fallet. Inledningsvis skickas en enkät ut för att lägga en grund inför intervjuerna, dels för att ta reda på lite mer kring vilka kompetenser som finns i företaget. Enkäten ger oss möjlighet att få en bredare inblick i hur arbetsprocessen ser ut och möjliggör än mer specificerade frågor i intervjuerna. Kombinationen av enkät och sedan kvalitativa intervjuer ger en god bas, då vi utifrån enkätsvar får möjlighet att göra vidare litteraturstudier på eventuella frågetecken som dyker upp innan vi tar itu med intervjuer. Studien fokuserar främst på de kvalitativa resultaten, men kombinationen används för att få en större grupp respondenter samt att utifrån enkätsvaren kunna utveckla intervjufrågorna. (Bryman, 2012)

4.1.1 Fallstudie

Fallstudier fokuserar på ett fenomen som sker inom en särskild kontext, i detta fall designprocessen. Det går att göra en eller flera fallstudier för samma teori (Jensen & Sandström, 2016) men i detta fall görs bara en, detta dels för att det är svårt och tidskrävande att få tag i företag, samordna möten med dessa och för att vi i detta arbete är relativt pressade på tid. Jensen och Sandström (2016) beskriver i sin bok Fallstudier ett antal tumregler att förhålla sig till både innan, under och efter fallstudiens genomförande. Här har vi tagit med oss att det är viktigt att genomföra litteraturstudier innan den empiriska forskningen för att kunna ställa de mest relevanta frågorna.

I denna studie görs fallstudien på ett lokalt IT-företag som arbetar agilt och som hanterar både design och utveckling. Detta görs för att få en konkret inblick i hur ett företag arbetar och hur personal upplever att arbetsprocessen fungerar.

4.1.2 Enkät

Enkäter möjliggör en standardiserad datainsamling från en större grupp respondenter. De kan utformas med hjälp av frågesatser eller påståenden, där frågesatser är att föredra då ett påstående kan upplevas som mer styrande. (Persson, 2016)

fungerar i teamen. Dessa teman har plockats ut från den relaterade forskningen inom ämnen, då stor vikt ligger på god kommunikation och att teamet samarbetar från start till mål. (Jones, Thoma, & Newell, 2016) Enkäten syftar till att samla in data kring hur väl respondenterna upplever att kommunikationen fungerar, samt i vilka former de sker.

4.1.3 Kvalitativa intervjuer

Arbetsprocessen inom företaget innefattar många olika personligheter och med detta även varierande förhållningsätt till arbetet och hur processen uppfattas. Det vi vill undersöka grundar sig i mycket kring hur arbetsprocessen och överlämningen upplevs. För att få in data kring detta krävs intervjuer med personal. Kvalitativa intervjuer är mer som ett samtal, vilket leder till att man kan anpassa frågor till individen i stunden och få ut mycket från sin datainsamling. (Yin, 2016) Genom en förstudie av relevant litteratur plockar vi ut frågor vi upplever relevanta för vårt syfte och frågeställningar; men möjligheten att fråga vidare om något i stunden välkomnas.

Vi har i denna studie valt att använda oss av kvalitativa intervjuer för att få en rik inblick i hur olika kompetenser arbetar samt hur de tycker att samarbetet i projekt fungerar. Genom att använda kvalitativa intervjuer kan frågor tas fram på förhand och eftersom intervjun artar sig mer som ett samtal så kan vi under intervjuns gång ställa uppföljningsfrågor vilket inte är någonting som är möjligt vid användning av exempelvis en enkät.

4.2 Case

Studien görs i samarbete med ett lokalt IT-företag som använder sig av agila arbetsmetoder. Det främsta arbetet sker inom webbdesign och webbutveckling. Företaget finns idag på orter över hela Sverige, så samarbete både på plats och på distans sker flitigt. I detta arbete ligger fokuset på de som arbetar inom design och utveckling på kontoret lokalt och på en annan svensk ort vilket innefattar cirka trettio personer.

Företaget använder sig av ett ärendehanteringssystem som kallas Jira1_{, här kan}

ärenden skapas och åtkomst kan ges till alla personer som samarbetar i ett projekt. I Jira kan de olika kompetenserna som arbetar i projektet skriva kommentarer för att underlätta för de andra i teamet. Utöver Jira så använder de sig även av ett prototypverktyg som heter Figma2_{, här kan en design skapas och sedan ses av alla medlemmar i projektet, samt}

kunden.

4.3 Datainsamling och urval

att kommunicera. Intervjuerna spelades in för att möjliggöra transkribering. Valet att ha distansintervjuer påverkades delvis av en rådande pandemi3_{, men det var även det enklaste}

sättet att kunna intervjua kompetenser på annan ort.

Vår kontakt på företaget ordnade kontaktuppgifter till sju respondenter, inklusive sig själv, utifrån kommunikation och rådläggning kring vilka kompetenser vi behövde intervjua. Främst ville vi intervjua de som i någon mån arbetar med UX-design eller grafik, men även utvecklare för att skapa en bredare bild av hur arbetet ser ut.

4.4 Litteraturval

Litteraturen har plockats ut dels i åtanke kring forskningsmetoden, samt för att få perspektiv kring relaterad forskning och för att själva sätta oss in i de agila arbetsmetoderna och termerna. Tidigare kurslitteratur som ansetts relevant har plockats med, samt böcker om ämnet och artiklar från ACM Digital Library. Databassökningar med nyckelord eller fraser så som ”agile design”, ”agile UX”, ”designer developer collaboration”, etc har lett oss till inledande artiklar. Utifrån dessa har vi funnit relaterade artiklar där vi genom titel och abstract gjort snabba bedömningar kring relevans och sedan endera sållat bort eller plockat in dessa för läsning. Detta gjordes för att skapa en selektiv översikt kring de studier som redan finns och vilka aspekter inom området de behandlar, för att kunna nischa in denna studie och ställa den mot de data som redan existerar. (Yin, 2016)

4.5 Dataanalys

På grund utav att intervjustudien som gjorts i detta arbete är kvalitativ valde vi att tillämpa en så kallad tematisk analys för att identifiera, analysera och presentera olika teman vi funnit i vår data. Yin (2016) beskriver hur en analys av kvalitativ data rör sig genom fem faser, varav den första består av att sammanställa och organisera materialet i en form av databas. Den andra fasen behandlar att plocka isär och eventuellt tematisera materialet i databasen och i den tredje sätter man ihop materialet igen med forskarens insikt och möjlighet att se mönster i datan. Den fjärde fasen involverar att tolka det ihopsatta materialet för att skapa ett nytt narrativ, vilket leder vidare till den sista fasen som består av att dra en slutsats utifrån hela studien. Dessa faser sker inte nödvändigtvis linjärt efter varandra utan snarare i en iterativ bearbetning. (Yin, 2016) Sammanställningen av intervjuerna har skett utifrån denna metod, där materialet granskats, viktiga delar markerats och utifrån detta har ett antal teman ställts upp i ett kalkylark för att kunna sortera in datan i tabeller. Teman identifierades genom återkommande fraser eller indelningar av arbetssätt och projektstruktur. (Bryman, 2012) En generalisering av varje temakolumn skapades sedan för att kunna ställa detta mot tidigare forskning i vår tolkningsfas.

4.5.1 Utförande

I den första fasen transkriberades alla ljudfiler för att återbekanta oss med materialet och en sammanställning av allt det insamlade materialet gjordes. Under transkriberingen

antecknade vi relevanta delar och gick sedan tillsammans igenom allt det transkriberade materialet ett flertal gånger.

I nästa fas av analysen så återkopplade vi till det vi funnit i relaterad forskning till vår insamlade data och diskuterade sinsemellan vilka delar av materialet som var av särskild vikt. På så sätt kunde vi identifiera ett antal teman i det insamlade materialet. Sammanlagt kom vi överens om 14 teman. (se figur 2)

I den tredje fasen skapade vi ett kalkylark för att effektivt kunna ställa upp de teman vi kommit överens om och plocka in relevant data från transkriberingsdokumenten. Detta gav oss en översiktsbild över det våra respondenter sagt under intervjuerna och vi kunde på ett enkelt sätt se vilka likheter och skillnader vi fått från respondenternas svar.

Utifrån det uppställda materialet kunde vi i fas fyra tolka vår data och valde här att begränsa oss ytterligare när det gällde kategorisering. Här slog vi ihop vissa teman som gett snarlika resultat. Ett exempel på detta är att ’planering’ och ’Tidigt projekt- vilka

kompetenser’ slogs ihop, vilket i resultatet kan ses under rubriken ’planering i designarbetet’. Denna process itererades ett flertal gånger tills att vi var nöjda med våra

teman och den data vi hade placerat under varje tema.

Slutligen, i den femte och sista fasen så gicks allt material igenom en gång till. Ett resultat sammanställdes där vi presenterade den data som respondenterna uttryckt i intervjuerna. Detta material fungerade sedan som en bas för den fortsatta analysen i denna studie, där vi relaterar den data vi fått fram genom intervjuer med det vi funnit i relaterad forskning. Genom detta och personlig insikt har vi sedan dragit vår slutsats.

4.6 Metodkritik

den ska vara okomplicerad och lättförstådd. (Persson, 2016) I och med att alla intervjuer tett sig lite annorlunda beroende på samtalsflödet så har också frågeformuleringarna ändrats lite beroende på kontext.

Problematik finns även när det gäller urvalet av respondenter vilket gjordes genom en form av snöbollsurval. I detta fall innebär detta att den första respondenten ordnat kontakt med resterande deltagare. Denna typ av urval är dock mer problematisk när det gäller kvantitativa studier än kvalitativa, men kan ändå vara viktigt att ha i åtanke gällande de svar som erhållits. (Bryman, 2012) I och med att vi fick möjlighet att påverka vilka kompetenser som förfrågades så blev urvalet ändå relevant. Att hitta dessa kompetenser hade varit svårt utan någon med inblick i företaget.

En viss debatt råder när det gäller att använda sig av blandade forskningsmetoder, dvs. kombinationen av kvantitativa och kvalitativa studier. Vissa menar att dessa metoder är utformade efter separata värderingar, och att dessa typer av data är inkompatibla med varandra. (Bryman, 2012) I vår studie har en separation av de blandade metoderna skett, vilket ger en möjlighet att analysera materialet separat istället för i en sammanställd analys. Enkäten analyserades för att ge en bas inför intervjuerna. Därav behandlar den insamlade datan olika aspekter och behöver inte värderas utifrån kompabilitet.

4.7 Forskningsetiska principer

5. Resultat

Här sammanställs det vi tagit med oss från de olika datainsamlingarna. I och med de kvalitativa intervjuerna samlades en större mängd data in, vilken sorterats utifrån relevanta teman och sedan presenteras.

5.1 Enkät

Totalt svarade tretton personer på enkäten, varav en fjärdedel av de som svarat är kvinnor. Majoriteten av de som svarade på enkäten arbetar främst i team på distans eller lika mycket på distans som på plats. Kommunikationen i projektteam på plats upplever de flesta funkar mycket bra, medan distanskommunikationen uppfattas som bra men inte fullt lika bra som den på plats. Majoriteten svarade dock att i de flesta projekt ses teamet flera gånger och de upplever att de kan kommunicera öppet med alla eller de flesta i sitt team. De flesta arbetar parallellt i flera projekt samtidigt.

En öppen fråga kring hur överlämning mellan design och utveckling fungerar gav varierande svar, vissa uppfattar inte att någon överlämning sker utan designers och utvecklare är med genom hela processen, medan någon beskrev att det fungerar bäst med tydliga gränser mellan områdena. Det som togs upp som positivt är när kommunikation och dokumentation funkar bra, när flera kompetenser är involverade tidigt och i varje steg som tas, samt är överens om helhetsbilden. Det som upplevs som negativt är att problem kan uppstå i rollfördelning; att vissa arbetsuppgifter förväntas vara utförda av den ena rollen men inte blir det, det som också upplevs som negativt är otillräcklig info vid överlämning och svårigheter att tajma uppgifter.

5.2 Intervju

Totalt sju intervjuer genomfördes, varav alla utom en under spannet av samma vecka. Under två av intervjuerna genomfördes mindre observationer på två av de mest använda programvarorna, Jira och Figma. En mängd frågor och följdfrågor gjordes i ordning men alla ställdes inte i alla intervjuerna då många svar behandlade flera områden och oställda frågor blev på så sätt besvarade. Frågorna handlade om respondenternas arbetsprocess, hur de upplever sitt eget arbete, hur det agila arbetet fungerar samt hur kommunikationen och samarbetet ser ut mellan kompetenser.

B Teamledare, projektledare, User Experience

Kvinna Har som teamledare ansvar för att teamet levererar utifrån åtaganden. Även operativ som konsult, främst med projektledning men även ibland på detaljnivå med UX. C Utvecklare, grafisk

formgivare

Kvinna Arbetar i Office 365-teamet, främst med design och UX. Innan arbetat med front-end och innehåll.

D Projektledare, User Experience/Customer Experience

Kvinna Arbetar som teamledare men även som projekt- eller förvaltningsledare och lite operativt inom UX området.

E User

Experience/Customer Experience

Man Arbetar med UX, webbanalys och innehållsjobb.

F Front-end utvecklare, designer

Man Jobbar framförallt med UXdesign och front-end utveckling, men sysslar ibland med lite krav och test. G Front-end utvecklare Man Arbetar med front-end utveckling, dvs. bygger det grafiska gränssnittet.

Tabell 1 Respondenter

5.2.1 När sker designarbetet i relation till utvecklingen?

Respondent A som endast arbetar med design beskriver att designarbetet normalt sett påbörjas en sprint innan den första utvecklingssprinten för att kunna leverera något till utvecklarteamet. Det som överlämnas vid detta stadie är skarpa designskisser, det vill säga inte bara wireframes eller en grund utan något som ser väldigt färdigt ut. Respondenten jämför hur arbetet gått till vid två av de senaste projekten, i det ena har designen gåtts igenom med kunden i sprinten innan och sedan lämnats över till utveckling, medan i det andra projektet påbörjades designen och utvecklingen i samma sprint. I det andra projektet placerades designdelarna i samma ärendehanteringsprogram som utvecklardelarna, men respondenten upplevde att delarna blev lite för stora.

”Men det är på grund av att vi är vana att jobba på ett sätt med den där fasen som ändå är agilt i sig självt och just när vi skulle lyfta in det i det här Kanbantänket så blev det lite för stora portioner, så att jag tror att man ska bryta ner det mer.”

– Respondent A

det i designarbetet kan vara svårt att lyckas med detta då denne gärna vill ha ett helhetsgrepp på konceptet.

”Allting hör ju som ihop, allting ska ju kännas som en sammanhållen produkt, det kanske är svårt att bryta ner och bara eh designa söken så, eller bara sidhuvudet eller bara, när man inte vet hur det stora *heh*.. eh asså den stora grejen ser ut, man måste som börja stort och sen.. ja.”

– Respondent A

Respondenten uttrycker även att det finns svårigheter när delarna av ett projekt hamnar i olika, långa faser, dvs. en testfas, en designfas och utvecklingsfas då risken finns att det blir lite väl stora leverabler mellan dessa och att det blir dyrt i slutändan då saker kan vara svåra att förändra. Respondenten uttrycker att den vill gå mot en mer sammanbunden arbetsmetod, där kanske en grundläggande prototyp byggs, eller utvecklas, som sedan kläs mer med design. I samma anda menar Respondent E som arbetar med UX att designarbetet sker en sprint innan utveckling, men att arbetet ändå sker iterativt. Till skillnad från Respondent A så uttrycker Respondent E att den design som lämnas över är en grund, eller ett utkast som sedan kan stämmas av med utvecklaren för att diskutera lösningar, respondenten menar att den första designen såklart inte är ”hugget i sten”.

Respondent B, en teamledare, menar på att det är lite olika hur designarbetet sker, oftast sätts en större grund designmässigt innan de går på med utveckling, men att de försöker arbeta mer mot att design och utveckling ska gå mer parallellt.

”/../ofta så sätter vi en större grund designmässigt innan vi går på med utveckling, sen försöker vi ju mycket mer nu än vad vi gjort tidigare att låta dom gå lite parallellt så att vi liksom tar fram en del, en designdel, och så utvecklar vi den i samma sprint, och så går man på med mer designdelar och så utvecklar man det.”

– Respondent B

typer av resurser inte kommit in tillräckligt tidigt och då blir det mer av en överlämning eller genomgång. När det är mindre projekt upplever respondenten att det finns större möjligheter att ha med alla kompetenser hela vägen, detta arbetssätt upplever respondenten som det bästa, men att det såklart också har sina utmaningar. I samma anda svarar Respondent F som arbetar med front-end och design att det blir väldigt olika hur de arbetar med designen, ibland sker det en sprint innan utvecklingen, och i andra sker det i samma sprint. I vissa fall vet de att en viss funktion ska finnas så att back-end utvecklare kan börja på funktionalitet i samma sprint, men det varierar. Respondenten tycker att omfattningen av projektet styr hur de arbetar och att det på så sätt fungerar bäst att arbeta på olika sätt.

”/../ i en del av projekten vi är i nu så kommer det fram behov och scenarion hela tiden som vi inte har vetat om så då är det ju bra att kunna designa under tidens gång, det kommer ju nytt hela tiden, så då ändras ju behoven och då ändras ju vad vi gör också.”

– Respondent F

Respondent C, utvecklare och formgivare, upplever inte att de arbetar med sprintar i sitt team, den programvara de sitter i tillåter att deras arbete sker lite mer ”pang på”, som respondenten uttrycker det. Respondenten berättar att när den suttit i andra team innan så har designarbetet ofta skett i sprinten innan, vilket sedan lämnas över till utveckling.

Till skillnad från de andra så tycker Respondent G, front-end utvecklare, snarare att de arbetar enligt en vattenfallsmetod, då de separata faserna blir så stora och att de gör så mycket arbete på en gång.

”/../ när vi får en hel.. mockup, för det är det (namn) oftast gör, det är att han, han gör ju en design på hela webben, och då är tanken att vi, vi ska bygga ihop layouten för hela designen från början så vi, och det skulle väl jag kunna klassa lite som en vattenfallsmetod, att man liksom gör allting på en gång.”

– Respondent G

5.2.2 Planering av designarbetet

”/../ när man jobbar med design och utveckling så ligger ju allting i Figma och det är ju nåbart för den som ska utveckla också att gå in där och kolla på hur saker och ting ser ut. Så att det är ju som dom två stora accesspunkterna för både utvecklare och designer och alla i teamet att Figma sen ser man i Jira då vad som ska göras. Däremot kan det ju vara lite lurigt eftersom Jira är ganska såhär utvecklings.. fokuserat, att du har ärenden, nu ska vi bygga en sök eh asså det kan ju vara, det är ju väldigt detaljerat där.”

– Respondent A

När utvecklingsdelen av projektet påbörjas läggs dock designärenden in i Jira, här lägger man då oftast beskrivningar och anteckningar samt länkar till den relevanta delen i Figma för att ge utvecklaren ett underlag eller en mall att jobba efter. Genom att både interna resurser samt kunden kan komma åt detta underlag ger det båda delarna en bra plattform att både beskriva olika designelement samt att ge återkoppling på det skapade materialet.

Företaget jobbar aktivt på att försöka få in designfasen i Jira, detta både för att ha möjligheten att koppla in fler kompetenser tidigare och för att på så vis även slippa att det blir två separata faser.

En framgångsfaktor som återkommer i många av de intervjuer vi har gjort är att blanda in fler kompetenser tidigt i projekt, främst att koppla in utvecklare redan i designprocessen. Detta anser de bör göras för att få tidig feedback samt för att slippa att göra om delar som visar sig inte gå att implementera. Dessa områden har dock underlättats med hjälp av de verktyg som företag använder för att involvera fler kompetenser samt kunden redan i designfasen, kunden får access till att gå in och se hur designen ser ut under hela processen och de kommer även åt de ärenden som skapas i projektet och kan där lämna kommentarer och synpunkter. Ett problemområde som en respondent har sett i detta arbete är att kunden i vissa fall kan få för stor frihet i vad de kan göra för ändringar i designen, hen ser hellre att kunden har möjlighet att bara redigera själva materialet som finns på hemsidan, det vill säga text och bilder, istället för att ge kunden full frihet att ändra om utformning av de komponenter som finns på sidan.

5.2.3 Projekt och agilitet

arbetet på samma gång, då de upplever att det fungerar som bäst då hela teamet arbetar tight och alla är medvetna om alla delar i projektet.

Alla de respondenter vi har varit i kontakt med i företaget anser att både deras egen arbetsprocess samt företagets arbetsprocess som helhet är agil och i de fall det är möjligt att jobba agilt strävar de att göra det i så hög grad som möjligt. I vissa fall behöver de dock anpassa hur agilt de arbetar beroende på hur deras kunder vill arbeta, detta leder till att arbetsprocessen skiljer sig åt beroende på hur bekväm kunden känner sig med det agila arbetssättet.

”/../ men sen blir det ju också, det är ju liksom från kund till kund där också, vissa kunder kanske vill hålla mer att ’nu vi vill ha en skiss på det här, och sen vill vi gå vidare med det’ medan vissa kanske är mer öppna för att liksom, ’ja men testa o ta fram det där så ser vi, amen de här blev inte bra, vi testar de där istället’, så att, det beror lite på vad man har att jobba med, men förhoppningen är ju det att man kan iterera det man har gjort /../ för oftast blir det bäst så.”

– Respondent F

Oavsett i hur hög utsträckning företaget arbetar agilt så försöker de att blanda in kunden så mycket som möjligt och går igenom varje iteration av projektet med dem.

5.2.4 Kommunikation och samarbete

Företaget lägger mycket fokus på att kommunicera mycket med varandra för att hålla alla inblandade i ett projekt uppdaterade. Ett flertal av respondenterna uttrycker att i de projekt där kommunikationen är klar och tydlig mellan kompetenserna så blir slutresultatet oftast bättre och man slipper göra om delar vilket kan ta mycket tid.

” Ja vi jobbar ju nära hela tiden, eh, och jag försöker ju alltid liksom, om jag drar till mig själv, sitter jag och designar nånting så försöker jag alltid ha med någon som sitter omkring mig som är delaktig liksom, ’vad tycker ni om det det här, vad tror ni om det här, blir det här bra, vad tror du om det här från ditt håll’ så att säga liksom, så att jag tror alltid vi försöker involvera någon som är med liksom och få deras åsikter, för även om jag tycker nånting så tror jag, ju fler som tycker ju bättre blir det ju i slutändan.”

– Respondent F

Kommunikationen mellan kompetenserna sker på många olika sätt, jobbar man exempelvis med någon i samma kontor blir det ofta så att man pratar med varandra direkt i person, jobbar man istället med en kompetens som sitter på annan ort sker kommunikationen vanligtvis via antingen videosamtal genom verktyg som Zoom4_{, Teams}5

eller Skype6_{, alternativt genom att chatta i gruppchatter där alla medlemmar i ett projekt}

4 _{https://zoom.us/}

finns inlagda. Utöver detta sker det även avstämningsmöten i varje projektgrupp, oftast en till tre gånger per vecka beroende på storleken av projektet och hur många som är inblandade. För att de olika teamen på företaget ska hållas uppdaterade kring vad de andra i företaget arbetar med så sker det även möten månadsvis där alla team deltar och ger de andra en inblick i vad de arbetar med. Många av respondenterna tycker att kommunikationen fungerar bra både inom kontoret samt när de arbetar med kompetenser på annan ort, det kan dock i vissa fall vara svårt att hålla koll på vad andra team i företaget arbetar med samt kan kommunikation med medlemmar i annan ort ibland visa sig vara något svårare att hantera än kommunikation på plats. Ett förbättringsförslag en respondent kom med är att på något sätt, möjligen i Jira, ge alla på företaget åtkomst till de olika projekten som företaget arbetar med för att ge alla en bättre helhetsbild över dessa projekt. För att detta ska fungera så bra som möjligt föreslår respondenten också att lite mer dokumentation kanske bör finnas tillgänglig i Jira.

Det är även viktigt för den person som tar emot en ny beställning från en kund att säkerställa att den information den tagit emot stämmer överens med det kunden vill ha samt att detta dokumenteras på ett sådant sätt så det är lätt att förstå för andra personer som ska arbeta med i det projektet.

5.2.5 Överlämning

Respondenterna i företaget uttrycker alla liknande tankar kring hur överlämning mellan de olika kompetenserna ter sig samt vilka framgångsfaktorer som finns för att överlämningen ska fungera så bra som möjligt.

Vid överlämning mellan designers och utvecklare skapas oftast ett ärende i Jira där viktiga kommentarer kring den tänkta designen samt en länk till designen i Figma finns tillgänglig. Av de respondenter vi intervjuat uttrycker både de som designar och de som utvecklar att överlämningen fungerar bäst om båda kompetenserna har varit med från ett tidigt skede, de uttrycker även att det är viktigt för designers och utvecklare att ha en tydlig kommunikation genom hela denna process.

” Eh, sen gäller det ju att eh försöka eh liksom överlämna designen till den som ska utveckla på ett sätt som gör det liksom eh… så att asså informationen går fram så att det blir det som vi vill åstadkomma och där gäller det ju både för en designer att kunna liksom förklara det på ett bra sätt, dels genom skisser att man liksom använder sig av rätt kontext, det är väldigt ofta det kan bli så att man använder någon kattunge på nån bild istället för riktiga liksom verkliga människor och bilder som det ska användas till eller Lorem Ipsum text liksom, att försöka hålla sig till riktigt content så det blir lätt för den som tar emot det att förstå vad det kan vara för verkliga exempel som det kan användas på.”

6. Diskussion och analys

I denna del analyseras resultatet med hjälp av den relaterade forskningen som presenterats tidigare. Här diskuteras även resultatet och en kortfattad genomgång kring hur en fortsatt studie skulle kunna se ut presenteras.

6.1 Analys

I helhet uttryckte de flesta respondenterna i vår studie att designarbetets del i projekten brukar variera. För det mesta görs alltid någon form av förarbete en sprint innan utvecklingen drar igång, men vad som skapas kan skifta. En respondent uttryckte att det som lämnas över efter förarbetet är en design som ser relativt färdig ut, detta faller i linje med vad Sharp, Preece och Rogers (2019) beskriver som big design up front vilket inte är optimalt i det agila då det skapar för stora arbetsblock och en överlämning som kräver mer dokumentation. Detta är enligt dem ett vanligt fenomen då designers gärna vill skapa sig en helhetsvision över projektet. En annan designer beskrev att det som lämnas över efter det första designarbetet snarare är wireframes och en bas på designen. Detta sätt att arbeta tillåter arbetet med designen att ske mer iterativt och ligger nära det Armitage (2004) beskriver som agil design. Denna metod möjliggör att designteamet och utvecklarteamet kan arbeta parallellt, men att designteamet ligger en sprint innan utvecklingen. Denna metod gör det även möjligt att fånga upp eventuella förändringar i specifikationer eller upptäckter kring användaren och ger designers en chans att implementera detta direkt. I denna process krävs det att användarundersökningar sker kontinuerligt i designarbetet. (Sy, 2007) För att kunna arbeta på detta sätt gäller det att bryta ner arbetsdelarna till mindre bitar, respondenter i intervjuerna uttrycker likt Sharp, Preece och Rogers (2019) att problematik kan uppstå om dessa är för stora. Däremot är det inte fel att vilja skapa sig en helhetsvision över projektet, men det är en fin balans mellan att skapa för mycket och bara precis så pass mycket design som krävs för att kunna gå vidare i projektet. (Armitage, 2004)

“To avoid unnecessary work on detailed design, UX design activities need to be conducted alongside and around agile iterations. The challenge is how to organize this so that a good user experience is achieved and the product vision is maintained.”

(Sharp, Preece, & Rogers, 2019) sida 478

Den föreslagna lösningen till detta är att designteamet och utvecklarteamet istället jobbar i parallella sprintar där designarbetet sker en sprint, eller iteration, innan utvecklingen. Genom att arbeta på detta sätt kan designarbetet bli klart precis innan utvecklingen av designen påbörjas och de två teamen kan på så sätt hela tiden arbeta nära intill varandra. Se figur 1 för ytterligare information kring den föreslagna lösningen. (Sy, 2007)

Flera av de respondenter som deltog i våra intervjuer beskriver att de projekt som har fungerat bäst är de projekt där flera, om inte alla, kompetenser blivit inblandade i ett tidigt stadie av projektet. Detta gör det lättare att tidigt i ett projekt få feedback vilket leder till att mindre ändringar behöver göras i senare delar av projektet. I studien "Collaboration

Constraints for Designers and Developers in an Agile Environment" skriven av Jones,

Thoma och Newell (2016) beskriver de hur både designers och utvecklare är överens om att båda kompetenserna bör kopplas in i ett tidigt stadie, detta överensstämmer med det resultat vi har fått från de intervjuer vi gjort.

Att företaget även blandar in kunden genom hela processen och låter kunden göra användartester och lämna feedback är ytterligare en faktor som tas upp i många av intervjuerna, detta är nära relaterat till de framgångsfaktorer som Chamberlain, Sharp och Maiden (2006) skriver om i sin artikel om integrationen av designers i det agila teamet:

”The designers and developers must be willing to communicate and work together extremely closely, on a day to day basis. Likewise the customer should also be an active member of the team not just a passive bystander.”

(Chamberlain, Sharp, & Maiden, 2006) sida 151

Utöver det så skriver de även att genom att blanda in användare tidigt för att få feedback så kan man säkerställa att de krav som användaren har på slutprodukten blir tillfredsställda.

Respondenterna i företaget berättar i intervjuerna att planeringen kan se lite olika ut både beroende på kunden samt beroende på vilken fas i projektet man befinner sig i. I de flesta fallen använder sig företaget av en design- och analysfas i början av projektet. I denna fas arbetar man nära kunden och det är via direktkontakt med kunden som den huvudsakliga planeringen sker. Diana Brown (2013) skriver i sin bok Agile User Experience

Design att baserat på fallstudier som hon gjort bör företag överväga att använda sig utav

Många av de som jobbar inom företaget, både som designers och utvecklare, uttrycker att de kopplas in i olika faser av projektet och att alla kompetenser generellt sett inte är med från början. Vanligtvis sker det i början av ett projekt en design- och analysfas innan utvecklare blandas in i projektet. Att ha en sådan tidig design- och analysfas är en av de grundprinciper som Chamberlain et al. skriver om i sin artikel:

"UCD practitioners must be given ample time in order to discover the basic needs of their users before any code gets released into the shared coding environment."

(Chamberlain, Sharp, & Maiden, 2006) sida 151

De trycker dock även på att alla som kommer att vara delaktig i ett projekt bör vara med under varje del av projektet, så att blanda in utvecklare redan i denna tidiga fas är någonting som de uppmanar till.

Företaget kommunicerar mycket inom projektteamen, man använder sig utav flera olika verktyg för att hålla alla inblandade uppdaterade kring vad som händer i ett projekt. Det är mycket vanligt att projektteam arbetar på olika orter vilket leder till att mycket av kommunikationen sker via diverse onlineplattformar som exempelvis Skype, Teams, eller Zoom. Är det så att man arbetar med kompetenser som finns på plats sker mycket av kommunikationen istället ansikte mot ansikte. I den relaterade forskningen som använts i denna studie ligger stort fokus på att kommunikationen inom ett projekt måste fungera så bra som möjligt, detta för att effektivisera arbetet i så hög utsträckning som möjligt. Detta är något som även återfinns i det inledande stycket i det agila manifestet;

“Individuals and interactions over processes and tools”

(Beck, o.a., 2001)

Det som antyds i detta påstående är att interaktionen och kommunikationen inom ett projekt är viktigare än de processer, metoder, och verktyg som används i projektet.

Företaget använder sig även utav avstämningsmöten där hela projektteamen medverkar, dessa avstämningsmöten sker vanligtvis mellan en och tre gånger per vecka beroende på projektet. I mycket av den relaterade forskningen, speciellt den forskning som förespråkar användningen av scrum, rekommenderas utövare att använda sig utav daily

standups för att varje dag både informera resten av teamet om vad man själv har gjort samt

Hon skriver dock även i boken att man inte ska hänga upp sig för mycket över att sådana möten alltid behöver inträffa om det visar sig vara opraktiskt för teamet. Skulle så vara fallet rekommenderas det att man istället använder sig utav teknologi för att hålla alla uppdaterade över vad som sker i projektet. (Brown, 2013)

6.2 Diskussion

När man börjar läsa om de agila metoderna så finns det en stor mängd artiklar och böcker som beskriver både arbetssättet samt de principer man bör följa för att lyckas i den agila världen. En av de mest återkommande faktorerna som listas är hur viktig kommunikationen är mellan medlemmarna i det agila teamet. Denna trend kan vi även återfinna i resultatet av vår intervjustudie, här beskriver många av respondenterna att kommunikation är en viktig faktor inom ett projekt. Respondenterna beskriver även i intervjustudien att när någonting går fel beror det med stor sannolikhet på att kommunikationen har brustit.

Många av respondenterna tycker sig arbeta agilt och att projekten följer ett agilt arbetssätt, något som vi kan se från resultatet är dock att även fast många av kompetenserna kanske arbetar agilt i sitt eget arbete så blir det ändå ofta en big design up

front. Detta leder till att det blir en överlämning mellan designteamet och utvecklarteamet

som liknar den överlämning som finns i vattenfallsprojekt, detta är någonting man vill undvika i agila projekt. Om detta är ett resultat av att designers arbetar i flera projekt samtidigt eller om det har någonting att göra med att man arbetar på olika orter är frågor som är svåra att besvara utan att göra en mer djupgående undersökning. Respondenterna i vår studie nämner även att det spelar in hur stora projekten är och hur bekväm kunden är med det agila arbetssättet. Att plocka in fler kompetenser från start kan bli kostsamt, men likaså kan det bli kostsamt om det i slutet av ett projekt blir större förändringar. En arbetsmetodik som skulle kunna avhjälpa att design och utveckling avskärmas och att en större överlämning blir oundviklig är att de två teamen arbetar i parallella sprinter på det sätt som Sy (2007) beskriver. Arbetar man på detta sätt krävs det fortfarande planering och design innan utveckling kan påbörjas, men denna fas kan kortas ner och de två teamen kan sedan arbeta närmare varandra under hela projektets gång. Detta arbetssätt låter likt det respondenterna beskriver att de försökt implementera, men att designdelarna måste ses över för att säkerställa att de är lagom stora för att kunna genomföras i en sprint istället för att kontinuerligt läggas över i nästa. En annan viktig punkt ligger i att definiera hur mycket som ska göras i den inledande sprinten, detta för att tillåta att designers hinner skapa sig en helhetsbild men samtidigt inte producerar för mycket färdigt material så att det leder till en big design up front situation.

samarbetet kan se ut och se om det finns några faktorer som skulle kunna göra att samarbetet kan fungera ännu bättre än vad det redan gör.

7. Slutsats

Det resultat som vi har fått ut från vår studie ligger väldigt nära det resultat som andra liknande studier har fått ut. När man ser till på tidigare forskning visas det klart att det finns flera faktorer som leder till att design och det agila arbetsättet kan integreras med varandra, det finns dessvärre inte någon gyllene regel som fungerar för varje team. Det är inte lätt att definiera en specifik arbetsmetod att följa när det gäller samarbetet mellan design- och utvecklarteam i agila projekt då företag arbetar på olika sätt och projekten kan se väldigt olika ut och kräva helt skilda saker. Grunden i det agila är helt enkelt att vara flexibel, vilket återspeglas på alla delar i projektet. Det som fungerar väl i ett team eller projekt, kanske fungerar mindre bra i ett annat. Det finns istället riktlinjer man kan följa och sedan försöka justera dessa fram tills att man har hittat den formel som fungerar för sitt team.

• Kommunikation – alla hålls uppdaterade och uppdaterar varandra genom projektets gång. Det är en fördel om alla kompetenser kan vara med vid uppstart av ett projekt eller så tidigt som möjligt.

• Starta upp designarbetet en sprint innan utvecklingen, dock bara för att hinna skapa en bas för designen. Detta för att få en helhetsbild samt för att ha tid att samla in information kring användarna.

• Planera för parallella sprintar där design arbetar en sprint innan utvecklarna för att alltid hinna göra research och användartesta.

Referenser

Armitage, J. (2004). Are agile methods good for design? Interactions, 14-23.

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas, D. (2001). Agile manifesto. Retrieved from

https://agilemanifesto.org/iso/sv/manifesto.html

Benyon, D. (2014). Designing Interactive Systems: A comprehensive guide to HCI, UX and interaction design. Harlow: Pearson Education Limited.

Brown, D. (2013). Agile User Experience Design: A Practitioner's Guide to Making It Work. Waltham, MA, USA: Elsevier Science.

Bryman, A. (2012). Social Research Methods (4:e ed.). New York: Oxford University Press Inc. Chamberlain, S., Sharp, H., & Maiden, N. (2006). Towards a Framework for Integrating Agile

Development and User-Centred Design. Extreme Programming and Agile Processes in Software Engineering (pp. 143-153). Berlin, Heidelberg: Springer Berlin Heidelberg. Green, M. D. (2016). Scrum: Novice to Ninja. USA: SitePoint.

Gustavsson, T. (2016). Agil Projektledning (3 ed.). Stockholm: Sanoma Utbildning AB. Jacobson, I., Lawson, H., Ng, P.-W., McMahon, E. P., & Goedicke, M. (2019). Software

Engineering Methods and Practices. In The Essentials of Modern Software Engineering: Free the Practices from the Method Prisons! (p. 37). Association for Computing Machinery and Morgan & Claypool.

Jensen, T., & Sandström, J. (2016). Fallstudier. Lund: Studentlitteratur AB.

Jones, A., Thoma, V., & Newell, G. (2016). Collaboration Constraints for Designers and Developers in an Agile Environment. Proceedings of the 30th International BCS Human Computer Interaction Conference: Fusion! (pp. 1-9). Poole, United Kingdom: BCS Learning & Development Ltd.

Persson, A. (2016). Frågor och svar: om frågekonstruktion i enkät- och intervjuundersökningar. Örebro: Statistiska Centralbyrån.

Salah, D., Paige, R., & Cairns, P. (2015). Patterns for Integrating Agile Development Processes and User Centred Design. Proceedings of the 20th European Conference on Pattern

Languages of Programs, 1-10.

Sharp, H., Preece, J., & Rogers, Y. (2019). Interaction Design: Beyond Human-Computer Interaction (5:e ed.). Indianapolis: Wiley.

Sy, D. (2007). Adapting Usability Investigations for Agile User-Centered Design. J. Usability Studies, 112–132.

Vetenskapsrådet. (2002). Forskningsetiska principer inom humanistisk-samhällsvetenskaplig forskning. Stockholm: Vetenskapsrådet.

Intervjuguide - Bilaga

Vad arbetar du med/huvudsakliga arbetsuppgifter? Vilka kompetenser arbetar du närmast?

- Hur ser samarbetet ut?

Arbetar design en sprint före, i samma sprint som resten av teamet eller på annat sätt? När i projektet kopplas du in?

- Anser du att det är en lämplig tidpunkt? Upplever du att du arbetar agilt i din process?

- På vilka sätt?

- Arbetar resten av företaget agilt? Följer alla projekt samma struktur? Använder ni er av Kanban?

- Hur arbetar ni med detta? (Hela teamet alt. Separata för design/utveckling?) Vilka mötesformer använder ni er mest av?

- Hur ofta har ni möten? - Vad tas upp på möten? - Vilka deltar?

Arbetar du genom hela projektet eller bara delar av? Hur många projekt arbetar du i samtidigt?

Ser arbetsprocessen likadan ut i alla projekt?

- Om ja: Beskriv ett typiskt projekt! Början/mitten/slut. - Om nej: finns det några aspekter som återkommer? Ser dina arbetsuppgifter likadana ut i varje projekt?

Upplever du att det sker en överlämning mellan design och utveckling? - Om inte: Hur sker arbetet för att slippa överlämning?

- Om överlämning: Hur går den till? Vad fungerar bra/mindre bra? Hur säkerställs det att designen fungerar/att det som designas sedan utvecklas? Har du en klar bild av slutprodukten redan i början av arbetet?