Embed Size (px)
Citation preview
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
Examinator: Gunnar Klein
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.
Nyckelord: Lean, Lean Software development, Lean principles, Lean practises
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
Bilaga - Samtyckesblankett ............................................................................................................... 50
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.
Stort tack!
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
den färdiga programvaran släpps till kunden (Middleton & Joyce 2012).
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.
Figur 1 - Kanban kort-beskrivning
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
uppmärksammade hur verksamheten samverkade med varandra.
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å
sprintplaneringsmötena planeras jobben som ska göras i nästa sprint utifrån nettolista. Det
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”.
- D1
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.
“Att man respekterar varandra, det är ju lite självklarhet på något vis.” - D1
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.
39
Teamet i fallstudien av Misaghi & Bosnic (2014) uppnådde principen Deliver fast genom att
de delade upp projekten i mindre iterationer mellan tre till fyra veckor och därav möjliggjorde
snabbare leveranser och snabbare kundåterkoppling. Verksamheten arbetar även i projekt
uppdelade i mindre iterationer, men i två veckors iterationer. I intervjuerna med verksamheten
så är de överens om att deras mål är att leverera snabbt.
För att uppnå principen Respect people har teamet i Misaghi & Bosnic (2014) fallstudie gjort
så att vid alla möten där de planerar framtida versioner av systemet får alla i teamet göra sig
hörda. Samt att de har tagit hänsyn till allas åsikter vid de slutgiltiga besluten. Verksamheten
beskriver i intervjuerna, att respektera folk upplevdes som en självklarhet. Under
observationen av deras sprintplaneringsmöte visade verksamheten på tillämpning av respect
people då de var väldigt noga med att alla var överens kring prioritering och fördelning av
uppgifter.
Teamet i fallstudien av Misaghi & Bosnic (2014) uppnådde principen Optimize the whole
genom att belysa vikten av att förstå företagets processer. De använde sig av ett verktyg för att
registrera och övervaka krav, tidsregistrering, och grafer och ett verktyg för att dokumentera
funktionella och tekniska detaljer om systemet.
Enligt Leans princip Optimize the whole ska man inte låta en person att bli expert på ett
område för då ökar risken att den personen blir en flaskhals (Björkholm & Brattberg (2018).
Under vår intervju med C beskriver personen att de tycker att det är bättre att låta en person
jobba på ett case och bli bättre på de än att alla ska kunna jobba på det caset och få övergriplig
kunskap. Utifrån detta så implementerar inte verksamheten principen Optimize the whole.
Teamet i fallstudien av Middleton & Joyce (2012) mätte sina ledtider utifrån den totala
förflutna tid som gått från att en kund beställt en programvara tills att den färdiga
programvaran levereras till kund. Med ledtiden kunde de mäta hur snabbt programvaran
levererades till kunderna. I intervjuerna med verksamheten så beskriver de att de aldrig följer
upp sina estimeringar som de satt från början och har därav aldrig någon vetskap om vad den
egentliga utvecklingstiden slutade på. En del av eliminate waste är att minimera ledtiden
genom att bort ojämnheter, överbelastning och slöserier. Men utifrån att verksamheten inte
följer upp sina estimeringar så går inte ledtiden att mäta.
40
7.2 Metoddiskussion
Vi upplever att en kombination av ostrukturerad-, semi strukturerad intervju samt observation
var det rätta valet för vår studie och dess syfte. Däremot anser vi att det hade gynnat studien
att genomföra ytterligare en observation. Hade vi genomfört en till observation hade vi
möjligtvis kunnat uppfatta upprepande beteenden och vanor. På grund av arbetsbelastning på
verksamheten och vår tidsplanering hade vi endast möjlighet att utföra en observation.
En av intervjufrågorna som ställdes kan till viss mån upplevas som ledande för att vi ville få
information om kvaliteten på systemen som byggs i förhållande till budgeten. Exempelvis
upplever vi att frågan “Eftersom Region Örebro län är en statlig finansierad verksamhet så har
ni ju strama projektbudgetar att förhålla er till - tycker du att de systemen ni bygger ändå
håller bra kvalitet?” till viss del är en ledande fråga.
Eftersom vi inte har tidigare erfarenhet av att intervjua personer kände vi oss vid vissa
tillfällen tomma på följdfrågor när intervjupersonen inte gav ett detaljerat svar. Detta ledde till
att vi direkt gick vidare till nästa fråga. Vi upplever att vissa av intervjufrågorna inte bidrog
med relevant information för studien. Exempelvis frågorna “Har du jobbat på annan
arbetsplats inom offentlig sektor?”, “Hur länge har du arbetat på företaget?”.
Vi förväntade oss att de semistrukturerade intervjuerna skulle vara omkring 10-15 minuter
var. Två av intervjuerna blev ganska mycket längre än förväntats, den ena blev 23 minuter
och den andra blev 24 minuter. Detta bör vi haft i åtanke när informationen kring utförandet
av intervjuerna skrevs, då vi inte vill ta upp mer tid av deras dag än vad personalen blivit
informerade om. Det var till vår fördel att utföra dessa intervjuer på en fysisk plats med
personalen, istället för exempelvis telefonintervjuer. På detta sätt kunde vi interagera med
intervjupersonerna. Studiens resultat kan blivit påverkat till en viss del av den anledningen att
verksamheten endast har sju anställda, varav fem av dem deltog i studien. Då det finns ett
fåtal anställda begränsades vi i att ta del av olika synsätt och perspektiv.
Under litteratursökningen hade vi svårigheter att hitta fallstudier där systemutvecklingsteam
använder sig av LSD. De fallstudier som valdes var de som upplevdes kunna besvara vår
frågeställning till största mån.
Vid vår litteratursökning efter fallstudier hade vi svårigheter att hitta fallstudier där
systemutvecklingsteam använder sig utav LSD. De fallstudier vi slutligen valde att använda
oss av var de fallstudier som till största mån kunde besvara vår frågeställning.
Fallstudierna som används i undersökningen har utförts med målet att använda LSD till fullo
vilket kan ha påverkat studiens resultat där syftet har varit att undersöka hur LSD används i
praktiken. Däremot anser vi att vi har fått en bra bild av hur LSD praktiker och principer kan
realiseras av verksamheter och vi har kunnat koppla det till vår egen undersökning.
Under arbetets gång så ändrades vår frågeställning, så de informationsbrev och
samtyckesformulär som gavs ut till verksamheten har en tidigare upplaga av syfte och
41
frågeställning. Då studiens huvudfokus alltid har varit LSD ser vi ingen problematik med att
behålla originaldokumenten.
8. Slutsats och bidrag
Syftet med denna uppsats har varit att undersöka hur LSD används i praktiken baserat på
fallstudier genomförda av forskare, praktiker och principer som LSD förespråkar samt vår
egen fallstudie. Studien har identifierat att det finns ett antal likheter samt skillnader i sätten
som LSD implementeras i verksamheten. Som vi har sett i vår fallstudie så implementeras
principerna Deliver fast och Respect people, Create Knowledge och praktiken Kanban tavla.
Principerna Deliver fast och respect people implementeras genom att verksamheten har ett
gemensamt mål att leverera snabbt samt att visa hänsyn och respektera varandra. Principen
Create Knowledge implementerar verksamheten då de använder sig av praktiken Kanban
tavla och att alla i verksamheten har tillgång till den.
När det kommer till principen Eliminate waste så finns det stöd i det insamlade datamaterialet
att verksamheten inte implementerar denna princip. Genom att dra ut på morgonmöten eller
genom att inte ha möten alls gör verksamheten inte utrymme för att eliminera
störningsmoment i utvecklingsprocessen. Principen Build quality in har potentialen att
implementeras då verksamheten har ett tänk kring kvaliteten men inte implementerar det från
början. Som i fallstudien av Misaghi & Bosnic (2014) menar författarna att tester ska
implementeras i processen från början vilken verksamheten inte gör utan påpekar endast att de
gör prioriteringar var kvaliteten läggs. Verksamheten påpekade att olika system kräver olika
kvalitet och av den anledningen jobbar de som de gör. Det är oklart om principen Postpone
commitments implementeras. Vad som samlades in av datamaterialet visar att verksamheten
har olika åsikter på hur viktiga beslut fattas. Enligt fallstudien av Misaghi & Bosnic (2014)
samt vad LSD förespråkar om principen så ska man vänta med att fatta beslut till det finns
tillräckligt mycket kunskap. En av respondenterna tyckte att detta stämde in på deras arbete
medan en annan inte höll med. Principen följa upp ledtider implementeras inte i
verksamheten. Genom att verksamheten inte följer upp de estimeringar som görs så har de
inte kunskap om vad den egentliga arbetstiden hamnade på. Det förekommer även en del
praktiker som inte finns inom Lean, dessa praktiker är sprintplaneringsmöte.
8.1 Förslag på framtida forskning Under vår studie har det vuxit fram tankar kring vad som hade varit intressant att fördjupa sig
i. Då det har upplevts svårt att hitta forskning kring när mindre team använder sig av LSD
hade en intressant aspekt varit att utföra en liknande undersökning som vi gjort fast på ett
team som har en fastställd systemutvecklingsmetod. Därav skulle man kunna identifiera
likheter och skillnader mellan LSD och den andra metoden som används på arbetsplatsen.
42
9. Referenser
Björkholm, T. & Brattberg, H. (2018). Prioritera, fokusera, leverera: din snabbguide till
Lean, Agile, Scrum, Kanban och XP : version 1.5. Stockholm: Vulkan.
Bryman, A. (2011). Samhällsvetenskapliga metoder. Malmö: Liber.
Jacobsen, I. D. (2017). Hur genomför man undersökningar?. Lund: Studentlitteratur AB.
Middleton, P., & Joyce, D. (2012). Lean Software Management: BBC Worldwide Case Study.
IEEE Transactions on Engineering Management, 59(1), 20-32.
https://doi.org/10.1109/TEM.2010.2081675
Misaghi, M., Bosnic, I. (2014).Lean Mindset in Software Engineering: A Case Study in a
Software House in Brazilian State of Santa Catarina. Springer Cham Heidelberg New York
Dordrecht London. DOI:10.1007/978-3-319-11854-3
Oates, B.J. (2012). Researching information systems and computing. London: SAGE.
Poppendieck, M. & Poppendieck, T. (2003). Lean software development: an agile toolkit.
Boston: Addison-Wesley.
Razzak, A. M. (2016). An Empirical Study on Lean and Agile Methods in Global Software
Development. Lero, the Irish Software Research Centre. 61-64.
Region Örebro län (2020) Lean - Förbättringsarbete. Hämtad 2020-07-08 från
https://www.regionorebrolan.se/sv/uso/Om-USO/Lean---
forbattringsarbete/
Wang, X., Conboy, K., Cawley, O. (2012). “Leagile” software development: An experience
report analysis of the application of Lean approaches in Agile software development. Lero,
The Irish Software Engineering Research Centre, Ireland. 1287-1289.
43
10. Bilagor
Bilaga - Informationsbrev intervjuer
Information till forskningsperson som deltar i intervjuer inom
ramen för studien “Hur kan Lean Software Development
användas för att effektivisera arbetet inom sjukvården i den
offentliga sektorn?”
Denna information riktas till IT-personalen på Region Örebro län, som har valt att delta i
observationer 1 inom ramen för studien “Hur kan Lean Software Development användas för
att effektivisera arbetet inom sjukvården i den offentliga sektorn?”
Forskningshuvudman: Örebro Universitet
Namn på för studien ansvariga forskare: Amela Begic, Malin Almstedt från
Handelshögskolan vid Örebro universitet
Kontaktpersoner för studien: Amela Begic, Malin Almstedt från Handelshögskolan vid
Örebro universitet.
Detta dokument består av två delar
● Information (beskrivning av studien, insamling av data, etc)
● Samtyckesformulär (för underskrift om du väljer att delta)
Du kommer att få en kopia av detta dokument, för underskrift, innan observationen påbörjas.
1 Här bör det stå “Intervjuer”, misstaget uppmärksammades i efterhand.
44
Del 1: Information
Utförande
Studien utförs i form av en intervju, som beräknas ta ca 10-15 minuter. Deltagandet är helt
frivilligt och du har rätt att ångra dig och när som helst avsluta ditt deltagande.
Frågorna ställs för att med din hjälp skapa en ökad förståelse för hur verksamheten arbetar
med olika systemutvecklingsmetoder, ramverk och verktyg. Även dina synpunkter och tankar
gällande arbetssättet är viktiga att höra. Om det förekommer frågor under intervjun som du av
någon anledning inte vill besvara behöver du bara säga till så hoppar intervjuaren över frågan
och går vidare till nästa. Inga andra än intervjuaren och ytterligare en person som för
anteckningar kommer att vara närvarande från forskningsteamets sida. Inga obehöriga
kommer att ha tillgång till materialet som samlas in. Dokumentationen sker genom
ljudinspelning och anteckningar.
Bakgrund och syfte
Utvecklingen av mjukvarusystem är mycket konkurrenskraftig och dynamisk. Nuvarande
mjukvarusystem måste ofta rymma förändringar för till exempel nya kundbehov, förordningar
och teknik för att behålla sin konkurrensfördel. Samtidigt som man måste ha allt detta så
måste organisationerna leverera på kortare ledtider, bättre kvalitet och med lägre budgetar.
Det finns flertal kritiska faktorer som påverkar utvecklingen av informationssystem inom
Sjukvård. Därav så vi vill undersöka hur Lean Software Development kan användas för att
effektivisera arbetet inom sjukvården.
Vinster
Du kommer inte att erbjudas någon försäkring eller belöning efter genomförd observation
men en vinst för ert företag är att ni får förslag på ett effektivare arbetssätt. Genom ditt
deltagande kommer du att hjälpa oss att samla in mycket viktig information om ert arbetssätt
på flera olika plan.
Risker
Det kan finnas en risk att du delar med dig av personlig eller konfidentiell information, eller
att du känner dig obekväm med att diskutera några av intervjuns områden. Tänk dock på att
du kan välja att hoppa över frågor om du känner att några av dem känns obekväma. Du har
även möjlighet att helt avbryta intervjun. Den information du lämnar under intervjun kommer
att behandlas så att ingen utanför forskargruppen kan komma åt den (se ”Hantering av
personuppgifter och resultat” nedan).
45
Hantering av personuppgifter och resultat
Hantering av dina personuppgifter regleras enligt Personuppgiftslagen (1998:204). 2
Informationen som samlas in kommer att hållas anonymiserad. All information som kan
kopplas direkt till dig, som t ex ljudfiler och transkript, kommer att identifieras med kod och
inte ditt namn. Filerna lösenordskyddas och kommer att raderas efter att alla analyser av
materialet är genomförda.
Information om resultat
Resultaten kommer att publiceras i form av en vetenskaplig rapport. Resultatet kommer även
att presenteras på seminarier vid Örebro Universitet men kommer också publiceras som en
allmän handling och kan begäras ut av vem som helst när de är godkända. Du som deltagare
kan även få information om resultaten av studien genom att skriftligen kontakta Malin
Almstedt eller Amela Begic.
Tveka inte att höra av Dig med frågor till någon av nedanstående personer om något är oklart.
Vänligen
Amela Begic och Malin Almstedt
Kontaktuppgifter
Amela Begic Malin Almstedt
Örebro Universitet Örebro Universitet
Handelshögskolan Handelshögskolan
e-post: [email protected] e-post: [email protected]
___________________________________________________________________________
2 Här bör det stå “Allmänna Dataskyddsförordningen”, misstaget uppmärksammades i efterhand.
46
Bilaga - Informationsbrev observationer
Information till forskningsperson som deltar i observationer
inom ramen för studien “Hur kan Lean Software Development
användas för att effektivisera arbetet inom sjukvården i den
offentliga sektorn?”
Denna information riktas till IT-personalen på Region Örebro län, som har valt att delta i
observationer inom ramen för studien “Hur kan Lean Software Development användas för att
effektivisera arbetet inom sjukvården i den offentliga sektorn?”
Forskningshuvudman: Örebro Universitet
Namn på för studien ansvariga forskare: Amela Begic, Malin Almstedt från
Handelshögskolan vid Örebro universitet
Kontaktpersoner för studien: Amela Begic, Malin Almstedt från Handelshögskolan vid
Örebro universitet.
Detta dokument består av två delar
● Information (beskrivning av studien, insamling av data, etc)
● Samtyckesformulär (för underskrift om du väljer att delta)
Du kommer att få en kopia av detta dokument, för underskrift, innan observationen påbörjas.
47
Del 1: Information
Utförande
Denna forskningsaktivitet gäller ditt deltagande i en observationsstudie som pågår under en
hel/halv arbetsdag. Deltagande är helt frivilligt och du har rätt att ångra dig och när som helst
avsluta ditt deltagande. Projektets forskare kommer att följa dig i ditt arbete under en
arbetsdag för att med din hjälp få en ökad förståelse för hur verksamheten arbetar med olika
systemutvecklingsmetoder, ramverk och verktyg. Den som observerar kan komma att ställa
frågor för att t ex få en bättre förståelse för varför vissa systemutvecklingsmetoder, ramverk
och verktyg används. Du är helt fri att avböja att svara på vissa frågor om du av någon
anledning finner dem olämpliga. För det mesta kommer observatörerna bara att observera och
hålla sig i bakgrunden. Vid de tillfällen då interaktion med andra, såsom kollegor, sker är det
centralt att du förklarar för dessa att det pågår en observationsstudie som är en del av ett
forskningsprojekt samt att deltagandet är frivilligt. Om den andra parten inte vill att
observationen ska ske under interaktionen, alternativt ändrar sig efter att ha gett sitt samtycke,
görs det en paus i observationen. Anteckningar kommer att föras löpande under
observationen.
Bakgrund och syfte
Utvecklingen av mjukvarusystem är mycket konkurrenskraftig och dynamisk. Nuvarande
mjukvarusystem måste ofta rymma förändringar för till exempel nya kundbehov, förordningar
och teknik för att behålla sin konkurrensfördel. Samtidigt som man måste ha allt detta så
måste organisationerna leverera på kortare ledtider, bättre kvalitet och med lägre budgetar.
Det finns flertal kritiska faktorer som påverkar utvecklingen av informationssystem inom
Sjukvård. Därav så vi vill undersöka hur Lean Software Development kan användas för att
effektivisera arbetet inom sjukvården.
Vinster
Du kommer inte att erbjudas någon försäkring eller belöning efter genomförd observation
men en vinst för ert företag är att ni får förslag på ett effektivare arbetssätt. Genom ditt
deltagande kommer du att hjälpa oss att samla in mycket viktig information om ert arbetssätt
på flera olika plan.
Risker
Det kan finnas en risk att du delar med dig av personlig eller konfidentiell information, eller
att du känner dig obekväm med att svara på vissa frågor som ställs. Tänk dock på att du kan
välja att inte svara på frågor om du känner att några av dem känns obekväma. Om
konfidentiell information, t ex vid interaktion med patient, skulle komma fram kommer
anteckningar om detta inte att göras. Fokus är på arbetssättet och inte specifika uppgifter som
registreras eller liknande detaljerad information. En ytterligare risk är att en tredje part (t ex
kollega eller patient) som inte vill bli en del av observationen börjar inleda en diskussion med
dig. Som tidigare nämnt är det centralt att du upplyser dessa om vad som pågår, och kom ihåg
att den som utför observationen gör en paus i aktiviteten om en tredje part inte skulle
samtycka.
48
Hantering av personuppgifter och resultat
Hantering av dina personuppgifter regleras enligt Personuppgiftslagen (1998:204).
Informationen som samlas in kommer att hållas anonymiserad. Anteckningarna kommer
direkt efter observationen att placeras i ett kodat kuvert. Det är bara inblandade forskare som
kommer att kunna identifiera dig genom koden. Filer med renskrivna anteckningar kommer
att lösenordskyddas och ingen obehörig kommer att kunna ta del av materialet. Filerna raderas
efter att alla analyser av materialet är genomförda.
Information om resultat
Resultaten kommer att publiceras i form av en vetenskaplig rapport. Resultatet kommer även
att presenteras på seminarier vid Örebro Universitet men kommer också publiceras som en
allmän handling och kan begäras ut av vem som helst när de är godkända. Du som deltagare
kan även få information om resultaten av studien genom att skriftligen kontakta Malin
Almstedt eller Amela Begic.
Tveka inte att höra av Dig med frågor till någon av nedanstående personer om något är oklart.
Vänligen
Amela Begic och Malin Almstedt
Kontaktuppgifter
Amela Begic Malin Almstedt
Örebro Universitet Örebro Universitet
Handelshögskolan Handelshögskolan
e-post: [email protected] e-post: [email protected]
___________________________________________________________________________
49
Bilaga - Intervjufrågor
1. Kön?
2. Ålder?
3. Vilken utbildningsnivå den anställda har
4. Vilken anställning har du på företaget?
5. Vilken roll har du på företaget?
6. Hur länge har du arbetat på företaget?
7. Har ni jobbat på annan arbetsplats inom offentlig sektor?
8. Har du jobbat på en annan arbetsplats som har tillämpat Lean?
9. Vad använde ni för systemutvecklingsmetod i ert arbetssätt på din gamla arbetsplats?
(Exempelvis Agilt)
10. Vad skulle du kalla er utvecklingsmetod på den här avdelningen?
11. Vad tycker du är det bästa med ert nuvarande arbetssätt?
12. Vad tycker du kan förbättra med ert nuvarande arbetssätt?
13. Vilka återkommande moment/system har ni?: (veckovis, Scrum, möten)
14. Använder ni några roller från Scrum? ( Exempelvis Scrummaster)
15. När ni estimerar tid använder ni er av Scrum poäng och T-shirt modellen, kan du
förklara hur det går till?
16. Ni har nämnt att i har morgonmöten tre gånger i veckan. Varför har ni inte det varje
dag? (Daily Scrum meetings)
17. Hur räknar ni ut hur ni ligger till i er sprintplanering? Har ni nått verktyg?
(Ex Burndownchart enligt Scrum)
18. Hur följer ni upp att ni har estimerat rätt tid?
19. Hur tänker ni kring dokumentation? (Är det någonting ni prioriterar)
20. Är du bekant med arbetssättet Lean?:
● OM JA
● Hur tillämpar ni Lean i er verksamhet?
● Tycker du Lean är ett bra verktyg för att effektivisera arbetssätt på?
● Visa modell om Lean:
Kan du ge oss exempel på vilka delar inom Lean du tycker är bra?
● Visa modell om Lean: De ska koppla modellen till det som de gör
21. Eftersom Region Örebro län är en statlig finansierad verksamhet så har ni ju strama
projektbudgetar att förhålla er till - tycker du att de systemen ni bygger ändå håller bra
kvalitet?
50
Bilaga - Samtyckesblankett
Jag har tagit del av informationen ovan och jag har givits möjlighet att ställa kompletterande
frågor och alla frågor jag har ställt har fått tillfredsställande svar. Jag samtycker frivilligt till
att delta i denna studie.
Deltagarens namn ________________________________
Deltagarens underskrift ________________________________
Datum ________________________________
