Nytt team – fra kaos til takt og rytme!

For å komme i gang, begynte vi med en kjapp brainstorming på noen hovedbehov for samhandling, ble enige om noen faste dager på kontoret, tidspunkt for en daglig standup og begynte med ukentlige retrospektiver. Vi brukte retro til å komme med behov og forslag når det kom til arbeidsprosess, testet tiltak og itererte sammen hyppig. Etter noen måneder merket vi oss mindre behov for endringer og hadde funnet en måte som funket for oss. Vi begynte med retro annenhver uke i stedet, og etter hvert holdt det med månedlige sesjoner. 

Inspirert av medlemmenes erfaringer med Scrum, Kanban og Radical Focus, men også prosjekter, kaostilstander eller fullstendig anarki, fant vi vår takt og rytme i hverdagen. 

Månedsfokus

Behovet for å se litt fremover, planlegge og samle noen løse tråder som ble plukket opp litt her og der, meldte seg raskt. Vi satte en strategisk gruppe som besto av produktleder, teamleder, UX lead og tech lead sammen månedlig for å snakke sammen og beslutte noen fokusområder for måneden. I starten produserte vi en liste med opptil 20 punkter som var viktig å tenke på, alt annet enn fokusert! Etter hvert klarte vi å spisse listen ned til rundt tre punkter.

Dette ble målene våre for måneden, og de var direkte koblet til vår visjon og strategiske mål, som et mellomledd ned til planlegging av aktiviteter i hverdagen. 

Mandagsplanlegging

Mandager satte vi av tiden frem til lunsj i alles kalendere, og kalte det mandagsplanlegging. Vi begynte denne sesjonen med å se på målbildet vårt for den neste måneden eller to, samt vår mer langsiktige visjon. Vi oppsummerte hva vi hadde fokusert på og oppnådd forrige uke, og satte fokusområder for inneværende uke på radaren til alle sammen, gjerne oppsummert i tre hovedaktiviteter for hele teamet knyttet opp mot gjeldende mål. Produkteieren vår var sentral i denne delen av planleggingssesjonen, og satte tydelig retning for teamet med innsikt, behov og oversikt. Likevel, produkteier er ikke alene om å holde i dette, og teamet deltok aktivt. 

Videre satte vi oss ofte sammen i grupperinger basert på ukens aktiviteter, for å planlegge de mer i detalj. Det kunne være at backend utviklerne trengte å planlegge en oppgradering de hadde fokus på, eller designerne en brukertest som skulle gjennomføres, eller en mer tverrfaglig gruppe som jobbet med en ny funksjonalitet. Her ble det innkalt til møter, avtalt arbeidstid, definert oppgaver og fordelt arbeid. Etter en felles lunsj kunne så en produktiv uke begynne. 

Vi prøvde å komme ut fra dette møtet med noen tydelige mål for uken, selv om man fort havner i aktivitetsfella. Vi kortet ned møtet ved behov, men forlenget det også hvis det var noe større som måtte planlegges. I denne sesjonen inviterte vi inn interessenter og støttespillere i arbeidet vårt, som kunne bidra inn eller burde høre på hva som ble planlagt, noe vi hadde god nytte av. For eksempel ble vår juridiske rådgiver gjerne med, og iblant våre eiere på fagsiden. 

Fredagsfeiring

Fredag kl 14 kom den selvskapte fredags-jinglen til teamet rungende fra en Mac sentralt i landskapet, møtebordet var dekket med godis og frukt, og vi gikk gjennom ukens seiere før vi tok velfortjent helg. Alle fikk her muligheten til å fortelle eller vise frem hva de hadde gjort og hvilke mål som ble oppnådd fra mandagens planlegging, og ingen slapp unna applausen fra teamet. 

Dette møtet rundet av uken på en god måte ved at alle hadde en følelse av å være oppdatert på andres arbeid og fremdrift, og ikke minst av å ha oppnådd noe og kommet videre mot målene. Dette var en sesjon hvor teamet var rause med hverandre, og vi inviterte gjerne inn samarbeidspartnere og ledere. Det kunne heller aldri bli nok boller og bakst på fredager. 

Standups

De andre dagene i uken hadde vi tjue minutter satt av til standup på morgningen, hvor vi holdt hverandre oppdatert på hva som foregikk, avtalte møtepunkter og spurte etter hjelp og støtte. I perioder hvor teamet var mye på hjemmekontor ga disse møtene et viktig treffpunkt i løpet av uken, mens i perioder hvor de fleste var på kontoret kunne møtene føles noe overflødige siden man hadde kontakt med hverandre kontinuerlig. Vi dro frem oppgavetavler, eller bare snakket sammen. 

Vi ville være effektive, hadde ikke fokus på at noe skulle rapporteres til hverandre, men åpnet opp for at alle skulle få si noe om hvordan det gikk i dag. Vi opplevde standups som et hyggelig møtepunkt først og fremst, noe som bygger teamfølelse og holder oss tett på hverandre og oppgavene vi jobber med. 

Demo

Flere på teamet hadde noe dårlige erfaringer med demo, det var en sesjon som iblant var blitt brukt mer som rapportering på fremdrift eller et sted å få negative tilbakemeldinger fra interessenter. Vi røsket litt tak i det, og ønsket å gjøre demo til en trygg og god arena for åpenhet, deling og engasjement. Vi hadde en workshop sammen, og satte noen regler for innhold og deltakelse.

Vi turte å vise frem våre halvferdige produkter, prototyper som så vidt hang sammen, konsepter, funn og kode, og viste med eksempel hva det vil si å være åpen for tilbakemelding og lære tidlig. Det ble også en god arena for produkteier å snappe opp hvem han burde snakke mer med og hvilke miljøer vi burde samarbeide tettere med. 

Vi inviterte åpent, men spisset oss mot de viktigste interessentene, og månedlig demo ble fort et høydepunkt! Folk på teamet viste fantastiske pedagogiske evner, fortalte og delte, og vi skapte en god heiagjeng rundt oss som ga gode innspill på det vi viste frem. 

Retro

Retrospektivene var som nevnt et viktig verktøy helt fra start, og det er viktig for team å sette av dedikert tid til evaluering og forbedringstiltak. Vi sørget for at alle fikk tid til å tenke litt selv aller først på hva som har vært bra i det siste, hva som ikke har fungert optimalt, og forslag eller ideer til forbedringer. Så tok vi en runde innom alle, så alle blir sett og hørt. Til slutt ble teamet sammen enige om noen tiltak som skulle settes i gang og evalueres til neste gang, med noen ansvarlige personer tilknyttet hvert tiltak på listen. 

Noe som også fungerte godt for dette teamet var å rullere på hvem som fasiliterte retro, noe som igjen skaper eierskap og autonomi. 

Oppgavetavle

Vi var et noenlunde selvstendig team, som styrte oppgaveflyten vår selv. Teamet var vant til å bruke Jira sine oppgavetavler, men hadde også ymse erfaringer og opplevelser med det. Noen syntes det var godt å alltid kunne knytte arbeidet sitt opp mot oppgaver i en tavle, andre så ikke helt behovet for sin egen del, men hadde måttet for å rapportere timer og fremdrift. Vi åpnet dermed for at teamet selv måtte finne ut av hvordan de ville bruke verktøyet for å få til et godt samarbeid, uten at det var noe behov for rapportering til andre enn dem selv. Jira ble testet, Git ble testet og ingen tavle i det hele tatt ble testet, og teamet fortsetter å bruke verktøyene de trenger etter behovene til medlemmene underveis. 

Poenget med verktøyene vi bruker er å støtte oss i prosessene vi ønsker å jobbe etter, ikke motsatt. Når teamet ble bedt om å følge en Scrum-prosess i Jira med alskens flotte funksjoner, skapte det mer frustrasjon enn nytte fordi man måtte endre seg for å passe inn i Jira-oppsettet. Da skal grunnene være gode for det, for eksempel fordi man samarbeider veldig tett med mange andre team og trenger én måte å gjøre det på, eller fordi man ser andre verdier av det. 

Hva kan du gjøre?

Dette er én måte å jobbe på, som ikke nødvendigvis bør implementeres i ditt team, men som kanskje kan fungere som inspirasjon? 

Poenget med å samskape og teste seg frem til en arbeidsmetode som fungerer for et team, er at eierskapet og ansvaret er og blir i teamet. Om noe ikke fungerer optimalt, må man ta tak i det selv og foreslå løsninger. Dette vil føre til mer trivsel og mer selvgående team som ikke nødvendigvis trenger ledelse eller fasilitering.