Agil organisering: Fra utviklingsprosjekter til produktteam (F)

Sammendrag 

I denne artikkelen tar vi for oss dagens «ortodoksi» innen agil organisering, som vektlegger innovasjon gjennom tverrfaglige produktteam med stabilt medlemskap. Denne modellen og kontrasten til organisering i utviklingsprosjekter er godt kjent fra populærlitteratur og blogger. Det har i liten grad vært forsket på dette temaet innen organisasjonsfaget. Artikkelen bidrar med ny vitenskapelig basert innsikt om utviklingsprosjekter versus produktteam, basert på data fra norske virksomheter. Vi tar for oss hva som oppfattes som problemer i utviklingsprosjekter, hva det vil si at produkter erstatter prosjekter, betydningen av stabilitet i medlemskap i teamene, hvordan agilitet i produktteam oppfattes, innslag av supplerende strukturer samt implikasjoner for omfang av prosjekter i de aktuelle organisasjonene. 

Innledning 

Agile prinsipper, metoder og tankesett har stor innflytelse og kan påvirke organisasjoner på ulike måter (Puranam & Clément, 2019; Meyer et al., 2022). Et viktig utgangspunkt er skillet mellom a) agilitet som organisatorisk evne eller utfall, som evnen til å fange opp endringer i omgivelsene og tilpasse seg raskt og effektivt (Felipe et al., 2016; Zitkiene & Deksnys, 2018), og b) et knippe av organisatoriske mekanismer, prosesser, metoder og verktøy som fremmer slike evner og utfall (Dybå & Dingsøyr, 2009; Stray et al., 2019). Agilitet og smart organisering har sin opprinnelse innen en spesifikk sfære av organisering (programutvikling og IT), men blir i økende grad benyttet som generiske prinsipper for organisering, utvikling og endring (Puranam & Clément, 2019). 

I denne artikkelen vil vi beskrive og analysere sentrale trekk ved agil organisering. Artikkelen er basert på intervjuer i fem norske virksomheter hvor digitale prosesser og programvare-utvikling er grunnlaget for kjernevirksomheten. Vi legger vekt på utviklingen fra separate utviklingsprosjekter (skilt fra forvaltning og drift) til varige, tverrfaglige agile produktteam. Dette er utviklingstrekk som er kjent fra populærlitteratur, blogger og podkaster, men i liten grad behandlet i akademisk forskning. I forskningen setter man typisk søkelyset på agilitet i prosjekter, bygget på en premiss om en dominerende prosjektlogikk, eller man går i liten grad inn på spørsmål knyttet til stabilitet og varighet i teamene (Puranam & Clément, 2018; Stray et al., 2019; Dingsøyr et al., 2021; Vestues & Rolland, 2021). En slik «deprosjektifisering av agil» vil også være av stor interesse for fagområdet prosjektorganisering og ledelse (project management), hvor antakelsen om midlertidige enheter som håndterer unike oppgaver med en klart start og slutt, står sterkt (Bakker, 2010; Bredin & Søderlund, 2011; Keegan et al., 2017). 

I den empiriske delen går vi inn på flere aspekter knyttet til spenningen mellom prosjekter og produkter: Hva som oppfattes som problemer i utviklingsprosjekter, hva det vil si at produkter erstatter prosjekter, betydningen av stabilitet i medlemskap, hvordan agilitet i produktteam oppfattes, innslag av supplerende strukturer samt implikasjoner for omfang av prosjekter i de aktuelle organisasjonene. 

Agilitet, prosjekter og team 

For å forstå utvikling og endring i organisasjoner legges ofte begrepet tohendighet (ambidexterity) til grunn (Raisch & Birkenshaw, 2008). Man antar her at utnyttelse (effektivisering) og utforsking (kreativ, innovativ) er forskjellige aktiviteter som krever ulike tankesett, mål, lederskap og kompetanser. Utforsking kan organiseres på ulike måter, og det er flere alternativer når disse aktivitetene skal bygges inn i organisasjonen (Meyer et al., 2022). Én måte å gjøre dette på er å organisere utviklings- og innovasjonsoppgavene i separate prosjekter som skilles fra de daglige aktivitetene i kjernevirksomheten. Utviklingen vil dermed være preget av en prosjektlogikk og trekke på organisasjonsprinsipper, verktøy og tankesett fra faget prosjektorganisering og ledelse. Et prosjekt blir her forstått som en oppgave med et start- og sluttidspunkt, med stor grad av unikhet, hvor det settes sammen en arbeidsgruppe eller et team for å løse oppgaven (Keegan et al., 2017; Bakker, 2010). Sett fra organisasjonens side vil denne prosjektlogikken typisk innebære at man søker å knytte ulike spisskompetanser sammen i tidsavgrensede team og legger vekt på fleksibel bruk av knappe ressurser over tid. På individnivå vil man ofte jobbe i en «kjede av prosjekter over tid», hvor midlertidig tilhørighet i team kan kombineres med langsiktig tilhørighet i en ressurs- eller fagenhet (Bredin & Søderlund, 2011; Nesheim, 2021). 

Det organisatoriske skillet mellom endringsprosjekter og løpende aktiviteter finner man også innen agil tankegang og verktøy-/programvareutvikling. Utvikling blir håndtert i egne utviklingsprosjekter, og den nye IT-løsningen blir overført til en drifts- eller forvaltningsenhet. Når oppgaven er fullført, blir prosjektet avsluttet, og medlemmene går inn i nye konstellasjoner. Mye av forskningen om agil organisering har tatt for seg utfordringer knyttet til agilitet i prosjekter eller bygger implisitt på en antakelse om en rådende prosjektlogikk (Conforto et al., 2014; Hobbs & Petit, 2017; Serrador & Pinto, 2015 Stray et al., 2019; Vishnubhotla et al., 2017; Przybilla et al., 2019; Grass et al., 2020). Puranam og Clément (2019) beskriver kjernen i dette slik: 

Agile practices grew out of a product development framework widely adopted by the software industry. Also called «scrum», its central principle is to set up highly autonomous and independent teams, each working on a different aspect of a larger, complex problem. Instead of marching in bureaucratic formation, they are given freedom to «sprint», i.e. rapidly advance in parallel towards a solution with minimal top-down oversight. […] Upon completion of the immediate task, teams either dissolve or take on a new project. 

Denne forståelsen er imidlertid blitt utfordret, både innen populærlitteraturen og fagområdet informasjonssystemer. Et ankepunkt er at prosjektlogikken og den midlertidige karakteren hindrer utvikling av tillit og samhold i teamet (Skelton & Pais, 2019). Det skarpe skillet mellom utvikling og drift bidrar videre til manglende eierskap til løsninger og gjør det svært vanskelig å gjøre justeringer og tilpasninger over tid (Forsgren et al., 2018. Detaljerte spesifikasjoner og omfattende styring og kontroll hemmer dessuten ofte teamets evne til å utvikle gode løsninger (Kelly, 2018). 

Som et alternativ fremheves en modell basert på flere stabile team som tar ansvar for utvikling, vedlikehold og drift, og som arbeider med stor grad av autonomi. Her trekker man gjerne inn antatte suksesshistorier som Spotify, Netflix, Amazon og ING (van Gerven, 2018; Kelly, 2018; Skelton & Pais, 2019; Barton et al., 2018). Det kan dermed synes som en ny «agil ortodoksi» er i ferd med å vokse frem i konsulentmiljøer og i populærlitteraturen. Det har imidlertid vært lite vitenskapelig forskning på den nye modellen og overgangen fra utviklingsprosjekter til varige produktteam eller spenninger mellom prosjekt- og produktlogikk. 

Det organisatoriske skillet mellom endringsprosjekter og løpende aktiviteter finner man også innen agil tankegang og verktøy-/programvareutvikling.

 

Data og metode 

Formålet med undersøkelsen er å få frem ny kunnskap om agil organisering i IT- og programvareutvikling. Vi avdekker og beskriver bakgrunn, innhold og utfordringer i virksomheter hvor agile, tverrfaglige team utgjør viktige operative enheter. Studien er beskrivende gjennom å få frem egenskaper og utfordringer knyttet til disse teamene, og bidrar også til begrepsutvikling gjennom å utfordre eksisterende forståelse av agil organisering. 

Det empiriske materialet bygger på casestudier i Alfa (18 intervjuer vinteren 2021) og Beta (13 intervjuer høsten 2021). Intervjuobjektene hadde ulike roller knyttet til agil organisering. Vi har også hatt tilgang til bakgrunnsinformasjon i form av organisasjonskart og teambeskrivelser fra disse to virksomhetene. I tillegg er det gjort intervjuer med en nøkkelperson for agil organisering i tre virksomheter: Gamma, Epsilon og Zeta (mellom 60 og 90 minutter). Disse virksomhetene har i norsk sammenheng vært tidlig ute med å benytte agile team. Det ble skrevet referat fra hvert intervju. Vi trekker også på bakgrunnsinformasjon fra samtaler med tre konsulenter med lang erfaring med temaet, samt en rekke podkaster (smidigpodden.no; smidig.no; Bekk) og blogginnlegg. 

Hvert av de 31 intervjuene ble kodet (første orden) og fordelt på undertema (andre orden) og tema (tredje orden). Denne prosessen ble utført iterativt over tid, noe som tillot oss å justere kodeskjemaene både vertikalt (mellom nivåer) og horisontalt (mellom respondenter og kategorier). Vi endte med seks temaer som danner grunnlaget for disponeringen av den empiriske analysen. 

Empirisk analyse: Fra utviklingsprosjekter til produktteam 

Et felles utgangspunkt for de fem bedriftene var at utviklingsarbeidet tidligere typisk var organisert i prosjekter, og dette arbeidet var adskilt fra forvaltning og daglig drift. Man hadde dermed midlertidighet langs tre dimensjoner: 

• Oppgaven: Utvikling av en ny løsning 
• Organisasjon: Prosjektet (teamet) blir oppløst etter at oppgavene er fullført. 
• Medlemskap: Arbeidsgruppen oppløses etter fullført oppgave. Unikt team for hver oppgave og hvert prosjekt. 

Over tid har det skjedd gradvise endringer hvor produktteam (og andre varige team) har vokst frem, mens de rene utviklingsprosjektene er blitt bygget ned. De konkrete utfordringene og løsningene varierer mellom bedriftene, men noen hovedmønstre peker seg ut på tvers av bedriftene. Den empiriske analysen har avdekket seks tema som blir belyst nærmere nedenfor. 

Hva var problemet med prosjekter? 

Det var tidligere et organisatorisk skille mellom utviklingsdelen på den ene siden, og driften av de aktuelle løsningene på den andre siden. Denne overføringen fungerte ofte dårlig: 

[…] det er en handover-problematikk […] det er jo utallige eksempler på at det fungerer dårlig. Det handler både om eierskap, […] det kan være ulike både kompetansebehov, ulike agendaer, ulike trosretninger innenfor teknologi også, som gjør at når du leverer fra en del av organisasjonen til en annen, så kommer det opp mange spørsmål. Hvorfor har vi gjort det sånn på den måten i første omgang, og så blir det et behov for å skrive om alt på nytt. (Zeta) 

[…] (tidligere) så vi at løsningen ikke ble optimal når de som utviklet løsningen, ikke var involvert i vedlikehold og drift. (Alfa 17) 

En konsekvens av dette var at læringen og erfaringsutvekslingen ble for begrenset: 

Vi gjorde en ting, skrev en sluttrapport som noen la i en skuff, og som ingen leste etterpå. Og når vi rigget opp nå nytt, så startet vi helt fra starten igjen og lærte veldig mye av det vi allerede egentlig hadde erfart. (Gamma) 

En annen svakhet som kom frem i intervjuene, var omfanget av kontroll og styring. Utviklingsprosjektene hadde ofte detaljerte kravspesifikasjoner, med hyppig oppfølging og dokumentasjon. Dette medførte hindringer for autonomi og kreativitet i prosjektene, som i neste omgang bidro til svekket tempo og innovasjonsgrad i prosjektene. Et intervjuobjekt uttrykker det slik: 

Og utfordringen var at vi hadde mye byråkrati, mye dokumentasjon, mye bestillingsregime og ting gikk veldig tregt i forhold til utviklingen av nettbutikken vår. (Beta 3) 

Vi hadde veldig liten grad av autonomi i (prosjektteamene) […] veldig mye av utviklingen skjedde på den måten at spesifikasjoner, skjermbilder, avgjørelser ble tatt på utsiden av teamene i stor grad. Og det var til dels veldig waterfall-orientert da […] eierskapet til produktet var veldig lavt, og forståelsen for hva man bygget i teamene, var til dels også veldig lav. (Alfa 16) 

Produkter, ikke prosjekter 

Etter hvert ble organiseringen endret i retning av mer varige team som dekker både utvikling, forvaltning og drift. Dette beskrives som gradvise endringer langs to dimensjoner: a) på teamnivå, hvor det finner sted en endring mot varige konstellasjoner i form av et produktteam (med produkteiere), b) gradvis økt utbredelse av slike team, slik at de utgjør en større andel av organisasjonen. 

Jeg husker ikke helt tidspunktet. Men fra et eller annet tidspunkt gikk vi over til å definere det som prosjektteam til produktteam. (Beta 8)

 

Eksempler på produkter er digitalt salg, boliglån, betalingstjenester, annonser, storskjerm. Sett i ettertid er det lett å se at disse produktene skiller seg klart fra prosjektene: 

[…] alle disse digitale produktutviklingsinitiativene som vi setter team bak, er litt vanskelig å kalle prosjekter, fordi så lenge produktet eksisterer, så eksisterer teamet. Men hvis vi vil legge ned produktet, så legger vi også ned teamet. (Zeta) 

[…] så for eksempel låneteamet eier på en måte låneområdet og alle løsninger som har med lån å gjøre, uavhengig av tid. Men så kan de jo ha oppgaver eller tiltak som de prioriterer som er tidsbestemte. […] da gikk det fra å være et tidsbestemt prosjekt som ble oppløst, til å være team som levde videre, men der de hadde en backlog der du på en måte plukket oppgaver fra. (Alfa 6) 

I produktteamene skulle man ivareta både utvikling, testing, forvaltning og drift over tid. Flere peker på at man var inspirert av DevOps-tankegangen, som legger opp til bedre integrasjon og større samspill mellom utvikling/forbedring og utførelse av daglige operasjoner. 

Du har en sånn ‘if you build it, you own it, you run it, you kill it’. Så du blir ansvarlig fra du lager noe, så må du også vedlikeholde det, du må drifte det, og du må skru det av når det på en måte ikke lenger virker eller skal brukes. […] tvinger folk både til å tenke mer tverrfaglig og […] også at det gjør at du tenker mer helhet over hele livsløpet til løsningen. (Alfa 8) 

Produktteamene omtales som varige (sammenlignet med de midlertidige prosjektene). Varigheten kan likevel variere, slik en informant peker på: 

[…] så har vi hatt produkter som har vært i denne porteføljen […] Og da har de hatt sånn typisk tre måneder til to års levetid. (Zeta) 

Endringen fra prosjekt til produkt skjedde ikke over natten, men fant typisk sted gradvis. Etter hvert vokste det frem en erkjennelse av at det var mer fornuftig å jobbe mer langsiktig innen teamene. 

Jeg husker ikke helt tidspunktet. Men fra et eller annet tidspunkt gikk vi over til å definere det som prosjektteam til produktteam. (Beta 8) 

[…] der de gikk fra å være et program som var tenkt å skulle levere og deretter stoppes, til å anerkjenne at dette er noe vi måtte drive med kontinuerlig videre. (Beta 8) 

I én av virksomhetene involverte endringen fra prosjekter til produktteam mange aspekter, inkludert intern kompetanseoppbygging, insourcing og mindre bruk av konsulenter samt samlokalisering av ansatte. Også her endte man opp med: 

[…] et team som eide og var ansvarlig for det produktet hele veien […] dedikert produkteier som på en måte tok de avgjørelsene, og så måtte han gjøre en del interne avklaringer og sånne ting (i teamet). (Epsilon) 

DevOps-tankegangen (bedre integrasjon mellom utvikling, drift og forvaltning) var heller ikke noe man kunne innføre fra en dag til en annen: 

Intervjuer: Er det riktig forstått at DevOps-tankegangen har preget endringen? 

Det er det. Jeg kan jo også si at hvis det er noen ting jeg skulle ha gjort enda bedre på den reisen her, så var det egentlig å forstå og erkjenne på en måte at det tar lang tid å få nødvendige deler av organisasjonen til å komme til den erkjennelsen. (Beta 8) 

Produktteamene utgjør en kontrast til prosjektorganiseringen. Samtidig åpnes det for at produktbegrepet ikke fanger opp alle de (varige) oppgavene som kan løses av agile team. Respondentene omtaler også plattformteam (dekker en teknologisk plattform som er grunnlag for mange produkter) og domeneteam (f.eks. rettet mot effekter i et delmarked, uavhengig av salgskanal). 

Stabilitet i medlemskap 

Organiseringen tar altså utgangspunkt i varige oppgaver. Teamet som varig organisatorisk enhet er knyttet til disse oppgavenes eksistens over tid. I forlengelsen av dette kan man spørre: Har teamet også stabilt medlemskap over tid, eller varierer medlemskapet, for eksempel som følge av skiftende kapasitets- og kompetansebehov over tid eller et ønske om rotasjon og fornyelse av deltakerne? 

Det har kommet også frem ulike beskrivelser og vurderinger av dette fra våre respondenter. Hovedmønsteret er at de legger vekt på stabilitet i teammedlemskap. To dimensjoner ved dette trekkes særlig frem: tillit og psykologisk trygghet og domenekunnskap. Over tid utvikles typisk tillit, gjensidighet og gode relasjoner, noe som styrker prestasjonene i teamet. Noen sitater som illustrerer dette. er: 

[…] får bedre samarbeidsmekanismer, blir vant til hva som er styrke og svakhet, hvem er det som gjør hva. I stedet for hele tiden å få nye folk å forholde seg til, så klarer du […] å bygge opp […] samarbeid og lagspill over tid. (Alfa 6) 

Når man jobber sammen over tid, bygges det opp kunnskap om det aktuelle produktet både hos det enkelte teammedlem og i teamet som helhet: 

[…] ikke minst at de får domenekunnskap. Sånn som låneteamet må jo forstå låneområdet veldig godt, de må forstå i hvilke settinger kundene er i modus for å låne. Hvordan fungerer kredittmodellene våre? Og hvilke data må vi da hente inn? Hvilke data må vi få fra kunden? Hva må vi få fra andre plasser? Hvis du dagen etter hadde tatt alle som jobbet på låneteamet og flyttet dem til betaleteamet og motsatt, da måtte du ha begynt helt på nytt og lært deg alle disse tingene på nytt igjen. (Alfa 6) 

Tilknytningsform er også viktig for bemanningen. Teamene vil typisk ha innslag av eksterne konsulenter som jobber sammen med bedriftens ansatte. I to av casebedriftene har man over tid ønsket å redusere andelen eksterne konsulenter, og har klart å realisere dette. Rasjonalet har vært å bygge sterkere identitet og knytte folk til seg på mer langsiktig basis enn det som er aktuelt for ekstern arbeidskraft. 

De andre virksomhetene har jevnt over hatt en høyere konsulentandel, i hovedsak ut fra hensyn til kostnader og fleksibilitet. Man legger også her vekt på stabilitet i medlemskap på teamnivå (ansatte og konsulenter), men peker på at konsulenter er mer ustabil arbeidskraft og har lettere tilgang til andre alternativer. 

Et relatert spørsmål er om man jobber i ett eller flere team på et gitt tidspunkt. Våre respondenter er samstemte om at man tilstreber 100 prosent deltakelse i et team. Rasjonalet er at man da kan legge all vekt på dette teamet. Det blir mye lettere å samordne aktiviteter, møter og annen kommunikasjon enn i en situasjon hvor de ansatte deltar i flere team. 

I praksis lar intensjonen om å delta i ett (og bare ett) team seg ikke alltid realisere. Det kan være mangel på aktuell spisskompetanse som gjør at de folkene man har, må spres på flere team. I noen team vil det ikke være nok arbeid til å dekke inn en rolle med en gitt kompetanse, og i noen tilfeller vil hensynet til kostnader medføre at man gir avkall på dette prinsippet. 

Stabilitet i medlemskap er ingen absolutt verdi. Det pekes også på at det åpnes for noe rotasjon mellom teamene for å løse opp i «uheldige» teamkonstellasjoner eller for å gi nye muligheter for den ansatte. Det kan også være ønske om endringer i kapasitet og kompetanse over tid, selv om produktet er av langsiktig natur. 

Ut fra intervjuene kan stabilitet i medlemskap også beskrives som et dilemma. Våre intervjuobjekter er enige om at stabilitet er et fortrinn, basert på argumentene om relasjoner, tillit, fokusert arbeid og domenekunnskap. Samtidig legger flere vekt på at det er viktig at teamene ikke stivner, og at det bygges inn fleksibilitet knyttet til teamets varighet, størrelse over tid og medlemskap. Teamene kan være for sterke: 

[…] teamene ble så sterke og hadde så stort eierskap, og det gjorde at mye av fleksibiliteten forsvant. Og som også gjorde at historiske prioriteringer ble liksom førende inn i fremtiden og. Det var kanskje et område som hadde et sterkt behov, og da tilførte vi det enten penger eller mennesker, og så ble de så godt vant med de folkene og de pengene at de var veldig lite interessert i å måtte gi det fra seg. (Epsilon) 

Det kan også være barrierer knyttet til skifte av medlemskap. Et eksempel er: 

Det er en god måte å spre kultur på at ansatte flytter mellom disse teamene. Men […] er det noen som har lyst på en ny utfordring? Du kan banne på at vi får ingen som rekker opp hånden, stort sett. Fordi folk blir så glad i teamet sitt, og de er så glad for å sitte i teamet. (Gamma) 

Det er ingen enkel løsning for hvordan dette dilemmaet kan håndteres. Bemanningen blir typisk et utfall av formelle prosesser for prioritering og uformell innflytelse. 

Agilitet i teamene 

Et team er altså knyttet til et varig produkt eller domene, og stabilitet i teammedlemskap vektlegges. Teamene er tverrfaglige, hvor utviklere jobber sammen med blant annet testere, interaksjonsdesignere (og ofte representanter fra forretningssiden), «scrum-ansvarlige», agile coacher, koordinert av produkteiere. På spørsmål om hva kjernen i dette agile er,i legges det størst vekt på autonomi og tilhørende arbeidsmåter og roller. 

Autonomi i teamet presenteres ofte som en kontrast til arbeidsmåte og styring i (de tidligere) prosjektene: 

Kjernen i agil organisering er at du jobber med team, og at du har autonome, selvstyrte team som får veldig tydelig mål og retning for hva de skal levere på. Men at de selv er ansvarlige for å finne beste løsning og beste arbeidsmåte for å komme frem til verdirealisering av de målene som er satt. (Beta 13) 

Nedbygging av omfanget av kontroll og styring sees på som en forutsetning for at teamene skal fungere godt. En illustrasjon på dette er: 

La oss kjøre et eksperiment ut mot sluttkunde, og så lærer vi og får en del data, og så justerer vi på det. Organisasjoner som har kommet veldig langt, de har den feedback-loopen daglig nesten, ukentlig, og da kan ikke forretningssiden sitte oppe i strategiavdelinger og forretningsutviklingsavdelinger og skrive tykke bunker av dokumenter. (Gamma) 

Autonomi krever at det enkelte teammedlem aktiviseres på en annen måte enn tidligere. Et intervjuobjekt peker på: 

[…] den viktigste effekten var at hvert medlem var forventet å «eie» det man bygger fra konseptfasen, via produksjon til anvendelse hos kunden […] de opplever at de skaper noe for kundene, i motsetning (til tidligere), da de bare ble gitt en instruksjon og skulle sette denne ut i livet. (Alfa 17) 

Arbeidet i teamet blir koordinert av en produkteier som ivaretar backlog, bidrar til samordning av aktiviteter i teamet og er et bindeledd til naboteam og andre deler av organisasjonen. Produkteier er en nøkkelperson, samtidig som man ikke må overstyre, men bidra til å utløse kreativitet og åpne for autonomi for de enkelte deltakerne i teamet. Det er viktig at produkteier bidrar til et godt samspill mellom deltakerne. I teamene inngår videre roller som agile coacher, «scrum-ansvarlige» og leveranse-lead og en meny av metoder som er knyttet til den agile paraplyen: scrum, digitale tavler, «design thinking», metoder inspirert av lean, med mer. 

Det legges også vekt på at agilitet krever et smart tankesett samt normer, holdninger og virkelighetsoppfatninger som gjør det mulig å jobbe sammen på tvers av fag og spisskompetanse, og hvor den enkelte evner å være kreativ og ta ansvar. Omfanget av kontroll, hierarki og muligheten for å endre arbeidsmåter må dermed sees i lys av organisasjonskulturen, og ikke bare de formelle trekkene ved organisasjonen. En av bedriftene satte i gang et eget program for å endre kulturen, slik at dette kunne være en støtte i overgangen til tverrfaglige produktteam og endrede arbeidsmåter. 

Den faglige dimensjonen: Innslag av supplerende strukturer

For den ansatte i den agile delen av virksomheten rettes oppmerksomheten mot teamet, oppgavene og samspillet med de andre deltakerne, som gjerne har en annen kompetanse som utfyller ens egen. Samtidig vil man typisk ha en spisskompetanse, som utvikler, designer, digital markedsfører eller produkteier. Et aktuelt spørsmål i alle virksomhetene er: Er det etablert en støttestruktur knyttet til denne spisskompetansen, i tillegg de tverrfaglige teamene? Tre forhold knyttet til fagområdet fremstår som viktige: sosial tilhørighet, faglig utvikling og spørsmålet om hvordan personalansvaret skal ivaretas. Et intervjuobjekt beskriver disse aspektene slik:

Vi ansatte folk rett inn i teamene, og så var det teamledere eller andre som hadde personalansvar. Det viste seg at det var primært to problemer som vi måtte løse. Det ene var at utviklerne meldte fra at de savnet en faglig utvikling, og i tillegg så var det mangel på sosial tilhørighet. (Gamma)

Oppgaveansvaret viser til ansvar for oppgaveutførelse og kvalitet (og ligger åpenbart hos teamet), mens personalansvaret er knyttet til medarbeideroppfølging og de formelle sidene ved arbeidstakerforholdet. I de virksomhetene vi har undersøkt, har man valgt ulike løsninger for å kombinere disse lederoppgavene. I én virksomhet var deltakerne i teamene (som utgjorde noen agile øyer i organisasjonen) organisert i en matrise, mens en annen virksomhet (se Gamma over) valgte å gjeninnføre matriseorganisasjonen:

Da børstet vi støvet, egentlig, av den gamle matrisen hvor du har fagmiljøer på den ene siden, og i gamle dager var det prosjekter på den andre. Men den store forskjellen er at vi byttet ut prosjektene med kryssfunksjonell teamstruktur, […] i fagmiljøene så skjer det ingen leveranser. Så fagavdelingene fokuserer på faglig utvikling, tilhørighet, det sosiale aspektet, og så er det teamene der man møtes og gjør leveranser. (Gamma)

Dette er dermed en ressurs-/teammatrise. For den enkelte er ansettelsen knyttet til en fagavdeling eller en ressursenhet. Her har man sin personalleder, og avdelingen er også kilde til faglig utvikling og sosial tilhørighet. Samtidig vil det være spenninger og avveininger mellom de to dimensjonene, noe som kommer til uttrykk i dette sitatet:

Hvis disse fagavdelingene blir […] kall det for mektige, for sterke, så kan det ødelegge dynamikken inn i teamene. […] det er produkteier som skal sette retning, og det er de forretningsmessige målene som er de riktige. Hvis det kommer en fagleder inn fra siden og sier at mitt fag er det viktigste, nå må dere gjøre sånn og sånn, det kan være litt krevende da. (Gamma)

Ressursdimensjonen er altså knyttet til de enkelte fag og fremheves i alle virksomhetene. I Alfa har man valgt å håndtere dette på en annen måte enn i Gamma. Ved innføring av gjennomgående teamorganisering ble fagavdelingene beholdt i den første fasen. Denne matrisestrukturen ble imidlertid jevnt over vurdert som en lite hensiktsmessig løsning, av flere grunner:

Personalleder har jo ikke da nødvendigvis så veldig god kjennskap til hva du jobber med, eller hvilken oppgave du står i, eller hva du bør prioritere. […] utviklerne kanskje følte seg mer hjemme i den gamle systemutviklingsavdelingen, og det var der mye av det sosiale skjedde. (Alfa 6)

[…] du blir trukket i så mange retninger, med ulike prioriteringer, ulike ledere, ulike roller og forventninger. (Alfa 7)

Ut fra dette ble matrisen bygget ned, og teamene inngikk deretter i stammer eller avdelinger i en mer helhetlig organisering. Samtidig er man bevisst på den faglige dimensjonen og at det er viktig å utvikle og dele kompetanse innen de enkelte fagområder.

For å bidra til utvikling og deling av spisskompetanse har både Alfa og andre virksomheter lagt vekt på å utvikle fagnettverk, eller communities of practice, som går på tvers av teamene og er organisert etter spisskompetanse. Dette kan forstås som supplerende, tverrgående strukturer i virksomhetene. Nettverkene skal være selvorganisert og behovsbasert, ifølge et intervjuobjekt:

Så har jo vårt prinsipp vært at det skal ikke være lederdrevet, det skal på en måte være kompetansedrevet. Og så er det lett å si, men i en hektisk hverdag så er kanskje alle travle nok i sitt team. Det er litt færre som vil ta det ansvaret, rett og slett. (Alfa 13)

Prosjekter har mindre betydning 

Vi har her beskrevet økt utbredelse av organisering i tverrfaglige, agile team. Våre intervjuer gir klare indikasjoner på høy endringsgrad i virksomhetene, samtidig som en mindre andel av endringene finner sted i prosjekter. Det er færre rene utviklingsprosjekter og mindre bruk av rene prosjektteam i dag enn for seks–sju år siden. Dette uttrykkes av flere intervjuobjekter: 

Ja, det som tidligere var prosjekter, er nå inni agile team. Stort sett. Så er det noen prosjekter som går på siden fremdeles. Men veldig mye av det som ellers ville vært prosjekter, det er flyttet inn i agile team. (Beta 6) 

Vi kaster (ikke ut) alle prosjektledere, for det er mye innen det faget som vi fortsatt trenger da. (Men) vi har ikke med oss veldig mye av den prosjektmetodikken. Det er teamene som gjør både nyutvikling og forvaltning innenfor sine domener. (Gamma) 

En implikasjon er at den tradisjonelle prosjektlederrollen fått mindre betydning, typisk på bekostning av en rolle som produkteier. Mange som tidligere har hatt ledende roller i prosjekter, jobber nå som produkteiere eller teamledere. Her vil erfaringen fra prosjektene (og agile metoder) komme godt med. Nedbygging av prosjektorganisering og -logikk omtales noe forskjellig i virksomhetene. I én virksomhet har man ikke lenger prosjektlederrollen, og benytter heller ikke prosjektbegrepet for å beskrive de midlertidige oppgavene. 

Diskusjon 

Vi har her beskrevet noen hovedtrekk i overgangen og spenningen mellom utviklingsprosjekter og produktteam. De momentene som er belyst, har flere implikasjoner for forskning, særlig når det gjelder a) forståelse av hva agil organisering faktisk innebærer, og b) betydning av midlertidig organisering og prosjektgrad i organisasjoner. 

1. Grad av stabilitet og varighet er viktig for å fange opp tidsdimensjonen i organisering. Vi har her fått frem at stabilitet/endring i organisering kan forstås ut fra tre dimensjoner: a) om oppgaven er avgrenset i tid og har en start- og sluttdato, b) hvilken varighet den organisatoriske enheten (her: teamet) har, og c) i hvilken grad det er stabilt medlemskap i teamet. Dette fremkommer av tabell 1. Vi har vist at produktteam (og andre varige team) skiller seg fra organisering av utviklingsprosjekter langs alle de tre dimensjonene.

   

   […] den viktigste effekten var at hvert medlem var forventet å «eie» det man bygger fra konseptfasen, via produksjon til anvendelse hos kunden […] (Alfa 17)

   Dette begrepsskjemaet åpner også for ulike kombinasjoner av disse dimensjonene. Vi har vist at et varig team kan være knyttet til et produkts levetid. Et team, og særlig et velfungerende team, kan også benyttes til en serie av prosjekter over tid. Bredin og Engberg (2020) har vist hvordan man i en prosjektbasert organisasjon gikk over fra å sette sammen et unikt team for hvert prosjekt, til å gjenbruke team i flere prosjekter over tid. Vi har her også vist at man vektlegger stabilitet i medlemskap, men i andre tilfeller kan hensynet til kompetanseutvikling, nye konstellasjoner og behovet for ny dynamikk i teamet medføre større utskifting over tid (Nesheim, 2021; Ancona et al., 2021).
2. De empiriske funnene har noen implikasjoner for forståelsen av agilitet og agil organisering. Forstått som evne eller utfall viser agilitet til at organisasjoner klarer å justere og utvikle seg og frembringe hyppige innovasjoner. Basert på våre intervjuer fremmes denne endringsevnen imidlertid ikke av en ukritisk bruk av midlertidige og prosjektbaserte strukturer. Våre funn utfordrer (den ofte implisitte) antakelsen om at agilitet er knyttet til endringsprosjekter og forståelsen av agilitet som evnen til å rekonfigurere ressurser. Ut fra innholdet i denne artikkelen (og nyere populærlitteratur) om agil, bør oppmerksomheten heller rettes mot varige team (som dekker både utviklings- og driftsoppgaver), og avveiningen mellom stabilitet og andre hensyn når de gjelder teamsammensetning over tid. Vi utfordrer dermed forståelsen av hva agil organisering og agile metoder innebærer, og bidrar til avklaring rundt virkemidlene som skal bidra til endringsevne og innovasjon. En viktig nøkkel er å forstå hva agile team er. Hvis det er slik at stabile heller enn midlertidige strukturer dominerer i virksomhetene, kan ikke kjernen i agilitet knyttes til prosjekter eller ligge i fleksibel bruk av personell mellom team. En annen egenskap som vektlegges, er tverrfaglighet og samspillet mellom personer med ulik kompetanse over tid. Dette er imidlertid godt kjent fra teamlitteraturen, og ikke unikt for agile team. Dette er argumenter for at kjernen i agil organisering må vise til samspillet mellom innslaget av stabilitet, tverrfaglighet og noen andre, unike egenskaper ved teamene. Våre respondenter trekker frem autonomi, agile metoder, kulturelle forhold og lite innslag av formell styring som sentrale elementer. Ut fra den empiriske undersøkelsen vil vi foreslå følgende definisjon: 

   Et agilt team:

   • er en tverrfaglig arbeidsgruppe med stor gjensidig avhengighet mellom medlemmene
   • har innslag av varighet og stabilitet i medlemskap
   • kombinerer utviklingsoppgaver og driftsoppgaver
   • har stort innslag av autonomi
   • bruker metoder som scrum og digitale tavler, og roller som agil coach og produkteier
   • støttes av en organisasjonskultur og styringsverktøy som åpner for frihet og selvstendighet i arbeidsgruppen
3. Studiet av prosjekter i virksomheter legger vekt på at dette best kan forstås som en særegen måte å organisere på; midlertidige enheter som løser unike engangsoppgaver. Litteraturen legger stor vekt på prosjektifisering, forstått som økt utbredelse av prosjektorganisering og prosjekt-mindset, på samfunns-, organisasjons- og individnivå (Maylor & Turkulainen, 2019). Denne undersøkelsen av agil organisering gir støtte for en motsatt hypotese: deprosjektifisering. Som det går frem av intervjuene, ble nye IT-løsninger for noen år siden typisk utviklet i egne utviklingsprosjekter. De aktuelle endringene fant altså sted i endringsprosjekter. Over tid er utviklingsarbeidet flyttet over i varige team, som produktteam, hvor man ivaretar både utvikling, drift og vedlikehold. Organisasjonen er skrudd sammen på en ny måte, organisering i prosjekter med tilhørende midlertidighet får mindre betydning, prosjektlogikken nedtones, og det blir mindre behov for prosjektledere. Denne hypotesen kan danne grunnlag for en rekke studier av prosjekter i og mellom organisasjoner.
4. Det er vel kjent at man kan organisere virksomheten langs flere dimensjoner, som oppgaver og fag. Virksomhetene i denne studien har tverrfaglige team som operative oppgaveenheter (produktbasert), med ulike former for strukturelle supplementer som ivaretar tilhørighet, utvikling og i noen tilfeller personalledelse knyttet til det spesifikke faget man er en del av. I flere av organisasjonene er det innslag av matriseorganisering, hvor det er både fagavdelinger (ressursenheter) og tverrfaglige team knyttet til selve oppgaven. Matriser som bygger på spesialiserte ressurser og prosjekter, har lenge vært kjent i faglitteraturen. Rasjonalet er enkelt sagt at ressursenhetene ivaretar personalansvar og faglig utvikling, mens stadig skiftende prosjekter og deltakelse i flere prosjekter på et gitt tidspunkt bidrar til fleksibel og effektiv bruk av spesialiserte ressurser (Bredin & Søderlund, 2011; Nesheim, 2021). Den organiseringen vi har avdekket, avviker fra denne ressurs-/prosjektmatrisen. Vi har fått frem at organisering i faste team kombineres med ressursenheter. Noen av virksomhetene har valgt å ha fagavdelinger (som impliser matrise), selv om oppgavesiden kjennetegnes av stabilitet med tilhørende trygghet og tilhørighet i teamet. Et forskningsspørsmål i forlengelsen av dette er: Gitt at varige tverrfaglige team er den operative grunnenheten i organisasjonen, under hvilke betingelser er det fornuftig å kombinere dette med fagavdelinger i en matrisestruktur? 

Konklusjon 

En forståelse av agil organisering bør i større grad legge vekt på tidsdimensjonen og ta hensyn til varigheten av oppgaver, team og medlemskap i team. Vi har vist empirisk at utviklingsprosjekter er blitt nedtonet til fordel for produktteam og andre varige team. Dette reiser en rekke spørsmål for forskning, knyttet til teamnivå, supplerende strukturer og innslag av prosjekter i organisasjoner. 

Referanser 

Ancona, D., Bresnan, H. & Mortensen, M. (2021). Shifting team research after COVID-19: Evolutionary and revolutionary change. Journal of Management Studies, 58, 289–293. 

Bakker, R. M. (2010). Taking stock of temporary organizational forms: A systematic review and research arena. International Journal of Management Review, 12, 466–468. 

Barton, D., Carey, D. & Charan, R. (2018). One bank’s agile experiment: How ING revamped its retail operation. Harvard Business Review, March–April, 59–61. 

Bredin, K. & Søderlund, J. (2011). The HR quadriad: A framework for the analysis of HRM in project-based organizations. The International Journal of Human Resouce Management, 22(10), 2202–2221. 

Bredin, K. & Engberg, C. (2020). Agile but fragile? Practices for sustained disciplinary expertise in project-based oranizations. Upublisert artikkel. 

Conforto, D. C., Salum, F., Amaral, D. C., da Silva, S. L. & de Almeida, L. (2014). Can agile project management be adopted by industries other than software development? Project Management Journal, 45(3), 21–34. 

Dingsøyr, T., Bjørnson, F. O. & Sporsem, T. (2021). Organisering av digitaliseringsprosjekter (Concept arbeidsrapport 2021-1). Norges teknisk-naturvitenskapelige universitet (NTNU). 

Dybå, T. & Dingsøyr, T. (2009). What do we know about agile software development? IEEE Software, 26(5), 6–9. 

Felipe, C. M., Roldán, J. L. & Leal-Rodríguez, A. L. (2016). An explanatory and predictive model for organizational agility. Journal of Business Research, 69(10), 4624–4631. 

Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The science behind DevOps: Building and scaling high performing technology organizations. IT Revolution. 

Grass, A., Backmann, J. & Hoegl, M. (2020). From empowerment dynamics to team adaptability: Exploring and conceptualizing the continuous agile team innovation process. Journal of Product Innovation Management, 37(4), 324–351. 

Hobbs, B. & Petit, Y. (2017). Agile methods on large projects in large organizations. Project Management Journal, 48(3), 3–19. 

Keegan, A., Ringhofer, M. & Huemann, M. (2017). Human resource management in organizational project management: Current trends and future projects. I Sankaran, S., 

Kelly, A. (2018). Project myopia: Why projects damage projects. Allan Kelly Associates. 

Maylor, H. & Turkulainen, V. (2019. The concept of organizational projectification: Past, present and beyond? International Journal of Managing Projects in Business, 12(3), 565–577. 

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

Nesheim, T. (2021). Exploring the resource manager role in a project-based organization. International Journal of Managing Projects in Business, 14(7), 1626–1641. 

Przybilla, L., Wiesche, M. & Krcmar, H. (2019). Emergent leadership in agile teams – an initial exploration. Upublisert artikkel. 

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

Raisch, S. & Birkenshaw, J. (2008). Organizational ambidexterity: Antecedents, outcomes, and moderators. Journal of Management, vo. 34, No. 3: 379–405. 

Serrador, P. & Pinto, J. K. (2015). Does agile work? A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040–1051. 

Skelton, M. & Pais, M. (2019). Team topologies. IT Revolution. 

Stray, V., Moe, N. B. & Hoda, R. (2019). Autonomous agile teams: Challenges and future directions for research. Upublisert artikkel. 

van Gerven, M. (2018, 16. november). From project teams to stable agile teams. Blogginnlegg Organize Agile. https://medium.com/organize-agile/from-project-teams-to-stable-agile-teams-5934c271a8fc 

Vestues, K. & Rolland, K. (2021). Platformizing the organization through decoupling and recoupling: A longitudinal case study of a government agency. Scandinavian Journal of Information Systems, 33(1), 5. 

Vishnubhotla, S. D., Mendes, E. & Lundberg, L. (2020). Investigating the relationship between personalities and agile team climate of software professionals in a telecom company. Information and Software Technology, 126, 106335. 

Zitkiene, R. & Deksnys, M. (2018). Organizational agility conceptual model. Montenegrin Journal of Economics, 14(2), 115–129. 

Noter 

1. At team er preget av stabilt medlemskap og er tverrfaglige, er godt
   kjent fra faglitteraturen. Disse trekkene kan dermed ikke være kjernen
   av det agile, og heller ikke det «nye» ved denne måten å organisere
   seg på. Det agile må derfor særlig ligge i andre aspekter ved organisering og prosesser som kommer i tillegg til forhold ved medlemskap og spisskompetanse.