Denne uken har vi hatt en tradisjonell kvartalsvis «Get together»-økt i ett av prosjektene våre, der vi fokuserer på de viktigste målene i kundens prosjekt. Metodikken vi bruker er «Objectives and Key Results» (OKR). Inspirasjonen for denne tilnærmingen var selvsagt John Doerr – ingeniør, investor (f.eks. Google, Amazon), men også forfatter av verdensbestselleren «Measure What Matters». Boken, basert på mange eksempler, hovedsakelig fra IT-verdenen, beskriver en aggressiv og bevisst tilnærming til målsetting og å nå dem. Mer informasjon finner du hos kilden, for eksempel her.
Denne gangen er utfordringen ekstremt vanskelig fordi vi alltid har kunnet møtes fysisk, enten her i Ustroń eller på kundens hovedkontor i Oslo. Som et resultat kunne intensive arbeidsdager avsluttes med felles byvandringer om kveldene eller bare tid sammen, ikke nødvendigvis på kontoret og med arbeidstemaer. Coronaviruset er nådeløst for oss alle, så vi måtte legge mye energi i å forberede online-økter. To verktøy spilte en nøkkelrolle her – Zoom og Miro. Det første er sannsynligvis mest kjent, det andre kanskje ikke, men vi anbefaler begge! Men la oss komme til poenget.
Mens jeg forberedte meg på effektiv brainstorming og frisket opp prinsippene mine for å lage slike mål og nøkkelresultater for å gjøre dem så oppnåelige som mulig, fikk jeg inntrykk av at alle disse eksemplariske OKR-ene er veldig «søte». Søte er kanskje et dårlig ord... Jeg mener, de er som hentet fra idealiserte situasjoner eller er så perfekt avhengige av alle nivåer i organisasjonen at de faktisk passer som hånd i hanske. Men våre prosjekter med denne kunden er ikke så enkle. Det er sannsynligvis vårt 4. forsøk, og noe gikk alltid galt, så det var alltid en viss frustrasjon eller bare skuffelse over at vi ennå ikke kunne bruke systemet slik vi ønsket.
OKR-er er i utgangspunktet flotte og fungerer fantastisk hvis de virkelig gjenspeiler våre prioriteringer. Ikke de teoretiske prioriteringene vi gjerne skulle hatt (men noe vil alltid forhindre oss i å gjøre det), men de reelle. De viktigste kritikkene vi har kommet med så langt i retrospektive økter, var for eksempel at vi var for ambisiøse i tilnærmingen til et gitt mål, som raskt viste seg å være utenfor rekkevidde. I tillegg er vårt problem at vi ennå ikke klarer å reagere adekvat på plutselige endringer som kommer «ovenfra». De skjer overalt, men bare de som har implementert OKR-metodikken på best mulig måte, klarer å fortsette å bruke den i uforutsette situasjoner. Vi kan nå se veldig tydelig at teoretisk kunnskap i denne typen saker kan og er viktig, men å oppleve visse situasjoner på egen hud kan gi uendelig mye bedre resultater hvis man kan trekke konklusjoner og lære av feilene sine. Det er det vi prøver å gjøre. Hold fingrene krysset!
Noe som motiverer oss til å fortsette å utforske denne metodikken, er det faktum at vi blir bedre for hvert kvartal. Med det blotte øye (men også på grunnlag av målbare nøkkelresultater) ser vi at bagasjen av erfaring i kombinasjon med en frisk dose inspirasjon gjør at vi skaper bedre og bedre kvalitetsmål. Ambisiøse mål, men også oppnåelige så snart vi engasjerer energien vår og bruker ferdighetene våre, med fokus på realisering.
Nedenfor er noen eksempler på våre OKR-er – ikke endelige ennå, men som setter retningen vi ønsker å gå i prosjektene våre.
Objective: Reagere på feil før brukerne merker det ved å
- KR: Forbedre MTTR (Mean Time To Restore) til 1t
- KR: Oppnå SLA på 99,95 %
- KR: Fikse de 5 mest vanlige feilene basert på App Insights
Objective:Bygge et pålitelig ingeniørteam ved å
- KR: Redusere feilrate med 80 %
- KR: Forbedre Lead Time med 50 %
- KR: Levere 5 PoC-er av inspirerende løsninger til interessenter
Tusen takk for at du leste! Hvis du har forslag eller ønsker å diskutere et tema jeg har tatt opp i dette innlegget, vennligst kommenter innlegget på sosiale medier, så svarer jeg definitivt.
Oskar Pilch
@osk_are
