Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 2/3)

Noe av det vanskeligste med å bygge produkter er det konstante spørsmålet: Gjør vi de riktige tingene nå, eller burde vi skifte fokus? Denne artikkelen er del 2 av en 3-partsserie der vi deler våre erfaringer med å gi teamet fullt eierskap til hva vi skal prioritere.

Del 1: Hvorfor hypotese-basert utvikling (start her)
Del 2: Organisering av små teams i stor organisasjon (du er her)
Del 3: Erfaringer på hypotesearbeidet og måling av suksess

Organisering av små teams i stor organisasjon

Jeff Bezzos sa en eller annen gang, ganske omformulert “Ikke ha et team større enn at det holder med to pizzaer til lunsj”.

Team Nettsider som jeg er en del av er et relativt stort team, men med tanke på våre ansvarsområder og oppgaver er mengden folk riktig. Siden OKR ikke er alt vi gjør, men noe av det viktigste vi gjør, var det letteste å fordele totalansvaret på en mindre enhet innenfor teamet.

Et mantra internt er at vi konstant skal bli bedre. Med det hører det med mye testing av oppsett, teams, verktøy og lignende for å skape kontinuerlig forbedring over tid. Hvis teamet derfor ønsker å teste ut en subgruppering, fordi vi tror dette er smart, så er vi helt autonome til å gjøre det.

Når det er sagt så er det en ting å være autonom til å gjøre noe, men man må også ha støtten fra teamet og internt generelt for å kjøre en ny satsning.

Hvordan skape en intern enighet av hypotese-satsningen?

Før man leser om hvordan vi satt opp hypoteseteamet, kan det være nyttig å skjønne hvor vi kommer fra.

For noen år siden stod vi med noen ganske store problem:

• Backloggen hadde 250+ issues
• Teamet jobbet med mye individuelle tiltak som ikke hadde sammenheng med hverandre
• Samarbeidet mellom utvikling/design og redaktørene var ikke godt nok
• OKR jobbingen var bare et ekstra lag over alt det andre vi gjorde
• Vi hadde ikke gode nok mål som ga mening å jobbe mot

Teamet hadde det rett og slett ikke gøy, og det var en klar mangel på mål og mening i det vi gjorde.

For å løse dette jobbet vi intenst i over 1 års for å forbedre dette. Det viktigste vi gjorde var:

• Strategi: Vi lagde en ny strategi som skulle operere som roten i alt vi skulle prioritere. Den har bare 12 slides med 4 prioriterte strategier. Ambisiøs nok for å jobbe mot i flere år, men enkel nok til å summere opp i én setning.
• 👆🏼 Lærdom: En strategi må gjentas til det kjedsommelige. Når du begynner å bli lei å snakke om den, begynner andre å legge merke til den.
• Grooming: Vår testleder tok ansvaret for å være grooming ansvarlig på våre backlog møter. Hver uke hadde vi 1 time der hele utviklingsteamet gikk gjennom alle issuene vi rakk. Disse møtene var brutale i starten, men alt ble målt opp mot: gjør dette issuet at vi kommer nærmere målene til strategien? Hvis ikke arkiverte vi det.
• 👆🏼 Lærdom: Alle diskusjoner blir lettere hvis vi alle husker på hvorfor vi gjør det vi gjør. Dette ville skape en bedre hverdag for alle.
• 👆🏼 Lærdom: Spre ansvaret. Det høres klisje ut, men du jobber med folk som er smartere enn deg. Den beste energien er hvis noen melder seg frivillig til å løse problem som sitter de nært.
• Nei til 90% av nye tiltak: Uten overdrivelse sa vi nei til rundt 90% av alle nye tiltak som kom inn, fordi de ikke hadde tilknytningen til det vi prøvde å oppnå. For å gjøre det enklest for alle satt vi opp et “regime” der nye ting måtte gjennom meg som produkteier. Dette var overraskende udramatisk, siden innsenderne som regel hadde forståelse for at vi måtte prioritere mot strategien.
• 👆🏼 Lærdom: Folk vil at ting skal skje. Hvis det ikke virker som vi gjør noe så kommer man til å få inn forslag på tiltak. Hvis man klarer å vise at man jobber med mye bra, er de fleste fornøyd med det.

Med det vi gjorde over fikset vi mye, men det var fortsatt to ting som var uløst:

• Samarbeidet mellom utvikling/design og redaktørene var ikke godt nok
• OKR jobbingen var bare et ekstra lag over alt det andre vi gjorde

Når vi snakker om at samarbeidet mellom utvikling/design og redaktørene var det rett og slett en mangel på system der man hadde avsatt tid og klare mål som gjorde det logisk å samarbeide.

Vi er i en unik posisjon der nesten alle redaktørene er utleid fra bankene i alliansen. Klarer man å opprette et godt samarbeid, skaper man også et direkte kontinuerlig samarbeid med bankene. Dette er viktig, fordi SpareBank 1 Utvikling jobber for å skape gode løsninger for bankene og brukerne deres.

Så, for å løse samarbeidet og OKR jobbingen, gjorde vi rett og slett en evangeliserings-runde både for teamet og bredt internt der vi skapte klarhet rundt:

• Vi har nå klart å skape fokus for teamet med å ha mindre, men bedre oppgaver prioritert opp mot strategien. Med andre ord en tydelig rød tråd fra det som skjer i det daglige arbeidet til det vi ønsker å oppnå
• Vi vet at utvikling/design og redaktørene har lyst til å samarbeide, og dette samarbeidet vil gjøre nettsidene mye bedre som et resultat
• Vi har lært at OKR ikke er noe vi bare kan ha på siden. Det er noe som krever prioritert fokus over tid
• Vi ønsker å gå fra individuelle tiltak til kontinuerlig forbedring. For å få til dette burde vi teste ut å lage et hypoteseteam (les del 1 på hvorfor vi valgte hypoteser)

Når dette var gjort var det egentlig bare å kjøre i gang og ikke minst: tørre å stå i det over tid.

Your people should own outcomes, not just tasks. […] We need a team of missionaries, not a team of mercenaries. — Fra boken Empowered

Hvordan velge ut folkene til hypoteseteamet?

Noe av det viktigste med å få en gruppe til å jobbe bra sammen, er at det er en psykologisk trygghet for å samarbeide mot et felles mål. En ting som gjør dette lettere er å skape et lite, men fokusert team som jobber sammen over tid.

Ansvarsområdet i teamet er som nevnt bredere enn det vi prøver å oppnå med hypotesearbeidet og OKR’ene. Derfor ble noen valgt ut for å være med i hypoteseteamet, mens andre blir trukket inn ved behov.

Det er en fin linje mellom å ikke eksludere mennesker, men være fokusert nok til å kunne skape disse små gruppene. Ved å rotere på noen av personene i hypoteseteamet over tid, vil man (forhåpentligvis) vokse kulturen innad over hele teamet.

På den andre siden må man ikke rotere på alt for mange personer av gangen. Den psykologiske tryggheten, team-følelsen og hastigheten i arbeidet er ikke noe som kommer av seg selv.

Alle sirklere er hele Team Nettsider (redaktører, utviklere, designere, systemforvalte etc). De blå sirklene er hypoteseteamet.

Dagens hypoteseteam består av UX og design (som har mest erfaring med hypoteser og leder hypotesemøtene hver mandag), redaktører, utviklere og produkteier. Akkurat liten nok gruppe til å jobbe effektivt, men stor nok til at vi kan gå fra idé til produksjon på det meste vi ønsker.

Basert på OKR’en som er satt, er det egentlig helt opp til hypoteseteamet å velge hva man skal fokusere på. Dette gir større eierskapet til produktet, samt at man forhåpentligvis får til det som skaper gode sportsteam: man vinner og taper sammen — som ett team.

Eller, som boken Empowered skriver mye mer elegant: “Creating empowered product teams involves giving product teams ownership of a problem to solve, so that they have the ability to solve problems the best way they see fit”

I del 3 av 3 skriver jeg om erfaringer på hypotesearbeidet og måling av suksess, både med løsningene vi lager men også helsen til teamet.

Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 3/3)