Kan industrin ta lärdom av Scrum?: en fallstudie av ett traditionellt tillverkande företag

Kan  industrin  ta  lärdom  av  Scrum?  

PATRIK ENGLESSON JOAKIM WRETSKOG

MG100X Examensarbete inom Industriell Produktion

Stockholm, Sverige 2015

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-100 44 STOCKHOLM

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.    

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.  

Innehållsförteckning  

1   Inledning  ...  1  

1.1   Bakgrund  och  syfte  ...  1  

1.2   Frågeställning  ...  2  

2   Metod  ...  2  

2.1   Informationssökning  ...  2  

2.2   Empirisk  studie  ...  2  

2.3   Avgränsningar  ...  2  

3   Litteraturstudie  ...  3  

3.1   Scrum  ...  3  

3.1.1   Roller  ...  3  

3.1.2   Händelser  ...  4  

3.2   Hybrider  mellan  Scrum  och  traditionell  projektledning  ...  5  

3.2.1   Fallstudie  1  –  Pharma  ...  6  

3.2.2   Fallstudie  2  –  Ledande  fönstertillverkare  ...  6  

3.3   Fallstudie  Wikispeed  ...  7  

4   Empiri  ...  8  

4.1   Projektledning  hos  Scania  ...  8  

5   Diskussion  ...  12  

5.1   Likheter  mellan  befintlig  projektledning  och  Scrum  ...  12  

5.1.1   Roller  ...  12  

5.1.2   Händelser  ...  12  

5.2   Förslag  på  Scrumimplementering  ...  13  

5.2.1   Roller  ...  13  

5.2.2   Händelser  ...  14  

6   Slutsats  ...  16  

6.1   Fortsatt  arbete  ...  16  

7   Referenser  ...  17  

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  33835  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).    

2

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.    

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.    

3.1.1 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).  

4   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).  

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  

6

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.).  

3.2.1 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.  

Tabell  1:  Implementering  av  Scrum  hos  Pharma   Svårigheter  innan  

Scrumimplementering   Verktyg  som  implementeras   Förbättringar  inom   projektledning  

• Överskridning  av   budget  

• Projektets  omfattning   minskade  på  grund  av   dålig  sikt    

• Dålig  resursfördelning  

• Scrum  boards  

• Burndown  chart    

• Daily  Scrum    

• Product  Backlog    

• Value-­‐chain  model  

• Förbättrad   resursfördelning  

• Bättre  kommunikation    

• Ökad  spridning  av   kunskap    

• Ökad  synlighet  över   processen  

3.2.2 Fallstudie  2  –  Ledande  fönstertillverkare      

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).  

3.3 Fallstudie  Wikispeed  

Wikispeed  är  en  organisation  bestående  av  volontärarbetande  ingenjörer  som  grundades  2008.  

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).    

8

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.  

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  

10

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.  

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.    

12

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.    

5.1.1 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.  

  5.1.2 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  

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.  

5.2.1 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