Hvor mange punkt, sa du? «Ølløv» er gudbrandsdøl for elleve, for den som lurte, som undertegnede.
Dataingeniøren fra Gudbrandsdalen har lang erfaring som utvikler, blant annet i NAV og SSB før han i 2021 gikk inn i rollen som Principal Cloud Developer og CTO i Capgemini.
Gjennom karrieren har Kvernstuen sett hvordan IT-bransjen har gjennomgått store endringer, og oppfordrer utviklere til å gripe mulighetene man har til å påvirke.
- Dersom man overlater områder som kultur eller rammebetingelser til ledelsen vil både den enkelte utvikler og organisasjonen som helhet tape, mener han.
For å jobbe som utvikler er mer enn å “bare” skrive kode.
- Utviklere bør aktivt engasjere seg for å forbedre utvikleropplevelsen, optimalisere organisasjonen, dele kompetanse og trekke brukerne nærmere det vi lager. Hvis utviklere trekker lasset sammen og vi lykkes med dette, er jeg overbevist om at både trivsel og produktivitet vil øke.
Den erfarne utvikleren og lederen har satt opp «ølløv» punkter for å utvikle bedre, utover å kode:
- Det er lov å feile. Det snakkes mye om psykologisk trygghet om dagen, og det er bra - for det er viktig! Du skal føle deg trygg på at teamet ditt står ved din side om du feiler, og at du anerkjennes når du lykkes. Ingen spørsmål er for dumme, og du er verdsatt for nettopp den du er.
- Tør å si ifra. Der den psykologiske tryggheten er tilstede kan man innføre enkle og ærlige prosesser for å vokse raskt på tilbakemeldinger. Dett fordrer at man er like god på å gi konstruktive tilbakemeldinger som man er til å ta i mot dem og bruke dem systematisk til egen forbedring.
- Rett kompetanse i teamet. Samla sett bør teamet være kompetent nok til å løse oppgavene. Litt for ofte ser man at team må ut og hente inn kompetanse de trenger. Det å koordinere kompetanse tar mye tid og energi, både i organisasjonen og hos den enkelte. Flinke folk strekkes tynt. Hvis man må være 20 % her, 20 % der og litt overalt ellers så blir det slitsomt. Nøkkelen er god planlegging.
- Myndighet til å løse oppgavene. Ende til ende. Når flere team skal levere en gitt brukerverdi sammen så krever det tid og koordinering. Ofte henger ikke brukeropplevelsen godt nok sammen heller, og man bruker sannsynligvis lengre tid til produksjon. La dyktige team få et ende-til-ende-ansvar over problemene de skal løse – da sparer man tid og lager bedre tjenester.
- Avgrens og avklar. Hva er teamets problemstillinger, og hva er noen andres? Avgrens teamenes domener og vær tydelige i hvordan man bruker språk og begreper innad i dem. Store fellestjenester som skal gjøre mye på vegne av mange blir ofte flaskehalser i stedet for å oppnå de storbruksfordelene man først forespeilet seg. Dette er egentlig prinsipper fra domenedrevet design – bare at vi tenker på folk og team i tillegg til programvare.
- Unngå “hjemme-alene-fest”. Man må ha rammer. Når man har en haug med godt fungerende team som jobber selvstendig og ende-til-ende kan det fort skli ut til en “hjemme alene”-fest der alle raver rundt og gjør sin egen greie dersom man ikke har rammer. Gode rammer som setter retning, samtidig som de ikke begrenser teamets mulighet til å finne løsninger. Ja, det er en vanskelig balanse, men det er viktig. Eksempler kan være virksomhetens evne til å standardisere, eller arkitekturprinsipper man jobber etter. Tydelige rammer som alle forholder seg til. I tillegg er det viktig at de rammene har rom for eksperimentering og nytenkning. Ha en tech-radar, der man følger med på feltet og noen tester og prøver for å finne ut hvor relevant ny teknologi eller nye verktøy er for dere. Slik får man prøvd seg fram uten at alle trenger å hoppe samtidig inn i ukjent farvann.
- Fra bestilling til selvbetjening. Opp gjennom årene har jeg sittet i mange team der vi har måttet bestille helt essensielle ting fra andre, som servere, databaser, skriptkjøringer etc. Ofte bestilles slikt i et klassisk ticketing-system der noen overivrige prosesshoder har brukt litt for mye tid på å designe en prosess helt fri for tillitt og med godkjenningsledd som forsinker. Det er like kjedelig å sitte i bestiller-enden av en slik prosess, som det er å ta imot dem. Dessuten blir det gjerne en hviskelek. Har du nylig gått i sky eller planlegger en skyreise, er dette et ideelt tidspunkt for å tilrettelegge for selvbetjening, gjerne med Infrastructure-as-code som metode for å sette teamene i stand til å provisjonere infrastrukturen de trenger selv. Dette handler både om tillitskultur og teknologi, og det tar tid. La 2024 være året der det skjer!
- Høst læring fra andre team. Med solide autonome, tverrfaglige team som har gode rammer så trenger de læringsarenaer for å dele erfaringer og kompetanse. Min erfaring er at utviklere er mest effektive når de kan lære daglig. Hverdagslæring er viktig og bør ha lav terskel, spørre og dele på Slack, Discord - tør jeg si Teams? I tillegg bør man ha arenaer der man setter av tid - ukentlige demoer eller månedlige fagdager for eksempel. Det viktige er at man finner arenaer som fungerer hos den enkelte virksomhet.
- Skap kultur for samarbeid. Parprogrammering har lært meg enormt mye de siste årene, selv om det kan være vanskelig i starten. For meg har det i hvert fall vært en terskel å komme over å la andre se meg programmere - jeg føler jeg er så utrolig treig når jeg skriver kode. Men selv om det stresset meg litt i starten har jeg blitt vant til det - og fordelene er så store. At vi kan prate oss gjennom problemstillingene mens de oppstår gir bedre løsninger. Peer-reviews er også en god løsning for mange, så lenge det gjøres på en bra måte. Å sende 1000 linjer kode til en kollega som legger inn noen halvhjerta kommentarer er ikke en god måte … Og ikke glem dine nye kollegaer: Copilot, Bard, AI Assistant og andre – jeg er lamslått av hva de kan hjelpe meg med og det vi nå får til sammen.
- Kort vei til prod. Koden min blir ikke verdifull før den brukes. Mange virksomheter har lang vei ut i produksjon, og dette er ofte et kulturproblem der man ikke stoler helt på utviklerne. At kode skal gjennom testmiljø en, testmiljø to, en tredje manuell tester og masse ventetid mellom hver stasjon - det tar tid. Og er ikke nødvendig dersom man har gode kvalitetsprosesser, som for eksempel parprogrammering, automatiske tester og statisk kodeanalyse i bygg- og deploy-prosessene.
- – eller ølløv: Vi trenger gode ledere. Vi trenger ledere som er gode til å veilede, ikke sjefe. Ledere som skaper mulighetsrom, motiverer, fjerner stein i skoen og inspirerer til selvledelse. Så er det dessverre ikke så mange av den typen ledere i dag - men det kan vi endre.
God kode er et lederansvar
- Å skape bedre rammebetingelser og kultur krever at alle bidrar, fortsetter Kvernstuen. Utviklere kan begynne med å spørre seg selv: Hvordan kan jeg konkret bidra til bedre samarbeid i mitt eget team? Prøve parprogrammering? Ta initiativ til å avgrense domener og forbedre prosessene? Men det stopper ikke der. - Jeg mener at ambisiøse ledere må ta ansvar for bygge et skikkelig godt IT-miljø. Dette kan ikke delegeres til mellomledere eller en teknologidirektør. Alle ledere må være seg dette bevisst, for idag er alle virksomheter teknologibedrifter.
- Virksomhetens egen IT-kompetanse bør styrkes i møte med konsulentmarkedet, for det handler ikke om konkurranse, men om kultur og rammebetingelser for å levere mest mulig verdi. Det gjør vi best sammen.