Oppsummering av Remote Team Interactions Workbook
En bok om hvordan mønstre fra Team Topologies kan bidra til økt fart og flyt og redusert kognitiv last i en remote hverdag.
Veldefinerte metoder for samhandling og kommunikasjon mellom team er viktig for å drive effektiv og bærekraftig digital produktutvikling. Det er spesielt viktig i en remote setting. Denne oppfølgeren til Team Topologies er en praktisk guide i hvordan Team API, monitorering av avhengigheter, tilrettelegging for god flyt og læring kan hjelpe oss på vei.
Remote Team Interactions Workbook fungerer som en “boosterdose” av Team Topologies. Man må ikke lese Team Topologies først for å ha nytte av den, men det er helt klart anbefalt.
Kognitiv last
For å håndtere en remote eller hybrid hverdag på en best mulig måte trenger vi mer enn chat- og videoverktøy. Vi trenger blant annet også tydelige prinsipper og praksiser for hvordan vi kan samhandle og kommunisere, både internt i et team og på tvers av flere team. Disse prinsippene og praksisene vil gjøre det enklere for oss å jobbe sammen på en god måte. De bidrar i tillegg til å tydeliggjøre relasjoner og avhengigheter mellom ulike grupperinger og team, og hva meningen med aktiviteter som pågår på tvers faktisk er. I sum får vi da redusert kognitiv last, som i sin tur gjør at vi kan rette en større del av den kognitive kapasiteten vår mot det som betyr noe.
Se også Google re:Work om psykologisk trygghet og hva som ellers kjennetegner gode team.
Her er en Team Cognitive Load Assessment Template (Github) som kan brukes som utgangspunkt til undersøking av kognitiv last i et team.
Team API
Et team sitt Team API kan ses på som en brukermanual som forklarer andre hvordan de kan og bør interagere med teamet. Det er altså ikke et API i ordets rette forstand, men et “API” for mennesker. Det er et slags vindu inn mot teamet, som på en enkel måte sørger for økt transparens og åpenhet om hva teamet jobber med og hvorfor.
Team API-et kan for eksempel inneholde noe om
- Produkter og annet som eies av teamet
- Hvilken teamtype teamet er (stream aligned, platform, enabling, complicated subsystem)
- Når og hvordan man enklest kommer i kontakt med teamet (slack-kanaler e.l)
- Hvordan teamet ønsker å samhandle med andre (collaboration, facilitating, X-as-a-service)
- Hvor man finner wiki eller annen dokumentasjon
- Mål og prioriteringer
- Praksiser og prinsipper (for eksempel hvordan teamet gjør utvikling, versjonering og testing)
Publisering av slik informasjon, på en enkel og forståelig måte, vil kunne bidra til å redusere kognitiv last hos andre (utenfor teamet). Som en direkte konsekvens av det kan vi få redusert den kognitive lasten i teamet også. For eksempel gjennom at avbrytelser og context switching reduseres.
Hvor og på hvilken måte ville du publisert team API-er for å gjøre informasjonen enklest mulig tilgjengelig for andre i organisasjonen?
Her er en Team API Template (Github).
Overvåking av avhengigheter
Forutsatt at alle team er en del av et sosioteknisk system, vil de før eller siden støte på situasjoner hvor de avhenger av andre team for å få jobben gjort. Vi bør derfor visualisere og følge med på avhengigheter og hvordan de utvikler seg, slik at vi enklere kan snakke om hvordan de bør utvikle seg og hva vi kan gjøre med det.
Hensikten med Team Topologies er å optimalisere for fart og flyt gjennom å blant annet fjerne avhengigheter og behov for koordinering mellom team. Det kan oppnås gjennom å dyrke fram arkitektur og team som tillater fullt eierskap, per team, til verdistrømmen de jobber med. Det vil sjelden være realistisk å fjerne alle avhengigheter, men vi bør etterstrebe å identifisere hvilke av de som er problematiske og som vi dermed bør jobbe for å fjerne eller redusere. En problematisk avhengighet fører til forsinkelser og uforutsigbarhet, at arbeid stopper opp, at work in progress (WIP) øker eller annet som gjør at teamet mister både fart og flyt.
Her er en Team Dependencies Tracking Template (Github).
For videre dypdykk i hvordan man kan visualisere avhengigheter anbefaler Matthew Skelton og Manuel Pais boken Making Work Visible av Dominica DeGrandis. Ved å google boktittelen Making Work Visible finner man flere opptak av foredrag også.
Nettverk og kompetansedeling
Remote Team Interactions Workbook snakker også en del om viktigheten av å tilrettelegge for uformelle sosiale nettverk, flyt av informasjon og kompetansedeling på tvers av avdelinger og team. Dette er spesielt viktig i en remote setting, hvor man typisk ikke får de tilfeldige møtene i lunsjen og ved kaffemaskinen. Nettverksbygging og kompetansedeling er viktig for å bli kjent og å bygge tillit som kan danne et grunnlag for framtidig samarbeid.
En av flere måter å oppnå dette på, som det snakkes om i boken, er å arrangere interne fagdager og konferanser hvor man kan delta remote og hvor alle som deltar kan føle seg inkludert. Victoria Morgan-Smith og Matthew Skelton har skrevet en egen bok (Internal Tech Conferences) om hvordan det kan gjøres.
Andre grep man kan gjøre for å motvirke statisk stillesitting i digitale siloer er for eksempel digital speed networking på tvers av organisatoriske skillelinjer, quiz, felles kaffepauser, jevnlige faggruppemøter og lignende.
Skriftlig (over)kommunisering
Særlig i en remote setting er det viktig å hele tiden være veldig tydelig på hva vi jobber med, hvorfor vi jobber med det, hvordan vi jobber for å dra det i land og når vi sikter på å være ferdige. Vi kan kommunisere dette på flere måter, som for eksempel ved å:
- Dele beslutninger i en egnet Slack-kanal
- Forklare større beslutninger og design i en Wiki
- Forklare viktige konsepter i en presentasjon, rapport e.l
Vi kan ikke forvente at alle får med seg alle chat-meldinger, og vi vet ikke nødvendigvis hvem som trenger hva eller når de trenger det. Vi bør derfor, kort fortalt, gjøre det enkelt for andre å sette seg inn i viktige beslutninger som er tatt og hvorfor. Det vil gjøre det enklere å forstå hva som ledet fram til hva teamet jobber med. Informasjonen må være lett å finne og enkel å forstå. Det kan redusere kognitiv last for både teamet og andre.
Gruppestørrelse, samhold og tillit
Fra forskningen gjort av Robin Dunbar vet vi at det finnes en øvre grense for hvor mange vi klarer å ha en nær sosial relasjon til. Hver og en av oss klarer stort sett ikke å ha mer enn omtrent 150 meningsfulle relasjoner gående på samme tid, og det gjelder både fysisk og digitalt. Grensene for hvor tillit og dynamikk endres i en gruppe går ved omtrent 5, 15, 50, 150, 500 og 1500 personer. En vil derfor kunne oppnå større grad av tillit og samhold, og dermed også bedre evne til innovasjon og eksperimentering, i et lite team (typisk 5–9 medlemmer) enn i et større et.
Vi kan bruke Dunbar til å mene noe om hvor mange team som bør operere innenfor samme forretnings- eller produktområde også. Et område med få team og færre enn 50 personer totalt, vil ha bedre forutsetninger for samhandling og kommunikasjon på tvers av teamene enn hva tilfellet er i et større område hvor det er flere folk og team å forholde seg til.
Når avdelinger og grupperinger i organisasjonen vokser forbi grenseverdien for ønsket group trust level, kan det være fornuftig å splitte opp i mindre enheter.
Det samme kan sies å gjelde for online samhandlings- og kommunikasjonsverktøy som Slack og lignende. Her bør man ha ønsket grad av tillit og psykologisk trygghet i bakhodet når man setter opp workspaces og kanaler. Når vi sitter på hjemmekontor har vi dessuten ikke det fysiske kontorlandskapet som hjelp til å skape naturlige områder og avgrensninger.
Digitale samhandlingsområder, som for eksempel et Slack workspace, bør i tillegg være orientert rundt forretningsområder og verdistrømmer hvor alle involverte kan være med. Vi bør unngå egne områder basert på roller og funksjoner — som jo da fort blir til digitale siloer som motvirker fart og flyt.
Her er en Trust Boundaries Template (Github) som kan brukes til å vurdere grupperinger opp mot Dunbars grenser. Det finnes en Online Space Assessment Template også.
Konvensjoner for chat
Vilkårlige kanalnavn, ufullstendige personnavn eller (for noen) kryptiske kallenavn gjør et chat-verktøy forvirrende og vanskelig å bruke. Om det i tillegg er en overflod av private kanaler kan det bli tilnærmet umulig å treffe de riktige folkene eller oppdage kanalen hvor en diskusjon eller spørsmål hører hjemme. Det er ikke effektivt, og det spiser av den kognitive kapasiteten vår. Vi trenger derfor også et sett med konvensjoner som gjør verktøyene konsistente, forutsigbare og enklere å bruke.
Eksempler på konvensjoner som foreslås er
- Inkludere teamtype i kanalnavn der hvor det er relevant. For eksempel #streamteam-dagpenger og #platformteam-designsystem.
- Gjør det enkelt å vite hvor man kan stille spørsmål eller få hjelp ved å prefikse kanalnavnet med support eller tilsvarende. For eksempel #support-naisplatform.
- Angi tilhørighet som del av personnavn, for eksempel “Anders Skifte (Team sosioteknisk)”.
Det kan også være en god idé å feste (pin) eller bokmerke instruksjoner for selvbetjening og hvordan be om hjelp i relevante kanaler. Videre nevnes automatisk arkivering av inaktive kanaler som et tiltak for å holde kanallisten oversiktlig. Slack Gardener av Equal Experts er et open source verktøy som gjør blant annet det. Samme selskap har laget en Slack Usage Guide også som kan være til inspirasjon med tanke på konvensjoner å følge.
I forbindelse med onboarding av nye medarbeidere kan det kanskje ha noe for seg å la en bot foreslå kanaler verdt å følge. Et spørsmål det uansett kan være verdt å stille seg, er: Hvor enkelt er det for en nyansatt å finne frem til hvilke kanaler som er relevant for vedkommende å følge?
Samhandlingsmønstre
Blant organisasjoner som driver med kunnskapsarbeid og innovasjon, vil en organisasjon hvor alle kommuniserer og samhandler med alle hele tiden prestere dårligere enn organisasjoner hvor dette foregår på en mer strukturert måte. Det er bedre å organisere seg i team og grupperinger som kommuniserer og samhandler med hverandre mer sporadisk. Måten team samhandler på, og hva meningen med samhandlingen er, er derfor en nøkkelindikator for hvor godt organisasjonen presterer.
Fra Team Topologies kjenner vi de fire teamtypene stream aligned team, platform team, enabling team og complicated subsystem team. Disse bruker mønstrene samarbeid (collaboration), fasilitering og X-as-a-service for samhandling på tvers. Poenget er å tilrettelegge for fart og flyt, gjennom struktur og gjenkjennbare mønstre for kommunikasjon og interaksjon.
Samarbeid mellom to team kan være nyttig for å jobbe mot et felles mål, men det bør foregå over en begrenset periode da det spiser av den kognitive kapasiteten vår. Fasilitering bør også være nokså kortvarig. Om behovet for samarbeid eller fasilitering vedvarer over flere måneder, kan det være et tegn på at noe ikke fungerer optimalt. Kanskje noe kan endres for å redusere avhengigheten? X-as-a-service, hvor et team konsumerer en tjeneste som leveres av et annet, bør helst ikke være like krevende. Her er det viktig at tjenestetilbyder søker feedback og at kundene (øvrige team) har en enkel måte å gi det på, slik at problemer og muligheter kan fanges opp og gjøres noe med. Begge parter bør også være årvåkne for endringer i kontekst som medfører endring i omfang og innsats. Kanskje ansvarsfordelingen må snakkes om?
Vi bør ha disse mønstrene i mente når vi tilrettelegger for remote jobbing også. For eksempel kan potensiell god kommunikasjon mellom team fort drukne i kanaler hvor annen informasjon også kringkastes. Kanskje kan man opprette en egen kanal for spesifikk samhandling mellom to team, som arkiveres når samhandlingen opphører? Jamfør ovennevnte konvensjoner bør kanalnavnet i så fall være selvforklarende — for eksempel ved at begge teamnavn og aktuelt samhandlingsmønster inngår i det. Slike kanaler tilrettelegger for åpen dialog mellom teamene, og motvirker tendensen til at det heller sendes direktemeldinger mellom enkeltpersoner.
Anbefalt lesning
Remote Team Interactions Workbook (Using Team Topologies Patterns for Remote Working) byr på mye god innsikt, gode eksempler og solide referanser — og ikke minst massevis av refleksjonsøvelser med mer for hvordan gripe problematikken fatt i egen organisasjon.
Dersom du er interessert i fart og flyt, er denne boken for deg!
Om du ikke allerede har lest Team Topologies, så vil jeg anbefale den også. Den er for øvrig oppsummert med key takeaways her.
