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

300 applications upgraded to Java 17 in one commit. The day before vacation. The power of monorepo!

It’s been six years since we decided to try a monorepo aproach for our microservices. Today we have over 300 applications in this monorepo. The applications are generated using templates. We refer to these applications as our “golden path” applications. All applications use Spring Boot and React and live in the same Git repository.Friday afternoon, the day before Easter holiday, we upgraded all monorepo applications from Java 11 to Java 17. This was done in one commit and at rest. The next day I was off to the Canary Islands, and the rest of the team to the mountains. In this article I will share why this major change to more than 300 applications did not turn out to be a project in itself.15000 tests to the rescueBut why not wait to after the holiday? The short answer is; why wait when you can do it today. All our applications have unit and integration tests. In the monorepo as a whole we have more than 15000 tests. When all of these run green, we are pretty sure that the change meets the required quality level. It is also important to note that we do not automatically deploy the applications to production. When we start doing this, it might be that we will not do such a change the day before vacation.Sharing code is sharing knowledge. Local improvments in one team become global improvements for the whole company if this is done right. This is also one of the main benefits with using a monorepo.One team to boost productivityBut let us travel to the Canary Islands. The island is lovely, especially because of the climate. The temperature in Easter is perfect for us Norwegians after a dark and long cold winter. One thing you dont’t want to do, is ruin the long awaited trip because of stress at work. Upgrading 300 applications from Java 11 to Java 17 can cause such stress. To optimize the developer efficiency at SpareBank 1, we have established a Developer Experience (DevEx) team. I am a part of this team, and we took on this upgrade task. The challenges with such an upgrade are much the same for all of our 300 applications. The DevEx team can gain expert knowledge when it comes to such an upgrade. An alternative approach would be to let every team do the upgrade themselves. That would certainly work too, but time spent on this task could have been used on building new features (opportunity cost). As teams have different goals, this upgrade might not be prioritized, and therefore it would have taken longer time to finish.Handling different technologies have a cost. This cost is often invisible. Having a standardized way of making applications makes it easy to switch teams, share code and knowlegde, and to make tooling. Tooling includes local build scripts and shared build pipeline. Not having to handle different Java version is just one benefit of marching in step.Dependencies can cause frustrationsOur applications share code at compile time. This code is what we refer to as our libraries. The library code is not versioned. All application is “on head” (using the latest library/shared code). This is an important principle for us, and a common technique when working with monorepos. This means that all changes in the library code must be compatible with all application in the monorepo. It is not allways obvious why this is a good thing. For a developer that wants his/her feature in production as fast as possible, it may seem daunting to have to change code in other teams’ applications. But one thing we have learned over the last 15 years is that this is for the best for SpareBank 1 as a whole. When using mulitrepo with versioned shared dependencies we ended up with what is often refered to as “version hell”. Application 1 depends on Library A. Library A depends on Library B. If you needed to do a change in Library B, and you needed to get it in to production fast, you had to build Library B. Then you would bump the version in Library B, build that library, and you probably understand, do the same thing for Library A. It did not stop there. All application that used Library A had to be bumped and built. But wait, some of the applications are on an old version of Library A. Nobody remembers how to refactor these appliactions to make them work with Library A. If that is not enough, you have to make sure your third party dependencies are in sync. What happens then? The world don’t stop spinning. The trip to the Canary Islands is tomorrow. And here you are, in a middle of a “dependency hell”.Versioning in a multirepo with a wait period for each pull requestIn a monorepo a pull request will show all changes needed for your feature. Also if you need to do library changes in shared code. This makes it easier to do a review because you avoid the need to also review the library change in a separate repository.Local discoveries are converted into global improvementsAll code in the monorepo is easily accesible to all developers. They have quick access to the code from their IDE. The can copy it, be inspired or refactor it as library code. This is knowledge sharing. One good example is when one team switched from Webpack to Vite, it did not take many weeks before several other teams did the same. Another example is me coding a new feature. The probability is high that somebody else have coded something quite similar.Deleting code increases your velocityDevelopers are problem solvers and coding is one tool used to solve problems. Maintaing code has a cost. Often this cost is higher than writing the code. To save money we need to be able to delete code. In a monorepo where all code is on head, your IDE can show you all dependencies. Should you miss a dependency, the build will break for the applications affected by the change. Deleting code is also important, as reducing mass will improve the speed in the development teams. When doing multi-repo we rearly deleted code. We just deprecated it. Today we actually delete it. Over time this is likely to have a significant impact on the mass of code we need to take care of.Peace of mind and happinessSo, how can we go on vacation with no stress when doing a big refactoring the same day the vacation starts? My answer is the confidence you get when all applications has been built and all tests have passed. Our pipeline also deploys all applications to our Kubernetes test-enviroment. This gives us confidence that the images has been built ok, and that the configuration seems ok. I say “seems ok” beacuse as we don’t automaticly deploy to production (yet) we can not be 100% sure. But sure enough that we can travel with our minds at the right place.Want to try monorepo?Monorepos are not for everyone. You need a mature development organization that is able to build the necessary tools and understand the value of a monorepo. It is not obvious to everyone that it is more efficient for the company as a whole if a platform team makes changes to other teams’ applications. Most people understand the value of having all applications always use the latest shared code, but not everyone sees why it often does not work to let teams themselves take care of this. Teams may have other priorities than updating to the latest version of the shared code. And the cognitive load that teams are exposed to, increases as they must understand all changes in infrastructure and shared code.If you still want to try the monorepo way, I wish you good luck! Feel free to contact me if you need someone to talk to before or during your monorepo journey.ReferencesVelocity defeats itself. Get acceleration instead https://jessitron.com/2022/12/22/velocity-defeats-itself-get-acceleration-instead/Monorepo med Git og Maven — hvordan lære gamle hunder nye triks (in Norwegian) https://2019.javazone.no/program/eb8bc683-ceaf-4baf-82ee-d7b72960a955What is a Monorepo, Really? https://www.codesimplicity.com/post/what-is-a-monorepo-really/300 applications upgraded to Java 17 in one commit. The day before vacation. The power of monorepo! 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

Gir verdier verdi?

Høsten 2018 fikk vi egen Utvikleravdeling i SpareBank 1 Utvikling.Da vi fikk muligheten til å lage vår egen avdeling, var det viktig for oss å være åpne om lønnsfastsettelse. I SpareBank 1 Utvikling er det regulerte rammer for lønn. Innenfor disse rammene er det også rom for personlige tillegg. Men hva skal en gjøre for å få disse tilleggene? Dette ville vi gjøre åpent og synlig for alle.God stemning på kontoret.Hos oss har vi i mange år kjørt en modell hvor utviklere har personalansvar for utviklere. Dermed visste vi allerede hvordan vi i praksis gjør lønnsvurderingene og hva vi vektlegger. Det handlet om å få det synlig og lett å forstå.Vi lagde et forslag hvor vi satte opp verdiene, egenskapene og aktivitetene vi setter pris på. Deretter hadde vi arbeidsmøter med hele avdelingen, for å tilpasse innholdet til noe vi alle var enige om, og la det ut på internnettet. Nå var det endelig tydelig for alle hva som påvirket de personlige lønnstilleggene.KoronaFire måneder etter at vi hadde fått på plass verdiene våre, kom Korona. Det gjorde at kulturbyggingen vår ble vanskeliggjort, både av at vi måtte lære oss å jobbe på hjemmekontor, og det at vi faktisk var på hjemmekontor. Samtidig fortsatte vi å ansette, slik at vi ble flere. Verdiene våre var viktige, og ble brukt aktivt ifm lønnvurderingene. Vi tok dem også fram når det var hensiktsmessig å vise til dem, men vi gjorde ikke en god nok jobb med å tydeliggjøre dem i hverdagen på hjemmekontoret.Bedre sammenI løpet av Korona definerte SpareBank 1 Utvikling verdiene som gjelder for alle som jobber hos oss. De ble mer generelle enn utviklerverdiene vi hadde tatt fram, men handlet om det samme. De var, og er fortsattVi vil hverandre velVi griper nye muligheterVi dyrker og deler kompetanseVi leverer best når alle føler seg verdifulleog går under samlebetegnelsen Bedre Sammen.Bedre Sammen plakaten vår.Henger verdiene fortsatt på greip?Da vi endelig var ute av koronapandemien i fjor høst, følte vi at vi trengte en oppfrisking av utviklerkultur- og verdiarbeidet vårt. Mange nye hadde startet hos oss i perioden, og vi visste at vi ikke hadde jobbet nok med å synligjøre verdiene våre da vi var på hjemmekontor.Vi fikk med oss fem av utviklerne som hadde startet i koronaperioden, og lot dem også få jobbe fram endringer og forslag til forbedringer i verdioppsettet. Resultatet av dette arbeidet ble en vesentlig forenkling. Vi så at vi kunne bruke materialet vi hadde tatt fram til å svare på to spørsmål for hver verdi eller egenskap:Hvorfor det? (*)Hvordan gjør jeg det? (**)Her er verdiene og egenskapene våre:Vær åpen og forståelsesfullJobb sammenDel kunnskapen din og tiden din med andreVær nysjerrigGjør ting bedre hele tidenTenk helhetligVis initiativVi tar fram en eller flere av disse verdiene jevnlig på avdelingsmøtene våre. Vi forteller om hvorfor de er viktige for oss, og ikke minst hvordan vi gjennom konkrete aktiviteter kan oppleve kraften i verdiene selv.Verdiene våre er med og skaper den utviklerkulturen vi vil ha.(*) Boka Start With Why for hvorfor det er viktig å starte med hvorfor.(**) Boka Switch for hvorfor det er viktig å være konkret på hvordan.Gir verdier verdi? 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

Skal teknologi brukes av alle, må den utvikles av alle

I SpareBank 1 Utvikling er vi vårt ansvar bevisst: oppdraget vårt er å lage de beste løsningene for alle våre én million kunder. Én million mennesker med ulik bakgrunn og kompetanse — og dermed svært ulike behov.En vrien oppgave, tenker kanskje noen. Men jeg mener at SpareBank 1 er på god vei og at en av nøklene ligger i mangfold. Et utviklingsmiljø bestående av et bredt mangfold, belønner oss med innovasjon og løsninger som treffer bedre og mer relevant. I anledning kvinnedagen vil jeg særlig belyse behovet for flere kvinnelige utviklere.Alle relevante perspektiverI dag er det stor overvekt av mannlige utviklere i Norge. En utpreget homogen gruppe er lite bærekraftig for å utvikle de beste teknologiske løsningene. Det er derfor vi i SpareBank 1 Utvikling sier: Skal teknologi brukes av alle, må den utvikles av alle.Utvikling av systemer og løsninger skal bidra til at samfunnet og hverdagen vår blir mer effektiv, lønnsom, bærekraftig, innovativ, enklere, smartere og mer rettferdig for alle. For å løse dette, trenger vi alle relevante perspektiver.SpareBank 1 Utvikling er et likestilt selskap. Vi har selvsagt likelønn, mange kvinnelige ansatte og andelen kvinnelige ledere i selskapet gjenspeiler den generelle fordelingen mellom kjønnene. Men vi har virkelig et ønske om å også få tak i flere kvinnelige utviklere.Strategisk og langsiktig satsingVi er altså ikke helt i mål med våre ambisjoner, og vi kommer ikke til å slå oss på brystet riktig ennå. Vi må rett og slett ta noen aktive grep for å øke rekrutteringen av kvinnelige utviklere. Dette jobber vi strategisk og langsiktig med. Målet er å tiltrekke oss en samling mennesker som sammen har best mulige forutsetninger for å lage gode løsninger for alle.For å nå målet har vi blant annet mangfoldsforum i SpareBank 1 Utvikling og vi er med på å arrangere Girl Tech Fest, en teknologifest for jenter i 5. klasse. Dette tror vi er noen gode steg på veien til å utvikle enda bedre teknologi fremover. Vi er også alltid på jakt etter innspill til hvordan vi kan få et enda mer mangfoldig utviklingsmiljø.En oppfordring til alleSå vil jeg gjerne komme med en oppfordring på selveste kvinnedagen. La oss fremsnakke teknologiske fag i samtalen med unge jenter, ungdom på vei inn i studier og andre som har perspektiver vi trenger — nettopp for å kunne lage de aller beste løsningene, for absolutt alle.Gratulerer med kvinnedagen!Skal teknologi brukes av alle, må den utvikles av alle was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Espen Kjølberg

Multi-tenant and hybrid DNS with Azure Private DNS

This article covers how The Azure platform team handles registering and resolving of Azure Private Endpoints in a multi-tenant and hybrid DNS setup.If you find yourself in a situation where you need to handle multi-tenant Domain Name System (DNS) together with an on-premises environment, look no further. In this article I’m writing how we did multi-tenant and hybrid DNS at SpareBank 1, one of Norway’s largest financial institutions.This article is one of several articles we are writing about our brand new Azure platform we’re calling Eunomia at SpareBank 1. In simple terms we’re creating a multi-tenant platform to fit the needs of the alliance.We did a presentation at Ignite 2022, watch it here: Spotlight on Norway | CLC08 — YouTubeShort background introductionSpareBank 1 is an alliance of 13 banks and over 40 product companies. As individual legal entities, they choose themselves whether to collaborate in key areas such as IT operations and sytem development.A large number of these banks and companies share an on-premises Active Directory environment. On-premises AD uses AD Connect to syncronise users and groups to their own Azure AD tenant.The challengeI’m not going into why there are 13 tenants and workloads running in each tenant, which means we have this requirement for cross-tenant and hybrid dns resolve.The challenge is to support DNS across the whole architecture. DNS resolution needs to work in each tenant, from on-premises to Azure workloads (Key Vault, Storage, Web apps etc.) running in each tenant as well as internal applications on-premises.This wouldn’t be a challenge if we could leverage public DNS for everything, but we need to keep everything on a private network. Where applicable, developers must use Azure Private Link on Azure PaaS services that support it. This is a big challenge!Requirements:Resolve private endpoints FQDN’s in any tenant from any tenant and on-premisesAutomate registering of Private Endpoint FQDN’s to a an Azure Private DNS ZonesTake a look at this figure to understand the challenge a bit more.Single tenant DNSAs you may understand from the figure above, DNS in this setting is a bit challenging. But let’s look at how we would do DNS in a single tenant.Azure has a PaaS service called Azure Private DNS Zones. That is perfect for our use case. We can create the DNS zones we need and add records that resolves to the ip’s of the workloads we have.Using Azure Policy we could do automatic registration of Private Endpoints Fully Qualified Domain Names (FQDN). This means that developers would create their private endpoints and after a couple of minutes the FQDN’s would be automatically registered in it’s associated private dns zone.The figure below shows a simple architecture on how to do DNS in single tenant.Single tenant automatic registration of Private Endpoint FQDN’sCustom DNS in vnet’s would point to the central dns-servers hosted in the HUB vnet.The dns-servers(in HUB-vnet) would forward all DNS request to Azure’s own DNS service in it’s vnet. Azure Recursive resolver will take the DNS request and try to resolve it.Since the Azure Private DNS Zones are linked to the HUB vnet the resolver can look up records in those zones.The magic sauce here is actually the Azure Recursive Resolver which will look up in all available sources for the record.The automatic registration of a private endpoint FQDN is accomplished by using Azure Policy. The Azure Policy would target all resources of type Microsoft.Network/privateEndpoints and deploy a resource of type Microsoft.Network/privateEndpoints/privateDnsZoneGroups on the private endpoint.Microsoft has several resources available to create a deployment like this. See sources here:Private Link and DNS integration at scale — Cloud Adoption Framework | Microsoft LearnIn the next section this architecture is expanded to work across multiple tenants together with an on-premises environment.Multi-tenant and hybrid DNSIn this section I will explain in detail how we did multi-tenant and hybrid DNS at SpareBank 1.HUB and spoke tenantsYou have probably heard of hub and spoke topology related to Azure networking. We’re expanding on that where we introduce the concept of hub-tenant and spoke-tenants.In the maze of all our tenants there is only one HUB-tenant and all other tenants are spoke-tenants. The HUB-tenant is used to centralize some services that can be consumed by the spoke tenants, such as DNS.Azure Private DNS ZonesWe’re using Azure Private DNS Zones to host records for all of our private endpoints. We deploy all the zones we need/for all the PaaS services we are using.In the figure below you can see we have a subscription called core-con, this is where we host all connectivity services, such as Azure Firewall, Azure vwan, DNS, VPN to on-premises and third-party tenants. These workloads is only necessary in the HUB-tenant. Vnet’s in spoke tenants is peered to the HUB vnet.We host the Azure Private DNS Zones in the resource group hub-core-con-pdns-nea-rg; The acronyms stands for:hub — core — connectivity — private dns — norway east — resource groupThe private dns zones is vnet-linked to our virtual network hub-core-con-net-nea-vnet in resource group hub-core-con-net-nea-rg.Private Link and DNS registration in a multi-tenant environmentIn this section I’ll go through how we manage the lifecycle of DNS records for private endpoints. The lifecycle must ensure that records are automatically created in the matching private DNS zone for the service being created. Since we have our Azure Private DNS Zones in our HUB-tenant we need a way to write spoke-tenant’s private endpoints zone configuration to our centralised private dns zones.Writing a private endpoint zone configuration to a private DNS zone is fairly straight forward in a single tenant setup. We did that in the single tenant section above by leveraging Azure Policy to do the work for us. Take a look at the figure below to get an idea of what we want to accomplish and keep in mind how we leveraged Azure Policy earlier to write the DNS zone configuration of a private endpoint to a private dns zone.In the single tenant design the policy assignment would deploy the zone configuration in the same tenant. In this multi-tenant design we need each spoke tenant to do the same as a single tenant, but instead of deploying to private dns zones in the same tenant, we need it to deploy to our centralised private dns zones in our HUB-tenant.Reverse Azure Lighthouse conceptYou have probably heard about Azure Lighthouse. It allows an identity in a managing tenant to have Azure Role Based Access Control(rbac) permissions in a delegated tenant. So what if we use this and let all the spoke tenants become a managing tenant for our HUB-tenant? But with limited delegated permissions.For an identity to write zone configuration to a private DNS zone it needs the RBAC permission Private DNS Zone Contributor. We can create a managed identity in each spoke tenant and assign the identity Private DNS Zone Contributor on the resource group where our Private DNS Zones is in the HUB-tenant using our reverse Lighthouse concept. The figure below shows the reverse lighthouse concept.Reverse lighthouse conceptThe last, but most important, part is how we can now leverage Azure Policy in each spoke tenant to automatically register all Azure Private Endpoints fqdn’s in the HUB Private DNS Zones.Azure Policy — Deploy if not exist — cross tenantWe deploy our Register private dns Azure Policy Definition to each spoke tenant and create assignments for each PaaS resource/groupid/region.PolicyRule "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Network/privateEndpoints" }, { "count": { "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]", "where": { "allOf": [ { "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId", "contains": "[parameters('privateLinkServiceId')]" }, { "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]", "equals": "[parameters('privateEndpointGroupId')]" } ] } }, "greaterOrEquals": 1 } ] },The policy deploys if not exists (DINE) a resource of type Microsoft.Network/privateEndpoints/privateDnsZoneGroups. "resources": [ { "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]", "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups", "apiVersion": "2022-05-01", "location": "[parameters('location')]", "properties": { "privateDnsZoneConfigs": [ { "name": "privateDnsZone", "properties": { "privateDnsZoneId": "[parameters('privateDnsZoneId')]" } } ] } } ]Because our managed identity in each spoke tenant has Private DNS Zone Contributor rbac permission to the hub-tenant we only need to reference the resource id to the Azure Private DNS Zone in the policy assignment.Screenshot of a Azure policy Assignment for privatelink.vaultcore.azure.netDNS ConfigurationThe figure below shows an overview on how DNS is configured on-premises, in spoke vnets (cross-tenant) and on HUB DNS server.When setting up Conditional Forwarders from on-premises to the DNS server in Azure I recommend starting with just a few zones that you are currently using. Don’t configure the whole list of public DNS zones which Microsoft lists here: Azure Private Endpoint DNS configuration | Microsoft LearnClosing NotesWith the configuration the benefits of the cloud are clear. Set up any PaaS service with private link across any of the multiple tenants, and we have full automation (including lifecycle management) for that private endpoint’s DNS records. Developers do not need to think about it when creating their systems, and it is also very low overhead for the Azure platform team. This works brilliantly for us!During the design and deployment of this the Azure DNS Private Resolver was still in preview. We’re looking into moving away from VMs to the PaaS solution. The PaaS solution will contribute greatly in achieving a more resilient solution.We’ve had this in production for a couple of months now and we’re experiencing a couple of challenges:Azure Static Web App has a partition id in its private dns zone name. It is not documented which partition id’s this can be. This makes it difficult to pre-provision the Private DNS zones for this and also create policy assignment to target the correct private dns zone. See issue #101133 and #99388Azure Machine Learning workspace creates several records utlizing two Private DNS Zones. Our Azure Policy only handle one of the zones and leaves us to handle the second manually. With some additional work on the policy I’m sure it’s possible to make it work. We have published an Github Issue on it here: #99388Multi-tenant and hybrid DNS with Azure Private DNS was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Joakim Ellestad

Coachende ledelse med fem små spørsmål

I SpareBank 1 Utvikling bruker vi gjerne strukturert problemløsning når en utfordring ikke er rett frem å løse. A3 er en slik problemløsningsmetode som hjelper oss til å få felles innsikt i problemet før vi jobber med løsning, og det har gitt gunstige resultater hos oss. På ledernivå har vi imidlertid erfart en utfordring med A3-arbeid. I en hektisk hverdag kan det være krevende for lederen å følge opp forbedringsinitiativ man selv har prioritert oppstart av. Varierende grad av dialog og forankring underveis blir da et hinder for fart og kvalitet i problemløsningen, der A3-teamet kan ende opp med å kun sporadisk rapportere status til lederen. Vi bestemte oss for å teste om dette mønsteret kunne endres for skape bedre flyt i A3-arbeidet. Ambisjonen var å stimulere til økt lederinvolvering mens forbedringsarbeid pågår og unngå for stor avstand ved at man går hver til sitt etter oppstarten. Valget falt på et eksperiment der A3-problemløsning ble kombinert med samtaleverktøyet Coaching Kata.Hva er Coaching Kata?En kata er en sekvens av steg som repeteres mange ganger, til mønsteret er automatisert og kan utføres som en enhet, uten å måtte tenke over hvert enkelt steg. Kata er kjent fra bl.a. kampsport og musikkøvelser.“the karate kids” by Orly Orlyson is licensed under CC BY 2.0.Mike Rother beskriver i boken Toyota Kata to slike mønstre som hører sammen: Improvement Kata og Coaching Kata.Improvement Kata er en forbedringsmetodikk med fire steg: 1) Forstå målet, 2) få oversikt over nåsituasjonen, 3) sett et kortsiktig, tidfestet mål (target condition), og 4) utfør eksperimenter for å fjerne hindringer og bevege deg i retning av target condition. Når target condition er nådd, kan man reevaluere nåsituasjonen og sette et nytt target condition. Det er viktig å innse at det finnes en grense for kunnskapen vi har i dag, vi kan bare se et lite stykke fram. Eksperimentene gjør at vi lærer, og gradvis ser og forstår mer av veien vi må gå for å komme frem til målet. Bruk av dette mønsteret trener inn den vitenskapelige metoden for problemløsning.Coaching Kata er lederens motpart til Improvement Kata. Den består av et lite sett spørsmål som lederen bruker for å hjelpe den som driver med Improvement Kata, og forsterker mønsteret av vitenskapelig tenkning. Spørsmålene printes gjerne ut på et lite kort med hovedspørsmålene på den ene siden og refleksjonsspørsmålene på den andre.Kilde: Toyota Kata Practice GuideLederen starter med å stille spørsmål 1 og 2, og snur deretter kortet og går gjennom de fire refleksjonsspørsmålene, før man snur kortet tilbake for å gå gjennom resten. Dette mønsteret vil føles unaturlig i starten, både for lederen og den som blir coachet. Men ved å holde seg til mønsteret (kataen) mange nok ganger, vil flyten etterhvert bli naturlig for begge parter. Når mønsteret er automatisert, kan man begynne å tilpasse det til situasjonen fra gang til gang, og få enda mer verdi ut av disse korte samtalene.“Those who have seen The Karate Kid have seen kata in practice; those who have watched a jazz band play have seen the results.”- Jeffrey Liker, How the Toyota Way and Toyota Kata Fit TogetherCoaching Kata på A3-arbeidI et A3-problemløsningsarbeid er det flere planleggingssteg før man kommer fram til beskrivelsen av en ønsket fremtidig situasjon (target condition): Man må forstå problemet godt, kartlegge nåsituasjonen, spisse problemstillingen ned til den delen som skal løses først og kartlegge rotårsaker, før man er klar til å se på forslag til løsninger.Kilde: Toyota Kata Practice GuideUnderveis i planleggingsfasen er det noen faste delmål som er svar på Coaching Kata-spørsmål nr. 1 (“Hva er delmålet du jobber mot nå?”):Enighet om formuleringen av “observert problem”, dvs. hva er problemet, hvem er det et problem for, hva er konsekvensene av problemet og hvor stort er det?Enighet om hvordan problemet skal spisses og mål for forbedringen, dvs. hvilken del av problemet er det vi skal løse, og hvor stor forbedring ønsker vi å oppnå?Enighet om hypotese for fremtidig situasjon, dvs. hva er første “target condition” vi skal eksperimentere for å nå?Hva som kan være et “neste steg” eller eksperiment varierer etter hva slags delmål man jobber mot. Eksempler vi så underveis i arbeidet:En kartleggingsjobb, f.eks. måle størrelsen på problemet, prosesskartlegging, rotårsaksanalyse.Administrative ting, f.eks. finne teammedlemmer, innkalle workshops, forberedelser.Test av en ny løsning, herunder planlegging, gjennomføring, måling av resultater.Alle slike steg kan betraktes som eksperimenter hvor det kan være noe å lære, enten om selve problemet som skal løses eller om problemløsningsmetodikken.Oppsett og gjennomføringI eksperimentet ble tre deltakere coachet. Dette var medarbeidere som skulle lede hvert sitt problemløsningsarbeid sammen med et A3-team. Felles for teamene var at forbedringsarbeidet fokuserte på hvordan de kunne gjøre utviklingsprosessene sine mer effektive. Underveis var det en av deltakerne som måtte prioritere bort forbedringsarbeidet, og avbrøt derfor også deltakelsen i eksperimentet. Coachen i Coaching Kata-samtalene var deltakernes leder og eier av problemene som skulle løses. Artikkelforfatterne fungerte som 2nd coach, og var med og observerte samtalene og ga tilbakemeldinger til coachen underveis.Møtene ble kjørt en gang i uka, med 20 minutter til hver deltaker. Disse ble lagt rett etter hverandre, slik at coachen hadde satt av en time pr uke i sin kalender for de tre deltakerne. Møtene ble kjørt på Teams fordi deltakerne befant seg på ulike steder. Hvis vi skulle kjørt fysiske møter, ville vi ønsket å samle oss rundt en fysisk tavle, mens på Teams viste deltakerne fram sitt arbeid på en digital tavle eller i PowerPoint.Kilde: Toyota Kata Practice GuideHva lærte vi?Underveis i det 5 måneder lange eksperimentet ble tre retrospektiver gjennomført. Nedenfor presenteres de tydeligste læringspunktene fordelt på positive opplevelser og muligheter for forbedring.I stort erfarte deltakerne Coaching Kata som et effektivt møtepunkt med høy verdi. Samtalene tok mellom 7 og 20 minutter, og skapte nyttig dialog mellom leder/coach og medarbeider. Her kom lederen nærmere problemstillingen teamet arbeidet med gjennom løpende involvering. Videre bidro Coaching Kata-strukturen til flyt i samtalen og til at man i stor grad pratet om rett ting: Hva har vi lært siden sist og hva skal vi gjøre framover for å lære mer? Arenaen ble ikke opplevd som et klassisk statusmøte. I stedet la de hyppige møtene til rette for dialog og tilbakemeldinger som ga medarbeiderne et “puff for fremdrift” som de opplevde positivt. Samtidig bidro strukturen i samtalen til at lederen fikk trene på og forsterke et mønster for coachende ledelse. Visualisering av arbeidet ble vurdert som svært nyttig for fokuset i samtalen.«Som A3-eier gir slike samtaler langt mer involvering enn vanlig, og med minimal bruk av tid»- Leder og coach i eksperimentetEt punkt deltakerne tidlig kjente på var hvordan man kunne stille riktig forberedt til samtalene. Kvaliteten og lengden på de første iterasjonene varierte en del. Ved tydeligere fokus på hvorfor visualisering av arbeidet var viktig, kombinert med sterkere forpliktelse til å stille forberedt, økte kvaliteten på møtene samtidig som tidsbruken ble redusert. Vi mener nå at en innkalling på 15 minutter skal være nok.En annen utfordring i starten av eksperimentet var at sparring med 2nd coach på A3-tekniske spørsmål ble til hinder for gjennomføring av Coaching Kata-syklusen. For å avverge dette problemet ble møteagendaen oppdatert med en eksplisitt rekkefølge for innholdet, der Coaching Kata stod først på kjøreplanen, mens A3-teknisk sparring var mulig når det var tid til overs. Med dette grepet ble det tydelig for alle involverte at Coaching Kata-spørsmålene hadde prioritet.Utklipp fra retrospektiv-tavle for eksperimentetEt tredje hinder under den første fasen av eksperimentet var at 2nd coach brøt ut av sin observatørrolle for å ta aktivt del i samtalen. Da vi ble oppmerksomme på denne utfordringen, fokuserte 2nd coach mer på aktiv lytting, ble mer oppmerksomme på egen iver etter å delta, og overlot samtalen til de øvrige deltagere. At A3-teknisk sparring ble plassert etter Coaching Kata-syklusen gjorde det også enklere å overholde rollefordelingen.Ukesrytmen for samtalene fungerte bra for deltakerne. Behovet varierte dog underveis, da det ikke alltid hadde skjedd så mye som man følte var verdt å diskutere. Andre ganger kjente man på at det kunne være nyttig å ha muligheten for flere samtaler i løpet av en uke. Selv om kadens ble diskutert underveis i forsøket ble det ikke foretatt justeringer på oppsettet.Observasjoner fra 2nd coachUt over erfaringene som er beskrevet over, observerte vi som 2nd coacher at fremgangsmåten med de fem spørsmålene muliggjorde en form for situasjonsbestemt ledelse, der hver enkelt medarbeider fikk sparring ut fra hvor man befant seg i problemløsningen. Vårt inntrykk var at coachen benyttet spørsmålene godt, og fikk fram elementer som kanskje ikke ville ha kommet fram i en mer tradisjonell dialog om status. Blant annet observerte vi at coachen så bort fra flere forsøk på å starte samtalene med å liste opp aktiviteter man hadde lagt bak seg, og i stedet vennlig oppfordret til å starte møtet med en beskrivelse av hvilket delmål man fokuserte på, etterfulgt av detaljert refleksjon over det siste steget man hadde vært gjennom. En annen fordel med oppsettet av samtalen var muligheten for rask feedback fra 2nd coach rett i etterkant av Coaching Kata-sesjonen, med denne friskt i minne.“Being a good coach is essential to being a good manager and leader. Coaching is no longer a speciality; you cannot be a good manager without being a good coach.”-Trillion Dollar Coach: The Leadership Playbook of Silicon Valley’s Bill CampbellEffektiv arena for coachende ledelseDet kan ta tid å snu mentalitet fra status-rapportering til læringssløyfe. Erfaringen fra vårt lille eksperiment var at samtaleverktøyet traff godt ved behov for en mer coachende tilnærming til ledelse. To klassiske grøftekanter, “set & forget” preget av alenegang, og sporadisk reaktiv statusrapportering, ble unngått. Både lederen og medarbeiderne i eksperimentet synes Coaching Kata fungerte godt til formålet om dialog og forankring underveis, samtidig som samtalene tok lite tid og ga positiv effekt på selve forbedringsarbeidet.Uavhengig av problemløsningsmetode er det kanskje flere som kjenner seg igjen i en situasjon der dialog med en opptatt leder blir flaskehals for fremdrift på problemet man jobber med? Samt ledere som opplever at med covid-pandemien og fremveksten av hybridkontoret har det blitt vanskeligere å finne naturlige arenaer for samhandling med folkene man leder? Hvis man kjenner på en slik utfordring tror vi Coaching Kata kan være et interessant alternativ å teste ut.Skrevet av:Ragni Ryvold ArnesenKristoffer BergReferanserToyota Kata: Managing People for Improvement, Adaptiveness and Superior Results, Mike Rother.The Toyota Kata Practice Guide: Practicing Scientific Thinking Skills for Superior Results in 20 Minutes a Day, Mike Rother.Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System, Durward K. Sobek II and Art Smalley.Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor and Lead, John Shook and Jim Womack.Coachende ledelse med fem små spørsmål 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

Speed up your Multi Module Maven Builds with turbo-maven-plugin

Fast feedback makes us happy. So if you are only looking for how to speed up your multi module build as fast as possible, go straight to turbo-maven-plugin.If you want to know more about why, and also how turbo-maven-plugin works, please keep on reading.The reason we are happy when we get fast feedback, is that it triggers the production of dopamine in our bodies. Dopamine is a happiness drug we can give ourselves for free. This is a smart thing to do as often as possible — it makes us happy.In addition to making us happy, fast feedback makes us deliver value faster. This not only feels good, it is also good for our team and the place we work.When working with Kotlin and Java, feedback from building our apps, is something we need often. Where I work, we code and run our tests in IntelliJ. As soon as we want to move the change to production, we normally build the app locally with Maven before pushing the code, to see that the tests run as they should, and that everything is working fine.A Multi Module Maven repository with 250 applicationsWe have our 250+ apps in a monorepo. The monorepo is one multi module Maven repository, where everything is on head all the time. When we build our app, we build both the app itself, and all the modules that it depends on.This is why it is important for us to build smart.A typical app builds and runs all tests for itself and its dependencies in 2–3 minutes. This is a long time to wait, so we started looking for a way to get faster feedback.A multi module Maven build with a change in one of the modules.We quite often have a code change in a module the app depends on.It is possible to ask Maven to build only the modules that we want, using the — projects <list of projects to build> argument, and building from the root pom. This is faster than building all required dependencies with — also-make.Using a maven command with — projects requires both mental capacity and finger acrobatics on the command line, so we seldom do this. We rather build with variants of cd in and out of modules and mvn clean install, hoping that we have built everything that needs to be built. Or we build everything to be sure.Building only what needs to be builtA multi module Maven build with a change in one of the modules. We only need to build this module and the modules depending on it.We only want to build what needs to be built, without having to hand code a special Maven command for every change we do. Both Bazel and Gradle knows how to do this.There are several strategies here, and all we have seen, is based on analysing what files have changed, then making scripts or programs calculating what modules the changes reside in, and then create a Maven command that builds these modules.We have created a Maven plugin helping us with just that. It is called turbo-maven-plugin.How does turbo-maven-plugin work?turbo-maven-plugin is based on the same strategy, that is analysing what modules have changes in their source code, and then build only these modules, and the modules depending on them.For every module, the plugin looks for a file containing one row per source code file in the module. A row contains the name of the source code file and a checksum of the contents of the file.If it doesn’t find a file for a module, it creates it, and puts it in the the module’s directory in the local m2 repo. It does this for all modules that is required for building the app, and also the app itself.If we build again, without changing anything, nothing will be built, since all the checksums are the same.If we do a change, the plugin will first get the complete list of modules that needs to be built from the Maven Reactor. This is the the app itself, and all its dependencies. For each module, it compares the checksum for each source code file in the module, with the checksum in the file in the m2 repo. If the checksums are the same, the plugin removes the module from the list.For the modules that have changes, we make sure we also add the modules that are dependant on them. In pseudo code, it looks like this://Find changed modules:modulesToBuild = modulesFromMaven.filter(isModuleChanged())//Find the modules dependent on the changed modules:modulesToBuild.forEach(module -> downStreamProjects.add(module.getDownstreamProjects()))//Return the distinct set of modules to build:return modulesToBuild.addAll(downStreamProjects).removeDuplicates()How do we use the turbo-maven-plugin?The plugin is defined in our root pom, and is disabled by default, so that Maven behaves normally for everyone when using regular Maven commands:<plugin> <groupId>no.sparebank1</groupId> <artifactId>turbo-maven-plugin</artifactId> <version>${turbo-maven-plugin.version}</version> <extensions>true</extensions> <configuration> <enabled>false</enabled> <ignoreChangesInFiles>swagger.json</ignoreChangesInFiles> <alwaysBuildModules>distribution</alwaysBuildModules> </configuration></plugin>We have a tool, that really is just a structured collection of scripts, called bob. When we want to build an app, we run bob mvn build from the app root. This command actually does this:mvn -T4 -f <path-to-the-root-pom> --projects <path-to-the-app-pom> --also-make -Dturbo.enabled=true clean installBut that is something our developers don’t have to think about.With this, we have cut the average app build time in half, from 2–3 minutes to 1–2 minutes. We have also reduced the cognitive load of our developers. They don’t have to think about what modules need to be built anymore. They just run bob mvn build, and Maven and maven-turbo-plugin take care of the rest.If you want to try the plugin, it is on Maven Central, and you find both source code and pom configuration on the turbo-maven-plugin’s home page.Speed up your Multi Module Maven Builds with turbo-maven-plugin 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

Fra agile team til agil organisasjon: Slik jobber vi agilt i SpareBank 1 Utvikling

For 10 år siden skjønte vi i SpareBank 1 Utvikling at vi måtte gjøre noe annerledes. Flere års dedikert arbeid hadde resultert i en monolitt av en løsning. Men tiden, teknologien og forventningene fra kundene hadde endret seg. Vi måtte rett og slett begynne å tenke annerledes.Rettere sagt — vi måtte begynne å tenke agilt. Det ble starten på vår agile reise.I 2013 begynte vi å dele opp monolitten. Bit for bit. Ikke bare var kravene fra kundene og teknologien endret, men leveransemodellen vår i SpareBank 1 Utvikling begrenset muligheten til å levere det vi ønsket.Vi endret arkitektur og teknologi, og etablerte tverrfaglige utviklingsteam. Vi begynte også det året å måle T2M og omfanget av endringene vi klarte å skape.Grepene hadde enorm effekt:I dag har vi 25 forskjellige utviklingsteam som blant annet jobber med mobilbanken og nettbanken.Kundetilfredsheten går oppover, og vi opplever økt salg gjennom de digitale kanalene.Innovasjonstakten har aldri vært høyere. Antall dager fra produksjonsstart til ferdig utviklet løsning gått fra over 50 dager til å kunne gjøre løpende produksjonssettinger på bare noen timer eller dager.Høy endringsevne har gitt mulighet for å kunne jobbe datadrevet for å forbedre kundeopplevelser, fjerne hindringer og å øke salget.Større grad av måloppnåelse gir høyere medarbeidertilfredshet.Lignende suksesshistorier og veien dit kan du høre mer av fra andre norske utviklingsmiljøer i NAV, Skatteetaten, FINN, Vipps og flere andre dyktige og forbilledlige organisasjoner. Men, jeg har den senere tiden stilt meg et spørsmål:For til tross for de strålende resultatene på de endringsreisene vi har gjort med agile team, er vi en agil organisasjon?Og har det egentlig noe å si?Jeg deler mine tanker her. Og, jeg har lyst til å høre dine. I kantina, innboksen eller kommentarfeltet.Hvorfor agilt?Før vi diskuterer agil organisasjon, er det nødvendig å spørre seg selv hvorfor et selskap skal jobbe agilt og å være en agil organisasjon.Hvis svaret er at man skal fremstå som en moderne organisasjon og tiltrekke seg nye medarbeidere, er det i og for seg bra og viktig, men det holder ikke som grunn alene.Jeg mener man må ha et mer gjennomgripende og grunnforankret forretningsmessig perspektiv om hvorfor man skal være en agil organisasjon. I SpareBank 1 Utvikling var det som nevnt innledningsvis så enkelt — og så vanskelig­ – at vi ikke fikk produsert alle tjeneste og produktene som ønsket. Vi rakk heller ikke å gjøre endringer raskt nok. Vi slet rett og slett med å skape verdi for selskapet og kunden når vi ønsket det.Med andre ord, vi hadde ikke nok fart i utviklingsarbeidet.I manifestet til agil arbeidsmetode, som du kan lese på agilemanifesto.com, står det tydelig hva man skal gjøre for og med smidig programvareutvikling. I fare for å repetere det som står der, vil jeg gi et innblikk i hvordan vi selv har tolket og adoptert den agile måten å jobbe på hos oss.1. Vi har fartFart og skalerbarhet er et helt sentralt fundament i agil utvikling. Det å ha evnen til å utvikle raskt har enorme fordeler for et selskap. Men, det krever også enorme endringer. Siloer må brytes ned, og nye tverrfaglige team må etableres. Prosesser må revideres og optimaliseres. Og under alt dette må det være en teknologi og arkitektur som bidrar til at teamene kan jobbe parallelt og minst mulig avhengig av hverandre.Alt for å først og fremst oppnå én ting; fart.Mine dyktige medarbeidere i SpareBank 1 Utvikling har publisert flere artikler om hvordan vi har gjort dette. De kan du lese mer om på sparebank1.dev.2. Vi har kunden og forretningsfokus i sentrumFart alene løser ikke kunde- eller forretningsbehov. Det krever tydelige ambisjoner og målsetninger. Målstyring er et sentralt grep og en forutsetning for selvgående, tverrfaglige team som jobber i høy fart.Kort forklart er det en strategisk retning som brytes ned i ambisjoner og deretter ned i ulike mål som kan følges opp av de ulike teamene.I fastsettelsen av ambisjoner og mål må grensene mellom forretningssiden og IT brytes ned. Med det mener jeg at det er eierne av forretningsbehov som eier målene. Disse har igjen flere produkteiere og produktledere til å hjelpe seg.Men disse forretningsbehovene kan også kreve endringer i arkitektur, datafangst, infrastruktur og dataanalyse.Teknologimiljøene må derfor også være tett på eieren av forretningsbehovene. Tilsvarende gjelder de som jobber med at teamene til enhver tid er best rigget for de endringene som må gjøres.Dette høres kanskje enkelt ut, men det å bryte ned en strategisk retning til tydelige mål, uavhengig av silo, er vanskelig. Samtidig er det helt avgjørende for å få ønskede resultater. Over tid vil det skape for mye friksjon hvis forretning og IT jobber for separat.3. Vi har topplederforankringÅ fjerne grensene mellom forretningssiden og IT er kun mulig med en tydelig topplederforankring. Det vil alltid, og særlig i større organisasjoner, være behov for å sette opp styringsstrukturer og tydelige ansvarsområder. I tillegg er det viktig at lederne ser hverandres bidrag for å nå selskapets mål.Det vil i dette oppstå ulike vurderinger om hva som er riktig å gjøre og hva som er balansen mellom forretningsmål og etablerte retningslinjer et selskap har av blant annet regulatoriske grunner.Styrken i en organisasjon handler ofte om hvordan man klarer å navigere effektivt og uten for mange konflikter når det som er riktig å gjøre ikke alltid er helt rett frem. I dette blir topplederforankringen på felles mål, retning og arbeidsform avgjørende for å bidra til å komme frem til gode løsninger og ikke større avstand.Overgangen fra en mer tradisjonell organisasjon til en mer agil organisasjon er stor. Eksempler på kjente smertepunkter er endringer i løsninger og prosesser, etablere tydelig ansvarsdeling og rolleforståelse, fordeling av midler og kapasitet, samt både faktisk og opplevd styring og kontroll.Det er med andre ord mange mulige grunner til at overgangen blir vanskelig. En sterk topplederforankring er sannsynligvis helt nødvendig for å lykkes godt.Avslutningsvis må et positivt menneskesyn der trygghet og tillit gjennomsyrer hverdagen ligge i bunn. Det blir ikke fantastiske resultater av frykt, forsiktighet og å holde seg til sin lille del av løsningen og ikke oppleve en trygghet til å utfordre det eksisterende på en god måte. Man må tro på at man er bedre sammen med andre og at man hele tiden lærer. Den kulturen må ligge til grunn i et selskap.Så, er vi en agil organisasjon, eller er vi «bare» agile team?Kanskje en liten brannfakkel til slutt: Å jobbe agilt og å være en agil organisasjon kan skape fantastiske resultater, men det er ikke alltid verken forutsetningene er på plass eller at det er riktig å jobbe agilt i form av ulike smidige metoder.I SpareBank 1 Utvikling har vi særlig erfart det ovenfor leverandører som jobber tradisjonelt med kravspesifikasjoner og større releaser. Dette gjelder særlig når det er større fagsystem med kompliserte forretningsregler som skal endres. Da kreves det andre typer av prosesser. En agil organisasjon må derfor også kunne tilpasse metodene som benyttes for å kunne håndtere sine omgivelser.Størrelse på organisasjonen har mye å si. Jo mindre organisasjon desto mindre avstand, ofte mindre legacy og færre leverandører skal håndteres. Mange av momentene over blir enklere å håndtere i mindre selskap, men det er viktig å ha en forståelse av om selskapet vokser mye under en periode.Agil utvikling og arbeid med agile organisasjoner krever kontinuerlig forbedring. Det vil være stadig nye problemstillinger som krever en kontinuerlig endringsevne og å kunne være tilpasningsdyktig.Merk at kontinuerlig forbedring kan fort bli for operativ. Vi kan ikke bare jobbe med selve løsningene, vi må også kontinuerlig forbedre prosesser, metoder og ikke minst organisering. Derfor blir punktene om verdiskapning, målstyring og topplederforankring igjen viktige for å sikre at forbedringene går langs de rette aksene.Jeg tror vi i SpareBank 1 Utvikling er nære å kunne si at vi er en agil organisasjon, men vi er ikke i mål.Det dukker hele tiden opp nye temaer som må jobbes med. Fokus i tiden fremover er å få teamorganisasjonen til å bli enda tydeligere knyttet til forretningsområdene og linjeorganisasjonen og tilhørende ansvarsgrenser.Ordtaket «behovet for endring er det eneste som er konstant» oppsummerer det godt.For hva som kommer rundt neste sving må vi se på da.Fra agile team til agil organisasjon: Slik jobber vi agilt i SpareBank 1 Utvikling was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Espen Kjølberg

Parprogrammering for flyt og fokus

(Dette er en oppfølging artikkelen Hvordan vi fikk høyere fart med hyppige prodsettinger og parprogrammering)Det er noe rart med parprogrammering. Det er en gammel teknikk som er godt kjent og respektert blant utviklere, men som likevel er lite brukt.Hvis jeg spør, opplever jeg at de fleste er positive til parprogrammering. Spørreundersøkelser hos oss i SpareBank 1 Utvikling viser stor interesse og at de fleste vil parprogrammere mer enn de gjør i dag. Kompetansedeling, læring og at det er sosialt scorer høyt på undersøkelsene.Likevel er det få som gjør det, selv hos oss. Vi kan også lese om samme type utfordringer andre steder. Hvorfor? Vi ser er at dette går igjen når man spør hvorfor vi ikke parprogrammerer:To kan heller jobbe i parallell med oppgavene fordi de vet hvordan de skal løse det hver for segVi bruker det bare på vanskelige problemstillingerVanskelig på hjemmekontorVi trives best med å jobbe aleneVi hjelper hverandre heller litt underveis, og tar resten i Pull RequestsVi vet ikke helt hvordan vi kommer igangVi er redd for å blottlegge oss, redde for å dumme oss utVi ser ingen umiddelbar effektFlytsonenFlyt. Vi har alle vært der, men jeg tror at for oss utviklere er det spesielt. Å være i flyt er fantastisk. Etter litt arbeid med en oppgave glemmer du tid og sted, og konsentrasjonen blir ekstra høy. Du får opp en god del av kodebasen i hodet, og vet hele tiden neste steg før du har utført det. Fingrene flyr over tastaturet. Nye ideer popper lettere opp en vanlig. Du har fokus. Du er motivert. Og ikke minst, du får gjort masse.De dagene jeg har vært mye i sonen, er de dagene jeg går ut av kontoret med et smil om munnen. Kone og barn får en bedre mann når jeg kommer hjem, og jeg har mer overskudd. Jeg flyr gjennom skogen på løpeturene mine. Jeg sover godt.Så da er spørsmålet: Burde ikke vi utviklere etterstrebe denne tilstanden mest mulig av tiden?Har du to minutter?Slack er fantastisk, det mener jeg. Vi har nesten sluttet med e-post, vi har alle ansatte tilgjengelige på et blunk og vi jobber asynkront over en lav sko. Mye blir løst raskt uten at vi trenger å sette opp egne møter for det.Men det har en pris.For hva skjer når du sitter midt inni denne gode flyten, og det plutselig dukker opp popup fra Slack med teksten “Har du to minutter?”I det du går inn på Slack, så ser du også andre kanaler som lyser som et juletre. Du blir interessert, leser noen tråder og forsvinner enda lenger bort fra det du egentlig holder på med.Utviklere er ikke datamaskiner.Forskning viser at det tar ca 15 minutter fra man blir avbrutt til man kommer tilbake der man var i konsentrasjonen.Når du går tilbake for å jobbe videre, vil du også automatisk tenke på det du ble avbrutt av, og flyten blir enda verre å komme tilbake til.Resultatet? Du får gjort mindre av det du hadde planlagt, og er mest sannsynlig mindre fornøyd etter arbeidsdagen.Parprogrammering som verktøy for flytDet er så kraftig og så enkelt. Når to sitter sammen og jobber på en oppgave så blir det fullstendig unaturlig at den andre skulle sjekke e-post, Slack, nettaviser, mobilen og andre ting.En sesjon med parprogrammering kan betraktes som et tradisjonelt møte. Sesjonen legges inn inn i kalenderen for å vise til andre at her er du og den du jobber sammen med er opptatt. Og slik får dere fullt fokus.Test gjerne med to tastatur mot samme maskin når man parprogrammererMen hva med alle meldingene på Slack? Og alt annet som krever tiden din?Vi tar avtalte pauser ca. annenhver time der vi svarer opp andre meldinger, og vi parprogrammerer heller ikke 7.5 timer om dagen, fem dager i uka. Vi setter av tid til slakk, fordi vi vet det dukker opp uforutsette hendelser hver eneste uke. Og vi liker å hjelpe andre.Hvordan kommer du igangStart med å planlegge dagen med den du skal jobbe sammen med.Slik kan en dag se ut. Jeg har en avtale hos legen og en workshop, Ola har et personalledermøte. Men merk at selve oppgaven har lite fri, den får full fokus og fart hele dagen. Og man får jobbet litt alene også, selv de mest ivrige parprogrammererne liker det iblant.Selv om man har litt forskjellig agenda, får oppgaven fokus hele dagenFerie og oppgaver på ventVi har opplevd at når folk jobber alene, drar på ferie eller blir syke, så blir oppgaven satt på vent til de er tilbake. Med parprogrammering kan den andre parten fortsette arbeidet, og lett rulle på andre utviklere.Og hva blir effekten av dette?Oppgaven blir raskere ferdig målt i kalendertidTrikkefaktor blir betydelig redusert og vi får høy grad av kunnskapsdeling. Flere kan kodebasen, mindre superhelter som eier hver sin applikasjon, mindre av “den der har Ola jobbet mest med”WIP (work in progress) reduseres, vi gjør ferdig oppgaven før vi starter noe nyttDobbel flytsoneTilbake til flytsonen. Vi er nå to utviklere som konsentrerer oss 100% om en oppgave og går inn i flyt. Hvilke konsekvenser får dette? Utviklerne har ofte litt ulik kompetanse, erfaring og måter å se oppgaven på. Man utfyller hverandre og slik oppnår man høyere fart, mindre avbrudd og bedre kvalitet. Og pull requests? De blir ofte overflødige, vi er ferdig diskutert lenge før koden kommer dit. Og vi prodsetter hele tiden.To utviklere med litt forskjellig erfaring kan ofte komme frem til solide løsninger i et større tempoMye av bittelitt istedenfor bittelitt av myeHar du noen gang pratet med en som har møtt veggen?Du vil ofte høre at “det ikke var en ting, det var summen av alt”. Jeg opplever at de mest stressa og slitne folka på jobben, er de som driver med for mye samtidig. De som ikke klarer å si nei. Dette resulterer ofte i tidspress, lite fokus og til slutt går det utover kvaliteten på det som blir gjort. WIP (work in progress) blir for høy.Planlegger man at oppgavene skal gjøres med samarbeid og parprogrammering, setter man automatisk ned WIP. Slik planlegger man altså inn fokus, får bedre flyt og vår erfaring er at vi får gjort mer med skikkelig kvalitet. Dette øker motivasjonen, og motiverte utviklere kan få til hva som helst.Jeg skrev at de dagene jeg gikk mest fornøyd ut fra kontoret, var når jeg har vært i flyt. Men så hørte jeg kollega Stian Conradsen si at de dagene han gikk hjem og var mest fornøyd, var de dagene han hadde parprogrammert. Hvorfor? “Det er de dagene jeg får gjort mye”, svarte Stian.Mest sannsynlig kan du sjekke av dette etter en dag med parprogrammering. Du har:Opplevd høy kompetansedelingHatt gode tekniske diskusjonerFått fokus og jobbet med bare en sak om gangenVært sosial med en eller flere kollegaerFått gjort mye, og gjort det skikkeligSå hvorfor parprogrammerer ikke alle hele tiden da?Jeg tror det er sammensatt, men den største faktoren virker å være at det er vanskelig å komme igang.Og jeg kan merke det selv noen ganger. Det er mye enklere å bare komme til plassen sin, sette seg ned og begynne å kode på sin oppgave i sitt eget tempo. Ingen som forstyrrer, du kan dypdykke, svare på Slack, prate med kollegaer og jobbe med det du mener er viktigst og i ditt tempo. Og dette mener jeg vi skal fortsette med også, men ikke hele tiden 5 dager i uka.Parprogrammering krever at du retter deg opp i stolen, konsentrer deg og setter deg skikkelig inn i oppgaven. Det er en intens måte å jobbe på, så ta pauser.Hvor mye skal vi parprogrammere?Ikke legg lista for høyt. Hvis teamet som en start setter av tid til parprogrammering et par dager i uka, vil det fort ha stor effekt. Et nyttig tips er at det er lurt å rotere på hvem som jobber sammen. Dette vil ikke bare gi hver enkelt en bedre hverdag og øke kvaliteten på det som blir levert, men det vil ha en positiv utvikling av kulturen i teamet.Har du lest om hva som er best for teambuilding? Det er ikke at de ansatte drar på rafting, paintball eller gokart. Det er at vi prøver å løse en vanskelig oppgave sammen, gjerne over tid. Da får vi tilbakemelding, det er lett å spørre om hjelp og frykten for å gjøre feil blir borte — teamet får psykologisk trygghet.Hva er det som stopper deg fra å komme i gang?ReferanserOn Pair Programming fra Martin Fowler’s blog, av Birgitta Böckeler, Nina SiesseggerHvordan vi fikk høyere fart med hyppige prodsettinger og parprogrammering av Asgaut MjølneFlow (psychology) fra WikipediaTegneseriebilde med parprogrammering, fra monkeyuser.comTegneseriebilde av fokus, fra monkeyuser.comDisse formene for teambygging har ingen effekt, fra forskning.no og NTNUSlik får du hybride team til å fungere fra e24.no av Nils Brede MoeWhat happens to psychological safetywhen going remote? av Anastasiia Tkalich, Darja Smite, Nina Haugland Andersen, Nils Brede Moe. SINTEF, NTNU, Blekinge Institute of TechnologyParprogrammering for flyt og fokus was originally published in SpareBank 1 Utvikling on Medium, where people are continuing the conversation by highlighting and responding to this story....

Av Asgaut Mjølne

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

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

Av Asgaut Mjølne

Synlighet og kunnskapsdeling styrker personvernarbeidet

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

Av Karen Grinvoll

SpareBank 1 Utvikling på Instagram@sparebank1utvikling