1
Hur används Lean Software Development i praktiken?
Författare: Malin Almstedt 970807 & Amela Begic 960127
HT19
Informatik med systemvetenskaplig inriktning, kandidatkurs, 15 hp Ämne: Informatik
Handelshögskolan vid Örebro universitet Handledare: Jonas Moll
2
Sammanfattning
Denna uppsats är en kvalitativ studie som bygger på fyra semistrukturerade intervjuer, en ostrukturerad intervju samt en observation. Studien har genomförts på en mindre verksamhet i Region Örebro län. Syftet med studien var att undersöka hur LSD används i praktiken i jämförelse med andra fallstudier inom detta område samt i jämförelse till de praktiker och principer som LSD förespråkar att företag ska använda. Resultatet visade att fallstudierna följer det LSD förespråkar utan att implementera egna metoder medan den verksamheten där vår studie genomfördes följer principerna till viss del. Resultatet visade att tre principer samt Kanban tavla implementeras till fullo av verksamheten. De resterande fyra principerna; Eliminate waste, Build quality in, Postpone commitments och följa upp ledtider har potential att implementeras då verksamheten till viss del redan använder sig av principerna men inte till fullo.
3
Innehåll
1. Inledning ... 7
1.1 Studieobjekt ... 8
1.2 Syfte och frågeställningar ... 8
1.3 Avgränsning ... 8
1.4 Disposition... 8
2. Lean ... 9
2.1 Leans tre huvudelement ... 9
2.2 Fallstudier ... 12 2.2.1 Fall 1 ... 12 2.2.2 Fall 2 ... 14 3. Metod ... 17 3.1 Metodologisk utgångspunkt ... 17 3.2 Ostrukturerad intervju ... 17 3.3 Observation ... 18 3.4 Semi-strukturerade intervjuer ... 19 3.5 Urval av respondenter ... 20 3.6 Val av organisation ... 20 3.6 Sökvägar ... 20
4. Bearbetning och analys av data ... 21
4.1 Intervjuer ... 21
4.2 Analys av observation ... 22
4.2.1 Tillförlitlighet ... 23
5. Etik ... 24
5.1 Forskarnas roll ... 26
6. Resultat & analys ... 27
6.1 Arbetsmodell ... 27 6.2 Arbetssätt ... 28 6.3 Morgonmöten ... 30 6.4 Eliminera slöseri ... 31 6.5 Optimering... 32 6.6 Kunskap ... 33 6.7 Kvalitet ... 33 6.8 Beslutstagning ... 34 6.9 Leverera snabbt ... 34 6.10 Respektera folk ... 34
4
6.11 Estimering/Ledtid ... 35
7. Diskussion ... 37
7.1 Hur används Lean Software Development i praktiken baserat på fallstudier? ... 37
7.2 Metoddiskussion ... 40
8. Slutsats och bidrag ... 41
8.1 Förslag på framtida forskning ... 41
9. Referenser ... 42
10. Bilagor ... 43
Bilaga - Informationsbrev intervjuer ... 43
Bilaga - Informationsbrev observationer ... 46
Bilaga - Intervjufrågor ... 49
5
Förord
Vi vill tacka verksamheten där studien genomfördes. Trots arbetsbelastning på verksamheten fick vi komma och intervjua flera av dem. Vi vill även rikta ett tack till vänner och familj som läst igenom vår uppsats och kommit med feedback samt stöttat oss under processen.
6
Centrala begrepp
Nedan presenteras centrala begrepp som uppsatsen kommer att beröra.
Lean Software Development (LSD) - En systemutvecklingsmetod som bygger på Leans
principer och praktiker (Poppendieck & Poppendieck 2003).
Kanban - Är en metod/princip där utvecklingen ses som ett ständigt flöde av arbetsuppgifter.
Med hjälp av Kanban tavlan blir flödet visualiserat och ger teamet en översikt av vad som ska göras, detta för att de ska kunna samarbeta och hitta stopp i flödet snabbt (Björkholm & Brattberg 2018).
Work in process (WIP) - Detta är mängden arbete som är påbörjat men inte har levererats till
kund (Björkholm & Brattberg 2018).
Sprint - Man delar upp arbetet i iterationer (sprintar) på till exempel två-fyra veckor. Längden
varierar mellan olika team utifrån deras behov (Björkholm & Brattberg 2018).
Flaskhals - Det steg i en process som “stryper” flödet. Det är flaskhalsen som kommer
begränsa genomflödet i hela processen (Björkholm & Brattberg 2018).
Estimering - Ett sätt att uppskatta tid, detta kan mätas genom timmar, Scrum poäng eller
genom andra verktyg (Björkholm & Brattberg 2018).
Ledtid - Ledtid är den totala förflutna tid som går från att en kund begär en programvara tills
7
1. Inledning
Begreppet Lean software development härstammar från verk av Mary och Tom Poppendieck (Poppendieck & Poppendieck 2003). Begreppet Lean uppkom redan under industriella renässansen i en japansk biltillverkning efter andra världskriget på 1940-talet. Termen Lean tillämpades dock inte offentligt förrän på en produktionshanteringsprocess och sedan vid produktutvecklingen på MIT (Massachusetts Institute of Technology) under 1980-talet. I allmänhet innebär Lean en tillverkning- och produktionpraxis som fokuserar på att skapa värde för kunden (Razzak 2016). Lean software development kan ses som en kombination av Lean produktutveckling med Leans IT-principer och deras tillämpning vid
mjukvaruutveckling. Denna strategi består av sju principer: Eliminate waste, Build Quality
In, Create Knowledge, Defer Commitment, Respect People, Deliver Fast, Optimize The Whole. Lean software development har använts för att optimera utvecklingens processer,
främst på grund av begreppet Eliminate waste som är en del i optimering av all verksamhet som producerar ineffektivitet. Tidigare publicerade fallstudier har implementerat LSD på team som redan arbetar efter en implementerad metod, men det finns inga undersökningar gällande att undersöka team som inte har en implementerad metod. Vi uppmärksammade även under litteratursökningen att majoriteten av artiklarna som berörde LSD var publicerade de senaste fem åren. Vi ansåg att det var intressant att undersöka ett ämne som blir allt mer populärt.
Uppsatsen avser att undersöka användningen av LSD i en mindre verksamhet jämfört med hur LSD används i andra fallstudier utförda på verksamheter bestående av mindre team. Vi vill undersöka om det finns några skillnader och likheter samt vad dessa är. LSD förespråkar många principer som bör implementeras av företag - men sker detta verkligen i praktiken eller finns det avvikelser hos dessa verksamheter som säger sig arbeta efter LSD?
8
1.1 Studieobjekt
Vi har valt att undersöka IT-avdelningen på en verksamhet i Region Örebro. Det vi vill undersöka är hur personalen arbetar idag, om de arbetar efter några principer och praktiker inom Lean Software Development och koppla dessa iakttagelser till tidigare fältstudier och vad Lean förespråkar.
1.2 Syfte och frågeställningar
Syftet med rapporten är att undersöka hur Lean Software Development används i praktiken. De som kan ha nytta av denna information är främst forskare inom Lean Software
Development samt utvecklingsteam som vill se över sitt metodanvändande.
Inom de undersökningar vi har stött på tidigare har det endast varit fältstudier där man implementerat LSD i team som vanligtvis använder sig av andra systemutvecklingsmetoder. Då det till vår kännedom inte finns några undersökningar där det undersöks hur LSD används i praktiken på team som inte har en uttalad systemutvecklingsmetod så anser vi att detta är ett intressant undersökningsområde.
Vår frågeställning lyder:
- Hur används Lean Software Development i praktiken baserat på en fallstudie jämförd med det som Lean förespråkar och litteratur om andra fallstudier?
1.3 Avgränsning
Studien är avgränsad till en IT-avdelning i Region Örebro län. Regionen består av ett flertal verksamheter och IT-avdelningen som undersöks är en av de verksamheterna. Eftersom det finns flertal IT-avdelningar inom regionen valde vi ut en av dem att utföra studien på. Detta baserat på tidsramen för uppsatsen men även för att få en analyserad bild av verksamhetens arbetssätt, gentemot att undersöka flertal mindre verksamheter där vi hade fått en översiktlig bild. När vi skriver “verksamheten” i texten menas den IT-avdelning som har valts för studien.
1.4 Disposition
I kapitel 1 introduceras problemområdet, forskningsobjektet samt hur vi har valt att avgränsa oss. I kapitel 2 redogör vi den teoretiska bakgrunden till Leans praktiker och principer, samt presenterar två stycken fallstudier som implementerat Lean. I kapitel 3 beskriver vi vår metodansats. I efterföljande del, kapitel 4, presenteras resultatet baserat på intervjuer och observationer. Kapitel 5 innehåller en diskussion kring resultatet. Slutligen i kapitel 6 redogör vi för vår slutsats samt ger förslag på fortsatt forskning inom aktuellt område.
9
2. Lean
Enligt Razzak (2016) uppkom begreppet Lean redan under industriella renässansen i en japansk biltillverkning efter andra världskriget på 1940-talet. Termen Lean tillämpades dock inte offentligt förrän på en produktionshanteringsprocess och sedan vid produktutvecklingen på MIT (Massachusetts Institute of Technology) under 1980-talet. I allmänhet innebär Lean en tillverkning- och produktionpraxis som fokuserar på att skapa värde för kunden.
2.1 Leans tre huvudelement
Wang, Conboy och Cawley (2012) nämner att Lean software development involverar tre huvudelement, dessa är Lean concepts, Lean principles och Lean practices.
Enligt författarna innebär Lean concepts att “[...]specify value, line up value-creating actions in the best sequence, conduct these activities without interruption whenever someone requests them, and perform them more and more effectively” (Wang et al. 2012, s.1288). Med detta menar de att organisationer bör specificera värdet, lägga upp värdeskapande handlingar i den bästa ordning och genomföra dem utan avbrott, detta gör arbetet alltmer effektivt.
Lean principles primära fokus och vägledande princip är att identifiera och eliminera slöseri
från processen med hänsyn till kundvärde. Genom att kartlägga processen kan steg som inte bidrar till att skapa värde identifieras. Enligt Wang et al. (2012) kan begreppet slöseri tolkas olika beroende på kontext. Det kan tolkas som extrafunktioner, extra processer,
uppgiftsväxling med mera.
Under Lean principles ingår sju principer. Björkholm & Brattberg (2018) illustrerar dessa:
Eliminate waste: (Ta bort ojämnheter, överbelastning och slöseri)
- Ojämnt flöde: För att uppnå maximal effektivitet måste störningsmoment som
påverkar processens flöde negativt och minskar effektiviteten tas bort.
Störningsmoment kan vara påtryckning, sidospår och förändrade krav. Författarna redovisar några tips för att jämna ut flödet och minimera ledtiden:
● Prioritera att bli klar med pågående uppdrag istället för att påbörja nya. ● Samarbeta istället för att jobba med en sak var.
- Överbelastning: Personer ska aldrig överbelastas med jobb eftersom en person som är överbelastad med arbetsuppgifter ofta tar fel beslut och får aldrig tid för förbättringar. - Slöseri: För att få bästa effektivitet ska slöseri identifieras och elimineras. Det kan
handla om onödiga möten, krångliga rutiner och svåråtkomlig information.
- Ett exempel på slöseri är ej färdiggjort arbete (partially done work). Påbörjade arbeten som inte är färdigställda för att kunna levereras till kund är en kostnad utan värde. Till exempel ej uppdaterad dokumentation, icke testad kod, icke lanserad kod.
10 - Ett annat exempel är att växla mellan uppgifter (task switching). Att hoppa mellan
uppgifter kan göra att projekt blir klara senare och därav genererar värde senare. Till följd kan företag få missnöjda kunder. Att jobba med en sak i taget gör att ledtiden minskar och effektivitet och kundnöjdhet ökar.
Build quality in: (Satsa på kvalitet)
- Säkerställ kvaliteten redan från början och vänta inte på att göra tester till slutet med hopp om att testerna ska fånga upp alla kvalitetsbrister. Åtgärda fel som dyker upp omgående, då går det snabbare i och med att utvecklarna har koden i gott minne.
Create knowledge: (Fokusera på lärandet)
- Att lära upp personal är en kostnad men även en viktig investering då man slipper återlärning i framtiden. Den person som har kunskap ansvarar för att sprida den till de som inte har kunskap och den som behöver kunskap ska söka upp den person som har den. Det är viktigare att jobba tillsammans framför en omfattande dokumentation då man överför kunskap i det dagliga arbetet när man jobbar tillsammans.
Defer Commitment: (Vänta med beslut)
- För att ta rätt beslut ska man vänta med beslutet så länge som möjligt, tills det att man har tillräckligt med information och kunskap. När man har inhämtat tillräckligt mycket kunskap kan man minska risken att göra ett felaktigt val, vid till exempel val av
teknik.
Respect people: (Respektera medarbetare)
- Det är viktigt att respektera människor för deras kunskap och de resultat de åstadkommer.
Deliver fast: (Leverera snabbt)
- Även om man har börjat jobba på en funktion så kommer inte den börja generera
pengar förrän den är levererad till kund. Tiden mellan inkomster och kostnader bör minimeras för att få hög lönsamhet. Ett annat skäl till att minimera ledtiden är snabb leverans, detta genererar att kunden inte hinner ändra sig och inte vill ha något annat än det man har börjat utveckla. En baksida av att vara för snabb är att man kan få ökade kostnader för underhåll.
11
Optimize the Whole: (Optimera helheten)
- Man ska inte stirra sig blind utan lyfta blicken och titta på helheten. Här följer ett exempel på ett ineffektivt utförande:
● “Att låta en person bli expert på ett område och sedan bara låta den personen göra de sakerna. Kortsiktigt går det fortare om alla bara gör det de är bäst på men det minskar flexibiliteten och ökar risken att personen blir en flaskhals.” (s. 53)
Lean Practices
Wang et al. (2012) talar om en av Leans praktiker som kallas Kanban tavla. Kanban tavlan är till för att begränsa WIP. Kanban metoden definieras som “[...] a production control system for just-in-time production and making full use of workers’ capabilities” (s. 1288). De menar att det är ett produktionsstyrsystem för det som ska göras och används för att planera ut resursernas fulla kapacitet. Den huvudsakliga faktorn till Kanban systemet är att minimera mängden av WIP. Med det menas att minimera överskottet i form av slöseri från ett Lean perspektiv. De arbetsuppgifter som ska utföras är utformade på Kanban kort. Kanban korten är i olika färger (se bilaga 1) för att signalera uppströms och nedströmsprocesser, dessa rör sig fysiskt mellan processer. Målet med Kanban är att hålla en process i rörelse med en jämn men kontinuerlig hastighet vilket uppnås genom att kontrollera antalet Kanban kort som är i rörelse inom processen.
12
2.2 Fallstudier
2.2.1 Fall 1
Middleton & Joyce (2012) presenterar en fallstudie där prestandan hos ett utvecklingsteam på nio personer som är anställda av BBC Worldwide London undersöks. Tanken med studien var att implementera Lean Software Development på ett utvecklingsteam. Middleton och Joyce (2012) beskriver att kontorslayout är en viktig komponent och kopplar det till Toyotas produktion där lampor används för att produktionsstatus ska vara tillgängligt hela tiden. Samma idé applicerades på utvecklingsteamet, fast med Kanban tavla och
informationsradiatorer runt arbetsutrymmet. Målet med detta var att säkerställa att framstegen med projektet var tillgängligt för alla att se. Med hjälp av informationsradiatorerna och Kanban tavlan blev teammedlemmarna mer självständiga. Utvecklingsteamet hade också en mycket tydligare uppfattning om sin kapacitet och nuvarande WIP. Det var väldigt viktigt att hålla arbetsflödet så stabilt som möjligt. Plötsliga ändringar i arbetet kunde skada
produktiviteten. Därför var det viktigt att försöka påverka uppströmarbetsflödena så mycket som möjligt. All denna information fångades upp på korten i Kanban tavlan. Om det fanns problem i utvecklingen så skulle det snabbt att bli uppenbart då de når sin WIP-gräns och blir en synlig flaskhals.
Utvecklingsteamet fick använda sig av Daily standup som pågick i 15 minuter där de varje morgon klockan 10.15 fick stå framför Kanban tavlan. Där såg de utvecklingsfasen och uppdaterade varandra om arbetsstatus och prioritering av arbetsobjekt och vem som är “blockerad”, som inte kan fortsätta arbeta. Det togs fram en lämplig åtgärd för att ta bort “blockeringen”. Alla kluster (blockeringar) noterades på kort som identifierade en flaskhals och utifrån de omorganiserade dem för att lindra detta. Slutligen granskades arbetet för att se om prioriteringar har förändrats eller om arbetsflödet kan förbättras. Med hjälp av Kanban tavlan blev det klart för hela teamet om exakta statusen, framsteg, blockeringar och
flaskhalsar. Teamet förbereder sig även på framtida problem som kunnat uppstå då de kan se signaler i tavlan. De använde sig av olika färger på korten på Kanban tavlan för att indikera olika saker.
13
Figur 2 - Kanban tavla
Fallstudien pågick i 12 månader för att forskarna skulle kunna utvärdera effektiviteten med implementeringen av LSD. Teamet övervakade den tid det tog att arbeta från att flöda igenom olika delar av värdeströmmen. Kvaliteten och kapacitetsåtgärder spårades också med
tidsserier och statiska processkontrolldiagram. Dessa diagram har två viktiga element. De horisontella övre kontrollgränslinjerna visar varians. Ju högre linje, desto mer varians, vilket allvarligt skadar produktiviteten i processen. Den andra visar genomsnittet som den nedre horisontella linjen går över tiden.
Figur 3 - Statiskt processkontrolldiagram
Ledtid är den totala förflutna tid som går från det att en kund begär en programvara tills den färdiga programvaran släpps till kunden. Med ledtiden kunde de mäta hur snabb och pålitlig programvara levererades till kunder. Ledtiden definierades i antalet arbetsdagar som arbetet tog.
14
2.2.2 Fall 2
Misaghi & Bosnic (2014) presenterar en fallstudie som genomfördes i ett team av mjukvaruutvecklare där LSD konceptet tillämpades inom deras nuvarande process.
De har använt sig av flera olika indikatorer för att kunna övervaka produktiviteten hos teamet och mål har fastställts för att utvärdera deras framsteg.
De utvärderade tiden som teamet investerade under varje version i förbättringar och nya funktioner. Det blev en av de viktigaste indikationerna då uppgifterna gav mervärde
till produkten och ett av företagets mål var att öka denna indikator. Alla de andra aktiviteterna som teamet utförde betraktades som slöseri, även de aktiviteter som behövdes för att
processen skulle hanteras korrekt. Några exempel på aktiviteter som teamet utförde som klassades som waste var korrigering av avvikelser, planering och deltagande i möten. När tiden som spenderas i korrigering av avvikelser (fel orsakade under körning av programvara) ökar, det är en indikation på att produktens kvalitetet har försämrats. Därför kommer teamet att ha mindre tid att investera i förbättringar och nya funktioner.
I ett försök att förbättra indikatorerna som har försämrat kvaliteten och öka produktens kvalitet så valde teamet i denna fallstudie att anta begreppen Lean Software Development.
Eliminate waste
Teamet hade tidigare ofta varit engagerade i mer än en aktivitet åt gången vilket tog deras koncentration av huvuduppgifterna (implementera förbättringar och nya funktioner) och ledde till minskad produktivitet. För att minska på onödig tid så följde teamet två nya riktlinjer gällande eliminate waste:
1. För varje version av programvaran, skulle en utvecklare väljas för att hantera support uppgifter som begärs av andra team. Således skulle resten av teamet vara fria att ägna tiden till utveckling av nya funktioner och förbättringar.
2. Ingen utvecklare skulle vara involverad i mer än en funktion samtidigt.
Syftet var att implementera flödesenheten (kontinuerligt). Först efter avslutad aktivitet skulle utvecklaren ägna sig åt en annan aktivitet, även om det innebar viss driftstopp.
Integration quality (Build quality in)
Utövandet av automatiserade tester, dvs tester som inte är beroende av människans interaktion och se till att korrekt funktion av en eller flera mjukvarufunktioner skulle integreras in i processen från början. Erfarenheten visade att lämnar man utvecklingen av tester till ett senare skede orsakades slöseri, eftersom det skapade en inventering av uppgifter som knappast hanterades.
15
Create Knowledge
Här fokuserade teamet på att produkten skulle vara tillgänglig för alla teammedlemmar. De använde sig av ett samarbetsverktyg för kunskapshantering, där alla kunde bidra med att dokumentera de processer de hade.
Postpone commitments (Defer commitment)
De viktiga besluten, särskilt de som innebar förändringar i arkitekturen för systemet har skjutits upp till när teamet hade mer kunskap om subjektet och därför var mer säker i beslutsprocessen. Denna princip visade sig vara väldigt effektiv då de undvek att ta hastiga beslut.
Delivering fast
Teamet har delat upp projektet i mindre iterationer mellan tre till fyra veckor och har därav möjliggjort snabbare leveranser av funktioner, även delvis avslutade. Således var det möjligt att få snabbare kundåterkoppling och att de fick ha en högre grad av engagemang i
utvecklingen av produkten.
Respect people
Vid alla mötena där de planerar framtida versioner av programvara så har alla teammedlemmar fått göra sig hörda. De har även tagit hänsyn till allas åsikter vid de slutgiltiga besluten och detta gör att alla har förbundit sig till estimeringarna.
Optimize the whole
Det belystes i teamet genom vikten av att förstå företagets processer. De utförde workshops med andra team för att klargöra flera frågor om hur mjukvaran användes i praktiken. Således fick de användbar kunskap för att utvärdera effekter av nya funktioner på interna och externa kunder. Resultatet av denna princip var en förbättring av användbarhet och bättre acceptans av kunder.
De använde sig av flera olika verktyg gällande att hantera processer för mjukvaruutveckling. De verktyg som användes i teamet för fallstudien var:
1. Jira:
Användes för registrering och övervakning av krav, tidsregistrering och grafer för att spåra utvecklingen av versioner.
2. Confluence:
Användes för att dokumentera funktionella och tekniska detaljer om systemet som är utvecklade av företaget. Det är ett delat system där alla teammedlemmar har tillgång till redigering av dokument.
Varje dag registrerar teammedlemmarna arbetstid. Varje gång registrering är obligatoriskt kopplad till en uppgift, vilket kan vara en förbättring, en korrigering av fel, ett möte etc. Var och en av dessa uppgifter är i sin tur kopplad till en viss komponent. För närvarande är komponenterna indelade i:
16 1. Produkt: Grupperar alla timmar som används på uppgifter som tillför värde till
produkten, t.ex. förbättringar och nya funktioner, utveckling av automatiserade test, etc.
2. Buggar: Den tid som spenderas på korrigering av avvikelser.
3. Support: Timmar registreras i support-aktiviteter som ges till andra team.
4. Ledning: Alla uppgifter relaterade till projektledning: möten, planering, dagligen möten etc.
17
3. Metod
I detta avsnitt redogörs för de utgångspunkter och tillvägagångssätt som valts för studien. De olika delarna har skrivits med stöd i litteratur av Oates (2012) och Bryman (2011).
3.1 Metodologisk utgångspunkt
Baserat på studiens syfte har vi valt att använda oss av kvalitativ forskning baserad på
observation och intervjuer. Detta eftersom en kvantitativ metod inte hade varit lämplig för att uppnå vårt syfte då respondenterna endast var fem personer. Syftet är att skapa en djupare förståelse för verksamhetens arbetssätt och med hjälp av personalens egna formuleringar kan det förmedlas en bild av hur de tycker att metoder används i det dagliga arbetet. Enligt Bryman (2011) är en kvalitativ forskning induktiv, tolkande och konstruktionistisk. Vikten läggs på ord och inte kvantifiering (Bryman, 2011). Den kvalitativa metoden tillåter också flexibilitet då det gäller att lägga till eller omformulera frågor under arbetets gång. Studiens observation utfördes för att undersöka verksamhetens aktuella arbetssätt där vi
uppmärksammar intryck, händelser, stämning och interaktion mellan de anställda.
Observationen användes sedan för att fördjupa beskrivningen av verksamhetens arbetssätt samt för att illustrera konkreta scenarios. Genom dessa kunde vi bilda egna uppfattningar om personalens arbetssätt. Intervjuerna låg till grund för att få kännedom om vad personalen anser om sitt arbetssätt men även för att ge oss större förståelse för deras dagliga arbete.
3.2 Ostrukturerad intervju
Enligt Oates (2012) har intervjuaren mindre kontroll vid ostrukturerade intervjuer. Det är respondenterna som ska tala fritt och utveckla sina tankar. Intervjuaren ska endast reagera på de punkter som är värda en uppföljningsfråga (Bryman 2011). Den ostrukturerade intervjun ansågs lämplig som en inledande intervju med den ansvariga personen på verksamheten. Intervjun bidrog med en förberedande förståelse för verksamhetens arbetssätt. Förberedelsen inför denna intervju bestod av att förbereda ett PM som enligt Bryman (2011) ska fungera som minneshjälp vid behandlingen av ett antal teman under intervjun. De teman var; arbetsrutiner, möten, metodanvändning och verktyg. Intervjun skedde på verksamheten i ett bokat mötesrum. På bordet hade vi våra datorer och medan intervjupersonen pratade
antecknade vi. Denna intervju gav detaljerad information om verksamheten vilket bidrog till en större förståelse, den spelades in och transkriberades. Under intervjun fick vi även
kännedom om personalen på verksamheten. Baserat på materialet som samlades in under denna intervju formulerades frågorna i de semistrukturerade intervjuerna.
18
3.3 Observation
Observationen utfördes i rollerna, som enligt Oates (2012) kallas, “complete observer”. Detta innebär att vi inte deltar i gruppens möte utan vi observerar endast det som sker. Oates (2012) förespråkar ett antal punkter som bör följas vid en observation; den första punkten är att personalen bör informeras om varför de observeras. Som observatör ska man förklara att observationen är till för att förstå hur arbetet fungerar och inte för att bedöma personalens arbetssätt (Oates 2012). För oss som forskare var det av stor betydelse att belysa att vi inte är på verksamheten för att hitta “fel” i hur de jobbar. Oates (2012) menar också att det är bra att informera respondenterna innan om varaktigheten av observationer och intervjuer samt vad syftet är.
Detta gjordes muntligt men även i samtyckesformulären som gavs till varje intervjuperson. Ännu en punkt som Oates (2012) nämner är att planera tidpunkten för observationen när det är praktiskt möjligt för studieobjektet. Förberedelsen inför observationen skedde på så sätt att det skrevs upp punkter som var relevanta för studien. Dessa punkter hade vi i bakhuvudet under genomförandet av undersökningen. Punkterna var:
- Hur arbetar de?
- Vad gör de? Hur gör de det? - Vad händer? Hur händer det?
- Hur interagerar personalen med varandra?
Observationstillfället vi var med på var ett sprintplaneringsmöte och passade utmärkt för att utföra en observation på. Den skedde på de anställdas arbetsplats i samma mötesrum där den ostrukturerade intervjun hölls. Plats och tid valdes av koordinatorn. Under
sprintplaneringsmötet satt vi med gruppen utan att interagera med dem och påverka
processen. Observationen utfördes i det bokade mötesrummet, runt ett bord. I rummet fanns en stor TV där den som höll i mötet visade upp deras Kanban tavla på vilken deras aktuella arbetsuppgifter presenterades. Under mötet planerade de anställda vad de skulle göra under de nästkommande 14 dagarna. Här observerades hur mötet var strukturerat, tidsramen på mötet, kroppsspråk, interaktion mellan de anställda, vad som diskuteras, beteenden samt
delaktigheten. Mötet pågick i drygt 50 minuter. Under observationen utfördes det som Bryman (2011) kallar för Fullständiga fältanteckningar. Detta innebär att vi antecknade utförligt och detaljerat. Första intryck samt känslomässiga upplevelser noterades också.
19
3.4 Semi-strukturerade intervjuer
För uppsatsen valdes även semi-strukturerade intervjuer. Syftet med dessa intervjuer var att skapa en djupare förståelse för hur personalen arbetar och därför ansågs detta
tillvägagångssätt mest lämpligt. Att ha färdiga frågor som i en strukturerad intervju skulle begränsa respondenten i att tala fritt och en ostrukturerad intervju, som tenderar att likna ett vanligt samtal (Bryman 2011), skulle i detta fall kunna leda konversationen bort från det egentliga syftet. Med den valda intervjuformen hade vi friheten att lägga till eller
omformulera frågor under intervjuns gång vilket är en fördel då det kan dyka upp nya frågor under intervjuerna. Förberedelsen inför denna intervju bestod av att skapa en uppsättning av allmänna frågeställningar som enligt Bryman (2011) kallas intervjuguide. Intervjufrågorna baserades på materialet som samlades in under den ostrukturerade intervjun, observationen samt Leans praktiker och principer. Utifrån observationen och den ostrukturerade intervjun bildades en uppfattning hos oss av verksamhetens arbetssätt. När intervjufrågorna utformades hade vi i åtanke att få en så pass stor kunskap om verksamhetens arbetssätt som möjligt utifrån intervjupersonernas perspektiv. Av denna anledning var majoriteten av frågorna
utformades på så sätt att intervjupersonerna skulle kunna uttrycka egna tankar och reflektioner istället för att ha frågor som kunde besvaras med ja eller nej.
Det förekom följdfrågor i alla intervjuer då respondenterna tog upp intressanta synpunkter som vi ville veta mer om. Frågorna ställdes inte alltid i den ordning som de var utformade att ställas, detta för att anpassa intervjun till respondenternas svar.
Intervjuerna som utfördes ägde rum på de anställdas arbetsplats i samma mötesrum där den ostrukturerade intervjun samt observationen skedde. Intervjun utfördes över ett bord där respondenten satt på ena sidan och vi satt på den andra. På bordet placerades våra datorer samt en extern mikrofon som var uppkopplad till ett röstinspelningsprogram på datorn. Med oss hade vi ett papper med intervjufrågorna där en av oss höll i intervjun. Den andra
antecknade vad intervjupersonen sa för att underlätta transkriberingen i efterhand. Samtliga intervjuer började med allmänt småprat för att få en avslappnad stämning. Innan intervjun satte igång delade vi även ut ett samtyckesformulär som respondenterna fick läsa och skriva under. Där fanns det bland annat information om vår studie. Under avsnittet 5. Etik redogör vi mer ingående om samtyckesformulären.
20
3.5 Urval av respondenter
Det totala urvalet av respondenter var sju personer varav två tackade nej till att intervjuas. Detta ledde till ett bortfall på två personer och endast fem personer deltog i studien. Samtliga personer blev tillfrågade om de var intresserade av att delta i en intervju under vårt första besök på verksamheten. Längden på de semi-strukturerade intervjuerna varierade från intervju till intervju. Intervjun med S tog 13 minuter, D1 tog 23 minuter, D2 tog 13 minuter och D3 tog 10 minuter. Den ostrukturerade intervjun med C tog 53 minuter. Informanterna hade alla en kandidatexamen inom systemvetenskap på tre år och var i åldrarna från 28 år till 52 år.
3.6 Val av organisation
Denna verksamhet valdes baserat på att de inte arbetade utifrån en specifik uttalad metod utan de använde sig av delar från olika systemutvecklingsmetoder som passade deras behov. Samt att Lean är en återkommande metod som används inom hela Region Örebro län. Där de använder Lean kring vanligt förbättringsarbete för att arbeta smidigare och smartare för att minska väntetider bland annat (Region Örebro län, 2020).
3.6 Sökvägar
Sökningen av artiklarna som används i studien skedde via Örebro universitetsbiblioteks databaser Web of Science och Scopus. Vi började med att göra sökningar med sökorden: Lean och Lean development men det gav oss för breda sökresultat och vi specificerade oss
ytterligare i sökningarna. Vi använde de engelska sökorden: Lean software development, Lean software development principles, för att få ett mer specifikt urval av artiklar. Där valdes artiklar som förklarar praktiker och principer inom Lean, dessa var skrivna av Razzak (2016) och Wang et al. (2012). Då samtliga artiklar är granskade och publicerade i tidskrifter anses de vara pålitliga. För att hitta artiklar som berör fältstudier kring LSD gjordes sökningar med sökorden: Lean Software development practices, Lean Software development principles, Lean Software development case study. Vi fann två artiklar som redovisade resultatet av team som implementerat LSD, dessa var författade av Middleton & Joyce (2012) samt Misaghi & Bosnic (2014) . Artiklar med senast publiceringsår prioriterades för att få den senaste forskningen inom det området.
21
4. Bearbetning och analys av data
Under detta avsnitt redogörs för analysen av intervjuerna samt observationen. För analys av datamaterialet används Oates (2012) som vägledning.
4.1 Intervjuer
Enligt Oates (2012) är det betydligt lättare att söka igenom och analysera data när den är nedskriven därav genomfördes transkriberingar efter att intervjuerna var färdiga.
Anteckningarna som fördes under intervjuerna underlättade transkriberingarna då vi hade antecknat det övergripande av vad intervjupersonerna sagt. Intervjuerna utfördes via personlig kommunikation den 29 November 2019.
Transkriberingarna analyserades enligt tematisk analys (Oates 2012). Tematisk analys är en metod som används för att identifiera nyckelord och kategorisera genom teman. Enligt Oates (2012) kan man utgå ifrån två tillvägagångssätt för att hitta teman; dessa metoder kallas induktiv- och deduktiv analys. För studien valdes den deduktiva analysen, här utgår man från en existerande teori för att identifiera teman. Då teman valdes ut utgick vi från Leans
praktiker och principer, vilket är studiens teori, dock menar Oates (2012) att man inte ska vara låst till en given teori då detta kan hindra att andra intressanta teman identifieras i texten. Av denna anledning skedde analysen av intervjuerna och observationen med en grundtanke i Leans principer och praktiker och samtidigt som vi var öppna för att identifiera andra teman som inte har en koppling till den valda teorin.
Nyckelord valdes ut genom att varje intervjutext lästes flertal gånger. Utifrån det valdes nyckelord för vad den intervjupersonen berörde. Därefter lades de identifierade nyckelorden under teman som tidigare identifierats. En del nyckelord passade inte in under de teman som funnits först. Därför fick vi komma på nya teman som var lämpliga för vår undersökning. På så vis kunde vi få en överblick över vad respondenterna hade pratat om för ämnen via teman. De identifierade teman var:
- Arbetssätt - Morgonmöten - Optimering - Kunskap - Kvalite - Beslutstagning - Leverera snabbt - Respektera folk
22 - Eliminera slöseri
- Estimering/Ledtid
De teman som identifierades utifrån teorin var; optimering, kunskap, kvalitet, beslutstagning, leverera snabbt, respektera folk, eliminera slöseri, samt estimering/ledtid. De sju förstnämnda teman identifierades utifrån Leans sju praktiker då principen Eliminate waste blev temat eliminera slöseri, Build Quality In blev kvalite, Create Knowledge blev kunskap, Defer
Commitment blev beslutstagning, Respect People blev respektera folk, Deliver Fast blev
leverera snabbt, Optimize The Whole blev Optimering.
Teman som definierades i efterhand var; Arbetssätt och morgonmöten. Temat arbetssätt identifierades utifrån observationen som utfördes, det var under sprintplaneringsmötet som denna identifierades då vi fick större förståelse för deras arbetssätt. Morgonmöten
identifierades genom att detta var ett återkommande ämne på intervjuerna samt att morgonmöten är en del inom Lean.
4.2 Analys av observation
Observationen analyserades i två skeden. Det första skedet var innan intervjuerna utfördes. Här skedde en översiktlig analys av observationen för att få en grundläggande bakgrund till utformningen av de semistrukturerade intervjufrågorna. Här reflekterade vi över det insamlade datamaterialet. Flera frågor grundades på det insamlade datamaterialet som behövde klargöras för att få en bättre förståelse. Det andra analys-skedet skedde efter
intervjuerna. Observationen analyserades genom samma metod som intervjuerna, skillnaden här var att vi utgick från våra egna anteckningar när teman valdes ut.
De identifierade teman var: - Mötesstruktur - Beteenden - Interaktion
- Metodanvändning
Temat mötesstruktur identifierades baserat på det vi uppmärksammade av hur mötet är strukturerat under observationen. Vi uppmärksammade hur de tillämpade olika typer av verktyg inom olika metoder och begrepp inom dessa metoder och därav identifierades temat metodanvändning. Temat beteenden identifierades baserat på de olika beteenden som upplevdes under observationen. Temat interaktion identifierades utifrån att vi
23
4.2.1 Tillförlitlighet
Enligt Oates (2012) finns tre kriterier för att stärka tillförlitligheten av observationer, dessa är:
Citeringar, triangulation och reflexivitet. För att observationen ska uppnå så hög
tillförlitlighet som möjligt bör följande kriterier uppfyllas;
Citeringar
För att försäkra läsarna att man faktiskt har hört observanterna uttrycka sig om något bör citat användas (Oates 2012). För att uppnå detta kriterium citerade vi personerna som
observerades.
Triangulation
För att vara säker på att den data som samlats in under en observation är tolkad på rätt sätt ska den bekräftas av de som har observerats (Oates, 2012). Detta kriterium uppfylldes genom att intervjufrågorna baserades på observationerna. På detta sätt kunde vi få ökad insyn på våra observationer.
Reflexivitet
Detta kriterium innebär att forskarna inte ska låta datainsamlingen påverkas av personliga värderingar. Vi kan inte garantera att vi inte har påverkats av våra värderingar under
processen, i det avseendet har det skett omedvetet. Vi anser att vi har agerat i god tro och på så sätt minimerat risken för att påverkas av våra värderingar.
24
5. Etik
För studien utfördes ingen etikprövning eftersom vi inte hanterade särskilt känsliga
personuppgifter. Vi utformade samtyckesformulär och studerade vikten av etik i Oates (2012). Studien har utgått från de fyra grundläggande etiska principerna; informations-, samtyckes, konfidentialitets-, och nyttjandekravet (Bryman 2011). Informationskravet uppfylldes genom att vi beskrev studiens syfte samt de moment som ingår i undersökningen i informationsdelen som återfinns i samtyckesblanketten, vilken gavs till de medverkande innan undersökningarna påbörjades. Innan datainsamlingen satte igång fick de medverkande skriva på en
samtyckesblankett, utifrån vilken samtyckeskravet uppfylldes. Med sin underskrift godkände personerna sin medverkan i vår studie. Vidare godkände de att de hade förstått att; deltagandet är helt frivilligt samt att de har rätten att ångra sitt deltagande när som helst, att de kan välja att avstå att svara på en viss fråga samt att dokumentationen av intervjuer skedde via
ljudinspelning och anteckningar.
Under rubriken “Hantering av personuppgifter” i samtyckesblanketten förklarades att deltagarnas personuppgifter hanteras enligt GDPR och att den informationen som samlas in kommer att hållas anonymiserad. Konfidentialitetskravet har varit av stor betydelse för studien eftersom verksamheten samt rollerna på avdelningen är unika inom regionen. Det fanns en risk att läsare identifierar vilken verksamhet samt vilka personerna är. För att minimera risken för detta har vi valt att benämna verksamheten som “verksamhet” och “organisation” i uppsatsen istället för att skriva ut vilken avdelning det handlar om. Vidare benämns arbetstjänsterna med ett annat namn än de egentliga titlarna som personerna har. All information som är personbunden har vi valt att anonymisera genom att inte skriva deltagarnas namn i transkriberingarna eller i uppsatsen. För att anonymisera ytterligare har vi valt att inte nämna vilket kön personerna har. Kön är dessutom inte relevant för denna studie. Citaten som presenteras i resultatavsnittet kommer refereras till rollerna i kodad form som kan ses i tabellen Anonymiserade roller.
25
Roller Roller i kodad form
Koordinator C
Systemförvaltare S
Systemutvecklare 1 D1
Systemutvecklare 2 D2
Systemutvecklare 3 D3
Tabell 1: Anonymiserade roller
Koordinator blir ett C i kodad form utifrån det engelska ordet Coordinator.
Systemförvaltare blir ett S. Systemutvecklare 1, 2 och 3 kodas till D1, D2 och D3 utifrån engelskans Developer.
Avslutningsvis uppfylls nyttjandekravet genom att det insamlade materialet används för forskningsändamålet i denna studie.
26
5.1 Forskarnas roll
För oss som forskare har det varit av stor vikt att ha en moralisk integritet. Enligt Oates (2012) görs detta genom att behandla respondenterna med värdighet samt genom att vara professionell, artig och neutral. Under intervjuerna har vi försökt att ha ett gott och
respektfullt uppträdande mot respondenterna. Vi har även visat intresse för deras svar genom att ställa följdfrågor. En annan aspekt som har varit viktig för oss var att skapa en atmosfär av förståelse till intervjupersonen. Enligt Jacobsen (2017) görs detta genom att komma med bekräftande signaler med jämna mellanrum. Det var också viktigt för oss att försöka vara så oberoende som möjligt och upprätthålla en professionell distans till intervjupersonerna. Slutligen har vi valt att inte värdera presentationen av resultatet i studien utan med hjälp av beskrivningar av det insamlade datamaterialet låter vi resultaten tala för sig.
En av oss skribenter är anställd inom samma organisation som studien är utförd på. Då det är separata verksamheter som inte har koppling till varandra har det inte påverkat den
professionella distansen som vi ville åstadkomma. Eftersom det är två separata verksamheter utan koppling till varandra har det inte varit en anledning till att ifrågasätta opartiskheten under denna studies gång.
27
6. Resultat & analys
För att i studien skapa större förståelse för verksamhetens arbetssätt har Figur 1 “Verksamhetens arbetssätt” infogats nedan. Vidare följer en redogörelse för
intervjupersonernas arbetsuppgifter baserat på vad de själva har berättat under intervjuerna. I detta avsnitt benämner vi rubrikerna efter de teman som hittades under analysen av det insamlade datamaterialet. Dessa teman togs upp under avsnittet 4.1 Intervjuer. I avsnittet tas även analysen av observationen upp.
6.1 Arbetsmodell
Figur 4 - Verksamhetens arbetssätt
Baserat på våra intervjuer och observation fick vi en bild av hur verksamheten jobbar enligt Figur 4. Vår tolkning av deras arbetssätt är att det börjar med att kunden fyller i en blankett med önskemål och skickar till sin verksamhetsrepresentant. Varje verksamhet har en representant som man skickar in sina önskemål till. Detta för att inte IT-avdelningen ska behöva prioritera vilka ärenden som är viktigast för verksamheten. Representanten skriver sedan i en excel fil vad kunden vill ha och prioriterar till en så kallad bruttolista. Bruttolistan är en lista där verksamhetsrepresentanten lägger in alla önskemål utifrån blanketterna som kommer in. Man prioriterar dessa så att IT-avdelningen får veta vilka ärenden som är högst prioriterade. IT-avdelningen går sedan igenom bruttolistan på deras sprintplaneringsmöte som hålls varje fjortonde dag där de tidsestimerar enligt en t-shirt modell (Figur 5 T-shirt
modellen). De väljer även att sätta olika färger på Kanban korten i Kanban tavlan för att
markera ut supportärenden/förvaltning, forskningsuttag, nyutveckling eller vidareutveckling. Efter att IT-avdelningen har estimerat klart återkopplar de till kunden kring
tidsestimeringen. Därefter går jobben in på en nettolista vilket är en lista med IT-avdelningens alla uppdrag där de är tidsestimerade och prioriterade. På
28 som inte är gjort från föregående sprint läggs över till nästa sprint. Sprintarna estimeras
utifrån Scrumpoäng och vanliga timmar. Denna planering sker i en digital Kanban tavla. Om ett uppdrag är klart flyttas det till DoD (Definition of Done) vilket är en Kolumn i Kanban tavlan. Om uppdraget inte är klart läggs det på mer timmar och det ligger kvar till nästa sprint. De har även morgonmöten tre dagar i veckan (Tisdag, Onsdag, Torsdag) i en halvtimme där de träffas och går igenom tavlan och ställer dessa frågor:
Vad gjorde jag igår? Vad ska jag göra idag? Detta hindrar mig från att komma vidare. Där pratar de mycket om hur de kan hjälpa varandra för att komma framåt i jobben och får lägesuppdatering kring allas case.
Figur 5 - T-shirt modellen
6.2 Arbetssätt
Under intervjuerna frågade vi respondenterna hur de definierar sitt arbetssätt. Utifrån deras svar ser vi att de inte har en klar definition av vad deras arbetssätt är. Detta var deras svar:
“Vi kallar den för Kanban board och att vi jobbar med Kanban, men det är en blandning mer av Scrum och Kanban.”- D1
“Det är väl en blandning mellan Scrum och Kanban...Scrumban aktigt, vi är ganska flexibla vi tillämpar ju liksom inte allt fullt ut. Våra dagliga möten är oftast längre än 15 minuter vilket man brukar ha.” - D2
“Jaaa..väldigt Agil tycker jag nog att den är, vi sitter ganska mycket direkt mot en kund och prata om det som krävs...så att man kommer framåt hela tiden och tänker i nya banor.” - D3
29
“Vi har inte riktigt nytta av det arbetssättet som vi har och på det sättet vi skattar och dokumenterar enligt mina behov och jag har inte haft tid eller ork att ändra det här under den här resan som jag har haft. Men det skulle behövas göras ett omtag. Man kan uttrycka att vi jobbar Agilt men håller fast vid gamla arbetssätt och metoder och vi borde kritiskt granska arbetssättet och anpassa det mer än vad vi gör” - S
Respondenterna påstår att de jobbar enligt Scrum och Kanban, däremot visar det insamlade datamaterialet att verksamheten endast använder sig av Scrum begreppet Definition of done i sin Kanban tavla. Detta uppmärksammades under observationen. Verksamheten använder sig inte heller av Scrum-roller som till exempel Scrummaster.
“Jag vet faktiskt inte, jag har ingen koll men C är certifierad Scrummaster, men sen om C har den rollen direkt eller indirekt det vet jag inte.” - D2
“C håller i de här sprintplaneringsmötena men vi har inga roller tilldelade så det skulle nog faktiskt bidra i den här gruppen.” - S
“C är som man brukar kalla produktägare, fast man kallar inte det här utan C är väl mer Scrummaster men hen är vad jag skulle säga produktägare. C har
verksamhetskontakt, kontakt med beställare och sen prioriterar och delar ut de till oss.” - D1
Intervjuperson S uttrycker vad hen anser är bristfälligt med verksamhetens nuvarande arbetssätt. Personen uttrycker att det är dålig återkoppling från beställarna av systemet. Av denna anledning kan projekt inte markeras som klara i verksamhetens Kanban tavla:
Jag känner ibland att jag saknar definition som brukar förekomma i dom metoderna definition of done, asså vi får ingen tydligt budskap från verksamheten. När dom upplever att deras beställning är färdig..så att säga...och då leder det till att olika beställningar ligger kvar i vår board väldigt länge och byggs på istället för avslutas och så.” - S
30 Utifrån detta kan det konstateras ännu en gång att de saknar en tydlig definition av vad deras arbetssätt är. S upplever inget tydligt budskap från verksamheten och det leder till att det inte blir tydligt vad som är klart och inte i deras Kanban tavla.
6.3 Morgonmöten
Det insamlade datamaterialet påvisar att verksamheten definierar sina morgonmöten som
Scrummöten. Det visar även att mötena är inplanerade tre gånger i veckan och de ska vara 30
minuter långa. Intervjupersonerna D1 och D2 nämner att dessa möten som är inplanerade inte alltid blir av och blir oftast längre än vad de planerat:
“Vi har dem inbokade tre gånger i veckan men det är sällan vi har tre gånger i veckan för ibland har vi inget och säga och då har vi inget möte så det kanske blir mer två gånger i veckan.” - D1
“Vi har tre gånger i veckan men dom blir väldigt långa, de är oftast en halvtimma så det är ganska mycket tid som går åt, det är väl en sak vi skulle kunna förändra” - D2
Enligt metoden Scrum ska ett Scrummöte hållas varje dag och det ska vara i 15 minuter (Björkholm & Brattberg, 2018). Utifrån respondenternas svar verkar inte varaktigheten stämma överens med den tänkta tiden.
31
6.4 Eliminera slöseri
Under principen Eliminate waste som skrevs om ovan nämndes att onödiga möten är en typ av slöseri. Utifrån det D1 beskriver är de möten verksamheten har idag för långa vilket innebär att tid går till spillo då tiden inte används effektivt. Detta är det principen eliminate waste innebär, att identifiera saker som kan förbättras för att öka effektiviteten i det dagliga arbetet. Även under observationen av deras sprintplaneringsmöte fanns det tecken på att mötena behöver effektiviseras. Nedan följer en analys av observationen:
Mötet började med att C skrev in ärenden som inte hade hunnits med innan. Vi informerades om att mötet skulle vara 30 minuter långt men det drogs ut till ca. 50 minuter. Gruppmedlemmarna gick flertal gånger ifrån ämnet och börja prata om andra saker som inte hörde till arbetet vilket är en bidragande faktor till att mötet drog ut på tiden. C gav ordet till en utvecklare i taget och frågade dem hur de låg till i processen. Ordningen följdes inte här, C gick vidare från en person till den andra för att sedan komma tillbaka till personen som redan hade haft ordet. C stannade upp vid ett tillfälle och frågade sig “har vi gått igenom alla de här nu?...ja just den var ju klar”. Vid ett tillfälle blev en anställd som inte var med på mötet inropad för att svara på en fråga som de andra undrade över. Kanban tavlan visades på en stor tv och utifrån detta sågs det vad lapparna var estimerade till från början. Det sågs också att de hade tagit längre tid när C frågade utvecklarna hur de låg till. Man kunde även se att vissa lappar var startade. Avslutningsvis var stämningen avslappnad då gruppmedlemmarna skämtade, skrattade och satt väldigt avspänt.
Utifrån det insamlade datamaterialet från observationen kan vi notera upprepande tillfällen där personalen kommer ifrån ämnet. Mötet tycktes även sakna mötesstruktur då de inte verkade ha en tydlig plan som mötet följde.
Under intervjun med D1 så förklarar hen hur de applicerar principen eliminate waste i praktiken.
“Eliminera slöseri, ja det får man av de här morgonmötena och att man har
planeringen då kan man jämna ut på de här morgonmötena typ: kan någon ta den här, jag hinner inte riktigt med den. Det är ju bra när man ändå har det här team tänket för då kan man ju hjälpas åt”.
32 Utifrån D1s svar så skiljer det sig från vad som upplevdes under observationen. Dock påvisar de övriga svaren kring morgonmöten från de övriga respondenterna att de upplever att de sällan håller tiden och upplevs allmänt oregelbundna (se punkt 6.3 Morgonmöten).
6.5 Optimering
Enligt principen Optimize the Whole är det kortsiktigt lönsamt att låta en person bli expert på ett område och låta den personen göra arbetsuppgifter den är bäst på. Däremot minskar detta flexibiliteten på lång sikt. Det ökar även risken för att personen blir en flaskhals. När
arbetsuppgifter delas ut på verksamheten baseras det på medarbetarnas kunskaper inom det området:
“(...) om det är nånting man har jobbat med då kanske man får ta de i första hand, i och med att du är redan insatt i det än att någon ny ska komma hela tiden och försöka lära sig.”
- D2
Även under intervjun med C lyftes denna punkt. Personen menar att verksamheten anser att det är bättre att ha uppdelade arbetsområden istället för att varje medarbetare ska känna till de olika områdena:
“Alla ska inte kunna allt utan det är bättre att en person kan sätta sig in i ett case till exempel. Då får man egentligen jobba från axel till karta för du stagear och hittar data, du modellerar data, du bygger rapporten. Du bygger hela lösningen och sen dokumenterar du.” - C
Enligt Optimize the whole är det sårbart och ineffektivt för en verksamhet om inte samtliga utvecklare har kunskaper inom alla områden. Till exempel om en anställd slutar eller är frånvarande från arbetet en längre period så leder det till att de andra utvecklarna inte kan utföra den personens arbetsuppgifter, vår tolkning av detta är att det kan stanna upp hela utvecklingsprocessen.
Under observationen uppmärksammade vi att utvecklarna var oeniga gällande fördelning av uppdrag. Den ena utvecklaren ansåg att den andra utvecklaren var mer lämplig för det uppdraget då den kunde det området bättre. Detta förtydligar det vi tidigare nämnt om att det gynnar verksamheten att samtliga i teamet kan de olika områdena.
33
6.6 Kunskap
I principen Creating knowledge tas det upp att det är viktigt att lära upp personal från början då man på så sätt undgår återlärning i framtiden. Att lära upp personalen är en viktig
investering som gynnar företaget, även om det till en början är en kostnad. Personer på
företaget som besitter kunskap ansvarar för att lära upp de som inte har kunskap. Man betonar även vikten av att jobba tillsammans då detta överför kunskap. Under intervjun med C
framkom det att verksamheten anpassar sitt arbetssätt efter personalen istället för att lära dem arbetsmetoderna som används på arbetsplatsen:
“(...) vi fick in två nya systemutvecklare och de hade ideer om hur de ville jobba. Då har vi ändrat lite under hösten för de är inte så vana vid det som vi gör här, då anpassar vi lite för de skulle lättare komma in i tjänsten”
- C
6.7 Kvalitet
Vi frågade intervjupersonerna vad de hade för koppling till principen build quality in i deras dagliga arbete och utifrån deras svar är alla intervjupersoner överens om att det är viktigt att ha bra kvalite. De förklarar även att de som de utvecklar håller bra kvalitet men att de gör prioriteringar kring var de lägger den högsta kvaliteten.
“Jag tycker att det vi gör här håller bra kvalitet men sen så eftersom vi jobbar med det vi gör så är ju vi och pillar i alla källsystem och där har man en del önskemål oså. Så jag tycker väl inte att alla system som vi köper in och sådär håller så höga kvaliteter sen berors det ju också på vilket system det är, är det vårdsystemet som är
livsnödvändigt eller till den vanliga produktionen på sjukhuset så där ställs det ju väldigt höga krav och därav hög kvalite. Men sen lite mindre system som man
fortfarande vill ha data ifrån kanske inte är lika högt prioriterade så där tar man bara in nått som täcker det man behöver för stunden. “ – D3
“Det är beroende på om vi har patientdata i just det projektet, men jag tycker ändå att vi inte krånglar till saker. Vi håller inte på och slänger in saker bara för att det är hippt. Massor med javascript och ramverk och såna saker. Man håller liksom på en bra nivå, man utnyttjar resurserna bra istället för att göra massa flashiga saker. Vi gör kanske inte de coolaste sakerna men jag tror ändå att vi använder resurserna bra.” - D2
34
6.8 Beslutstagning
Gällande beslutstagning och att vänta med beslut så hade intervjupersonerna D3 och D2 olika syn på principen “Postpone commitments/Defer commitment”. D3 ansåg att de tar beslut snabbt medans D2 anser att de väntar med beslut.
“Jag tycker att vi fattar beslut ganska fort istället tänker jag. Det kanske blir fel men då får man uppskatta om, det kanske är ett man kan jobba på.” - D3
“Vänta med beslut, ja men det tycker jag att vi gör faktiskt.”- D2
6.9 Leverera snabbt
Verksamheten är överens om att deras mål är att leverera snabbt.
“Leverera snabbt, det är klart att man vill det liksom..” - D1
“Leverera snabbt, man vill inte att det ska ta alltför lång tid utan när man väl satt igång med någonting så är det ju snabba puckar fram och tillbaka hela tiden för att få det gjort och det tycker jag funkar bra.” - D2
6.10 Respektera folk
Utifrån intervjuerna så var alla överens kring att man respekterade varandra och det upplevdes som en självklarhet. Under observationen på verksamhetens sprintplaneringsmöte vid
fördelning och prioritering av uppgifter så var de väldigt noga med att alla var överens kring prioriteringen och vem som skulle ta uppgiften tills de gick vidare till nästa.
35
6.11 Estimering/Ledtid
Det framkommer i samtliga intervjuer att systemutvecklarna inte följer upp sina tidsestimeringar:
“Det är väldigt sällan som när man går in i sprinten att man lägger en tidsplan som faktiskt håller.” - D2
“Vi följer upp mot vår förvaltningsbudget och förvaltningsplan för året. Gentemot budget men inte gentemot våra arbetade timmar” - S
“Jag har aldrig kollat nåt sånt där utfall mot vad jag faktiskt uppskattade eller vad jag trodde det skulle ta.” - D3
“ Nä och det har inte jag gjort på något annat ställe där jag har jobbat på.
Har aldrig haft uppföljning för om man nu ska tidsplanera och tidsuppskatta så måste man ju om det ska vara någon vits med det.. så tycker jag att man ska följa upp hur lång tid tog det i verkligheten så att man åtminstone skulle kunna bli bättre på det i framtiden. Nån sån uppföljning har man ju heller aldrig.“ - D1
Intervjupersonerna är överens om att de estimeringarna som görs idag aldrig följs upp och de har ingen vetskap om vad den egentliga ledtiden för utvecklingen slutade på. Baserat på materialet som samlades in under observationen såg vi att den tid som de olika Kanban lapparna hade estimerats till inte följdes. Systemutvecklarna gick över de estimerade
timmarna. Då verksamheten inte följer upp sina estimeringar kan de inte ta reda på varför det blev en missbedömd tidsuppskattning. De kan därav inte hålla koll på vad egentliga ledtiden för uppgifterna blir.
D1 kommenterar gällande estimering kring t-shirt modellen.
“(...)man får först räkna liksom Medium.. det ska va ungefär så många timmar då gör man ju iallafall omvägen via timmar och sen göra den omvägen hela tiden mellan timmar och det andra. Och det är egentligen inte så som det är tänkt utan om man inte ska använda sig utav timmar utan ska använda sig av tshirt storlekar eller någonting annat då är ju tanken att man vill bort från det från tim tänket..”
36 D1 menar om man ska tidsestimera baserat på ett annat sätt än timmar ska man inte koppla det till timmar överhuvudtaget. Tidsestimeringen ska istället bytas ut mot en metod som anses beskriva det bättre. D1 anser att T-shirt modellen inte byter ut tidsestimeringen baserat på timmar utan det blir istället ännu en estimering som verksamheten måste göra. Först måste de tänka i T-shirt storlekar och sedan omvandla det till timmar. Vidare kommenterar D1
tidsuppskattning och uttrycker svårighet vid tidsuppskattning då verksamheten får in förvaltningsuppdrag som inte är planerade under sprintarna:
“ Man jobbar ju inte uteslutande med de uppdrag man tar in utan det kan komma in
andra saker som är oplanerade och det gör ju att dom här planeringarna håller aldrig.. någonsin. Och det går ju inte att planera så därför tycker jag att det är så onödigt att lägga så mycket tid för att planera när man ändå vet att det inte ger
någonting för att det säger ändå ingenting om när det här är klart för det beror ju helt på hur mycket annat som kommer in så det är ganska tråkigt att sitta och planera för att överhuvudtaget så är det är bara gissningar hela tiden och det är ganska tråkigt jobb och att lägga mycket tid på någonting som man inte har någon nytta av känns bara onödigt…alltihopa.”
37
7. Diskussion
Syftet med studien var att undersöka hur verksamheten arbetar idag och om de arbetar efter några praktiker och principer inom LSD och utifrån det koppla iakttagelserna till tidigare fältstudier och Leans rekommendationer. I detta avsnitt diskuteras verksamhetens arbetssätt utifrån det framställda resultatet samt utifrån teorin och fältstudier som har presenterats under avsnittet 2. Lean.
7.1 Hur används Lean Software Development i praktiken baserat
på fallstudier?
Baserat på vad LSD förespråkar samt vad som fallstudierna presenterat så finns det
genomgående likheter samt skillnader med vårt studieobjekt. Verksamheten använder sig av Kanban tavla för att lägga till items, estimera och följa utvecklingens gång. Det som skiljer sig är att verksamheten använder sig av en digital Kanban tavla och inte en fysisk som fältstudien hos Middleton & Joyce (2012) använde sig av. Dock är principen att använda en Kanban tavla fortfarande densamma. Middleton & Joyce (2012) använde sig även av olika färger på Kanban korten för att indikera vad för typ av uppgift det handlade om eller
eventuella flaskhalsar (se figur 1 - Kanban kort-beskrivning). Verksamheten använde sig av ett liknande koncept, där de inte använde exakt de nyckelorden som Middleton & Joyce (2012) tillämpade utan de använde sig av olika färger på korten för att markera ut
supportärenden/förvaltning, forskningsuttag, nyutveckling eller vidareutveckling. Gällande estimering så skriver verksamheten endast in den uppskattade tiden och den egentliga tiden. Men ingen typ av uppföljning i form av ledtid för och mäta hur den uppskattade tiden gentemot den egentliga tiden blev. Middleton & Joyce (2012) mätte ledtiderna från att ett arbete kom in tills det var färdigt till kund för att mäta hur snabb och pålitlig leveransen var i antal arbetsdagar. Även Misaghi & Bosnic (2014) hade en typ av uppföljning kring den tid som teamet investerat under varje version i förbättringar och nya funktioner. De antydde på att det var en av de viktigaste indikationerna då uppgifterna från uppföljningarna gav mervärde till produkten.
Verksamheten beskriver att de använder sig av scrummöten/morgonmöten, tre gånger i veckan i 30 minuter. Utifrån vårt insamlade datamaterial så kom det fram att den egentliga tiden ofta blir längre än utsatt tid eller att mötet inte blir av alls. Middleton & Joyce (2012) hade daily standup där de varje morgon klockan 10:15 stod framför Kanban tavla och
kontrollerade om Kanban tavlan var korrekt, identifierade blockeringar, WIP/Flaskhalsar och gick igenom arbetet för dagen. Verksamhetens "scrummöten” är ursprungligen från metoden scrum men de har gjort en egen anpassning av metoden. Verksamheten ställer tre frågor under mötet: Vad gjorde jag igår? Vad ska jag göra idag? Detta hindrar mig från att komma vidare. De går även igenom hur de kan hjälpa varandra för att komma framåt i jobben och får
lägesuppdatering kring allas case. Det som skiljer sig här är framförallt möteslängden och antalet dagar för mötet. Mötenas huvudfokus är i stort sett detsamma, de vill veta nulägets
38 status och blockeringar som hindrar dem från att komma framåt i processen. Middleton & Joyce (2012) hade morgonmöten varje dag i 15 minuter medans verksamheten hade tre dagar i veckan i 30 minuter.
Från det insamlade datamaterialet så visar det på att verksamheten använder sig av en del utav Leans sju principer. I fallstudien hos Misaghi & Bosnic (2014) hade teamet tillämpat
Eliminate waste genom att endast engagera sig i en funktion åt gången samt att en från teamet
hade till uppgift att förvalta supportärenden medans resterande i teamet ägnade sig åt nyutveckling. Här handlar det om enligt Lean att ta bort ojämnheter, överbelastning och slöseri. Baserat på observationen hos verksamheten så visades det att det var ostrukturerat och den planerade tiden för mötet gick från 30 minuter till 50 minuter. Samt att utifrån intervjuer med verksamheten så tycks morgonmötet dra ut på tiden eller inte bli av alls. Men i intervju med D1 så berättar personen att under deras morgonmöten så planerar de ut uppgifter som berörd utvecklare inte hinner med. Baserat på vår observation samt det som D1 uttryckte kan vi inte fastställa att principen Eliminate Waste uppfylls.
I fallstudien som utfördes av Misaghi & Bosnic (2014) uppnåddes principen Create
Knowledge genom att alla teammedlemmar hade tillgång till produkten. Det användes även samarbetsverktyg där vem som helst kunde dokumentera. Verksamheten där vår studie utfördes använder sig av samarbetsverktyg såsom Kanban tavla. Wang, Conboy och Cawley (2012) påpekar i sin fallstudie att det som behövs för att skapa kunskap är en god
samarbetsförmåga. Förmågan att samarbeta med andra verkar finnas i verksamheten då alla anställda gav en positiv respons när de blev tillfrågade om samarbetsförmågan på
arbetsplatsen. Utifrån detta kan vi se att principen Create Knowledge uppfylls. Teamet i fallstudien av Misaghi & Bosnic (2014) uppnådde principen
Integration quality/Build quality in genom att använda sig av tester som är oberoende av
människans interaktion (automatiserade tester). Samt så implementerade de korrekt funktion in i processen från början. Verksamheten beskriver i intervjuer att de tycker att de har god kvalite i sin utveckling men att de gör prioriteringar kring var de lägger den högsta kvaliteten. De anpassar kvaliteten kring om det till exempel är ett vårdsystem som är livsnödvändigt och behöver hög kvalitet gentemot ett mindre system som inte innehåller patientdata. Principen
Build quality in handlar om att man ska säkerställa kvaliteten från början och inte vänta med
att göra tester i ett senare skede samt att åtgärda fel som uppstår omgående (Björkholm & Brattberg, 2018). Utifrån datamaterialet så följer inte verksamheten principen till fullo men har ett kvalitetstänk kring utvecklingen.
Principen Postpone Commitments (Defer commitment) uppnådde teamet i fallstudien av Misaghi & Bosnic (2014) genom att de väntade med alla viktiga beslut tills de hade
tillräckligt med kunskap och därav mer säkra i beslutsprocessen. Speciellt beslut som innebar förändringar i arkitekturen för systemet. Från det insamlade datamaterialet så visar det att verksamheten hade olika syn gällande principen postpone commitments. D3 ansåg att de fattade beslut relativt fort medans D2 ansåg att de väntade med beslut rätt länge. Därav kan det inte fastställas om verksamheten arbetar efter principen Postpone Commitments.
