Fra autonome team til produktutvikling med produktteam i en team-topologi
«The three things that motivate creative people — autonomy, mastery, purpose!» — Daniel H. Pink
Mange har lest boka til Daniel H. Pink og mener at han treffer godt. Vi agelistas har i alle fall tatt det til oss og jobber i selvorganiserende autonome team. Likevel sliter vi med tradisjonelle ledere som fremdeles driver med mikromanagement, insisterer på at vi skal følge deres planer, milepæler og estimater. De siste års digitale transformasjoner, farten på digitaliseringen i samfunnet, og den senere tids fokus på produktutvikling, gjør at vi kommer noen steg nærmere Pink sitt utsagn. Flere implementerer reelle autonome produktteam, styrer etter visjon og mål, følger opp resultater (outcome) og verdi, og ikke antall timer og leveranser. Så hva er autonome team og hva kjennetegner slike team?
Autonomi
Autonomi betyr selvstyre, selvrespekt, selvbestemmelse eller uavhengig innen ulike fagområder. Hvor autonomt er et autonomt team? En modell som kan hjelpe oss og som er noe benyttet i akademia er Hackman sin. Den beskriver fire ulike teamtyper og ansvarsfordeling mellom teamet og ledelsen. Tradisjonelle team ledes av en teamleder som bestemmer oppgavefordeling og overvåker fremdrift. Selvledede team, eller selvorganiserende som vi agelistas foretrekker, er team som har myndighet til å bestemme hvordan de selv skal utføre oppgavene, overvåke fremdrift og styre arbeidsprosessene sine.
Dette har store implikasjoner for lederrollen, både for teamlederen og andre ledere rundt teamene.
I selvdesignede team er medlemmene selv ansvarlige for utforming av teamet inkludert oppgavene over. De bestemmer også hvem som skal bli med i eller forlate teamet. I noen tilfeller har selvdesignede team også myndighet til rapportering både i teamet og til de utenfor teamet. Den siste typen team, og den mest autonome, er selvstyrte team. Et selvstyrt team har det ekstra ansvaret ved at de kan endre teamets hovedformå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 en 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 nærmeste til helt autonome produktteam. De færreste er og skal vel ikke være helt slik, i og med at man også må forholde seg til virksomhetens retning og mål. Hovedmålsetningen er det veldig ofte andre som rettmessig mener noe om. Det var heller ikke Hackman sin idé.
Innføringen av ekstra roller er ofte en trussel mot selvorganisering når teamene får beskjed om å etablere spesifikke roller. 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 om teamets oppgaver, men en gruppe som arbeider sammen ved å spille ulike roller.
Forskning viser at sammenlignet med andre teamstrukturer er autonome team mer effektive for å gjennomføre oppgaver med ny teknologi eller radikal innovasjon. Slik team er også avhengig av spesielle ferdigheter, nettverk, andre prosesser og belønningssystemer enn tradisjonelle team. De må utformes slik at medlemmers ekspertise og kompetanse har gode inter-team relasjoner for å skape samarbeid og kreativitet. I Sintef sitt forskningsprogram på Autonome team A-Team fant de at effektive team kjennetegnes av en sunn struktur og sammensetning av teamene, teammedlemmene har et stort nettverk og er involverte i beslutningene.
«Autonomi uten styring er ferie»
Uttalt litt mildere sier ofte tradisjonelle ledere at teamene må ha styring. Ofte også innforstått at de selv må ha kontroll. Styringen av slike team er imidlertid annerledes. Gode autonome team tar ansvar for sine oppgaver, har integritet, er transparent og organiserer selv sine oppgaver og prosesser. De utarbeider sine målsettinger sammen med ledelsen ved bruk av f.eks. OKR, visjon og retning for oppgavene. Ledelsens «styring» er å sette mål og rammer f.eks. ved å benytte «Mission Command» og OKR. Innen systemutvikling måler vi ofte på verdi 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 benyttete teknikkene for ledelse i organisasjoner med autonome team er transformasjonsledelse og tjenerledelse. Transformasjonsledere setter mål og visjon, coacher og støtter teamet og slik ledelse har forskning funnet at 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. En Scrum Master er et eksempel på en tjenerleder.
Produktutvikling
«Produktorganisasjoner er ikke for å betjene virksomheten, men for å løse problemer for våre kunder på måter som fungerer for vår virksomhet» — Marty Cagan
Produktutvikling kommer fra et noe annet perspektiv enn systemutvikling, og har f.eks. benyttet konsepter som Design Thinking før de ble tatt i bruk innen systemutvikling. Den er også mer fokusert på å bygge det riktige produktet, mens smidig har tradisjonelt vært mest opptatt av å bygge produktet på riktig måte. Produktutvikling fokuserer både på at man utvikler det riktige produktet og hvordan man utvikler det. Den omfatter hele prosessen med å bringe et nytt produkt ut på markedet. Sentrale aspekter er produktdesign, markedsføring, utvikling, sammen med ulike forretningshensyn og forretningsmodeller. Produktutvikling er transformasjonen av en markedsmulighet til et produkt som er tilgjengelig for salg.
Produktutvikling refererer vanligvis til alle trinnene som er involvert ved å bringe et produkt fra konsept eller idé gjennom utvikling, markedsintroduksjon og videreutvikling. Med andre ord inkluderer den hele produktets livssyklus. Denne tankegangen er utbredt i digitale virksomheter som f.eks. Facebook, Google, Netflix og i startup miljøer. Tankegangen har i den senere tid også fått utbredelse i tradisjonelle IT-organisasjoner som f.eks. NAV og Oslo kommune.
Marty Cagan er en av pionerene innen digital produktutvikling. Produktutviklingen er teknologi (digitalt) drevet, og kan i noen tilfeller også ha analoge komponenter som f.eks. både Amazon og Airbnb har. Prosessen for utvikling av digitale produkter omfatter samtidig utforskning og utvikling i en kontinuerlig prosess. Sentralt i prosessen er det tverrfaglige myndiggjorte produktteamet som har fått 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 Hackman sin 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 implementer i utviklingsteamene. Feature Team i figuren over.
I en produktutviklingsorganisasjon derimot eksisterer produktteamene for å betjene en virksomhet sine kunder på måter som oppfyller behovene til virksomheten. Produktteamene får kunde- eller forretningsproblemer å løse, blir gitt myndighet til å utforske og implementere en løsning, og være ansvarlige for resultatene.
Det kan se ut som en ubetydelig nyanse, men medfører en stor endring i hvem som leder og styrer produktutviklingen ved å gi et slikt ansvar og autonomi til teamene. Det er ikke lengre en annen enhet, eller noen andre som prioriterer og beslutter. Dette er for mange en stor forskjell, som påvirker nesten alt om hvordan teamene fungerer. Forskjellen resulterer i høyere motivasjon og moral, og viktigst av alt, resultater i form av verdi for kundene og virksomheten. Slike produktteam er en mellomting mellom selvstyrte team og selvledede team i Hackman sin modell.
Med et slikt produktfokus er grunnlaget lagt for å få til samskaping av digitale tjenester og produkter der ulike enheter deltar i den digitale transformasjonen for å nå virksomhetens mål.
Team-topologi
«Highly Aligned, Loosely Coupled» — Reed Hastings
For å få fart på digitaliseringen ønsker man at teamene er autonome, samstemte og arbeider for virksomhetens mål. Et viktig prinsipp for å skape denne endringsevnen og kontinuerlige produktutviklingen er å organisere seg for å fjerne avhengigheter slik at man reduserer behovet for kommunikasjon og koordinering.
«Flaskehalser og koordinering er drepen på fart» — Audun F. Strand
Et overdrevent fokus på leveranser av funksjoner ignorerer den menneskelige og teamrelaterte dynamikken som ligger i moderne systemutvikling. Det fører ofte til manglende engasjement, spesielt når den kognitive belastningen overskrides.
Team-topologier er en samling teknikker for hvordan man kan organisere team, hvilke funksjoner disse teamene utfører, og hvordan teamene kommuniserer med hverandre for å utvikle mest mulig verdi og god flyt. Det er en samling team og teamstrukturer, med tydelige og avgrensede ansvarsområder. De fire grunnleggende topologiene eller teamtyper: 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, tjeneste, brukerreise eller lignende. De er tverrfaglige og har muligheten til å levere inkrementer av et produkt uten å være avhengig av 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 komplekse teknologier og redusere den kognitive belastningen for teamene som benytter plattformen. Muliggjørende team assisterer andre team i en kort periode som en del av en overgang eller opplæringsperiode. I tillegg er det komplisert-subsystem-team. De tar seg av spesielle subsystemer og blir bare benyttet når det er helt nødvendig.
En slik organisering bør endres evolusjonært i takt med endrede behov. Da er man tilpasningsdyktig og teamene kan på best mulig måte samskape for å nå felles mål. Det er definert tre interaksjonsmetoder; samarbeid, X-as-a-service og fasilitering, illustrert i figuren over. Tankegangen fra team-topologi kan skaleres opp og ned, med mange team eller få team. I større virksomheter er de ofte organisert i produktområder.
F.eks. benytter både NAV IT og Oslo kommune Origo plattformer og plattformteam. Origo sin 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 f.eks. App Store eller Amazon.
En plattform tilbyr tjenester til verdistrømteamene som API’er, og det er viktig at plattformerteamet ikke blir gitt ansvar til alle ting som andre ikke har ansvar for. Da kan de bli en kombinasjon av plattformteam og mulighørende team, og man undergraver verdistrømteamenes eierskap til sine tjenester. Vi må ikke gjenskape siloene med overlevering fra verdistrømteam til plattformteam. Typiske tjenester som et plattformteam kan ha ansvar for er infrastruktur, tjenester for deployering, provisjonering, logging og monitorering. Hovedhensikten er å redusere den kognitive belastningen for verdistrømmteamene som har autonomt ende til ende ansvar. De kan benytte seg av plattformen for å levere i et høyere tempo med minimal koordinering.
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 plattformtenking i alle team, og la nye selvstendige domener og plattformer oppstå organisk i stedet. Det er nok også avhengig av størrelsen på organisasjonen. Plattformtenking handler ikke om gjenbruk, det handler om å legge til rette for utviklingen. Ulempen med plattformteam er at de ikke har direkte eksterne kunder, men andre team. Plattformteamet risikerer å bli veldig frakoblet hva virksomheten egentlig dreier seg om, og utviklingen kan bli av veldig teknisk karakter. Utviklerne behøver ikke å takle den virkelige verden med kunderettede produkter.
«Utviklere elsker å bygge plattformer, og uten sterk produktledelse vil de utvikle en større plattform enn nødvendig» — Allan Kelly
Site Reliability Engineering
Hvis man har en samling av komponenter som har lav endringstakt og er stabil over tid kan man vurdere å benytte Google sine praksiser og teknikker for håndtering av dem. Site Reliability Engineering (SRE) er en modell fra Google for forvaltning av stabile komponenter og tjenester. Selskaper som Google, Atlassian, Airbnb, Oracle, Apple m.fl. bruker i dag en slik modell. Både DevOps og SRE har fokus på å automatisere drift av tjenester slik at de er skalerbare og pålitelige. Et SRE-team har ansvar for et sett med komponenter og deres tilgjengelighet, ytelse, overvåking, beredskap, kapasitetsplanlegging og endringshåndtering. Modellen er på mange måter en implementasjon av DevOps med noen utvidelser. Teamet består av utviklere med spesiell interesse for drift, nettverk og problemløsning. De fokuserer på automatisering, og bruker minst 50% av tiden til utvikling. SRE implementerer DevOps på noen bestemte måter.
- Redusere organisatoriske siloer: For å redusere organisatoriske siloer bruker SRE samme verktøy som utviklerne og man har delt eierskap til koden for å skape et felles ansvar.
- Aksepter at feil er normalt: En viktig del av SRE er post mortems kulturen. Man analyserer og dokumenterer feil og sørger for at den samme feilen ikke kan oppstå flere ganger, uten at man legger skylden på noen.
- Implementer gradvise endringer: Ved å redusere kostnaden ved feil oppmuntrer SRE utviklere og produkteiere å bevege seg raskt, og implementerer endringer fortløpende.
- Utnytt verktøy og automatisering: Å utnytte verktøy og automatisering er en av de viktigste fundamentene i SRE, og minst 50% av tiden skal brukes til å utvikle dette. Velfungerende SRE-team har en god balanse mellom driftsoppgaver og programmering, slik at de kan opprettholde systemets tilgjengelighet og ytelse samtidig som de legger til rette for vekst.
- Måle alt: SRE definerer en rekke måter å måle verdi på, som Mean Time To Failure (MTTF) og Mean Time To Recovery (MTTR).
En slik konstruksjon med SRE-team vil også møte alle utfordringene med overleveringer. En mulig løsning kan være at man gradvis faser komponenter inn i en slik modell når de ikke lengre har like stort behov for endringer, og man kan flytte med noen av utviklerne.
Der er også en rekke andre nye team modeller som diskuteres ute i markedet men som er tatt lite i bruk. I alle fall innen systemutvikling. En er «Team of Teams» men vi agelistas foretrekker heller å tenke i produkt og/eller domene områder i stedet for et nettverk som vil bli veldig vanskelig å «aligne». Her en oversikt over noen andre modeller som ofte kommer opp i diskusjoner om selvledelse.
Det får bli en annen bloggpost.
Referanser
Bernstein, E. et al. (2016). Beyond the Holacracy Hype. Harvard Business Review.
Beyer B. et al. (2016). Site Reliability Engineering: How Google Runs Production Systems
Cagan, M. (2017). Inspired: How to create tech products customers love.
Hackman J.R. (1986). The psychology of self-management in organizations.
Gundelsby J.H. (2019). Selvbetjent tjenesteplattform.
Løvold A. (2017). Fra Smidig til DevOps til Kontinuerlig Produktutvikling i Autonome Team?
Løvold A. (2020). Fra smidig systemutvikling til storskala digital produktutvikling.
Patanakul, P. et al. (2012). Autonomous teams and new product development.
Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow.
Takk til Rune Storløpa Sparebank 1 for diskusjonene om ulike plattformer. Håper at jeg forstod noe av det.
