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 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

Plag din egen webapp

Sikkerhetstesting må ikke utføres av en med sikkerhet i tittelen. Hvordan kan en utvikler gjøre litt selv?Photo by Sean Lim on UnsplashI utviklingsavdelingen er vi to personer som jobber fulltid med sikkerhet, sammen med flere hundre utviklere. Min kollega fortalte om at hvordan utviklere kan begynne å tenke sikkerhet, jeg ønsker å fortelle litt mer om testing og verktøy.Du kommer langt hvis du starter med å spørre deg selv “Hvordan kan jeg få denne applikasjonen til å gjøre ting den ikke skal?”Et kart over applikasjonssikkerhetMange utviklere har blitt kjent med OWASP og deres mest kjente verk, Top Ten. Det forteller om de ti mest utbredte sårbarhetene i webapplikasjoner, en god start når du ønsker å lære mer om sikkerhet.OWASP har en rekke prosjekter som går dypere enn Top Ten, deriblant Web Security Testing Guide. Dette er et godt oppslagsverk som beskriver sårbarheter og hvordan du skal teste for dem. Bare ikke bruk den som enda en evinnelig og forbanna sjekkliste, da går den fort i skuffen.Et enkelt verktøyMest sannsynlig har du allerede et verktøy for enkel sikkerhetstesting. Webapplikasjoner skrevet i JavaScript er utbredt og Chrome DevTools lar deg studere oppførselen nærmere. Kombinerer du verktøyet med et kritisk blikk, så kan du fort finne informasjon på avveie.Har du Chrome installert er det enkelt å komme i gang. I menyen klikk View → Developer → Developer Tools og verktøyet er klart.Network-fanen gir deg en oversikt over trafikken som genereres av en webapplikasjon, dette kan fort gullgruve med informasjon. Alt fra lastingen av selve siden til ressurser som stilsett og bilder fanges opp her.Den mest interessante trafikken som genereres av webapplikasjoner, er ofte XHR-kallene. Denne trafikken genereres av klienter som kommuniserer med et API. For eksempel en React-applikasjon som kommuniserer med et API skrevet i Kotlin.Kanskje finnes det sensitiv informasjon gjemt i kallene? Da sitter du på et mulig viktig funn.Network-fanen i Chrome DevTools som viser XHR-trafikk.Det er mye data tilknyttet webapplikasjoner og noe lagres på klienten. Application-fanen lar deg se nærmere på disse, her finner du cookies, session storage og local storage. Ofte finner du sensitiv informasjon, andre ganger finner du verdier som kan endres som igjen kan gi deg nye privilegier.Application-fanen i Chrome DevTools som viser en oversikt over cookies.Et kraftigere verktøyJeg startet sikkerhetsreisen min med utviklerverktøyene og fikk senere behov for en større og kraftigere verktøykasse. Burp Suite fra PortSwigger er en samling av verktøy for å gjøre sikkerhetstesting mer effektiv, dette har blitt mitt viktigste verktøy i hverdagen.Dette er en proxy som legger seg mellom nettleseren og nettet, som lar den logge og manipulere all trafikk. Den innebygde utgaven av Chromium lar deg enkelte komme i gang, samtidig som du fortsatt har tilgang til Chrome DevTools.Ofte ønsker vi ikke at absolutt all trafikk logges i Burp. Heldigvis kan vi sette et scope slik at kun sidene vi er interessert i logges. Vi kan i ettertid inspisere og arbeide med den loggede trafikken, det er her kraften i Burp ligger.https://medium.com/media/32da9b079d11e9d305903fbcb15cfd1b/hrefSom sikkerhetstester ønsker jeg ofte å endre på headere og annen last for å se hvordan en webapplikasjon reagerer, dette kan gjøres enkelt ved hjelp av Repeater.Jeg starter ofte med å finne en forespørsel i loggen, denne sender jeg til Repeater som lar meg gjøre endringer på forespørselen før jeg sender den på nytt. Det er en veldig enkel handling, men Burp lar meg gjøre dette veldig effektivt.https://medium.com/media/9bf5ecece90d6e6a8151c0acf9b9c76f/hrefOm man vil teste flere forskjellige verdier vil det være tungvint å legge de inn manuelt en etter en i Repeater. Heldigvis kan verktøyet Intruder hjelpe med å sende hundrevis av forespørsler på kort tid. Alt man trenger er en ordbok med alle variasjonene man vil teste, Intruder ordner resten og sender hundrevis av ulike forespørsler på veldig kort tid.Gjennom konfigurasjon velger jeg hvor jeg ønsker å legge inn de ulike lastene eller om det er noen mønstre som det skal søkes etter.https://medium.com/media/05209a7496aea86b47731af8ce398828/hrefBurp Suite byr på veldig mye mer funksjonalitet, men verktøyene jeg har snakket om er de viktigste. Verktøyene er tilgjengelige Burp Suite Community Edition som er tilgjengelig gratis fra PortSwigger.Den betalte utgaven inneholder en skanner, men ikke fyr av automatiske verktøy før du forstår hvordan testing gjøres manuelt. Samtidig risikerer du å teste ting du ikke har lov til å teste.OppsummeringDet skal ikke mye til for å gjøre enkel sikkerhetstesting selv.Vær ondsinnet og tenk over hvordan applikasjonen ikke skal brukes.Ta med kart og kompass levert av OWASP.Hent frem en proxy og gi applikasjonen en veldig kjip dag.Happy hackin’!Ressurser brukt i demo:Burp Suite Community EditionOWASP Juice ShopSecListsPlag din egen webapp was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Adrian Alexander Eriksen

Har du rom for forbedring?

Du har kanskje spilt dette spillet som barn?En 10x10cm plastplate med brikker du kan skyve rundt på. Illustrasjon fra Slack av Tom DeMarcoVed hjelp av den ledige plassen flytter du rundt på brikkene for å sortere dem i den rekkefølgen du vil.For å dra det litt nærmere vår virkelighet, så kan vi tenke på den ledige plassen som noen ledige pulter i lokalet i vårt, eller kanskje et par utviklere som har ledig kapasitet?Ved å bruke også den ledige plassen blir vi 100 prosent effektive! llustrasjon fra Slack av Tom DeMarcoFyller vi helt opp blir vi utrolig effektive . Vi utnytter absolutt all kapasiteten vi har.Samtidig mister vi helt muligheten til endring og forbedring.Vi har ikke noe handlingsrom til å håndtere endrede prioriteringer og forbedringer uten at vi samtidig må stoppe andre aktiviteter. Kundeverdien av aktivitetene vi stopper er null, helt til vi får gjort dem ferdig. Kanskje. Siden. En gang.For å kunne jobbe godt med forbedringer og endrede prioriteringer, trenger vi slakk i organisasjonen.Det kan være lettere å forstå mekanismene som ligger bak denne observasjonen med et generelt eksempel? Avsnitt ni her, viser at i et team med varierende antall oppgaver og kompleksitet, så må vi ha slakk i teamet for å optimalisere time to market for det vi holder på med.Hvordan lager vi slakk da?Ja vel. Men hvordan i all verden skal vi lage slakk da?Vi kan lage slakk på flere måter:Ikke alloker folk fulltid på en oppgave. Fulltid er uansett en illusjon, i og med at folk skal på ferie, blir syke, og skal være med på en fastelavensfeiring i barnehagen innimellom.Ikke lås omfang for oppgavene. Mye av det mange av oss jobber med, er utvikling av løsninger som aldri har vært laget før i akkurat vår kontekst. Med mindre det er løsninger som må på plass innen en viss dato grunnet for eksempel lovregulering, så planlegg med slakk i leveransene ved hjelp av variabelt omfang. Kan vi levere litt som skaper verdi nå, så er det nesten alltid bedre enn å levere mer som skaper verdi siden.Ved å planlegge med slakk i leveransene får du også en mye bedre og åpnere håndtering av alt det som kommer til å skje de neste månedene, som du ikke har den fjerneste anelse om i dag.Noe nesten ingen av oss hadde den fjerneste anelse om for litt over et år siden.Slakk gir rom for forbedringMed slakk gir vi oss selv også rom til å drive med forbedringsarbeid. Dette kan vi gjøre på flere måter og på flere nivå.Slakken vi har i organisasjonen eller teamet, kan vi bruke til å jobbe med forbedring både direkte og indirekte i det daglige arbeidet. Et eksempel kan være å forbedre en enhetstest som ikke er direkte koblet til oppgaven vi løser, eller ta oss tid til å tilgjengeliggjøre den smarte nye funksjonaliteten vi har laget til alle, istedet bare for oss selv eller teamet vårt.Med slakk kan også vi bygge forbedringsarbeid inn i måten vi arbeider på. Vi kan kjøre forbedringsprosesser som retrospektiver, A3 og post mortems. Forbedringsoppgaver vi finner der, kan vi ta inn som en del av det daglige arbeidet.Har vi tilstrekkelig med slakk i organisasjonen, kan vi kjøre større forbedringsinitiativer ved å la folk vi normalt sett ville brukt på ordinært arbeid, jobbe med forbedringsinitiativ i en periode. Siden det er planlagt med slakk i utgangspunktet, vil ikke dette påvirke de planlagte leveransene.Slakk kan vi også bruke til refleksjon og tankearbeid. Sett av tid til å reflektere over oppgavene du jobber med. Løser vi oppgavene på rett måte? Løser vi de riktige oppgavene? Finnes det andre måter vi kan jobbe bedre sammen på?I bransjen vår er kontinuerlig kompetanseheving omtrent obligatorisk for å kunne levere godt over tid. Dette kan det derfor også være lurt å sette av fast tid til. Planlegg med at folk trenger å bruke tid på kompetanseheving. Kanskje kan vi til og med slå to fluer i en smekk, og bruke kompetansehevingen som teamaktivitet og kulturbygger også?Jobber vi med oppgavene våre hele tiden, oppfattes vi fort som veldig effektive.I SpareBank 1 Utvikling jobber vi med å skape stadig bedre flyt i både produktutviklingen vår og forbedringsarbeidet vårt, med bruk av slakk. Vi har skrevet flere artikler tidligere om hvordan dette fokuset har gjort kontinuerlig forbedring til en av bærebjelkene i produktutviklingen vår. Det kan du lese mer om her.Har du rom for forbedring? 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

Jobber du med det du egentlig vil?

Om å være ærlig med seg selv.Photo by Free To Use Sounds on UnsplashJeg har på ingen måter mistrivdes i mine tidligere jobber og har for det meste gledet meg til å gå på jobb. I nesten hele min yrkeskarriere har jeg jobbet med ledelse av utviklingsprosjekter og team. Inntil nylig var dette en naturlig karriere å bygge videre på.Som nyutdannet fikk jeg meg en jobb som utvikler, men det tok ikke mer enn et par uker før jeg ble spurt om jeg kunne lede et prosjekt. Det virket jo som om jeg kunne passe til det? Sant nok, jeg passet til det. Jeg har passet til det i over 15 år, og jeg passer sikkert til det fremdeles, men jeg har endelig funnet ut at det er noe annet jeg heller vil gjøre.Ekte stock photo av megDet kan ta tid å innse at man kanskje ikke lever livet fullt ut slik man egentlig vil. Det er mye lettere å bare la det skli som før og gjøre det man er vant til. Det som er innenfor komfortsonen og det som tilsynelatende er trygt.Jeg har hele tiden følt jeg har jobbet med noe jeg er god til. Mestringsfølelsen jeg har hatt har vært med på å dra karrieren videre i samme retning. Men det handler ikke alltid om hva man er best til. Det handler like mye om hva man selv vil og hva som gir glede og energi i livet. Prioritering her ble vanskelig for meg fordi jeg rett og slett ikke turte å tenke nøye gjennom hva jeg gjorde og hva jeg egentlig ville. Det måtte modnes over tid, men til slutt var svaret innlysende. Svaret var selvsagt noe jeg alltid hadde visst. Jeg ville ikke jobbe med ledelse. Jeg ville jobbe som utvikler.memegenerator.netÅ velge en annen vei, i hvert fall så sent i karrieren, krevde en del mot fra min side. Jeg var ganske redd for hvilken vei høna skulle sparke. Jeg var n00b i git-kommandoer, rota til min første rebase og hadde aldri før har satt mine ben i emacs. Heldigvis så er det ofte slik at det man frykter mest ofte ikke skjer i virkeligheten. Så lenge man er tydelig på hva man kan og hva man må jobbe mer med, handler det ikke lenger så mye om “du er flink nok”. Jeg måtte tørre å ikke være så “flink”, våge å gå fra senior til junior, noe som ikke var lett. For noen er en slik endring enkelt å gjennomføre, og således vanskelig å sette seg inn i. Andre kjenner seg nok igjen og fikk kanskje noe å tenke på.Å være modig er mye lettere når man har noen som støtter og heier på deg. I SpareBank 1 Utvikling følte jeg det var trygt å ta denne praten med min leder og sette i gang en prosess med å gjøre store endringer i karrieren. Jeg fikk også en fadder og mentor jeg kunne ringe til for å løse opp i rebase-floker og stille alle de dumme spørsmålene til. Uten å føle meg dum.Åpenhet og god dialog er viktig. Man trenger å føle en trygghet rundt det å snakke åpent om hva man selv vil. Når jeg først turte å ta steget ble jeg kun møtt med interesse og støtte. Det var fokus på meg som menneske og hva jeg vil gjøre for å trives i min jobb og hvordan jeg kan best bidra med mine egenskaper.Det er ikke mangel på studier som sier at organisasjoner som er gode til å hente ut det beste i sine ansatte og legger godt til rette for at hver enkelt får mulighet til å utvikle seg i den retningen man ønsker, lykkes bedre enn andre. Det er ingen tvil om at endringstakten har økt på de fleste fronter, noe som også øker behovet for å oppdatere seg med tanke på kompetanse. Spørsmålet er om behov og ønske om å bytte spor underveis i karrieren er et tema som stadig flere vil kjenne behov for?Budskapet her er at du alltid har et valg og at dersom du ønsker deg nye oppgaver må du gjøre noe med det, selv om det koster en del å innrømme det. Husk at det spiller ingen rolle om du egentlig burde ha gjort noe med det for lenge siden. Det er aldri for sent. Det som betyr noe er at du tar mot til deg og gjør noe med det når det kjennes riktig. Det krever kanskje at du er dønn ærlig med deg selv, noe som ikke alltid er like lett. Men det er verdt det, jeg lover.Hilsen en utvikler som trives særs godt med nye oppgaver og fokus.Jobber du med det du egentlig vil? was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jens-Christian Bjerkek

Fredag er for feiring

I SpareBank 1 Utvikling er vi på en spennende og lærerik reise innen målarbeid, der bl.a. bruk av Objectives and Key Results (OKR) har gitt gode resultater. En av grunnene til at OKR fungerer godt hos oss er rytmen Christina Wodtke anbefaler i boken Radical Focus. Rytmen har vært viktig for å løse “set and forget”-utfordringen, der mål ikke blir del av det daglige arbeidet. Dette innlegget handler om den delen av rytmen som avslutter uken. Velkommen til “Friday wins”.Radical Focus-modellenFørst noen ord om “Monday commitments”, møtet som kickstarter uken. Her samles hele teamet foran tavlen mandag morgen og spør seg selv “Hvordan ligger vi an i forhold til målene vi har satt oss?” og “Hva må vi ha fokus på denne uken for å nå målet?”. Gjennom denne diskusjonen blir teamet enige om de viktigste oppgavene. Kun disse havner på tavlen. Dette er oppgavene man forplikter seg til i felleskap, og som teamet strekker seg for å levere innen fredag.“Fridays wins”-sesjonen handler om å feire det man har fått til og om å dele læring. Med en varm kopp kaffe, og gjerne med noe godt å bite i, samles teamet på slutten av uka for å fortelle hverandre om ting man har lykkes med.Hadde vi for få markeringer?SpareBank 1 Utvikling kommer fra en sterk kultur for å løse problemer. I utgangspunktet et meget godt fundament for å ta hånd om utfordringene vi har ansvaret for. Ting som gikk bra underveis i arbeidet var det imidlertid begrenset med fokus på. En slik kombinasjon kan skape ubalanse i tilværelsen.“When teams are aiming high, they fail a lot. While it’s good to aim high, missing your goals without also seeing how far you’ve come is often depressing. That’s why committing to the Friday wins session is so critical.” — Christina WodtkeFremveksten av hyppigere produksjonssettinger gjorde at misforholdet muligens ble større. En følge, av denne ellers gledelige utviklingen, var at det ble færre markeringer knyttet til tradisjonelle milepæler og leveranser. Prosjekter har typisk omfavnet viktigheten av å markere leveranser og måloppnåelse. Omfanget av den klassiske prosjektarenaen har imidlertid blitt gradvis redusert i vår organisasjon. Etter hvert som team gikk mer over mot kanban og kontinuerlig flyt, ble demo mer del av det daglige arbeidet og markering på slutten av hver Scrum-sprint borte. I sum kunne det nok tidvis fortone seg som en ørkenvandring på stadig jakt etter ambisiøse mål man ikke helt oppnådde, kombinert med jevnt tilsig av nye problemer å håndtere.Endret dynamikkMed introduksjon av “Friday wins”-sesjonen endret dynamikken seg. Vi startet å prate mer om det vi hadde oppnådd, og gjorde det med en fast rytme. Økt fokus på det som har gått bra har flere fordeler. Ved å gi det man lykkes med mer plass og anerkjennelse øker sannsynligheten for at det vil skje igjen. Atferdspsykologi omtaler dette som at “positive reinforcement” anerkjenner og forsterker det som går bra.“Positive reinforcement is the most powerful leadership tool” — Aubrey Daniels, (Daniels, 1982)I et ambisiøst miljø som jobber med å løse krevende utfordringer bidrar “Friday wins” til å vise oss selv at mye faktisk er oppnådd. Med “Friday wins”-møtet blir positive tilbakemeldinger bygd inn i prosessen, der hver uke avsluttes med en følelse av mestring og fremgang som tas med inn i helgen. Dette til tross for at en del ikke har gått slik vi håpet. Mandag er vi igjen klare for å løse utfordringer og kjempe med å ta de neste stegene gjennom uka.Et annet positivt aspekt ved “Friday wins” er bidrag til trygghet i arbeidet. I boken The Fearless Organization peker Amy Edmondson på viktigheten av at ledere legger til rette for en kultur der psykologisk trygghet er med på å etablere et klima som støtter opp om læring. Google fant i prosjekt Aristoteles at det viktigste kjennetegnet ved team som lykkes er psykologisk trygghet. Med covid-19 pandemien kjennes dette viktigere enn noen gang, med behov for tilhørighet og trygghet fra hjemmekontoret.“…several benefits. One, you start to feel like you are part of a pretty special winning team. Two, the team starts looking forward to having something to share. They seek wins. And lastly, the company starts to appreciate what each discipline is going through and understands what everyone does all day.” — Christina WodtkeUtfordringerEn praktisk utfordring med “Friday wins” oppstår om ikke alle kan delta. I teamet jeg er medlem av benyttes ofte Slack for deling om man ikke har anledning til å være med. Rikelig med high fives og positive kommentarer sørger for at også de som var opptatt får med seg en god dose mestringsfølelse inn i helgen. En annen ting å tenke på er at arenaen ikke blir dominert av de ekstroverte. Ved å la ordet gå runden i teamet sikres at alle deler noe man har lykkes med.Videre kan det være nyttig å understreke hva “Friday wins” ikke er. Hverken rapportering, avmelding av status eller problemer hører hjemme her. Dette kan være krevende å overholde, særlig i begynnelsen, men med litt trening blir det etter hvert naturlig at innholdet kun er det som har gått bra.Tro på å sammen klare det neste stegetEr det god tidsbruk å avslutte uken i fellesskap med fokus utelukkende på det positive? I mitt team undervurderte vi verdien av å prate om tingene som går bra. Vi har erfart at fokus på det positive skaper kraft og tro på at man sammen vil klare å ta det neste steget. Det er mye som fortjener oppmerksomhet, uten at det nødvendigvis direkte har flyttet nøkkeltall. Resultatet er alltid stolthet over det vi har fått til sammen.“Friday wins”-sesjon fra hjemmekontoret.Slik runder “Friday wins” av uka med en kraftfull vitamininnsprøytning. Teamet tar med seg en mengde positiv energi inn i helgen, etterfulgt av velfortjent avkobling og restitusjon. Så enkelt, og så kraftfullt. Fredag egner seg definitivt for feiring.PS! Vil du vite mer om hvordan Radical Focus-modellen fungerer? Les innlegget “Ikke nok et jævla statusmøte!” der et av utviklingsteamene i SpareBank 1 Utvikling oppsummerer sine erfaringer.Fredag er for feiring was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Kristoffer Berg

Hvordan har teamet det når alle er på hjemmekontor?

Lenge før vi befant oss på hjemmekontor i mars hadde vi i SpareBank 1 Utvikling jobbet med å måle teamets helse. Noen team hadde kommet lengre enn andre og vi teamledere lærte kontinuerlig av hverandre. Arbeidet ble ekstra viktig nå når alle plutselig måtte jobbe hjemmefra. Hvordan ville “den nye normalen” påvirke oss?Mars 2020 — tomme lokaler hos SpareBank 1 UtviklingJeg er teamleder for Team Betaling, ett av utviklingsteamene som leverer de digitale løsningene for SpareBank 1-bankene. Vi hadde siden juni 2019 hatt en del utskiftninger på teamet, så vi startet måling av teamets helse når alle de nye utviklerne var på plass. For å spare tid gjenbrukte vi spørsmål fra et annet team og rakk såvidt å komme i gang før pandemien traff oss.Helsesjekk for Team Betaling uke 5 og 11 — svaralternativer Ja=5, Tja=3 og Nei=1Vi brukte mer tid på å diskutere hva spørsmålene betydde enn å reflektere rundt svarene som var gitt. Konklusjonen etter to helsesjekker var at vi måtte ha nye spørsmål. I retrospekt var det kanskje ikke den beste løsningen å arve spørsmål fra et annet team, men da kom vi i hvert fall i gang.TrygghetVi visste det var viktig å bygge tryggheten i teamet slik Amy Edmondson snakker om i sin TED-talk Building a pshygologically safe workplace. Det var også godt kjent at trygghet troner øverst etter Googles funn om hva som kjennetegner high performing teams gjennom prosjektet Aristotle.https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/Tid for å ta frem egne spørsmålVia Microsoft Teams og Confluence (Miro var under innføring og kom på plass like etter) jobbet vi frem våre egne spørsmål.Resultat fra workshopDet var mange gode diskusjoner underveis som f.eks. “Kan alle faggrupper i teamet svare på spørsmål om vi har redusert gjeld?” “Ja, det kan vi”. Både design, utvikling og test har gjeld de kan redusere. Og hva syntes vi om å svare på “Jeg har kunnet si hva jeg mener og blitt hørt?” Var vi trygge nok på hverandre til å svare oppriktig her? Ja, vi mente det.Gjennomføring av helsesjekkSpørsmålene ble lagt inn i Microsoft Forms slik at teamet kunne svare anonymt i forkant av selve gjennomgangen.Frekvensen på helsesjekken ble annenhver uke for å få hyppig feedback nå som alle satt hjemme. Gjennomgangen av resultatene med teamet ble satt til 30 minutter. Spørsmålene som hadde snitt på tre eller lavere ble plukket ut for diskusjon. Vi forsterket også spørsmålene som hadde høyt snitt for å forstå hva vi gjorde bra og hvordan vi kunne gjøre mer av det. De få gangene tiden ble knapp under gjennomgangen, satte vi opp egne møter som f.eks. retrospektiv for videre diskusjon.Helsesjekk med de nye spørsmålene — Svaralternativer Helt uenig=1, litt uenig=2, litt enig=3 og helt enig=4MøterFør pandemien hadde vi en del diskusjoner rundt arbeidsflyten. Diskusjonen fortsatte, men årsaken hadde endret seg. Utfordringen hadde gått fra tidvis visuell støy og vanskeligheter med å jobbe fokusert i kontorlandskapet til savn etter raske avklaringer ved pulten/kaffemaskinen og summingen i landskapet.For å kompensere for dette savnet steg møteaktiviteten, som igjen førte til hyppigere fokusskifter og mindre effektiv arbeidsflyt. For å sikre mer tid til fokusert arbeid testet teamet ut å blokke tid i kalenderen slik som Vidar Moe skriver om i sin artikkel Ikke jobb mens jeg forstyrrer. Vi syns det hjalp, og sammen med god dialog mellom produkteier og teamet ble vi også enda flinkere på prioritering av oppgavene.Et annet møte vi måtte se på var standupen. Med 18 personer på Teams ble standup i drøyeste laget og vi besluttet etter en helsesjekk å gå over til skriftlig standup på Slack. Teamet ble enig om å liste opp planene for dagen og eventuelle behov for hjelp. Og ikke minst, passe på å si hei nå som vi ikke så hverandre.“Jeg har kunnet si hva jeg mener og blitt hørt?” hadde stort sett høy score. De gangene den gikk litt ned var årsaken for mange deltagere i et Teams-møte. Terskelen for å ta ordet var høyere nå enn når vi satt i samme møterom. Tiltaket ble å dele opp i mindre arbeidsgrupper som gjorde det tryggere å ta ordet. Vi prøvde også å alltid ha kamera på og bruke hånden eller chatten i Teams for å be om ordet eller gi små kommentarer.Etter hvert endret vi frekvensen på helsesjekken fra annenhver uke til en gang i måneden, både for å ha færre møter, men også for å rekke og gjennomføre tiltakene vi satte oss fra gang til gang.Det sosialeSelv om møter ofte var tema på helsesjekken, var kanskje den største gjengangeren etter pandemien det sosiale. Vi savnet møtene ved kaffemaskinen, de tilfeldige møtene i gangene, det å spise lunsj sammen, kakefeiring og ikke minst noe så enkelt som å si “Hei, hvordan går det?”Det var ikke like enkelt å få gjort noe med det sosiale når smittevernsreglene ble justert regelmessig. Når vi ikke kunne treffes fysisk prøvde vi å få til så mye som mulig digitalt. Kahoot ble innført fast hver fredag som en del av fredagens markering av hva vi hadde fått til gjennom uken. Kakefeiring på leveranser ble samlet opp med levering av noe godt på døren hjemme hos hver enkelt. Vi gjennomførte Team Canvas som gjorde at vi ble bedre kjent med hverandre som team og enkeltpersoner. Alle tiltak hjalp, men de sosiale arenaene er og blir best når vi møtes fysisk.Som teamleder har det også vært viktig med hyppige 1–1 samtaler da helsesjekken ikke erstatter den viktige dialogen med hver enkelt. Vi har også hatt jevnlig retrospektiv for å få mer helhetlig innblikk i teamets tilstand.Uten helsesjekken og verdien den gir hadde vi ikke kunne hatt like god innsikt i teamets helse, spesielt nå som alle sitter på hjemmekontor. Helsesjekken hjelper teamet til å finne hva som bør være fokus for kontinuerlig forbedring og videreutvikling slik at vi skal kunne bli enda Bedre sammen.SpareBank 1 Utviklings VerdiplattformHvordan har teamet det når alle er på hjemmekontor? was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Sissel Sveum

Sayonara, Internet Explorer

Er det ikke kjipt når du har tatt på fullt turtøy og skal ut på en lang ferd mot en vakker horisont, bare til å merke at det er en stein i skoen?Du står da i et viktig veivalg:Skal du bare dure på? Selv om det gjør vondt og går mye tregere, kan du potensielt nå målet ditt.Skal du fjerne steinen? Det tar kanskje litt tid å ta av skoen, men turen blir mye morsommere og du kommer kjappere til mål.På nettsidene har vi fjernet vår stein; Internet Explorer (IE).Alle som har jobbet med web de siste årene vet hvor ressurskrevende det er å tilpasse løsninger sånn at det fungerer greit på IE. Spesielt når man utvikler løsninger som pusher hva våre teknologiske muligheter er, tar det nesten like lang tid å få dette til å fungere på IE.Fokuset vårt vil være på mobil, ikke Internet Explorer.Trygt valgFor sparebank1.no er det et trygt valg å fjerne supportering av IE. Mobil blir bare mer og mer den foretrukne enheten for brukerne våre, og Chrome samt Safari er desidert de mest populære nettleserne. Etter dette kommer Edge og langt bak med stadig synkende trafikk: IE. Microsoft har selv sagt at de skal slutte supportering av IE i 2021 og fokusere fullt på Edge.Dette betyr ikke at nettsidene vil slutte fungere på IE. Det betyr bare at vi kommer til å prioritere andre oppgaver enn å fikse IE feil. Over tid vil det være mer og mer gunstig for brukeren å velge en annen nettleser. Vi står heller ikke alene om dette: Både finn.no, nav.no og spleis.no gir varsling hvis du bruker Internet Explorer.Problemet er bedrifter som har IE som standard nettleserFor de som får en Windows PC fra jobb og booter denne opp er det en stor sannsynlighet at default nettleser er Internet Explorer. Dette er problemet.Jeg antar at en stor andel av brukere ikke egentlig bryr seg om hvilken nettleser de bruker. Den nettleseren som er mest tilgjengelig er den de bruker, og normalen blir at nettsider kan oppføre seg litt rart eller at man får flere og flere varslinger.Når selv Microsoft har gått ut med at Internet Explorer kan være en risiko for sikkerhet, regler og universelle standarder, kan det ikke være opp til den individuelle ansatte å gjøre et skippertak mot bedriftens anbefalinger ved å bytte nettleser. Bedriften må sette en bedre standard med å tilrettelegge en nettleser som faktisk er supportert og fungerer.Uansett, for å bruke et av Japans mest misforståtte ord:Sayonara, Internet Explorer.Sayonara, Internet Explorer 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

SpareBank 1 Utvikling på Instagram@sparebank1design@sparebank1utvikler