Retroene du får presentert her har fokus på personlig utvikling. De to første er ganske lavterskel og enkle å gjennomføre, mens de siste to går mer i dybden og lar dere bli godt kjent som et team.

Dette er del 3 av en serie med forslag til retrospektiver du kan bruke i ditt team. Del 1 som handler om tradisjonelle retroer med en artig vri finner du her. Del 2 som handler om korte og uformelle retroer finner du her. Alle retroene som blir presentert i serien kan finnes i Retrobanken.



Øy-retroen: gi kudos og løft hverandre opp

Fin og lavterskel måte å gi hverandre ros og løfte hverandre opp.

Tidsestimat: 40-60 minutter.

Passer for team som vil ha en ekstra hyggelig retro.

Mal: Øy-retroen.

Er dere flinke til å skryte av hverandre i teamet? Hvis ikke, kan denne retroen bidra til å minne dere på nettopp det! Øy-retroen kan ved første øyekast minne om seilbåten og luftballongen, men det som skiller denne fra de andre er at den har et eget kudos-punkt! Dette er et hyggelig og nyttig punkt å ha med som en del av en retro da man får satt seg ned og faktisk gitt folk den skryten de fortjener. Dette kan virke motiverende og oppløftene for videre arbeid i teamet.

I øy-retroen skal man bevege seg gjennom øyen og svare på følgende fire punkter:

Sweet fruits - Hva gikk bra?

Hidden gold - Kudos/shout out til team medlemmer.

Pirates on the bay - Hva gikk ikke bra?

Message in a bottle - Tiltak man kan iverksette.

Som i de andre retroene går man vanligvis igjennom ett og ett punkt hvor dere skriver lapper individuelt før dere kategoriserer og diskuterer lappene sammen.



Energy levels: finn ut hva som tapper energi og lad opp

Dra denne fram om du vil finne ut hva som motiverer og demotiverer ulike teammedlemmer.

Tidsestimat: 20-30 minutter.

Passer for alle team, spesielt de som merker det har vært et lavt gir i teamet i det siste.

Mal: Energy Levels.



Følt deg litt slapp denne uken? Eller full av energi? Denne retroen er en artig vri som får frem hva man synes er gøy eller kjedelig å gjøre. Hvis man merker at motivasjonen til teamet ikke er på topp, kan en slik retro få frem hva som er grunnen*.* Retroen kan brukes til å få en bedre forståelse for hvordan man kan motivere de rundt seg med utgangspunkt i lapper på lavt og høyt energinivå. Retroen gjennomføres ved at teammedlemmene først skriver ned hva som har gitt energi i løpet av uken. Det kan være en gøy oppgave som du har blitt tildelt, eller noe annet som har gitt deg mestringsfølelse. Kanskje var det noe sosialt med teamet, eller at du vant foos-matchen i pausen? Deretter går man til neste kolonne og fyller inn hva som har vært “helt greit” for energinivået, og til slutt hva som har tatt all energien. Det kan for eksempel være at en oppgave har tatt litt for lang tid, eller at du måtte purre på en mail flere ganger. De siste kolonnene åpner opp for “recharge” delen, hvor man fokuserer på hva man hadde trengt for å lades opp. Dette åpner opp for diskusjon for hvordan teamet og du kan finne og iverksette tiltak som gir mer energi. Og ikke minst hva man kan gjøre for at teamet ikke skal jobbe på “lavt energinivå”.

Hvem er du i båten? Se på deg selv og din rolle i teamet



Finn ut hvem teammedlemmene føler seg som og hvem de ønsker de skulle være.

Tidsestimat: 20-30 minutter.

Passer for team som vil stoppe opp og se på seg selv.

Mal: Hvem er du i båten?



Noen ganger kan et team ha bedre av å reflektere rundt seg selv og sin rolle i teamet, enn prosjektet og arbeidsprosessen. “Hvem er du i båten?” byr på et annerledes retro-format enn det du kanskje er vandt til. Denne retroen passer like godt for nye som etablerte team, små som store team og storming som norming team.

“Hvem er du i båten?” retroen er delt inn i to deler:

Først skal dere individuelt se på bildet og reflektere rundt hvilke av karakterene hver du føler man har vært den siste arbeidsperioden. Dette kan være en eller flere karakterer. Du lager selv definisjonen på hvorfor du er den karakteren(e) du velger. Hva man ser på bildet og i karakteren er tross alt subjektivt. Del så med resten etter tur.

Videre tar man en runde på hvem av karakterene på bildet du ønsker å bli eller være.

Refleksjonene er ofte nyttige i seg selv, men dere kan ta et steg videre og diskutere sammen hva som skal til for at dere blir den karakteren dere ønsker å være.

Retro med tilbakemeldinger: ta et skikkelig dypdykk og fokuser på personlig utvikling

Fokus på personlig utvikling og åpner muligheten til å gi personlige tilbakemeldinger.

Tidsestimat: 60+ minutter.

Passer best for team på 3-6 personer og som har en høy grad av psykologisk trygghet.

Mal: Retro med tilbakemeldinger.



I denne retroen går man enda litt dypere ned i teamdynamikken og refleksjonene ved å gi hverandre tilbakemeldinger. Skummelt tenker du kanskje? Slapp av, vi skal komme med noen eksempler! Kanskje du ønsker å se en av teammedlemmene dine ta enda mer plass i de faglige diskusjonene? Kanskje du vil gi ekstra ros til han eller hun som alltid setter av tid til å hjelpe deg? Eller er det noen som kunne forbedret PR-gamet sitt?

Ettersom dette er en dyptgående retro er den ikke å anbefale som den første retroen man skal teste, men heller når teamet føler seg trygge på hverandre og kjenner godt til hva retroer er. Det kan ta tid å gå igjennom tilbakemeldingene til hvert teammedlem, så den passer best for team på 3-6 personer.

Retroen er delt inn i to deler. Første del er en tradisjonell retro, men siste del handler om å gi og få tilbakemeldinger.

Del 1 (tradisjonell retro):

Start med en oppvarmingsøvelse for å skape trygghet i gruppa, og for å lage rom til å gi og motta tilbakemeldinger. Nederst ligger et forslag på hvilken oppvarmingsøvelse dere kan gjøre.

Skriv lapper individuelt på hva som har vært bra og hva som kunne vært bedre for perioden man har vært igjennom (ca. 5-7 min).

Gå igjennom alle lappene muntlig, start med hva som har vært bra og deretter hva som kunne vært bedre. Gjerne grupper lappene som henger sammen slik at det er lettere å oppsummere (ca. 15 min).

Skriv lapper individuelt om hva teamet burde starte og stoppe med. Av erfaring er det ikke alltid at det kommer opp noen punkter på stopp, og det er helt greit (ca. 3-5 min).

Gå igjennom tiltakene som er foreslått og bestem hvilke man ønsker å ta med til neste periode (ca. 10 min).

Del 2 (personlige tilbakemeldinger):

Bruk 10 min på å skrive tilbakemeldinger individuelt til hverandre. Man skriver både positive tilbakemeldinger som for eksempel hva du syns personen er god på, hva du setter pris på med de som kollega, eller generell ros du ønsker å gi. I tillegg har man et felt for forbedringspunkter for hver person. Si gjerne i fra et par dager i forveien at man skal gi hverandre tilbakemeldinger så har alle mulighet til å forberede seg litt og kanskje skrive ned et par punkter på forhånd.

Gå en runde igjennom teamet og oppsummer tilbakemeldingene hver person har fått. Dette gjøres for å kunne forklare lappene man har skrevet og gi dem litt kontekst dersom det trengs. Sett av et par minutter per person. Første gang man kjører denne retroen er det fint å sette av litt ekstra tid slik at man får gått igjennom tilbakemeldingene ordentlig.

Oppvarmingsøvelse for å skape rom og trygghet i teamet

Før man kjører i gang med litt tyngre retroer kan det være greit å løfte stemningen i gruppen og få alle litt ut av komfortsonen. Her kommer en kjapp øvelse som passer for absolutt alle.

Øvelsen går ut på at deltagerne sammen skal tegne en tegning av et gitt tema. De får tegne én og én i 10 sekunder før de må bytte med nestemann. Totalt skal alle tegne 3 ganger hver.

Bruk en tavle eller heng opp et stort ark på en vegg. Utstyr alle deltakerne med en penn hver.

Be så deltakerne stille seg i kø og forklar dem øvelsen og temaet for tegningen. Noen eksempler på tema kan være; en sommerdag på Sørenga, neste julebord, en festival o.l.

Sett på noe artig musikk i bakgrunnen og start stoppeklokken!

Når tiden er ute kan dere bruke et par minutter på å snakke rundt hva dere har tegnet. 



Kilder

Mal for Øy-retro er fra Clyde D'Souza.

Mal for Energy levels er fra TeamRetro.

Mal for Hvem er du i båten er fra Prosjekthåndboka (båten).

Mal for retrospektiv med personlige tilbakemeldinger er inspirert fra retrospektivene til Dreamknit.

Retrobank del 3 - Fokus på personlig utvikling

Designdrypp er en artikkelserie hvor forskjellige designere fra Bekk forteller om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips!





Hvem er jeg?

Navn: Sigrid Molde

Alder: 27 år

Fra: Bergen

Studerte: Anvendt Datateknologi ved OsloMet og Master i Informatikk: design, bruk og interaksjon ved UiO 

Jobbet som designer i 5 måneder



Når jeg startet på utdanningen min for 5 år siden så jeg for meg en fremtid som utvikler. Underveis ble jeg introdusert til designfaget, noe jeg på den tid tenkte at jeg på ingen måte hadde god nok kreativitet til å gå videre med. Gjennom de første årene interesserte jeg meg allikevel mer og mer for dette faget, og oppdaget at design kunne være så utrolig mye mer. Alt fra prosess til informasjonsarkitektur, konseptutvikling til innsikt og analyse, og mye mye mer. Havet av ulike retninger innenfor design gjorde det tydelig at dette var retning for meg. Her fikk jeg muligheten til å stå i krysningspunktet mellom utvikling, forretning og brukeren.

Hva gjør jeg?

I dag sitter jeg på prosjektet Ruteplanlegger for turister. Prosjektet bygger på data fra Statens Vegvesen og Kartverket for å skape en innovativ tjeneste som tilrettelegger for bilferieopplevelser i Norge. Her har jeg fått jobbet med hele produktutviklingsreisen fra idé- og konseptutvikling, til implementering, videreutvikling og måling av effekt. Selve prosjektet er veldig spennende i seg selv, men det som virkelig har pirret mestringsfølelsen er å jobbe med nye verktøy som Google Analytics 4 og OKR-målinger. Dette har vi brukt for både sette retningen til teamet og produktet, og måle at det vi utvikler oppnår ønsket effekt.





Hvilket tips ville jeg gitt meg selv i starten av oppdraget/karrieren?

Inviter inn utviklerne så mye som mulig i designprosessen. De sitter på en haug av verdifull kompetanse og synspunkter som er fint å få med så tidlig som mulig. Og tegn sammen, ofte. Denne lærdommen fikk jeg da teamet mitt la merke til at kommunikasjonen mellom design og teknologi ikke var så optimalt som vi så for oss at den kunne være. Noe av grunnen til dette var at jeg selv var litt for knepen med å plukke opp penn og papir i diskusjoner. Etter å ha satt fokus på dette selv, og samtidig oppfordret utviklerne til å gjøre det samme, har vi sett en betydelig forbedring i effektivitet og kommunikasjon innad i teamet vårt.


Hva eller hvem inspirerer deg?

Teamet jeg har jobbet med siste måneden er de som inspirerer meg om dagen. Ettersom året nærmer seg slutten har jeg brukt en del tid på å reflektere over første halvåret i jobb og hva jeg har lært. Det som virkelig skiller seg ut er hvor god teamdynamikk vi har fått til på kort tid, og hvordan dette har hjulpet oss med å jobbe mot samme mål for produktet. Også har det jo gjort de første månedene i Bekk så gøy!

Designdrypp med: Sigrid Molde

Det er lite som er like inspirerende som å kunne løse sine egne problemer med teknologi! Les om hvordan jeg, som ivrig toppturentusiast, har tilgjengeliggjort snøskredvarselet fra varsom.no som app til Garmin-klokker.

Når vinteren kommer, og det endelig kommer snø i fjellene, drar jeg på tur. Aller helst med toppturski på beina. Og når man går på topptur er det veldig lurt å ha kontroll på skredvarselet! NVE publiserer daglige skredvarsler for de fleste regioner i Norge mellom mellom 1. desember og 31. mai årlig på varsom.no, og disse varslene kan være livsviktig informasjon som bidrar både i turplanlegging, og til å ta trygge valg underveis på turen.

Inspirasjon 💡

Varsom tilbyr allerede apper for å lese skredvarselet på mobilen, men når eks-kollega Jonas Follesø lagde en app for å vise skredvarselet på Apple Watch, fikk jeg inspirasjon til å lage en app for Garmin også, siden jeg har vært fan av Garmin sine klokker helt siden jeg kjøpte min første fēnix for mange år siden.

Jeg hadde også flere ganger irritert meg over at Varsom sin iOS-app ikke synkroniserer varselet offline til telefonen. Det gjør at det er litt vanskelig å sjekke varselet ute i felt eller på parkeringen, hvis man skulle ha glemt å sjekke det før man drar hjemmefra. Derfor var en av hovedprioriteringene for appen min at varselet skulle synkroniseres til klokka, slik at man kunne få lest det også uten internett.

Monkey C, monkey do 🐒

Da jeg startet på prosjektet hadde jeg ingen tidligere erfaring med klokkeprogrammering av noe slag, og da iallefall ikke Garmin sitt økosystem. Det ble derfor tidlig klart at prosjektet kom til å ha en relativt bratt læringskurve. 

For å programmere apper til klokkene tilbyr Garmin en SDK som benytter et hjemmesnekra programmeringsspråk som heter Monkey C 🐵. Monkey C er litt som om Javascript og Java fikk et barn sammen, så heldigvis føles språket relativt kjent hvis man har programmert med noen av de før. Visual Studio Code er den anbefalte IDEen å bruke, og Garmin har en offisiell plug-in som anbefales brukt til utvikling. Totalt sett har det gått veldig greit å komme i gang med, bortsett fra to ting: Minne og skjermplass.

Minne 💾

I tillegg til utfordringene med programmeringsspråk og SDK, ble det også ganske raskt klart at et av hovedproblemene med å få appen til å kjøre, kom til å være tilgjengelig minne på klokkene. Jeg ønsket å støtte så mange klokker som mulig når jeg først var i gang, og ble da raskt klar over at mange av de litt eldre klokkene har særdeles begrenset minnekapasitet. Noen klokker har så lite som 20kb(!) tilgjengelig minne når appen kjører. 

Så på grunn av dette ble det raskt klart at jeg ble nødt til å skrive et proxy-API mellom Varsom sitt API og klokkene, slik at klokkene ikke gikk tom for minne når de spurte Varsom om skredvarselet. I tillegg måtte appen tilpasses relativt grundig slik at jeg ikke gjorde for mye fancy greier samtidig, og gikk tom for minne 💥. 

Det var egentlig ganske artig å forholde seg til at man har en minnebegrensning, siden det er sjeldent man tenker på minnekostnaden av programmeringen man driver med i det daglige.

Skjermplass ⌚️

En annen interessant problemstilling når man jobber med klokke som flate, er mengden tilgjengelig skjermplass. I det daglige er jeg vant med å å jobbe på vesentlig større flater, og jeg trenger egentlig aldri å tenke på om det jeg vil vise får plass på skjermen eller ikke. På klokker er det helt motsatt: Man har nesten ingen plass til å vise den informasjonen man vil.

Et skredvarsel består av flere deler. Det viktigste er selvsagt selve faregraden, som går fra 1 til 5, samt en beskrivende tekst. Men det er også en annen veldig viktig del av varselet: Aktuelle skredproblemer.

Skredproblemene for et gitt varsel sier noe mer spesifikt om hvilke farer som befinner seg i fjellet. Hvilke himmelretninger er farlige, hva slags type skred er forventet, og hvor høyt eller lavt må man befinne seg for å være i faresonen. Det var viktig for meg å få med disse skredproblemene inn i appen når jeg først skulle vise skredvarselet på klokka, og jeg ble derfor nødt til å legge inn en stor innsats for å få vist en oppsummering av skredproblemene uten at all skjermplass ble brukt opp.

Betaling 💸

Når jeg først måtte etablere en backend for å kunne støtte appen, bestemte jeg meg for at jeg ville ta litt betalt dersom den skulle ut til massene, slik at jeg kunne få dekket serverkostnader og litt til uten å gå i minus. Jeg endte derfor med en sum på 30kr per år for å bruke appen. 

I motsetning til Apple og Google, tilbyr ikke Garmin noen direkte måte å ta betalt for apper på i sin app store, så det må man ordne selv.

Jeg hadde ingen erfaring med integrering mot betalingsløsninger, men Vipps virket som et naturlig alternativ, siden omtrent alle har det, og det er veldig enkelt for brukere å gjennomføre betalinger. Jeg integrerte derfor med Vipps som betalingsløsning, og i høst har jeg også integrert med Stripe, slik at også folk som ikke har Vipps kan få skaffet seg appen.

Backend ⚙️

Appen består av to deler: Selve klokke-appen, og en backend som ligger på skredvarsel.app. Backenden fungerer som API for klokka og frontend for betaling av abonnement.

Backenden er skrevet i .NET, med PostgreSQL som database, og Hangfire for å kjøre periodiske jobber for å synkronisere mot Vipps. Frontendløsningen er en veldig enkel React/Vite-app, som bruker Chakra UI som komponentbibliotek. Backenden integrerer med Vipps Recurring og Stripe Subscriptions for å gjennomføre betalinger, og man kan logge inn med Vipps, Google eller Facebook.

Ønsket mitt når jeg lagde backenden var å bruke flest mulig kjente teknologier, siden jeg allerede hadde mer enn nok med å lære meg Garmin SDKen og Monkey C for å lage klokkeappen.

Både appen og backenden er åpen kildekode, og kildekoden kan finnes på GitHub.

Status 🏔️

Jeg begynte å jobbe med appen i februar 2023, og satte meg et mål om å prøve å få lansert før skisesongen var over. I starten av april fikk jeg ut første versjon, og etter litt blæsting på diverse Facebook-grupper for toppturer, fikk jeg raskt mine første brukere. Jeg var også så heldig å få en artikkel om appen min i Fri Flyt, noe som virkelig satte fart på nedlastingene. 

Jeg har lært masse om både klokkeprogrammering, små skjermer, minneoptimalisering, og integrasjon med betalingsløsninger. Alt i alt har det sålangt vært et veldig givende prosjekt, og det har gitt meg kunnskap som jeg allerede har fått bruk for i jobbsammenheng.

I tillegg til å kontinuerlig støtte nye klokker, har jeg i fremtiden planer om å få inn støtte for å automatisk velge region basert på GPS-posisjonen til klokken, samt støtte planlagte endringer som Varsom innfører rundt skredvarslingsregioner i 2024/2025 sesongen.

I skrivende stund har appen litt over 500 brukere, og ser ut til å fungere fint for de aller fleste. Den støtter omtrent alle Garmin-klokker som er lansert de siste 5 årene, og henter automatisk skredvarselet hver time hele vinteren. Så hvis du skal på topptur i vinter, ta en titt da vel?

Du finner mer informasjon her ➡️ skredvarsel.app

Skredvarsel for Garmin ⛷️⌚️

There are many ways to solve problems in React, some will say too many. In a large code base it is helpful if the developers are united about the way to maintain the code base. Take a look at the topics I present to you in this article, which one do you use and are you and your team on the same page?

React is an unopinionated JavaScript library, meaning that the user can choose freely how to solve a problem. There are no decisions made by the framework on how to specifically write your code. Due to this, I have experienced that many developers have their subjective way of structuring the code. Having a code base with many ways to write and organize your code can be messy and hard to keep track of. Therefore, it is important to have a set of conventions to follow in your codebase.

During my time as a React developer, I have encountered several ways to solve different problems, and personally, I don't like all of them. So, I want to present the five topics I have discussed the most at work.

Take a look at the topics in the article; do you have a preferred way to solve a problem, and are you and your team on the same page?

Named or Default Exports

Let's begin with a simple one: How do you want to make your components available for other components? There are two ways to export your component so you can use it across files: either named exports or default exports. Let's take a look at both of them:

Default exports

When exporting your component as the default, you can export a single value from that given module. You can only export one component from a file as the default; the other exports must be named if you want to make more components available from the same file. Take a look at the example of exporting a component as the default:

How you export it will tell you how you must import it. And when importing a component that is exported as the default in another file, you can name it the same as the name of the component where you are importing it:

Personally, I think the syntax for importing this is clean, not too many curly brackets and clutter for the human eye; you only export one value from a given module (which is nice, structuring your components in separate files). However, you can also import and give the component whatever name you want, like this:

Giving the user (aka the developer) the possibility to name the import as they want may lead to inconsistencies between the export and the import. Another downside to this approach is if you want to rename your file. If you rename your component and forget to update the imports, you quickly get a mismatch between the component name and the imported name. It may become a real head-scratcher for future teammates searching for the component when debugging.

Named exports

When exporting your component as a named export, the name has to match when you export it and when you import it. 

Exporting a named export:

Importing a named export

Using named exports will make renaming much easier. Giving your component a new name will force you to remember to rename the imports since refactoring components gives the opportunity to automatically update the references or give you a TypeScript error.

Naming of files

Let's say you want to develop a new feature, and you are creating the file that will be the main component for this feature. What do you call it? I have practiced both naming it index.tsx but also experienced the advantages of a more descriptive filename as CoolFeature.tsx.

Calling files index.tsx

In my previous project, we always called the main file index.tsx, as it makes it easy to see what was the "entry point" for this feature when you are looking in a given folder.

Example of a feature with an index.tsx file as the entry point:

When quickly scanning content of the "CoolFeature" folder, you can see which file you can open to begin exploring the feature. However, searching for index.tsx in a global search in your very large code base will result in tens or even hundreds of occurrences in the search result.

Same name as the folder

Another way is to have the entry file having the same name as the folder and the feature it represents. From the example above with the "CoolFeature" folder, we can have a more descriptive filename like CoolFeature.tsx instead of index.tsx:

It is not as easy to scan as index since the name will be different in every folder, but on the other side, it is easy to search for as it (hopefully) results in a singular match across the code base. It is also important to remember to rename the entry file as well as the folder name when refactoring features and giving them new names.

Naming of Props

Most components have props since it is the most common way to share data between your components. Since we live in 2023, it is common to use TypeScript to ensure type safety for your component, but what are you naming the type for the props?

You have two options: either name it just Props or prefixing it with the name of the component it belongs to.

How it will look like when prefixing the prop interface with the name of the component:

Naming the interface as just Props

Both cases have their pros and cons as I see it. By naming it Props, it is easy to scan in a component, and you avoid line breaks. However, searching in a codebase after the word "Props" will result in many matches. Further on, if you want to export the type you will get name clashes since all your objects are named Props. (This can easily be solved by giving it another name when importing it: import { Props as MyComponentProps }). By prefixing Props, it is very easy to search for, but it drowns in long variable names and results in long lines (I don't like long lines). I also feel it is redundant naming of your types.


Bonus quarrel: Do you define the props over or under the component?

Regular Functions vs. Arrow Functions

Functions are essential when creating a React application, as they are the building blocks of React. Mainly there are two ways to define a function in JavaScript: either by using regular functions or using arrow functions.

Writing your component as a regular function is a known way to write a function and was the only way to write functions until ES6 was released. Take a look at the example:

Writing your component with the arrow function syntax is more terse and might, for some people, be more readable. 

It is also nice when you want a short hand for returning a single expression statement:

A functional difference for these two ways to write a function is the meaning of this. (In regular function, this changes according to the way that function is invoked; read more about it here). However, after the release of React 16 with functional components, the majority of React developers don't need to be concerned about this.

Bonus: In addition to deciding on how to declare your React components, what about the helper functions inside the component?

Ternary Operator or Early returns

The ternary operator is a conditional operator in JavaScript that allows you to return one value if the condition is true and another return if the condition is false. It is kind of a shorthand for if/else. In the simplest way, you can have a ternary operator which returns some variables based on a condition:

It is also nice to use it for conditional rendering; take a look at the example below which returns a component instead.

Another way to return a component is in the traditional if/else:

Ternary operators are nice, and I use them frequently as they often result in fewer lines of code. However, I have experienced that the code can be hard to read with a ternary operator in the middle of a big component. Especially if the expression breaks over several lines (and yes, part of the problem may be that the component is too big). A way to break out of big return statements is early returns.

It may be confusing to have several return statements inside a component when debugging what that component actually returns.

———

Hope you have gathered some arguments you can bring to your team. Happy arguing!

React fights you can have with your team

Den utdaterte tilnærmingen til IT-utvikling i offentlig sektor får alvorlige konsekvenser for viktige samfunnsfunksjoner

Denne artikkelen ble først publisert i forkortet versjon på Digi.no

-

Nylig kom Riksrevisjonen med kritikk av digitaliseringen både i politiet og helsesektoren. Situasjonen gir store samfunnsmessige utfordringer, som dårligere bekjempelse av kriminalitet og redusert trygghet for innbyggerne. Den kan gå ut over pasientsikkerheten og binder opp unødvendig tid for helsepersonell.

Datadelingen i forvaltningen er heller ikke god nok, konkluderte Riksrevisjonen i sin tredje rapport fra samme dag. Kort tid senere fikk Nav en bot på 20 millioner kroner for brudd på personvernet. Nav peker blant annet på gamle datasystemer som årsaken. Til og med brukervennlighet i systemer for kritiske samfunnsfunksjoner er satt på dagsordenen, som Tone Nordbø i UXNorge ny(de)lig kommenterte.

Det er nemlig ikke bare AI-hypen og rammevilkår for privat sektor som må håndteres av en ny digitaliseringsminister og -strategi. Det kan nesten ikke sies med store nok bokstaver:

Den utdaterte tilnærmingen til IT-utvikling i offentlig sektor gir alvorlige konsekvenser for viktige samfunnsfunksjoner.

Historisk har vi riktignok hatt flere velmenende tiltak for å hjelpe offentlig sektor å komme i fart, som Skate og Digitaliseringsrådet, som nylig kom med sin erfaringsrapport for 2023. Men snølandskapet ligger tungt over den offentlige digitaliseringen, og velmenende råd fra Digitaliseringsrådet blir som saltpåstrøing i denne sammenhengen. Vi trenger kraftigere virkemidler.

Vi trenger en brøytebil. Noen som setter retning og rydder vei.

Det er særlig fire områder det må brøytes vei for å transformere offentlig sektor til å være i stand til å levere gode digitale tjenester. Vi får håpe Karianne Tung stiller med rett førerkortklasse.

1. Kompetansen rundt hvordan vi organiserer oss for IT-utvikling er for lav, selv i IT-avdelinger

Digitale teknologier er kilde nummer én til forbedring og effektivisering av offentlige tjenester. Dette gjelder i hver eneste seksjon, avdeling, divisjon, enhet, på tvers av alle statlige forvaltningsorgan, og i alle kommuner. Det er på den digitale arenaen at innbyggere møter staten, og hvor tjenestene oftest leveres.

Selv om alt dette er ubestridt, kan vi spørre ut i luften hvor stor andel av ledergrupper på ulike nivåer som har god og oppdatert kompetanse på hvordan vi organiserer oss for IT-utvikling?

Dette er en litt annen tilnærming enn i digitaliseringsstrategien. Det handler om at ledere må forstå landskapet og hvor vi skal. Det er riktignok alltid lett å peke på lederansvaret, det gjelder i all slags retninger, og det å være leder i offentlig sektor må sies å være krevende. Men gapet mellom hvor sentralt en forståelse av IT-utvikling er, hvor manglende kompetansen er, og hvor stor Dunning-Kruger-effekten er, virker å være særdeles stort. Dette er blant annet årsaken til at vi stadig ser fake agile.

Gapet er så stort, og så utbredt, at jeg synes vår nye digitaliseringsminister bør se på saken. En ny digitaliseringsstrategi kan sette krav - eller i det minste peke ut en retning - for en større digital kompetanseutvikling av ledere over hele fjøla.

2. Fag og teknologi blir fortsatt sett på som to vidt forskjellige ting i tjenesteutviklingen i offentlig sektor. Det fører til interne gnisninger som gir kompromisser og manglende digital transformasjon

Den manglende kompetansen fører nok til enda en utfordring som er overraskende utbredt: fag og teknologi betraktes fortsatt som separate områder i utviklingen av tjenester, i en urovekkende stor del av sektoren. Det slapp vi kanskje unna med på 90-tallet, men nå fremstår det som prehistorisk og skadelig. Når mangelfull digitalisering setter tryggheten til innbyggere i fare, så er politiet en IT-virksomhet - ikke bare uniformer i gata. Tilsvarende med helsesektoren.

For å få utnyttet den kraften digitale teknologier gir, så må vi integrere faglig ekspertise med teknologisk kunnskap for å skape helhetlige, brukervennlige og nyttige digitale løsninger. Det er helt elementært egentlig, men ser du på nesten hvilken som helst offentlig virksomhet i dag, så er det ikke det som er historien.

Den ene historien er at IT er tydelig adskilt fra fag, og her er tanken at fag skal legge premissene og så skal IT levere på det. Dette er prehistorisk tankegods, men like fullt overraskende utbredt.

Den andre historien er om virksomheten som er i en transformasjonsfase hvor fag og IT veves inn i hverandre. Et riktig skritt, men det er kun et lite knippe forvaltningsorganer som er her. I denne historien oppleves det som at IT tar seg til rette på bekostning av fagdisiplinene (les: resten av virksomheten). Når IT får mer innflytelse så vil det i alle tilfeller bety at fagdisipliner føler seg forbigått, og at de de facto mister makt. Eller mer presist: de deler på makten i tverrfaglige team.

Denne utfordringen forsterkes av et kompetansegap mellom IT og fag: de ulike fagdisiplinene har ikke (ennå) den kompetansen som er nødvendig for å blomstre i et tverrfaglig miljø.

Resultatet er kompromisser. Vi beholder de samme interne maktbasene og linjefunksjonene, samtidig som vi forsøker å etablere samarbeidsarenaer med tverrfaglighet og autonomi, og så klapper vi oss på skuldren og kaller det smidighet.

Det bør heller styres med stø hånd - både fra digitaliseringsministeren og fra ledernivåene internt i de statlige forvaltningsorganene. Vi trenger en tydeligere visjonær ledelse for tverrfagligheten, og tydelige krav om at vi hever kompetansen nok til å forstå hvor vi skal.

3. Vi er i en kontinuerlig metodisk limbo mellom eldgammel tilnærming til IT-utvikling, og den smidige og kontinuerlige produktutviklingen

Nært beslektet med punkt 2 er det faktum at mange organisasjoner holder fast ved en utdatert tilnærming til utvikling. Den er preget av langvarige og store prosjekter, vannfallsmetodikk, gjerne on-prem, med få prodsettinger og med et skarpt skille mellom utvikling og drift/forvaltning. I tillegg er organisasjonsstrukturen ofte kompleks og ulogisk fra et IT-perspektiv, med ulike ITIL-roller og prosesser spredt ut i hierarkiet.

Den utdaterte tilnærmingen flere virksomheter baserer seg på i dag sementerer skillet mellom fag og IT, og mellom utvikling og drift/forvaltning, og gir oss kunnskapssiloer, og uklare og fragmenterte roller og ansvar. Dette gir langsom IT-utvikling som stadig sørger for at vi er langt unna å få realisert det digitale potensialet vi trenger offentlig sektor.

Det er vanskelig å si kortfattet og konkret hva det skal settes opp mot, og det vi også variere. Men du kommer typisk ikke utenom produkttankegangen som misjonert i bøkene til Marty Cagan, Melissa Perri og Teresa Torres. Så kan vi også nevne utsiden-inn-organisering og Conways lov som veiledende for organiseringen, sammen med Team Topologies. Accelerate har lenge vært en bibel i å fremføre DevOps-tankegangen og hvilke metrikker som betyr noe på IT-siden. Psykologisk trygghet som forklart av Edmundson har gitt en tydelig retning for ledelse, gjerne supplert av resten av Googles prosjekter Oxygen og Aristotle. OKR og tight-loose-tight er også sentralt. Alt dette og mye mye mer utgjør DNAet for dagens og fremtidens IT-utvikling. Det er ikke en fase vi er i, det er resultatet av en taktfast gang i en ny retning. Dersom alle ledere er inneforstått med, og agerer iht., disse prinsippene/litteraturen nevnt over, så er vi på god vei til å løse punkt 1 også. Men det er lang vei dit.

Her må ny digitaliseringsstrategi - og minister - peke ut en tydelig retning. Dagens gjeldende digitaliseringsstrategi var på mange måter god, men den hoppet like godt bukk over hele smidig-begrepet, når den hadde sjansen til å bruke det til å kickstarte transformasjonsprosessen i offentlig sektor. La oss ikke la sjansen glippe nå også. Ikke vær redd for å brøyte vei også på det metodiske.

Punkt 1, 2 og 3 er nok også hovedårsakene til at vi fortsatt har eldgamle prosjektbaserte finansieringsmodeller for IT-utvikling. Finansieringsmodellene gjør det også spesielt vanskelig å ha en tverrfaglig tilnærming til lovverket, fordi begrensningene som ligger i regelverket alltid vil oppdages sent i en prosjekt. Som eminent presentert av NAVs Audun F. Strand og Truls Jørgensen på JavaZone: regelverk er software.


4. Den juridiske digitaliseringsdialogen må bli smidigere

Nært inntil alt som digitaliseres av fag i offentlig sektor har et lovverk som definerer rammene. For å kunne utvikle effektive digitale løsninger er det viktig å ha en tett kobling mellom IT-og- fag-miljøet og de politiske regelverksprosessene. Det er nødvendig å forstå både de faglige kravene og behovene som lovgivningen stiller, samtidig som man tar hensyn til teknologiske muligheter og begrensninger. En bedre samhandling mellom disse områdene kan bidra til å utvikle digitale løsninger som er i tråd med både faglige og juridiske krav. Det er dessverre bare når kode setter begrensninger for politikk at politikerne verdsetter smidighet og tverrfaglig samarbeid. Dette er vi avhengig av å oppdage på et tidlig tidspunkt. I tillegg - som Riksrevisjonen viste - så er juridiske spørsmål den største hindringen for å dele data med andre virksomheter.

For å løse dette i praksis må de for eksempel opprettes nye arenaer hvor IT-direktører, produktledere og utviklere har direkte dialog med departementene. Som Catherine Janson sa i en nylig podcast: da hun kom inn som IT-direktør i politiet så fikk hun ikke snakke med departementet uten å ha med seg en “voksen”. Her er det nok direktoratene selv som setter ødeleggende begrensninger for seg selv, men det er beskrivende om hvordan formalismen som preger dialogen er direkte ødeleggende for den politisk-juridiske tverrfagligheten som må til for å levere bedre digitale tjenester.

Lovverket definerer rammene for hva IT skal løse, og når lovverket er komplekst så må de digitale løsningene ivareta kompleksiteten (se Teslers lov). Det betyr at vi enten får dyr og kompleks utvikling av IT, eller at vi blir flinkere til å ta den juridiske digitaliseringsdialogen, selv om det kan gi uklarhet i grensegangen mot styringsdialogen. Sistnevnte blir etter min mening det åpenbare minste ondet.

Det handler i første omgang bare om å skape en dialogarena. Covid viste oss at det kunne gjøres, og om vi bare fikk en ørliten bit av den smidigheten og tverrfagligheten så vil det være transformativt for tjenesteutviklingen i offentlig sektor.



Nå har hun sjansen

Karianne Tung sa selv for to år siden at “det er politikkens oppgave å stake ut kursen”, og “så er jeg litt usikker på hvor store grep politikerne tør å ta”.

Nå har hun endelig sjansen. Å stake ut kursen og brøyte vei på disse fire områdene vil kreve en annen tilnærming til digitalisering i offentlig sektor enn vi har hatt tidligere. Det vil bety å legge premisser for mye av organiseringen internt i hver etat/direktorat - å tråkke i bedet til andre ministre.

Jeg håper hun tør.

Vi trenger en digitaliseringsbrøytebil, ikke et Digitaliseringsråd

Et forsøk på å løse “hvem eier den tjenesten der?” med noen tommelfingerregler og backstage 👍👎

Vi har alle vært der

“Det vi trenger er en oversikt over tjenestene våre”, sier den ene. En av de andre sier: “Jeg tror vi har noe liggende i confluence om det. Kanskje vi kan bruke den og friske opp litt?” I virkeligheten ligger det sikkert flere sånne oversikter i confluence. Og noen excel-ark. Og kanskje noen word-tabeller. Drøssevis av greier.

Jeg har lyst til å dele noen tanker og erfaringer rundt eierskap, noen enkle regler for å kanskje få gjøre det lettere å få til og et forsøk på å få has på den hersens utdaterte oversikten.

Del 1: Ei det

Diskusjonen dukka opp fordi tjeneste X ikke funker. Noen tenkte at Team Vollgrav (oppdikta navn) var ansvarlig, men de trodde Team Borgtårn holdt i tøylene. Det viser seg til slutt at ved forrige omorganisering glemte man å fordele litt ansvar. Man ble enige om det meste, men et par tjenester var vanskelig å lande og med tiden glemte man de også litt. En av tjenestene er det jo de fra det gamle Team Bro (som nå ikke eksisterer lenger) som hadde. Det er jo de folka som kunne det. Men det viser seg jo at de driver med andre ting, Team Bro er jo historie for lengst.

Det er ikke bare én gang jeg har havna i en eller annen variant av det her. Det er ikke med vilje, men det skjer likevel. Resultatet er tjenester som enten sier pang og går i stykker, eller kanskje de er potensielle sikkerhetsrisikoer. Man må uansett bruke masse energi på å gå opp eierskapet når noe dukker opp, siden det ikke ble tatt i den originale runder av ansvarsfordeling.

Reglene

Så! Hvordan kommer vi dette til livs? Hvordan får vi tydelig eierskap og folk til å bry seg og føle at de må ta tak i ting? At det ikke er noen andre som gjør det. Jeg har tro på at det gir et bedre klokkeklart bedre produkt i den andre enden. Grunnene er for mange til å gå inn på her, men tenk på din egen organisasjon og hva det gjør/hadde gjort.

Personlig har jeg troa på noen prinsipper jeg har lært og kjemper for.

1. Det er én, og bare én eier (som er et team)

Hvis flere eier noe, så eier ingen det. I hvert fall når det kommer til vedlikehold. Da tenker man alltid at “de andre” tar det. Men også for koden ellers. Det er ingenting i veien for å samarbeide, men hvis noen andre hele tiden gjør endringer man ikke ser, skjønner eller forstår føler man ikke voldsomt eierskap for den koden. Da slutter man å bry seg. Kanskje forfaller ting. En og bare en.

2. Du kan ikke gi fra deg ansvaret uten at det overleveres til noen andre

Den neste regelen er for å unngå “orphans”: Tjenester uten eiere. Kanskje man har bytta navn og ansvarsområder for teamene? Vel da må de eksisterende tjenestene fordeles til andre/nye team. Ja, alle sammen. Nei, det passer kanskje ikke like bra inn i den nye oppdelingen, men det må fordeles likevel. Nei, det kan ikke plasseres hos flere teams. Én og bare én.

3. Det går bra å ha noe man ikke skjønner eller kan helt

Hvis man skal fordele ting på denne måten vil man ha noen ting “ingen” kan eller vil ha. Hva gjør man da? Jeg synes bare man skal fordele dem, jeg. Det er litt skummelt å eie noe man ikke kan. Samtidig, det at du kjenner på den følelsen betyr også at du føler på et eierskap. Riktignok et vondt ett, men for organisasjonen er det sunt. Noen bryr seg. Du bryr deg. Det er bra! Så får man ta tak i det når man må forholde seg til den. Kanskje be om litt hjelp, lære litt av de som satt med det en gang. Vi er jo kollegaer, tross alt!

Da vi slipper at tjenestene våre faller mellom to stoler og blir glemt. Vi slipper at det koster masse energi å gå opp eierskap i ettertid. Vi bygger eierskap. Og det tenker jeg er bra det.

Del 2: Ut med excel-arket og inn med Backstage

For de som kjenner backstage.io så tenker man gjerne utviklerportal. Det er det også - faktisk en ganske kul en! I jakten på gode utviklerverktøy tok vi dette i bruk hos en kunde jeg sitter på. Har du ikke sett på det anbefaler jeg å ta en titt. Vi tar en lynrask titt på tjenesteeierskap her, men hvis konsepter som å “samle dokumentasjonen og gjøre den mer tilgjengelig” eller “god templating av nye repoer” er ting du synes høres spennende ut bør du absolutt ta en titt!

Men her skal jeg snakke om bare en liten del av det. Nemlig owner-feltet i speccen. Kan dette få has på de utdaterte oversiktene?

Hos oss settes owner til github-teamets navn. Backstage importerer allerede en del fra github-organisasjonen, inkludert teamene. Det trenger vi ikke vedlikeholde.

En catalog-fil i backstage ser typisk ut som noe slikt:

Det spennende feltet her er altså owner. Fyller vi inn dette i repoene våre i github får vi ting som dette i backstage:



Hvorfor gir dette en bedre oversikt enn excel?

Vel, det er ikke sikkert det er det. Det gjenstår å se om dette hjelper på å løse det eller ikke. Men! Erfaringene vi har fått er:

Det er digg å ha denne definisjonen kodenær og ikke i separate dokumentasjons-systemer (som confluence). Det er lett å endre og et eventuelt utdatert eierskap synliggjøres, så man får lyst til å rydde opp i det.

Når medlemmer i team forandrer seg gjør vi jo det i github og det reflekteres automatisk i backstage. Digg.

Det er lett å lage en liste med “NO-OWNER” tjenester som er synlig og gjør litt vondt.

Én og bare én. Og ett sted hvor eier defineres. Ett sted å lete når du vil finne ut hvem som sitter med noe. Ett sted å se hva du er ansvarlig for. Og ikke minst én eier av tjenesten.

Så får vi se om vi se om en stund om vi får bukt med tvetydig eierskap eller om vi har laget en ny type excel-ark da.