Er smidige prosjekter mer innovative enn fossefallsprosjekter? (F)

Sammendrag 

Bør bedrifter som tar sikte på innovasjon, velge å organisere endringsteamene etter smidige løsninger eller fossefallsmetoden? Vi har fulgt tre ulike team i Laerdal Medical som varierer i hvorvidt de bruker fossefall som metode eller er organisert etter smidige løsninger. Basert på en rekke intervjuer finner vi at smidige løsninger har potensialet til å oppnå de mest innovative løsningene, men at de må overkomme to generiske utfordringer: organiseringen av programvareutviklere og håndtering av selskapets teknologiske arvegods (legacy). Begge utfordringer må overvinnes for at smidige løsninger skal la seg realisere. 

Innledning 

Laerdal Medical er et multinasjonalt produksjonsselskap innen helsesektoren med over 1 900 ansatte i 25 land. Med 98 prosent eksport og en omsetning på over fire milliarder kroner er Laerdal et av Norges mest suksessrike globale industrikonsern. Selskapet har i en årrekke vært verdensledende innen opplærings- og behandlingsutstyr for livreddende førstehjelp. Det familiedrevne selskapet har over flere generasjoner produsert helseteknologiske produkter til flere sektorer, primært helse og undervisning. I 2016 gjennomførte selskapet en organisatorisk endring med hensikt å øke hastigheten på produktutvikling, samt sikre at man fikk øket fokus på hva som alltid har vært selskapets styrker, kundenærhet og kundetilpassete løsninger. Et grep var å endre strukturen i en mer smidig retning. For å øke fokus på mer tverrfaglig samarbeid gikk man bort fra å ha hver fagdisiplin delt inn i produktområder. I stedet endret man strukturen slik at de ulike fagdisiplinene ble organisert på tvers av utviklingsområdene. 

Laerdal opplevde at det var lettere å legge til rette for smidige løsninger i de mindre teamene enn de store. Det medførte at i 2020 da vi samlet data hos Laerdal, fantes det team som var organisert etter både fossefallsprinsipper, smidige løsninger og en blanding. 

Basert på en rekke intervjuer finner vi at smidige løsninger har potensialet til å oppnå de mest innovative løsningene, men at de må overkomme to generiske utfordringer: organiseringen av programvareutviklere og håndtering av selskapets teknologiske arvegods (legacy). 

Teoretikere og praktikere mener at smidige løsninger sikrer innovasjon (Annosi et al., 2020; Holbeche, 2018; Rigby et al., 2018; Rigby et al., 2020), men i hvilken grad er dette sant? Vår problemstilling er derfor om smidige løsninger er mer innovative enn fossefallsprosjekter. For å undersøke dette har vi fulgt tre team som varierer i hvorvidt de jobber etter fossefall som metode eller smidige løsninger. 

Teori 

Det er i dag to rådende tilnærminger hvis man skal lede et prosjektarbeid rettet mot produkt- eller tjenesteendring, nemlig fossefallsmetoden og smidig løsning (se tabell 1 for en oversikt). Den første tradisjonelle tilnærmingen er fossefallsmetoden, som er en lineær og sekvensiell metode som kjennetegnes ved at prosjektet er delt inn i ulike steg der en må fullføre ett steg før en kan gå videre til neste. Fossefall er ofte preget av hierarkisk styring og at teamet er organisert etter profesjoner (Nerur & Balijepally, 2007). Et annet kjennetegn er at arbeidet blir planlagt i starten av prosjektet der man utarbeider en detaljert plan om et ønsket resultat (Royce, 1970). En fordel med fossefallsmetoden er at en kan redusere risiko ved å ha en omfattende planlegging i starten for så å bruke minst mulig tid og ressurser på de planlagte aktivitetene. En ulempe er at denne måten å styre prosjekter på er lite fleksibel, og at den i liten grad åpner for endringer ved planen. Et annet moment er at kundene kun er involvert i planleggingsfasen, og i liten grad i selve prosessen der man utvikler produktet og løsningene. Dette gjør at fossefall som metode er mindre egnet hvis man ikke vet hvordan produktet eller løsningen skal se ut ved prosjektets start. 

Den andre tilnærmingen er smidige løsninger, som vokste frem på starten av 1990-tallet (Conboy, 2009) som en konsekvens av at mange prosjekter opplevde utfordringer med budsjettoverskridelser, tidsfrister, manglende kundekontakt og kvalitet i leveransene (Cooke, 2012). Det var spesielt innen programvare- og teknologiutvikling man opplevde at lineær og standardisert prosjektledelse ikke var tilpasset kortere og raskere prosjekter der utfallet ikke var gitt ved starten av prosjektet (Goulstone, 2016). Som en løsning på dette publiserte man formelt det såkalte Agile Manifesto (Beck et al., 2001) som en reaksjon på fossefallsmetoden. Utgangspunktet var ønsket om iterative og inkrementelle aktiviteter som var mer fleksible, og der også kunden i større grad var mer involvert underveis (Goulstone, 2016). Manifestet var opprinnelig utarbeidet for programvare-utvikling, men har blitt populært som metode og praksis nå i store, multinasjonale selskaper og også innenfor de fleste bransjer (Lindskog & Magnusson, 2021). 

Rigby et al. (2020, s. 66–67) har foreslått at smidige team skal «skape lønnsomme innovative løsninger på problemer – komme med nye produkter og tjenester, foreslå en bedre utviklingsprosess og utvikle en avansert teknolog for å støtte nye tjenester». Rigby et al. (2018, s. 4) definerer innovasjon som «det å utvikle lønnsomme, kreative løsninger i form av produkter, tjenester, prosesser og forretningsmodeller.» Laerdals oppfatning av innovasjon er ganske lik, men legger i tillegg vekt på innvirkning (impact) målt i antall liv som reddes. Smidige løsninger i team består av et sett med metoder og praksiser (Abrahamsson et al., 2017) slik som sprinter, Scrum, Kanban, kryssfunksjonelle team, myndiggjørende selvledende team og kontinuerlig kundekontakt (Annosi et al., 2020; Schwaber & Sutherland, 2017). Hvilke metoder og praksiser man skal velge, varierer med konteksten og den utviklingsprosessen selskapet står overfor (Campanelli et al., 2018). Et annet valg er om man skal skalere smidige løsninger i hele organisasjon, altså alle team i en organisasjon, og ikke bare de innen programvare- og teknologiutvikling (Rigby et al., 2018). Det gjør at smidige løsninger ikke bare handler om koordinering innad i et team, men også om hvordan team koordinerer seg mot andre team og løser sine prosjekter når det eksisterer avhengigheter også til andre team. Forskningslitteraturen har tatt innover seg at det er krevende å implementere smidige løsninger i alle team, ikke minst i multinasjonale selskaper (Annosi et al., 2020; Dybå & Dingsøyr, 2008; Dingsøyr et al., 2017; Sommer; 2019), og at det eksisterer lite forskning om hvordan man skalerer smidige team til alle områder i et multinasjonalt selskap (Dikert et al., 2016). 

Dingsøyr et al. (2017) fulgte implementeringen av smidige team i stor skala i et programmeringsselskap og fant utfordringer knyttet til kundeinvolvering, arkitekturløsninger og koordinering på tvers av teamene. Sommer (2019) gjennomførte en kvalitativ studie av implementeringen av smidige løsninger i Lego-gruppens digitale avdelinger. Hun fant at ett år etter innføringen reagerte teamene raskere på endringer (fra måneder til uker) i kjernefunksjoner i selskapet, men at flere av teamene ikke fungerte godt med smidig løsning. En utfordring var å etablere «riktige» oppsett med metoder og praksiser, og det var manglende kunnskapsdeling om de ulike løsningene mellom teamene. Annosi et al. (2020) gjorde også en kvalitativ studie der de fulgte implementeringen av smidige løsninger i utviklingsavdelingen ved et multinasjonalt telekom-selskap over fem år. Målet for implementeringen var at de smidige løsningene skulle bidra til effektivitet, lavere kostnader og innovasjon. Det man fant, var det motsatte: Effektive smidige løsninger svekket den enkeltes læring og utviklingen av produkter i selskapet. 

Ut fra tidligere forskning ser vi at smidige løsninger ikke alltid har bidratt til mer innovative løsninger. I denne studien har vi derfor fulgt tre team som i varierende grad benytter seg av fossefallsmetoden eller smidige løsninger. I hvert av teamene har vi gått inn med et åpent sinn for å få et innblikk i hvordan smidige metoder og praksiser har bidratt til mer innovative løsninger i et multinasjonalt selskap. 

Metode 

Vi valgte en kvalitativ og casebasert tilnærming. En casestudie er en empirisk utredning av et fenomen i dets naturlige kontekst (Yin, 2018). Casestudiene foregikk under pandemien. Vårt generelle inntrykk er at pandemien var utfordrende for alle de tre casene uavhengig av graden av fossefall eller smidige løsninger. Alle de tre casene rapporterer at pandemien har gitt utfordringer relatert til fysiske møter, men dette var ikke en uoverkommelig barriere. 

Caser 

I desember 2020 studerte vi tre forskjellige prosjektteam som arbeidet i varierende grad etter smidige løsninger og lokasjon. Team 1 jobber med å videreutvikle Laerdals avanserte simuleringsdukke til bruk for profesjonelle helsearbeidere. Teamet er i mindre grad organisert etter en smidig løsning, og det er lokalisert på hovedkontoret. Team 2 lager et digitalt produkt som gjør at livredderne kan få virtuell fjernopplæring. Teamet benytter seg av smidige løsninger og er lokalisert på hovedkontoret. Team 3 utvikler et nytt konsept for pasientsimulering til en mye lavere pris enn hovedproduktet. Team 3 er organisert etter prinsippene om smidige løsninger og er lokalisert utenfor selskapet – på den andre siden av gaten i en garasje. Det er en internasjonal dimensjon ved alle de tre teamene. Selskapet har en miks av egne faste ansatte programvare-utviklings ressurser i tillegg til at noen programvare-utviklings ressurser hentes eksternt fra enten Danmark, India, USA eller leies inn fra eksterne nasjonale og internasjonale konsulenter. 

Data 

Data ble samlet inn ved intervjuer. Til sammen ble det gjennomført ti intervjuer av én overordnet prosjektleder og tre personer fra hvert av de tre teamene (to teammedlemmer og én teamleder). 

Intervjuene 

Deltakerne ble kontaktet via e-post der de fikk informasjon om formålet med studien. Intervjuene var semistrukturerte, og det var utarbeidet en intervjuguide som kandidatene hadde fått på forhånd. Intervjuet ble gjennomført digitalt på Zoom eller Teams og varte i ca. 1 time. Spørsmålene handlet om deres erfaringer med prosjektarbeid og det å jobbe i et team. Alle intervjuene ble tatt opp og transkribert fullt ut. 

Analyse 

I analysen ønsket vi å undersøke betydningen av de ulike smidige løsningene i teamene. For å få innsikt i dette tok vi utgangspunkt i teori og så etter kategorier basert på ulike metoder og praksiser, mens vi også utviklet nye kategorier induktivt med utgangspunkt i de transkriberte dataene. For eksempel var én kategori hierarkisk/flat organisering i teamene, og et annet eksempel var myndiggjøring av teamene. I den neste fasen tok vi utgangspunkt i kategoriene og så etter mønstre og sammenhenger både innad og på tvers av teamene. I den påfølgende delen vil vi presentere resultatene. Tabell 2 viser en oversikt over funnene ved bruk av en vis og fortell-teknikk (Golden-Biddle & Locke, 1997) for å belyse hvilke av de to tilnærmingene (fossefall og smidige løsninger) som er tatt i bruk i teamene, og konsekvenser av disse. 

Resultater 

De tre teamene har ulik oppfatning om bruk av fossefall som metode. Team 1 opplever at de er 80 prosent fossefall, team 2 opplever at de er 40 prosent fossefall, og team 3 opplever at de er 0 prosent fossefall (altså 100 prosent organisert etter smidige løsninger). Vi vil se nærmere på hvert av disse tre teamene og hva det har å si for innovasjon. Tabell 2 viser en oversikt over de tre teamene. 

Team 1 

Målsettingen til team 1 var å levere to nye moduler av ansikt og armer som et ledd i å videreutvikle Laerdals simuleringsdukke. Dette innebærer inkrementelle forbedringer på eksisterende produkter over en periode på 1–2 år. Målet er at endringene vil bidra til økt salg av dukkene, mer fornøyde kunder og salg av oppdateringer til ca. 10 000 eksisterende simulatorer. Team 1 er relativt stort og består av 20–25 teammedlemmer. 

Det overordnede målet er tydelig for prosjektet i team 1, og de følger en stegvis prosess. 

En etablerte først kundebehovene, og basert på disse så startet en prosess med utvikling av prototyper før man låser kravene og begynner industrialiseringen. Deretter går de fleste ressursene med på å lage krav og tegninger, før vi deler opp i mindre team som jobber på sine deler opp mot de spesifikke leveransene, før det hele sammenstilles.  

(leder, team 1) 

Team 1 er hierarkisk organisert, der man har en overordnet prosjektleder som forholder seg til teamleder, og teamleder som har ansvar for å formelt følge opp teamet. Prosjektene har også en styringsgruppe der toppledelsen er representert, og hver annen måned er det et fysisk møte der prosjektleder presenterer status til styringsgruppen. Her ser vi også eksempler på at man foretrekker innspill fra kunden fremfor mer direkte styrt ledelse. 

Innspill fra partnere og toppen har gjort at det har vært vanskeligere å få gjort en god jobb. 

(medlem, team 1) 

Lederen anslår at de jobber 80 prosent etter fossefallsmetoden, men at team 1 ønsker å bli mer smidig ved å ha raskere sykluser på prosjektene og tettere kobling til kunden. 

Så lenge vi ikke har et modulært system, og ikke har et sett med Lego-klosser som kan settes sammen og bli hva som helst, så er vi nesten tvunget inn i fossefall. 

(medlem, team 1) 

De ansatte i team 1 er også organisert i team ut fra profesjoner, der teknologi er plassert utenfor team 1. Organisering byr på utfordringer med teknologi, men også på tvers av profesjonene. 

Den organiseringen vi har hatt de siste fire årene, har vært utfordrende med tanke på teknologi. Det har vannet ut kompetansen. Det er ikke lenger en fagansvarlig eller disiplinansvarlig. Det er heller ikke en «sånn gjør vi det i selskapet». Vi lærer ikke av hverandre, og konsekvensen er at det blir lavere effektivitet fordi vi er nødt til å finne ut av ting selv. 

(medlem, team 1) 

Team 1 har tatt i bruk noen elementer av smidige løsninger, selv om de i all hovedsak bruker fossefallsmetoden. De jobber etter sprinter for å øke tempoet og bruker stand-up for å koordinere arbeidet, men det er også utfordringer med å gjøre dette på en god måte. 

I starten i konseptfasen så jobbet vi i sprinter, men av en eller annen grunn så er det å jobbe med mekanisk og fysisk utvikling vanskelig å få til en slik arbeidsform, og det er ikke tradisjon for det. 

(leder, team 1) 

Når vi jobber uten daglige stand-ups, så blir det ukoordinert – vi er mye mer koordinert når vi har daglige standups og et klart fokus på et mål. Men det må ikke bli for lange møter hvor arbeidslysten forsvinner i detaljerte diskusjoner. 

(leder, team 1) 

I team 1 skjer innovasjonen i den digitale løsningen, mens man mer stegvis og inkrementelt utvikler det fysiske produktet. 

Den virkelig innovative delen av produktet er i den digitale løsningen, mens i det fysiske produktet foregår utviklingen inkrementelt. 

(leder, team 1) 

Team 2 

Team 2 har som mål å lage et digitalt opplæringsprodukt som muliggjør virtuell fjernopplæring ved hjertestans. Tanken er at du bruker telefonen din til å filme trening på redning ved hjertestans, og når kameraet filmer bevegelsene, får du tilbakemelding på kompresjonsaktivitet. Hvis du i tillegg bruker en simuleringsdukke, kan du øke kvaliteten på tilbakemeldingene med ekstra informasjon om dybde og ventilasjon, som er viktig for kvaliteten på redningen. Team 2 er et middels stort team og består av mellom 12–20 teammedlemmer, alt etter hvor mange konsulenter som er engasjert. 

Team 2 jobber med digitale løsninger og har kunnet bryte med den overordnede prosjektorganiseringen og utviklingsprosessen som team 1 følger. Det gjør at team 2 kan operere mer ad-hoc og frigjøre seg fra noen av prosessreglene samt forenkle noe av organiseringen. Team 2 har vært organisert i et produktteam som leverer på et problemområde og med en noe enklere styringsgruppestruktur. I stedet for å forholde seg til en styringsgruppe som møtes sjeldent (for eksempel annenhver måned), har man hyppigere avklaringer for å sikre at teamet gjør de rette valgene. 

Det har vært mindre av gate reviews som sørger for avklaring med styringsgruppen, men vi har hatt en mindre gruppe stakeholders som har vært mer informert om hva som skjer, heller enn at vi har spurt om lov og tillatelser. 

(leder, team 2) 

Team 2 er et kryssfunksjonelt team som er organisert etter område. Teamet har ressurser innenfor alle fagfelt, som designere og utviklere. Teamet har også programvareutviklere som er tilknyttet teamet fra et felles ressursteam, men som ikke direkte er en del av teamet. Det tekniske teamet består utelukkende av konsulenter. 

 Vi er kryssfunksjonelle rundt fysiske produkter, mens digitale produkter som software- og apputvikling er mer felles tjeneste der ressursene blir allokert til teamet ved behov. 

(leder, team 2) 

I team 2 er det en viss frihet, og alle i teamet skal ha mulighet til å påvirke beslutninger. Det som er viktig, er at produktsjefene får lov til å ta de beslutningene de trenger for å oppnå målene. 

Løsningen har vært å etablere en kjerne i teamet bestående av produktsjef, designer og en teknisk leder og gi dem ansvar for leveransene og at de tar beslutningene som sørger for at det blir en løsning som skaper verdi for både kunden og for selskapet. 

(leder, team 2) 

Selv om teamet oppgir at de er myndiggjort, må de fremdeles rapportere til styringsgruppen, og vi ser at teamet ønsker enda mer myndiggjøring. 

For å bli mer smidig trenger teamet mer myndiggjøring – at de får en oppgave der de kan diskutere seg frem til at løsningene er gode, verdifulle, brukbare og ønsket i markedet. 

(leder, team 2) 

En annen utfordring ved organisering er at det virker krevende å utnytte programvare-utviklingskompetansen med hensyn til både tid, avstand og kultur. Programvareutvikling er organisert utenfor teamet og må leies inn enten som innleid konsulent eller som felles tjenester som er lokalisert andre steder i organisasjonen (for eksempel Danmark eller India). Teamet opplever ofte at programvareutviklingskompetansen kommer inn sent i prosessene og mangler eierskap og innspill til løsningene. 

Du får ikke det eierskapet, og så må du gå til et eksternt team og be dem om å bemanne opp et team som de egentlig ikke styrer. 

(leder, team 2) 

Team 2 er organisert etter smidige løsninger og bruker Scrum med sprinter som varer i to uker, med planlegging, gjennomgang og evaluering av sprintene for kontinuerlig forbedring av metoden. En utfordring er å bli hurtigere på hva som skal leveres og utvikles. 

Vi lagde veldig raske prototyper som vi delte med kunden og et knippe av våre partnere tidlig, og så ble det tatt på markedet etter bare 4,5 måneder, som er raskt for selskapet. 

(leder, team 2) 

Team 2 jobber mest med inkrementell innovasjon, som vil si å innovere eksisterende produktlinjer. Samtidig ønsker de å utvikle helt nye måter å levere trening på som både er skalerbare, kundenære og effektive. Dette stiller krav til mer programvare-utviklingskompetanse, som er en annen type kompetanse enn man har hatt tidligere i teamet. 

Vi også må tilegne oss den kunnskapen/kompetansen når vi erstatter og får inn nye folk i selskapet som i større grad har erfaring med digitale produkter. 

(leder, team 2) 

Team 3 

Laerdals mest avanserte simuleringsdukke koster en halv million kroner. Målet til team 3 er å drastisk redusere kostnadene ved produktet og løsningen selskapet leverer. Ambisjonen er å utvikle en simulator som er billig og robust, og som også kan benyttes i utviklingsland for å redde liv. 

Laerdal tilbyr trening i å sette sprøyter, gi medisiner, utføre kompresjoner og innblåsinger (hjerte- og lungeredning) og så videre. Tradisjonelt har dette vært løst med mere fysisk løsninger, men nå ønsker man å løse det mer digitalt for å forenkle, gjøre det billigere og øke fleksibiliteten til å endre underveis. Man ønsker å ha et abonnementssystem slik at man kan aktivere aktuelle løsninger for hver enkelt kunde. Team 3 er et mindre team og består av 8–12 teammedlemmer. 

Ambisjonen til team 3 er å levere en radikalt ny plattformløsning, både ny teknologi og nytt produkt. De ser på en ny plattform for å kunne levere enda rimeligere, smartere sensorisk og modulær pasientsimulering. Team 3 har en overordnet plan for hvordan de vil gå frem, men de har ikke detaljert kunnskap om det de skal utvikle. 

Formålet er å ta i bruk ny teknologi, nye tanker, knytte seg opp mot andre selskaper/partnere og gjenbruke det andre har laget før, sånn at vi kommer oss raskere på markedet og kan redde enda flere liv. 

(leder, team 3) 

Teamet er organisert som en enhet ved at lederen, designere og produkteier jobber sammen med ingeniørene og teknisk leder. Man ønsker å jobbe så tverrfaglig og flatt strukturert som mulig. Man prøver også å legge til rette for både plattform- og moduler av både fysiske og digitale produkter slik at man i større grad kan basere løsningene på gjenbruk av de eksisterende, slik at det kan gå raskt og være smidig. 

Vi ønsker å gjenbruke ressursene og ideene som er i organisasjonen. Så vi prøver å være veldig åpne for alle ideer som finnes i casebedriften og hos andre partnere og bedrifter. 

(leder, team 3) 

Teamet er plassert i garasjen på den andre siden av gaten slik at de slipper å være involvert i den daglige driften. Meningen er at de skal stå friere til å komme med nye tanker og ha en start-up-mentalitet. I tråd med smidige løsninger finner vi at de ansatte opplever at de er autonome og selvdrevne, og at teamet tar egne beslutninger i fellesskap. 

Den fritenkningen er det som kan skape innovasjon i alle bedrifter. At man får lov til å tenke nye ideer og gå nye veier. 

(leder, team 3) 

Jeg gleder meg til å gå på jobb hver dag, vi sprudler hver dag og har det veldig gøy. 

(medlem, team 3) 

Risikoen med smidige prosjekter er at: 

Du kan ende opp med at prosjektet mislykkes, og at det ikke kommer noe ut av det. En annen utfordring er at du jobber mot et overordnet mål der man ikke helt har definert hva målet er. Man må utvikle en felles forståelse for hva man ønsker å løse. 

(leder, team 3) 

En tydelig utfordring teamet opplever, er at selv om de sitter i garasjen, må de forholde seg til selskapets teknologiske legacy-systemer, det vil si de eksisterende løsningene og produktene. Legacy setter rammer for hvor innovativ man kan være i praksis: 

Vi ser allerede nå at vi har et legacy-problem. Hvis vi skal skru sammen en løsning, så er det lett å bruke noen skruer du har brukt før, og bruke dem om igjen. Vi leverer en prototype der vi bruker en del kjente komponenter og en del nye komponenter. Ved å gjøre det så har vi gjort noen kompromiss som vi vet vi ikke vil godta, men for å få det gjort så gjør vi det. Vi bruker noen skruemuttere, software, teknologier og skyløsninger som vi allerede har, for å vise hva vi vil levere. Men da avdekker vi og at det er egentlig ikke sånn vi ønsker å gjøre det, og vi tror det blir bedre om vi gjør det skikkelig fra grunnen av. 

(medlem, team 3) 

Legacy virker inn på team 3s ambisjon om å levere en radikalt ny plattformløsning: 

Så har du legacy. Vi har så mye historie. Men vi prøver å ikke bli begrenset av historien, men å ha med oss kunnskapen fra teknologi og historien. 

(medlem, team 3) 

En annen utfordring for team 3 har vært å kunne trekke på programvareutviklere fra Laerdals fellestjenester. En av initiativtakerne bak team 3 klarte ikke å vente og rekrutterte utviklere fra Laerdals eget selskap i USA. 

Programvareutviklere har vært den største svakheten, men utenom det har vi designere og mekaniske folk. 

(leder, team 3) 

Diskusjon 

De tre teamene vi har fulgt, har alle ulike utfordringer som virker inn på innovasjonsgrad. Som vi har sett i resultatdelen, har team 1 utfordringer knyttet til myndiggjøring, kundeinvolvering, tempo og programvareutviklere, mens team 2 har utfordringer knyttet til spesielt programvareutviklere og myndiggjøring av teamet. For team 3s del er tilgang til programvareutviklere en enda tydeligere utfordring enn hos team 2. I tillegg er håndtering av legacy-utfordringer en bremsekloss for realiseringen av innovasjonspotensialet. Våre resultater tyder på at skal innovative løsninger frembringes ved bruk av smidige tilnærminger hos Laerdal, må begge utfordringer overkommes. 

Smidige team skal «skape lønnsomme innovative løsninger på problemer – komme med nye produkter og tjenester, foreslå en bedre utviklingsprosess og utvikle en avansert teknolog for å støtte nye tjenester». 

Innovasjon for Laerdal kommer til uttrykk i form av innvirkning målt i form av antall liv som reddes, underbygget av antall opplært helsepersonell og dernest høyest kommersiell betydning. Team 1 opplever innovasjon i den digitale løsningen på tross av fossefallsmetoden, mens vi opplever at smidige team i større grad har potensialet for å være grunnleggende innovative. Dette funnet er tråd med litteraturen om agile løsninger, som hevder at smidighet er veien å gå for å oppnå innovasjon (Annosi et al., 2020; Holbeche, 2018; Rigby et al., 2018; Rigby et al., 2020). Rigby et al. (2020) sier at et selskap må finne balansen mellom standardisering av operasjoner og innovasjon. Det betyr at selskapet ikke bare må se seg blind på smidige løsninger og praktiser, men også nøye vurdere denne balansen mellom fossefall som metode og smidige løsninger. Her må en nok la hvert enkelt team finne sin metode og løsning ut fra situasjonen det står i. Her er det også verdt å merke seg at team 1 har et klart definert mål slik at fossefall er mer forventet, mens team 2 og 3 har mer uklare mål der man ikke helt vet hva man skal komme med. Dette gjelder spesielt team 3, som ikke vet hvordan den endelige løsningen skal se ut (både digitalt og fysisk), de har kun et overordnet mål å jobbe mot og er avhengig av å eksperimentere i korte iterasjoner for å finne den korrekte veien, og da er det mer effektivt med en smidigere løsning (Goulstone, 2016). 

Utfordring 1: Utfordringer med tilgang til tverrfaglig programvare-utviklingskompetanse 

Samlet finner vi at Laerdal har en utfordring med å håndtere tverrfaglig programvare-utviklingskompetanse som særlig rammer team 3, som har de største innovasjonsambisjonene. Hvis selskapet skal oppnå tverrfaglig programvareutvikling, vil det kreve at de i større grad ansetter personer med programvareutviklingskompetanse og innlemmer disse i teamene. I dag mangler teamene programvareutviklingsressurser og storparten av ressursene må hentes andre steder (f.eks. Laerdals datterselskaper i Danmark, USA eller India) eller hos innleide internasjonale konsulenter (som mangler dybdekjennskap til løsninger og produkter). Programvareutviklerne er også ofte i team uten designere – noe som gjør at de kommer senere inn i prosessen, har mindre eierskap og er der mer som en problemløser enn en utvikler og innovatør. Et annet poeng er at team som utelukkende trekker på utenforstående konsulenter, har mindre eierskap til prosessene og fremtidsplanene. Dette henger også sammen med hvordan Laerdal tildeler ressurser. I teamene har man mandat til å hente konsulenter, men for faste ansettelser må man involvere toppledelsen, noe som er en omfattende prosess. Det gjør at man ender med løsninger med innleide konsulenter. For at smidige team skal realisere sine innovasjonsambisjoner, er det derfor kritisk å håndtere utfordringer knyttet til tilgang på tverrfaglig programvare-utviklingskompetanse. 

Utfordring 2: Utfordringer med teknologisk legacy-systemer 

Team 3 jobber i garasjen på andre siden av gaten for å slippe å være med i daglige aktiviteter slik at de kan tenke friere og komme med nye tanker og ideer. Selv om de kan tenke helt nytt, ta i bruk ny teknologi og knytte seg opp mot andre partnere, vil de oppleve å komme raskere på markedet hvis de kan gjenbruke tidligere løsninger. Det gjør at teamet får en kobling til selskapets teknologiske legacy-systemer, løsninger og produkter – og dermed arver de også selskapets teknologiske legacy. Det gjør at selv om teamet skal stå helt fritt, har det i praksis vanskelig for å løsrive seg fra selskapets teknologiske legacy-systemer. 

Begrensninger 

En begrensing med vår studie er vi opererer med et relativt lite antall caser i ett selskap. Til gjengjeld ser vi på caser med varierende grad av smidige løsninger innenfor en enhetlig kontekst. Dette gir et godt grunnlag for valide sammenlikninger. Videre mener vi at Laerdal utgjør en kontekst som er relativt representativ for etablerte selskaper som arbeider med å få til innovasjon. En annen begrensing er tidsspennet til vår studie. Et lengre tidsrom vil kanskje vise andre utfall enn de vi avdekker. For eksempel i 2021/2022 gjennomførte Laerdal en omorganisering og det hadde vært interessant å følge opp med en ny studie av både hvilken retning bedriften nå beveger seg og hva konsekvensene er for prosjektene vi har studert. Ideelt sett bør fremtidig forskning dermed ha et mer eksperimentelt design der man følger team med ulike innslag av smidige tilnærminger over tid.

Konklusjon 

Teorien tilsier at fordi smidige team er fleksible, motiverende, kundenære, raske og lar ansatte ta del i utviklingen, er de mer innovative enn de som bruker fossefall som metode. Studiens analyser tyder på at teamet som følger smidige løsninger har potensialet for å være mest innovativt, men at teamet i likhet med fossefall teamene står overfor to grunnleggende utfordringer: organiseringen av programvareutviklere og håndteringen av selskapets teknologiske legacy. Selv om vi har utført intervjuer i kun et selskap, er vår mening at disse to utfordringene ikke er spesielt Laerdal-spesifikke, men er generiske utfordringer. Vår konklusjon er dermed at for å kunne realisere smidige løsninger er det avgjørende for selskaper som vurderer slike løsninger at disse to utfordringene håndteres på en effektiv måte. 

Referanser 

Abrahamsson, P., Salo, O., Ronkainen, J. & Warsta, J. (2017). Agile software development methods: Review and analysis (Rapport, VTT Publications 478). VTT Technical Research Centre of Finland. arXiv:1709.08439 [cs.SE]. 

Annosi, M. C., Foss, N. & Martini, A. (2020). When agile harms learning and innovation: (and what can be done about it). California Management Review, 63(1), 61–80. https://doi.org/10.1177/0008125620948265 

Beck, K. et al. (2001). Principles behind the Agile Manifesto. The Agile Alliance. https://agilemanifesto.org/principles.html 

Campanelli, A. S., Camilo, R. D. & Parreiras, F. S. (2018). The impact of tailoring criteria on agile practices adoption: A survey with novice agile practitioners in Brazil. Journal of Systems and Software, 137, 366–379. 

Cooke, J. L. (2012). Everything you want to know about agile: How to get agile results in a less-than-agile organization. IT Governance. 

Conboy, K. (2009). Agility from first principles: Reconstructing the concept of agility in information systems development. Information Systems Research, 20(3), 329–354. 

Dikert, K., Paasivaara, M. & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108. 

Dybå, T. & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9–10), 833–859. 

Dingsøyr, T., Moe, N. B., Fægri, T. E. & Seim, E. A. (2017). Exploring software development at the very large-scale: A revelatory case study and research agenda for agile method adaptation. Empirical Software Engineering, 23(1), 1–31. 

Golden-Biddle, K. & Locke, K. D. (1997). Composing qualitative research. Sage. 

Goulstone, P. (2016). Project management. It could be agile? Deloitte. https://www2.deloitte.com/au/en/pages/financial-services/articles/project-management-technology.html 

Holbeche, L. S. (2018). Organisational effectiveness and agility. Journal of Organizational Effectiveness: People and Performance, 5(4), 302–313. https://doi.org/10.1108/JOEPP-07-2018-0044 

Lindskog, C. & Magnusson, M. (2021). Ambidexterity in agile software development: A conceptual paper. Journal of Organizational Effectiveness: People and Performance, 8(1), 16–43. https://doi.org/10.1108/JOEPP-07-2019-0068 

Nerur, S. & Balijepally, V. (2007). Theoretical reflections on agile development methodologies. Communications of the ACM, 50(3), 79–83. 

Rigby, D. K., Elk, S. & Berez, S. (2020). The agile C-Suite: A New Approach to Leadership for the Team at the Top. Harvard Business Review, 98(3), 64–73. 

Rigby, D. K., Sutherland, J. & Noble, A. (2018). Agile at scale. Harvard Business Review, 96(3), 88–96. 

Royce, W. W. (1970). Managing the development of large software systems. IEEE CS Press, 328–339. 

Schwaber, K. & Sutherland, J. (2017). The Scrum Guide. Scrum Alliance. https://www.scrumguides.org/scrum-guide.html 

Sommer, A. F. (2019). Agile transformation at LEGO Group. Research-Technology Management, 62(5), 20–29. https://www.doi.org/10.1080/08956308.2019.1638486 

Yin, R. K. (2018). Case study research and applications: Design and methods. Sage.