Jeg er med i et produktutviklingsteam i Oslo Origo som fungerer bra, og som har fungert ganske bra over lang tid.
Nå har jeg grublet på spørsmålet: Hvorfor er det slik?
I dette innlegget skriver jeg om de faktorene som jeg tror bidrar til at teamet fungerer. Jeg skal ikke påstå at dette også vil fungere for andre, men det er noen faktorer som kan være universelle for alle som jobber i et produktutviklingsteam.
Noe har oppstått litt tilfeldig, mens andre ting har vi jobbet bevisst med for å få til.
#1. Et tydelig og viktig oppdrag
Oppdraget er det som får oss opp om morgenen. Viktigheten av et oppdrag er til syvende og sist subjektivt, men alle team-medlemmer må se viktigheten av det.
Et viktig oppdrag bidrar til vi har noe felles å arbeide mot. Hvis ett teammedlem ikke er opptatt av oppdraget er det en faktor som kan gjøre teamet dysfunksjonelt.
Thereses 10 beste tips for å kapre en utvikler: - Lønn er viktig
#2. Ansvarlighet
Blandingen av et viktig oppdrag og ansvarlighet er sterk.
Vi i teamet har et kollektivt ansvar for hvor godt oppdraget løses etter hvert som tiden går. Vi må levere verdi mens vi går! Vi kjenner på at her må vi prestere bra!
Hvis ikke det er en god driver, så vet ikke jeg.
#3. Alle gjør litt av alt
I vårt team har vi særdeles lite fokus på roller. Om du er utvikler, UX-designer eller organisasjonsutvikler spiller liten rolle.
I det ukentlige planleggingsmøtet dukker det ofte opp svært mange rare oppgaver som absolutt ikke treffer en bestemt rolle. Så hvem gjør det da?
Dette handler om interesse, men også det å ta en for laget. Av og til dukker det opp oppgaver vi må gjøre som er dørgende kjedelige å utføre.
Men det finnes unntak: Oppgaver som handler om koding. Det er vanskeligere for en UX-designer å programmere en liten del av en applikasjon enn det er for en utvikler å lage en prototype i et prototypeverktøy. Men det er ikke noe i veien for at UX-designeren får utviklingsmiljøet opp på sin maskin, og dermed kan prøve å endre koden (eller direkte i Github)!
«Dette handler om interesse, men også det å ta en for laget.»
Heldigvis har vi utviklere på teamet som forstår dette, og utviklere som gjerne kjører det intervjuet eller deltar i brukertesten!
En annen styrke ved å ha denne innstillingen er at det gjør ikke så mye om Kari blir koronasjuk og er borte noen dager. Noen andre står parat til å ta hennes oppgaver.
Teamet skal jo få produktet til å funke og skape verdi, så legg til side titlene og gjør det dere må gjøre for å komme i mål! Fokus på det dere kan og ikke titler.
#4. Alle er til enhver tid oppdatert på «teigen»
Hvis du gjør som oss, og jobber i Oslo kommune, vet du at en mer komplisert arbeidsplass skal du lete lenge etter.
I slutten av hver uke har vi et eget såkalt innsiktsmøte der ett av temaene er «hva slags ny informasjon har jeg fått denne uka som dere burde vite?» Dette er et spørsmål som hvert teammedlem skal spørre seg og svare på i møtet.
Fordelen med å spare dette til slutten av uka (i stedet for å hive det ut på Slack med en gang) er at vi får mer ro til å fokusere på oppgavene vi har tatt eller fått tildelt.
Dette betyr at på fredag ettermiddag, så har alle i teamet en god forståelse av «hvordan teigen ser ut», og alle vil være i bedre stand til å planlegge og ta gode avgjørelser.
#5. Designprosessen er i førersetet
Alle teammedlemmer forstår designprosessen og hvorfor den er så viktig for produktutvikling. Alle forstår at hvis du følger denne prosessen, så vil du skape verdi (så lenge du har valgt et problem som er verdt å løse vel å merke).
En slags motsetning til det å jobbe drevet av designprosessen er å jobbe med det vi har lyst til å jobbe med. Jobber du med det du har lyst til å jobbe med skaper du kanskje verdi for deg selv, men ikke nødvendigvis for sluttbrukeren.
Sånn sett setter designprosessen føringer for hvilke oppgaver det til enhver tid vil være flest av! Det er klart at i en periode som krever mye innhenting av innsikt så vil det være færre koderelaterte oppgaver. Da er det viktig å ha et prinsipp om at alle gjør litt av alt (punkt 3). I verste fall blir noen team-medlemmer sittende å tvinne tommeltotter i påvente av oppgaver som passer dem bedre.
Potet: - Hva betyr det egentlig å være fullstack-utvikler?
#6. OKR-er med fokus på å gjøre livet litt bedre for innbyggere eller ansatte
Å ha brukeren i fokus er i dag så selvsagt som å drikke vann. Det du gjør i det daglige må være fokusert mot å gjøre ting litt bedre for sluttbrukeren (med de midlene du har eller kan få). Det gjelder også Oslo kommune selv om konkurransesituasjonen for en kommune er annerledes enn i det private.
I Origo bruker vi OKR som målstyringsverktøy (i denne artikkelen skriver jeg om hva OKR er). Teamet har nå kommet på et nokså høyt nivå når det gjelder setting av OKR-er for en periode. Målene våre er som oftest skrevet på en slik måte at vi sier noe om økt kvalitet for innbyggeren eller ansatte.
Vi har også blitt kreative når det gjelder å lage gode nøkkelresultater for målene vi setter. Disse er nesten alltid fokusert på utfall fremfor aktiviteter.
Kombiner OKR med punkt 5 (designprosessen i førersetet), så blir det veldig kraftfullt!
#7. Psykologisk trygghet
Psykologisk trygghet kan defineres som at du kan være deg selv og si hva du mener uten å være redd for represalier eller andre negative reaksjoner fra andre. Det er noe «alle» snakker om, men ikke noe nytt.
Psykologisk trygghet er en forutsetning for at hvilken som helst gruppe med nære bånd skal fungere godt, enten det er snakk om et team, en familie eller vennegjeng.
I tillegg til dette må hver enkelt være noen lunde stabile. Med det mener jeg at det kan være vanskelig å oppnå god psykologisk trygghet i teamet hvis ett eller flere team-medlemmer har sterkt overslag i den ene eller andre retningen. Eksempler på sterke overslag kan være et teammedlem som kun snakker, men aldri lytter, eller et som alltid sier ting rett ut som hen oppfatter ting (noe som fort kan lede til at noen blir såret), eller noen som er mest opptatt av å tulle og fjase.
