SpareBank 1 Utvikling

Dette er SpareBank 1 Utvikling, og på denne siden kan du bli bedre kjent med hvem vi er, hva vi gjør og hvordan vi jobber – gjennom oss som faktisk jobber her. Så kan du vurdere selv om du også har lyst til å bli en del av det vi mener er det beste og triveligste IT-miljøet i bransjen. Med de flinkeste folka.

Vi skaper en enklere og bedre hverdagsøkonomi

Vi utvikler og forvalter løsninger som brukes av over 1 million kunder. Det er vi skikkelig stolte av! Her kan du bli enda bedre kjent med selskapet, måten vi jobber på, løsningene vi lager, og ikke minst - ukas aller beste dag: Fagdagen.

Miljøbilde fra SpareBank 1

SpareBank 1 Utvikling på Medium @sparebank1-digital

Hvordan vi fikk høyere fart med hyppige prodsettinger og parprogrammering

I november 2021 hadde vi besøk av Terje Heen og Julian Ravn Thrap-Meyer fra NAV. De fortalte hvordan de prodsatte mange ganger om dagen. De brukte ikke annet testmiljø enn produksjon, de parprogrammerte alt, hadde sluttet med Pull Requests samtidig som de opplevde økt kvalitet. Wow.Jeg jobber som utvikler i “Område Hverdagsøkonomi” hos SpareBank 1 Utvikling. Vi har stort fokus på modernisering av plattformen, og de siste årene har vi kunnet prodsette oftere og oftere, gjerne flere ganger i uka. Pull Requests er en sentral del av utviklingsprosessen. Akkurat som hos mange andre selskap.Vi ble inspirert av NAV og ønsket å teste ut mer parprogrammering og hyppigere prodsettinger. Og vi hadde én oppgave foran oss som var perfekt for å akkurat dette.Kjenner du deg igjen?La oss ta et steg tilbake. Dette er ofte den klassiske måten man jobber med utvikling av et API:Du jobber alene på en oppgave i branch som bare vokserMye manuell testing av HTTP-kall i ulike testmiljøerÉn egen testansvarlig. Du får en rapport på hva som er galt og fikser feilene.Underveis ber du teamet om å ikke endre så mye på samme kodebase før man selv har merget til master, det blir så vanskelig å merge. Man blir mer og mer stressa for å bli “ferdig”.Du sparer automatisk testing til slutt, og skriver bare tester på en brøkdel-som du også påstår er “den viktige delen”.Pull Requesten inneholder mye diskusjoner og meninger, gjerne på smådetaljer som syntaks. Men lite om helheten, og den kan bare du.Du er nervøs ved prodsetting. Endringen er med i en release. Denne er full av andre endringer også. Feilsøking blir vanskeligere.Det feiler på flere ting ved prodsetting, du har ikke kontroll på hva og det er krise i teamet. Du har høyest puls, det er jo “din” kode.I fremtiden kommer alle til deg hver gang det skjer noe i denne delen av koden.Så er oppgaven din ferdig, koden er i prod og det fungerer. Du og teamet ditt blir hyllet fra nært og fjernt. Men i notepad har du en lang liste over ting som må forbedres.Men nå vil produkteieren videre. “Det funker jo, kundene er fornøyd”, sier han. Er ikke det det viktigste? Du får høre at “forvaltning vil vi alltid ha, og det må prioriteres mot andre viktige ting”. Vi kan gjøre det senere.Du taper diskusjonen. Resultatet er splitter ny teknisk gjeld. Hvordan kunne dette vært unngått?Hva må til for å kunne drive med hyppige prodsettinger?For å jobbe med hyppige prodsettinger, kan du ikke bare ha effektiv teknologi og prosesser i teamene. Du må også ha en leder som skjønner hva som skal til. En som har forstått at utviklere ikke er datamaskiner. Og at koden ikke er ferdig selv om funksjonaliteten tilsynelatende er det.For å utvikle med høy fart og hyppige prodsettinger nytter det ikke bare å være dyktig ninja-utvikler.En sentral del er at du ikke er redd for å endre og prodsette. Og skal man endre uten å være redd, bør man ha visse mekanismer på plass:Kunne utvikle slik at du kan prodsette små endringer om gangen.Mulighet for parprogrammering.Holde god testdekning.Raske bygg på byggserver, gode tilbakemeldinger på feil.Enkelt å prodsette og rulle tilbake.Bruk av feature toggling og gjerne soft release (canary deploys).God logging, monitorering og alarmerDet finnes mer avanserte deploy-strategier, og flere selskap i Norge har kommet mye lenger enn oss. Men vi kan vi sjekke av mesteparten her, og det holdt for å teste ut hyppige prodsettinger.Utprøving av hyppige prodsettinger med parprogrammering i oppgaven “Endre kategori”Transaksjoner i SpareBank 1 får i dag satt kategorier på transaksjoner basert på data fra vår maskinlæring. F.eks. at en transaksjon fra Spotify får kategorien “strømmetjeneste” under “ferie og fritid”. Dette bruker vi til å gi deg en fin inndeling av hva du bruker penger på.I enkelte tilfeller klarer ikke maskinlæringsmodellen å finne kategori, eller så den feil. Vi ønsket at kunden selv skulle kunne endre kategori. Slik ville også maskinlæringsmodellen bli trent og funksjonaliteten bli bedre for kunder alle i fremtiden.Dette skulle vi utvikle. Her har maksinlærignsmodellen ikke fanget opp at Adam og Eva er frisør, og kunden skal kunne endre selvOppgaven inneholdt masse utvikler-snacks:Mikrotjeneste for behandling av kategorier sammen med transaksjonerPersistering og cachingKall på kryss og tvers av interne tjenester, bruk av maskinlæringAlgoritmerFrontend-utvikling og designKodespråk: Kotlin og ReactHvordan la til rette for hyppige prodsettinger og parprogrammeringGeir Olav og Bård Kristian parprogrammerer på et privat, dyrt nerdetastaturParprogrammering, gjerne med innblanding fra andre. Fysisk eller over Teams/Slack.Delte opp funksjonaliteten i mindre deler. Og delte den så opp enda mer. Hver enkelt del ble prodsatt fortløpende, også deler som ikke var i bruk enda.Endringer styres via “Feature toggles” på f.eks. fødselsnummer. Vi prodsatte fortløpende, men bare for oss selv på teamet. Ble utvidet til flere brukere ved behov.Utviklet REST-endepunkter tidlig, men stubbet APIer, database o.l. som også ble brukt i produksjon. Slik kunne vi teste helt spesifikke deler av koden, i produksjon, uten at vi gik ut med for mye samtidig.Litt kode om gangen, men alltid med kjærlighet og automatiske tester.Ingen egne testere, vi testutvikler og tester selv konitnuerligVi startet midt inni kodebasenDet klassiske ville vært å starte med databasen. Lage det persistente laget, serviceklasser og endepunkter. Og så implementert endringer i andre APIer vi er avhengige av, og til slutt sydd det hele sammen og testet alt på en gang.Men vi valgte å snu på dette.Vi startet med å utvikle koden som modifiserer transaksjonskategorien, en liten del langt inni kodebasen. Vi erstattet baksystemer med stubs, til og med selve APIet som skulle lagre kategori-endringen. Og så prodsatte vi det, men bare for min bruker.if( socialSecurityNumber.equals(“Asgauts fødseldsnummer”)) { // Kall til den nye koden} else { // Kall til gammel kode}På denne måten fikk vi testet noe av kjernen av forretningslogikken umiddelbart og lærte fortløpende hva vi videre måtte implementere i andre tjenester.Samtidig fikk vi endret kategori på en transaksjon i produksjon og fikk en visuell opplevelse. Og feedback-loopen på endringer var lynrask.Vår første del av koden så noe sånn ut. Vi laget en ny klassse som modifiserte på transaksjonkategorier feature togglet og stubbet baksystemerFørste endring i produksjon hvor vi bare endret kategori på én transaksjon, men kun for min bruker, med stubbede data fra baksystemDet smalt i produksjon med en gangSelv med denne bittelille endringen smalt det i produksjon. Vi fikk meldinger om rar oppførsel på eksisterende sortering av transaksjoner. Altså på en del av koden vi rørte, men vi ikke trodde skulle feile. Dette var enkelt å oppdage, fikse og prodsette — fordi endringen vår hadde vært såpass liten og avgrenset.Dette ble også betydelig enklere når vi hadde parprogrammert og begge hadde full kjennskap til endringen.Ved å teste i produksjon fikk vi altså ikke bare testet vår endring isolert. Vi fikk også testet hvordan koden vår oppførte seg sammen med resten av produksjonsmiljøet.Vi parprogrammerte på alle endringerVi jobbet på oppgaven i ca. en måned og endte totalt opp med over 50 prodsettinger før det var live for alle kundene våre.Utvalg av commits som ble merget og prodsatt, alt parprogrammertMens vi jobbet ble vi stadig bedre på at hver fiks, små refaktoreringer, integrasjoner mot andre system, oppdatering av tester osv. ble til egne commits som vi merget og vi prodsatte, sammen. Her nærmer vi oss “ekte” Continious Integration slik det orginalt ble beskrevet av Kent Beck.Legg merke til deploy8 i gult. Det ble mer naturlig å rydde teknisk gjeld underveis da vi ikke var midt inne i en kjempestor branchLokalt og så rett i prod?Vi opplever nå en endring i måten vi jobber på. Og metoden har oppstått uten av vi aktivt har forsøkt å endre oss:Vi har så lite kode som går ut om gangen, med så gode tester, at behovet for å teste i test-miljøer reduseres. Og ikke nok med det, vi starter faktisk nesten aldri opp appen lokalt, ettersom vi får så bra svar gjennom gode automatiske tester.Vanlig prosess har blitt: Tester kjører lokalt →merger til master → bygg og test OK på CI Server →ruller ut i prodVi koder med hvilepuls. Vi stoler på tester, stoler på den gode gjennomgangen vi får med parprogrammering, stoler på alarmer. Så lenge byggserver sier OK så går det bare rett ut i produksjon, samtidig som vi opplever mindre og mindre feil.Vi opplever veldig lite av “jeg har bare igjen å skrive tester”. Det er allerede gjort som en del av utviklingen fortløpende og holder nede teknisk gjeld.Dette øker farten betraktelig og vi har kontroll.Nå forstår vi hvorfor NAV kunne ta bort Pull RequestsDa vi parprogrammerte, ble all koden diskutert og reviewet fortløpende til minste detalj. Det Pull Requesten derimot ble brukt til, var infodeling til de andre og et verktøy for diff på koden for oss selv.Tiden Pull Requesten lå før den ble merget ble betraktelig redusert. Det ble mer en teknisk formalitet for compliance vi måtte gjennom for å få koden til master. Vi markerte Pull Requester som vist under, merget umiddelbart når bygg ble grønt, og så kunne resten av teamet se på diff om m vil.Opplysning til teamet at vi har samarbeidet, og at vi derfor godkjente Pull Request og merget uten å vente på andreSkulle hele teamet godkjent alle Pull Requests hadde, farten gått betraktelig ned. Vi hadde også måte avbryte det andre teammedlemmer jobbet med.Slik beholder vi fart og flyt i teamet. Kunnskapsdelingen skjer hovedsakelig gjennom parprogrammering og rotering på hvem som jobber sammen.LangtidseffektenVi hører ofte at man må kode på hver sin oppgave for å bli fort ferdig. I SpareBank 1 Utvikling jobber mange team med Radical Focus metodikken. Da jobber teamet i ukessykluser hvor man mandag “commiter seg” til å bli ferdig med noe til fredag.Men det store produktet Sparebank 1 Digitalbank blir aldri ferdig. Vi er ca. 160 utviklere som endrer på kodebasen hver dag. Vi bør tenke langsiktig og på helheten.1% forbedring hver dag gjør deg 37 ganger bedre på et årJames Clear forklarer i boken “Atomic Habits” at en forbedring på 1% om dagen, vil gjøre at du får en forbedring på hele 37 ganger over et helt år.Med hyppige prodsettinger og parprogrammering får man forbedringseffekten til Clear inn i software utvikling:Små endringer gjør at man enklere kan endre retning og jobbe mer innovativt.Kompetanseheving. Diskusjonene gjennom parprogrammering er som et uendelig kurs i programmering.Ingen “min og din kode. Kunnskapen om kodebasen økes på tvers hele tidenTeknisk gjeld tas fortløpende.Teamsamarbeidet og pyskologisk trygget blir litt forbedret hver dag.Kunden får kontinuerlige forbedringer på produktet.Alt dette er fint, men hvordan kommer du i gang i ditt team?Det ikke-tekniske er ofte det viktigste. Her er noen enkle grunnprinsipper:Bryt ned oppgavene så godt du kan. Og så bryt dem ned enda mer. Og få dem ut i produksjon så fort som mulig.Planlegg ukentlig med lav WIP (work in progress). Ha gjerne færre oppgaver enn antall utviklere, det vil gjøre det naturlig å jobbe sammenI starten kan det være uvant å skulle gå sammen i par for å løse oppgaver. En måte å komme i gang på er å avtale par i starten av uken inntil man får parprogrammeringen litt inn i fingrene.Stop starting, start finishing. Teamet, ikke enkeltpersoner, skal bli ferdige med oppgaver. Hjelp andre med å bli ferdige fremfor å starte på noe nytt selv.Stop starting, start finishing, hold WIP nede. Simen spør hvem som trenger hjelp i stedet for å starte noe nytt selvGjør en retro etter noen uker på hvordan det har gått. Finn det som passer ditt team.Lykke til!NB! Snart kommer en ny artikkel om hvordan parprogrammering påvirker flyt i programmering.ReferanserJames Clear (2018) Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones. Random House Business BooksContinuous Improvement: How It Works and How to Master It av James ClearHver commit er en ny deploy til prod, del 1 av Terje HeenIkke nok et jævla statusmøte! av Marthe Slaatsveen og Thomas Allan NygaardContinuous Integration av Martin FowlerTestDouble av Martin FowlerHvordan vi fikk høyere fart med hyppige prodsettinger og parprogrammering was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Asgaut Mjølne

Synlighet og kunnskapsdeling styrker personvernarbeidet

Det er ikke enkelt å lykkes med å etterleve personvernkravene som stilles til norske virksomheter i dag. Det finnes ingen tydelig oppskrift vi kan følge. I personvernteamet i SpareBank 1 Utvikling erfarer vi at det lønner seg å være synlig, tilgjengelig og engasjerte overfor våre kollegaer. Opplæring bidrar til at vi er flere som kan imøtekomme personvernregelverkets krav. Fremover skal vi i tillegg jobbe for at det blir lettere å gjøre rett.Personvernregelverket er kommet for å bliDen 25. mai er det fire år siden personvernforordningen (GDPR) ble tatt inn i norsk lov. Det fantes regler for behandling av personopplysninger lenge før 2018, men de siste årene har det blitt satt et særlig søkelys på etterlevelse av personvernregelverket. Det samme kan vi si at gjelder internt i vår virksomhet, SpareBank 1 Utvikling. Vi er et produkt- og tjenesteutviklingsselskap som leverer tjenester til bankene og produktselskapene i SpareBank 1-alliansen. Med dette følger behandling av et stort volum av personopplysninger.I likhet med mange virksomheter har vi gjennomført flere prosjekter og tiltak for å øke kompetansen og etterlevelsen av personvernregelverket. Modenhet kommer med tiden, og vi opplever at kompetansen er styrket siden vi gjennomførte vårt første GDPR-prosjekt i 2018. Dette gjenspeiles i alle ledd, fra styret i selskapet til utvikleren i et av våre mange utviklingsteam. Modenheten vises også i antall personer som jobber med personvern hos oss. Siden 2018 har oppgaveporteføljen til personvernombudet vårt økt betraktelig, og i dag er det fire personer i selskapets personvernteam som i fellesskap håndterer personvernombudets oppgaver. I tillegg har vi personvernadvokater og mange produkteiere, systemforvaltere og andre som jobber med personvern i førstelinja. Vi jobber sammen for å sikre etterlevelse av et stadig mer krevende regelverk.Vår suksessfaktorFor å sikre at vi jobber sammen om personvern, etterstreber vi i personvernteamet å være synlige og tilgjengelige for våre kollegaer. Dette medfører at vi blir koblet på utviklingsprosesser eller anskaffelser i selskapet, slik at vi kan samarbeide om å finne løsningene som etterlever personvernregelverket på best mulig måte. I personvernteamet bruker vi ikke pekefingeren, men forsøker å være en løsningsorientert lagspiller. I tillegg forsøker vi å engasjere våre kollegaer gjennom ulike opplæringstiltak. Dette er vår suksessfaktor, og det skal vi fortsette med.Målet fremover er at våre kollegaer skal oppleve at det er lett å gjøre rett. For oss betyr dette slagordet flere ting. Personvernteamet skal fortsette med å jobbe tett med de ulike fagmiljøene i selskapet. Vi skal ha bedre systemer og prosesser som understøtter de kravene selskapet er satt til å etterleve. Disse systemene og prosessene skal være forståelige, tilgjengelige og oppdaterte. Dette vil forhåpentligvis medføre at vårt personvernteam kobles på tidlig i enhver prosess som gjelder behandling av personopplysninger. Dette vil redusere faren for feil, øke kvaliteten på arbeidet vårt og effektivisere arbeidet med personvern. Dersom det er lett å gjøre rett håper vi det vil være enda enklere å jobbe bedre sammen.Opplæring er viktigOpplæring er en nødvendighet for å lykkes med å etterleve kravene i personvernregelverket. Derfor har vi flere ulike aktiviteter, digitalt som fysisk, for å heve personvernkompetansen i selskapet. I personvernteamet jobber vi for at etterlevelse skal være en ryggmargsrefleks for våre kollegaer.Vi opplever særlig å ha suksess med et opplæringstiltak som vi kaller Personverntimen. Dette er et månedlig webinar som alle i selskapet kan lytte inn på. Her tar vi opp ulike personvernrelaterte tema som våre kollegaer bør kjenne til, og vi inviterer ofte andre kollegaer til å holde innlegg. Det gir en ekstra verdi dersom andre enn personvernjurister snakker om personvern, med egne ord og fra eget perspektiv.De siste årene har vi også markert den internasjonale personverndagen den 28. januar. I år gjennomførte vi et webinar for hele SpareBank 1-alliansen, der Datatilsynet, Kripos og vår administrerende direktør snakket for hele 900 av våre kollegaer. På GDPR sin bursdag den 25. mai skal vi også sette personvern på dagsorden, ved å gjennomføre en personverntime hvor vi løfter frem alt personvernarbeid som er gjort og ambisjoner fremover. Vi erfarer at det lønner seg å bruke både de store og de små anledningene til å rette oppmerksomheten mot personvern.Synlighet og kunnskapsdeling styrker personvernarbeidet was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Karen Grinvoll

Hvordan kan vi lede og kode samtidig — del 2

Hvordan kan vi lede og kode samtidig — del 2For å finne leder til Utvikleravdelingen vår i 2018, bestemte vi oss for å PoC-e ledelse. Dette endte blant annet opp med en lederstilling på åremål. Du kan lese mer om bakgrunnen for dette i den første delen av artikkelen.Der forteller vi også om communityledelse og de tre gjengene Faggjengen, Sosialgjengen og Personalledergjengen. Vi så at for å kunne lede og jobbe operativt samtidig, trengte vi å delegere flere av de tradisjonelle lederoppgavene.Distribuert rekrutteringÅ rekruttere er en av de viktigste tingene vi gjør. For å kunne lykkes med rekruttering samtidig som vi både leder og koder har distribuert rekruttering vært viktig, siden det ågjennomføre en ansettelse er mye jobb. Hos oss er det teamlederne som har behov for utviklere som driver rekrutteringsprosessene. Den kanskje mest avgjørende delen av rekrutteringsprosessen er intervjuene. For at de skal være så gode som mulig, har vi jobbet mye med innholdet i både første- og andregangsintervjuet, med QA fra HR og andre som synes slikt er spennende. Det er alltid minst en utvikler med i førstegangsintervjuene, og gjerne to i andregangsintervjuene, slik at flest mulig får dannet seg et bilde av kandidaten.Uten distribuert rekruttering kan vi med sikkerhet si at vi aldri hadde kunnet hatt ledelsen av utvikleravdelingen på deltid.Ledelse på åremålÅ gjøre ledelse på åremål ligner mye på å løpe stafett.Den kanskje viktigste endringen vi gjorde, var å gjøre lederstillingen for Utvikleravdelingen om til en åremålsstilling. Å gjøre ledelse på åremål, ligner mye på å løpe stafett. Du gjør ditt aller beste på din etappe, og på slutten fokuserer du maksimalt på å gjøre en så god veksling som mulig.I tillegg til at avtroppende leder kan gå tilbake til å fokusere på utvikling på heltid igjen, så er det flere styrker med åremålsmodellen. Blant annet sørger det for dynamikk og nytenking rundt ledelsen, og ikke minst nytenking også rundt selve lederrollen. Så selv om vi hadde et par overleveringsmøter, så er mye av poenget at den nye lederen setter sitt eget preg på de faste sermoniene våre.Åremål er som leasingPodcasten Mannspanelet har en episode hvor de debatterer en ide om at ekteskap burde være på leasing. I ekteskapet tenker vi gjerne at denne utfordringen har vi lang tid på å løse. Et helt liv. Men om vi vet at ekteskapet skal opp til vurdering innimellom, så er det større sannsynlighet for at vi fikser riper og skader mer fortløpende.Dette gjelder kanskje for lederskap også? Når vi har en dato å forholde oss til, så er det ikke like lett å utsette oppgaver. Det kan også hjelpe til med at vi er mer til stede og aktiv i perioden vi har fått.Det eneste negative vi har opplevd med åremålsmodellen, er at det kan være vanskelig for personer utenfor avdelingen å vite hvem de skal prate med. Ett år går fort.Hva har vi lært?En av de fine tingene med at flere av oss nå har fått prøvd oss som ledere, er at vi har har lært mye.Vi lærte at en bør delegere så mye jobb som mulig. Når flere er med og løser opggaver, øker sannsynligheten for gode løsninger, engasjement, og eierskap til disse. Å delegere heller enn å gjøre det selv, kan være uvant i starten. Som utviklere er vi både vant til, og ikke minst liker, å løse utfordringer, så det er lett å bare starte på dem uten å tenke over at det nok er bedre å få hjelp fra flere.Når det er mye å gjøre, må vi prioritere. Da må vi også si nei til mer. Det kan være vanskelig, men en blir vant til det også. Et konkret tips her, er å forklare hvorfor du må si nei. Da blir avvisningen litt lettere å godta.I en verden som endrer seg raskere og raskere, og i en organisasjon som er doblet i størrelse på få år, er det bra med noe som er stabilt. Strukturer og faste rutiner skaper trygghet og stabilitet. Det gjelder for barna, og det gjelder også for oss voksne. For oss er det blant annet slikt som avdelingsmøtet vårt hver torsdag, fast after work og stabil personalledelse. Og selv om vi bytter personen som har på seg lederhatten vår hvert år, så er hovedoppgaven som leder for Utvikleravdelingen også fast.Hovedoppgave til lederen for Utvikleravdelingen er å fortsette og bygge utviklerkulturen vår. For å skape en god kultur, må vi hele tiden jobbe med å skape arenaer og muligheter som øker den psykologiske tryggheten blant utviklerne.Vi skaper psykologisk trygghet når vi gjør ting sammen.Den beste måten å skape psykologisk trygghet i en gruppe på, er å la gruppen gjøre ting sammen, dele opplevelser sammen. Så får vi krysse fingrene for at vi får muligheten til å fortsette med det, nå som pandemien ser ut til å roe seg og det går mot vår.Vil du vite enda mer om dette, så kan du se foredraget vi holdt på JavaZone, eller ta kontakt med oss direkte.Hvordan kan vi lede og kode samtidig — del 2 was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

Hvordan kan vi lede og kode samtidig — del 1

Hvordan kan vi lede og kode samtidig — del 1Da jeg ble spurt om å lede den nye Utvikleravdelingen i 2018, sa jeg nei.Jeg hadde lyst til å prøve meg som leder for avdelingen. Men jeg var redd for å komme i en situasjon hvor jeg ikke kunne kode profesjonelt igjen på flere år. En god kollega, Stian Conradsen, ble også spurt. Han sa også nei. Han følte det samme.Dermed lyste vi ut stillingen. Intervjuprosessen med de mange gode søkerne gav oss mer innsikt i hva lederrollen for utviklerne burde være. Vi forstod at Utvikleravdelingen var mer å se på som et utviklercommunity heller enn en klassisk avdeling, i og med at vi generelt ikke jobber sammen, men er spredd ut i mange team.Dette gjorde at vi skjønte at vi trengte en communityleder heller enn en klassisk avdelingsleder. Det ble en runde til internt.Det går heldigvis an å lede og jobbe operativt samtidig.Hvordan kan vi PoC-e ledelse?Vi er vant til å prøve ut nye ideer og muligheter i vår bransje. Vi gjør gjerne en spike eller en PoC (Proof of Concept). Vi tenkte at det kanskje går an å gjøre det samme med ledelse? Vi tok en prat med ledelsen i SpareBank 1 Utvikling, og ble enige om at vi kunne gjøre stillingen som leder for Utvikleradelingen om til en åremålsstilling. Dermed var det maksimalt et år til vi kunne ha koding som hovedaktivitet igjen. Det endret alt. Stian og jeg ble enige om at jeg kunne starte, og så skulle Stian ta over etter et års tid. Vi hadde landet ikke bare en, men to ledere for Utvikleravdelingen.Et engasjert utviklercommunityUtviklercommunityet vårt var sterkt, og fungerte godt allerede før avdelingen ble opprettet. Vi hadde faggrupper, brown bag lunsjer, bokklubb og jobbet strukturert med JavaZone og andre viktige konferanser. I tillegg hadde vi også distribuert personalledelse. Det betyr at hos oss er det utviklere som er personalledere for opptil fem andre utviklere.Selv om vi hadde alt dette på plass, så vi at vi trengte å delegere enda mer av arbeidet en tradisjonell leder gjør for både å kunne lede avdelingen og jobbe med kodeoppgaver i et team.Vi opprettet Faggjengen, Sosialgjengen og Personalledergjengen for å få til dette.FaggjengenFaggjengen har det overordnede ansvaret for den faglige utviklingen i avdelingen. Den lager blant annet heldags fagdager, fikser faglig opplegg når vi er på tur, og har også et ansvar ifm prioritering av felles forbedringsopgaver.Faggjengen ordner frokost med godt påfyll av både mat og fag.SosialgjengenEn kan ha det gøy sammen med mer enn faget vårt. For å fikse det har vi Sosialgjengen. Også det er en sammensatt gruppe av utviklere som får energi av å gjøre noe for andre på det sosiale planet. Fra uke til uke har vi gjort det veldig enkelt. Da er det after work. Når vi skal på tur, er det også Sosialgjengen som ordner det.PersonalledergjengenVi må fortelle mer om måten vi gjør personalledelse på. En vanlig modell er at en avdelingsleder har ansvar for mange, gjerne alle ansatte i sin avdeling. Da kan det bli krevende å være tett på de en har ansvar for.Vi ønsket å prøve en annen modell, hvor utviklere har personalansvaret for et lite antall utviklere. Å hjelpe den enkelte med faglig utvikling er en vesentlig del av personallederansvaret. Vi tenker at dette er lettere å få til når det er utviklere som hjelper andre utviklere med dette. Og når antallet utviklere en har ansvaret for er lite, blir det enklere å komme tett på. Vi ønsker heller mange hyppigere samtaler enn store og få. Smidig HR kaller vi det.Flere av våre utviklere har erfaring med personalledelse fra tidligere. I tillegg kjører vi kurs for de som kommer med som nye personalledere, slik at de får ballasten de trenger. Vi har også fast møte i personalledergjengen, hvor vi kan prate om utfordringer og praktiske ting som dukker opp.Men det er merSelv om vi har distribuert mye ansvar i Faggjengen, Sosialgjengen og Personalledergjengen, så er ikke det nok til at Avdelingslederen for Utvikleravdelingen i praksis skal få tid til også å drive med utvikling. I del to av artikkelen forteller vi mer om hvordan vi har distribuert blant annet rekruttering. Vi deler også mer om hva vi har lært etter tre års erfaring med ledelse på åremål.Vi pratet også om dette på JavaZone i desember 2021.Hvordan kan vi lede og kode samtidig — del 1 was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

SpareBank 1 Utvikling på JavaZone

Endelig ble det JavaZone 2021. Det ble avholdt i Oslo Spektrum 8–9. desember, med sju parallelle tracks begge dagene, og med et begrenset antall publikum inne onsdag 8. desember. Nye koronaregler trådte i kraft natt til 9. desember, og siste dag var det bare speakere som hadde mulighet til å møte i Spektrum.Vi vil benytte anledningen til å si en stor tusen takk til JavaZone arrangementskomiteen som har hatt to veldig krevende år. På tross av situasjonen vi har vært i, har de klart å arrangere en mindre og heldigital JavaZone i 2020, og en full JavaZone, dog uten ordinært publikum, nå i 2021.SpareBank 1 Utvikling var involvert i fem foredrag i år, og alle ble streamet live fra Spektrum. I tiden som kommer vil vi skrive artikler basert på flere av foredragene her på bloggen. Vi vil også legge ut lenker til foredragene når de blir tilgjengelige online.Her er foredragene:Mer enn gode talks og kald pils — derfor burde Du snakke på JavaZone!Jonas Nordstrand holdt denne lyntalen om hvorfor du bør snakke på JavaZone, og ikke minst hva som gjør at mange vegrer seg for akkurat dette.Jonas forteller om hvorfor akkurat du burde snakke på JavaZone.Norske byggeklosser — Hands-on bruk av norsk BERTJan Erik Modal kjørte dette maskinlæringsforedraget om praktisk bruk av nye norske språkmodeller.Fun and controversial programming tricks they don’t teach you at schoolGunnar Kriik pratet om utradisjonelle måter å løse programmeringsutfordringer på.Hvordan lede 86 utviklere og samtidig levere kode hver dag?Stian Conradsen og Vidar Moe pratet om hvordan SpareBank 1 Utvikling gikk fram for å finne en intern leder til stillingen som leder av Utvikleravdelingen samtidig som ingen interne ville slutte å kode.Team på tomgangJostein Emmerhoff og Marius Mikalsen (Sintef) pratet om hvordan vi kan kan jobbe både med allignment og autonomi i organisasjoner som både både vokser hurtig og har flere og flere kryssfunksjonelle team.JavaZone 2021 ble en spesiell JavaZone både for publikum og speakere.Vi gleder oss allerede stort til JavaZone 2022. Vi sees der.SpareBank 1 Utvikling på JavaZone was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

Hvilken skal jeg velge?

Vi vil hele tiden lage de beste og smudeste løsningene for kundene våre. For å få til det, må vi innimellom oppgradere teknologiene og verktøyene vi bruker. Men hvordan skal vi egentlig velge et nytt produkt / teknologi / plattform når det er flere gode valg, i en industri der det som er State of the art i dag gjerne er worst practice i morgen?Det finnes mange jevnbyrdige konkurrerende produkter innenfor de fleste områder, det være seg databaser, byggesystemer eller skyleverandører. Hvordan skal vi finne de teknologiene som er best for oss når det er så mange alternativer å velge mellom?Hvilken skal vi velge?Top of the PopsVi tror det er lurt å basere oss på teknologier som er populære i industrien generelt, og godt likt blant utviklere spesielt. Det er det flere grunner til:Sannsynligheten er stor for at også våre utviklere vil like, eller allerede liker teknologienNår vi skal ansette nye utviklere, så er det stor sjanse for at de også liker tekonlogienPopulære teknologier har som oftest god og enkel dokumentasjon, slik at det er lett å få hjelpDet som ikke står rett fram i dokumentasjonen, står som gjerne på stackoverflowMen det er ofte flere teknologier som er populære, og har sine følgerskarer. Hva gjør vi da?Spør en vennDet kan være lurt å finne ut om noen andre en kjenner og stoler på, har erfaring med en eller flere av de aktuelle teknologiene. I så fall, inviter til en prat og få dem til å fortelle om både fordeler og ikke minst ulemper og ting å tenke på. Da er det også fint å få høre mer om konteksten de bruker teknologien i — er den lik nok ditt behov til at deres erfaringer er relevante?Et annet tips er å gå utover venner og kjente, og rett og slett gjøre et moderne literaturstudium. Det består av å se talks, lese reviews, bloggposter og artikler om de aktuelle teknologiene. De mest populære teknologiene kan ofte gjenkjennes på at det også er de det er flest artikler og talks om.Det viktigsteHvis dere har noen absolutte krav, så er disse bra for å snevre inn valget. Er det noen egenskaper med produktet som er ekstra viktige for dere? Kanskje har dere for eksempel en del absolutte sikkerhetskrav rundt autentisering og autorisasjon? Eller kanskje har dere et konkret problem dere trenger å løse? Det hjelper ikke om en teknologi er aldri så bra på aldri så mye, om den ikke leverer på de viktigste kravene.Har du troen?Hvem er det som backer teknologiene? Har dere troen på firmaet eller personene som står bak? Hvis det er en open source teknologi, er det aktivitet og videreutvikling på teknologien? Vil det sannsynligvis også være det om to år?Det kan være mye å velge mellom.Bli skitten på hendeneNår dere har en shortlist på to-tre produkter, er det på tide å bli skitten på hendene for å finne ut av hvordan produktene faktisk fungerer i din kontekst. Dere må prøve dem ut.Vi anbefaler å lage et testcase som er så enkelt som mulig, og samtidig stikker fingeren inn der det gjør mest ondt. Dere må verifisere at dere får løst utfordringene som er grunnen til at dere startet denne vurderingen.Trenger dere en ny database fordi den gamle er for treg når den jobber med store JSON datasett? Da lager dere et digert JSON datasett og utstetter testkandidatene for dette. Eller kanskje dere trenger et nytt byggsystem fordi det gamle ikke takler at dere bygger de 400 nye flotte mikroserviceappene deres i parallell? Starte med å teste ut bygging av 800 apper i parallell.Med reell uttesting kan dere også samtidig verifisere at for eksempel sikkerhetsmekanismene faktisk fungerer som beskrevet.Utvikleropplevelse og brukervennlighetReell uttesting er også den eneste måten å få en følelse med brukervennligheten til teknologiene dere vurderer. Er APIene hensiktsmessige og enkle å bruke til for eksempel automatisering? Hvordan føles det å jobbe med dem? Er de lett å bruke i konteksten som er viktig for dere? Er de raske? Er dokumentasjonen rett? Eller mangler kanskje de viktigste APIene for dere helt, og eneste mulighet for automatisering er screenscraping av triste pek-og klikk-grensesnitt?APIene gir også røntgensyn som lar oss se inn i firmaet som utvikler dem. Gjennom APIene kan vi se hvordan utviklerene tenker og hvilket fokus de har på utvikleropplevelse. Skal dere for eksempel vurdere en ny partner som leverer tjenester via APIer, ta med en utvikler på det første møtet. Gå rett på sak. Det kan spare dere for mye bortkastet tid.Hvis dere til slutt sitter igjen med mer enn en teknologi som svarer godt på punktene over, så er dere heldige. Da spiller det trolig ingen rolle hvilken av disse dere starter med. Skulle det senere vise seg å bli utfordringer, så har dere allerede en alternativ teknologi klar til å ta over.Lykke til med valget.Hvilken skal jeg velge? was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Moe

Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 3/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 3 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 organisasjonDel 3: Erfaringer på hypotesearbeidet og måling av suksess (du er her)Erfaringer på hypotesearbeidet og måling av suksessNår man tester ut nye ting er det viktig å få målt om det faktisk fungerer. Selvfølgelig kan dette være skummelt å se om resultatene blir når man har lagt inn mye energi og krefter for å få det til å fungere, men i eksperimentens ånd må man også være klar på at dette er noe vi tester, og at det ikke er et giftemål.Jeg skulle gjerne delt alle hypotesene vi har gjennomført, men her er et lite utvalg.Hypoteser vi har testetEksempelet under viser flere hypoteser vi utførte på nettsiden for boliglån. Basert på en brukertest så vi at de aller fleste synes boliglån er en veldig “skummel” ting å ta avgjørelse på, samt at produktene som vi kanskje tenkte var logisk for oss, var veldig forvirrende for brukeren.Basert på brukertester så vi at de fleste brukerne synes boliglån er vanskelig, og at våre renter/produkter var forvirrende. Ved bruk av flere hypoteser prøvde vi å både forenkle og gjøre det tydeligere.Hva skjer når en hypotese slår feil?En problemstilling vi jobbet med var at alt for mange mobilbrukere ikke brukte appen vår, men logget seg inn via nettleser på mobil. Dette er et problem fordi appene våre gir den beste brukeropplevelsen.Hypotesen var at hvis vi endret teksten slik at fordelen for mobilbanken var tydeligere, ville flere klikke på lenken til mobilbankappen.Første løsning vi testet var hele teamet fornøyde med. Vi trodde vi hadde skapt et bra innsalg for mobilbankappen, bare ved hjelp av tekst. Problemet var at det motsatte skjedde: det ble mindre klikk på mobilbankappen og flere på nettbank.Hvis vi ikke hadde jobbet hypotesedrevet kan det være at vi hadde gjort denne endringen og duret på videre for å gjøre andre endringer. Men, siden det ligger i rammeverket at vi må verifisere en hypotese etter en gitt periode, er vi tvunget til å analysere endringene når nok data kommer inn.Noen ting jeg lærte av dette eksempelet:Vi kan aldri gi garantier på resultater. Vi kan bare skape et kalkulert forslag og analysere etterpå.Uansett om løsningen ikke gjorde det vi ville, har vi fortsatt lært og blitt smartere av det.Små endringer som dette har store utslag siden vi har millionvis av besøk. Det er ikke alltid nødvendig å gjøre om alt for å få til det man vil.Med det vi lærte fra løsning 1, skapte vi løsning 2 som gikk rett til poenget. Dette ga både en drastisk oppgang i klikk på mobilbanken, men også nedgang i klikk på nettbanken.Selv om dette kan virke som en liten endring, er det en endring som forhåpentligvis vil hjelpe endre brukermønstret til brukerens levetid i SpareBank 1.Hvordan måle suksess?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?Hypoteser og “små seire” gjør at man blir kontinuerlig bedre over tid, mens risikoen er minimert med tanke på tiden teamet bruker. Men, man kan fortsatt skape små seire som egentlig ikke løser de store problemene for brukeren. Derfor er det viktig å ta flere avsjekker for å sikre riktig fremgang.Noen måter å sikre fremgang på er:Klarer vi å måle at vi blir bedre for brukeren over tid?Tester vi nok hypoteser, er de ambisiøse nok og jobber de mot våre OKR?Jobber hypoteseteamet bra sammen?Hvis man har gjort OKR’ene riktig skal det i teorien være enkelt å måle suksess på løsningen basert på målet som ligger i en KR (Key Result).For eksempel er en av våre KR’er: Andelen som oppgir at de finner informasjonen de trenger skal være 90%Et skyhøyt, men veldig konkret mål som vi kan følge med på over tid. Hvis tallet blir høyere (som det har gjort ganske drastisk) kan vi knytte det vi gjør med hypotesene mot de overordnede målene vi har satt.Noe som er like viktig er å forstå om teamet fungerer bra sammen.Måle teamets helse for å bygge kulturen over tidGlade team skaper de beste løsningene fordi de har eierskap, men det krever arbeid og tid for å skape tillit og bygge kultur. Det tok lang tid for å få hypotesearbeidet til å flyte, og selv om man aldri blir ferdig med forbedring, går det mye bedre nå.Det er viktig å konstant ta en sjekk på hvordan folk har det, hvordan vi arbeider, om vi jobber riktig og gjør riktig arbeid. For å få til gode samtaler rundt dette er det nyttig å gjøre det innenfor et bestemt rammeverk som sikrer progresjon.Retrospektiv er kongen her.Det finnes gode forklaringer på hva en retro er, men over tid kan man se et tydelig tegn på at retroene vi har kjørt har gått fra store spørsmål om hvordan vi egentlig skal jobbe sammen til hvordan vi kan bli enda bedre på spesifikke problemstillinger.Under kan dere se progresjonen fra første retro der vi hadde mye å forbedre oss på, til retro nummer 4 der vi kan jobbe med å svare på et spørsmål , i stedet for å diskutere alt. (spørsmålet var “Klarer vi skape verdi for bruker gjennom å ha hypoteseteam?”)Eksempel fra venstre som var første retro med hypoteseteamet til nummer 4 til høyre som var siste.Veien videreI hypotesens ånd er denne måten å jobbe noe vi tester ut nå, men vi er åpne for at det kan komme bedre rammeverk med tiden.Vårt mål er ikke å bli en slave for et rammeverk som vi liker nå, men kontinuerlig være åpne for å finne den nåværende beste løsningen som gjør at våre folk kan skape det beste produktet for våre brukere. Alt annet enn dette hovedfokuset skal egentlig være sekundert.Med det sagt så har denne metoden både bidratt med bedre løsninger for brukeren, en tettere enhet mellom folkene våre og større eierskap til nettsidene. Tre viktige ting for å gjøre kontinuerlig suksess i det evige maratonet vi kaller produktutvikling.Og hvis du har kommet helt til del 3 av artikkelserien (nice!) vil jeg også gi et stort takk til hele teamet. Det aller viktigste man har er de folkene som er på teamet og den ivrigheten, åpenheten og ambisjonene de har vist er noe jeg er utrolig glad jeg har fått vært en del av.Referanser og bøkerUten om at vi deler kunnskap internt i SpareBank 1, er det mange bøker og artikler som hjelper med å bygge forståelsen. Selv om dette er en stor miks som i hver sin grad har inspirert, er dette noen bøker som har vært nyttig rundt dette temaet.Alle lenker under går til Goodreads.comOrganisering og målEmpowered — Hvordan bygge opp et team, spesielt rettet mot produkteiere.Radical Focus — Min favorittbok om OKR og hvordan starte med dette.Lean UX — Finnes mange fine bøker om UX, men denne er fin mtp hvordan få metoder inn i et team.Fagbøker om nettsiderDon’t Make Me Think — en klassiker om hvordan skape nettsider som fungerer for brukeren.Hacking Growth — en bok om å gjøre kontinuerlig testing av små endringer.Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 3/3) was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Lasse Olsen

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 suksessOrganisering av små teams i stor organisasjonJeff 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+ issuesTeamet jobbet med mye individuelle tiltak som ikke hadde sammenheng med hverandreSamarbeidet mellom utvikling/design og redaktørene var ikke godt nokOKR jobbingen var bare et ekstra lag over alt det andre vi gjordeVi hadde ikke gode nok mål som ga mening å jobbe motTeamet 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 nokOKR jobbingen var bare et ekstra lag over alt det andre vi gjordeNå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 resultatVi har lært at OKR ikke er noe vi bare kan ha på siden. Det er noe som krever prioritert fokus over tidVi ø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 EmpoweredHvordan 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)Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 2/3) was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Lasse Olsen

Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 1/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 1 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 (du er her)Del 2: Organisering av små teams i stor organisasjonDel 3: Erfaringer på hypotesearbeidet og måling av suksessHvorfor hypotese-basert utvikling?Jo flere bøker og artikler jeg leser om optimalisering og bygging av produkter, jo mer komfortabel blir jeg med å si at jeg vet ikke hva den perfekte måten er.Med all sannsynlighet er det en all-inclusive buffett som bruker litt av scrum, agilt, sprint eller annet — basert på hva slags produkt og team du har. Med andre ord som en slags cabaret, bare i positiv forstand.Selv om metodene for å bygge et produkt er mange, er prinsippene få:Du har et produkt du vil gjøre bedre.Da bør du ha noen mål du vil oppnå.For å nå målene bør du ha noen flinke folk som kan bygge/forbedre produktet.Hvis alt går bra så oppnår de flinke folkene målene, og produktet blir bedre. PS: gitt at målene er gode, folkene har det gøy og den psykologiske tryggheten gjør at man kan ha ambisiøse eksperimenter innenfor trygge rammer.I snart ett år har teamet jeg er den del av jobbet hypotesedrevet. Vi har prøvd masse, feilet mye, vunnet mer og kommet med utrolig gode løsninger.Eksempel på hypotese vi testet der forbedring av tekst skulle øke trafikk inn til Mobilbanken fra nettsidene på mobil. Resultatet var 23% økning i klikk, som er veldig bra.Hva er en hypotese?En hypotese er en gjetning på at en endring man gjør, vil resultere i noe. Nedenfor kan dere se et bilde der vi testet å endre tekst, som vi trodde ville resultere i at flere klikket på det vi ville de skulle trykke på.En hypotese vi testet, med læringen vi gjorde under.Det vakre med å jobbe hypotesebasert er at man vet egentlig ikke hvordan en endring vil bli. Man kan gjøre en antagelse, basert på tidligere kunnskap og (helst) analyse, men det er egentlig det.Det er først når vi kan analysere dataen at vi vet resultatet. Gikk hypotesen som vi ønsket er det flott fordi da ble produktet bedre. Var hypotesen feil er det bra fordi da har vi lært. win-win.Siden vi er 15 banker kan vi teste hypotesene rett i produksjon for 2–3 banker av gangen. En stor luksus som minimerer risikoen, men gir oss reel data. Bankene synes også det som regel er veldig kult å få teste ut nye ting på sine sider.Vurderte vi andre løsninger enn hypoteser?Det viktigste for oss når vi diskturte hvordan vi skulle jobbe var ikke nødvendigvis hvilken metoder vi skal bruke, men hva er det vi ønsker og har lært:a) Vi har lært at OKR er ikke noe vi kan gjøre i ny og ne. Vi må få opp et rammeverk der folkene kan jobbet fokusert i en lengre periode mot våre mål. (her kan du lese mer om hva OKR er)b) Vi vil at teamet skal ha eierskap til nettsidene (produktet vårt) og målene vi har, så de selv kan bestemme hva vi burde gjøre.c) Vi vil at produktet vårt skal være det beste for våre brukere, som er store deler av norges befolkning.b) Vi vil at folk skal ha det gøy på jobb! Dette høres kanskje flåsete ut for noen, men vi bruker mye tid av våre liv på en jobb. Vi jobber med individer som er smarte, har følelser, egne mål og ambisjoner samt ønsker over hva de vil gjøre på jobben. Vårt produkt er et produkt som konstant skal forbedres gjennom tiden, og jo lengre vi kan holde på en god kjerne av mennesker jo bedre. Med andre ord, vi er ikke i en sprint, men et raskt maraton der vi sprinter noen ganger.Vi har prøvd å bruke hypoteser sporadisk, men det er vanskelig å gjøre ordentlig hvis man ikke har systemet for oppfølgning. I en kombinasjon med at vi fikk to dyktige designere med hypoteseerfaring på teamet og at vi så at andre selskaper og team har suksess med hypotesearbeid, valgte vi å teste dette ut.Grunnlaget for hypotesearbeidetDet varierer hva slags produkt man har, men sparebank1.no har et veldig bredt ansvarsområde. Stort sett alle forretningsområder i SpareBank 1 treffer nettsidene på en eller annen måte. Skulle vi derfor prøvd å fikse alt for alle hele tiden, fikser vi ingenting.OKR og hypotesearbeid er ikke alt vi gjør, men det er noe av det viktigste vi gjør.Å ha en solid forankring i et stort firma som SpareBank 1 Utvikling er viktig. Hadde alle team laget sine egne løsninger basert på subjektive meninger om hva som er viktigst for deres produkt, ville brukeren fått en fragmentert brukeropplevelse.Det som foreløpig har fungert for oss er å sette OKR (Objective Key Results) basert på ett forretningsområde (f.eks. daglig bruk som vi kaller det), som varer en viss tid. I det området har man kunne presentere 3 store problemstillinger, og ut ifra det sette OKR som et team.Hypoteseteamet har da klare mål som sitt anker. Det gjør at de kan velge hva de skal jobbe med, men kanskje viktigere: ha en grunn til å nedprioritere ting som ikke passer til det vi prøver å oppnå.I del 2 av 3 jeg skriver om organisering av små teams i stor organisasjon.Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 2/3)Hvordan hypoteser og små seire kan skape en vinnerkultur (Del 1/3) was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Lasse Olsen

En god og ansvarlig skyreise

Skyteknologi har blitt den foretrukne måten å realisere og levere tjenester på for de fleste selskap. Nye teknologiselskaper etableres i skyen og benytter skyteknologi fullt ut, mens etablerte selskaper gradvis går over til å realisere og levere sine eksisterende tjenestene gjennom sky.Dette er en artikkelserie hvor vi tar for oss hvordan vi i SpareBank 1 Utvikling beskriver hvordan vi migrerer systemer til sky og hvordan dette påvirker organisasjonen. I første del ser vi på den organisatoriske forankringen og endringene dette kan medføre.Egenskaper og fordeler med sky gjør at teknologisk innovasjon og tjenesteutvikling i stadig større grad foregår i sky, og konsum av skytjenester blir derfor en forutsetning for å få tilgang til de nyeste produktene og tjenestene.Vi i SpareBank 1 Utvikling har lang erfaring med sky i isolerte caser, for eksempel mCash (en forløper til Vipps), Spleis og Spink, men at dette ikke har medført en bredere overgang til sky.Vi har nå startet en større migreringløp hvor vi ser på hvordan vi kan migrere flere av våre egenutviklede løsninger ut i skyen.I tillegg til egenutviklede løsninger benytter vi allerede SaaS løsninger (Software som en tjeneste), hvor vi bruker ulike enkelttjenester til spesifikke oppgaver. En del av dette er at vi har en bred utrulling av Microsoft 365 porteføljen til de ulike underselskapene.Hovedfordelene vi ser ved å gå til sky er:• Sikre konkurransefortrinn gjennom tilgang til innovasjon, nye tjenester og økt funksjonsrikdom.• Øke endringsevne og fleksibilitet gjennom tjenestekonsum og bruk av arkitektur og plattformer bygget for og i skyen. • Redusere ledetid ved å utnytte egenskapene ved skyen og rendyrke automatisering.• Oppnå kostnadsoptimalisering gjennom effektive og skalerbare plattformer.Tydelig retning og forankring i ledelsenSky er en reise og ikke bare flytt av tjenester fra en leverandør til en annen. Ved å gå ut i sky åpner man for en endringsreise hvor det er viktig at alle er med.Å gå til sky er en langsiktig reise og det viktig at man har en tydelig retning og god forankring i hele organisasjonen slik at man har ett felles målbilde som man står sammen i over tid. SpareBank 1 er en allianse og det er også viktig for oss at de ulike bankene i alliansen også har en grunnleggende forståelse for hva vi gjør i sky og hvordan det påvirker deres bank.I SpareBank 1 Utvikling har vi etablert en skystrategi hvor vi på et overordnet plan har definert hvordan man benytter sky i ulike scenarioer for ulike tjenestetyper. Denne er etablert som en del av våre felles strategier og håndtert i vår kvalitetshåndbok.Skystrategien definerer ett sett strategiske prinsipper som vi benytter i vår tilnærming:• Vi vurderer alltid skyløsninger som et reelt alternativ.• Vi tilpasser organisering og løsninger til sky, ikke omvendt.• Vi foretrekker tjenestekonsum og ferdige løsninger.• Vi etablerer skykapabiliteter iterativt, basert på forretningsbehov.• Vi har finansieringsmodeller som harmonerer med sky.• Vi har et bevisst forhold til lock-in og hvilken risiko vi aksepterer.Autonome teamAutonome team er ikke noe som springer ut av en skyreise, vi i SpareBank1 Utvikling har allerede gode innarbeidede autonome team. Men det vi ser at teamene blir mer effektive og selvstendige med å ta i bruk de løsninger og teknologier som ligger i skyen.Erfaringen er også at det er enklere for driftsteamene å bli mer effektive når man migrerer til sky. Bakgrunnen for dette er at det er enklere å ta i bruk muligheter som infrastruktur som kode, hyppige leveranser og full testautomatisering.Kompetansebygging og forståelse for sky er viktig. For at alle skal få en god forståelse for sky så ha vi introdusert skytimen hvor alle kan delta. Her har vi presentasjoner om mulighetene og utnyttelse i sky. Her kommer vi også til å benytte eksterne presentatører til å presentere hvordan de ser fordelene i deres utnyttelse av sky.De som arbeider direkte med sky har hyppige uformelle show&tell-møter hvor de går gjennom spesifikke temaer og løsningerI tillegg har vi godt samarbeid med skyleverandørene hvor vi får fortløpende støtte og assistanse til kompetanseheving slik som egne hackathons, 1:1 møter med produkteksperter og kursing.I neste artikkel vil vi ta for oss hvordan vi utvider forståelsen og kompetansen sett i lys av våre tjenester og organisasjon.En god og ansvarlig skyreise was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Vidar Hagen

SpareBank 1 Utvikling på Instagram@sparebank1design@sparebank1utvikler