«The three things that motivate creative people — autonomy, mastery, purpose!» — Daniel H. Pink.
Mange har lest boka og mener at Pink treffer godt. Vi agelistas (av «agile», smidig) har i alle fall tatt det til oss og jobber i selvorganiserende autonome team. Likevel sliter vi med tradisjonell styring og ledelse.
«Selvstyrte grupper er i konsekvens et frontalangrep på den hierarkiske og byråkratiske organisasjonen.» – Einar Thorsrud
Det er nok noe av årsaken. De siste års digitale transformasjoner, farten på digitaliseringen og fokuset på produktutvikling gjør at vi er kommet mange steg videre. Mange etablerer reelle autonome produktteam, leder med visjon og mål, følger opp resultater («outcome») og verdi, ikke antall timer og leveranser.
Hva er autonome team, og hva kjennetegner slike team?
Autonomi
Autonomi betyr selvstyre, selvrespekt, selvbestemmelse eller uavhengighet innen ulike fagområder. Hvor autonomt er et autonomt team? En modell som kan hjelpe oss, og som benyttes i akademia, er Hackmans. Den beskriver fire ulike teamtyper og ansvarsfordeling mellom teamet og ledelsen. Tradisjonelle team ledes av en teamleder som bestemmer oppgavefordeling og følger opp fremdrift. Selvledede team, eller selvorganiserende – som vi agelistas foretrekker å kalle dem, er team som har myndighet til å bestemme hvordan de selv skal utføre oppgavene, arbeidsprosessene og følger opp fremdrift.
Dette har store implikasjoner for lederrollen, både for teamlederen og andre ledere utenfor teamene.
I selvdesignede team er de selv ansvarlige for utforming av teamet, inkludert oppgavene over. De bestemmer også hvem som skal være i teamet. I noen tilfeller har de også myndighet til rapportering til andre. Den siste og mest autonome typen er selvstyrte team. De har det ekstra ansvaret ved at de kan endre teamets formål og retning. Eksempel på slike team er lovgivende forsamlinger, styrer, rådgivende organer og partnerskap. Denne team-konstruksjonen er spesielt krevende siden de i tillegg til selvledelse ikke har en ledelse å henvende seg til for mål og retning.
De fleste smidige utviklingsteam er i én av de to kategoriene til venstre. Noen team eksperimenterer med å la ledelsen av teamet rotere. Noen team får også delta i, eller til og med bestemme, teamsammensettingen. Den siste kategorien, selvstyrende team, er den nærmeste til helt autonome produktteam. De færreste er og skal vel ikke være helt slik, i og med at man også skal forholde seg til virksomhetens strategi og mål. Noe som også andre veldig ofte rettmessig mener mye om. Det var heller ikke Hackmans idé.
Autonomi er ikke anarki!
Det er ikke det vi ønsker å få til. Det er graden av autonomi som er viktig.
Innføringen av ekstra roller er ofte en hindring for teamarbeid. Det er ikke det Hackman omtaler som å styre sin egen arbeidsprosess og selvledelse. En slik rollebesetning medfører overlevering internt i teamet, og det blir ikke et velfungerende team som samarbeider og tar ansvar for teamets oppgaver, men en gruppe som arbeider sammen ved å spille ulike roller.
«Autonomi uten styring er ferie.»
Tradisjonelle ledere sier ofte noe mildere at teamene må ha styring – ofte innforstått at de selv skal ha kontroll. Styringen av slike team er imidlertid annerledes. Gode autonome team tar ansvar for sine oppgaver, har integritet, er transparente og organiserer selv sine oppgaver og prosesser. De utarbeider sine målsettinger sammen med ledelsen ved bruk av for eksempel OKR (Objectives and Key Results), visjon og strategi for teamet. Ledelsens «styring» er å fasilitere og utarbeide mål og rammer sammen med teamet. Vi måler ofte verdien teamene skaper for virksomheten, endringshyppighet og kvalitet på endringene, ende-til-ende-flyt og psykologisk sikkerhet.
Ledelse av autonome team er også annerledes enn ledelse av andre type team, roller og oppgaver. De mest benyttede teknikkene for ledelse i organisasjoner med autonome team er transformasjons- og tjenerledelse. Transformasjonsledere setter mål og visjon, coacher og støtter teamet. Slik ledelse fremmer kunnskapsdeling og bidrar til innovasjon. Tjenerledere legger til rette for teamet, motiverer og utvikler teamet, tjener teamets interesser foran egne, myndiggjør og utvikler teammedlemmene.
Produktutvikling
I en produktorganisasjon er produktteamene til for å levere til en virksomhets brukere eller kunder på måter som understøtter virksomhetens behov.» — Marty Cagan
Produktutvikling kommer fra et noe annet perspektiv enn systemutvikling. Den er mer fokusert på å bygge det riktige produktet og hvorfor, mens smidig tradisjonelt har vært mest opptatt av å bygge produktet på riktig måte. Produktutvikling fokuserer både på utforskning og utvikling. Det er alle stegene for å bringe et produkt fra idé gjennom utvikling, markedsintroduksjon og videreutvikling. Hele produktets livssyklus.
Denne tankegangen er utbredt i digitale virksomheter som for eksempel Facebook, Google, Netflix og i startup-miljøer. Tankegangen har i den senere tid også fått utbredelse i tradisjonelle IT-organisasjoner, som for eksempel Nav og Oslo kommune. Produktutviklingen er teknologi- og brukerdrevet og kan i noen tilfeller også ha analoge komponenter, slik for eksempel Amazon og Airbnb har.
Sentralt i prosessen er det tverrfaglige, myndiggjorte produktteamet som tar ansvar for hele prosessen for et eller deler av et produkt. For å få frem poengene sine har Marty Cagan laget en modell for å sammenligne ulike typer team. Den gir en tilleggsdimensjon til Hackmans for å forstå autonome team.
I mange virksomheter eksisterer utviklingsteamene for å betjene forretningssiden. Ofte, selv om det ikke er eksplisitt uttalt, ender andre deler av virksomheten med å drive det som faktisk blir implementert – «Feature Team» i figuren over. Et overdrevent fokus på leveranser av funksjoner mister fokus på den menneskelige og teamrelaterte dynamikken som ligger i moderne systemutvikling. Det fører ofte til manglende engasjement, spesielt når den kognitive belastningen blir for stor.
«Produktteamene har bruker/kunde- eller forretningsproblemer å løse, blir gitt myndighet til å utforske og utvikle en løsning, og være ansvarlige for resultatene.» — Marty Cagan
Det kan se ut som ubetydelige nyanser, men medfører en stor endring i hvem og hvordan man leder og fasiliterer produktutviklingen ved å gi et slikt ansvar og autonomi til teamene. Det er ikke lenger en annen enhet eller noen andre som prioriterer og beslutter. Dette er for mange en stor endring. Forskjellen resulterer i høyere motivasjon og engasjement og, viktigst av alt, resultater i form av mer verdi for brukerne og virksomheten. Slike produktteam er en mellomting mellom selvstyrte team og selvledede team i Hackmans modell.
Forskning viser at sammenlignet med andre teamstrukturer er autonome team mer effektive for å gjennomføre oppgaver med ny teknologi eller radikal innovasjon. Slike team er også avhengig av spesielle ferdigheter, nettverk, andre prosesser og belønningssystemer enn tradisjonelle team. De må få til gode inter-team-relasjoner for samarbeid og kreativitet. Effektive team kjennetegnes av en sunn struktur og sammensetning av teamene, de har et stort nettverk og er involvert i beslutningene.
Det er sterk sammenheng mellom teamets mulighet til selvstyring og psykologisk trygghet – og en direkte sammenheng mellom psykologisk trygghet og teamets produktivitet og evne til å lære. Autonomien gjør utviklerne mer villige til å eksperimentere, ta initiativ og lete etter nye løsninger, viser forskningen. Den bidrar til høyere psykologisk trygghet og øker teamets evne til å utvikle seg, lære og forbedre seg.
Dette er ikke noe du kan vedta, det er noe du må gjøre, du må gjøre det hver dag, og du må fortsette å gjøre det.
Team-topologi
«Alignment» muliggjør autonomi.
«Highly Aligned, Loosely Coupled» — Reed Hastings
For å få fart på digitaliseringen ønsker man at teamene er autonome, «alignet» og arbeider mot virksomhetens mål for å få til:
Fart og flyt – med innsikt.
Et viktig prinsipp for å skape denne endringsevnen og utviklingen er å organisere teamene for å redusere avhengigheter, slik at man reduserer behovet for kommunikasjon og koordinering.
«Flaskehalser og koordinering er drepen på fart.» — Audun F. Strand
Team-topologier er en samling teknikker for hvordan man kan organisere team, hvilke funksjoner disse teamene utfører og hvordan teamene kommuniserer med hverandre. Det er en samling team og teamstrukturer med tydelige og avgrensede ansvarsområder. De fire grunnleggende typene er verdistrøm-, plattform-, muliggjørende og komplisert-subsystem team.
Verdistrømteam, produktteam er kanskje et bedre navn, er den typen team man har flest av i en produktutviklingsorganisasjon. De håndterer hele eller deler av et produkt, et domene, en brukerreise eller lignende. Teamene er mer tverrfaglige og kan levere inkrementer av et produkt med få avhengigheter til andre team. Andre typer team eksisterer for å understøtte disse teamene.
Et plattformteam arbeider med den underliggende plattformen og støtter opp under verdistrømteam ved å forenkle teknologien og redusere den kognitive belastningen for teamene. Muliggjørende team assisterer andre team i en kort periode som del av en overgang eller opplæringsperiode. Komplisert-subsystem-team håndterer spesielle subsystemer og benyttes bare når det er helt nødvendig.
En slik organisering endres evolusjonært i takt med endrede behov. Det er definert tre interaksjonsmetoder; samarbeid, X-as-a-service og fasilitering. Tankegangen fra team-topologi kan skaleres opp og ned, med mange team eller få team. For eksempel benytter både Nav IT og Oslo kommunes Origo plattformer og plattformteam. Origos tjenesteplattform er beskrevet her. Den er nok bredere enn plattformer beskrevet i Team Topology. Slike utvikler- eller tjenesteplattformer er ikke det samme som en digital plattform i et digitalt økosystem, som for eksempel App Store eller Amazon.
En plattform tilbyr tjenester til verdistrømteamene som API-er, og det er viktig at plattformteamet ikke blir gitt ansvar for alle ting som andre ikke har ansvar for. Da kan de bli en kombinasjon av plattformteam og muliggjørende team, og man undergraver verdistrømteamenes eierskap til sine tjenester. Vi må ikke gjenskape siloene med overlevering fra verdistrømteam til plattformteam.
Andre argumenterer for at det er bedre å operere med flere plattformteam som spesialiserer seg i sine egne domener, enn å ha et enkelt plattformteam. De argumenterer for plattformtenkning i alle team og å la nye plattformer oppstå organisk. Det er nok også avhengig av størrelsen på organisasjonen. Plattformtenkning handler ikke om gjenbruk, det handler om å legge til rette for utviklingen. Ulempen med plattformteam er at de ikke har direkte eksterne kunder. De risikerer å bli for frakoblet virksomheten, og utviklingen kan bli av veldig teknisk karakter. Utviklerne kommer for langt unna til å forstå hva brukeren egentlig ønsker å få utført.
«Utviklere elsker å bygge plattformer, og uten sterk produktledelse vil de utvikle en større plattform enn nødvendig.» — Allan Kelly
Der er også en rekke andre nye teammodeller som diskuteres ute i markedet, men som er tatt lite i bruk. En er «Team of Teams». Mange foretrekker å tenke i produkt- eller domeneområder som er noe lettere å «aligne» enn en nettverksorganisasjon.
Kronikken er en forkortet utgave av en tidligere publisert bloggpost.
