I följande kapitel genomförs en analys av och en diskussion kring de utmaningar som presenterats i föregående kapitel, mot bakgrund av studiens litteraturstudie.
5.1 Upprätthålla kommunikationskanaler
Kommunikation skapar förutsättningar för att deltagarna från olika branscher kan bidra med sina insikter och kunskaper tidigt i designprocessen. Elbanna och Sarker (2015) skriver att avsaknaden av en gemensam användning av kommunikationsverktyg kan leda till förvirring inom teamet vilket skadar samarbetet. Vidare menar Liikanen et al. (2014) att Lean UX som ansats ställer höga krav på en organisations struktur och anpassningsförmåga. I Just Arrived har vi observerat att projektdeltagarna använt flertalet kommunikationskanaler och att det saknats en tydlig struktur kring var och hur kommunikationen ska ske. Då projektteamet utgjorts av deltagare från olika branscher har preferenserna för hur kommunikation ska gå till varierat. Exempelvis har utvecklare föredragit verktyget Slack medan marknadsföringssidan varit lättast att nå via mail. Aktivitetsgraden i kommunikationskanalerna har också varierat.
Detta har resulterat i att mer aktiva projektdeltagare behövt ta kommando och regelbundet fråga de mindre aktiva projektdeltagarna om var de befinner sig i projektet. Utmaningen har varit att upprätthålla tydliga kommunikationskanaler och skapa en transparent designprocess, där alla deltagare är medvetna om projektets status och vad som behöver göras.
Gothelf och Seiden (2013) belyser essensen av interaktion mellan projektets olika deltagare, och att även se till att dessa befinner sig på samma nivå genom ett gott samarbete mellan projektets tvärfunktionella team. Projektdeltagarna menar på att det varit svårt att veta exakt var i processen somliga projektdeltagare har befunnit sig och att de inte varit medvetna om vilka problem de andra arbetar med. Detta har resulterat i att de andra projektdeltagarna inte kunnat bidra med nya insikter kring, eller lösningar på problem. För att tillämpningen av Lean UX ska lyckas krävs att organisationen upprätthåller en kollaborativ miljö där alla yrkesgrupper har möjlighet att även bidra med insikter och lösningar som ligger utanför ens kärnkompetensområde (Gothelf & Seiden, 2013). Detta ökar effektiviteten och sammanhållningen inom projektteamet (Gothelf & Seiden, 2013), vilket är särskilt viktigt inom Lean UX då ansatsen förespråkar ett nära samarbete och frekventa interaktioner mellan tvärfunktionella team, samt undvikande av omfattande dokumentation. Gothelf och Sieden (2013) poängterar att ett bra samarbete bidrar till en miljö där en kollektiv förståelse för produkten och kunderna kan bildas. När alla i teamet förstår vad som händer och varför, krävs mindre dokumentation för att fortsätta arbeta. McHugh et al. (2012) poängterar även att ett förtroende för projektdeltagarnas förmågor är en viktig komponent för att effektivisera samarbetet inom agila metoder, och leder till att teamen självorganiserar sig och bättre hanterar de problem som uppstår. Den gemensamma förståelsen och förhöjda effektiviteten inom projektteamet ökar förutsättningarna för att produkten når marknaden snabbt, och samtidigt möter slutanvändarnas behov (Gothelf & Sieden, 2013). För att undvika omfattande dokumentation och en förlängd utvecklingsprocess behöver Lean UX-‐ansatsen vara effektiv, och
resursslöseriet minimalt (Liikanen et al., 2014). Ansatsen ställer i och med detta krav på att kommunikationen inom projektteamet är så effektiv och regelbunden som möjligt.
5.1.1 Hur utmaningen kan bemötas
Just Arrived har som organisation saknat en struktur för vilka kommunikationskanaler som ska användas, vilket har resulterat i att team inom olika ansvarsområden har använt olika kommunikationskanaler. Detta har påverkat den gemensamma förståelsen för vad som sker i projektet och vem som gör vad. Utmaningen har grundats i att projektledningen inte ställt tydliga krav kring hur, var, och när kommunikationen ska ske. Ramesh, Cao, Mohan och Xu (2006) menar att i projekt där agila team är distribuerade, bör varje team utnämna en teammedlem som primär kontaktperson. Ramesh et al. (2006) skriver att dessa utnämnda kontaktpersoner bär ansvaret att facilitera kommunikation mellan teamen. Detta i syfte att formalisera och förbättra kommunikationen mellan de distribuerade teamen. Vidare understryker Liikanen et al. (2014) att utveckling inom Lean som filosofi innebär att skala ner ett projekts aspekter så mycket som möjligt. En sådan åtgärd kan vara att minimera antalet kommunikationskanaler i syfte att skapa ordning, öka sammanhållningen inom teamet och förtydliga var kommunikation kan och bör äga rum.
5.2 Upprätthålla momentum
Gothelf och Seiden (2013) menar att projektets utvecklare bör ligga i fas med vad projektets designers för stunden arbetar med, och därmed bör de inte befinna sig längre bak i projektet rent framstegsmässigt. Så har inte fallet varit för front-‐end-‐utvecklarna i Just Arrived. Anledningen till detta var delvis att front-‐end-‐utvecklarna ville uppleva en känsla av momentum, och därför ville de vänta tills de erhållit enligt dem själva tillräckligt mycket material från designers för att kunna arbeta effektivt. Problemet ligger i linje med den utmaning Cyrillo (2011) lyfter med Lean UX kring att det kan vara svårt att inom ansatsen förse utvecklarna med tillräcklig mängd information så att de kan börja arbeta, innan designen är klar. Rodriguez et al. (2014) betonar att kontinuerlig planering i agila mjukvaruutvecklingsprojekt där principerna inom Lean Production appliceras, kräver en hög nivå av synkronisering mellan projektdeltagare. Detta för att inte så kallade flaskhalsar ska uppstå vilka kan resultera i ledtider (Rodriguez et al., 2014). Vidare kräver Lean UX att samtliga yrkesgrupper i projektteamet är på samma nivå och således är i fas med varandra i syfte att upprätthålla en gemensam förståelse kring produkten och effektmål (Gothelf &
Seiden, 2013). Den gemensamma förståelsen främjar i sin tur att momentum kan upprätthållas samtidigt som mängden dokumentation kan minimeras. Att upprätthålla momentum inom Lean UX är viktigt av flera anledningar. Bland annat kan valideringar av designlösningar då ske effektivt och med minimal fördröjning, vilket gör att lärandet om slutanvändarna snabbt kan styra produkten i rätt riktning. Detta leder i sin tur till att produkten kan lanseras och nå marknaden snabbt, vilket är ett centralt mål inom Lean UX enligt Gothelf och Seiden (2013).
Gothelf och Seiden (2013) menar att ett samarbete med distribuerade och således ej samlokaliserade tredjepartsutvecklare är en utmaning inom Lean UX, vilket även vi identifierade som en utmaning i Just Arrived och den Lean UX-‐
ansats projektet tillämpat. Vidare skriver Liikanen et al. (2014) att projekt med distribuerade team kan resultera att kunskap isoleras inom teamen. Baserat på empiri från de djupintervjuer vi genomförde med projektdeltagare identifierades emellertid ett antal fördelar med att teamen i projektet inte varit samlokaliserade. En av intervjurespondenterna poängterade exempelvis att de olika projektteamen kan dra nytta av sina egna nätverk om de inte är samlokaliserade. Därmed kan exempelvis designteamet med fördel dra nytta av sitt nätverk av designers medan projektägare kan dra nytta av sitt nätverk där de arbetar.
5.2.1 Hur utmaningen kan bemötas
I Just Arrived har somliga projektdeltagare inte varit i fas med varandra arbetsmässigt, vilket i sin tur är ett resultat av att projektteamen varit distribuerade och således inte kunnat interagera med varandra regelbundet på samma fysiska plats. Detta har reducerat momentum inom projektet. Vidare skriver Ramesh et al. (2006) att projektledningen inom distribuerade och agila projektteam bör koordinera aktiviteter och se till att projektdeltagare rapporterar händelser. Detta för att nå uppsatta projektmål. Att förse utvecklarna med tillräcklig mängd information så att de kan börja arbeta innan designen är klar, är en utmaning som kan reducera momentum om det inte sker.
Enligt Cyrillo (2011) kan detta åtgärdas genom att säkerställa att utvecklare är bekväma med implementering av low-‐fi-‐prototyper samt att förse dem med design patterns. Vidare måste projektteam som tillämpar Lean UX vara förberedda på möjligheten att design och kod kan behöva ändras omedelbart, ifall hypoteser visar sig vara falsifierade (Liikanen et al., 2014).
5.3 Tillgång till målgrupp
Deltagarna i projektet hade inte från början räknat med att det skulle vara svårt att få tillgång till målgruppen nyanlända. Detta ledde till att validering av designlösningar med slutanvändare inte kunnat ske regelbundet på grund av att målgruppen nyanlända varit svårtillgänglig. I användarcentrerade designprocesser är förståelsen för användarna, deras problem och behov en förutsättning för att kunna utveckla tjänster som är tillfredställande (Vredenburg, Isensee, Righi & Design, 2001). Gould och Clayton (1985) poängterar att designteamet bör ta kontakt med de potentiella användarna, intervjua och observera dem för att förstå deras behov redan innan utvecklingen påbörjats. Sy (2007) poängterar vikten av att inom agila metoder genomföra användningstester under hela utvecklingsprocessen för att säkerställa att slutanvändarnas behov nås. Vidare belyser Gulliksen och Göransson (2002) problematiken som kan uppstå då användarmedverkan inom systemutveckling inte representeras av de tilltänkta slutanvändarna. Enligt Gothelf och Seiden (2013) bör användningstester inom Lean UX schemaläggas regelbundet så att designlösningar och idéer kan valideras medan de fortfarande är nyproducerade.
Gothelf och Seiden (2013) föreslår införandet av en “testa-‐allt-‐policy” för att inom ansatsen upprätthålla en regelbunden rytm av användartester. Silva da
silva et al. (2013) understryker att användningstester är tidskonsumerande och dyra att planera inför, genomföra och analysera. Bobeth et al. (2013) menar att en utmaning med användarcentrerad design kan vara att hitta och rekrytera användare.
Gothelf och Seiden (2013) understryker att projektteamet oundvikligen kommer behöva anpassa Lean UX-‐ansatsen efter den egna organisationen och projektets förhållanden. Avsaknaden av regelbunden tillgång till målgrupperna tvingar projektteamet att anpassa sig och vänta på att validering kan ske. Detta medför att designresurser inte kan användas med maximal effektivitet och att projektet rör sig framåt i en långsammare takt. Ju tidigare projektteamet kan validera designlösningar, desto tidigare vet teamet vilka designlösningar som är värda att investera projektets begränsade resurser i (Gothelf & Seiden, 2013). Eftersom att Lean UX som ansats kräver en hög grad av användarinvolvering (Gothelf &
Seiden, 2013) uppstår problematik när målgruppen är otillgänglig.
Problematiken kan resultera i att utvecklingsprocessen förlängs med stigande kostnader som följd, eller att de designade tjänsterna inte möter de verkliga slutanvändarnas behov. I Just Arrived kan problemet kring otillgänglig målgrupp anses vara en kontextuell utmaning. Dock skapar en otillgänglig målgrupp stora problem inom Lean UX då ansatsen kräver kontinuerliga användarstudier och validering. Otillgängliga målgrupper i projekt där Lean UX tillämpas kan vara utmanande eftersom att projektet då riskerar att försenas, eller misslyckas med att möta slutanvändarnas behov.
5.3.1 Hur utmaningen kan bemötas
Utmaningen kan förebyggas genom att undersöka målgruppens tillgänglighet och planera för användningstester i ett tidigt stadium i projektet. Liikanen et al.
(2014) poängterar att projektteamet bör se till att de har tillgång till användare innan Lean UX tillämpas som ansats. Att inte ha god tillgång till målgruppen inom projektteamet är således en organisatorisk utmaning. Svårtillgängliga målgrupper kan förslagsvis nås genom att samarbeta med icke-‐vinstdrivande organisationer (Benoit, Jansson, Millar, & Phillips, 2005; Bobeth, Schreitter, Schmehl, Deutsch & Tscheligi, 2013). Sy (2007) föreslår introduceringen av så kallade Designpartners i utvecklingsprojekt vilka utgörs av slutanvändare som åtar sig att delta i användningstester under hela projektets gång.
5.4 Definition av MVP
Det har funnits en avsaknad av en gemensam förståelse kring vad en MVP är i projekt Just Arrived. Detta har resulterat i att arbetstimmar och resurser slösats på ett antal funktioner som inte kom att implementeras vid första lansering, och som nödvändigtvis inte kommer att implementeras i en senare version heller.
Gothelf och Seiden (2013) hävdar att begreppet MVP har skapat förvirring, och problemet är att begreppet används på olika sätt. Enligt Gothelf och Seiden (2013) behöver en MVP inte vara byggd i kod, utan kan bestå av exempelvis en lo-‐fi prototyp eller en enkät vars syfte är att validera hypoteser och designlösningar. I Just Arrived tvingades vi att skala ner tjänsten och antalet funktioner för att utvecklarna skulle hinna bli klara tills lanseringsdatumet.
Detta går emot de rekommendationer Gothelf och Seiden (2013) skriver om där de menar att lärande inom Lean UX som ansats prioriteras framför tillväxt.
Vidare skriver Ries (2011) och Moogk (2012) att framsteg som en start-‐up-‐
liknande organisation gör kan mätas i mängden lärande som erhålls genom experiment och MVPs. Vidare ökar chanserna att rätt produkt som når rätt marknad utvecklas, om lärandet kan ske så accelererande som möjligt (Moogk, 2012). Gothelf och Seiden (2013) understryker att validering av hypoteser och designlösningar bidrar till lärande som i sin tur är en förutsättning för att produkten i fråga kan skalas upp. Enligt Ibarogoyen et al. (2013) kan det uppstå kommunikationsproblem när designers och utvecklare arbetar tillsammans på grund av att begrepp och termer används olika inom disciplinerna. Cyrillo (2011) skriver att produktvision, användarstudier och ett iterativt arbetssätt utgör centrala delar av ansatsen Lean UX. En gemensam vision är nödvändig för att inom ansatsen ta beslut kring vad som är viktigast och vad som behöver prioriteras (Gothelf & Sieden, 2013). En gemensam uppfattning kring vad MVPn behöver innehålla skapar i sin tur förutsättningar för ett effektivt arbete där projektdeltagarna är medvetna om vad de behöver prioritera (Gothelf & Sieden, 2013). Detta minskar även resursslöseri då samarbetet kan effektiviseras.
5.4.1 Hur utmaningen kan bemötas
Komi-‐Sirviö och Tihinen (2005) understryker med sin studie att verktygsrelaterade problem inom distribuerade utvecklingsteam adresseras som mest effektivt i början av projektet. Det är således viktigt att teamet från projektstart har en gemensam definition av vad en MVP är och vad den förväntas bestå av. Genom att alla arbetar mot en gemensam vision och en gemensam förståelse för vad som behöver göras och varför, kan också detaljerad dokumentation undvikas (Gothelf & Seiden, 2013). En gemensam definition i projektteamet förhindrar även att arbetstimmar och resurser slösas på funktioner som eventuellt inte implementeras i produkten. Vidare föreslår Komi-‐
Sirviö och Tihinen (2005) att en definition och dokumentation av för projektet acceptabla verktyg och versioner bör skapas. Det är således viktigt att inom projektteamet exempelvis redogöra för skillnaden mellan en MVP och den första lanseringen av produkten, samt regelbundet kommunicera detta. På så vis skapas en gemensam förståelse inom teamet för vilka funktioner som ska implementeras i projektets MVPs respektive den första lanseringen av produkten.