SpareBank 1 Utvikling

Et spennende sted å jobbe

Vi er de 14 SpareBank 1-bankenes felles utviklingsselskap. Vår oppgave er å skape de aller beste løsningene og brukeropplevelsene i bransjen – fordi hverdagsøkonomien er viktig for folk. Vi lykkes ved å la kompetanse, læring og frihet definere oss, og fordi vi jobber kompromissløst data- og kundedrevet.

Et godt sted å være

For å kunne yte på jobb, må vi trives på jobb. Våre medarbeidere får derfor stor tillit og mye ansvar, men også den støtten, veiledningen og opplæringen de trenger for å mestre og like jobben sin. Dessuten passer vi på å le sammen. Mye. Det blir nemlig veldig gode løsninger av god stemning.

@sparebank1-digital på Medium

Velkommen til Bankbokklubben

En hel klokketime dedikert til et spennende tema, med ivrig diskusjon blant vennlige og motiverte folk på søken etter innsikt og læring, i kombinasjon med en god kopp kaffe. Kan man egentlig starte dagen på en bedre måte?Hver onsdag morgen møtes Bankbokklubben i SpareBank 1 Utvikling på en kafe i nærheten av kontoret for å prate om det siste kapittelet i en bok vi leser sammen. Hvorfor gjør vi dette?Formålet med klubben er læring med en felles rytme gjennom fordypning i utvalgte bøker innen vårt interessefelt. Fremgangsmåten følger gjerne et slikt mønster:Gruppen blir enige om valg av ny bok. Kandidatlisten inneholder som regel en rekke godbiter, og det smerter å måtte velge bort de fleste.En avtalt del av boken leses på egenhånd, f. eks. et kapittel eller to.På det ukentlige klubbmøtet diskuteres hovedpunktene i kapittelet. Hva betyr dette for oss i SpareBank 1 Utvikling, og hvordan kan vi teste ut elementer vi har lyst til å undersøke nærmere?Rett som det er gjennomfører vi små eksperimenter og diskutere betydningen av funnene.Bankbokklubben i SpareBank 1 Utvikling tar en pause i diskusjonen av hva boken Deep Work byr på av innsikt, muligheter og utfordringer.Hvorfor fungerer dette for oss?Vi jobber med utrolig mange flinke folk, og det er interessant og nyttig med bredden i perspektiv dette skaper.Man kommer dypere i materialet gjennom diskusjon og repetisjon.Innsatsen som legges ned gjøres overkommelig ved å dele opp en bok i mindre bolker.Det blir enklere å lese ved en positiv forpliktelse i det å møtes for å jobbe videre med materialet sammen.Man kommer i kontakt med interessante temaer og tilegner seg innsikt man trolig ellers ikke ville oppnådd på egenhånd.Vi pleier en felles interesse i det å fordype seg i fag og læring innen vårt fagområde.Det er hyggelig å være sammen. Vi styrker samholdet i gruppa og lærer hverandre å kjenne enda bedre. Dette skjer på tvers av grupperingene vi jobber mest i.Med mange sterke kandidater er nåløyet trangt for å bli valgt som felles bok i Bankbokklubben.Bankbokklubbens opprinnelse kan spores tilbake til da det interne utviklingsmiljøet i selskapet ble etablert. I løpet av denne perioden ble en lesesirkel benyttet for å gå gjennom og jobbe med innholdet i boken The Toyota Way. Hver enkelt leste først et kapittel for seg, som så ble diskutert i gruppen med fokus på hva innholdet betydde for miljøet vårt. Dette skapte en felles plattform, og ga mye energi, til arbeidet med hvordan arbeidsprosesser og -miljø ble etablert og videreutviklet. Da siste kapittel var avsluttet, og boken lagt til side, var det flere oss som kjente på den samme følelsen. Den positive dynamikken fra lesesirkelen ville vi svært gjerne beholde. Dermed gikk det ikke lang tid før Bankbokklubben var etablert.Her er et utvalgt av våre favorittbøker:Culture codeThis is LeanLoonshotsAccelerateGood to GreatLean EnterpriseThe Phoenix ProjectFor tiden leser klubben boken Deep Work og diskuterer ting som: Hva er et godt mønster for bruk av tiden vår, for hver enkelt og for gruppene man er del av? Hva er gode strategier for å oppnå en slik tilstand for kunnskapsarbeidere? Hvordan bør vi måle bruk av egen tid, og hvilke eksperimenter kan vi enkelt gjennomføre for å etablere data og innsikt?Plutselig er en time over. Tiden formelig fløy avgårde, og vi er klare for å gyve løs på resten av dagen. Vel vitende om at nok et spennende kapittel venter for Bankbokklubbens medlemmer i uken som kommer.Velkommen til Bankbokklubben 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

Utvikleravdelingen er død! Lenge leve utvikleravdelingen!

Vi har vært på reisen med kryssfunksjonelle team hver dag siden 2014. Vi jobber så svetten siler med å gi teamene våre best mulig forutsetninger for å løse oppgavene sine.Plutselig en dag oppdaget vi at vi hadde kastet ut babyen med badevannet. Vi hadde optimalisert vekk utviklerkulturen vår.Hva var det egentlig som hadde skjedd?Foto fra BigStockBakteppetVi kan takke Frederick Taylor (1856–1915) for mye. Han populariserte standardisering av arbeidsmetoder. Dette gav oss massiv økning i produksjonsvolum for fabrikker over hele verden. Med på lasset fikk vi også med oss ledelsesprinsipper for å maksimalisere effektiviteten:Finn beste måte å gjøre en oppgave påDokumenter beste måte å gjøre oppgaven påTren opp medarbeiderne til å gjøre oppgavene på beste måteLedere og medarbeidere deler ansvaret for løsning av oppgavene. Lederne skal løse oppgavene de er bedre egnet til, heller enn medarbeiderneEn av utfordringene med disse, er at de har større fokus på å optimalisere enkeltroller heller enn systemet. I tillegg er ledelsesprinsippene er ofte blitt mistolket, eller brukt i feil kontekst. Mange mistolker dem fortsatt, over hundre år etterpå:en bruker rammeverket på arbeidsoppgaver det aldri var ment for å løseen ser bort i fra de kontinuerlige treningsaspektet, dvs. dropper kontinuerlig forbedringTa dette og bland det med tradisjonell avdelingsorganisering i underavdelinger som hver for seg er optimalisert for å være så effektive som mulig, dvs at alle i avdelingen til en hver tid jobber opp mot 100 prosent kapasitet, så har vi en standard bedrift. Deler av utfordringene med tradisjonell avdelingsorganisering har vi også erfart i SpareBank 1 IT.Avdelingsdrevet utviklingVi hadde konseptavdeling, arkitektavdeling, prosjektavdeling, forvaltningsavdeling og driftsavdeling. Nye løsninger ble tatt fram i midlertidige prosjektteam, hvor utviklere var leid inn kun med tanke på å utvikle den ene løsningen. Arkitekter støttet opp om prosjektteamet. Arkitektenes utfordring var mange. De var gjerne booket opp i flere prosjekter samtidig , de var få, og de var fullt ut prosjektfinanisert. Dermed fikk de sjelden mulighet til å dykke dypt ned i utviklingen — de måtte løpe til neste prosjekt.Avdelinger med forskjellige mål — et system optimalisert for konfliktNår løsningen var ferdig kodet og testet, ble den overlevert til forvaltningsteamet. Dette tok gjerne flere uker, siden koden sjelden var i henhold til standard, og måtte rettes og retestes før handoveren ble godkjent.Denne måten å jobbe på førte til lav tillit mellom avdelingene, og fremmedgjøring for de som jobbet i dem med de aktuelle løsningene.Mikrotjenestene gav oss teamSom så mange andre, hadde også vi en stor monolitt som alle de nye løsningene ble merget inn i. Vi fikk større og større utfordringer med å levere i monolitten, og dette medførte at vi startet et arkitekturprosjekt i 2012 for å bryte den opp i flere mindre tjenester — la oss kalle dem mikrotjenester. Da vi gjorde dette, bestemte vi oss for å bruke verdikjedeinngangen for å finne fornuftige deler å dele monolitten opp i. Da ble det også naturlig å lage team rundt verdikjedene. Dette var starten på de kryssfunksjonelle teamene våre. Med stabile team organisert rundt verdikjedene, fant vi svar på mange av utfordringene vi hadde hatt med den avdelingsdrevne utviklingen.Egne utviklereVi hadde hatt 100 prosent konsulentdrevet utvikling fram til 2012. Vi startet reisen med egne utviklere omtrent samtidig som vi startet reisen med microtjenester. I starten var vi totalt omtrent 50 personer som jobbet sammen i et fåtall team og omtrent ti av oss var ansatte utviklere og testere. Vi jobbet sammen, og hadde hyppige avdelingsmøter sammen.Entusiasmen var høy. I tillegg til å få en mer moderne arkitektur, hadde vi skapt oss et rammeverk som gjorde at vi kunne skalere opp til å støtte flere verdikjeder — og dermed også flere team. Det gjorde vi. I 2017 var vi blitt 15 team.Samtidig hadde vi ikke evnet å rekruttere egne utviklere i et like høyt tempo. i 2017 var vi gått fra omtrent 10 til omtrent 25 fast ansatte utviklere. Brorparten av skaleringen var gjort med konsulenter.OppsigelserI løpet av seks måneder vinteren 2017–2018 sa seks av utviklerne våre opp.Hva var det som hadde skjedd?Det viste seg at vi hadde jobbet så mye med å skape optimale arbeidsforhold for de kryssfunksjonelle teamene våre, at vi hadde kastet ut babyen med badevannet.I reisen fra et fåtall til da 15 team, ble utviklerne våre spredd tynnere og tynnere utover teamene. Med 25 utviklere på 15 team, så vil de fleste utviklerne enten være ensom som fast ansatt utvikler på teamet sitt, eller i beste fall har en utviklerkollega til i teamet. Den gangen vi var 10 stykker og et fåtall team, så vi hverandre og delte kaffemaskin hver dag. I 2017 var vi blitt 15 team spredd over tre etasjer. Vi traff ikke hverandre lenger. Utviklerkulturen vår var blitt anonym. Tilhørigheten var borte.Utviklerne går sammenOppsigelsene gav oss en skikkelig vekker. Sluttsamtalene var entydige. De som sluttet, følte liten tilhørighet til SpareBank 1 og var ikke fornøyd med den faglige utviklingen sin.Sommeren og høsten 2018 la vi opp til en rekke grep for å snu dette helt om. Vi ville skape et skikkelig bra fagmiljø med mye sosial trygghet og mye humør. Et sted det er godt å være.Vi gjorde to fundamentale grep:Vi satte opp utviklerne som en egen fagavdeling. Vi hadde tidligere vært organisert sammen med flere andre disiplinerVi innførte ukentlig fagdag. Du kan lese mer om fagdagen vår herFagavdelinger + kryssfunksjonelle team = santFor å bygge sosial trygghet og sosial tilhørighet i en hverdag hvor en jobber i kryssfunksjonelle team, er fagavdelingene våre blitt viktigere enn noen gang. I fagavdelingen har vi et fast møtepunkt. Der bygger vi kulturen vår, jobber sammen og blir bedre utviklere sammen. Vi mener dette er så viktig at vi bruker en hel dag hver uke på dette. Dette gir oss muligheten til å jobbe sammen på arkitekturutfordringer, ta kurs sammen, jobbe aktivt med blogg- og konferanseinnlegg, og jobbe med personal, rekrutterings- og brandingsaktiviteter. Ved å være sammen og jobbe sammen med disse aktivitetene, skaper vi også sosial tilhørighet og trygghet. Vi skaper utviklerkulturen vår.Fra standen vår på JavaZone.Faggruppene våreI tillegg til det strategiske kompetansearbeidet som foregår i fagavdelingene, gjør vi taktisk og operativt kompetansearbeid i faggruppene våre. Her er også konsulentene med, og de går gjerne på tvers av fagavdelinger. Vi har faggrupper for en rekke fagområder. Eksempler er teamledelse, applikasjonsarkitektur og sikkerhet.Shift left holder ikkeShift left er en trend som peker på at en skal flytte en rekke aktiviteter som tidligere typisk dukket opp sent i utviklingsprosessen, for eksempel test og sikkerhetsarbeid, tidligere i prosessen. Vi mener at dette på langt nær er nok for å skape en effektiv utviklingsprosess.Du skal ikke bare “shift left” — du skal “rotate left”. Du skal bevege deg fra en horisonal avdelingsstruktur med handovers og ressursoptimalisering, til en vertikal verdikjedeorientert struktur, med kryssfunksjonelle team som jobber flytoptimalisert.Vi må dyrke kulturen og den faglige tilhørigheten. Dette gjør vi i fagavdelingene og faggruppene våre. Samtidig er det i verdikjedene forretningsverdiene skapes. Da er de vi må optimalisere, og i de vi må jobbe.Synes du dette var interessant, så pratet Jostein Emmerhoff og jeg mye mer om dette teamet på JavaZone 2019. Foredraget finner du her.Utvikleravdelingen er død! Lenge leve utvikleravdelingen! 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

Monorepo med Git och Maven: så fick vi det till!

I SpareBank1 Utvikling har vi tagit i bruk ett monorepo för vår nya generation med appar i digitalbanken. Vi har utgått från verktyg som vi känner gott från tidigare: Git, Maven och Jenkins. Detta är verktyg som i stor grad är mer tillpassade får multirepo än monorepo.Vi har tagit fram ett exempel-githubrepo som visar hur vi har arbetat runt många av de utfordringarna som kommer särskilt från bruk av Maven och Jenkins. Repot visar också hur Bazel-byggsystemet kan användas som ett mer monorepo-native alternativ till Maven.Mer om monorepo kommer på JavaZone 2019: Monorepo med Git og Maven — hvordan lære gamle hunder ny triks, 11 september kl 13:00 i rum 2.Bild av StartupStockPhotos från PixabayMonorepo med Git och Maven: så fick vi det till! was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jonas Nordstrand

Torsdag er den nye lørdagen

For en utvikler i SpareBank 1 Utvikling er hver torsdag dedikert til fag. Vi kaller det enkelt og greit Fagdag. Denne dagen brukes til å ta kurs, teste ut nye teknologier, lage helt nye løsninger eller gjøre forbedringer på felles kode.Vi ønsker å dele det vi jobber med. Derfor bruker vi også Fagdagen til å lage artikler som denne, og til å forberede foredrag.Som utvikler i SpareBank 1 er du medlem av et kryssfunksjonelt team. Organisatorisk og faglig er du en del av Utvikleravdelingen. Utviklere, testere og designere jobber sammen i de tverrfaglige teamene, men hver torsdager forlater utviklerne teamet sitt. Denne dagen finner utviklerne sammen for å jobbe med fag. Vi forsøker på denne må å skape en felles utviklerkultur i SpareBank 1 Utvikling.Utvikling kan være så mangt! Her presenteres Hjernebank 1Kultur spiser strategi til frokostPeter Drucker skal ha sagt at “Culture eats strategy for breakfast”. Kort fortalt mente Drucker at kultur alltid vil vinne over struktur. Vi trenger struktur, men kulturen må underbygge strukturen. På QCon i mars var jeg på et foredrag med Randy Shoup. Han påstår at “Kultur spiser strategi og organisering og teknologi og prosess og … til frokost”.Vi tror på en kultur der deling, åpenhet og psykologisk trygghet er fundamentene. Med basis i denne kulturen bygger vi en organisasjon som støtter opp under disse verdiene. Når vi møtes hver torsdag er vi med på bygge denne kulturen. Vi deler kunnskap . Vi lærer og feiler sammen. Vi sosialiserer og vi blir bedre kjent. På denne måten blir vi tryggere på hverandre. Dette gjør det igjen enklere å kommunisere på tvers av teamene. Vi tror også at en god kultur gjør at våre dyktige utviklere ønsker å fortsette å være en del av SpareBank 1 over tid. Fakta er at siden vi startet med fagdagen har ingen utviklere avsluttet hos oss. Samtidig har vi blitt 13 nye utviklere i avdelingen.FlerkulturNår man har en kultur i teamet og en kultur i fagavdelingen, får man flerkulturelle utviklere. Om avstanden mellom “team-kultur” og “fag-kultur” er for stor, vil det kunne skape utfordringer. Resultatet kan bli at man ikke kjenner seg hjemme i fagavdelingen. Utvikleravdelingen i SpareBank 1 Utvikling er en ny avdeling. Når vi nå lager en felles kultur for denne avdelingen, må alle få være med å lage den. Fagdagen er en bra arena for dette. Vi har etablert to arbeidsgrupper. Den ene gruppen fokuserer på sosiale tiltak, mens den andre fokuserer på faglige tiltak. Dette har resultert i felles utflukter, middager og kodekata.Sterke fagmiljø kan også være en utfordring. I en matriseorganiasjon kan det bli konflikt mellom teamene og fagavdelingene. Teamene er tett på kunden og har fokus på levere løsninger på en effektiv måte. For at et team skal bli effektivt jobbes det hele tiden teamkulturen. Stabilitet er et viktig element for effektive team. Endrer man sammensettning av personer i et team viser forskning at det tar tid å bygge effektiviteten opp igjen. Mye av grunnen er at endringer av denne typen påvirker den psykologiske tryggheten i teamet. Denne tryggheten er ikke bare nødvendig for å være effektiv, men også for innvoasjon (Edmondson, 2008). På bakgrunn av dette er det derfor veldig viktig at teamene er tett innvolvert når fagavdelingen ansetter nye utviklere. Teamtilhørighet bør være avklart før ansettelsesprosessen starter og en representant fra teamet bør være med på intervjuene. På denne måten tror vi at vi skal klare å ansette utviklere som passer kulturen i både teamet og fagavdelingen.Snakk om kollegaFor å bli enda bedre kjent, har vi hver torsdag en quiz som vi kaller for Snakk om kollega. Alle har delt noen hemmeligheter med vår quiz master Jan Erik Modal. På bakgrunn av hemmelighetens vanskelighetsgrad får man poeng for riktig svar, og ikke minst minuspoeng om man svarer feil. Dette er en artig måte å bli kjent på og et fint avbrudd fra fagfokuset.Utviklerne gir tilbakeFor en leder er det ingen enkel avgjørelse å la utviklerne bruke 20% av sin tid utenfor teamet. Det er derfor viktig å vise resten av organisasjonen hva man gir tilbake. Vi har valgt å forløpende publisere alle aktiviteter som kommer fellesskapet til gode på en delt liste.Hva fagdagen brukes tilMålingFra første fagdag 13. desember i fjor, har vi målt tilfredshet med det sosiale og det faglige blant oss utviklere i SpareBank 1. Vi har brukt en skala fra 1 til 5, hvor 1 betyr svært lite tilfreds, og 5 betyr veldig tilfreds. Like før sommeren var det eksamen. Den ble gjennomført anonymt. Etter ett halvår med fagdag ønsket å måle hvor godt vi nå kjenner hverandre. Resultatet ble et gjennomsnitt på underkant av 80% riktige. Vi har dessverre ingen historiske resultater å måle mot. Vi vet derfor ikke om dette er et bra resultat, men magefølelsen tilsier at 80% riktige er bra.Utviklingen på bare 5 måneder har vært formidabel. Vi startet med en lite tilfredstillende måling i desember med en gjennomsnitlig tilferdshet på 2.41 for det sosiale, og 2.91 for det faglige. Utover vinteren og våren har gjennomsnittet beveget seg opp på 3 tallet, både for det faglige og det sosiale. Vår siste måling, utført 16. mai, ga oss 4.16 for det sosiale. En økning på hele 79%! Den faglige tilfredsheten ble målt til 4.37. En økning på imponerende 44%.Dette er tall vi er utrolig fornøyde med. Spesielt glad er vi for den høye scoren på det sosiale. Fagdagen må ta mye av æren for dette. Men også aktiviteter som vennegrupper og fagsamling med overnatting har hatt en innvirkning. Vennegruppene er en ren kopi av barneskolens opplegg, men i stedet for å hoppe på en trampoline sammen, så spiller vi dart eller spiser god mat.Veien videreFagdagen var er et halvårlig eksperiment. Det er nå besluttet at dette er en fast aktivitet, og at vi skal bruke en dag i uken på fag. Det faktum at vi ikke har noen turnover og at vi i år skal ha fire bidrag på JavaZone, har vært med på å gjøre det enklere å ta denne avgjørelsen.Ønsker du en ny oppdatering på hvordan det går med oss og fagdagen vår, kan du høre meg prate om dette på JavaZone onsdag 11. september kl 12.20 i Rom 1.Anbefalt litteraturJeg elsker å lese om kultur og organisasjon, og hver onsdag morgen møtes bankbokklubben for en kaffe og en bokprat. Av de bøkene vi har lest det siste året vil jeg spesielt trekke frem disse:The Culture Code: The Secrets of Highly Successful Groups, Daniel CoyleLoonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries, Safi BahcallAccelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, Nicole Forsgren, Jez Humble, Gene KimTorsdag er den nye lørdagen was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Stian Conradsen

SpareBank 1 Utvikling skal prate på JavaZone

JavaZone 2019JavaZone er en av de store happeningene for oss i SpareBank 1 Utvikling. Dette er den største utviklerkonferansen i Nord-Europa, og er en fantastisk arena for å lære om alt det som foregår i industrien, fortelle om de spennende tingene vi jobber med hos oss, og ikke minst møte gamle kollegaer og treffe nye kjente.Jobbingen med JavaZone standen og foredrag, foregår nesten hele året hos oss. I år holder vi fire foredrag, og vi har en stand med aktiviteter hvor software og hardware i stor grad er hjemmelaget. Vi skal ikke røpe for mye av detaljene, men vi kan vel si at de som kommer bortom standen vår, skal få noe å tenke på.Her er foredragene vi skal holde på JavaZone i år:Torsdag er den nye lørdagen. Hvorfor bruker vi en dag i uken på fag?Stian ConradsenOnsdag 11. september, 1220, Rom 1Tordentale 20 minMonorepo med Git og Maven — hvordan lære gamle hunder nye triksAnders Gjendem og Jonas NordstrandOnsdag 11. september, 1300, Rom 2Presentasjon 45 minUtvikleravdelingen må dø! Lenge leve utvikleravdelingen!Jostein Emmerhoff og Vidar MoeOnsdag 11. september 1540, Rom 4Presentasjon 45 minHendelsesdrevet læring i SpareBank 1 — Erfaringer fra to år med post mortemKristoffer BergTorsdag 12. september 0900, Rom 1Lyntale 10 minVi har allerede delt av erfaringene våre fra to år med post mortem her på bloggen tidligere. I løpet av august slipper vi bloggposter som deler mer av det vi kommer til å prate om på JavaZone i år.Stemningsbilde fra JavaZoneSees i Oslo Spektrum fra 10. til 12. september. Dette blir gøy!SpareBank 1 Utvikling skal prate 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

Denne PSD2-datoen bør du kjenne til

Mye er sagt om PSD2 (eller betalingtjenestedirektivet som vi så kortfattet sier på norsk), men det er spesielt to datoer som har vært viktige.14. mars (i Norge ble dette april til slutt): Dagen alle skulle kunne teste løsningene bankene vil tilby til tredjeparter med konsesjon som betalingsforetak.14. september: Som tredje part skal du kunne hente ut informasjon fra banken på et vis som følger den tekniske spesifikasjonen for direktivet (den mye omtalte RTSen).Men ettersom tidslinjen for direktivet, og det som kalles “Søknad om fritak fra krav om reserveløsning for kontotilbyder (fallback)” har modnet i bankverdenen, har det dukket opp en ny dato. Denne er egentlig vel så viktig: 14. juni.Og hva er “Søknad om fritak fra krav om reserveløsning ….”? Dette er en søknad som bankene må sende til Finanstilsynet der de forteller om PSD2-løsningen sin, hvordan den er og hvordan den er blitt brukt. Dette skal forsikre om at den er god nok til at tredje partene kan stole på den, og ikke påberope seg retten til å bruke en annen løsning.Alternativet til en godkjent søknad kalles “fallback”. Med mindre banken ikke har en annen løsning implementert, vil tredje-part kunne bruke screen scraping som potensielt gir de tilgang til mer informasjon enn de har krav på under PSD2-direktivet.En forutsetning for søknaden er at du har hatt trafikk på PSD2-løsningen din, i minst 3 måneder før 14. september. Og vipps så kom datoen 14.juni opp!For resultatet av dette er jo at alle bankene vil måtte ha sin løsning i produksjon 14. juni, for å ha trafikk på den. Og det er da det hele egentlig begynner! For hvem vil vel være sist med å vise kontoer fra alle bankene i sine flater?Vi står nå klare med våre grensesnitt — og ønsker tredjeparter varmt velkommen. Frem til midten av juni gjør vi manuell innrullering av tredje parter. Så om du ønsker tilgang til våre grensesnitt er det bare å ta kontakt med meg på kristine.ursfjord@sparebank1.no.Se gjerne på portalen til en av våre banker for informasjon om tilgang f.eks. her.Denne PSD2-datoen bør du kjenne til was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Kristine Ursfjord

Datadrevet og kundeorientert utvikling, sa du?

Å ha en mer datadrevet og kundeorientert tilnærming til utvikling av digitale tjenester og produkter er stadig viktigere for å henge med i en tøff konkurransesituasjon. Dette er noe som gjerne faller seg naturlig for startups og er en tilnærming som de globale teknologi-gigantene er skremmende gode på. Men hvorfor kan det se ut om dette er spesielt krevende å bli god på for etablerte organisasjoner som vår egen? Og hva legger vi egentlig i datadrevet og kundeorientert utvikling?Bort med antagelseneDet er her snakk om en tilnærming til digital produkt- og tjenesteutvikling hvor man er drevet av innsikt — og ikke antagelser. Eric Rise gjorde denne tilnærmingen kjent gjennom boken The Lean Startup som ble utgitt i 2011 [2]. Tilnærmingen omtales både som eksperimentdrevet utvikling og hyptesedrevet utvikling, samt at UX miljøet har trykket den til sitt bryst som en del av begrepet Lean UX [8]. Videre i denne artikkelen vil jeg omtale denne tilnærmingen som datadrevet og kundeorientert utvikling, som er mer beskrivende for hva vi ønsker å få til.Kort fortalt så handler det om å gjøre innsiktsarbeid og eksperimenter mot sluttkunde som en del av oppgaveløsningen. Dette gjøres for å redusere antagelser man tar både før og underveis i utviklingen. Læringen man tilegner seg ved analysen av, og involveringen fra, kunde skal brukes aktivt til å styre valgene man fortløpende tar.Arbeidet med å realisere noe gjøres veldig forenklet ved hyppige iterasjoner der man bygger noe, man måler hvordan det går og man bruker læringen i videre arbeid med nye iterasjoner. Dette til forskjell fra hva mange tidligere har gjort — bygge masse for så å håpe på det beste.Vi må gå bort fra en tilnærming hvor man bygger masse basert på antagelser for så å håpe på at noen har lyst til å bruke produktet eller tjenestenMålet med å jobbe på denne måten er at innsikt — og ikke antagelser — skal drive utviklingen.Eksempler på eksperimenteringNår et team har denne tilnærmingen har de typisk en veldig klar visjon eller retning for hvor de skal, men erkjenner at de kun har antagelser om hvordan de skal komme seg dit. Teamet setter derfor typisk opp en hypotese og utfordrer seg selv på hvordan de, med minst mulig ressurser, kan få innsikt som sier noe om denne antagelsen er riktig eller gal. Det er bare kreativiteten til teamet som begrenser hvilke type eksperimenter de kan gjøre. Her er noen eksempler vi har sett i noen av våre team:Fiktiv tjeneste / Fake doors: Man lanserer en tjeneste eller funksjonalitet uten at den er (i nærheten av) ferdig. Dette for å tidlig kunne få feedback på hvordan brukere vil ta i bruk tjenesten eller funksjonaliteten. Det som i dag har blitt spleis.no var i starten et lite innovasjonsteam som eksperimenterte med en uferdig tjeneste under fiktivt navn og merkevare.A/B testing: Man presenterer flere ulike varianter av en endring til ulike kundegrupper og måler hvordan de ulike alternativene presterer.Gradvis utrulling: Man starter i det små med å rulle ut endring til en liten del av brukermassen for så å analysere og gjøre forløpende endringer før man slipper på flere.Fake it til you make it I: Lansere en tjeneste tidlig, hvor kunden opplever det som en komplett tjenesten, men som i realiteten krever mye manuell oppfølging i bakkant.Fake it til you make it II: Et fint eksempel er også når et team hos oss skulle lage e-post notifikasjon/kvittering til kundene. Det som for kunde så ut som en automatisk generert kvittering, var i realiteten manuelt laget på enklest mulig måte i ulike varianter til ulike kundegrupper. Man brukte først utviklingstid på å implementere den varianten man visste hadde best effekt (mtp aksjoner kunden gjorde etter å ha mottatt kvitteringen).Spør kunden: I arbeidet med en ny tjeneste eller ny funksjonalitet er man smart med å jobbe inkrementelt hvor man gir sluttkunde mulighet til å gi feedback mellom iterasjonene.Mål adferd: Dagens team har en helt annen mulighet enn tidligere til å bruke data og målinger til å lære om kundenes adferd. Dette brukes aktivt i arbeidet med å stadig og stegvis forbedre løsningene våre.Hvorfor er dette viktig?Selv om vi ofte tror vi vet det — så har vi sjelden på forhånd nok innsikt i hvilke problemer kunden ønsker at vi løser og hvordan vi bør løse de. Dette har resultert i at det opp igjennom årene har vært investert utrolig mye penger i antagelser og gjetting. Dette har igjen ført til utvikling av produkter og tjenester som (I) ingen kunder vil bruke, (II) kundene er misfornøyd med eller (III) som må lages helt på nytt.Ved både å ha langt flere personer i teamene med interesse og fagkunnskap om UX/kundeinnsikt, samt at hele teamet bruker data og innsikt mer aktivt i utviklingen vil vi øke sannsynligheten for at vi lager produkter og tjenester som kundene faktisk vil ha.Når skal man benytte denne tilnærmingen?Vi startet med denne tilnærmingen på noen utvalgte prosjekter som gjerne kan kalles interne startups. Dette var grupper som kunne jobbe relativt isolert og gjerne var uavhengig av øvrig organisasjon når det kommer til arkitektur, teknologivalg, løsninger og andre team. De senere årene har vi tatt inspirasjon og læring fra disse interne startups og forsøkt å ha samme tilnærming på noen av de mer etablerte løsningene og teamene våre. Dette har ført til at vi må ha et mer bevisst forhold til når vi bruke hvilken tilnærming.Teamene våre må kunne jobbe i ulike modus avhengig av hvilke problem de skal løseIllustrasjonen over viser litt grovt sett hvilke ulike modus teamene våre må kunne jobbe på avhengig av hvordan problemet de skal løse.Tradisjonell utvikling: Vi gjør lite av dette, men i enkelte tilfeller har vi sterke avhengigheter til store leveranser fra leverandører eller er avhengig av store datamigreringer for å kunne lansere noe. Det jobbes gjerne smidig internt i utviklingsfasen, men i stort er leveransen vannfall.Smidig utvikling er tilnærmingen de aller fleste teamene våre jobber i til vanlig. Teamene våre har stor frihet til hvordan de velger å jobbe, men de fleste teamene ender opp med en KANBAN variant med enkelte elementer fra Scrum. I denne modusen vet vi gjerne hva vi skal lage.Hypotesedrevet utvikling: Er tilnærmingen som er beskrevet i denne artikkelen. I denne modusen skal vi både finne ut hva vi skal lage — og hvordan vi skal lage det.I vurderingen om hvordan tilnærming man kan bruke er det god hjelp i modeller som Cynefin (uttalles Ki-NEW-in). Modellen er utarbeidet av Dave Snowden beskriver ulike nivåer av kompleksitet og sier at hvilken problemløsningsmetode vi bør velge, avhenger av problemets kompleksitet. Geir Amsjø har skrevet en fin artikkel om rammeverket her.Videre i artikkelen vil vi fokusere på hvordan vi har startet å jobbe mot en mer datadrevet og kundeorientert utvikling. En tidlig erfaring var at det ikke er teamene vi må starte med, heller med rammebetingelsene til teamene.Start med rammebetingelsene til teameneSelv om det kreves både modenhet og kompetanse i teamene for å jobbe etter denne tilnærmingen er vår erfaring at det viktigste er hvilke rammebetingelser som blir gitt til teamene. I arbeidet med de ulike teamene hos SpareBank 1 som helt eller delvis jobber etter denne tilnærmingen er det to ting som dukker opp som viktige for å lykkes:Outcome orientering: Når vi som organisasjon klarer å gi teamene målsetninger og retning — og ikke konkrete bestillinger.Hastighet: Når vi som organisasjon klarer å gi teamene den nødvendige hastigheten de trenger for å kunne gjøre eksperimentering som en del av oppgaveløsningen.Krever store endringer på organisasjonenSom tidligere nevnt er denne tilnærmingen krevende å rigge seg for når man som organisasjon gjerne sitter på både teknisk og organisatorisk historikk. Litt av årsaken til dette er at ulike deler av organisasjonen må endre seg for at man skal kunne få teamene til å agere på denne måten. Ledelse og “forretningssiden” til teamene må endre tankesett for å oppnå outcome-orientering og IT-delen av organisasjonen må endre seg ganske dramatisk for å kunne gi den nødvendige hastigheten til teamene.Hvordan bli outcome-orientert?Det hele starter med at man har kryssfunksjonelle og autonome team. Kryssfunksjonelle ved at man har de fagdisiplinene tilstede i teamet som trengs for å løse det aktuelle problemet, og autonomt ved at gruppen faktisk har mulighet til å løse problemet uten for mye avhengigheter. Diskusjonene om hvor autonomt et team skal være og om det i det hele tatt er mulig at et team er helt autonomt i en kompleks organisasjon er ikke så interessante synes jeg. Det viktige er sette sammen en gruppe med mennesker som sammen kan løse problemet — og fokusere på at denne gruppen har:minst mulig avhengigheter til andre løsninger/teamminst mulig behov for å løpe i organisasjonen etter avklaringerminst mulig behov for å spørre om lov utenfor teametNår man har et velfungerende kryssfunksjonelt team er det forlokkende for organisasjonen å henvende seg til dette teamet å gi de beskjed om akkurat hva de skal lage. Lag denne tjenesten, gjør denne endringen og så videre. På denne måten utnytter du imidlertid ikke teamet særlig bra. Bruk teamene til det de er gode på — nemlig problemløsning.Organisasjonen bør heller sikre at man kan kommunisere en tydelig retning til teamene og følge opp team på målsetninger og hva de faktisk oppnår. Når man er tydelig på målsetninger ovenfor teamene gir man med andre ord teamene et problem å løse, snarere enn ferdig løsninger.Illustrasjon: Hanne Wetland/Netlife fra presentasjonen “Hva er problemet ditt” av Jostein Magnussen/NetlifeKryssfunksjonelle og autonome team som man måler på outcome har imidlertid med seg noen utfordringer som man må løse:Hvordan hindre anarki?Hvordan endre tankesettet til ledere og det vi tradisjonelt har kalt “forretningsiden”.Hvordan hindre anarki?I en organisering med kryssfunksjonelle og autonome team sikter man gjerne på en nettverksorganisering snarere enn en hierarkisk oppbygning av organisasjonen [12]. Om mer av problemløsningen skjer i teamene vil tydelig retning og strukturert arbeid med målsetninger bli viktig. Vi har innsett at vi av den grunn må bli mer strukturert i arbeidet med målsetninger og retning ovenfor teamet — noe vi for tiden jobber mye med i SpareBank 1 Utvikling.Henrik Kniberg har i sitt arbeid hos Spotify jobbet med hvordan man balanserer autonomi og alignment og kommet opp med begrepet alligned autonomi om noe man bør søke å oppnå. Henrik Kniberg / Spotify — Aligned AutonomyHenrik Kniberg har i sitt arbeid hos Spotify jobbet med hvordan man balanserer autonomi og alignment og har gjennom dette kommet opp med begrepet alligned autonomi om noe man bør søke å oppnå.Illustrasjonen og denne videoen beskriver dette godt.Hvordan endre tankesettet til ledere og “forretningsside”?Det høres kanskje lett ut å endre tilnærming i organisasjonen slik at man måler teamene på hva de oppnår og ikke hva de gjør. Men i store organisasjoner har man kanskje både personer, roller og hele avdelinger som tradisjonelt har jobbet med hva som skal gjøres. I en organisasjon med team man ønsker agerer mer datadrevet og kundeorientert, må mye av hva som skal gjøres overlates til teamene. Personer, roller og avdelinger som tidligere har gjort dette må jobbe som en del av teamene eller jobbe på en annen måte enn tidligere. Vår erfaring er at dette gjøres best ved starte begrenset, ved å velge ut et prosjekt, et produkt eller et område hvor man blir enig om at man skal jobbe på en litt annen måte enn tidligere.Hvordan gi teamene nødvendig hastighet?Om eksperimentering mot sluttkunde skal være en del av oppgaveløsningen til teamene er det en forutsetning at teamene har hastighet. SpareBank 1 Utvikling har jobbet med å få opp hastigheten på teamene i mange år nå, fra å ha kvartalsvise releaser av totaliteten, til nå hvor hvert enkelt team i større grad kan styre sin egen leveransehyppighet av applikasjonene innenfor sitt ansvarsområde.Da vi gjorde en brainstorming rundt hvilke tiltak vi har gjort de siste årene for å øke hastigheten vår var det veldig lett å komme opp med en lang liste av tiltak og årsaker. Vi har forsøkt å kategorisere endringene vi har gjort og skal liste opp disse samt si noe om rekkefølgen på endringene vi har gjort.Kategorier av endringer er: - Arkitektur- Organisering- Prosess- MenneskerEndringer på vår arkitektur for å sikre hastighetVi starter i 2012 en reise hvor vi gikk fra en monolittisk arkitektur over til en mer mikrotjenesteorientert arkitektur. Dette er en reise vi fortsatt er på, og målet har vært det samme hele tiden; løse koblinger. Spørsmålet vi hele tiden har stilt er hvordan arkitekturen vår kan støtte oss i arbeidet med å organisere oss i små grupper som jobber med deler av våre løsninger uten å være påvirket av de andre.Vi ønsker team som ikke er satt sammen som et resultat av tekniske løsninger, men heller er satt sammen for å levere på et forretningsmessig eller kundeorientert domene.Endringer på vår organisering for å sikre hastighetEtter at vi fikk en mer fleksibel arkitektur hvor det var mulig å sette grupper av mennesker til å ta ansvar for ulike deler av løsningene våre, ga det oss noen spennende muligheter når det kommer til å jobbe med organisering. Dette arbeidet var sterkt inspirert av Lean og Lean verdikjedeorientering.Hva er det vi egentlig leverer?Hva er våre hovedprosesser og hva er støtteprosesser?Hvordan kan vi optimalisere for hovedprosessene våre og sørge for at vi er mest mulig effektive fra en idè oppstår til den gir verdi til sluttkunde?Vi så tidlig at en av de hyppigste årsakene til problemer og tregheter i organisasjonen vår var overleveringer av ulike sorter. De meste smertefulle overleveringene var:Overleveringer mellom fagdisiplinene design, utvikling og testOverleveringer mellom utvikling og driftOverleveringer mellom prosjekt og forvaltningDet har tatt tid, men for å løse opp i disse problemene har det vært helt naturlig for oss å gjøre en overgang til (I) kryssfunksjonelle team for å løse opp i overleveringer mellom fagdisipliner, (II) fokus på DevOps-praksiser for å løse opp i overleveringer mellom Utvikling og Drift, samt (III) en overgang fra prosjektorientering til produkutviklings-fokus for å fjerne overleveringer mellom prosjekt og forvaltning.Endringer på våre prosesser for å sikre hastighetEn nøkkel for oss har vært å innføre stadig færre sentrale prosesser og retningslinjer for hvordan teamene skal jobbe. Med en arkitektur og organisering som gjør at teamene kan bli mer selvstendige, kan det også være mer opp til det enkelte team å påvirke hvordan de selv jobber mest mulig effektivt.Med for mye sentralstyrte prosesser er vi redd for at vi hindrer mye av den kontinuerlige forbedringen vi er avhengig av for å stadig bli bedre. Vi trenger både personer og team som tør å utfordre hvordan vi jobber og ønsker å bidra til at vi stadig tar nye steg i å bli mer effektive.Her ligger det selvsagt en utfordring i både å fange og å dele erfaringer fra de enkelte teamene slik at vi sammen løfter oss som organisasjon. Vegard Kolbjørnsrud har noen gode poenger i sitt foredrag “Designe smidige og smarte organisasjoner” hvor han påpeker at en organisering i smidige team er bra sted for læring, men at hukommelsen er dårlig.Endringer på hvordan behandler mennesker for å sikre hastighetVi kan gjøre hvilke endringer vi vil på arkitektur, organisering og prosess, men uten at vi har motiverte mennesker som virkelig vil gjøre en innsats for å få dette til å fungere — hjelper det ingen ting. Å være et godt sted som folk vil jobbe starter med at organisasjonen, og særlig ledere, har en grunnleggende tro på at ansatte kommer på jobb for å bidra, lære og levere verdi. Starter organisasjonen med å ha tro på folk, får man ikke ansatte som trenger å gjetes, men får ansatte og team som tenker selv og som utfordrer! Det er bra det!Hva har inspirert oss?Om du har lyst til å dykke dypere i disse temaene har jeg her listet et utvalg bøker og noen foredrag som har vært spesielt inspirerende i arbeidet med å lage en stadig bedre utviklingsorganisasjon.BøkerThe Toyota Way (Jeffrey K. Liker)The Lean Startup (Eric Rise)DevOps Handbook (Gene Kim, Patrick Debois, John Willis, Jez Humble)Accelerate (Nicole Forsgren, Jez Humble, Gene Kim)This is lean (Par Ahlstrom, Niklas Modig)The Age of Agile (Stephen Denning)The Culture Code (Daniel Coyle)Lean UX (Jeff Gothelf, Josh Seiden)Foredrag9. Henrik Kniberg, Spotify Engineering Culture (Smidigkonferansen 2014)10. Jon Kåre Stene, End of Big, hva nå? (Smidigkonferansen 2013)11. Mary Poppendiek, How do teams know what to do (SpareBank 1 2017)Andre kilder12. The fine trademarks of agile organizations13. The agile manifestoDatadrevet og kundeorientert utvikling, sa du? was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jostein Emmerhoff

Beretninger om en varslet katastrofe

“Den dagen de skulle drepe ham, stod Santiago Nasar opp klokken 5.30 om morgenen for å vente på båten som biskopen kom med. Han hadde drømt at han vandret gjennom en kjempefikenskog hvor det falt bløtt duskregn, og et øyeblikk var han lykkelig …”Tittelen og formen på denne posten er inspirert av Gabriel Garcia Marquezs roman “Beretninger om et varslet mord”. Et av de sentrale temaene i denne romanen er mordet på Santiago Nasar, som var forutsett og tilsynelatende hadde hele samfunnets velsignelse, mens det i virkeligheten skjer uten at noen egentlig ville det. Dette er et forsøk på en alternativ last- og ytelsesrapport, for helt ærlig hvor gøy er det egentlig å skrive eller lese slike rapporter?Vi hadde kjørt ml-appen vår i produksjon en liten stund, og alt hadde sett bra ut. Vi var egentlig ganske fornøyde, men de siste dagene hadde vi sett at noe var på gang, minnebruken gjorde noen hopp med jevne mellomrom. Det ble aldri frigitt noe.Minne er en begrenset ressurs og denne utviklingen er ikke bærekraftig. Vi kommer til å gå tom for minne. I oppsettet vårt er det slik at når grensen for tildelt minne nås vil applikasjonen drepes. Heldigvis skal vi ha introdusert et “Jesus”-gen, så de skal gjenoppstå av seg selv. Dette har vi ikke fått testet i produksjon, så da denne situasjonen oppstod hadde vi et perfekt utgangspunkt for å få verifisert at alle deler fungerte som forutsatt.Plutselig må det ha skjedd noe dramatisk, to av instansene får en ustoppelig apetitt på minne. Kan ikke være lenge til nå. Vi finner frem kalkulatoren og regner oss frem til at den første instansen vil eksplodere ca kl 8 fredag kveld. Vi kjøper inn popcorn og sitter klare.Men, vi har tabbet oss ut. I overvåkningsgrafene våre plotter vi minnebruken i GB, mens tildelt minne er GiB. Katastrofen er utsatt! Her er første læringspunkt, sørg for å rapportere i samme skala som man opererer. Spiste popcornet likevel.Katastrofen er uungåelig, og klokken 23 lørdag kveld skjer det. Og ingen får det egentlig med seg. Før på mandag. Og da er jo alt bare fryd og gammen. Appen har gjenoppstått som den skulle og den spiser minne som tidligere.Løsningen er verifisert, trafikken ble rutet til en av de andre instansene og kundene merket ingenting.Det er et kjent ordtak som sier at Python tar det minne den kan få tak i, og frigir bare til seg selv. Vi forventer altså en svakt økende minnebruk. Dette er greit å ha med seg og betyr at du ikke nødvendigvis har gjort noe feil i applikasjonen din.Vi hadde benyttet biblioteket functools til å håndtere trådene i applikasjonen. Våre undersøkelser tydet på at problemet lå i hvordan vi brukte dette biblioteket. Vi byttet til standard Python trådhåndtering og da ble det rimelig klart hvor problemet var:Minnebruk ved ulike trådhåndteringsbibliotekerFor å se hvordan forskjellige modellstørrelser påvirker minne- og CPU-bruk trente vi først opp modeller på forskjellige mengder treningsdata. Modellene ble brukt med et oppsett som skulle simulere produksjon.Maksimalt påtrykk som er målt i produksjon er 600 request/minutt med et snitt på 80 elementer/request. På dette grunnlaget ble det generert en statisk request med 80 elementer som ble kjørt i to tråder. Request-delay ble satt til 200 ms, som gir 2x5 request/sekund = 600 req/min totalt.Tallene i tabellen under ble plukket ut fra top etter at tallene hadde stabilisert seg etter et par kjøringer.Her ser vi flere ting:Ved bruk av veldig runde tall — modellstørrelsen dobles for hver 4x økning av treningssettetMinneforbruk korrelerer bra med størrelsen på modellene. Den er ikke helt lineær, stigningen er avtagende (innslag av logaritme).CPU-bruk øker ikke veldig mye selv om modellstørrelsen øker betraktelig.Responstid ligger på snitt 3ms siden CPU holder seg godt under 100%Alt dette hadde vi gjort før instansen gikk i luften, vi hadde også en ny versjon klar som fikset problemet. Kjøremiljøet vårt er Kubernetes/OpenShift og i løpet av prosessen endte vi også opp med å gjøre endringer i hvordan minne og CPU tildeles.Aller helst skulle vi sett at problemet ikke hadde oppstått. Når det først skjedde har det, at vi lot katastrofen inntreffe, gjort at vi totalt sett har en bedre løsning nå enn om vi hadde rettet feilen med en gang vi oppdaget den.Beretninger om en varslet katastrofe was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Jan Erik Modal

Fra ti om året til ti om dagen

Bilde fra chuttersnap på UnsplashDet er bare få år siden vi hadde ti nettbankreleaser i året. Nå har vi innimellom ti releaser på forskjellige deler av nett- og mobilbanken på samme dag.Har du tenkt på at evnen til å endre raskt, er en forutsetning for å kunne drive med datadrevet utvikling?@Somaiah Nymoen Kumbera har skrevet en bloggpost om reisen vi er på her.Fra ti om året til ti om dagen 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

Hendelsedrevet læring i SpareBank 1

Erfaringer fra to år med post mortemDu har trolig kjent på smerten som oppstår når noe du jobber med, og har ansvaret for, går galt. Det gjør vondt, og instinktet er gjerne å legge det uheldige bak seg så raskt og stille som mulig. Samtidig er erfaringer tilknyttet feil og uheldige hendelser en gullgruve for å forbedre måten det jobbes på. Gjennom dette kan erfaringene være med å forhindre at feil inntreffer på nytt.SpareBank 1 jobber med pengene til folk, og løsningene våre regnes som kritisk infrastruktur i Norge. Ved hendelser av en viss karakter og omfang skal det derfor utarbeides en rapport til Finanstilsynet. Dette er det gode rutiner for i SpareBank 1, og arbeidet ble tidligere håndtert av en fast rolle i utviklingsteamene.Vi ønsket å dra mer nytte av potensialet knyttet til læring ved slike hendelser. Spesielt nysgjerrige var vi på hvordan organisasjonen bedre kunne legge til rette for læring i etterkant av hendelser, på en trygg og positiv måte for alle involverte. Bakgrunnen var betydelig varians i organisasjonen i forbindelse med involvering, analyse og evne til å gjennomføre tiltak for forbedring, tilknyttet feil og uønskede hendelser.Test av post mortemMot slutten av 2016 bestemte vi oss derfor for å teste ut konseptet post mortem på feil og hendelser vi opplevde i produksjon. Kort fortalt er en post mortem en prosess der alle involverte går gjennom hendelsesforløpet sammen, for å etablere en tidslinje for hva som skjedde når, forstå hva som gikk galt, og identifisere rotårsaker til hvorfor dette inntraff. Med utgangspunkt i denne innsikten diskuterer man så hvilke tiltak som skal testes ut for å løse problemet. Arbeidet skjer innenfor en ramme der man ikke snakker om hvem som har skylden for det som har skjedd. Psykologisk trygghet er en viktig forutsetning for å lykkes med dette. En vellykket post mortem vil resultere i læring innenfor en positiv ramme, på bakgrunn av at noe ikke gikk som man ønsket. Den setter oss i stand til å identifisere relevante tiltak for forbedring med utgangspunkt i reelle rotårsaker, og over tid styrkes kvaliteten på det vi leverer. PagerDuty beskriver hendelse-post mortem nærmere her.Kultur er viktigHvordan organisasjonen reagerer på en hendelse, betyr mye for hvilke rammer man jobber innenfor. I boken Accelerate omtales Dr. Ron Westrum sin “typology of organizational culture”, som beskriver tre typer organisasjoner (Westrum 2014):Pathological organisations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.Bureaucratic organisations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book — their book.Generative organisations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.Westrums Topology of Organizational Culture, hentet fra boken “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”.Å være klar over hvor man befinner seg i denne modellen er nyttig for å forstå forventningene folk tar med seg inn i en post mortem. Vil man fritt dele informasjon med lave skuldre eller vil man bekymre seg for eventuelle konsekvenser av det som blir sagt? Funnene fra en fem år lang studie utført av Google, der man undersøkte hva som skapte de beste teamene, støtter opp om dette. I artikkelen “What Google Learned From Its Quest to Build the Perfect Team” i New York Times Magazine fra februar 2016 skriver Charles Duhigg: “Google’s data indicated that psychological safety, more than anything else, was critical to making a team work.”Post mortem som standardPå bakgrunn av positive erfaringer fra forsøksperioden standardiserte vi fra begynnelsen av 2017 på post mortem for alle hendelser i produksjon av en viss karakter. For å gjøre det enkelt å komme i gang, ble retningslinjer og maler tilrettelagt og gjort lett tilgjengelig for utviklingsteamene. I skrivende stund er det 19 team i operasjonen. Videre var personer med erfaring klare til å bistå teamene ved oppstarten. De passet særlig på at kjørereglene for post mortem var godt kjent og ble etterlevd.Standardiseringen sikret prioritet for gjennomføring av post mortem. En fellesarena ble dermed skapt for dialog, refleksjon og læring, på tvers av organisasjonen. Det ble raskt etablerte et mønster der en feilsituasjon først blir håndtert med fullt fokus (som tidligere). Kort tid etter gjennomføres post mortem mens hendelsen er relativt fersk.Erfaringer med post mortemPer i dag er det gjennomført 37 post mortems. Tabellen under viser summen av post mortems gjennomført i 2017 og 2018, fordelt på årets måneder. Her skiller juli måned skiller seg ut, med null post mortem. Trolig henger dette sammen med færre endringer under sommerperioden. November var måneden med flest post mortems.Summen av post mortems gjennomført i 2017 og 2018, fordelt på måneder.Første gang man utfører en post mortem oppleves det gjerne uvant, og det kan være nyttig med to personer som samarbeider om å fasilitere gjennomføringen. Vi erfarte også at det var lurt å starte med en gjennomgang av formålet og kjørereglene for arbeidet som skulle finne sted. Videre var støtte fra noen med erfaring gunstig, særlig for å sikre fokus på skyldfri dialog. Med erfaring blir det mer rutinepreget å gjennomføre en post mortem. Dette har resultert i god flyt og begrenset tidsbruk.I tillegg har det vist seg viktig å passe ekstra på at alle involverte ved en hendelse inviteres og oppfordres til å delta. Vi har sett stor verdi av å komme sammen utenfor gruppene man jobber i det daglige, som utvikling, drift og kundestøtte. Å samles slik “på tvers av siloer” fører til at en større del av totalbildet ved hendelser fremkommer, samtidig som relasjoner og tillit bygges mellom personer som ellers sjelden møtes.Som del av en post mortem la vi etterhvert til en vurdering av egnede arenaer for deling av innsikt, som faggrupper, demo-sesjoner, tavlemøter mm. Dette har styrket vår delingskultur, og økt fokus på deling av læring med resten av organisasjonen.En annen endring som har funnet sted, er at mye av arbeidet med å ta frem rapporter til Finanstilsynet ble flyttet fra en fast rolle og over til teamet. Erfaring med post mortem bidro til å forberede teamene på denne endringen.Post mortem har blitt del av verktøykassen for å styrke vår evne til å lære, og brukes nå tidvis mer enn opprinnelig tiltenkt. Et eksempel på dette er teamet som bestemte seg for at i deres arbeid for å sikre rett kvalitet, skulle alle feil, som oppstod i en forhåndsdefinert periode, resultere i post mortem. Et annet team benyttet post mortem for å jobbe med prosessforbedring i en situasjon der det tok lang tid å få påbegynt arbeid satt i produksjon, uten at dette var relatert til noen spesifikk hendelse.Flere mulige bruksområderDet har så langt ikke vært like naturlig for oss å bruke post mortem for å regulere kontraktfestede leverandørforhold utenfor organisasjonen. Kanskje ligger det noe spennende i vente her, der post mortem med åpen dialog mellom gode samarbeidspartnere kan videreutvikle et fundament der tilliten mellom partene allerede er høy? Vi kan trolig også dra nytte av å legge bedre til rette for søk og analyse på totalen av erfaringer fra en voksende post mortem-base. Et annet område det har vært knyttet en del interesse til, er å benytte post mortem for å styrke læringsevnen på ting som går bra, og dermed bygge videre på gode prestasjoner gjennom positiv forsterkning.OppsummeringPost mortem har fungert godt for oss og har vist seg å være et nyttig verktøy for trygg læring og strukturert problemløsning etter en hendelse. Vi anbefaler derfor å teste ut post mortem som en arena der alle involverte samles for læring kort tid etter at en hendelse er tatt hånd om. For at post mortem skal fungere godt, er psykologisk trygghet sentralt. Jobber du i en organisasjon der dette er på plass, er forutsetningene for å kunne lykkes med post mortem gode.Hendelsedrevet læring i SpareBank 1 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

@sparebank1design og @sparebank1utvikler på Instagram