Institutionen för informatik
Examensarbete i Informatik
Kandidatuppsats i Informationslogistik
Från Minimal Viable Product till Most Lovable Product
Möjliga Boundary Objects mellan UX och Agil systemutveckling i SaaS-branschen i Sverige
Författare: Caroline Carlsson &
Daniel Larsson Handledare: Peter Adiels Termin: VT20
Kurskod: 2IL10E
Abstrakt
Praktiska erfarenheter från fallföretaget och tidigare forskning visar på utmaningar i att kombinera processerna för agil systemutveckling och användarbaserad designutveckling.
Användarbaserad designutveckling förespråkas av UX (User eXperience). Litteraturstudien visar på skillnader i syn på dokumentation, avsaknad av definierad process för gemensamma iterationer, problem med att bryta ner UX-arbete i små beståndsdelar samt hur rollen för UX kan eller ska arbeta tillsammans med utvecklingsteamet. Samarbete över funktionsgränser innebär ofta behov av informationsöverföring genom någon form av objekt eller artefakt.
Studiens syfte är att bidra till den befintliga forskningen gällande interaktion mellan agila utvecklingsteam och UX-designers genom att undersöka båda parters perspektiv på hur gemensamt använda artefakter fungerar, för att effektivisera kommunikation, samarbete och informationsöverföring de två funktionerna emellan. Empirin är insamlad genom semistrukturerade kvalitativa intervjuer med produktägare, utvecklare, development managers och UX-designers/UX-specialister. Resultatet av empiri och analys visar att ingen av de funktionsöverskridande artefakterna som studien identifierat, stödjer informationsöverföring för båda funktionerna enligt kriterierna i Boundary Object Theory.
Resultatet av den kontextualiserade jämförelsen i diskussionen visar att funktionernas metodologiska filosofi utgör ytterligare en möjlig barriär för effektivt samarbete funktionerna emellan.
Abstract
Practical experience from the case company and previous research shows challenges in combining the processes for agile system development and user-based design development.
User-based design development is advocated by UX (User eXperience). The literature study shows differences in their views on documentation, lack of a defined process for joint iterations, problems with breaking down UX work into small components and how the role for UX can or should work with the development team. Collaboration across functional boundaries often involves the need for information transfer through some form of object or artifact. The purpose of the study is to contribute to the existing research on the interaction between agile development teams and UX designers, by examining both parties' perspectives on how mutually used artifacts operates, to improve communication, collaboration and information transfer between the two functions. The empirical material was gathered through semi-structured qualitative interviews with product owners, developers, development managers and UX designers / UX specialists. The result of the empirical analysis show that none of the cross-functional artifacts identified in the study, that supports information transfer for both functions according to the criteria in Boundary Object Theory. The result of the contextualized comparison in the discussion shows that the methodological philosophy of the functions is another possible barrier to effective collaboration between the functions.
Förord
Ämnet för studien har växt fram iterativt under de tre år som vi har haft möjlighet att bedriva olika fallstudier på fallföretaget under utbildningen i informationslogistik. Vi har blivit allt mer intresserade för kommunikation över funktionsgränser och hur information ska hanteras för att alla inblandade parter ska kunna utföra sitt arbete på ett sätt som är både effektivt och hållbart. Även om vi i studien lyfter fram brister i interaktionen mellan agil systemutveckling och UX på fallföretaget, är det viktigt att påpeka att samtliga respondenter både trivs på fallföretaget, respekterar varandra och har en uppriktig önskan om att förbättra samarbetet på ett sådant sätt att alla inblandade gynnas.
Vi vill tacka det dryga 30-talet personer på fallföretaget som på olika sätt stöttat oss under resans gång och stått ut med ett oändligt antal frågor. Vi har haft förmånen att få träffa hjälpsamma människor från avdelningarna för drift, IT, ekonomi, utveckling, eftermarknad och affärsutveckling. Vi vill rikta ett särskilt tack till våra handledare på fallföretaget, som tyvärr inte kan nämnas vid namn här samt till Peter Adiels från LnU, för att ni alltid lyssnat och hjälpt oss under de tre år som har gått.
Daniel Larsson & Caroline Carlsson
Växjö 2020-05-25
Innehåll
1. Introduktion ________________________________________________ 5 1.1 Inledning 5
1.2 Tidigare forskning __________________________________________________ 6 1.2.1 Kravhantering & värde i agila organisationer __________________________ 6 1.2.2 Artefakter & Boundary Objects i agila organisationer ___________________ 7 1.2.3 Processer, barriärer & metodförslag för integration mellan agil & UX ______ 7 1.2.3.1 Processer ___________________________________________________ 7 1.2.3.2 Barriärer ___________________________________________________ 8 1.2.3.3 Metodförslag _______________________________________________ 9 1.2.4 Tema 4 Gemensamma processer, artefakter och metodförslag för agil & UX _ 9 1.2.5 Sammanfattning ________________________________________________ 10 1.3 Problemformulering ________________________________________________ 11 1.4 Syfte och frågeställning _____________________________________________ 12 1.5 Avgränsning ______________________________________________________ 12 1.6 Målgrupp 13
2. Teori _____________________________________________________ 13
2.1 Ett informationslogistiskt perspektiv ___________________________________ 13 2.2 Boundary Objects __________________________________________________ 14 2.3 Agila Manifestet och Agila Arbetsmetoder ______________________________ 16 2.4 User Centered Design & User eXperience _______________________________ 17 3. Metod ____________________________________________________ 19
3.1 Vetenskaplig ansats ________________________________________________ 19 3.2 Datainsamling _____________________________________________________ 19 3.2.1 Urval ________________________________________________________ 20 3.2.2 Genomförande _________________________________________________ 21 3.3 Analys 21
3.4 Tillförlitlighet _____________________________________________________ 22 3.5 Etiska överväganden ________________________________________________ 23 4. Resultat ___________________________________________________ 24
4.1 Empiri 24
4.1.1 Introduktion empiri _____________________________________________ 24 4.1.2 Empiri från intervjuer ___________________________________________ 25 4.2 Analys 33
5. Diskussion ________________________________________________ 34
5.1 Resultatdiskussion _________________________________________________ 34 5.2 Metodreflektion ___________________________________________________ 37 6. Avslutning ________________________________________________ 38
6.1 Slutsats 38
6.2 Förslag till fortsatt forskning _________________________________________ 39
Bilagor
Bilaga 1: Litteratursökning Bilaga 2: 12 Agila Principer Bilaga 3: Intervjufrågor
Bilaga 4: Sammanställning av empiri
5 (52)
1. Introduktion
I följande kapitel presenteras bakgrunden till studien och vad tidigare forskning säger om problemområdet. Avsnittet om tidigare forskning är uppdelat i ett par tematiserade punkter och avslutas med en sammanfattning av det aktuella forskningsläget. Vidare presenteras problemområdet med avgränsning, syfte och studiens frågeställning.
1.1 Inledning
Ingen har väl lyckats missa de enorma tekniska framsteg som gjort under bara de senaste 20 åren. Under dessa år har även en ny filosofi och metodik för systemutveckling blivit omåttligt populär runt om i världen. Det agila manifestet utvecklades 2001 i en skidort i Colorado (Agile Alliance, 2020a) och numera följer majoriteten av företag de riktlinjer som där fastställdes för systemutveckling. I och med att stora framsteg har gjorts inom området, har det även lett till att vi som människor har kommit närmare teknisk utrustning, vilket även har förändrat hur vi lever våra liv. Eftersom fler människor nu interagerar med tekniken är det inte heller konstigt att begrepp så som User eXperience (UX) fått större betydelse inom systemutveckling. Termen User Experience (UX) definieras i ISO-standarden 9241- 210:2010 som “A person´s perceptions and responses that result from the use or anticipated use of a product, system or service.” (Law & Lárusdóttir, 2015). Att arbeta med UX är att skapa förutsättningar för konkurrenskraftiga användarupplevelser i teknik, som är och kan bli naturliga inslag i vår vardag. Exempel på teknik som förenklat företeelser i vardagslivet för många är IOS, Spotify, Instagram, Alexa, Sonos, Swisch, AirBnB, listan kan göras hur lång som helst.
Eftersom det därför finns två aktörer som strävar efter samma mål i utvecklingsarbetet, ibland inom samma företag och ibland som samarbetspartners, har det oundvikliga ämnet om hur man kan effektivisera samarbete och kommunikation samt informations- och kunskapsöverföring lyfts allt oftare. Genom att ha utfört ett flertal fallstudier på fallföretaget, som är verksamt inom just branschen SaaS (Software as a Service), under våra år som studenter på programmet för informationslogistik Linnéuniversitetet, har vi fått ett ökat intresse för hur sådana informationslogistiska utmaningar ska kunna hanteras inom agila verksamheter.
Ett annat sätt att beskriva problemet är att det saknas en gemensam förståelse eller överenskommelse för vilka krav som finns, hur de är prioriterade samt hur de kommuniceras mellan enheterna som är inblandade i utvecklingsprocessen på ett eller annat sätt. Agil systemutveckling listar sina viktigaste krav i så kallade user stories och UX kan t ex presentera researchmaterial i form av kundarketyper enligt tekniken personas. Den här studien undersöker hur informationslogistik tillämpas, eller inte tillämpas, mellan agila utvecklingsteam och UX-avdelningen på fallföretaget.
6 (52)
1.2 Tidigare forskning
Det finns ganska gott om forskning på området de senaste 15 åren, vilket förmodligen kan vara ett resultat av ett ökat medvetande över att integrera användarna i mjuk- och hårdvaruutveckling. Stickel et al. (2016) beskriver att till och med icke-agila verksamheter anser att nuvarande förväntningar på upplevelse kräver en genomtänkt och användarbaserad UX. Eftersom integrationen är en relativt ny företeelse, fungerar den inte felfritt i organisationer och mellan deras funktioner. Dessutom saknas oftast en övergripande vision och arkitektur för helhetsperspektivet eller “UX-vision” (Singh, 2008). Det är förmodligen förklaringen till det växande antalet vetenskapliga studier inom flera ämnen. En stor andel artiklar använder termen UCD (User Centered Design) istället för UX, i och med att termen UX är något som främst växt fram det senaste decenniet. Litteratursökningen (bilaga 1) som gjorts inför den här studien resulterade i ett slutligt urval av 14 ämnesrelevanta vetenskapliga studier, vilka vi har valt att tematisera enligt fyra olika teman nedan.
1.2.1 Kravhantering & värde i agila organisationer
En viktig beståndsdel i den agila metodiken är hur man identifierar, hanterar och prioriterar krav på det som ska utvecklas. Något som i sin tur avspeglar vad en agil organisation anser är värdefullt att lägga ner utvecklingstid på, både när det kommer till vilken produkt som utvecklas, hur den utvecklas och för vem. I en studie utförd av Alahyari et al. (2016) studerade de hur agila verksamheter ser på värde. Studien visade att agila organisationer värderar tid högst, och kvalitet var endast prioriterat av organisationer inom telekom, bilindustrin, försvarsmakter och konsulter. Förutom de organisatoriska värderingarna undersökte de även hur prioritering och uppfattning av värde skiljde sig mellan olika yrkesroller inom organisationerna. Resultatet visar på att produktägare och produktchefer ansåg upplevd kvalitet som den mest värdefulla aspekten, medan funktionalitet ansågs vara en av de minst värdefulla aspekterna. Studien visar även på att de största hindren för agil systemutveckling är en oklar definition av vad som ska levereras, sena ändringar samt beroenden till andra utvecklingsteam.
Eftersom agil metodik förespråkar kontinuerliga delleveranser för att möjliggöra feedback från användare och kunder, vilket kan förändra kraven är det intressant hur man i praktiken värderar och tar till vara på feedback och hanterar olika intressenters krav i agil systemutveckling. Schön et al. (2017) redovisar i en litteraturundersökning att det inte finns någon gemensamt etablerad förståelse för användarperspektiv i agil systemutveckling, men att metodologierna Human-Centered Design, Design Thinking, Contextual Inquiry och Participatory Design i olika grad integreras för att öka kunskapen om användarbehov.
Vidare visar deras undersökning att det saknas en gemensam processmodell för hur man hanterar intressenter i den agila miljön, att det är problematiskt att dela kunskap mellan intressenter när det gäller användarkrav och vem som är ansvarig för användbarhet och upplevelse (Schön et al., 2017). Det är svårt att bestämma vilken sort av de vanligast
7 (52)
förekommande artefakterna, som ökar samarbetet mellan intressenter, utvecklare och det agila teamet, när agil systemutveckling hanterar dokumentation av kravhantering (Schön et al., 2017).
1.2.2 Artefakter & Boundary Objects i agila organisationer
När man använder sig av den agila metoden Scrum uppstår ett behov av verktyg för kommunikation och samarbete, för projektledning och hur backloggen hanteras eftersom fokus ligger på mänsklig interaktion och kommunikation före dokumentation. De vanligast förekommande artefakterna när agil systemutveckling hanterar dokumentation av kravhantering är User stories, prototyper, användarfall, scenarios och story cards (Schön et al., 2017). Bland de vanligast förekommande verktygen och artefakterna i Scrum, verkar det dock enligt Wagenaar et al. (2015), oftast saknas en artefakt för design samt något som syftar till att bevara kunskap över flera iterationer.
Den mest centrala artefakten i agil systemutveckling är backloggen, vilken enligt Sedano et al. (2019), både är en modell/lista över arbetsuppgifter att utföra och ett boundary object för att överbrygga gapet mellan skapandet av User-stories, samt att realisera dem till utvecklad funktionalitet. Backloggen kan ses som ett boundary object eftersom den är en artefakt som delas mellan flera roller och ibland även flera team och intressenter i organisationer, vilket även gör att den behöver hanteras på ett annat sätt än de artefakter som endast används i specifika team (Wohlrab et al., 2018). Den forskning vi har hittat som utreder hur boundary objects hanteras i organisationer där agil systemutveckling tillämpas, är studier inom bilindustrin samt mer generella studier om boundary objects. De senare redovisas mer under teoriavsnittet om Boundary object Theory.
1.2.3 Processer, barriärer & metodförslag för integration mellan agil & UX
Eftersom vi hittade flest studier på det här temat har vi valt att dela in avsnittet i underkategorierna processer, barriärer och metodförslag för att göra det mer överskådligt.
1.2.3.1 Processer
Singh (2008) beskriver att agila mjukvaruprocesser generellt sett inte har något i sina regelverk som beskriver när UX-relaterat arbete ska utföras, eller hur rollen för UX kan eller ska arbeta tillsammans med utvecklingsteamet. Det styrks även i en masteruppsats av Dahl (2012), samt i resultatet av Salah et al. (2014) litteraturstudie. Det finns enligt Stickel et al.
(2016), sannolikt inget perfect-fit när det gäller arbetsformer som främjar samarbete mellan agila och icke agila funktioner i en verksamhet. Det är enligt Stickel et al. (2016) en kontextspecifik process som kräver tid, intelligenta och empatiska människor samt ständig
8 (52)
självutvärdering. Det agila ramverket Scrum kritiseras särskilt för sin bristande förmåga att integrera UX i sin process (Singh, 2008).
1.2.3.2 Barriärer
Även om många större företag föredrar Scrum, så ökar antalet och komplexiteten av företagets regler, vilka enligt Law och Lárusdóttir (2015) kan vara inkompatibla med regelverket i Scrum. Därav är antagligen differentiering mellan roller oundviklig, företagskulturen mycket viktig och lagom mycket empowerment för att våga uttrycka sig fritt, men ändå stå bakom den övergripande produktvisionen enligt Stickel et al. (2016).
Bordin och De Angeli (2016) uttrycker det som ett kontextuellt beroende, där behovet av dokumentation och roller som koordinerar och faciliterar överföring av tyst kunskap sannolikt ökar ju fler team och användare som är inblandade.
Begränsad involvering av användare i början av utveckling, kan enligt Law och Lárusdóttir (2015) leda till dålig kravinsamling. Stickel et al. (2016) beskriver en annan sida av samma barriär som att antalet användare och differentiering mellan olika kanaler och verktyg kan öka med företagets tillväxt, vilket gör det svårt att vara i kontakt med "rätt" användare på ett strukturerat sätt och motverka bias. Det kan dessutom enligt Bordin och De Angeli (2016) vara svårt att definiera användare och deras behov, utan att ha fysiska representanter, vars relevans på grund av bias minskar ju längre de är med i projektet.
När det kommer till begränsningar i själva inhämtandet av användarfeedback nämner Stickel et al. (2016) avsaknaden av en genomtänkt strategi för vilka verktyg/media som används för att samla in feedback från användare. Law och Lárusdóttir (2015) beskriver det som ad-hoc insamling av feedback, där informell utvärdering med ett fåtal kunder/användare är vanligast. Bordin och De Angeli (2016) anger dessutom att mängden användarfeedback kan eskalera och därmed påverka utvecklingsprocessen. Något som även anknyter till den barriär som Salah et al. (2014) beskriver i sin litteraturstudie som avsaknad av dokumentation, i form av t ex wikis, webbsidor, användarfall, scenarios, personas, sketcher, wireframes, prototyper, designmönster och användarstöd.
UX-resurser verkar ofta vara begränsade i agil systemutveckling, vilket beskrivs Law och Lárusdóttir (2015). Dessutom visar flera studier på att det är svårt att bryta ner UX-arbete i små beståndsdelar, hur man prioriterar UX-aktiviteter, samt att det saknas tid för UX- aktiviteter som sker på förhand, dvs innan första iterationen, vilket bekräftas i litteraturstudien av Salah et al. (2014). Här nämns även den agila systemutvecklingens funktionsfokus av Bordin och De Angeli (2016), som ett fokus som kan vara för snävt för UX tidiga stadier.
9 (52) 1.2.3.3 Metodförslag
När det kommer till metodförslag föreslår Bordin och De Angeli (2016) att man integrerar UCD och agil utveckling efter designkoncept är färdigt, dvs efter iteration 0, annars riskerar UX att hamna efter utvecklingsprocessen och påverka iterationerna för sent vilket kan skapa flaskhalsar. Ett annat metodförslag nämns av Dahl (2012) och kallas “parallel track”. I modellen skapas design och specifikationer oftast en eller flera sprintar i förväg, men för ett effektivt användande av “parallel track” modellen krävs enligt Dahl (2012) ett mindre resurskrävande och lättviktigt UX-arbete.
Ett mer rollbetonat förhållningssätt lyfts av Singh (2008) och Stickel et al. (2016), där de förespråkar att man har flera produktägare som delar på ansvaret. Singh (2008) föreslår en separat produktägare för UI/UX-perspektivet i Scrum, eftersom den vanliga produktägaren väldigt sällan har kompetens eller tid att arbeta med de frågorna i fokus. Stickel et al. (2016) förespråkar fler produktägare, t ex en senior UX som produktägare på deltid. Stickel et al.
(2016) kallar till och med produktägaren för den viktigaste länken i kedjan, det som kan göra att det fungerar eller inte, p g a krav och stress.
1.2.4 Tema 4 Gemensamma processer, artefakter och metodförslag för agil & UX
Det sista temat i litteraturstudien representeras av det vi hittat i tidigare studier, som på ett eller annat sätt kombinerar de föregående teman som redovisats.
Singh (2008) förespråkar att agil utveckling använder sig av UX-artefakten personas, eller en form av lättvikt-personas för att främja integrationen. Det gör även Lopes et al. (2018) vilka i sin fallstudie låter 18 utvecklare testa genom att låta utvecklarna välja fritt bland UX- artefakter när de ska skriva User Stories. Studien av Lopes et al. (2018) visar att UX- artefakterna Personas och Scenarios är de som används flest gånger i kombination med User Stories, att utvecklarnas förståelse för UX-frågor ökade, samt att kravbeskrivningen blev tydligare. Ingen av dessa studier innehåller dock respondenter från UX, något som Blomkvist et al. (2015) lyfter i sin undersökning av vilka boundary objects som finns i kommunikationen mellan UX och utvecklingsteam, samt effektiviteten i dem.
Undersökningen av Blomkvist et al. (2015) visade att User Stories är det enda objektet som är värt insatsen i och med att det var den enda artefakten som båda sidorna kunde se nyttan med. Däremot påpekar Blomkvist et al. (2015) att krocken mellan agil metod och icke-agil metod, vilket integrationen innebär, kan innebära andra integrationsproblem.
Att använda sig av gemensamma artefakter för att skapa en gemensam förståelse för användare och designvision är något som även lyfts i litteraturstudien av Salah et al. (2014).
Singh (2008) menar att UX-visionen dessutom kontinuerligt behöver presenteras för utvecklarna för att de ska förstå helheten, samt att det kan vara svårt att skapa gemensam förståelse för användare med hjälp av gemensamma artefakter i en organisation med flera
10 (52)
komplicerade produkter. Dessutom kan det då enligt Singh (2008) finnas flera UX- specialister och behovet av en övergripande UX-vision och en tillhörande arkitektur blir oundvikligt, något som oftast går på tvärs mot vad en agil organisation vill skapa.
Utöver att använda sig av gemensamma artefakter lyfter Salah et al. (2014) i sin litteraturstudie identifierade fördelar med gemensamma processer och ritualer som främjar den dagliga kommunikationen, som t ex att UX deltar i daily Scrums eller gemensamma workshops.
Det mest rigorösa metodförslaget presenteras av Kuusinen (2016), vilken menar att UX borde vara i teamet för att ha full kompetens och undvika beroenden, eftersom det blir det problem med timing och implementering när UX är ett separat team. Kuusinens (2016) förslag innefattar rekommendationer som att sprida UX-arbete över fler medlemmar i teamet för att undvika flaskhalsar, att arbeta i en iteration i taget för att hela teamet ska fokusera på en sak gemensamt, samt att acceptera både teknisk- och designskuld, för att leverera testbar funktionell design och funktioner. Slutligen anser Kuusinen (2016) att UX- relaterade uppgifter ska planeras och kommuniceras via samma verktyg som övriga uppgifter via t ex backlog-verktyg, samt att samma kriterier för tid/storlek ska gälla för dem.
Studien av Kuusinen (2016) fokuserar på aktiviteter och processer och har därför inte närmare utrett implementation av specifika artefakter i metodförslaget.
1.2.5 Sammanfattning
De 14 vetenskapliga publikationer som ingår i litteraturstudien och beskrivits ovan visar generellt att:
● Båda metodologierna värderar feedback från användare högt, men den agila metodikens förhållningssätt till dokumentation och fokus på att utveckla funktionalitet i korta iterationer, kan i praktiken innebära att det inte finns tid att ta till vara på feedback från användare på ett strukturerat sätt. Eftersom UX-arbete inte utvecklas i sin helhet i de agila iterationerna, är det inte heller säkert att feedbacken blir relevant.
● Det finns ingen uttalad och etablerad gemensam artefakt för att hantera information- och kunskapsdelning i interaktionen mellan de båda metodologierna agil och UX.
● Det saknas etablerade processbeskrivningar för interaktionen mellan de båda parterna, särskilt när det gäller samarbete mellan UX och den agila metoden Scrum.
● De båda metodologierna har olika syn på dokumentation. Agil systemutveckling förespråkar så lite dokumentation som möjligt, särskilt i de inledande faserna av utveckling, men UX bygger helst sitt arbete på ett gediget och väldokumenterat förarbete.
11 (52)
Flera studier förespråkar att man inkluderar UX-kompetensen i de agila teamen, eller strävar efter att använda centrala artefakter som user stories, backlog och personas i gemensamma processer, samt ökar samröret mellan rollerna i de agila ritualer som tillämpas i organisationen.
1.3 Problemformulering
För att en organisation ska utveckla rätt produkter på ett effektivt sätt, som svarar mot ett eller flera behov, så behöver dessa behov, vilka som har behovet och hur dessa behov ska lösas specificeras. Både agil systemutveckling och UX arbetar likt annan produktutveckling med att identifiera, hantera och prioritera krav. Det är dessa krav som på ett eller annat sätt dokumenteras och kommuniceras i respektive metodologis artefakter.
Eftersom agil metodik bygger på att all central kompetens som behövs för att utföra arbetet ska finnas i utvecklingsteamet, behövs det arbetsstöd för kommunikation och informationsutbyte med de funktioner som har den kompetensen, om den inte finns i utvecklingsteamet. Dessa arbetsstöd innefattar processer och artefakter som används gemensamt av båda parterna i interaktionen, i det här fallet mellan UX och agil systemutveckling. Resultatet av litteraturstudien visar att det finns begränsad forskning om det finns gemensamt använda artefakter som stödjer kommunikation, informationsöverföring i interaktionen mellan utvecklingsteam och UX-designers.
Dessutom saknas det forskning som:
● Undersöker gemensamt använda artefakter ur båda parters perspektiv.
● Gjort fallstudier i en svensk icke-industriell kontext, som t ex branschen SaaS (Software as a Service).
● Undersökt samlokaliserade teams samarbete över funktionsgränser.
Eftersom UX-avdelningens arbetsuppgifter på fallföretaget utgör en central del av de produkter som utvecklas enligt agil metodik på utvecklingsavdelningen, är behovet av en fungerande interaktion efterfrågad av fallföretaget. En interaktion som i dagsläget inte är standardiserad när det kommer till de processer, arbetsstöd och olika verktyg eller artefakter för informationsöverföring, vilka används eller inte används av parterna. Vi har därför valt undersöka vilka artefakter som finns och används av parterna på fallföretaget, vilka som används gemensamt, samt hur de upplevs stödja interaktionen mellan parterna. Eftersom artefakter som används för informationsdelning av flera parter kan ses som en form av gränsobjekt, har vi valt att använda oss av Boundary Object Theory för att analysera de gemensamt använda och funktionsöverskridande artefakterna.
12 (52)
Studiens kunskapsbidrag är att undersöka interaktionen mellan agil systemutveckling och UX i en svensk kontext, på ett fallföretag som är verksamt i branschen SaaS (Software as a Service). Studien undersöker båda parters perspektiv hur de gemensamt använda artefakter i interaktionen mellan agil systemutveckling och UX, som i form av Boundary Objects stödjer interaktionen mellan parterna när inte UX-kompetensen finns i det agila systemutvecklingsteamet.
1.4 Syfte och frågeställning
Studiens syfte är att bidra till den befintliga forskningen gällande interaktion mellan agila utvecklingsteam och UX-designers genom att undersöka båda parters perspektiv på hur gemensamt använda artefakter fungerar, för att effektivisera kommunikation, samarbete och informationsöverföring de två funktionerna emellan. För att bidra till forskningen förankrat till studiens syfte har vi utformat följande forskningsfråga:
• Hur fungerar funktionsöverskridande artefakter som gränsobjekt för informationsöverföring mellan UX och agila utvecklingsteam i SaaS-branschen i Sverige?
1.5 Avgränsning
Studien har utförts på ett fallföretag under den begränsade perioden 2020-02-03 till och med 2020-05-25. Fallföretaget är ett medelstort svenskt företag verksamt inom branschen SaaS (Software as a Service). Empirin är insamlad med hjälp av 11 semistrukturerade kvalitativa djupintervjuer, vilka utförts på plats i alla fall utom två. De sista två intervjuerna kunde på grund av Corona-pandemin inte utföras på plats, utan utfördes via länk i Google meets.
Samtliga intervjuer har spelats in och de sista två även med bild.
Endast artefakter som tas upp explicit eller implicit i intervjuerna är föremål för analys enligt teorin Boundary Object theory. De metodologiska ramverken för agil systemutveckling och UX används för att kontextualisera empirin.
Studiens omfattning är inom ramen för ett arbete inom informatik på kandidatnivå, vilket är en anledning till att andra teorier för analys och metoder för insamling av empiri än de som använts har valts bort. Valet av teori och metod för studien är i första hand baserat på den kunskap som studien ämnar bidra med. Vi har även valt att gruppera respondenternas svar efter deras respektive roll på grund av anonymisering, något som har gjort beskrivning av enskilda intervjusvar något begränsad i sin utförlighet.
13 (52)
1.6 Målgrupp
Målgruppen för studien är fallföretaget och andra företag som använder agil systemutveckling tillsammans med UX-kompetens utanför utvecklingsteam, såväl som forskare inom området som kan använda resultatet för mer djupdykande forskning om artefakter, processer och metoder som stöder informationsdelning i interaktionen mellan UX och agil systemutveckling.
2. Teori
Här presenteras det bakomliggande informationslogistiska perspektivet i studien, den teori som ligger till grund för analysavsnittet, samt huvuddragen i de båda metodologier som utgör grunderna för agil systemutveckling och UX.
2.1 Ett informationslogistiskt perspektiv
En utgångspunkt för studien har varit ett perspektiv på informationsöverföring som utbildningen i informationslogistik har bidragit med. Det perspektivet kan bäst beskrivas enligt en definition av informationslogistik som vi konsekvent har använt oss av under hela utbildningen i informationslogistik:
Pieter Klaas Jagersma (2011) beskriver i sin artikel Competetive Information Logistics informationslogistik som ett värdeskapande verktyg. Jagersma trycker särskilt på att information måste delas för att den ska få ett värde i en organisation. Enligt Jagersma (2011) strävar informationslogistik efter att optimera det totala värdet och den totala kostnaden för alstring, överföring, behandling, lagring och kontrollering av informationen i en organisations värdekedja. Jagersma trycker särskilt på att det inte finns något universalrecept för informationslogistik som fungerar överallt och alltid. Däremot finns det sannolikt en för varje organisation, men inte heller den är statisk säger Jagersma (2011) eftersom organisationen interagerar med en omgivning som ständigt förändras och på så sätt organisationen med den.
(Larsson, 2018) Med ovanstående definition i åtanke har det varit vår ambition att undersöka hur interaktionen mellan fallföretagets agila systemutveckling på utvecklingsavdelningen och UX-avdelningen, sker med hjälp av de olika artefakter som identifierats i de gemensamma processer och metoder som uttryckts i studiens intervjuer. I och med att dessa gemensamma artefakter används för att dela information och i bästa fall kunskap, är de enligt oss i allra
14 (52)
högsta grad av informationslogistiskt intresse. För att försöka förstå hur väl dessa artefakter fungerar för informationsöverföring mellan funktioner, har vi valt att använda oss av teorin Boundary Object Theory som analysverktyg.
2.2 Boundary Objects
Boundary objects representerar ett objekt som används som medel för kommunikation mellan olika sociala världar, vilka har ett gemensamt mål och aktivt agerar för att uppfylla detta mål (Star & Griesemer, 1989). Det objekt som agerar som boundary object mellan dessa olika funktioner blir på så sätt plattformen för samarbetet, vilket också är avsett att hantera de svårigheter som tvärfunktionella samarbeten medför. Beroende på behovet av vilken sorts kunskap som behöver förmedlas mellan funktionerna som sätts av den specifika uppgiftens kontext, behövs olika former av boundary objects för att hantera kommunikation vid olika situationer (Star & Griesemer 1989).
Carlile (2002) applicerade det teoretiska ramverket inom kontexten för produktutveckling, där han inte enbart fokuserade på olika former av boundary objects, utan även vilken typ av kunskap som varje form av boundary object är menad att hantera. Genom att inkludera olika kunskapsgränser kunde han ta fram riktlinjer för hur effektiva boundary objects är uppbyggda. Nedan presenteras en sammanfattande figur över sambanden mellan kunskap, boundary object och kunskap ur perspektivet effektiva boundary objects.
Figur 1: Type of Knowledge Boundary, Category, and Characteristics of Boundary Objects (Carlile, 2002)
15 (52)
För att ett boundary object ska fungera effektivt i den kontext där det används måste formen av boundary object vara lämpad för den typ av kunskapsgräns som situationen står inför.
Den grundläggande kunskapsgränsen är den syntaktiska kunskapsgränsen (Carlile, 2002) vilken representerar behovet av en gemensamt specificerad syntax, för att samtliga aktörer ska kunna förstå varandra och samarbeta på ett effektivt sätt. Vid den här typen av kunskapsgräns är boundary objects av formen Repositories mest lämpad. Repositories representerar sådana objekt som besitter samlad data, vilket är menat att fungera som en gemensam referenspunkt för samtliga inblandade funktioner och aktörer (Carlile, 2002).
Exempel på sådana boundary objects kan vara databaser, vilka definierar värden som samtliga aktörer sedan arbetar utefter. Eftersom samtliga sociala världar är under ständig utveckling och förändring behöver syntaxen emellanåt kompletteras med de nyheter som framkommit. Dessa nyheter gör att det istället framkommer en semantisk kunskapsgräns (Carlile, 2002).
Vid den semantiska kunskapsgränsen behövs standardiserade processer och metoder som verktyg, för att samtliga aktörer ska kunna översätta tilläggen i syntaxen. Vid den här typen av kunskapsgräns är boundary objects av formen standardized forms and methods mest lämpad. Standardized forms and methods representerar objekt som syftar till att skapa ett gemensamt format för problemlösning för samtliga involverade funktioner och aktörer (Carlile 2002). Genom att anamma samma metod för problemlösning kan samtliga aktörer arbeta med problem ur samma perspektiv och på så sätt ska inte överlämningar mellan funktioner bli lika problematiska. När kunskapen däremot är inbäddad i praktisk handling framkommer ännu en kunskapsgräns, den pragmatiska kunskapsgränsen (Carlile, 2002).
“This pragmatic view of knowledge and boundaries has been helpful in explaining why knowledge is both a barrier to and a source of innovation in a product development setting.”
(Carlile, 2002 s. 454).
Vid den pragmatiska kunskapsgränsen behövs inte bara processer för att bearbeta kunskapen, utan även processer för att aktörerna ska kunna transformera kunskapen som delas. (Carlile, 2002) Vid den här typen av kunskapsgräns är boundary objects av formen objects or models och maps of boundaries mest lämpade. Objects or models representerar boundary objects som används mellan funktioner för att visuellt kommunicera möjliga framtida formationer av produkten (Carlile, 2002). Den här kategorin innefattar sketcher, mockups och simuleringar, vilka används för att skapa en gemensam vy av det möjliga resultatet. Maps of boundaries representerar istället objekt som kan demonstrera gränser mellan funktionerna på en mer systemisk nivå (Carlile, 2002). Boundary objects som innefattas i den här kategorin är exempelvis Gantt-scheman och processkartor, vilka syftar till att identifiera beroenden mellan funktioner och aktörer inom en process eller ett projekt.
16 (52)
2.3 Agila Manifestet och Agila Arbetsmetoder
Det agila manifestet uppkom 2001 som reaktion på det sekventiella förhållningssätt som tidigare dominerat inom systemutveckling. Manifestet innehåller 12 principer (bilaga 2) vilka ligger till grund för vad det innebär att arbeta agilt. De agila grundvärderingarna kan sammanfattas i följande punkter.
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
(Agile Alliance, 2020c)
Idén är att bygga på inkrementell och iterativ utveckling istället för seriell utveckling.
Genom att fokusera på fungerande funktionalitet och sedan bygga på denna grundfunktionalitet kontinuerligt, kan agila verksamheter anpassa sig efter förändrade krav och på så sätt kunna försäkra sig om att det som utvecklas är det som faktiskt efterfrågas.
Genom den agila metodologin har olika roller, artefakter och ceremonier formats, vilka i sin tur även formar hur man arbetar agilt. Gustavsson (2016) beskriver de centrala rollerna som Produktägare, Utvecklare och Testare. Produktägaren leder teamet och ansvarar för att samla in, dokumentera och prioritera krav. Utvecklaren realiserar sedan kravet i kodform och överlämnar det till Testaren vars uppgift är att säkerställa att koden fungerar i sin enhet, men även som en del i systemets helhet.
För dokumentation och kommunikation av krav används ett flertal artefakter inom agil systemutveckling. Den grundläggande artefakten för agila utvecklingsteam är Backloggen.
Backloggen är en prioriterad lista av de krav som utvecklingsteamet ska realisera (Sedano et al., 2019). För att dokumentera dessa krav används ofta tekniken User Stories vilken är avsedd att definiera vad som ska göras, varför det ska göras, samt för vem det ska göras (Sedano et al., 2019). När kraven är redo för utveckling förs dessa in i utvecklingsteamets Board vilket är ett verktyg som används för att visualisera arbetsflödet (Schön et al., 2017).
Den vanligast förekommande agila arbetsmetoden är Scrum, även om den ofta på senare tid kombineras med den Lean-baserade metoden Kanban. I Kanban arbetar man inkrementellt med mer kontinuerlig utveckling utan utsatta tidsramar, medan man i Scrum arbetar både inkrementellt och iterativt (Gustavsson, 2016). I Scrum används korta iterationer, vilka kallas för sprintar, där arbetet inom dessa iterationer planeras, definieras och målsätts i
17 (52)
förväg. Scrum förespråkar även att all kompetens finns tillgänglig i utvecklingsteamet för att undvika beroenden som kan skapa hinder för utvecklingsprocessen. (Gustavsson, 2016) Förutom artefakter använder Scrum även vissa ceremonier, utöver tidigare presenterade artefakter, vilka används för att stärka utvecklingsprocessen. Den mest frekvent använda av dessa är Daily Scrum vilken hålls dagligen. Vid ceremonin går utvecklingsteamet igenom vad som gjordes dagen innan, vad som ska göras idag, samt vilka hinder som finns för att möjliggöra detta. Inför varje Sprint hålls även Backlog Refinement, vilket är en ceremoni där utvecklingsteamet går igenom och diskuterar krav inför kommande sprint för att de ska vara redo för utveckling så fort sprinten drar igång. Efter en sprint hålls Retrospective, där utvecklingsteamet diskuterar föregående sprint och vilka lärdomar sprinten genererat. Syftet med den ceremonin är att sedan kunna anpassa arbetet för att möjliggöra ökad effektivitet i teamet (Gustavsson, 2016). Efter en sprint hålls även en Demo, där utvecklingsteamet visar upp resultatet av sprinten i syfte att få feedback från berörda intressenter. Genom att kombinera dessa ceremonier med Kanban har en ny agil metod utformats på senare tid, vilken kallas Scrumban.
2.4 User Centered Design & User eXperience
Vi lever i en tid där datoriserade system är en del av nästan allting vi tar oss för i vår vardag.
Dessa system behöver därför vara utformade så att de är enkla och effektiva och gärna angenäma att använda. Ett sätt att förklara vad UX är för något är beskrivet av Nielsen Norman Group:
User experience’ encompasses all aspects of the end-user's interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features. In order to achieve high-quality user experience in a company's offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.
(Norman & Nielsen, 2020)
Majoriteten av forskning kring UX och dess interaktion med agil systemutveckling gjord innan 2018, använder ofta termen User-Centered Design (UCD) istället för UX, eftersom termen UX först på senare tid börjat användas mer frekvent. UCD beskrivs av Bordin och De Angeli (2016) som en paraplyterm för en uppsättning tekniker, metoder, förfaringssätt och processer vilka sätter användaren i centrum för en iterativ designprocess.
18 (52)
De viktigaste beståndsdelarna i UCD, vilka även gäller för UX är enligt Law och Lárusdóttir (2015) att man:
● Kontextualisera vilka mål, behov och uppgifter som användarna har: att man tar reda på vilka behov som finns, hur systemet kan möta behovet, samt vilka specifika uppgifter användaren ska kunna utföra i systemet för att uppnå målet.
● Användarengegemang: att involvera representativa användare genom hela systemutvecklingens livscykel.
● Holistisk design: en övergripande vision för systemets nyckelfunktioner under utveckling, särskilt ömsesidiga beroenden mellan dess komponenter samt relationer mellan dessa komponenter och andra kontextuella faktorer.
● Användarupplevelse i sin helhet: Design av ett system bör vid sidan om psykologiska faktorer även beakta sociala, organisatoriska och ekonomiska faktorer som är med och skapar användarens upplevelse.
De steg som ingår i processen för UCD kan beskrivas som sex olika faser:
• Specify the use context and user´s needs.
• Specify business requirements.
• Build design solutions from rough to finished design.
• Evaluate designs with usability testing.
• Implementation - develop and deliver the product.
• Deployment - the final product is evaluated, as consumer needs change.
(Gladkiy, 2020)
Ett par exempel på vanligt förekommande tekniker och artefakter som används i UCD och UX är användartest, användarintervjuer, personas och mockups. Användartest och användarintervjuer används för att ta reda på vad riktiga användare tycker om specifika funktioner i ett system, eller vad de tycker saknas eller har behov av. Behovet kanske inte alltid uttrycks explicit, vilket gör att det är vanligt med kvalitativa djupintervjuer och ibland även avancerade analyser av var användare tittar på en webbsida, genom att spela in ögats rörelser. Tekniken personas är en form av en fiktivt skapad användare, vilken baseras på större mängder insamlade användardata, som sedan kategoriseras till olika former av användararketyper (Cadle et al., 2014). Mockups är en form av webbaserad prototyp, som används för att designa webbaserat material iterativt, visuellt och gärna klickbart.
19 (52)
3. Metod
Följande kapitel redovisar studiens vetenskapliga förhållningssätt, metoder för datainsamling och analys, samt etiska överväganden.
3.1 Vetenskaplig ansats
Studiens syfte är att utifrån det vi vet om verkligheten undersöka det som inte är tillräckligt undersökt eller konkretiserat i befintlig forskning. Därav är studien såväl deduktiv som explorativ. Deduktion innebär att författarna förankrar sin forskning i teorin istället för att först samla in empiri som sedan ställs mot teorin efter empiriinsamlingen (Jacobsen, 2002).
Eftersom studiens syfte bygger på befintlig forskning är inte meningen att utmana den forskningen utan att komplettera det som redan gjorts. Därför har en deduktiv ansats valts för studien.
Creswell och Creswell (2018) beskriver tre former av upplägg för utförande av empiriinsamling, kvalitativ- och kvantitativ- och mixed methods metod. Kvalitativ forskning är menad att gå på djupet och verkligen förstå ett fenomen medan kvantitativ metod främst fokuserar på att få en så bred bild av fenomenet som möjligt för att möjliggöra en högre generaliseringsgrad. Mixed methods är en metod där man använder båda principerna från kvalitativ- och kvantitativ metod för att kunna dra ytterligare slutsatser genom metodtriangulering. Vi har valt att utföra en kvalitativ studie för att få med fler nyanser och på så sätt möjliggöra ett mer förklarande resultat än det mer beskrivande resultat som en kvantitativ studie är menad att resultera i.
3.2 Datainsamling
Processen för undersökning av det aktuella forskningsläget finns redovisat i bilaga 1.
Samtliga vetenskapliga publikationer som används i studien har granskats utifrån samma grundkriterier, förutom eventuella webbaserade källor som hittats via referenser i någon av de vetenskapliga publikationerna samt den litteratur utgiven i bokform som använts.
För att kunna uppfylla syftet med valet av en kvalitativ studie valde vi att utföra semistrukturerade intervjuer där frågor utformades iterativt med fokus på frågor om artefakter, överlämningar, processer och upplevelse av interaktionen. Jacobsen (2002) beskriver förstrukturering av intervjuer som nödvändigt även vid kvalitativ metod för att undvika för komplex data. Blir datan för komplex kan den bli för resurskrävande att analysera. Därav använde vi oss av förbestämda punkter som behandlades under intervjuerna för att säkerställa att intervjun går i linje med studiens syfte. Trots en viss grad av strukturering hölls frågorna inom fokusområdena öppna för att möjliggöra öppna svar från respondenterna.
20 (52)
Utöver dessa frågor utformades frågor om kön, ålder, erfarenhet och andra kontextuella förutsättningar för varje respondent. Dessa intervjufrågor bifogas i bilaga 3. Intervjuerna tilläts dock att utvecklas från den kunskap och upplevelse som respondenten i fråga besatt.
Målet var att få en så ingående inblick i situationen ur de valda perspektiven som möjligt i omfattningen av studien, för att sedan analysera materialet utefter de bestämda mätpunkter som är avsedda att uppfylla syftet med studien och besvara forskningsfrågan.
3.2.1 Urval
För att göra urvalet av respondenter till studiens undersökning valde vi att först granska vilka utvecklingsteam som finns på fallföretaget med fokus på vilken arbetsmetod de arbetar utefter, samt vilka sorters produkter och tjänster de utvecklar. Eftersom fallföretaget växer snabbt, så har en betydande andel av utvecklingsteamen inte varit aktiva under en längre tid. Vi valde därför bort team som antingen inte arbetade mot UX alls, eller som inte hunnit bli en del av det samarbete som redan är implementerat mellan UX-designers och utvecklingsteam.
För att öka kunna graden av reliabilitet valde vi att inkludera två team som arbetar enligt Scrum och två team som arbetar enligt Scrumban. Avsikten var att få empiri som representerar agil metodik, oavsett vilken sorts agil metodik som respondenterna använder sig av. Vi anser inte att detta stör studiens syfte eftersom främsta skillnaden mellan Scrum och Scrumban ligger i tidsramarna och hur man förhåller sig till mål för varje iteration. För att kunna fånga ytterligare nyanser i kommunikationen och samarbetet mellan utvecklingsteamen och UX-avdelningen, valdes både utvecklingsteam som arbetar mot interna intressenter, samt de som arbetar mer mot kund och externa intressenter.
Studiens respondenter representerar fyra olika roller inom fallföretaget. Dessa roller är Development Manager, Produktägare, Utvecklare och UX-designer. Syftet med att involvera Development Managers var att få en övergripande bild av hur kommunikationen är avsedd att fungera. Produktägarna är de som för majoriteten av kommunikationen mellan utveckling och UX-designers, vilket gör att de kan bidra med perspektivet av hur det faktiskt fungerar i verkligheten. Utvecklarna har mest intresse av kommunikation med UX- designers vid implementationen av de skisser som UX-designers tar fram för de tänkta vyerna. Den sista delen var att gå ifrån utvecklingsperspektivet och istället se UX-designers perspektiv på kommunikationen med utvecklingsteamen. Vi har valt att inkludera två development managers, tre produktägare, tre utvecklare och tre UX-designers. Samtliga tillfrågade tackade ja till att bli intervjuade och gav medgivande till inspelning av intervjuerna.
21 (52) 3.2.2 Genomförande
Genom att studera forskningsfrågor som använts i tidigare forskning och analysera vilka faktorer som studien fokuserar på, utformades ursprungligen två forskningsfrågor. Efter ett antal iterationer, en mer rigorös genomarbetning av litteraturstudien och sammanställning av empiri, formulerades slutligen en forskningsfråga.
Med hjälp av semistrukturerade intervjuer fångades fler nyanser av respondenternas erfarenheter, eftersom detta tillvägagångssätt gav utrymme till att ställa motfrågor och motverka upprepning av frågor där svaret redan besvarats under samtalets gång. Valet av intervjumetod är också anpassat efter fallföretaget företagskultur, vilken förespråkar informell, öppen muntlig kommunikation face to face. För att säkerställa att inga signaler missades under empiriinsamlingen valde vi att båda närvara under intervjutillfällena, där en agerade som intervjuare och den andra som observatör.
Samtliga intervjuer spelades in och transkriberades. På grund av rådande förutsättningar under Corona-pandemin fick två av intervjuerna hållas på distans. Intervjuerna spelades då in med både bild och ljud och transkriberades sedan precis som föregående intervjuer. All transkribering är gjord ordagrant, där varje mening kodad med anonymiserade markörer. I de fall någon form av förstärkande eller kontrasterande känsloyttring upptäckts, har det noterats.
3.3 Analys
Genom att koda det transkriberade materialet kunde materialet sedan kategoriseras och sammanställas i tabellform utefter tillhörande respondentgrupp. Tabellerna delades upp mellan artefakter som används av respondenterna, personuppgifter för varje respondentgrupp och de insikter respektive respondent bidrog med. Eftersom personuppgifter kan möjliggöra identifiering av specifik respondent valdes att endast presentera snitt och fördelning i samtliga respondentgrupper. Av samma anledning flyttades insikter från empirin till egna figurer grupperade efter respondentgrupp istället för enskilda respondenter. Utöver det har empirin tematiserats utifrån kategorierna roller och artefakter samt processer, barriärer och informationsbehov.
Analysen är i första hand gjord med hjälp av teorin Boundary Object Theory. De identifierade gemensamt använda artefakterna i fråga har analyserats genom att använda de kriterier som teorin anger behöver uppfyllas, för att en artefakt ska kunna ses som ett fungerande boundary object. Dessutom har analysavsnittet försökt att kontextualisera den analyserade empirin med hjälp av de metodologiska ramverken, för att försöka klargöra och förklara utmaningarna, åsikterna och sambanden som empirin visar ur ett teoretiskt perspektiv. Studien har på detta sätt försökt att öka reliabiliteten genom att använda både teorin för analys, men samtidigt ta med de båda metodologiernas kontextuella bidrag.
22 (52)
Analysen är gjord på den empiri som är kopplad till funktionsöverskridande artefakter som används på fallföretaget och respektive respondentgrupps perspektiv av hur artefakterna fungerar för informationsöverföring mellan utvecklingsavdelningen och UX. Övrig empiri som mer rör upplevelse av processer, interaktion mellan roller och funktioner i övrigt, samt respondenternas förståelse för varandras arbetsuppgifter används tillsammans med de metodologiska ramverken och resultatet från litteraturstudien till att problematisera i diskussionsavsnittet.
3.4 Tillförlitlighet
Jacobsen (2002) beskriver två krav för kvaliteten av en studies insamlade empiri, validitet och reliabilitet. Validitet kan i sin tur delas in i två kategorier, intern- och extern validitet.
Intern validitet innebär att empirin måste vara giltig, alltså att man faktiskt undersöker det som man menar att undersöka. Extern validitet handlar sedan mer om i vilken utsträckning resultatet kan generaliseras till andra sammanhang. Med reliabilitet avses att empirin måste vara tillförlitlig. Utförandet måste ha skett på ett sådant sätt som gör att resultatet kan ses som trovärdigt.
Som förklarats tidigare i kapitlet användes öppna frågor i semistrukturerade intervjuer för att möjliggöra öppna svar, vilka reflekterar respondentens egen upplevelse. Det gjordes för att öka både studiens reliabilitet och validitet. Genom att till viss del strukturera intervjuerna skapade vi förutsättningar för att faktiskt få svar på det vi undersöker. Eftersom vi ställde öppna frågor som krävde öppna svar, lät vi på så sätt även respondentens faktiska upplevelse av situationen genomsyra empirin. Det skapade förutsättningar för att studiens resultat är grundade i en trovärdig bild av situationen.
Frågorna som utformades för intervjuerna grundades i syftet med studien och den kunskap som vi med den här studien ville generera. Genom intervjuerna kunde använda artefakter identifieras, samt vilka av dessa som användes mellan funktionerna. Genom intervjuerna kunde vi även få fram hur respondenterna upplever informationsöverföring genom dessa artefakter, men främst hur de upplever samarbetet och kommunikationen funktionerna emellan. Genom att analysera situationen ur respektive rolls perspektiv skapades förutsättningar för att få en holistisk förståelse för situationen vilket stödjer studiens interna validitet.
Vi valde att intervjua varje respondent enskilt och vi har båda närvarat vid samtliga intervjuer. Samtliga intervjuer utom två har utförts face-to-face i förbokade mötesrum på fallföretaget, med goda möjligheter till att undvika yttre påverkan från fallföretagets övriga verksamhet. Respondenterna har intervjuats enskilt för att undvika att respondenter påverkar varandras svar, eller på något sätt hämmar ett öppet samtal, vilket möjligtvis hade kunnat skada resultatets reliabilitet. Motivet till att vi båda deltog i intervjun, var att vi skulle kunna koncentrera oss helt på våra respektive uppgifter: att leda samtalet respektive
23 (52)
dokumentera, spela in och observera. Vem som hade respektive roll varierades mellan intervjuer, för att den som intervjuade inte skulle ha samma teamtillhörighet som respondenten. Eventuell teamtillhörighet skulle kunna leda till att den som intervjuade, avsiktligt eller oavsiktligt styrde respondenten på ett sätt som skadar studiens reliabilitet.
Studiens val av respondenter är gjord efter bästa förmåga efter vad vi vet om organisationen efter snart tre år på fallföretaget. Det är vår uppfattning att antalet respondenter och deras fördelning i kön, roller, erfarenhet och ålder är en representativ bild av hur det ser ut på fallföretaget. Vidare har vi i den utsträckning det har varit möjligt, valt respondenter som faktiskt arbetar med varandra för att säkerställa att vi får båda perspektiven på samma situation vilket ytterligare ökar reliabiliteten i studiens resultat. Dessutom valdes samtliga respondenter i de olika rollerna med fokus på att få med ett brett spektrum av vad UX respektive den agila verksamheten innefattar. Vid urval av respondenter för UX valdes respondenter med olika fokusområden inom området för att studiens resultat skulle behandla hela omfattningen av vad UX innefattar. Vid urval av respondenter från utvecklingsavdelningen valdes respondenter som arbetar såväl enligt olika agila arbetsmetoder, som med olika utvecklingsfokus i form av utveckling av interna system respektive kundsystem. Det bidrar även till att studiens resultat kan generaliseras till andra sammanhang vilket ökar studiens externa validitet.
Eftersom fallföretagets kultur uttalat är för öppen och informell dialog, anser vi att det finns goda utsikter för att respondenternas svar är uppriktiga. Undersökningen av problemet som utreds i studien är dessutom något som aktivt efterfrågats av fallföretagets kontaktpersoner och flera av respondenterna. Detta skapar goda förutsättningar för god reliabilitet i studiens resultat.
3.5 Etiska överväganden
Samtliga respondenter medverkade i studien frivilligt och syftet med studien kommunicerades tydligt innan respondenterna tackade ja till medverkan i studien. Samtliga respondenter informerades även om att intervjuerna skulle spelas in och godkände det i förväg. Eftersom intervjuerna hölls med respondenterna var för sig valde vi att sammanställa materialet gruppvis, baserat på yrkesroll för att bibehålla respondenternas anonymitet och integritet. Material som ansågs som känslig information presenteras inte i studien av samma anledning. Sammanställningen av empirin är utformad i tabellerna på ett sådant sätt att det inte går att koppla ihop respondenternas utsagor med ålder, kön eller erfarenhet. Detta för att säkerhetsställa fullständig anonymitet i så stor utsträckning som möjligt. Sekretessavtal med fallföretaget har även gjort att känslig information kopplat till fallföretaget inte heller inkluderas i studien för att bibehålla fallföretagets anonymitet.
