Kan industrin ta lärdom av Scrum?

Transkript

1 Kan industrin ta lärdom av Scrum? PATRIK ENGLESSON JOAKIM WRETSKOG MG100X Examensarbete inom Industriell Produktion Stockholm, Sverige 2015

2 Kan industrin ta lärdom av Scrum? En fallstudie av ett traditionellt tillverkande företag av Patrik Englesson Joakim Wretskog MG100X Examensarbete inom Industriell Produktion KTH Industriell teknik och management Industriell produktion SE STOCKHOLM

3 Sammanfattning Traditionell projektledning bygger på en gedigen förstudie där projektets uppgifter planeras i detalj för att uppnå uppsatta mål. Den förklarade detaljplanen ska i största möjliga mån följas. I en omvärld där utveckling och förändring sker konstant kan traditionell projektledning ha brister då detaljplanen inte är anpassad efter den aktuella situationen, utan efter förstudien. Inom systemutvecklingsprojekt används ofta agila metoder vars ramverk tillåter förändringar, både vad gäller projektplan och mål för projektet. Scrum är ett agilt ramverk som med stor framgång har använts för produktutvecklingsprojekt inom IT- sektorn. Ramverket är uppbyggt av bestämda roller och händelser vars syfte är att effektivisera projekt genom att rätt kunskap används för att uppnå slutkundens ständigt uppdaterade krav. Arbetet är uppdelat i cykler där varje cykel bör utmynna i en funktionsduglig produkt. Arbetets syfte är att undersöka möjligheten att applicera IT- sektorns agila lösningar inom den tillverkande industrin. Med hjälp av empiriska studier på ett traditionellt tillverkande företag, likt Scania, har möjligheten att använda Scrum för fysisk produktutveckling undersökts. En litteraturstudie av liknande implementeringar har även gjorts för att skapa erfarenhet i frågan. Utifrån empirin har likheter kunnat dras mellan det tillverkande företagets arbetssätt och Scrums beståndsdelar. Litteraturstudien visade att ett effektivt sätt att applicera agila metoder på fysiskt tillverkande företag är att göra det som en hybrid mellan befintligt arbetssätt och Scrum. Med detta som grund har slutsatsen dragits att Scrum inte helt och hållet kan användas hos det undersökta företaget. Däremot kan delar av Scrum med fördel användas. Även i detta fall kan slutsatsen dras att en hybrid mellan traditionell projektledning och Scrum är den bästa lösningen. Då tiden inte räckt till för att testa slutsatserna i praktiken rekommenderas fortsatta studier i detta.

4 Abstract Traditional project planning is built on a thorough feasibility study where the projects task is planned in detail to achieve the goals of the project. The explanatory detail plan shall in the greatest extent be followed. In a world where development and changes occur constantly, traditional project management has shortcomings when the detail plan is not adapted to the current situation, but to the feasibility study. System development projects often use agile methods, whose framework allows changes, both in terms of project plan and goals for the project. Scrum is an agile framework that has been successfully used for product development projects in the IT sector. The framework consists of defined roles and events which aim is to improve the efficiency of the project by using the right knowledge to achieve the end customer, constantly updated, requirements. The work is divided into cycles and each cycle should lead to a working product. The aim of this report is to investigate the possibility of applying the IT sector s agile solutions in the manufacturing industry. With the help of empirical studies on a traditional manufacturing company the possibilities to use Scrum for physical product development can be investigated. A literature study of similar implementations has also been made to create experience in the question. Based on the empirical data similarities have been drawn between the manufacturing company working methods and Scrum components. The literature study showed that an effective way to apply agile methods on physical manufacturing companies is to make it as a hybrid between the existing working methods and Scrum. On this basis the conclusion can be drawn that the investigated company cannot fully use Scrum. However, parts of Scrum can advantageously be used. Also in this case the conclusion is that a hybrid between traditional project management and Scrum is the best solution. Due to time limits, the conclusions have not been tested in practice. The recommendation is to make further studies.

5 Innehållsförteckning 1 Inledning Bakgrund och syfte Frågeställning Metod Informationssökning Empirisk studie Avgränsningar Litteraturstudie Scrum Roller Händelser Hybrider mellan Scrum och traditionell projektledning Fallstudie 1 Pharma Fallstudie 2 Ledande fönstertillverkare Fallstudie Wikispeed Empiri Projektledning hos Scania Diskussion Likheter mellan befintlig projektledning och Scrum Roller Händelser Förslag på Scrumimplementering Roller Händelser Slutsats Fortsatt arbete Referenser... 17

6 1 Inledning I detta kapital kommer vi beskriva bakgrunden till arbetet samt syftet med arbetet. 1.1 Bakgrund och syfte I dagens samhälle handlar det mycket om att vara ekonomisk, social och ekologisk hållbar. De flesta företagen har insett att detta inte enbart medför större lönsamhet men även att företagen jobbar effektivare (KTH 2014). Vid undersökning av de stora industriföretagen på produktionssidan är det tydligt att i och med intåget av lean började företagen bli mer effektiva och att kommunikation och samarbete med kunden blivit mer påtagligt. Däremot är projektledning och hur projekt sköts relativt okänt, det finns inte riktigt någon erkänd metod som anses är bäst. Därför finns det ett intresse att undersöka vad för alternativa metoder som finns. En metod som skapar stort intresse och är snabbväxande, dock främst inom IT- sektorn, är Scrum. Scrum är en Agil- modell som betyder lättrörliga metoder. Syftet med dessa metoder är att det skall vara lätt att göra förändringar under projektens gång. Scania AB är idag en ledande aktör i tillverkning av lastbilar och bussar med fabriker i både Europa och Sydamerika. Scania har i dagsläget anställda och de flesta är stationerade i Södertälje där montering av lastbilar och bussar sker (Scania 2015). Scania är ett företag som jobbar främst med traditionell projektledning. Många företag har inslag av Agila- modeller utan att veta om detta. Scrum är fortfarande bitvis okänt och obeprövad när det kommer till produktionsbaserade företag. Scania är ett exempel på ett sådant företag. De använder Scrum på IT- sidan men vid projektledning på produktionssida är det fortfarande relativt okänt. Med begreppet traditionell projektledning menas att utvecklingsprocessen utförs i bestämda steg. Varje steg representerar olika utvecklingsmetoder och verktyg för att uppnå de varierade deluppgifterna. Utvecklingsprocessen är ofta standardiserad enligt stage- gate modeller som visas i figur 1 (Aganovic 2004). Figur 1: Översikt av traditionell projektledning (Aganovic 2004). 1

7 1.2 Frågeställning Tanken är att upptäcka likheter och skillnader mellan Scanias sätt att sköta projekt och hur projektledning enligt Scrum är. För att göra detta har två frågeställningar tagits fram som skall besvaras i denna rapport. Kan Scrum- metodiken appliceras inom produktframtagning hos ett tillverkande företag? Kan projektledningen hos ett tillverkade företag dra nytta av Scrum? 2 Metod Två olika metoder har använts för att få en teoretisk grund för analysen. Den består av en informationssökning och en empirisk studie. 2.1 Informationssökning För att få en teoretisk grund som analysen sedan grundats på har en litteraturstudie genomförts där framförallt material för teorin bakom Scrum och Agila- metoder undersökts. Vidare har även en litteraturundersökning gjorts på arbeten där Scrum har applicerats på produktutvecklingsföretag och tillverkande företag. Dessa sökningar gjordes via databaser som Kungliga Tekniska Högskolan har tillgång till. En del teori har även hämtats från Scrum grundarnas hemsida. 2.2 Empirisk studie Det har även utförts en intervju för att ta reda på hur projektledning ser ut hos Scania. Intervjun gjordes med Ali Ebrahimi som arbetar som processteknisk chef för en grupp ingenjörer som arbetar med produktionsutveckling på Scanias lastbilar. Intervjun var öppen och medförde en diskussion kring ämnet. Ett antal nyckelfrågor gjordes för att kartlägga hur projektledning ser ut hos Scania. Vidare har även kontinuerlig mejlkorrespondens hållits med Ali Ebrahimi för frågor som dykt upp under rapportens gång. 2.3 Avgränsningar På grund av tidsbrist har undersökningarna enbart tagit upp om det finns möjlighet att applicera Scrum på produktframtagningssidan och inte om Scrum är bättre än nuvarande metod. Av samma anledning har inga tester genomförts för att undersöka om Scrum kan implementeras och ersätta nuvarande metodik. Teoridelen för hur Scania jobbar kommer enbart vara baserad på intervjun och inte på någon vetenskaplig rapport. 2

8 3 Litteraturstudie Litteraturstudien som har utförts är baserad på artiklar som förklarar Scrum. Vidare har även publikationer angående hur Scrum kan integreras i företag som jobbar med produktutveckling och tillverkning av produkter analyserats. Detta har utförts för att få en insyn i vilka delar av Scrum som passar i ett företag likt Scania. 3.1 Scrum Scrum är ett ramverk uppbyggt av bestämda roller, händelser och kontinuerlig återkoppling i syfte att ge en effektiv, flexibel och kreativ produktframtagning Roller Tre olika roller utgör vad som har kommit att kallas ett Scrumteam. Ett Scrumteam skall vara ett tvärfunktionellt och självorganiserande team som inte skall vara beroende av någon utomstående part för att fullfölja sitt syfte. Teamets roller är Produktägare, Scrummaster och utvecklingsteamet (Ovesen 2012). Rollen som Produktägare medför ansvaret att maximera produktens värde och bestämma vad utvecklingsteamet skall arbeta med. Produktägaren är alltid en person och aldrig fler än en person vars arbete sker genom att hantera en produktspecifikation (Ovesen 2012). Produktspecifikationen innehåller vilka egenskaper och funktioner som produkten skall uppfylla samt en rangordning av dessa egenskaper och funktioner. Rangordningen ger utvecklingsteamet information om vilken av produktens egenskaper som de skall ta fram i nästa sprint. Det skall vara säkerställt att backlogen är tydlig och synlig för alla inom Scrum teamet. Utvecklingsteamet är ett självorganiserande team som utför det faktiska arbetet i att leverera en funktionsduglig produkt efter varje sprint. Teamet är tvärfunktionellt och innehar all den kunskap som är nödvändig för att ta fram produktens olika egenskaper (Ovesen 2012). Ramverket tillåter inga undergrupper eller titlar inom Utvecklingsteamet oavsett arbetsuppgift hos medlemmarna, teamet som helhet ansvarar för den framtagna produkten. Teamet bör ha mellan tre till nio medlemmar vars arbete skall utgå från samma fysiska plats för att underlätta och optimera kommunikation och samarbete inom teamet. Utvecklingsteamet ansvarar även för att upprätta en Sprint Backlog, vilket är ett dokument som uppdateras kontinuerligt och innehåller all nödvändig information för att nå uppsatta mål för sprinten (Sutherland & Schwaber 2013). Rollen som Scrummaster innebär flera olika ansvarsområden. Det huvudsakliga ansvaret är att agera som coach för Produktägaren och Utvecklingsteamet. Det kan vara att hjälpa Produktägaren med att skapa en optimal produktspecifikation eller att hjälpa Utvecklingsteamet med att skapa så värdefulla produkter som möjligt genom att exempelvis hålla i dagliga möten. Scrummastern kan ses som en expert inom Scrum och ser till att Scrumteamet alltid agerar enligt ramverket för Scrum samt hjälper den övriga organisationen i frågor och problem gällande Scrumprocessen. Scrummastern fungerar också som teamets kontaktperson till utomstående parter inom organisationen, så som att frånhålla irrelevanta arbetsuppgifter från Utvecklingsteamet. Scrummastern kan ofta men inte nödvändigtvis vara en av medlemmarna i utvecklingsteamet (Ovesen 2012). 3

9 3.1.2 Händelser Scrumprocessen är uppbyggt av bestämda händelser som enligt ramverket för Scrum alltid skall efterföljas. Händelserna utgörs av fyra olika möten som kallas Sprint Planning, Daily Scrum, Sprint Review och Sprint Retrospective. Dessa möten bygger tillsammans med de respektive rollernas egna arbetsuppgifter upp Scrums grundsten sprinten. En sprint är ett tidsintervall på maximalt en månad där resultatet efter varje sprint skall vara en funktionsduglig produkt. Sprintarna avlöser hela tiden varandra genom att en ny sprint påbörjas direkt efter att föregående sprint avslutats (Sutherland & Schwaber 2013). Nedan figur visar en övergripande bild på processen vid en sprint. Figur 2. Ovan figur visar hur en sprint enligt Scrum är uppbyggd (Gonzalez 2015). Det första mötet som påbörjar sprinten är Sprint Planning mötet där hela sprintteamet deltar. Här läggs en plan upp för den kommande sprinten, en sprint backlog tas fram innehållande de uppgifter och aktiviteter som sprinten skall innehålla. Detta sker genom att produktägaren med hjälp av produktspecifikationen presenterar vad som skall uppfyllas under sprinten. En diskussion mellan Produktägare och Utvecklingsteam är viktig för att uppsatta mål inte skall bli för omfattande för sprintens tidsram. Sprint planning mötet avslutas med att Utvecklingsteamet själva lägger upp en plan för när och hur dem uppsatta målen uppfylls. Målet för hela sprinten delas upp i mindre uppgifter, det är viktigt att varje uppgift kan lösas utav en ensam utvecklare under maximalt en arbetsdag. Hela Sprint Planning mötet får uppta maximalt åtta timmar (Sutherland & Schwaber 2013). Möte nummer två är Daily Scrum. Detta är ett dagligt återkommande möte på 15 minuter där Utvecklingsteamet och Scrum Mastern deltar. Syftet med mötet är att planera arbetet och att svara på dem tre frågorna: Vad har åstadkommits sedan föregående möte? Vad skall åstadkommas innan nästa möte? Vilka hinder är i vägen för att nå detta? Scrummasterns uppgift är att se till att mötet hålls, att tidsbegränsningen uppfylls och att samtliga inom Utvecklingsteamet får sin röst hörd (Ovesen 2012). 4

10 När en sprint har avslutats hålls alltid ett Sprint Review möte. Detta möte är till skillnad från Scrum Planning, Daily Scrum och Sprint Retrospective öppet för parter utanför Scrumteamet. Här har Utvecklingsteamet möjligheten att presentera vad de har jobbat med den senaste tiden. Målet med mötet är att på ett konstruktivt sätt gå igenom vad som har gjorts under sprinten och att mötet skall fungera som ett underlag för Produktägaren över vad som behöver göras i nästa sprint. Produktägaren förklarar vilka delar av produktspecifikationen som har uppnåtts och vilka delar som inte har det. För en sprint på en månad bör detta möte inte överstiga fyra timmar, även här ansvarar Scrum Mastern för att mötet hålls inom tidsramen (Ovesen 2012). Processens sista möte följer direkt efter Scrum Review mötet och kallas Sprint Retrospective. Detta möte ger scrum teamet en möjlighet diskutera hur arbetet under sprinten har fungerat. Detta är viktigt för att konstant förbättra och effektivisera arbetet och samarbetet. Efter mötet skall teamet ha kommit fram till förbättringar som implementeras under nästa sprint, scrum mastern ser till att dessa förbättringar sker inom ramverket för Scrum (Ovesen 2012). För att underlätta kommunikationen inom Utvecklingsteamet är Scrum Board ett hjälpmedel som ofta används, även om Scrum Board inte är någon officiell del av Scrums ramverk. En Scrum Board består av en stor white boardtavla tillsammans med post- it- lappar där information om vilka kvarvarande uppgifter som finns, vilka som har slutförts samt vilka uppgifter som arbetas med för tillfället. Ofta innehåller även Scrum Boarden en Burndown Chart, vilket är en graf över kvarvarande arbete kontra kvarvarande tid. Vanligt är att en Burndown Chart, likt figur 2, används för kvarvarande arbete hos både Sprint och Product Backlog (Ovesen 2012). Figur 3. Ovan figur visar ett exempel på en Burndown Chart (Joel 2010). 3.2 Hybrider mellan Scrum och traditionell projektledning Edgett tar i sin rapport upp behovet av samarbetsvillig produktutveckling. Istället för att ersätta traditionell stage- gate modeller, integrerar man Agila modeller i befintliga produktutvecklingsmodeller (PU) och skapar då hybrider. Traditionellt jobbar industriföretag med en linjär stage- gate modell. I rapporten har forskare undersökt och kommit fram till att produktutveckling är en Iterativ process som kräver iterativa projektmodeller. Agila projektlednings metoder som Scrum har haft en positiv inverkan på PU prestationer inom mjukvaruutveckling. Nya undersökningar har visat implementering av Agil PU modeller hos 5

11 industriella tillverkare har visat samma resultat (Friis Sommer et al. 2013). Den delen som är intressant när man implementerar Scrum på företag som använder sig av stage- gate är Stage 3 Development som figur 1 visar (Edgett n.d.) Fallstudie 1 Pharma Ett av företagen som beskrivs som en hybrid är Pharma. Pharma behöll stage- gate projektledning på kommittémöten och koordinering av deras portfölj men använde Scrum i alla andra projekt. Innan implementering av Scrum hade Pharma problem med att deras projekt inte höll tidsramen och de hade även problem med resursfördelning (Sommer et al. 2015). I tabellen nedan visas vilka delar av Scrum som implementerats och till vilken orsak detta genomförts. Svårigheter innan Scrumimplementering Överskridning av budget Projektets omfattning minskade på grund av dålig sikt Dålig resursfördelning Tabell 1: Implementering av Scrum hos Pharma Verktyg som implementeras Förbättringar inom projektledning Scrum boards Burndown chart Daily Scrum Product Backlog Value- chain model Fallstudie 2 Ledande fönstertillverkare Förbättrad resursfördelning Bättre kommunikation Ökad spridning av kunskap Ökad synlighet över processen Produktutveckling på ovan företag är strukturerad runt en stage- gate modell på den strategiska nivån och Scrum på projektnivå. Produktutvecklingsprojekt måste bestå utav minst en representant från fyra olika områden; projektledning, marknad, produkt och lager för att säkerställa en integrerad PU process. Alla fyra områdena använder Scrum vid arbeten som är tvärfunktionella över organisationen samt individuella arbeten inom områden när tre eller fler personer är involverade från samma område eller plats. Från marknad är det oftast en key account manager som har direktkontakt med kunder genom frekventa möten, utställningar och undersökningar, informationen från mötena förs in i produktspecifikationen tillsammans med Scrumteamet. Produktrepresentanter är från utveckling och produktion; projektledare agerar som koordinator och politisk filter medan representanter från lagret garanterar resurser, material och information för projektet. PU teamet är utspritt i hela landet så teamet möter varandra en hel dag varje vecka i ett projektrum som har tillgång till ett fysiskt Scrum Board, prototyper, övergripliga planer och temporära arbetsstationer. Eftersom en key account manager har utnämnts som ska ha kontakt med kunderna så har samarbetet med kunderna ökat drastiskt. Effektiviteten från teamet har ökat eftersom tvärfunktionell kommunikation och koordination har förbättrats. Omarbeten på både fysiska samt informella arbeten minskade med 20 % (Friis Sommer et al. 2013). 6

12 3.3 Fallstudie Wikispeed Wikispeed är en organisation bestående av volontärarbetande ingenjörer som grundades Organisationen ägnar sig åt att utveckla personbilar på ett innovativt och effektivt sätt. Det som gör att Wikispeed skiljer sig från traditionella biltillverkare är att arbetet sker helt och hållet enligt ramverket för Scrum. Den första personbilen som utvecklades färdigställdes efter tre månaders arbete av ett team med 44 medlemmar. Hos Wikispeed ligger arbetsfokus hela tiden på vad potentiella kunder efterfrågar genom att visa nuvarande prototyp samt låta de svara på frågor som: Vad gillar du med den nuvarande bilen? och Vad gillar du inte med den nuvarande bilen?. Arbetet i nästkommande sprint grundas sedan i resultatet av dessa kundundersökningar där längden på en sprint är en vecka. Organisationens utvecklingsteam är fördelat över hela världen. På grund av detta sker Sprint Planning mötena som videokonferenser, som efter mötet laddas upp på YouTube. På grund av utvecklingsteamets geografiska spridning krävs tydlig koordination över teamets arbete. Lösningen på detta är att Wikispeed använder sig av Kanban som samtliga inom teamet har tillgång till över internet. På så sätt har varje medlem vetskap i vad resterande medlemmar arbetar med. Än så länge konkurrerar inte Wikispeed med de ledande biltillverkarna. Till exempel saknade deras första utvecklade bil dörrar och bilen var inte vattentät. Trots detta är Wikispeed ett utmärkt exempel på hur en traditionell marknad som bilbranschen kan dra lärdom från Agila metoder som Scrum där fokus är på flexibilitet och vad kunden efterfrågar (Denning 2012). 7

13 4 Empiri Empirin är baserad på en intervju samt kontinuerlig korrespondens med Ali Ebrahimi som arbetar som processteknisk chef på Scania Lastbilar i Södertälje. 4.1 Projektledning hos Scania Ali Ibrahim ansvarar för en grupp av 14 processtekniker. Han ansvarar tillsammans med processteknikerna för hur lastbilarna skall sättas ihop. Processteknikerna är uppdelade i två grupper. Den ena gruppen kallas front office, deras arbetsuppgift är att lösa kortsiktiga problem. Det kan till exempel vara att snabbt lösa uppkommande aktiviteter så som att linan står still. Front office gruppen jobbar intensivt med produktionen. Den andra gruppen kallas back office, de ansvarar för de längre projekten och de större förändringarna i produktionen. Till exempel om ny utrustning krävs för att komplettera befintlig utrustning eller om befintlig utrustning måste bytas ut. Om front office identifierar ett fel i produktionen så jobbar back office med att lösa problemet på ett sådant sätt att felet aldrig uppkommer igen. När ett fel uppkommer i produktionen ansvarar en processtekniker, en produkttekniker och en gruppchef för problemet. Rollen som gruppchef innebär att ansvara för en viss del utav linan. Gruppchefen rapporterar avvikelser från sin egen avdelning och bestämmer om avvikelsen är ett problem som teknikerna bör lösa. Om avvikelsen har med processen att göra ansvarar processteknikerna för att lösa det. Produktionsoperatörerna arbetar i pass om två timmar på produktionslinan och efter varje pass summerar gruppchefen alla avvikelser som uppkommit. Det kan exempelvis vara stopptider och kvalitetsavvikelser. På så sätt ges en bild av hur produktionen fungerar samtidigt som avvikelser dokumenteras. Om betydande avvikelser konstateras i summeringen så kontaktar gruppchefen tekniksidan. När back office tar fram ny utrustning till produktionen följs en bestämd process. Till att börja med så stäms produktionens önskemål av genom samtal mellan gruppchefer och back office- tekniker. Samtalen sker kontinuerligt med två veckors mellanrum. Om det inte finns några akuta avvikelser i produktionen så kan fokus istället läggas på problem som kan förutses. Detta leder till investeringsprocessen. Investeringsprocessen inleds varje höst, där listas de investeringar som back office vill göra under året och vilken budget som skulle behövas. Där ges även input från underhållsdelen, vilka ansvarar för att kontrollera utrustningens tillstånd. Om livslängden för en viss maskin är förbrukad är det befogat att investera i en ny. Med utgångspunkt i allas input så rangordnas investeringarna. Nästa steg är att göra investeringsplaner för de investeringar som bör göras. Dessa planer innehåller all relevant fakta om investeringarna och offerter från leverantörer. Investeringsplanerna presenteras för beslutsfattare högre upp i organisationen. När en investering godkänns av organisationen sätts arbetet igång med att göra förundersökningar där kravspecifikationer bestäms. Investeringarna delas upp kvartalsvis. Processteknikerna är just nu involverade i ett stort byte av utrustning som är kritisk för produktionens resultat. När ett sådant byte sker så följer processteknikerna alltid den bestämda investeringsprocessen. Den processen följs punktvis och punkterna måste bockas av för att nästa steg skall påbörjas. Det kan till exempel vara att kontrollera att reservdelar till utrustningen finns eller att utrustningens funktion har testats hos leverantören. 8

14 Det finns en standard över hur projekt genomförs. Den går i stort ut på att projektet sker stegvis och varje steg måste säkerställas innan nästa steg påbörjas. En av back office teknikerna har ansvaret att ge input på förbättringar som kan göras i denna process. Processen över hur ett projekt genomförs lärs ut av Scania under en femdagars kurs. All återkoppling sker till den processtekniska chefen innan han återkopplar till styrgruppen. Det sker en genomgång en gång i veckan med back office teknikerna. Meningen med genomgången är att se till att alla är i fas. Längre projekt kan vara upp till två år medan kortare projekt brukar ha en projekttid på tre månader. Detta medför att en back office tekniker ofta parallellt arbetar med flera projekt samtidigt. Det är inte enbart projektens längd som avgör om back office teknikerna kan leda projekten på egen hand. Snarare beror det på hur mycket projektet skall komprimeras och hur mycket projektet måste påskyndas. Även vad det är som skall tillverkas och vad för ledtider som finns från leverantörer som bestämmer hur projektet skall ledas. Vissa kortare projekt parallellkörs och då kan det finnas tidsluckor som måste fyllas. Vid eventuella tidsluckor ansvara den processtekniska chefen för att förutspå och fylla dessa luckor, samt sköta kontakten med slutkunden. En utmaning som finns är att en del av arbetet på produktionslinan sker i en icke ergonomisk miljö. Något Scania jobbar ständigt med för att förbättra. När en station inte är ergonomisk är dialogen mellan personen som jobbar på stationen och personen som är tillsatt för att förbättra situationen avgörande. Så fort projekten inte sköts tvärfunktionellt, där alla avdelningar är med och ser till att slutprodukten blir bra, kommer projekten misslyckas. När det sker en förändring av en metod eller av utrustningen måste representanter från produktion, montörer och produktägare vara med och tycka till. Sedan koordineras detta med tvärfunktionerna för att dra nytta av all kunskap. Det är den processtekniska chefens uppgift att skriva en korrekt kravspecifikation så att alla upphandlingar blir rätt. Det är av stor vikt att alla potentiella frågor som måste besvaras är ställda, för att kravspecifikationen skall bli korrekt. Vidare är det viktigt att gruppen är med när den nya produkten installeras och frågar sig: Hur blev det på måndag? Hur blev det två veckor senare? Hur blev det två månader senare? Efter denna procedur genomförs en garantiuppföljning för att undersöka hur det blev två år senare när garantin gått ut. Garantiuppföljningen görs bland annat för att undersöka om det är någon utrustning som måste förbättras från leverantören, kontrollen genomförs av front office- teknikerna. Det finns en utmaning i att ha färre aktiva projekt igång samtidigt, då det påverkar effektiviteten. Målet är inte enbart att få ner antalet projekt utan att även få ner ledtiderna och öka träffsäkerheten i projekten. Det betyder att stort fokus ligger på att göra rätt saker och att leveranserna blir rätt från början. För att lyckas med detta görs analyser av alla projekt med hjälp ut av en jättetavla där alla projekt som är aktiva samtidigt är med. På tavlan skall det framgå hur projektet är uppdelat i delmål och i vilket steg projektet befinner sig i. Det är även viktigt att alla stegen i investeringsprocessen genomförs. För att se till att dessa steg genomför ställer gruppen frågor såsom: Vad innebär just det här steget för det här projektet? Så att rätt kunskaper används på rätt projekt. Det finns ingen standard för vilka frågor som skall ställas, utan frågorna är baserade på vad det är för projekt. Varför det just är dessa områden som man väljer att fokuserar på är för att det har funnits stora utmaningar med utdragna projekt. I det komplexa produktionssystem som Scania använder sig av kan ge upphov till en viss avvikelse och det finns många förslag på hur produktionssystemet 9

15 kan förbättras. Däremot finns det varken tid eller resurser för att ändra på allt. Därför måste det ske en sortering och en prioritering över vad en satsning på en viss avvikelse kan bidra med. Detta tillsammans med en prioritering som är baserad på hur mycket pengar som kan läggas på avvikelserna. Därför blir det extra viktigt att göra en väl genomförd sortering och prioritering. Fungerar inte systemet är det lätt att man tar på sig för mycket. Det fanns ett tag då gruppen av processtekniker tappade effektiviteten. När det kommuniceras till kunden att gruppen kollar på uppgiften medför det att kunden förväntar sig att projektet snart skall vara klart, vilket inte alltid är fallet. Därför är det viktigt att vara tydlig mot kunden, att innehållet i varje installation skrivs ner, att budget finns och att det finns en tydlig överenskommelse på målen. Målen som är uppsatta mellan kunden och projektgruppen kan ändras av olika anledningar under projektets gång. När förstudien har brister måste målen ändras. Det kan även hända att produkten ändras. Ibland kan projektgruppen förutspå vad som behöver åtgärdas för att ligga ett steg före, men ibland kommer förändringar som inte kan förutspås. Det kan till exempel vara så att något har hänt ute på fältet när produkten används av kunden och för att inte framtida kunder skall blir drabbade måste en förändring ske omedelbart. Det är inte helt ovanligt då ett projekt kan pågå under ett år och under den tiden kan det hända saker som man inte alltid kan förutspå. Vidare kan även bättre lösningar tas fram när de olika tvärfunktionella grupperna har möten. Om förstudien är väl genomförd kommer de ske färre förändringar längs med. Med det sagt behöver inte förändringar vara negativa under projektets gång, så länge det bidrar till ett positivt resultat. Helst skall målen som är satta från början håller hela vägen för att det underlättar genomförandet av projektet. Prioriteringen som görs över vilket projekt som skall prioriteras är baserad på en samlad bedömning. Där underhåll berättar vad som skall göras och där de anställda i produktionen prioriterar vad som måste genomföras. Viktigt är att det hela tiden finns en dialog mellan alla intressenter. Den samlade erfarenheten från tekniker och chefskåren bestämmer sedan vilken prioritering som skall gälla. Det är även viktigt att det finns en klar plan över vad som skall göras de närmsta åren. Jättetavlan som nämndes tidigare visar inte enbart vad varje person bör göra den kommande veckan utan även vilka som ingår i varje projekt och även vad som skall göras under hela året. Projektplaneringen genomförs på så sätt att varje vecka bör representera stadiet i projektmodellen och vad som bör göras för att kunna gå vidare till nästa stadie. Det kan till exempel vara så att vecka ett skall förstudien vara klar, vecka två skall kravspecifikation skrivas, vecka tre skall offerter skicka ut till leverantörer och vecka fyra skall varor beställas. När projektplanen är gjord följer den processtekniska chefen upp denna en gång i veckan tillsammans med processteknikerna för att se hur alla ligger till. Utifrån detta fastställs det om teknikerna kan gå vidare till nästa stadie eller om det behövs mer tid för att kunna genomföra det befintliga stadiet. Skulle det vara så att det fattas en offert från leverantören eller liknande kan den processtekniska chefen gå in och trycka på inköparna att kontakta leverantörerna. Vidare finns det även en detaljplan för respektive projekt som komplettera den mer överskådliga jättetavlan. Detaljplanen är för detaljerad för att den processtekniska chefen skall gå in och följa upp, förutom i vissa enstaka fall. Skulle det vara ny utrustning som måste installeras kan det vara så att insyn på detaljnivå måste finnas. Annars sköter generellt varje tekniker sin egen detaljplan. Detaljplanen kan både vara veckovis och timvis beroende på projekt. Däremot dokumenteras inte vad som har genomförts i detaljplanen. 10

16 Det sker sällan byten mellan vem som arbetar med ett visst projekt. Skulle någon bli sjuk i en vecka står oftast projektet still under den veckan. Vid sjukskrivning under en längre period kommer projektet lyftas över på en annan tekniker. Den största delen av informationen, angående ett projekt befogar den till projektet tillsatta teknikern över. En del information finns däremot nerskrivet som till exempel vad som är beställt och vilka som teknikerna har varit i kontakt med. 11

17 5 Diskussion Scrum är ett ramverk som har tagits fram för att framförallt optimera produktframtagning inom IT orienterade verksamheter. Att applicera detta ramverk på tillverkande industrier är därmed ett stort steg att ta och det går rimligtvis inte att utföra rakt av. Även om fallet Wikispeed är ett framstående exempel på hur Scrum kan användas vid framtagning av en komplex fysisk produkt så är olikheten stor mellan en nystartad verksamhet som Wikispeed och Scania (Denning 2012). Ett traditionellt företag som Scania, med ett arbetssätt som tagits fram och utvecklats under mer än hundra år gör appliceringen än mer komplicerad. Det vore naivt att tänka sig att detta arbetssätt kan anpassas helt och hållet efter ramverket för Scrum eller ändras i grunden då skillnaden i att till exempel producera lastbilar och att producera mjukvara är stor. Däremot är det troligt att flera delar inom Scrum kan användas för att komplettera och effektivisera det befintliga arbetssättet. 5.1 Likheter mellan befintlig projektledning och Scrum Scanias metodik kring projektledning är skapad och formad efter hur Scania arbetar. Många delar av hur projektledning ser ut i dagsläget har likheter med Scrum även fast benämningar är annorlunda. Som tidigare nämnt är det generellt IT verksamheten på företag som har implementerat Scrum och likadant är det hos Scania. Vid närmre studier av empirin, över hur projektledning på produktionsutvecklingssidan är utformad, återfinns det likheter till metodiken runt Scrum som kan ha influerats från IT verksamheten hos Scania Roller Inom Scrum finns tydliga roller och tydliga arbetsuppgifter uppdelade inom Scrumteamet. Inom produktionsutvecklingen hos Scania finns benämningar över olika roller och arbetsuppgifter som kan liknas med hur rollerna är indelade inom Scrum. Gruppchefen som dagligen är i kontakt med och ansvarar för en del av produktionen är ett exempel på en produktägare. Som definitionen säger skall produktägaren ansvara för att maximera produktens värde samt att upprätthålla en product backlog. Genom att dokumentera avvikelser och ge förslag på förbättringsåtgärder för processteknikerna att arbeta med gör gruppchefen just det, även om gruppchefen inte har mandat till att skriva en kravspecifikation. Gruppen av processtekniker hos Scania är ett exempel på ett utvecklingsteam som utför själva produktframtagningen, även om sättet processteknikerna utför projekt skiljer sig från Scrumstandarden. Den processtekniska chefens uppgift är att stöda processteknikerna i deras arbete och hjälper även till med kontakten mellan processtekniker och den övriga organisationen. Därför kan den processtekniska chefens arbete till viss del liknas vid hur en Scrum Masters arbetsuppgifter definieras Händelser En viktig del för att kunna definiera projektets önskemål och krav är, inom Scrum, att det sker en kontinuerlig kommunikation mellan produktägaren och utvecklingsteamet. I dagsläget sker 12

18 en liknande kommunikation genom samtal mellan gruppchefer och back office tekniker. Samtalen hålls med två veckors mellanrum där gruppcheferna framför produktionens önskemål på förbättringar. Dagens möten kan liknas med hur ett Sprint planning möte är uppbyggt. Tanken med Sprint planning mötena är att produktägaren skall framföra sina önskemål med projektet. Inför mötet har produktägaren definierat sina önskemål i produktspecifikationen. Information från produktspecifikationen skall vara till hjälp för att avgränsa utvecklingsteamets framtida arbete och hindra arbetet från att bli för omfattande. En central händelse inom Scrum är Daily Scrum- mötet som pågår i 15 minuter i början av varje arbetsdag. Tanken med mötet är att se till så att utvecklingsteamets arbete flyter på och att identifiera om några problem med sprinten har uppstått. I dagsläget finns det frekventa möten inlagda i projektplanen hos Scania. Mötena hålls veckovis och sker mellan processteknikerna och den processtekniska chefen. Även fast frekvensen inte är i enlighet med Daily Scrum- mötena återfinns en likhet med syftet med mötena. Ett ytterligare medel som används för att se till att utvecklingsteamet ligger i fas och hinner färdigt med sprinten är en funktion som kan liknas vid en Scrum Board. Scrum Boarden finns till för att visa vilka kvarvarande uppgifter som finns, vilka som har slutförts samt vilka uppgifter som arbetas med för tillfället. Det finns ett liknande hjälpmedel, som kallas för jättetavlan hos Scania, som innehåller information om i vilket steg projektet befinner sig i för tillfället. Meningen med jättetavlan är att säkerställa att stegen i investeringsprocessen genomförs i tid. 5.2 Förslag på Scrumimplementering Tanken med förslagen som presenteras i diskussionen är områden där Scania skulle kunna ta lärdom från Scrum för att effektivisera arbetet. Just effektivitet är ett område som den processtekniska chefen har kommenterat som ett område där Scania skulle kunna bli bättre. Då inga experiment har genomförts är förslagen som tas upp idéer på hur Scrum skulle kunna appliceras hos Scania. Vissa av förslagen är av mindre karaktär medan en del är mer omfattade och kommer behöva en längre implementeringsperiod Roller Vid Sprint planning möten är det fördelaktigt att personen som är produktägare eller som påverkas av problemet skriver kravspecifikationen. Enligt Scrum är det viktigt att informationen är öppen för samtliga och att informationen är tydlig. Annars kan problem uppstå om informationen först skall förmedlas muntligt till tekniker som sedan skriver kravspecifikationen. Det är viktigt att den som upptäcker problemet även definierar problemet och hur det bör förbättras, eftersom det är dem som dagligen kommer drabbas ifall problemet inte blir löst på ett korrekt sätt. Ansvaret för kravspecifikationen bör därför inte ligga på den processtekniska chefen då missförstånd lätt kan uppstå vid förmedling av information. För att Scrum skall kunna appliceras i en organisation krävs någon med fullständig förståelse för ramverket och som därmed kan ta rollen som Scrum Master. Rollens huvudsakliga uppgift är att säkerställa att ramverket för Scrum används men även att fungera som en ledare och koordinator mellan Produktägare och utvecklingsteam. Det sistnämnda går att likna med den processtekniska chefens arbetsuppgifter. Att den processtekniska chefen bör ta rollen som 13

19 Scrum Master är därmed logiskt, då det inte skulle innebära några större förändringar i arbetsupplägg utöver att anpassa det till ramverket för Scrum Händelser Mötena mellan gruppchefer och back office tekniker, som nämndes under likheter, som sker med två veckors mellanrum skulle kunna bytas ut mot Sprint planning möte. Sprint planning mötet hålls en gång i början av varje sprint där processtekniker, gruppchefer och den processtekniska chefen bör närvara. Här kan gruppcheferna dela med sig av önskemål på förbättring och komma överens med processtekniker om vad som är viktigast att uppnå, den processtekniska chefen bör ansvara för att de uppgifter som processteknikerna åtar sig inte är för omfattande. För att säkerställa effektiviteten kan Daily Scrum- möten införas där processteknikerna och den processtekniska chefen deltar. Även Daily Scrum- möten mellan gruppchefer och back office- tekniker skulle med fördel kunna införas för att ersätta de veckovisa mötena som hålls i dagsläget. Om man här likt Daily Scrum- mötet delar med sig av vad man har gjort, vad som skall göras och vilka problem som finns skulle teknikerna få en bättre inblick i vad de andra arbetar med. Därmed skulle teknikerna enklare kunna bidra med kunskap till varandras arbeten och det skulle bli enklare för en tekniker att ta över projekt vid oförutsägbara händelser. För att ge ytterligare inblick i varandras arbete skulle jättetavlan kunna kompletteras med uppgifter om vad som har slutförts och vad varje tekniker arbetar med för tillfället. Detaljplanen som varje tekniker har för sig själva skulle kunna bli publik och användas på jättetavlan för att utnyttja kunskapen som finns tvärfunktionellt i hela gruppen. Som det ser ut nu innehåller detaljplanen endast uppgifter om vad som skall göras i varje projekt, däremot finns ingen information om vad som har gjorts. Eftersom att processteknikerna i nuläget ofta ensamma ansvarar över sina egna projekt och sällan tar över någon annans har det förmodligen inte varit nödvändigt. Ett mer flexibelt och tvärfunktionellt sätt att arbeta på skulle däremot kräva att sådan information om varje projekt behövs för att olika processtekniker skall ha möjlighet att följa upp ett projekt. Att införa en Product Backlog för varje enskilt projekt kan därmed motiveras. Product Backlogen kan även användas som underlag vid Daily Scrum mötena. En utmaning som Scania upplever är att tekniker tar på sig för många projekt som skall lösas parallellt. Applicerar man Scrum, där tanken är att jobba intensivt med ett projekt åt gången, skulle det kunna lösas. För att lyckas är det viktigt att fokus ligger på just ett projekt åt gången. Projekt som sträcker sig över en längre period skulle därför kunna delas in i kortare sprintar. Stora projekt skulle då kunna delas in i kortare delprojekt. När en sprint är genomförd kan ett nytt delprojekt påbörjas och möjliggör då att fler projekt pågår men som är aktiva vid olika tillfällen. 14

20 Tabell 2 sammanfattar de förslag på vilka roller och händelser Scania skulle kunna använda sig av för att dra nytta av Scrummetodiken. Tabell 2: Implementering av Scrum hos Scania Roller Händelser Teoretisk vad förslagen kan medföra Förslag Tydlig rollindelning Tydlig kommunikation Flytta över ansvar för kravspecifikation, Scrum Master. Scrum board Burndown Chart Sprint Daily Scrum Product Backlog Sprint planning Ökad insyn Bättre utnyttjande av resurser Bättre effektivitet och träffsäkerhet. 15

21 6 Slutsats Scania skulle kunna ta lärdom av Agil projektledning likt Scrum. Det är dock en stor utmaning att implementera enbart Agil projektledning hos ett industriellt tillverkande företag som Scania som genom åren jobbat fram ett väletablerat arbetssätt. I fallstudien undersöktes ett antal tillverkande företag där Scrum har applicerats i den befintliga projektledningen som finns hos företaget (Friis Sommer et al. 2013). Företaget hade då en slags hybrid av traditionell projektledning och Scrum som etablerats på ett framgångsrikt sätt. Ett liknande system skulle sannolikt även passa Scania. Det som framförallt gör att Scrum inte kan appliceras i sin helhet hos Scania är projektens tidsramar. Enligt ramverket för Scrum bör en Sprint inte pågå i mer än en månad och varje sprint bör utmynna i en funktionsduglig produkt. Genom att dela in större projekt i mindre delprojekt och överlägga hur en funktionsduglig produkt definieras kan detta problem undvikas. För att sammanfatta frågeställningarna som ställdes kan slutsatsen dras att Scrum både kan appliceras hos ett tillverkande företag och även tillföra en förbättring av hur projektledning sköts i dagsläget i teorin. Däremot är det svårt att avgöra till vilken omfattning Scrum kan ersätta den befintliga projektledningen. 6.1 Fortsatt arbete För att verifiera slutsatsen bör teorin appliceras och testas i praktiken för att undersöka i vilken utsträckning Scrum kan ersätta och förbättra sättet att utföra projekt. 16

22 7 Referenser Aganovic, D., On Manufacturing System Development in the Context of Concurrent Engineering. Royal Institute of Technology. Denning, S., How Agile can transform manufacturing: the case of Wikispeed. Strategy & Leadership, Vol. 40(Iss. 6), pp Edgett, S., Stage-Gate Idea-to-Launch Model. Available at: Friis Sommer, A. et al., Scrum Integration in Stage-gate Models for Collaborative Product Development - A Case Study of Three Industrial Manufacturers. IEEE International Conference on Industrial Engineering and Engineering Management, p.5. Gonzalez, M., Learn About Scrum. Available at: [Accessed May 2, 2015]. Joel, Burn down Chart Tutorial: Simple Agile Task Tracking. Available at: [Accessed May 2, 2015]. KTH, Vad är hållbar utveckling? Available at: ( [Accessed May 14, 2015]. Ovesen, N., The Challenges of Becoming Agile. Aalborg University. Scania, Scania Koncernen. Available at: Sommer, A.F. et al., Improved Product Development Performance through Agile/Stage- Gate Hybrids. Research Technology Management, Vol. 58(Issue 1), p.12. Sutherland, J. & Schwaber, K., The Scrum Guide Available at: 17