Fart og flyt er viktig for NAV. Vi ønsker at arbeid skal flyte så uhindret som mulig fra idé til produksjon. Dette forutsetter hensiktsmessig organisering av teamene våre rundt fornuftig avgrensede ansvarsområder tilpasset teamenes kognitive kapasitet. Videre kan vi optimalisere for fart og flyt ved å fjerne eller redusere avhengigheter som skaper behov for koordinering mellom team. Det kan oppnås gjennom fullt eierskap, per team, til verdistrømmen eller domenet de jobber med. I tillegg kan vi redusere teamenes kognitive belastning gjennom å avlaste de fra oppgaver som ikke er direkte tilknyttet disse verdistrømmene og domenene. På den måten kan vi frigjøre kapasitet i teamene til å jobbe med det som betyr noe.

La oss definere noen begreper før vi går videre:

• Et team er en stabil gruppe mennesker som jobber som en enhet og som avhenger av hverandre for å nå et felles mål. Medlemmene har felles ansvar for resultatet, og tilbringer majoriteten av arbeidstiden sin i teamet.
• Teamtopologi beskriver sammensetningen av team av ulike typer og relasjonene dem imellom.
• Sosioteknisk arkitektur handler om at system og organisasjon må ses i sammenheng og at de ikke kan designes hver for seg. Systemarkitektur påvirkes av hvordan teamene er organisert og hvordan og hvorfor de kommuniserer og samhandler med hverandre. Dette går begge veier. Organisering og kommunikasjonslinjer påvirkes også av systemarkitekturen. Observasjonen ble først beskrevet av Mel Conway i artikkelen How Do Committees Invent, i 1968.
• Kognitiv kapasitet beskriver mengden informasjon arbeidsminnet kan holde på en gang. Om systemet vi jobber med er for stort eller komplisert til å få plass i hodene våre, får vi kognitiv overbelastning. Det samme gjelder om vi jobber med for mange systemer på samme tid. Kognitiv overbelastning er en flaskehals som bremser fart og flyt, og vi må derfor ta høyde for kognitiv kapasitet når vi designer team og systemer.

Så, hvordan går vi frem for å få det til?

I NAV har vi mange team som jobber med digital produktutvikling. Enten ved at de bygger og har ansvar for egne produkter, eller ved at de støtter opp om team som gjør det. For at dette maskineriet skal fungere best mulig ønsker vi å tilpasse oss teamtyper og samhandlingsmønstre kjent fra Team Topologies.

Hypotesen er at økt bevissthet omkring teamtyper vil hjelpe oss å:

• Gjøre det tydeligere for teamene hva de skal levere og for hvem.
• Øke rolleklarhet slik at hensikten med det enkelte team blir tydeligere for alle.  Det skaper forutsigbarhet og er tillitsbyggende.
• Legge bedre til rette for og styrke teamenes evne til effektiv samhandling med hverandre.

Et naturlig sted å starte er å avdekke dagens teamtopologi og å hjelpe teamene våre å forstå hvilken teamtype de er.

For flere av teamene vil det være enkelt å se hvilken teamtype de er. For noen kan det være vanskelig å identifisere seg med bare én av de. Kanskje de er en hybrid av flere typer? Andre team vil kanskje mene at de er noe annet og at de ikke ligner på noen av typene.

Om det er uklart eller ukjent for teamet hvilken teamtype de er, så kan vi heller forsøke å finne ut hvilken type de bør sikte mot. Da kan vi bruke denne teamtypen som utgangspunkt til å peke retning for hvordan teamet og teamets rammer bør utvikle seg. Dermed kan vi på sikt få mer fokuserte team som gjør færre ulike ting, som får redusert kognitiv last og som det blir enklere for andre å forholde seg til.

Bærekraftige team

I NAV har vi en sosioteknisk ambisjon om å bygge bærekraftige team med eierskap til problem og løsning. Men hva er et bærekraftig team? Vi kan for eksempel definere det slik:

Et bærekraftig team opprettholder en høy grad av motivasjon, psykologisk trygghet og tilfredshet blant medlemmene, samtidig som det holder god fart over tid. Teamet er fleksibelt og tåler fravær eller utskifting av enkeltpersoner.

For at et team skal kunne nå sitt fulle potensial må vi ta vare på folkene og tilrettelegge for at de skal kunne prestere bra sammen. Nedenfor følger et sett med prinsipper og beste praksiser vi kan bruke for å hensynta bærekraft når vi etablerer og endrer team og ansvarsområder. Disse gjelder alle teamtyper.

Teamstørrelse

Ideell teamstørrelse er normalt fem til ni personer. Flere enn det vil kunne begrense tryggheten og tilliten internt i teamet så mye at det gå ut over fart, kvalitet og innovasjon. Et høyt antall interne kommunikasjonslinjer, som øker eksponentielt med antall medlemmer, gir i tillegg mer overhead og større behov for koordinering i teamet.

Stabilitet Vs. fleksibilitet

Det er en fordel om et team er stabilt over tid. Det tar tid å bygge opp tryggheten og tilliten som trengs i et team for at det skal kunne prestere bra. Samtidig må vi ha fleksibilitet til å endre team ved behov. Tiltak for å gjøre seg mindre sårbar ved endring kan for eksempel være at kunnskap og kompetanse deles i teamet, slik at nøkkelpersonrisiko reduseres. Om vi i tillegg skriver kode på en måte som gjør at flere kan forstå det får vi bedre bærekraft i både team og systemer.

Myndighet og hensikt

Myndiggjøring kombinert med tydelig retning og hensikt skaper tettere bånd mellom teammedlemmene. Det bidrar til at teamet opptrer mer som en sammensveiset enhet og at det følgelig presterer bedre. Å ha innflytelse over eget arbeid er en sterk driver for tilfredshet, og det er både motiverende og prestasjonsfremmende. Inspirerende mål og tydelig hensikt tilfører mening, som skaper ytterligere motivasjon og som gjør at teamet bedre forstår sin rolle. Ledere og andre på utsiden av teamet bør ikke tildele arbeidsoppgaver til enkeltpersoner, men alltid til selve teamet som selv prioriterer og finner ut hvem som gjør hva.

Ansvar tilpasset kognitiv kapasitet

Ansvarsområdet må tilpasses teamets kognitive kapasitet. Det gir mestringsfølelse og motivasjon, og setter teamet i stand til å jobbe effektivt. Dersom ansvarsområdet eller domenet er for stort og komplisert for et team, bør vi søke å dele det opp i mindre biter som tilordnes flere separate team. Det kan være fristende å øke teamstørrelsen i stedet, men om teamet blir større enn ideelt kan også det by på utfordringer. I tillegg vil ikke tilførsel av nye medlemmer umiddelbart gi økt kapasitet, men snarere det motsatte – som forklart av Brooks lov.

Om teamet har ansvar for flere kompliserte domener kan det ofte være en fordel å splitte opp teamet, slik at det for eksempel blir to separate, litt mindre team med ansvar for hvert sitt domene. Det reduserer behovet for koordinering og kommunikasjon, og gir lavere kognitiv belastning siden ingen trenger å kunne flere domener i detalj.

Om vi lesser på med ansvar uten å ta høyde for kognitiv kapasitet, svekkes teamets motivasjon og evne til å jobbe effektivt. Mestringsfølelsen går ned, myndigheten reduseres og innsatsen oppleves mindre meningsfull. Teamet kan oppleve å bli dratt i flere retninger, slik at også prioritering blir vanskelig. Enden på visa er at teamet slutter å opptre som en samlet enhet. De opptrer i stedet som en samling løst koblede individer som jobber med hver sine ting. Å jobbe som individualister med digital produktutvikling er ikke bærekraftig.

Teamtyper

De fire teamtypene fra Team Topologies er:

• Verdistrømteam (Stream-aligned team)
• Tilretteleggingsteam (Enabling team)
• Subsystemteam (Complicated subsystem team)
• Plattformteam (Platform team)

Verdistrømteam er den primære og vanligste teamtypen. De øvrige teamtypene danner til sammen et støtteapparat som avlaster og understøtter verdistrømteam.

Produktteam inngår ikke blant teamtypene fra Team Topologies. Vi bruker derimot produktteam som en samlebetegnelse for de teamtypene som har digital produktutvikling som hovedfokus. Dette omfatter verdistrømteam, plattformteam og subsystemteam.

Verdistrømteam

En verdistrøm er en kontinuerlig strøm av arbeid innenfor et avgrenset forretningsområde eller domene. Den kan være tilknyttet hele eller deler av et produkt eller tjeneste. Likeledes kan den være avgrenset til en bestemt brukergruppe eller brukerreise og inkludere flere produkter. En verdistrøm består av alle aktiviteter og oppgaver som skal til for å skape verdi for brukeren, innenfor et gitt domene (se bounded context). Et verdistrømteam er innrettet langs og har ende-til-ende-ansvar for en slik verdistrøm. Det betyr at teamet håndterer hele arbeidsflyten selv.

Med slike team får vi det vi kaller en vertikal arbeidsdeling. Det betyr at teamene håndterer alle lag nedover i design- og teknologistacken og at de kan levere verdi på egenhånd uten å koordinere med andre. En horisontal arbeidsdeling, hvor spesialiserte team i stedet tar ansvar for hver sin lagvise del av den samme stacken, er i dag å betrakte som et anti-pattern. Eierskapet blir spredt og vi får blant annet økt behov for kommunikasjon og koordinering mellom teamene.

Å jobbe med en verdistrøm, fra idé til verdi, forutsetter at teamet har den kompetansen og de kapabilitetene som kreves. Teamet må følgelig være både tverrfaglig og myndiggjort. Relevante kapabiliteter i teamet kan være, men er ikke begrenset til:

• Sikkerhet
• Domene- og fagkunnskap (for eksempel tolkning av regelverk)
• Design og UX
• Utvikling og arkitektur
• Produktledelse
• Måling og analyse
• Testing

Det betyr ikke at teamet må være stort, med minst én person per kapabilitet, men at at det kan bestå av noen få spesialister og flere generalister som alle bidrar der de kan. Om teamet kun består av spesialister, som ikke bidrar utenfor sitt felt, blir teamet større samtidig som vi får flere flaskehalser.

Hvordan opptrer et verdistrømteam?

Eksempler på atferd som kjennetegner et verdistrømteam er at de:

• Etterstreber en jevn flyt av endringer og har minimalt med (helst ingen) overleveringer til andre team.
• Jobber brukernært basert på eksperimentering, læring og forbedring.
• Bruker målinger og feedback aktivt for å kunne korrigere kursen kjapt.
• Setter av tid og jobber aktivt med teknisk gjeld og vedlikehold.
• Er proaktive og oppsøker øvrige teamtyper for hjelp og støtte, ved behov.

Tilretteleggingsteam

Et tilretteleggingsteam (enabling team) består normalt av eksperter innen et gitt kompetanseområde, som har i oppdrag å hjelpe et eller flere verdistrømteam med å skaffe seg nye kapabiliteter og kunnskap. Det kan styrke teamenes autonomi og gjøre de i stand til å jobbe mer effektivt og å overkomme hindringer.

Et tilretteleggingsteam kan for eksempel være spesialisert innen kontinuerlig leveranse og automatisering. Slike team hjelper vanligvis til over en begrenset periode, og jobber for å spre kunnskap og å gjøre seg selv overflødige. Et tilretteleggingsteam kan ellers bli en flaskehals som flere til slutt avhenger av. Å lene seg på dedikert ekspertise er en langt mer effektiv måte å tilegne seg ny kunnskap på, enn om de som jobber i verdistrømteam må investere tid og krefter i å finne ut av alt selv. Det ville gått på bekostning av fart og flyt.

Hvordan opptrer et tilretteleggingsteam?

Eksempler på atferd som kjennetegner tilretteleggingsteam er at de:

• Ivrer etter å forstå problemer, mangler og behov som andre team har eller opplever, slik at det kan gis mest mulig treffsikker hjelp og rådgiving.
• Fasiliterer og bistår uten å gjøre selve jobben for det mottakende teamet, slik at kunnskap spres og nye kapabiliteter tilegnes i stedet for at det skapes nye avhengigheter.
• Har rom for og jobber aktivt med å holde seg oppdatert og i front innenfor sitt ekspertiseområde. Kunnskap deles generøst med andre.

Subsystemteam

Et subsystemteam (complicated subsystem team) har ansvaret for å utvikle og vedlikeholde en komponent, eller del av et system, som er så komplisert at det kreves spesialistkompetanse for å gjøre det. Det kan være kompetanse som er både tidkrevende å bygge og vanskelig å finne, og som vi dermed ikke har tilstrekkelige mengder av til å sette inn i flere verdistrømteam. Å utvide slike team med flere spesialister kan dessuten være lite hensiktsmessig. Teamet vokser kanskje forbi ideell størrelse, samtidig som vi risikerer at ansvarsområdet vokser forbi teamets egentlige mål og hensikt.

Da kan det være bedre å innrette seg på en måte som gjør at et eller flere verdistrømteam i stedet kan konsumere subsystemet som en intern tjeneste, utviklet av et eget subsystemteam. På den måten bidrar sistnevnte teamtype med å redusere den kognitive lasten hos førstnevnte, som jo også er hensikten.

Det er identifiserte behov for spisskompetanse og et ønske om redusert kognitiv last, og ikke en øynet mulighet for gjenbruk av noe mer generelt, som er driverne bak oppretting av et subsystemteam.

Hvordan opptrer et subsystemteam?

Eksempler på atferd som kjennetegner et subsystemteam er at de:

• Samarbeider mest intensivt med et eller flere verdistrømteam i tidlig og utforskende fase av utviklingen. Dette avtar, og teamet jobber mer selvstendig etter hvert som subsystemet tar form og stabiliseres.
• Holder høyere fart og leverer bedre kvalitet enn hva tilfellet hadde vært om et eller flere verdistrømteam utviklet subsystemet selv.
• Behov fra verdistrømteam tas i betraktning og er førende for hvordan subsystemteamet prioriterer og hva de leverer.

Plattformteam

Et plattformteam leverer interne tjenester som øvrige team avhenger av. Med plattform menes et fundament bestående av API-er for selvbetjening, verktøy, tjenester, kunnskap og support — pakket inn som et internt produkt. Hensikten er, som for de øvrige støtteteamene (subsystem- og tilretteleggingsteam), å redusere kognitiv last hos verdistrømteamene slik at best mulig flyt opprettholdes.

En velfungerende plattform fordrer naturligvis god devEx (developer experience), som i at API-er og tjenester er av høy kvalitet, at de er stabile og enkle å bruke, og at de er formålstjenlige. Med en plattform-som-produkt-tankegang forsøker plattformteamet å gjøre plattformen så attraktiv og friksjonsfri at øvrige team foretrekker den og velger å bruke den av fri vilje. Derfor kan både UX og produktledelse være vel så nødvendige kapabiliteter i et plattformteam, som i et verdistrømteam.

En plattform bygges og vedlikeholdes ikke nødvendigvis av bare ett team. Om plattformen vokser i omfang kan være hensiktsmessig å fordele arbeidet på flere team av ulike typer som jobber med hver sine deler av den. Plattformteamet blir i praksis da en gruppering av flere team med hver sine interne ansvarsområder og verdistrømmer.

Hvordan opptrer et plattformteam?

Eksempler på atferd som kjennetegner et plattformteam er at de:

• Ser på verdistrømteam som sine kunder, og samarbeider tett med de for å forstå behovene.
• Ser på plattformen som et digitalt produkt og handler deretter. Eksperimenterer, lærer og forbedrer basert på feedback fra brukerne (team som bruker plattformen).
• Går foran med et godt eksempel og konsumerer sine egne, interne tjenester eller andre, underliggende plattformtjenester fra andre plattformteam, når mulig. Plattformteam lener seg også på øvrige teamtyper ved behov.

Øvrige teamtyper og grupperinger

I teamkatalogen i NAV finnes det team og grupperinger som enten ikke passer med teamtypene fra Team Topologies, eller som det av andre grunner er naturlig å holde adskilt fra disse. Det gjelder for eksempel grupperinger som bedre beskrives som arbeidsgruppe enn team, da medlemmene møtes sporadisk og ikke tilbringer majoriteten av tiden sin der.

I tillegg finnes ulike ledergrupper som riktignok kan omtales som team, men som foreløpig ikke omfattes når vi avdekker og tilpasser teamtyper i henhold til nevnte topologier. Derfor er også arbeidsgruppe, ledergruppe, prosjektgruppe og annet mulige valg når team og grupperinger oppdaterer sin informasjon i teamkatalogen.

Samhandlingsmønstre mellom team

Hvordan team samhandler og hva meningen med samhandlingen er, er en nøkkelindikator for hvor godt en organisasjon presterer. Begrensninger i den menneskelige båndbredden for kommunikasjon, som sier noe om hvor mye informasjon vi klarer å oppfatte eller formidle, gjør at vi må være bevisst på hvilke team som samhandler, hvorfor de samhandler og på hvilken måte. Å samhandle tett med flere team legger stort beslag på båndbredden og fører til høyere kognitiv last. Det skaper behov for koordinering og kan oppleves krevende. Tett samhandling mellom team er naturlig i en utforskende fase (discovery), men vi bør deretter søke en mindre krevende måte å samhandle på.

Team Topologies foreslår tre forskjellige mønstre for samhandling mellom team. Poenget er å tilrettelegge for fart og flyt gjennom struktur og gjenkjennbare metoder for kommunikasjon og interaksjon. De tre mønstrene er:

• Samarbeid (collaboration): To team samarbeider om et felles mål.
• X-as-a-service: Et team tilbyr et API eller en tjeneste som konsumeres av et eller flere andre team.
• Fasilitering: Et team hjelper et annet med å tilegne seg nye ferdigheter og kompetanse.

Tett samarbeid mellom to team egner seg for eksempel når vi trenger hurtig utforsking av ny teknologi og teknikker, eller i tidlig-fase utvikling og innovasjon. Det gir mest verdi når teamene har ulik kompetanse og kan mobilisere sin felles kunnskap for å løse problemer. Teamene må ha delt ansvar for overordnet utfall om samarbeidet skal fungere. I tillegg bør det være klart hvem som har hvilket ansvar etter at samarbeidet opphører. Tett samarbeid er krevende og bør derfor bare foregå over en begrenset periode. Vedvarende tett samarbeid over flere måneder kan være et symptom på mangelfull tilrettelegging for at teamene skal kunne opptre selvstendig. Kanskje grensene mellom teamenes ansvarsområder må justeres? Eller kanskje et av teamene mangler kompetanse og ferdigheter som kreves for å løse oppdraget sitt?

X-as-a-service, hvor et team konsumerer en tjeneste fra et annet, er mindre krevende og kan pågå over lang tid. Ansvarsområdene er tydelig avgrenset mellom teamene, og liten eller ingen grad av kommunikasjon er nødvendig. Det gjør at tilbydende team kan håndtere mange samtidige konsumenter. Høy grad av kommunikasjon mellom tilbyder og konsument er et tegn på at noe ikke fungerer optimalt og at grep bør tas. Kanskje tjenesten er for lite brukervennlig eller for dårlig dokumentert til at konsumentene kan være selvbetjente? Slik friksjon medfører høyere kognitiv last for begge parter. Derfor er det viktig at tjenestetilbyder aktivt søker feedback og at konsumentene (øvrige team) har en enkel måte å gi det på, slik at problemer og muligheter kan fanges opp og gjøres noe med. Plattform- og subsystemteam tilbyr typisk sine tjenester via X-as-a-service.

Fasilitering egner seg når et eller flere team trenger hjelp med å tilegne seg ny kunnskap om hvordan løse et gitt problem. Fasilitering, som her også kan omfatte mentoring og coaching, er et samhandlingsmønster som er mye brukt av tilretteleggingsteam. Målet er at teamene som mottar hjelp skal bli selvgående så fort som mulig, og at det ikke bygges permanente avhengigheter mellom teamene.

Vi må forvente at samhandlingsmønster mellom team endres jevnlig, avhengig av hva vi ønsker å oppnå. To team kan for eksempel gå fra innledende tett samarbeid til mer sporadisk samarbeid, før de til slutt går over til X-as-a-service. Topologien for øvrig må også kunne endres evolusjonært og i takt med stadig endrede behov. Det vitner om en endringsdyktig organisasjon.

Økt endringsevne, fart og flyt

Team Topologies gir oss et felles vokabular og felles forståelse som gjør det enklere å snakke om hvordan vi organiserer teamene i NAV. Vi tror vi kan oppnå flere positive effekter ved å ta de nevnte mønstrene i bruk. Teamtypene kan i kombinasjon med domenedrevet design gi oss bedre definerte team og ansvarsområder – i tråd med kognitiv kapasitet, kompetanse og ønsket arkitektur. Det gjør mål og mening med det enkelte team tydeligere, og vi får økt rolleklarhet.

Med økt tydelighet får vi også bedre forutsetninger for effektiv samhandling på tvers av teamene. Vi blir mer bevisst på hvor lenge og til hvilket formål vi bør bruke de ulike samhandlingsmønstrene. Dersom samhandlingen lugger eller skurrer, eller på annen måte føles ikke-ideell, kan vi bruke det som et signal om at noe burde fikses. Med andre ord kan det bli enklere å fange opp når et team eller ansvarsområde bør endres.

Team Sosioteknisk kan bistå

Team sosioteknisk (NAV-intern lenke) er et tilretteleggingsteam som har som misjon å hjelpe team og produktområder med å oppnå fart og flyt. Teamet bidrar med kompetanse, veiledning og coaching innen domenekartlegging, sosioteknisk arkitektur, teamtopologi og bygging av fremragende team.

Lurer du på noe angående tematikken i denne artikkelen, eller sosiotekniske problemstillinger for øvrig? Send oss ei melding i kanalen #team-sosioteknisk-værsågod på Slack, da vel! 🙌

Mer om hvordan NAV har latt seg inspirere av Team Topologies:

• A conversation with Matthew Skelton – Team Topologies (En åpent tilgjengelig episode fra NAVs interne podcast, IT-simpelthen)
• How the internal technology platform creates value at NAV (Teamtopologies.com)