Fra agile team til agile organisasjoner i finansbransjen (F)

Sammendrag 

I denne artikkelen undersøker vi hvordan organisasjoner kan skalere opp den agile arbeidsmetodikken til et organisatorisk nivå. Vi sammenlikner to virksomheter i finansbransjen og synliggjør likheter og forskjeller i deres tilnærming til agil organisering. Mens Fana Sparebank benytter fleksible team til å jobbe på prosjekter av midlertidig karakter, har DNB valgt faste team med ansvar for utvikling og drift av nye produkter og tjenester. Felles for begge bankene er at for å kunne jobbe raskt og smidig i stor skala kreves noen strukturer eller prosesser som koordinerer arbeidet. 

Mange virksomheter jobber i dag med å bli mer agile (eller smidige, som det gjerne kalles på norsk). Ifølge en McKinsey-rapport (Inacio et al., 2022) har 44 prosent av respondentene på et globalt spørreskjema startet eller fullført en agil transformasjon i sine selskaper. Hensikten er som regel å sikre at organisasjonen raskere kan tilpasse seg endringer i de eksterne omgivelsene. Virksomheter som allerede har opplevd gode resultater ved å benytte agil metodikk i utvikling av programvare (software), ønsker gjerne å skalere opp den agile arbeidsmåten til å gjelde for større deler av organisasjonen. 

Selv om mange virksomheter jobber med å bli mer agile, finnes det ikke noen enhetlig forståelse av hva det betyr når det trekkes fra programvare- og tjenesteutvikling til organisasjonsnivå. Flere ulike oppfatninger eksisterer side om side i praksis så vel som i forskningen. I praksis brukes begrepet både til å beskrive hvordan arbeid konkret utføres, og hvordan hele virksomheten organiseres. I forskningen finner vi også en rekke ulike definisjoner som befinner seg på forskjellige nivåer – noen er knyttet opp til konkrete IT-prosjekter, andre til arbeidsmetoder mer generelt, mens der også skrives om agile team, organisasjoner, ledere og strategier. 

I denne artikkelen trekker vi på studier av to norske banker – Fana Sparebank (FSB) og DNB – for å undersøke hva som kjennetegner en agil organisasjon, og hvordan en agil organisasjon ser ut i praksis. Vi finner at der er en felles kjerne som først og fremst handler om agile arbeidsmetoder, men at agil organisering ellers innebærer ulike ting. For eksempel innføres en felles struktur i DNB for å koordinere autonome team, mens FSB innfører et felles sett med prosesser. Vi drøfter fordeler og utfordringer med de to ulike tilnærmingene bankene har valgt. Formålet er å illustrere at agil organisering kan gjøres på ulike måter, samt drøfte hva som kan ligge til grunn for valg av den ene eller den andre tilnærmingen. 

Agile arbeidsmetoder 

Ideene om agilitet kommer fra programvarebransjen. Som beskrevet i artikkelen til Sverdrup og Schei (denne utgaven av Magma) etablerte en gruppe programvareutviklere i 2001 et manifest (The Agile Manifesto) for å beskrive en alternativ måte å jobbe på med utviklingsprosesser innenfor IT (Rigby et al., 2016). Eksisterende arbeidsmetoder ble oppfattet som for kompliserte med sin detaljerte dokumentasjon, som gjorde prosessene trege. Tradisjonelle utviklingsprosesser fulgte også ofte den såkalte fossefallsmetoden, som er en lineær, stegvis tilnærming som ofte tar lang tid – gjerne opptil flere år. 

Det agile manifestet var imidlertid mer en filosofi enn noe konkret. Manifestet består av fire verdier som fremhever at menneskene og samhandling mellom mennesker er det aller viktigste (Beck et al., 2001; LeMay, 2019 – se også Sverdrup & Schei i denne utgaven for en nærmere beskrivelse). Det finnes en omfattende forskningslitteratur som omhandler agil fra et IT-perspektiv (se oversiktsstudier Dybå & Dingsøyr, 2008; Dingsøyr et al., 2012 samt Dingsøyr et al., 2019 om skalering av agil programvareutvikling). 

Agil organisering handler ikke bare om nye arbeidsmetoder og tverrfaglig samarbeid (…), men også om hvordan hele organisasjonen er strukturert for å sikre raskere tilpasning til endringer i markedet.

For å utvikle en bedre forståelse av hvordan agilitet ser ut i praksis når man tar sikte på å innføre dette på organisasjonsnivå, sendte vi en rekke masterstudenter ved Norges Handelshøyskole (NHH) ut for å undersøke hva som kjennetegner virksomheter som beskriver seg selv som agile. Studentene har jobbet med casebedrifter på tvers av bransjer (Førland & Klemp, 2021; Glesne & Pedersen, 2020; Kamath, 2020; Løvik, 2020). Kjennetegn som går igjen på tvers av bedriftene i finans-, medie- og konsulentbransjene, er tverrfaglige team som arbeider etter et tydelig mandat, men med stor grad av autonomi til å sette sine egne delmål og legge opp arbeidsprosessen på egen hånd, slik de ser at jobben best kan bli gjort. De agile teamene kopler derfor ofte sammen IT-utviklere med personer som har god kjennskap til forretningen. Teamene er som regel samlokalisert og arbeider i tett dialog med kunden. Komplekse oppgaver brytes opp i mindre biter, og teamene jobber i intensive perioder, såkalte sprinter, med å løse en konkret oppgave. En sprint kan vare i to uker, hvorpå noe konkret skal leveres og/eller testes ut av kunden. Med disse arbeidsoppgavene følger et nytt språk. I tillegg til sprinter (korte tidsfrister) snakkes det gjerne om tribes eller familier (sammensatt av flere team), scrum (et rammeverk som beskriver arbeidsprosessen), kanban (tavler som viser arbeidsflyten) og produkteier (personen som er ansvarlig for produktet/tjenesten teamet skal levere). Noe av tankegodset og språket overlapper med andre organisasjonstrender, som lean. 

I masteroppgavene fant studentene at agile arbeidsmetoder gir fleksibilitet og tempo for produkt-/tjenesteutvikling ut mot kunden. Eksemplene på innovasjon var som regel knyttet til produkt-/tjenesteinnovasjon, nye apper og liknende, mens det var få umiddelbare tegn til mer radikale innovasjoner som handler om at virksomheten skal gjøre noe helt annerledes. Ifølge McKinsey (Inacio et al., 2022) er virkningen av agil transformasjon økt effektivitet, engasjement blant ansatte og cirka 30 prosent bedre driftsresultat (operational performance). 

Det McKinsey omtaler som den agile transformasjonen, handler ikke kun om agile arbeidsmetoder eller enkelte team, men et helt nettverk av team. Vi har imidlertid begrenset forskningsbasert kunnskap om hvordan en agil organisasjon ser ut, og hva som er fordeler og ulemper med å skalere opp tenkningen og filosofien til å innbefatte større deler av organisasjonen utover rene utviklingsprosjekter for programvare. Det er nettopp dette vi vil se nærmere på i resten av artikkelen. 

Fra agile team til agile organisasjoner 

Agil organisering handler ikke bare om nye arbeidsmetoder og tverrfaglig samarbeid (for eksempel mellom IT og forretning), men også om hvordan hele organisasjonen er strukturert for å sikre raskere tilpasning til endringer i markedet. Mens det agile teamet leverer nye produkter og tjenester i et høyt tempo, handler den agile organisasjonen vel så mye om å strukturere og organisere hele virksomheten slik at arbeidet skjer sømløst og uten for store koordineringskostnader: 

En agil organisasjon har organisasjonsstrukturer og administrative prosesser som er raske og sømløse og skaper verdi for kunden. 

(Gunasekaran, 2001) 

En agil organisasjon består av mange autonome og kundefokuserte team – noe som vil kreve en viss samordning i form av enten strukturer eller prosesser. 

Doz og Kosonen (2010) introduserer begrepet ressursflyt (resource fluidity) og beskriver agil organisering som evnen til å raskt og effektivt allokere ressurser. På samme måte er Teece et al. (2016) opptatt av evnen til å effektivt omdirigere ressurser, og de definerer agil organisering som: 

[…] organisasjonens evne til å omdirigere ressurser på en effektiv måte i retning av mer verdiskapende aktiviteter når interne eller eksterne omstendigheter krever det. 

(Teece et al., 2016) 

Blant konsulenter og praktikere beskrives agil organisering gjerne som en måte å bryte ned hierarkiet og siloer på (se for eksempel Aghina et al., 2018). Det tverrfaglig samarbeidet i team skal sikre at tempo og kundeorientering står i fokus fremfor hierarki og avdeling, og således bidra til raskere tilpasning og innovasjon. Samtidig viser studier og erfaringer at de agile teamene ofte møter hindringer ved at resten av organisasjonen fortsatt er mer tradisjonelt organisert. Så hvordan ser egentlig den agile organiseringen ut? Hvordan koordineres mange autonome og tverrfaglige team? Og hvordan kan man sikre effektiv flyt av ressurser ut fra raskt endrede behov? Dette er forskningen fortsatt uklar på. 

Metode 

For å undersøke hvordan agil organisering ser ut i praksis, trekker vi på data fra studier og masteroppgaver i RaCE-prosjektet ved NHH. 

Vi rapporterer hver 14. dag om hva vi har gjort, og hva vi skal gjøre fremover (…) Alle ansatte kan komme og lytte til hva vi gjør. Fremdrift og rapportering er helt transparent (…)

Fana Sparebank ble valgt fordi de har fortalt om hvordan de utviklet et helt nytt forretningskonsept (Himla) gjennom agile arbeidsmetoder. Konsernleder Marianne Wik Sætre, som var sentral i dette arbeidet, har beskrevet hvordan banken jobber i sprinter (Lem, 2018). Med bakgrunn i dette gjennomførte masterstudentene Cornelia Lindqvist og Sindija Liepina tre intervjuer med sentrale ledere rundt utviklingen av Himla høsten 2018. To år senere, høsten 2020, gjennomførte Samyuktha Kamath ytterligere ti intervjuer og gjorde feltobservasjoner (delvis dokumentert ved fotografier) knyttet spesifikt til de agile arbeidsmetodene som da var implementert i større skala. Kamath intervjuet ledere, prosjektledere, produkt- og forretningsutviklere, leder av kundeservice, leder av digital eiendomsmekling, leder og kunde av digitale rådgivningstjenester advisory samt IT-utvikler. Masteroppgavene var i hovedsak beskrivende, men søkte også å vurdere om og hvordan agil organisering bidro til å utvikle virksomhetens innovasjonskapasitet. Datasettet består også av dokumentasjon, som strategidokumenter og publisert intervju i tidsskriftet Magma (Lem, 2018). Til sist består datasettet av uformelle samtaler forfatterne har hatt med sentrale ledere i banken. 

DNB ble valgt fordi de har gått langt i å organisere virksomheten i agile familier. Vi gjennomførte en serie med intervjuer av nøkkelinformanter i DNB og kartla deres innovasjonsreise fra en tradisjonell bank til et innovativt, mer teknologirettet selskap (se case om DNBs innovasjonsreise i Meyer et al., 2022). I skrivingen av denne artikkelen har vi trukket på seks av intervjuene med toppledere og mellomledere i DNB som omhandler agil organisering. Arbeidet med å kartlegge DNBs innovasjonsreise dannet samtidig utgangspunkt for å grave litt dypere i den agile organiseringen, og masterstudentene Iselin Førland og Sara Klemp gjennomførte en studie av innføring av agil organisering i DNBs IT-avdeling med over 1 000 medarbeidere. De intervjuet tolv ansatte i ulike roller – familieledere, teamledere, teammedlemmer og interne konsulenter – og fikk også tilgang til et internt dokument som kartla hindringer for innføring av agile arbeidsmetoder. 

Studentene formulerte egne forskningsspørsmål i samarbeid med veileder og casebedrift. For å belyse hvordan agil organisering ser ut i praksis, har forfatterne gjennomgått dette datamaterialet samt intervjuene fra en tidligere studie i DNB på nytt, og kodet dataene på nytt ved en induktiv tilnærming hvor man søker å holde seg så nært respondentenes ordbruk som mulig. I motsetning til masteroppgavene, som går i dybden på ett case på ett konkret tidspunkt, er fokuset i denne artikkelen en sammenliknende analyse hvor vi også ser på utviklingen over tid. Deretter har vi lagt en felles struktur på casene slik at det skal være enklere å følge og sammenlikne dem. 

Agile prosjekter i Fana Sparebank 

Fana Sparebank har siden 2016 organisert omtrent 20 prosent av staben i prosjekter som arbeider i sprinter. Resten av banken er organisert mer tradisjonelt, men sentrert rundt kundeorientering, slik at digitale rådgivere innen privatmarked og kundesenter er plassert tett på produkt og IT-utvikling. Prosjektteamene består av tre til fem personer som settes sammen basert på kompetansen som trengs for å løse en definert oppgave, og teamene benytter agile metoder kombinert med lean for å løse oppgaven. Den nye organiseringen har gitt fart til innovasjonstakten og skapt motivasjon og engasjement blant ansatte som jobber i prosjektteamene, men den bringer også noen potensielle utfordringer. 

Omtrent samtidig som banken endret organisasjonsformen, ble det også gjort endringer i strategiprosessen. Fra å utvikle store, tunge strategidokumenter gikk man over til korte notater med definerte satsningsområder. I perioden 2016–2020 var de fem satsningsområdene kroner, kunder, digital, mennesker og samfunn. Prosjektene som velges ut, knyttes tett opp til strategien og defineres innenfor ett eller flere av de fem satsningsområdene. 

Fra funksjonsorganisering til agile prosjekter 

Det er ikke uvanlig at nye ledere har med seg et nytt og annerledes blikk på hvordan arbeid organiseres og utøves. Så også i Fana Sparebank. Den agile tilnærmingen var i Fana Sparebank i stor grad drevet frem av nye ledere. 

Etter fire til fem års erfaring med den agile måten å jobbe og organisere arbeid på beskriver ansatte forskjellene. Det er stort sett positive erfaringer som trekkes frem, knyttet til oversikt, tydelig prioritering og følelsen av å være innovativ og frempå. 

Ansatte hadde tidligere liten kjennskap til strategi og hva man prøvde å oppnå: 

Tidligere hadde vi strategidokumenter på flere hundre sider. Nå er det kanskje 30–40 slides […] og mye bilder. Vi bruker sprintene til å synliggjøre kort sikt fremfor det langsiktige […] vi bruker bilder på veggene. Hvis du jobber her og ikke vet hva vi holder på med, så må du ha lukket øynene veldig bevisst. Strategidokumentet henger praktisk talt på veggen. Det er kortfattet og enkelt å lese. 

(Intervju 3) 

Det var også vanskelig å få oversikt over hvem som gjorde hva, og hva som skulle prioriteres: 

Vi hadde langsiktige mål [tidligere], men du var ikke sikker på hvem som hadde ansvar, og hvilke prosjekter som var i gang. Ansatte hadde ikke oversikt […] Nå henger alt på veggen slik at alle kan se. 

(Intervju 4) 

I den over 100 år gamle banken så man på seg selv som tradisjonell og kanskje også litt sidrumpa; de strevde med å følge med på endringer i de eksterne omgivelsene, og det skjedde ikke så mye nytt: 

Vi var veldig entusiastiske [etter at vi lyktes med Himla] fordi dette var noe helt nytt, og det gjorde at vi ikke følte at vi bare var en gammeldags bank som har vært her i 200 år og gjort det samme hele tiden. Nå er vi i forkant og gjør noe nytt. 

(Intervju 5) 

Den tradisjonelle funksjonsorganiseringen med IT, markedsføring, kundeoppfølging osv. organisert hver for seg, ble endret. I stedet for funksjoner ble kundereiser lagt til grunn, og deler av banken ble organisert i prosjekter, med et sterkt innslag av ideer og arbeidsmåter fra det agile og lean. Den nye organiseringen kan dermed beskrives som agile prosjekter. 

De agile prosjektene følger en strukturert prosess. Det legges opp til to prosjektløp per år. Hver januar og august velges prosjekter ut, bemannes og settes i sprinter som typisk varer i 16 uker. Dersom oppgaven er større og krever lengre tid, kan prosjektet strekke seg over flere sprintperioder, men poenget er at alle ansatte vet når prosjekter velges og bemannes. Dette ligger fast. Alle ansatte kan spille inn ideer til prosjekter. 

Ved å strukturere arbeidet i små sprinter forstår ansatte strategien bedre og kan følge med på utviklingen. 

(Intervju 1, leder) 

Ledelsen velger ut prosjekter og prioriterer dem som bidrar til de strategiske satsningene. Slik sett er prosjektene tett knyttet til strategi og verdisett. 

Vi bruker verdiene og de strategiske satsningene våre aktivt når vi skal ta beslutninger. Vi har fem strategiske målområder […] og vi prøver å sikre at vi har minimum ett prosjekt innenfor hvert, og vanligvis er det balansert med tre–fire i hvert. Jeg tar med meg forslagene inn i ledergruppen, ofte jobber jeg med mine ledere først for å vurdere hvor mye for eksempel IT-utviklerne eller markedsførerne klarer å håndtere, vi estimerer og prioriterer, og deretter tar jeg en runde med den ledergruppen jeg sitter i. 

(Intervju 1, leder) 

Der er ingen faste team. Prosjektene bemannes ut fra kompetansebehov, og den enkelte ansatte vil som regel jobbe på flere prosjekter parallelt. Teamet består av en kjernegruppe på tre til fem personer som også kan trekke inn annen kompetanse etter behov. 

For å bemanne prosjektene som skal i sprinter, lager vi et spørreskjema slik at ansatte kan krysse av på de prosjektene de ønsker å være med på, og de kan også notere om de ønsker å være prosjektleder. Deretter setter jeg meg ned med prosjektlederne og spør hva de mener de trenger. Vi setter mandatet og bemanner ut fra ressursbehov, for eksempel én med markedsføringskompetanse, én utvikler, men den trenger først å komme inn litt senere, osv. 

(Intervju 1, leder) 

Alle får jo ikke det de ønsker. Noen ganger er det viktig med en spesifikk person, andre ganger med en spesifikk kompetanse. 

(Intervju 2) 

Når prosjektene er valgt ut og bemannet, har de stor grad av autonomi for hvordan de velger å løse oppgaven og legge opp arbeidet. Men også her er det noen faste rammer og strukturer. Alle prosjekter starter med en kick-off hvor de klargjør hvordan de skal jobbe, og gjerne diskuterer verdier og hva som skal til for å lykkes, for eksempel hvordan de skal etablere tillit i teamet. 

Rapportering er transparent og foregår ved hjelp av stående møter hvor man gjør utstrakt bruk av visuelle bilder for å formidle status, fremdrift og planer. Møtene er åpne for alle i banken, og her deltar også gjerne ledere for å holde seg oppdatert og komme med innspill: 

Vi rapporterer hver 14. dag om hva vi har gjort, og hva vi skal gjøre fremover […] og det er ganske pinlig å måtte rapportere at en ikke har levert, eller at en ikke har kontroll […] Alle ansatte kan komme og lytte til hva vi gjør. Fremdrift og rapportering er helt transparent […] og involveringen fra andre enheter er mye større nå. 

(Intervju 2) 

I etterkant av sprinten bruker teamene tid på å reflektere og lære, slik at neste prosjekt skal gå enda bedre. Flere ansatte beskriver også at de opplever personlig utvikling gjennom refleksjonsøvelsene: 

Det er veldig hektisk i 16 uker, men så har vi en pause helt til slutt før vi starter en ny sprint […] Vi ser tilbake på hva vi har gjort, og hva vi kan gjøre bedre. Så hver sprint blir litt annerledes, og vi lærer masse om hvordan vi kan gjennomføre sprinter, hvordan vi kan knytte oss til andre prosjekter, men vi lærer også masse om oss selv. Hva må jeg gjøre bedre, hva trenger jeg å lære meg? 

(Intervju 3) 

Selv om prosjektteamene har stor grad av autonomi, arbeider de ikke lederløst. Tvert imot spiller ledelsen en viktig og tydelig rolle. Som nevnt er det ledelsen som har bygget opp rammene rundt arbeidet, og som velger ut og bemanner prosjektene. I tillegg er ledelsen tett på under sprintene. De deltar i «stående» møter og er tilgjengelige for å gjøre raske avklaringer, for eksempel ved å sette av én time hver morgen til å bidra i beslutninger og fjerne hindringer. 

Ved å organisere banken på denne måten oppnår en større fleksibilitet i ressursene. Arbeidsformen bidrar også til mer effektiv samhandling fordi teamene får tilgang til annen kompetanse: 

Det er stor grad av fleksibilitet med hensyn til ressurser. Lederne er fleksible: «Okay, hvis du trenger noen av mine ansatte i to dager for å gi innsikt til prosjektet – vær så god. Perfekt.» Dette er ikke noe problem. Jeg låner ut mine ansatte hele tiden […] 

(Intervju 4) 

Samtidig gir det ro til å fullføre oppgaver og en tydeligere prioritering. Nye oppgaver som oppstår, skal som hovedregel vurderes i forbindelse med neste sprint, og ikke stjele oppmerksomhet og ressurser. Det kan imidlertid bety at man er mindre fleksibel til å raskt ta andre presserende oppgaver som oppstår: 

Med sprintene har vi bestemt hva som skal gjøres, og dersom en leder sider at «nå vil jeg ha dette gjort», sier vi «ok, vi skal kikke på det når vi setter opp neste sprint i januar» […] Alle kjenner prioriteringene […] 

(Intervju 1) 

Fordi ansatte jobber med ulike personer i de ulike prosjektene, flyter informasjonen godt, og ansatte får oversikt. Kombinert med stående møter, som er åpne for alle, blir oppgaver og fremdrift transparente: 

Jeg er mer oppmerksom på hvor mange ting som foregår parallelt. Tidligere kunne jeg være på et prosjekt ett år og fokusere på det prosjektet og ikke så mye annet. Men nå har jeg mulighet til å være med på flere prosjekter i kortere perioder. 

(Intervju 4) 

Ansatte har en bedre forståelse for hva alle andre arbeider med. Tidligere satt alle på sin egen pult og tenkte at de arbeidet mer enn andre, men nå vet de hva alle andre gjør, og at alles bidrag er viktig. 

(Intervju 10) 

I tillegg til bedre oversikt, prioritering og effektivitet skaper den nye samarbeidsmåten stort engasjement blant ansatte. De blir proaktive og nysgjerrige på hva andre både i banken og rundt banken driver med, og hvordan de arbeider: 

Det gir motivasjon og selvtillit [å jobbe på denne måten] […] Vi er mye mer åpne for tredje part og har møter med eksterne. Vi har et blikk ut mot verden på en annen måte enn vi hadde før. 

(Intervju 2) 

Fordi vi jobber i mindre prosjekter, blir vi veldig oppmerksom på hva andre (utenfor banken) gjør. Hvordan kan vi skille oss fra andre, hva kan vi gjøre eksakt på samme måte, men med en liten twist […] Vi er ofte ute og besøker andre og spør «hva gjør dere?» 

(Intervju 3) 

Utfordringer og begrensninger 

Virksomheter som innfører agile arbeidsmetoder og gir hvert enkelt team stor autonomi, uten å se på helheten, opplever gjerne at det oppstår koordineringsutfordringer mellom teamene. Det ene teamet vet for lite om hva de andre teamene gjør. Dette har Fana Sparebank løst ved den sentraliserte prosessen og ved å knytte alle prosjektteam tydelig opp mot strategiske satsningsområder. En slik strukturert og overordnet prosess vil være enklere å få til i en relativt liten organisasjon (cirka 70 personer i FSBs avdeling) enn i en større organisasjon med mange tusen ansatte. Løsningen FSB har valgt, er hybrid ved at mesteparten av banken fortsatt er mer tradisjonelt organisert. Slik sett vil en potensiell utfordring som nevnes av noen få informanter, kunne være spenninger mellom de agile delene av organisasjonen og de tradisjonelle: 

I denne etasjen/avdelingen er tempoet veldig høyt. Det er mye som foregår, men i den andre etasjen er det roligere. Det er mer enn nok å gjøre, men det gjøres i et lavere tempo. Noen ganger blir vi for raske her, og det blir vanskelig for de andre å følge med […] noen ganger må vi roe ned tempo slik at vi matcher resten av organisasjonen, fordi hvis vi pusher for mye, får vi ikke en god forståelse for produktene. 

(Intervju 6) 

Spenninger vil kunne oppleves forskjellig avhengig av hvor i organisasjonen man sitter, og det er viktig å påpeke at våre studier kun har fanget opp opplevelsen til dem som jobber i agile prosjektteam. 

De agile prosjektene blir også i noen tilfeller veldig avhengige av eksterne partnere. Dette vil åpenbart også kunne være en utfordring ved andre måter å organisere arbeidet på, men det synliggjør at ikke alt handler om teamenes autonomi og tempo – andre rundt teamet må også kunne levere. 

Vårt prosjekt skulle vært ferdig i løpet av året, men det er ikke mulig. Det er på grunn av at interne prosesser tar lengre tider, men mest på grunn av interne eller eksterne businesspartnere vi bruker til løsninger. Når de har «setbacks» og deres egne prosjekter tar lengre tid, vil det også ta lengre tid for oss. 

(Intervju 8) 

Noen få informanter ser at daglig drift kan bli fortrengt av stadig nyutvikling, men dette er ikke et utpreget trekk ved datamaterialet vårt: 

En nedside med korte sprinter er at de tar så mye tid, og det kan gå ut over min daglige jobb. 

(Intervju 4) 

Det kan fort bli slik at vi har en halvferdig eller halvdårlig kode som kunne vært mye bedre, men så må vi slutte å jobbe på den fordi der er noe nytt. Da skapes en backlog som vi ikke har tid til å ta oss av. Så når vi kjører raske prosjekter, trenger vi også tid til å fikse det vi har lovet å fikse, istedenfor å hele tiden utvikle nytt. Heldigvis er det en god forståelse for det her. 

(Intervju 7) 

Til sist er det enkelte informanter som nevner at agile prosjektteam med stor grad av autonomi, transparens og tidspress kan skape stress på et personlig nivå, men da viser de gjerne til andre enn seg selv: 

Det er høyt tempo, puls, du føler virkelig at du lever. Men det er ikke for alle. Vi har noen som har sluttet fordi det blir for travelt. 

(Intervju 2) 

Kanskje vi innimellom bør stoppe opp og spørre oss selv: Er det viktig at det går så fort? 

(Intervju 3) 

Agile familier i DNB 

DNB har valgt en organisasjonsstruktur for deler av banken der agile team organiseres i produktfamilier – ikke ulikt de strukturene vi finner i banken ING og Spotify. Strukturen er bygget nedenfra og opp, med faste agile team som nøkkelbrikker. De agile teamene inngår i ulike produktfamilier som igjen inngår i ulike divisjoner. Den nye organiseringen har gitt fart til innovasjonstakten i DNB, men også gitt noen utfordringer. 

Behovet for endring mot en mer innovativ og teknologiorientert bank har handlet om mye mer enn agil organisering (Meyer et al., 2022), men det å ta i bruk agile arbeidsprosesser og organisere banken på en mer fleksibel og innovativ måte har vært en viktig bidragsyter i DNBs innovasjonsreise. 

Endring til agil organisering 

Behovet for å bryte med de mer tradisjonelle måtene å arbeide på ble særlig klart da DNB skulle utvikle Vipps. Vipps ble satt opp som et prosjekt med et klart mål om å utvikle en ny betalingsapp på seks måneder og vinne markedet for mobile lommebøker. Styret og ledelsens vurdering var at det ville ta for lang tid å legge dette i et ordinært utviklingsløp, som tar anslagsvis 18 måneder, og dette skapte et behov for å organisere utviklingsarbeidet på en annen og mer innovativ måte. 

Vipps var det første innovasjonsprosjektet der man gikk bort fra tradisjonell utviklingsmetodikk og over til nye og innovative arbeidsmetoder. Behovet for å organisere utviklingsarbeidet på nye, innovative måter var ikke unikt for DNB. Den opprinnelige ideen i mange store konsern var at man kunne drive IT-operasjonene som en fabrikk med tradisjonell fossefallsmetodikk der man organiserte prosjekter i lineære, sekvensielle faser, og der hver ny fase var avhengig av den foregående. 

For noen år siden var det et mantra at IT var en fabrikk. Da var det sånn at når vi kom inn til et nytt prosjekt, så skulle det detaljspesifiseres akkurat hvordan dette skulle se ut […] Det gikk lang tid fra idé til man begynte å lage noe, og så ble det ofte feil, det man laget, dårlig kvalitet. 

(Leder 1) 

Den raske utviklingen av Vipps gav mersmak, og DNB rullet ut den agile metodikken til å omfatte flere utviklingsprosjekter. Målet var å kraftig redusere tiden det tok å bringe nye produkter og tjenester til markedet. I en appell til de ansatte beskrev lederen av IT Transformation hvordan arbeidsprosessene skulle endres for å bli raskere og mer kundeorienterte: 

Vi skal i løpet av de neste årene øke outputen av IT-investeringene og redusere «time to market» for nye produkter og tjenester betydelig. Det betyr at vi må bli enda flinkere på å lage minimumsløsninger som vi kan få fort ut til kundene slik at de raskt kan gi oss tilbakemeldinger som vi kan bruke i videreutviklingen. 

(Lande, 2018) 

Resultatet lot ikke vente på seg, og banken fikk opp tempoet på nye innovasjoner og lanserte flere nye apper, deriblant den nye mobilbanken og spareappen ved hjelp av agil metodikk. I tråd med den nye metodikken var de første versjonene som ble lansert, relativt enkle, for så å bli bygget opp med bedre og bedre funksjonalitet etter hvert som stadig nye versjoner ble lansert. 

Samtidig vokste erkjennelse om at en måtte gjøre noe med organiseringen av banken og oppløse siloene. De som satt i IT-avdelingen, var for langt fra forretningsområdene og kundebehovene, og oppgavene druknet i daglig drift og brannslukning. Samtidig opplevde de som satt på forretningssiden, at de ble sittende og spinne alene med nye og innovative ideer og vente på ressurser fra IT-avdelingen: 

De som satt og kodet, hadde ikke noe sånt spesielt eierskap til det de laget heller, og typisk ble det flere titalls overleveringer i et prosjekt. 

(Leder 2) 

Man måtte splitte opp den litt mastodontiske IT-organisasjonen som hadde levd sitt liv. Den hadde blitt større og større og var veldig mye av en innkjøpsorganisasjon, en forvaltningsorganisasjon og en utviklingsorganisasjon. Den levde for lite tett på det som var forretningen til at den ble kraftfull nok. 

(Tidligere leder 2) 

Gjennom utviklingen av Vipps hadde en også lært hvor effektivt det var å sette IT og forretning sammen i tverrfaglige team, og mer og mer av IT-ressursene flyttet over i forretningsvirksomheten. Dette skapte grobunn for helt nye utviklingsteam og for læring på tvers av profesjonene. I tillegg gav det forretningsenhetene kontroll over knappe IT-ressurser. 

Hver av oss fikk digitale ressurser innenfor vårt forretningsområde. Jeg er ikke spesielt god på teknologi, men resultatet var at du fikk mye bedre innsikt og diskusjoner. Det var fordi vi hadde diskusjonene i våre lederteam, ikke som kunde til IT, men kontroll på våre egne ressurser. 

(Tidligere leder 1 i DNB) 

Utviklingen av Vipps skjedde gjennom et prosjekt, og her opplevde man det som også skjedde i mange andre prosjekter: Man klarte å lage et nytt og innovativt produkt, men da prosjektet var ferdig, lå det mange løse tråder igjen. De som satt på utviklingssiden, hadde mål om å bli ferdig med prosjektet, men det var ikke de som skulle sitte med resultatet i fanget etterpå. 

Det er som å si at du har skrudd sammen IKEA-møblene med lim og spart masse tid, men når du da plutselig skal flytte dem neste gang fordi du skal bytte hus, så må du slå dem i stykker med hammer. 

(Ansatt i IT-avdelingen) 

Det handler om langsiktige investeringer, og prosjektene har vært veldig dårlig til [dette]. Prosjektene leverer på sine midlertidige behov for å komme raskt til mål og spare masse tid og levere verdi fortest mulig i sin boble. 

(Teamleder i IT) 

Det ble også stadig vanskeligere å holde tritt med og oversikt over de mange IT-prosjektene, og det ble mange flaskehalser i organisasjonen som følge av at leveranser hang sammen. 

Prosjekter er litt som raketter som går i ulike retninger, og noen ganger treffer de hverandre, og noen ganger ikke. Så dette er begynt å bli mer og mer uglesett. 

(Intern konsulent) 

Med denne lærdommen i bagasjen gjorde DNB et grep hvor de valgte å lage faste team med ansvar for alt av utvikling, drift og forvaltning knyttet til produkt/tjeneste. Etter hvert gikk en enda et steg videre og organiserte teamene i produktfamilier. 

[…] du setter opp en familie som er tverrfaglig og inneholder alt innenfor for eksempel kredittområdet. Du har med folk fra risikoområdet, storkundeområdet, tech and services og mange forskjellige som sitter i faste team og jobber kontinuerlig med dette. Du samler alt av utvikling, all forvaltning, all drift og alle deler, egentlig som et eget produktselskap. 

(Leder 2) 

Med stabile ressurser i teamene kunne en slippe å lære opp nye teammedlemmer, og medlemmene spesialiserte seg, og dette økte tempoet på prosessene. 

Grunnet avhengigheter og gamle kjernesystemer måtte en stor del av IT-avdelingen forbli ren IT. Men i tråd med ny arbeidsmetodikk valgte en også her å endre organiseringen til team og familier med helhetsansvar for utvikling, forvaltning og vedlikehold. 

Med den nye organisering i faste team i familier som var ansvarlige for produkter, ble eierskapet til produktene større. Det nyttet ikke lenger å si at dette er ikke mitt bord, eller forlate prosjektet etter første betaversjon. Teamene fikk lov å jobbe intensivt sammen og lære hverandre å kjenne, og de fikk delegert et helhetlig ansvar for produktene. Dette skapte en motivasjon hos medarbeiderne. 

Innovasjonskraften vår har økt kraftig som følge av at vi har disse teamene som har fått lov nå å jobbe i en god stund med å drille, «hva er smart?» De er mer autonome, de jobber mer selv, det er de som må bestemme, det er de som eier, det er mye mer passion knyttet til at «jeg er sjefen over nettbanken, eller blodpumpen i norsk næringsliv». Da sover du dårlig hvis det er ett eller annet der som ikke fungerer. I stedet for å bare si «nei, men det er IT, det, som gjør det», sant? 

(Leder 3) 

I tillegg ble det mer oversiktlig organisering og lettere å styre ressursene. Når utviklingen var mer prosjektstyrt, var det mindre gjennomsiktighet i organisasjonen. Omleggingen førte til at mange skjeletter datt ut av skapene, og man fikk oversikt over prosjekter som gikk dobbelt opp og ulik belastning på teamene. 

Flere av teammedlemmene opplevde også at det ble lettere å forankre beslutninger, både fordi mer var delegert til teamet, men også fordi ansvaret var mye klarere plassert. 

Nå trenger jeg bare et kort møte med familieleder i 10–15 minutter der jeg forklarer endringen og han kan stille spørsmål. Hvis han godkjenner det, er vi klare til å gå i produksjon. Så beslutningstaking er mye raskere. Så vi har fått mye mer kontroll i familiene. Før var det en ganske annerledes prosess der en annen måtte godkjenne endringer. 

(Teamleder IT) 

I tillegg tillot de faste teamene en større grad av spesialisering på produkt/tjeneste, noe som igjen gjorde at tempoet i utviklingsprosessene økte. 

Hvis du har stabile ressurser som kan applikasjonen og applikasjonsområdet […] kan du få oppgavene til å gå utrolig fort igjennom. Men hvis du bytter ut ressurser hele tiden, så er det opplæring, og du må ha noen som guider dem underveis. 

(Teammedlem IT) 

Utfordringer og begrensninger 

Selv om den agile arbeidsmetodikken ble rullet ut i banken, var det også bevissthet rundt at ikke alle prosesser burde kjøres i agile løp. Yngvar Ugland, leder i DNBs New Tech Lab, uttalte i en artikkel på DNBs hjemmesider at for noen prosjekter var fortsatt tradisjonell metodikk den riktige metoden. 

Jeg er enig i at arbeidsmetodikken ikke passer til alle arbeidsoppgaver og prosjekter. Den var for eksempel ikke riktig da DNB skulle få alle medarbeiderne over på Microsoft 365. Det var et klassisk fossefallsprosjekt som flere bedrifter hadde gjennomført før oss. Det som gjaldt da, var å følge beste praksis, legge en god plan og gjennomføre den. 

(Ugland, 2020) 

Det var også enklere å gi autonomi til et team som arbeider med nye teknologiske løsninger som var uavhengig av reguleringer og kjernesystemer som for eksempel utvikling av chatbots, enn for andre team som arbeider med hvitvasking og etterlevelse av lovverket. 

Samordning av IT og forretning hadde også sine begrensninger grunnet gamle IT-systemer. DNBs teknologiske plattform er fra 60- og 70-tallet, den gang COBOL-programmering var på moten. Utfordringene med det gamle systemet er at det ikke er tilpasset de nye arbeidsmåtene DNB har implementert, med kontinuerlige produkt- og tjenesteinnovasjoner i tverrfaglige team som har helhetsansvar for utvikling, forvaltning og drift innenfor definerte produktkategorier. Når et team skal endre «sitt» produkt, får det følgekostnader for mange av de andre teamene fordi systemet har så mange avhengigheter, og dataene ligger plassert mange ulike steder. 

Ideelt sett skal teamet ha frihet til å styre alt selv, og når vi har en bankplattform med mange avhengigheter og sammenkoblinger, blir dette vanskelig gjennomførbart. 

(Leder 2) 

Organiseringen i faste team tilhørende familier var heller ikke uten utfordringer. Når teamene ikke lenger bare hadde ansvar for å utvikle produktene, men også skulle ha ansvar for drift og forvaltning, måtte de bruke mer av tiden og oppmerksomheten på driftsproblemer og vedlikehold. 

Vi har nok mistet litt fart fordi noen av teamene har hengt seg opp i store, komplekse driftsproblemstillinger som de før ikke måtte ta stilling til. 

(Leder 4) 

Med de faste teamene i familiene ble det også bygget nye, sterke identiteter og kulturer som gjorde at den fleksibiliteten man ofte forbinder med agile organisasjoner, ble utfordret. 

Dette er min flokk, og det er her jeg bor, og dette er min gjeng, liksom. Og vi har til og med gått og kalt det familie, ikke sant, og det er min familie, og det bryter du ikke lett ut av, for å si det sånn. 

(Leder 4) 

Etter hvert som en større og større del av banken ble organisert i agile team, ble det også behov for å tenke gjennom hvordan man styrte disse familiene med faste team, og flere av lederne syntes det var utfordrende med den agile metodikken som tilsa stor frihet for teamene. Det ble vanskeligere å styre, og mange opplevde også at det var kunden, og ikke ledelsen, som prioriterte hva teamene skulle bruke tiden på. 

Begrepet autonomi kan gå litt sånn sport i. Det er ingen som bestemmer over oss, vi bare er vår egen hær. 

(Leder 4) 

Det som nå skjer, er at jeg ikke kjenner prioriteringene inni de teamene. Alle sier sånn: «Nei, men når du jobber agilt, så vet du heller ikke, du må bare høre på kunden, og så tar du bare det som kunden sier at vi skal gjøre.» Men det kan vi ikke. Vi er nødt til å tenke strategisk, tenke funksjonelt, tenke gjenbruk osv. 

(Leder 4) 

Sammenlikning og diskusjon 

De to casebeskrivelsen viser at der er en felles kjerne. For begge bankene handler agil organisering helt klart om innføring av arbeidsmetoder som bruk av tverrfaglige team som får stor grad av frihet til å organisere arbeidet selv. De jobber i sprinter og bruker mange av metodene og begrepene vi har beskrevet tidligere knyttet til agilt. Der er imidlertid også noen tydelige og interessante forskjeller. Mens Fana Sparebank benytter fleksible team til å jobbe på prosjekter av midlertidig karakterer, har DNB valgt faste team med ansvar for utvikling og drift av nye produkter og tjenester. 

I tabell 2 sammenlikner vi agil organisering i de to bankene, og nedenfor drøfter vi fordeler og ulemper med de to tilnærmingene vi har beskrevet, samt hva som kan ligge til grunn for disse forskjellene. 

En av de tydeligste forskjellene mellom de to bankene er valget av faste versus fleksible team. Mens FSB oppnår god ressursflyt (Doz & Kosonen, 2010) ved å allokere personer med riktig kompetanse til hvert enkelt prosjekt, har DNB vektlagt faste team fordi det plasserer tydelig ansvar der teamene følger et produkt over tid fra utvikling til driftsfase. De unngår dermed utfordringer knyttet til overlevering (se også Nesheims artikkel i denne utgaven om agile produktteam). I tillegg utvikler teamene psykologisk trygghet og kan raskt gå i gang med nye oppgaver. Men det betyr samtidig at teamene selv må sikre en god balanse mellom utvikling og drift. 

Kikker vi nærmere på teamene, ser vi at de jobber med ulike typer oppgaver. De faste teamene i DNB jobber primært med produkt-/tjenesteutvikling, mens de fleksible teamene i FSB jobber med et bredere sett av oppgaver som også inkluderer organisasjonsutvikling, sosialt ansvar osv. Slike oppgaver har gjerne ikke samme tidspress og kan ha fordel av å bringe sammen nye personer for å sikre ulike perspektiver. Produkt-/tjenesteutvikling vil være mer presset på tid, og det kan da være fordelaktig å unngå å bruke tid på å bli kjent og «sette» teamet. 

Utgangspunktet for agil organisering er også forskjellig. I FSB er sprintene knyttet opp mot strategi og et ønske om å bli mer foroverlent som organisasjon, mens de agile familiene i DNB er knyttet mer direkte opp mot innovasjonsprosesser. DNB hadde lang erfaring med å jobbe i tverrfaglige (dog ikke agile) prosjekter og hadde også ferske erfaringer med agile arbeidsmetoder fra Vipps. Problemene de ønsket å løse med den agile organiseringen, krevde noe annet. DNB ville dermed neppe løst sine problemer ved å velge samme tilnærming som FSB. 

Selv om bankene har valgt ulike tilnærminger, ser vi at felles for dem begge er noen ganske stramme rammer. Det tyder på at for å kunne jobbe raskt og smidig i stor skala kreves noen strukturer og/eller prosesser som koordinerer arbeidet. I DNB danner familiene en felles struktur, mens i FSB er det selve prosessen – med tydelige forventninger til hvordan sprintene gjennomføres, med kick-off, stående møter og refleksjoner – som danner rammen. Dersom målsettingen er å sikre ressursflyt, synes strukturelle rammer som familier mindre fleksible enn prosesstyring. Der er også en risiko for at strukturelle rammer blir til nye siloer hvor teammedlemmene søker identitet og tilhørighet og i liten grad er åpne for samarbeid med andre utenfor teamet. På den andre siden vil større organisasjoner som DNB ofte trenge mer formelle strukturer for å koordinere arbeidet. 

Oppsummert ser vi at den agile organisasjonen kan ta ulike former, og rammene rundt de agile teamene kan konstrueres på ulike måter. McKinsey beskriver den agile transformasjonen som en reise (Inacio et al., 2022), mens våre funn tyder på at de to bankenes reiser kanskje ikke går til samme sted. Det er også relevant å reflektere rundt endestasjonen. Strekker vi det for langt dersom målet er at hele organisasjonen skal være agil? Utgangspunktet for organisasjonsfaget er at det ikke finnes en optimal måte å organisere arbeid på – en må velge organiseringsprinsipp ut fra målsetting. Er målet alltid høyt tempo, eller er det noen type oppgaver som vil ha fordel av å ta tiden til hjelp? 

Dette er min flokk, og det er her jeg bor, […] det er min familie, og det bryter du ikke lett ut av, for å si det sånn.

Forskningsbaserte studier tyder på at agile arbeidsmåter er effektive for oppgaver som kan gjøres parallelt, som kan brytes ned i sekvenser, og som kan utvikles til prototyper (Rigby et al., 2016). Programvare/IT, produktutvikling, ny design og produktegenskaper nevnes som gode eksempler på dette. Metodikken beskrives imidlertid som mindre egnet for finans, regnskap og risikostyring (Rigby et al., 2016; Puranam & Clément, 2019). Ledere som ønsker å sette fart på innovasjon, bør derfor tenke nøye gjennom hvilke typer oppgaver en organiserer agilt, og hvilke rammer som legges for å koordinere de autonome teamene. 

Konklusjon 

I denne studien har vi undersøkt hvordan agile team kan skaleres opp til å gjelde store deler av organisasjonen. Ved å sammenlikne to banker finner vi at der er en felles kjerne som handler om autonome team som tar i bruk agile arbeidsmetoder, mens koordineringen av teamene kan ta ulike former avhengig av hvor organisasjonen kommer fra, og hva den ønsker å oppnå. I begge våre studieobjekter har agile arbeidsmetoder og organisering gitt positive effekter. Det har skrudd opp tempoet, og det har økt tverrfagligheten i teamene, noe som henger sammen med innovasjonsevnen (Phillips et al., 2014), og mange ansatte føler seg også mye mer motivert gjennom denne måten å organisere arbeidet på. Samtidig finner også vi at det er noen utfordringer ved agil organisering: I DNB blir det et spørsmål om en er i ferd med å lage nye siloer som er vanskeligere å lede, i FSB er det noen som synes dette blir litt heseblesende, og det er heller ikke en metodikk som passer for alle. 

Vi er rimelig sikre på at disse to tilnærmingene ikke er uttømmende, men at der også finnes mange andre måter dette kan gjøres på. Fremover trenger vi mer kunnskap om hva agil organisering er, og hvor grensene går for hva som kan kalles agil organisering. Vi håper at denne studien kan være et første skritt i retning av en bredere kartlegging av disse spørsmålene. 

Referanser 

Aghina, W., De Smet, A., Lackey, G., Lurie, M. & Murarka, M. (2018, 22. januar). The five trademarks of agile organizations (Rapport). McKinsey & Company. https://www.mckinsey.com/business-functions/people-and-organizational-performance/our-insights/the-five-trademarks-of-agile-organizations 

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schaber, K., Sutherland, J. & Thomas, D. (2001). The agile manifesto. https://agilemanifesto.org/ 

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. 

Dingsøyr, T., Falessi, D. & Power, K. (2019). Agile development at scale: The next frontier. IEEE Software, 36(2). 

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

Doz, Y. L. & Kosonen, M. (2010). Embedding strategic agility: A leadership agenda for accelerating business model renewal. Long Range Planning, 43(2–3), 370–382. 

Førland, I. & Klemp, S. (2021). Agil organisering i et komplekst selskap med store avhengigheter: En kvalitativ casestudie om agil organisering i et veletablert finanskonsern (Masteroppgave). Norges Handelshøyskole (NHH) / Samfunns- og næringslivsforskning (SNF), RaCE-prosjektet. 

Glesne, D. & Pedersen, M. (2020). Strategic agility: Adapting and renewing strategic direction: An exploratory case study (Masteroppgave). Norges Handelshøyskole (NHH) / Samfunns- og næringslivsforskning (SNF), RaCE-prosjektet. 

Gunasekaran, A. (2001). Agile manufacturing: The 21st century competitive strategy. Elsevier. 

Inacio, J., Kincesm, D., Riederer, G. & Róna, D. (2022, 24. januar). CIO perspectives on leading agile change. McKinsey & Company. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/cio-perspectives-on-leading-agile-change 

Kamath, S. (2020). The influence of agile ways of working on change capacity: A case study exploring organizational agility in practice (Masteroppgave). Norges Handelshøyskole (NHH) / Samfunns- og næringslivsforskning (SNF), RaCE-prosjektet. 

Lande, H. S. (9. september 2018). DNB blir teknologibedrift med bankkrisens. https://www.dnb.no/dnbnyheter/no/samfunn/dnb-blir-teknologibedrift-med-banklisens 

LeMay, M. (2019). Agile for everybody: Creating fast, flexible, and customer-first organizations. O'Reilly Media. 

Lem, C. H. (2018). Strategi har gått fra langdistanse til sprint. Magma, 6, 6–8. 

Lindqvist, C. & Liepina, S. & (2018). The challenges encountered by the managers of exploratory units in structurally ambidextrous organizations. (Masteroppgave). Norges Handelshøyskole (NHH) / Samfunns- og næringslivsforskning (SNF), RaCE-prosjektet. 

Løvik, O. L. (2020). Hvordan få til et godt samarbeid i den tohendige løsningen? En eksplorativ casestudie (Masteroppgave). Norges Handelshøyskole (NHH) / Samfunns- og næringslivsforskning (SNF), RaCE-prosjektet. 

Meyer, C.B., Stensaker, I.G., Bjerke, R., & Haueng, A.C. (2022). Innovasjonskapasitet. Fagbokforlaget. 

Nesheim, T. (2022). Agil organisering: Fra utviklingsprosjekter til produktteam. Magma, denne utgaven. 

Phillips, K. W., Medin, D., Lee, C. D., Bang, M., Bishop, S. & Lee, D. N. (2014). How diversity works. Scientific American, 311(4), 42–47. 

Puranam, P. & Clément, J. (2019, 29. juli). Why agile may be fragile. INSEAD Knowledge. https://knowledge.insead.edu/leadership-organisations/why-agile-may-be-fragile 

Rigby, D. K., Sutherland, J. & Takeuchi, H. (2016, 20. april). The secret history of agile innovation. Harvard Business Review. https://hbr.org/2016/04/the-secret-history-of-agile-innovation 

Sverdrup, T. & Schei, V. (2022). Smidige team – utfordringer som gir muligheter. Magma, denne utgaven. 

Teece, D., Peteraf, M. & Leih, S. (2016). Dynamic capabilities and organizational agility: Risk, uncertainty, and strategy in the innovation economy. California Management Review, 58(4), 13–35. 

Ugland, Y. J. (23. november 2020). Agil team utvikler seg raskere og riktigere. https://www.dnb.no/dnbnyheter/no/samfunn/agile-team-utvikler-raskere-og-riktigere