En delvis taksonomi av autonomiHva vil det si at et team er autonomt?

Nå som smidig har kommet forbi vippepunktet ønsker de fleste organisasjoner å organisere seg i kryssfunksjonelle og autonome team. Vi vet nemlig at autonomi er en av de fundamentale byggeklossene for menneskers motivasjon.

Men hva er egentlig autonomi? Hva vil det si at et team er autonomt? Autonomi kan bety forskjellige ting, og det kan være lurt å ha noen felles begreper vi kan bruke når vi diskuterer autonome team. I denne artikkelen ønsker jeg å skille på tre typer autonomi - prosessautonomi, resultatautonomi og designautonomi.

Prosessautonomi

Prosessautonomi vil si at et team selv kan velge hvordan de ønsker å organisere arbeidsprosessen sin. For utviklingsteam kan det si at de ønsker å bruke en standarisert scrum-prosess med alle seremonier som medfølger -sprintplanlegging, daglige standups, sprint review og sprint retrospective. Eller såkalt scrum-ish - at de kun velger det de anser som relevant for teamet og ignorerer resten. Eventuelt at de jobber med et kontinuerlig kanban-board uten å bruke noen faste seremonier i det hele tatt.

For mange som kommer fra klassisk prosjektledelse er dette det de først tenker på når de hører om autonome team. Prosjektmodellen kan ganske enkelt tilpasses til en modell hvor team har prosessautonomi, under visse begrensinger. PRINCE2 Agile gir for eksempel team mulighet til å praktisere prosessautonomi, så lenge leveransene gjøres i henhold til sprint og release-kadensen bestemt av prosjektgruppen. Men den spesifiserer fortsatt hvordan prosjektet skal utredes, initieres og overleveres. Det setter begrensinger på hvor langt autonomien kan strekkes.

Resultatautonomi

Resultatautonomi vil si at teamet får ansvar for å oppnå et resultat, men hvordan de oppnår det resultatet bestemmer teamet selv. Altså, om ledergruppen ønsker at det strategiske fokuset framover skal være på å øke brukeraktivering (fra engelsk “activation” i pirate metrics), så gir man teamet målet å øke aktivering med x% over en gitt tidsperiode, og lar dem selv teste ut løsninger for hvordan dette gjøres. Denne type autonomi er vanskeligere å tilpasse til prosjektmodellen siden man ikke kan:

• Planlegge arbeidet i forveien, siden man ikke vet hvordan problemet skal løses
• Forhåndsdefinere arbeidspakker, siden man ikke kan planlegge arbeidet.
• Overlevere til "linjeorganisasjon", siden løsningen må utvikles kontinuerlig av et team med domene- og kundeinnsikt.

Derfor krever resultatautonomi at man går over til såkalt produkttankegang hvor team eier et eller flere problemområder over tid, og er ansvarlig for både utvikling og forvaltning av løsningene.

Designautonomi

Designautonomi er et begrep jeg selv har funnet på, men som jeg tror er verdifullt om vi ønsker å lage en taksonomi av typer av autonomi. Her tenker jeg på design som i design av et system, ikke som i visuelt design. Som arkitekt og utvikler er dette selvfølgelig noe jeg er veldig opptatt av. Designautonomi vil si at et team har autonomi til å designe systemet sitt uten å bli påvirket av eksterne faktorer.

Eksterne faktorer kan for eksempel være at kjøreplattformen organisasjonen bruker gir begrensinger på mulige løsninger for teamet. Eller at når man konsumerer et API fra et annet team, gjør det visse antagelser om hvordan dataen skal brukes, og mulige måter å løse problemet på blir derfor begrenset. Eller kanskje det andre teamet tvinger dere til å bruke dårlig strukturert data, fordi de er bekymret for replisering av data.

En begrensende designfaktor veldig mange utviklingsteam møter gjelder teknologivalg. Om organisasjonen bestemmer at en bestemt skyleverandør eller lagringsteknologi skal brukes, er det mulig at det ikke tilbyr det riktige verktøyet i noen spesifikke situasjoner.

Ingen team eksisterer i vakuum, og når vi er en del av en organisasjon er det naturlig at det settes begrensinger på autonomien til et team. Den store utfordringen er selvfølgelig å sette begrensinger på en måte som gjør at teammedlemmene er motiverte for å løse teamets oppgaver, samtidig som vi leverer i henhold til organisasjonens mål og strategi. Jeg liker å bruke “stillas-metaforen” for strukturer man kan sette opp med mål å begrense autonomitet på riktig måte. Enkelt forklart er stillaser at man bruker en form for prosess eller organisasjonsstruktur for å sette yttergrensene for hva team kan gjøre, men innenfor dette “stillaset” får teamene selv styre hvordan de utfører oppgaver.

Prosess-stillaser

Et veldig klassisk stillas for prosess er deadlines eller koordinerte utrullinger. "Dere kan styre utviklingen som dere vil, men det må være ferdig innen denne datoen" (da gjerne med checkpoints underveis). Eller at man har en koordinert utrulling (typisk i et monolittisk system), for eksempel en gang i måneden.

En mer moderne organisasjon vil typisk heller be team om å rulle ut så ofte som mulig. Men de kan fortsatt velge å bruke sprinter som en mulighet til å ha en fast kadens på visse prosesser (som backlog-grooming, retrospektiv, og lignende), og for å ha en fast “synkronisering” med andre områder i organisasjonen.

For et godt eksempel på en velbegrunnet prosess-stillas kan jeg anbefale å lese gjennom oda sin utviklingsprosess - flow.

Resultat-stillaser

Resultat-stillaser vil si hvordan vi sikrer at det teamene jobber med er knyttet til selskapets strategier og mål. Den enkleste måten å gjøre dette på, er selvfølgelig å la en form for ledegruppe forhåndsdefinere alle oppgaver og så sende de videre til enkelte utviklere, eller team, for å gjennomføres. Dette er det få organisasjoner som fortsatt gjør, da det ikke er en motiverende måte for de fleste å jobbe på, man begrenser mulig innovasjon (siden man ikke utnytter ideer generert fra flere mennesker) og man får ikke utnyttet ekspertisen til kunnskapsarbeiderne som utfører arbeidet (som tross alt er det man betaler dem for).

Men selv om man har gått bort fra denne aller mest rigide måten å organisere resultatoppnåelse på, er det fortsatt ganske stort spenn i hvor langt ledere går i det å gi resultatautonomi.

Et veldig populært resultat-stillas i disse dager er OKR (objectives and key-results), som kan være verdt å se på dersom man ønsker å gi team mer resultat-autonomi. En annen modell (som er mye mindre deskriptiv) er Tight-Loose-Tight, som jeg skrev en kort introduksjon til på bloggen tidligere.

Design-stillaser

Design-stillaser vil ofte være regler om spesifikke teknologier som må brukes. For eksempel kan en organisasjon kreve at team bruker en relasjonell database. Problemet er at relasjonell databaser er et verktøy som har visse styrker og svakheter. Dersom et team da skulle jobbe med et problem som løses mye bedre av en dokument-database, men driftsavdelingen ikke vil drifte en slik løsning og ikke la teamet drifte en selv, blir man tvunget til å gjøre et sub-optimalt designvalg på grunn av for rigide stillaser rundt teknisk design. En måte å bygge stillas for teknisk infrastruktur som øker i popularitet er det såkalte “golden path” eller “paved road”-stillaset. Det vil si at man har en “anbefalt plattform” som tilbys alle team i organisasjonen, og driftes av et sentralt plattform-team. Ønsker man å bruke noe annet, er man selv ansvarlig for å sette det opp og drifte det. Dersom flere team skulle ønske å ta i bruk denne løsningen over tid, vil plattform-teamet absorbere den, og tilby den i “golden path”-plattformen til alle team.

Et annet typisk problem man ser i arkitektur og løsningsdesign er deling av data og oppførsel mellom tjenester som er eid av forskjellige team. Det vil si at for at team A skal få gjort en oppgave med "riktig" design, så er de avhengig av at team B gjør en endring i en tjeneste som de utvikler og forvalter. Dette er et veldig komplekst problem, da det ofte faktisk er avhengig av prosess- og resultatautonomiet til team B. Om team B har en rigid prosess eller er fokusert “innover” (altså på sine egne resultater og leveranser, istedenfor organisasjonen som helhet), er det stor sjanse for at team A må vente lenge på funksjonaliteten de trenger. Da er det sannsynlig at team A, i fokuset på å bli ferdig med sin oppgave, lager en sub-optimal løsning for å bli ferdig, istedenfor å vente på/samarbeide med team B om å utvikle en bedre løsning. Dette betyr at en sterkt begrenset prosess- og resultatautonomi i en organisasjon vil føre til lavere kvalitet på tekniske løsninger. Dette vil videre føre til en unødvendig kompleks arkitektur, og teknisk gjeld. Dette stemmer veldig godt overens med min egen erfaring.

Et generelt råd jeg vil anbefale alle som ønsker å bevege seg mot mindre rigide stillaser er konseptet “Team API” fra Team Topologies. Det vil si at team lager et offisielt “interface” mot teamet - hvordan man når teamet, hvordan de organiserer arbeidet sitt, hva de jobber med og skal jobbe med fremover, hvordan de ruller ut nye features, hvilken teknologi de bruker og så videre. En slik struktur vil gjøre det lettere for en organisasjon å tillate høyere grad av autonomi, uten at det oppleves som kaos.

Inspirasjon

Dette innlegget ble inspirert av to innlegg av Kristin Wulff:

• Selvbestemmelse over resultater
• Har teamet ditt resultatautonomi?

Klikk her for flere blogginnlegg