Smidige team: Kan man sprinte en maraton? (F)

Sammendrag

Smidige team er blitt populære i mange virksomheter. Slike team kjennetegnes ved at de er autonome, tverrfaglige og benytter agile metoder. Smidige team har sitt utspring i utviklermiljøer og har derfor lagt stor vekt på metodikk. De største utfordringene i smidige team synes imidlertid å være knyttet til teamarbeidet i seg selv. For å få bedre innsikt i disse utfordringene intervjuet vi 72 medlemmer i smidige team fra fem ulike virksomheter. Fire elementer fremstår som sentrale å avklare: mål, autonomi, roller og innovasjon. Smidige team gir større fleksibilitet og hurtighet, men redusert kontroll krever at man gir seg tid til avklaringer underveis. Så kanskje kan man ikke sprinte en maraton. Men man kan klare mange sprinter hvis man legger inn noen pauser underveis. 

Agile processes and tools provide support, but the central weight-bearing mechanism of the agile approach is not the scrum or the sprint. Rather, it’s the team’s dialogic process — the way team members interact — that ultimately determines success. (Clark, 2022) 

De senere årene har vi sett en sterk interesse for å implementere agile eller smidige arbeidsmetoder i norske virksomheter. Argumenter som at vi trenger å endre oss hurtigere, jobbe mer tverrfaglig og være mer fleksible, er hyppig brukt, og mange virksomheter har derfor etablert smidige team. Et av de sterkeste kjennetegnene ved smidige metoder er at endring omfavnes, noe som står i kontrast til mer tradisjonelle prosjektledelsesmetoder (Hennel & Rosenkranz, 2021). Det er særlig innenfor programvareutvikling at smidige team er benyttet. I en global undersøkelse av 1 300 forretnings- og IT-ledere sier 75 prosent at smidige metoder er viktig for deres fremtid (Panditi, 2018). Og ifølge samme studie ønsker virksomheter å implementere smidige metoder innenfor flere domener, som for eksempel marked og kommunikasjon, salg, HR, kundebehandling, og forskning og utvikling. Til tross for stor popularitet og en del funn som viser at organisasjoner har positive resultater av smidige metoder (Bianchi, et al., 2020), er forskningen på effekten av å bruke smidige team eller smidige metoder ikke entydig positiv (Hennel & Rosenkranz, 2021). Faktisk hevdes det at så mange som halvparten feiler i sine forsøk på å jobbe agilt (Clark, 2022). 

Forskning på smidige prosesser har imidlertid ikke klart å holde tritt med den høye takten av implementering av smidige metoder i organisasjoner, og fremstår som underutviklet og uten teoretisk fundament (Dingsøyr, et al., 2012). Mer spesifikt er det særlig effekter på teamnivå og hvordan teamprosesser utvikler seg i smidige team, som er understudert (Hennel & Rosenkranz, 2021). Dette er uheldig siden mye av implementeringen av smidige metoder nettopp gjennomføres i smidige team. Smidige team er typisk selvstyrte og må selv koordinere sine aktiviteter, noe som betyr at teamsamarbeidet er viktig å forstå (Moe, et al., 2010). Sitatet i innledningen understreker dette i klartekst: Den største utfordringen i smidige prosesser er å få samspillet i de smidige teamene til å fungere effektivt (Clark, 2022). I denne artikkelen undersøker vi derfor hvilke utfordringer som kan oppstå i smidige team. Vi baserer artikkelen på intervjudata av 72 teammedlemmer fra fem ulike virksomheter, og vi finner at det særlig er utfordringer knyttet til mål, autonomi, roller og innovasjon som går igjen på tvers av teamene. Gjennom å utforske ulike teamutfordringer ønsker vi å diskutere hvilke implikasjoner dette har for ledelse av smidige team. Det korte svaret er at smidige team gir fleksibilitet og hurtighet, men krever løpende justeringer og avklaringer. I det følgende kan du lese hvordan dette kan gjøres. 

Smidige team: hva vet vi? 

Smidige utviklingsmetoder er gjerne brukt som et paraplybegrep for å beskrive ulike metoder i programvareutvikling (Dybå & Dingsøyr, 2008), som igjen er basert på det såkalte agile manifest, der fire agile prinsipper ble foreslått av fremtredende programvareutviklere i 2001 (Hohl et al., 2018). De fire prinsippene – personer og samspill, programvare som virker, samarbeid med kunden og reaksjon på endringer – viser betydningen av at mennesker bør organiseres i små, kryssfunksjonelle team for å raskt kunne svare på endringer i samarbeid med kunden (Lindsjørn, et al., 2016). Til forskjell fra tradisjonell programvareutvikling (ofte kalt fossefallsmetoden) der man fokuserer på individuelt arbeid, spesialister, ledere som tar beslutninger, lite kundekontakt og større team, er smidig programvareutvikling kjennetegnet av samarbeid, tett kundekontakt, delt beslutningstaking og små og tverrfaglige team (Vinekar, et al., 2006). Ifølge Rigby, et al., (2016) viser en rekke studier at smidige metoder fører til økt produktivitet og høyere tilfredshet blant ansatte, i tillegg til økt kundetilfredshet og at ledere får bedre tid til å jobbe helhetlig med organisasjonen. 

Smidige team er typisk heterogene team som anvender ulike smidige praksiser som for eksempel Scrum, Kanban, eXtreme Programming etc. (Przybilla, et al., 2018). Selv om det kan virke som smidige team legger stor vekt på tekniske elementer (programvareutvikling), trekkes det i litteraturen frem at mange av problemene som kjennetegner disse teamene, er psykologiske og sosiale heller enn teknologiske (Hennel & Rosenkranz, 2021). 

I den senere tid har vi fått mer kunnskap om sentrale utfordringer i agile team, og også hvilke elementer som må være på plass for å lykkes. Moe et al. (2010) gjennomførte et feltarbeid over ni måneder der de undersøkte ulike utfordringer som hadde oppstått for team som nylig hadde implementert Scrum. De fant at teamene slet med å fungere som team fordi de hadde svak teamorientering. Siden de var vant til stor individuell autonomi, slet de med å koordinere sine aktiviteter innad i teamet. De strevde også med å få til distribuert teamledelse, som gjerne er et mål i smidige team, og teamleder ble derfor mer autoritær i stilen og klarte i liten grad å få de andre i teamet til å ta ansvar. I tillegg hadde de utfordringer med å gi tilbakemeldinger til hverandre og å kommunisere og interagere innad i teamet. Strode, Dingsøyr, and Lindsjorn (2022) gjennomførte en kvalitativ studie samtidig som de sammenfattet og utvidet tradisjonelle teameffektivitetsmodeller. Dette resulterte i den såkalte ATEM-modellen (agile teamwork effectiveness model). Ifølge denne modellen vil agile team være effektive dersom de innehar delt ledelse, teamorientering, redundans, tilpasningsevne og kollega-feedback. 

Til tross for denne utviklingen og en bedre forståelse av elementer som kan forbedre agile team, er det likevel mye med smidige team vi enda ikke har forstått, og hvorfor de eventuelt skulle virke bedre. Vi trenger derfor mer kunnskap om selve samspillet i de smidige teamene. 

Metode 

Data til studien er samlet inn ved hjelp av masterstudenter ved Norges Handelshøyskole i tidsperioden 2019–2021. Tabell 1 viser en oversikt over syv masteroppgaver og deres datagrunnlag med hensyn til problemstilling for oppgaven, antall team, antall informanter, beskrivelse av informantenes roller, metode som er anvendt, og i hvilken bransje studiene er gjennomført. Alle masteroppgavene benyttet seg av en tradisjonell casemetodikk for innsamling av data. For en nærmere beskrivelse av de ulike metodene til hver av oppgavene henvises leseren til den enkelte masteroppgaven (Austrheim & Lam, 2021; Christensen & Gustafsson, 2020; Gunby & Kandiah, 2021; Hestad & Solheim, 2021; Monsen, 2019; Olsen & Erlandsen, 2019; Sandvik & Engen, 2020). 

Caser 

Alle teamene er rekruttert ut fra kriteriet om at de jobber smidig og bruker ulike smidige metoder (Scrum, Kanban, eXtreme Programming e.l.). Det varierte noe hvor lang erfaring virksomhetene hadde med bruk av smidige metoder (fra ett år til 15 år), og hvor store virksomhetene var (fra 30 til flere hundre personer). Alle teamene var tverrfaglige og besto av et sett uttalte roller som for eksempel scrum master, team lead, utviklere, designere, prosjektledere, osv. 

Data 

Data ble samlet inn gjennom intervjuer, observasjoner og sekundærdata. Det varierte noe i hvilken grad masterstudentene hadde anledning til å observere de ulike teamene. Til sammen ble det gjennomført intervjuer med 72 informanter. I tillegg ble det gjennomført en rekke uformelle samtaler i forbindelse med observasjonene av møter, lunsjmøter og sosiale samlinger. Sekundærdataene besto hovedsakelig av dokumenter som omtalte hvilke smidige systemer og metoder de ulike virksomhetene hadde innført. Datainnsamlingen for alle teamene ble meldt inn og godkjent av Norsk senter for forskningsdata (NSD). 

Alle intervjuene ble gjennomført ved bruk av intervjuguideri og var semistrukturerte. De syv masteroppgavene hadde noe ulike nyanser i forskningsspørsmålene, men intervjuguidene var tematisk overlappende og ganske åpne i tilnærmingen. Hovedsakelig ønsket vi å avdekke hvordan de ulike teamene hadde opplevd innføring av smidige team, nærmere bestemt hvilke utfordringer og muligheter de hadde opplevd. På grunn av pandemien de siste to årene ble mange av intervjuene gjennomført via Teams eller andre digitale medier. Noen av teamene ble videre observert i sine naturlige omgivelser, som oftest som flue på veggen, det vil si at man ikke aktivt deltok i møtene, men likevel var synlig for teamet. Observasjonene ga for eksempel god innsikt i hvordan teamene gjennomførte ulike stand-ups (15 minutters møter på starten av dagen – del av scrum-metoden), og hvordan de ga hverandre tilbakemeldinger. 

Analyse 

Siden utgangspunktet for studien vår var å kartlegge ulike utfordringer som oppleves i smidige team, kategoriserte vi dataene i ulike tema på tvers av de ulike teamene. Alle de syv masteroppgavene inneholdt elementer knyttet til generelle utfordringer i smidige team, noe som førte til at vi så mønstre på tvers av de ulike teamene. Selv om teamene som ble studert, var fra ulike virksomheter og hadde ulik erfaring (tid) med å jobbe i smidige team, var det forbausende hvor mye overlapping vi fant i hvilke utfordringer teamene opplevde. Vi dannet oss et bilde av særlig fire elementer som gikk igjen, nemlig mål, autonomi, roller og innovasjon. Vi søkte derfor videre gjennom rådataene (de 72 intervjuene) for å kartlegge hvilke utfordringer som i stor grad var felles for de ulike teamene, og fikk bekreftet den første antakelsen om fire elementer. I resultatdelen presenterer vi de fire elementene gjennom bruk av såkalt «vis og fortell» - teknikk (Golden-Biddle & Locke, 1997). 

Resultater 

Vi vil i det følgende se nærmere på de fire elementene som fremsto som mest sentrale i dataanalysen: (1) mål, (2) autonomi, (3) roller og (4) innovasjon. Tabell 2 oppsummerer hovedpunktene. 

Mål 

Et viktig element i smidige team er at teamene skal ha et felles mål å jobbe mot, men også at teamenes mål er i overensstemmelse med et overordnet strategisk mål (Moe et al., 2010). På tvers av de ulike virksomhetene fant vi at det er flere elementer knyttet til målforståelse som skaper utfordringer. Nærmere bestemt er det utfordringer knyttet til (1) å se helheten i organisasjonen når teamene har skarpt søkelys på egne mål, (2) at det skapes uheldig konkurranse på tvers av teamene når man blir for opptatt av eget teams mål, og (3) tidspresset som oppleves gjennom sprintene, som forskyver oppmerksomheten fra mål over på oppgavene som skal utføres. Sitatet under viser hvordan et teammedlem mener det ideelt sett bør være, men mener de ikke får til fordi de mister den helhetlige målsettingen av syne: 

[…] jeg tenker at ledelsen bør ta et ansvar for å sikre at de overordnede målene for selskapet og retning er på plass. Så blir det opp til teamene å se ut ifra de oppgavene de har, hvordan de kan sette seg mål og delmål som bidrar til at selskapet når sine overordnede mål. Så jeg tenker det er en todeling der. 

I en annen virksomhet legges det vekt på følgende knyttet til overordnet mål og delmål: 

Vi har nok en vei å gå på kommunisering av mål for eksempel, og strategi. Litt sånn den der overordnede […] hvorfor gjør vi egentlig det vi holder på med. Den kommunikasjonen er nok mindre tydelig nå. 

Oppsummert ser vi at det kan bli forvirrende for teamene hvis de ikke ser det overordnede bildet og blir mer opptatt av egne mål i teamet. I enkelte virksomheter førte dette også til uheldig konkurranse mellom teamene: 

[…] og det er også litt sånn vanskelig med å få tillit på tvers av teamene at liksom «Ja, men det [problemet] har et annet team [allerede] løst. Det kan faktisk være skikkelig bra» og da blir det nesten litt sånn, nå setter [jeg] det litt på spissen da, men at internt i butikken at «Ja, men hvis ikke vi har løst det, så er det ikke bra», sant. Og det blir litt sånn intern konkurranse i teamene, «Hvem som har den beste løsningen på en gitt funksjonalitet», for eksempel. 

Så i stedet for å tenke at teamene til sammen har hjulpet organisasjonen fremover, kan det bli misnøye når teamet selv ikke har vært del av løsningen. Videre fant vi også at selv om mange av teamene kunne kjenne til hvilke mål de jobbet mot innad i eget team, førte tidspress og stadige sprinter til at man kan miste teamets eget mål av syne, noe følgende sitat viser: 

[…] målene i seg selv er jo litt sånn der, at du sitter og kjenner litt på stresset. At det ikke ... det er mer det, enn at sånn yes, kom igjen, dette skal vi, vi skal der, liksom ... det er mer sånn shit, dette må være ferdig om to uker. 

Hva som faktisk er teamets mål, det er jo og litt vanskelig å si noe om. For vår del føler jeg meg usikker på hvor mye vi har å si, egentlig, for det er hele tiden ting som kommer utenfra, ting du bare må gjøre. 

Sitatet over viser også hvordan man kan miste teamets mål av syne fordi det kommer pålegg utenfra om hva man skal gjøre, som går på bekostning av eget teams mål. Oppsummert kan det synes som at smidige team kan ha nytte av å være sterkere koblet på et overordnet organisatorisk mål som de ser sitt eget teams mål som en del av, og at de innad i teamet bør være oppmerksom på at tidspress kan bidra til at de mister teamets eget mål av syne. 

Autonomi 

Et relatert tema til teamenes mål og en mer helhetlig tilnærming er autonomi. Som nevnt innledningsvis er smidige team typisk autonome team som har stor selvbestemmelse i å sette egne mål og utføre oppgaver i tråd med målet. Et typisk dilemma som ser ut til å oppstå på tvers av teamene, er hvor mye autonomi hvert team skal ha. 

Med den smidige organiseringen følger også en utfordring med å finne en balansegang for hvor mye ledelsen skal involveres i beslutninger som tas innad i teamene. 

Det er en veldig interessant diskusjon, fordi det med autonomi […] det er nok et ord. Folk kan misforstå. Vi oppdager jo faktisk at forskjellige team mener forskjellige ting, men det tar litt tid før du skjønner. At vi mener det. Og vi mener jo det at det skal være autonomi innenfor de prioriteringene og målene som er gitt. Hvordan du skal oppnå de målene, kan godt være at du har autonomi eller selvbestemmelse til å avgjøre. Men du har ikke selvbestemmelse til å gjøre akkurat hva du vil til enhver tid. Hvis du ikke slenger på det når du sier autonomi, så får du misforståelsen. 

Vi har kommet et stykke med autonome team. Men vi har ikke rammet det veldig tydelig inn sånn at det er gode forventninger til både teamet og for ledergruppen hvor grensene går mellom […] altså hvor langt autonomien strekker seg. 

Mens for mye autonomi gjerne kan skape utfordringer knyttet til ivaretakelse av overordnet mål, slik det ble beskrevet over, kan for lite autonomi oppleves frustrerende fordi man ikke får fullført de oppgavene man hadde planlagt. 

Iblant kunne jeg ønske det var mer frihet. Vi hadde jo det her at vi var tvunget til å slutte med en greie, begynne på en ny greie, få den klar og begynne på den andre greien. Jeg hadde gjerne ønsket at vi fikk gjøre klart den første oppgaven. Men da ble det bestemt over våre hoder at – nei, nå skal dere gjøre det her i stedet. Det kan jeg synes er vanskelig. 

Oppsummert er det altså forståelse og aksept for at teamene skal være autonome, men det er fortsatt noen utfordringer knyttet til å finne ut hvor grensen går, og hva teamene kan bestemme selv, og hvor mye ledelsen både skal og kan blande seg. 

Roller 

I smidige team er det i større grad enn tradisjonelle team tydelige roller med ulike kravspesifikasjoner (team lead, scrum master etc.), noe man skulle tro gjorde det lettere å unngå rolleuklarheter og forvirring. Likevel ser vi at det på tvers av de fleste teamene er utfordringer knyttet til rolleforståelse: 

Jeg ser det at flere av dem er usikre på sin egen rolle, og det fører ofte til at det er konflikter når man må ta beslutninger. […] jeg tror at vi har et litt høyere konfliktnivå fordi at de (ansatte) er usikre på rollene sine. 

Alle rollene som skal være i teamet og rundt teamet, er kanskje ikke helt tydelig definert, så det kan nok være noen som føler at de har blitt mindre viktige, kanskje. Altså, de finner kanskje ikke sin plass i teamet da. 

Rolleklarhet handler om å forstå hva egen rolle går ut på, hvem som har ansvar for å kalle inn riktige folk til ulike møter, og også hvem som har endelig beslutningsmyndighet hvis det oppstår uenighet. Eksempelvis nevnes det at i et team med en produkteier, arkitekt, teknisk tester og team lead kan det oppstå uenighet om hvem som endelig kan sette foten ned hvis det oppstår konflikt om hva som skal gjøres: 

Da vil jo arkitekten hevde at «Nei, men dette er teknisk spørsmål, og da er det jeg som er nødt til å kunne sette ned foten». Men så vil produkteieren hevde «Ja, men jeg har bedre oversikt over det funksjonelle behovet, og da lar det seg ikke løse med det tekniske forslaget som du har foreslått». Men hvis team leaden og sier «Men jeg kjenner teamet og kompetansen og kapasiteten vår, og det [gjør at] begge dere to sine forslag ikke er mulig å gjennomføre med manpoweren vi har». Hvem er det da som egentlig skal fatte beslutningen? Hvordan skal vi da håndtere det at det er uenighet internt i teamet? 

Oppsummert kan det synes som at selv med så mye oppmerksomhet om roller og rolleforståelse som det er i smidige team, bør team både snakke om hvordan de ulike rollene opplever grensesnittet opp mot hverandre, og om hvem som har endelig beslutningsmyndighet i spørsmål der man er uenige. 

Innovasjon 

Rigby et al. (2016, p. 42) hevder at «innovation is what agile is all about». Målet er at man gjennom smidige team kan flytte organisasjonen fremover gjennom å implementere nye, innovative ideer. Vi syntes derfor det var interessant at mange av teamene opplevde at de gjennom sprinter og oppgaveløsning fikk lite tid til innovasjon. Sitatet under viser at teamene hadde strukturer som skulle legge til rette for å være innovative gjennom såkalte hackathons, der målet innenfor en fast tidsramme er å komme opp med nye, innovative ideer: 

Vi har hatt hackathon i noen tilfeller. Da gis vi mulighet til å komme opp med ideer. Det snakket vi om nå sist på vår retro, at da vi hadde hatt hackathon, så hadde man ikke tenkt godt nok gjennom på forhånd hva man ville gjøre. Denne innovasjonsdelen var ikke helt startet opp, føltes det som hos mennesker. Det var mange som kom til hackathon og hadde ingen ideer, og jeg tror de egentlig har mange ideer. 

Opplevelsen blant informantene er at de i det daglige jobber med sine oppgaver under tidspress, og hvis det oppstår nye ideer, begrenser tidsrammene innenfor sprinten dem til å forfølge disse ideene, og når de så endelig kan idémyldre i slike hackathons, er ideene borte. Videre viser sitatet under at gjenstående oppgaver (backlog) får mest fokus, og at det ikke er tid til å utvikle nye ideer: 

[…] Det er flere ting vi har diskutert løst og fast i teamet som vi tenker «dette kunne vært kult, eller dette kunne vært lurt å teste» osv. Men vi har en rekke ting som må løses, og da er det ikke så mange som er opptatt av hvilke tanker vi har om hvor vi skal i fremtiden. Det er veldig sånn «har dere gjort det som står på roadmap-en?», på en måte. 

Siden noen av intervjuene var gjennomført under pandemien, kom det også frem at det var spesielt vanskelig å få til nye ideer når man jobbet virtuelt, noe følgende sitat illustrerer: 

[…] Vanskeligere å få til innovasjon fordi man kan diskutere ting helt åpent og den naturlige «her er en idé», og så dukker det opp en ny idé på grunn av den ideen. Det er vanskelig når man ikke sitter sammen. Pluss sånn verktøy som tavler og det å kunne ha en mer uformell kommunikasjon, altså når man diskuterer ting som er vanskelig, så er det ikke bare hva du sier, men hvordan du beveger deg, og det forsvinner jo litt når man er digitalt. 

Oppsummert kan det synes som at tidspress, de faste rammene man jobber under, og prioritering av backlog-oppgaver gjør at det blir for lite tid til innovasjon og åpenhet for nye ideer i det daglige arbeidet preget av tidspress og sprinter. Det kan nærmest synes som at smidige modeller begrenser smidighet og innovasjon. 

Diskusjon 

Smidige team er blitt en populær og foretrukken arbeidsform i mange virksomheter i typisk utvikleravdelinger, men også i mer tradisjonelle avdelinger som marked, HR, forskning og utvikling, og salg. Mye av forskningen på smidige team handler om i hvilken grad denne typen team er effektive eller ikke sammenlignet med mer tradisjonelle team (fossefallmetode) (Hennel & Rosenkranz, 2021). Siden det hevdes at det nettopp er teamdynamikk og interne prosesser som bør utforskes mer for å bidra til å utvikle gode, smidige team, ønsket vi å studere dette nærmere. Gjennom å sammenligne hvilke utfordringer som oppleves av 72 teammedlemmer som jobber i smidige team på tvers av fem ulike virksomheter, fant vi at det var fire tema som utmerket seg: mål, autonomi, roller og innovasjon. I det følgende diskuterer vi hvordan ledere av smidige team kan møte disse utfordringene, og hvordan organisasjoner som helhet kan ta hensyn til dette når de etablerer smidige team. 

Det blir for lite tid til innovasjon og åpenhet for nye ideer i det daglige arbeidet preget av tidspress og sprinter. Det kan nærmest synes som at smidige modeller begrenser smidighet og innovasjon.

For det første: Smidige team er som nevnt autonome team med felles mål. En utfordring knyttet til mål i smidige team var at teamene kan miste av syne både hva som er det overordnede målet for virksomheten, fordi de blir for opptatt av sitt interne mål i teamet, men også eget mål i teamet fordi de blir så fokusert på oppgavene som skal løses, at de ikke ser det overordnede målet i teamet. Tidligere forskning finner også utfordringer knyttet til mål i smidige team, men da gjerne knyttet til individ versus team. Moe et al. (2010) fant at utviklere prioriterte individuelle mål heller enn teamets mål, og dermed slet med å få til god teamorientering innad i teamene. Vi vil anbefale ledere å ta hensyn til utfordringene som fremkommer her når det gjelder mål. Det er positivt for de smidige teamene å vite hvilke helhetlige mål de jobber mot, men de bør ha frihet til å utforme egne mål som understøtter virksomhetens overordnede mål. Lederne av de smidige teamene bør imidlertid være tydelige på at det ikke må utvikles individuelle mål som går på bekostning av teamenes mål, eller at tidspress fører til at man ikke lengre ser hvilket mål man jobber mot, men bare fokuserer på neste oppgave uavhengig av om den er knyttet til teamets mål. 

For det andre: Teamene opplevde utfordringer knyttet til autonomi, i den forstand at det kunne være utfordrende å finne en god balanse i hvor mye ledere overordnet skal blande seg inn i hvilke oppgaver teamene velger å jobbe med, samtidig som det er viktig at de bryr seg om hva teamene produserer og får til. I tidligere forskning ser vi at utfordringer knyttet til mangel på tillit mellom ledere og de smidige teamene kan føre til at teamene opplever manglende autonomi og heller opplever seg kontrollert (Stray, Moe, & Hoda, 2018). Det er derfor viktig for ledere å vise teamene tillit slik at de både kan ta gode valg og selv finne ut av hvordan de skal arbeide. Dette er spesielt viktig i en smidig kontekst, fordi det er uttalt at smidige team er autonome team. Det å bryte denne forventningen om å la teamene bestemme selv, og innføre kontrollregimer, kan oppleves som psykologiske kontraktsbrudd (Rousseau, 1995), noe vi vet har negativ innvirkning på både hvordan medarbeidere opplever og ikke minst utfører jobben. 

For det tredje: På tvers av teamene opplevedes det å være uklarhet i roller og myndighet knyttet til de ulike rollene. Vi har ikke funnet annen forskning som peker på dette som en utfordring i smidige team, men mener at dette er et aspekt som ledere kan og bør ta hensyn til. Som nevnt over er det kanskje noe overraskende at rolleuklarhet oppleves som en utfordring i smidige team, siden det nettopp er så klare og tydelige roller i smidige metoder. En forklaring kan være at uttalte forventninger til roller kan bidra til rigiditet og lite fleksibilitet når man skal løse oppgaver. Som en ledelsesutfordring vil vi oppfordre til at man utforsker og forsøker å avklare grenseoppganger mellom de ulike rollene, og diskuterer hvordan man skal håndtere situasjoner der det blir uklart hvem som har endelig beslutningsmyndighet. 

Til sist vil vi trekke frem utfordringen knyttet til mangel på innovasjon. Som nevnt over handler innføringen i smidige team mye om at teamene skal ha større rom til og metoder for å komme opp med innovative løsninger. Selv om det i teamene vi har studert, absolutt var eksempler på at de kunne komme med innovative ideer, var det også flere som pekte på at de smidige metodene kunne være med på å hindre innovasjon. Våre funn er i tråd med en nyere studie av Annosi, Foss, og Martini (2020). De undersøkte smidig implementering over fire år i samme bedrift og fant at presset på rask levering kunne gå på bekostning av læring og idéutvikling. For ledere er det altså viktig å legge til rette for å stoppe opp og forfølge ideer når de oppstår, selv om det kan gjøre at man må utsette tidsfristen for en leveranse. 

Selv om vi i denne studien har fokusert på utfordringer i de ulike teamene vi har studert, kunne vi også trukket frem hvilke positive elementer som oppleves. Mange av informantene kunne fortelle at de opplevde det å jobbe i smidige team som positivt, og at de hadde stor tro på dette som arbeidsform. Vi valgte å fokusere på utfordringer for å trekke frem elementer som kan gjøre smidige team enda bedre. Funnene fra våre case kan naturligvis ikke generaliseres uten videre, men vi tror at gjennom å ha intervjuet og observert så mange teammedlemmer på tvers av ulike typer virksomheter og med ulik erfaring i bruk av smidige team, har vi tilført kunnskap for dem som vil utvikle sine smidige team. 

Konklusjon 

Smidige team blir stadig mer utbredt. Denne arbeidsmåten bidrar til større fleksibilitet og hurtige prosesser. Å danne smidige team kan derfor utløse mye av potensialet som ligger i teamarbeid. Samtidig krever større frihet sin pris, og denne prisen er mindre kontroll. Lederes oppgave blir å manøvrere i dette landskapet mellom kaos og kontroll. Vi har sett at noen felles utfordringer er å avklare hvor man skal (mål), hvor fritt man skal jobbe (autonomi), hvordan man skal utnytte tverrfaglighet (roller), og hvordan man skal stimulere kreativitet (innovasjon). Dette er utfordringer som er dynamiske, og som vanskelig løses én gang for alle. Man må derfor leve med den spenningen som ligger latent i denne måten å jobbe på. Da er det viktig at smidige team ikke fanges i et hamsterhjul og sprinter hele tiden, men tar seg tid til pauser og kan løfte blikket før man gyver løs på neste sprint. Da holder man kanskje en hel maraton. 

Referanser 

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. 

Austrheim, I., & Lam, C. (2021). Virtuelle, agile team. Hvordan blir agil tilnærming påvirket av virtuelt arbeid og hvordan kan en tilrettelegge for virtuell, agil samhandling [Masteroppgave]. Norges Handelshøyskole. 

Bianchi, M., Marzi, G. & Guerini, M. (2020). Agile, Stage-Gate and their combination: Exploring how they relate to performance in software development. Journal of Business Research, 110, 538–553. https://doi.org/10.1016/j.jbusres.2018.05.003 

Christensen, F. & Gustafsson, F. (2020). Når smidige modeller begrenser smidighet. En casestudie om hvilke begrensinger et smidig rammeverk kan legge for agile team i veletablerte selskaper. [Masteroppgave]. Norges Handelshøyskole. 

Clark, T. R. (2022, 21. februar). Agile doesn’t work without psychological safety. https://hbr.org/2022/02/agile-doesnt-work-without-psychological-safety 

Dingsøyr, T., Nerur, S., Balijepally, V. & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85(6), 1213–1221. https://doi.org/10.1016/j.jss.2012.02.033 

Dybå, T. & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9), 833–859. https://doi.org/10.1016/j.infsof.2008.01.006 

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

Gunby, J. & Kandiah, C. (2021). Muligheter og utfordringer i agile team: En kvalitativ casestudie av hvilke sentrale muligheter og utfordringer som kan oppstå i veletablerte agile team, og hvordan læring og kompetanseutvikling av teammedlemmer blir ivaretatt. [Masteroppgave]. Norges Handelshøyskole. 

Hennel, P., & Rosenkranz, C. (2021). Investigating the «Socio» in Socio-technical development: The case for psychological safety in agile information systems development. Project Management Journal, 52(1), 11–30. https://doi.org/10.1177/8756972820933057 

Hestad, S., & Solheim, L. (2021). Spenningen mellom kaos og kontroll. En eksplorativ casestudie om hvordan etablerte selskaper kan lykkes med agil ledelse og organisering av agile team i reisen mot å bli smidige. [Masteroppgave]. Norges Handelshøyskole. 

Hohl, P., Klünder, J., van Bennekum, A., Lockard, R., Gifford, J., Münch, J., Stupperich, M. & Schneider, K. (2018). Back to the future: Origins and directions of the «Agile Manifesto»–views of the originators. Journal of Software Engineering Research and Development, 6(1), 1–27. https://doi.org/10.1186/s40411-018-0059-z 

Lindsjørn, Y., Sjøberg, D. I., Dingsøyr, T., Bergersen, G. R., & Dybå, T. (2016). Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, 274-286. https://doi.org/10.1016/j.jss.2016.09.028 

Moe, N. B., Dingsøyr, T. & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480–491. https://doi.org/10.1016/j.infsof.2009.11.004 

Monsen, G. K. (2019). Utfordringer i Agil Transformasjon: En eksplorativ casestudie om hvilke utfordringer team opplever på veien mot å bli agile. [Masteroppgave]. Norges Handelshøyskole. 

Olsen, A. S. & Erlandsen, J. D. (2019). Samhandling i agile team: Hvordan foregår samhandlingen i agile team, og hvilke særlige utfordringer kan agil samhandling medføre? [Masteroppgave]. Norges Handelshøyskole. 

Panditi, S. (2018, 22. mars). Survey data shows that many companies are still not truly agile. Harvard Business Review. https://hbr.org/sponsored/2018/03/survey-data-shows-that-many-companies-are-still-not-truly-agile 

Przybilla, L., Wiesche, M., & Krcmar, H. (2018). The influence of agile practices on performance in software engineering teams: A subgroup perspective. [Paper-presentasjon]. Proceedings of the 2018 ACM SIGMIS Conference on Computers and People Research. 

Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing agile. Harvard Business Review, 94(5), 40–50. 

Rousseau, D. M. (1995). Psychological contracts in organizations: Understanding written and unwritten agreements. Sage. 

Sandvik, A. & Engen, A. S. (2020). Ledelse av agile team: En eksplorativ casestudie av hvordan ledelse av agile team foregår, og hvilke utfordringer som oppleves i forbindelse med ledelse av agile team. [Masteroppgave]. Norges Handelshøyskole. 

Stray, V., Moe, N. B. & Hoda, R. (2018). Autonomous agile teams: Challenges and future directions for research. [Paper-presentasjon]. Proceedings of the 19th international conference on agile software development: Companion. 

Strode, D., Dingsøyr, T., & Lindsjorn, Y. (2022). A teamwork effectiveness model for agile software development. Empirical Software Engineering, 27(56). https://doi.org/10.1007/s10664-021-10115-0 

Vinekar, V., Slinkman, C. W. & Nerur, S. (2006). Can agile and traditional systems development approaches coexist? An ambidextrous view. Information Systems Management, 23(3), 31–42. https://doi.org/10.1201/1078.10580530/46108.23.3.20060601/93705.4  

NOTER 

Intervjuguidene er tilgjengelige som vedlegg i de ulike masteroppgavene
og kan søkes opp her: https://www.nhh.no/bibliotek/nhh-brage/