Erfaringer fra arbeid i tverrfaglige team

Photo by Marvin Meyer on Unsplash

I hele min karriere har jeg vært opptatt av å skape et nært bånd mellom design og utvikling. I team jobber man ofte mot de samme målene, og er avhengig av hverandre for å nå dem. Ved å ha et åpent sinn og transparent arbeidsmiljø, vil man kunne lære en hel del, om og av andre, som nesten alltid vil komme til nytte. I min tid som konsulent har jeg opplevd og blitt kjent med mange ulike kunder, prosesser, team og mennesker. Om det er noe viktig jeg har lært, så er det at samarbeid på tvers av fag, og tett kommunikasjon, er helt nødvendig når man jobber i tverrfaglige team.

Men hva syntes jeg har fungert bra, og hva har fungert mindre bra? Og hva må til for at et team skal føle at det er på bølgelengde? Noen tanker rundt disse spørsmålene, og egne erfaringer, skriver jeg om i innlegget. Innholdet er like relevant for designere og utviklere, som ledere, forretning- og domeneekspeter.

Transparens og åpenhet

Et team som er transparent, er et team som kommuniserer åpent og ærlig om arbeidet og prosessene de har. Når man vet hva alle de andre i teamet ditt jobber med og hvilket ansvar de har, og samtidig vet at alle de andre har motivasjonen for å ville levere like bra som deg, og du vet hvem du kan snakke med om ulike problemstillinger, da vet du at teamet er på samme bølgelengde.

Èn av ni løsninger

I et møte hos en tidligere kunde ble jeg plutselig overrasket. Det jeg ble vitne til da, var to avdelinger som knapt kommuniserte med hverandre. La oss kalle dem for avdeling A og B — begge avdelingene var eid av samme selskap, A var bruker og B jobbet med utvikling. Avdeling A holdt et innlegg for avdeling B om hvordan de jobbet i sin avdelingen, og hvilke verktøy de brukte. De brukte èn av ni verktøy som avdeling B hadde laget for dem. De åtte gjenværende verktøyene løste ikke lengre de utfordringene som avdeling A hadde. Avdeling A forklarte hva som var problemet med de åtte verktøyene og hadde sjeldent noe positivt å si om dem. Den niende løsningene ble derimot sett på som det eneste brukbare, som fra Avdeling B sin side var et utdatert, usikkert og et dårlig lagd system. Uten å ha kommunisert utfordringene tidligere, kjøpte avdeling A andre verktøy og løsninger, og la til side de som ikke ble brukt, uten å si noe til Avdeling B. Vel uvitende jobbet avdeling B med optimalisering og forbedring, i god tro om at det de hadde skapt ble brukt. Grunnen til at kun èn av ni løsninger ble brukt, var i hovedsak mangelen på kommunikasjon mellom avdelingene. Ingen av partene var åpne om systemenes tilstand eller tok initiativ til å diskutere fremtidige behov og utfordringer. Ingen av partene var heller så interessert i hva den andre parten gjorde eller jobbet med, enda de satt vegg i vegg med hverandre.

Selv om historien over ikke handlet om det tverrfaglige teamet, er poenget det samme. Dersom man unngår å holde hverandre informert om utfordringer, kan lignende situasjoner oppstå. Man bør ikke kommeet punkt hvor man bare leter etter feil, før man forsøker å kommunisere eller løse de utfordringene man allerede har.

Synliggjøring

Åpenhet kommer tydelig frem når man synliggjør hvem som er ansvarlig for hva. Den personen som starter med en oppgave, er sannsynligvis den mest kompetente til å løse den i starten — mens andre kan bli mer kompetente på sikt. Synliggjøring av kompetanse og ansvar gjør at teamet blir bedre på å delegere arbeid og teammedlemmene vet hvem man kan spørre om hjelp for ulike problemstillinger. Samtidig bidrar synliggjøring til at informasjon ikke holdes skjult, men det er heller en strøm av ressurser og ideer som flyter mellom medlemmene. Synliggjøring er med på å skape tillit i teamet og styrker hvordan man samarbeider i sin helhet.

Oppsummering: Transparens og åpenhet

Jeg tror at team som er transparente har mindre utfordringer og at problemer løses raskere. Grunnen kan være at i transparente team, vil man jevnlig snakke om utfordringer, feil man har gjort og bekymringer. Medlemmene kjenner hverandres styrker og svakheter. Strømmen av informasjonen som flyter rundt i teamet gjør det tydelig hvem som har ulikt ansvar, oppgaver og kompetanse. Teammedlemmene har stor tillit til hverandre. De er ikke redd for å dele, få tilbakemeldinger eller motta kritikk, fordi teamet i utgangspunktet deler med hverandre. Dersom vi tør å snakke om feilene vi gjør, vil vi unngå at andre gjør dem også. Vi må godta at andre kan gjøre feil, og gi dem ros når de deler erfaringene med oss.

Kunnskapsdeling

Kunnskap er ferskvare, mens erfaring får man jo mer man anvender kunnskap. Når man deler kunnskap, bidrar man til at andre kan utforske den samme kunnskapen og bygge mer erfaring. Deling er en kritisk forutsetning for personlig og andre sin utvikling. Noen ganger har vi behov for å få andres perspektiver, gjennom tilbakemeldinger, innspill og konstruktiv kritikk for å utvikle oss.

Deling mellom designere og utviklere

Det viktigste et tverrfaglig team gjør for å holde hverandre oppdatert, er å dele kunnskap. Team som jevnlig deler kunnskap vil kunne diskutere kompleksitet i mye større grad, på tvers av fagområder, enn team som ikke gjør det.

La oss ta for oss noen fordeler som utviklere og designere kan få ut av å dele kunnskap: Utviklere kan få bedre innsikt i hvordan designere arbeider og verktøyene de bruker. Man vil oppdage feil og mangler lettere. Man får bedre forståelse for informasjonsarkitektur, brukertesting, universell utforming og kontraster, for å nevne noe. Dette gjør det mulig for utviklere å ta egne avgjørelser og gjøre endringer i grensesnittet uten å være avhengig av en designer til enhver tid. Designere kan få bedre innsikt i hvordan komponentene (samspillet mellom koden og designet) oppfører seg i brukergrensesnittet. Skisser og prototyper kan utvikles med dypere teknisk innsikt når man skal lage nye eller videreutvikle eksisterende løsninger. Designeren blir mer bevisst på hvordan data prosesseres og flyter mellom systemene — fra backend via frontend til sluttbrukeren — og kan sammenligne kode og design.

Jo mer designere og utviklere vet om hverandres fagområder, desto bedre vil man kunne diskutere forandringer i utseende, tekniske utfordringer, prioriteringer, ytelse og testing m.m. Det vil være enklere å holde kode, design og dokumentasjon synkronisert. Designsystemer kan være svært nyttig til dokumentering, og er et fint verktøy for å samle, synkronisere, strukturere og organisere informasjon i èn felles plattform (en såkalt «single source of truth»). Designere og utviklere som er synkroniserte tar bedre avgjørelser, alene og i fellesskap.

Oppsummering: Kunnskapsdeling

En ting jeg husker spesielt godt, fra et tidligere prosjekt, var da jeg og en designer gjorde par-programmering og par-design for å dele kunnskap. De gangene vi leste kode, forklarte jeg hvordan koden og elementene i grensesnittet — designet — hang sammen. Andre ganger satt vi i Figma og diskuterte hvilke tekniske utfordringer vi måtte tenke på når designet skulle utformes. Designeren inviterte meg stadig med på brukertesting for å observere hvordan brukerne opplevde å bruke applikasjonen i den stegvise utviklingen over seks uker. Det viste seg å ha stor verdi for løsningene vi lagde i ettertid. Personlig har det også vært en svært nyttig erfaring for løsninger jeg har bidratt med å lage i andre prosjekter. Når man lærer bort trenger det ikke alltid være noe nyttig, det viktigste er at man får noe ut av læringen. Lær bort det du vet kan være nyttig for andre. Det finnes utallige måter å dele kunnskap på og det kan skje i mange ulike forum. Whiteboard med notislapper, verktøy som Trello, Figma eller discussions i Github er noen eksempler.

Frihet og eierskap

I tiden vi lever i nå, hvor endringer skjer utrolig raskt, er bedrifter helt avhengig av å fornye seg for å henge med. Kreative prosesser, eierskap og frihet under ansvar er derfor nødvendig for at vi skal lykkes med å skape nye ideer og nyttige resultater.

Frihet under ansvar

Selskapene som fanger interessen til dagens designere og utviklere, er de som har og gir stor frihetsfølelse. Det er også de selskapene som gir rom for egne perspektiver, der det er høyt under taket og lite byråkratisk ledelsesstruktur. Når man hele tiden blir fortalt hva man kan gjøre og hva man ikke kan gjøre, er det vanskelig å kunne være kreativ og bidra med sine beste ideer. Og, når man har fagkompetente mennesker som jobber for seg, er det snodig når en høyt oppe i systemet skal ta tekniske valg fordi de mener de har en god magefølelse. Å gi de ansatte større frihet til å velge selv, når de skal jobbe, hvordan og hvor de skal jobbe — om de vil delta på kontoret eller i møter — vil det mest sannsynlig resultere i lykkeligere ansatte. Det å stole på sine ansatte, og vite at de har kompetansen som trengs, er like viktig da de jo faktisk er profesjonelle på det de gjør. Der teamene har frihet under ansvar, kommer også lojalitet, produktivitet, fleksibilitet og effektivitet som et naturlig resultat.

Eierskap

At team tar eierskap for det man skaper, har sterk innvirkning på kvaliteten og arbeidsinnsatsen for sluttproduktet. For at teamet skal få følelsen av eierskap, må selskapene tørre å gi team og medlemmene ansvar. Ansvar betyr å gi teamet selvstendighet til å eie produktet ved å bestemme egne prosesser, metodikk, leveranser og teknologi. Med eierskap blir teamene mer selvdrevne og eksperter innenfor sitt domenet. Utviklerne og designerne kan fokusere på færre prosjekter, og de slipper å sjonglere mellom mange ulike domener, kontekster, prosesser og avhengigheter (møter, planlegging, standups) som ikke har noe med hverandre å gjøre. Eierskap gir mer trygghet, og dypere forståelse for det man jobber med, fordi man kan fokusere og bli ekspert på mindre deler av et prosjekt, domene, brukergruppe eller produkt.

Oppsummering: Frihet og eierskap

Jeg jobbet en gang i et team hvor en rekke utviklere og designere hadde fullt eierskap til flere løsninger innenfor et bestemt domene. Dersom en avhengighet utenfor domenet måtte løses, ble et annet team koblet på for å løse avhengigheten i det respektive domenet — fordi det var deres ansvarsområdet og ekspertområde. Jeg jobbet også i et annet team for ikke så lenge siden — der jeg kom helt fersk inn i domenet og selskapet –, hvor alle utviklerne kunne plukke utviklingsoppgaver fra mange ulike domener. Det var ikke så nøye hvem som gjorde hva, men oppgavene skulle løses. Utfordringen med å jobbe på denne måten, var at ingen fikk spesiell kompetanse på noen av domenene. Samtidig kunne du jobbe med enten SvelteJS, NextJS, NodeJS eller ren ReactJS, CSS, SCSS, CSS Modules eller StyledComponents. Personlig har jeg hatt en god opplevelse når det kommer til Frihet under ansvar. Men jeg tror at de teamene som har ansvar for få prosjekter, har lettere for å ta et større eierskap fordi de kan gå i dybden og konsentrere seg om færre ting. For mye eierskap kan gjør at man ikke kjenner godt nok til et domene. Dersom man er innom mange oppgaver og prosesser samtidig i ulike prosjekter, kan delegering av arbeid og ansvar fort føre til at man får mindre eierskap og oversikt for de enkelte prosjektene.

Individuell og kreativ tenking

Mange utviklingsteam jobber etter smidige prosesser som Scrum eller Lean. I smidige prosesser samles gjerne teamet en gang i blant for å snakke om ideer, progresjon, mål, oppgaver, ansvar og trivsel. Under samlingene, er målet som regel å arbeide og tenke som et lag. Men, det kan også handle om å finne roller og styrker i teamet eller meningen med hvorfor du og teamet eksisterer.

Retrospektiv

Retrospektiv er en ganske vanlig teknikk som benyttes i smidige prosesser. Teamet reflekterer sammen om hva som har fungert bra, og hva man kan forbedre i utviklingssyklusen. Dette er ofte kalt sprinter. En gang jobbet jeg med et team bestående av utviklere, designere, testere, devops, prosesseier og produkteier. Teamet var opptatt av å få med alle sine meninger, for det var viktig at alle ble hørt. Hver og en av oss tok en bunke post-it lapper og tusj. Vi fikk ti minutter til å skrive ned tanker og ideer i stillhet. En og en fra teamet fikk så henge opp sine post-it lapper på veggen og snakke om hva den handlet om foran de andre. På denne måten fikk alle formidle sine tanker og ideer som ble delt med resten av teamet. Til slutt hadde vi avstemning. Hvert teammedlem fikk tre røde prikker som kunne klistres på de lappene som man syntes burde diskuteres videre eller fortjente å være med videre til neste syklus.

Hvorfor?

Vet du meningen bak hvorfor akkurat du og teamet ditt eksisterer? Hvorfor dere skal løse de utfordringene dere er tildelt, og hvorfor du og dine egenskaper er viktig for å løse dem? Jeg husker godt da teamet mitt benyttet teknikker fra Simon Sinek’ bok og TED foredrag, Start with Why. Simon har laget en modell han kaller “The Golden Circle”, der han snakker om hvordan store ledere verden over inspirerer til innovasjon og definerer suksess; svaret er å starte med “Why”:

• ”hvorfor eksisterer vi som team i denne virksomheten?”
• “hvorfor er jeg i teamet og hva kan jeg bidra med?”
• “hvorfor er vi viktig for virksomheten, brukerne eller kundene?”
• “hvorfor eksisterer produktene våres?”
• “hvorfor skal kundene bruke produktene vi lager?”

Modellen fokuserer på hvorfor, fremfor hva og hvordan.

Oppsummering: Individuell og kreativ tenking

Selv tror jeg, at når enkeltmenneske kan reflektere og tenke individuelt, vil man få frem utrolig mange ulike ideer, meninger og følelser. Jeg tror også at det skapes flest ideer, og at de beste beslutningene blir tatt, når man får flest mulig perspektiver inn i diskusjonene, og hver person kan tenke for seg selv uten forstyrrelser. Det er viktig å finne ut hvem man selv er i teamet, og hvor man kan bidra med sine styrker. Simons Sinek’ modell, hjalp teamet mitt med å få et godt overblikk på hver enkeltes bidrag, ansvaret de hadde og hvorfor vi individuelt og teamet eksisterte. Retrospektiv er en veldig god aktivitet for alle mulige team, men jeg tror det er spesielt nyttig der teamene er tverrfalige. De ulike fagrettningene kan oppleve forskjellige utfordringer og kan dele de med resten av teamet. Mange teknikker i smidig utvikling handler om å prate og jobbe sammen som ett lag. Og det er jo fint det, men jeg har også opplevd når man jobber i workshops, at det er lett for at personene som har flest ideer eller de som snakker mest, ofte sitter med fasiten. Retrospektiv muliggjør for at alle kan tenke frem sine ideer og dele de med hele teamet. Fordi alle ideene, meningene og menneskene blir tatt seriøst, og er like viktige.