Å opprettholde suksess og relevans krever mer enn bare en vellykket lansering. Uten påfølgende, kontinuerlig videreutvikling forvitrer digitale produkter fort. Hvordan kan vi da tilrettelegge for endringsevnen som trengs for å holde produktene relevante? I denne artikkelen utforsker vi hvordan kunnskap og eierskap kan bevares i teamet og hva det betyr for NAVs endringsevne. La oss begynne med å se nærmere på hvorfor endringsevne er viktig.

En kontinuerlig strøm av endringer som aldri stopper

For å opprettholde produktets kvalitet og verdi over tid, må vi gi det kontinuerlig pleie og omsorg. Det betyr at vi må investere jevnt i produktet også etter det er lansert. Brukerforventningene øker stadig og vi må holde tritt med skiftende omgivelser for øvrig. Et endringsbehov kan for eksempel trigges av at:

Forbedringen av forsiden på nav.no er et godt eksempel på sistnevnte. Der ser vi hvordan læring vi gjør underveis, mens produktet er i bruk, kan gjøre oss bevisste på endringer som må til for å løse brukernes behov på en bedre måte. Det bidrar til å opprettholde eller øke kvalitet og verdi.

Produktet forvitrer om vi ikke vedlikeholder det. Kvalitet og verdi reduseres gradvis, samtidig som vedlikeholdsbehovet øker. Det gir et etterslep som innebærer økt risiko og uforutsigbarhet. Vi risikerer for eksempel å måtte fikse andre, underliggende ting før vi kan ta tak i en nyoppdaget sårbarhet eller andre akutte behov. Det kan medføre lang nedetid og følgelig gi ringvirkninger for både borgere og tilstøtende applikasjoner og produkter. I sum kan det derfor koste oss mer å neglisjere produktet enn å aktivt vedlikeholde det. Om forvitringen foregår lenge nok vil vi til slutt havne i en situasjon hvor produktet går teknisk konkurs. Det betyr at det ikke lenger er reparerbart og at det eneste reelle alternativet er å lage det på nytt. Det er et dyrt alternativ til kontinuerlig vedlikehold og videreutvikling.

For å skape endringsevne må vi ta vare på folk og kunnskap

Etter hvert som produktet vokser i omfang og kompleksitet vil det kreve mer av oss å videreutvikle det på en trygg og bærekraftig måte. Vi må ha oversikt over hvordan produktet henger sammen med og løser problemer i den virkelige verden. Vi må ha mentale modeller av hvordan det er skrudd sammen og hvordan de ulike delene fungerer og interagerer med hverandre. Vi må kjenne domenet og vi må forstå både brukernes og forretningens behov. Denne kunnskapen bygges over tid, mens vi arbeider med produktet, og den lar seg sjelden dokumentere fullstendig eller overføres kun via dokumentasjon. Mye av det er taus kunnskap, som kun kan læres via handling og erfaring.

Koden, designet og hele brukeropplevelsen vi leverer er et resultat av denne kunnskapen og læringen, og det er også der magien ligger. Alberto Brandolini sier det fint:

“Software development is a learning process; Working code is a side effect”
– Alberto Brandolini (Introducing EventStorming, 2021)

Digitale produkter er med andre ord sterkt koblet til menneskene som lager dem. Denne innsikten forteller oss at det er teamet, som har den nevnte kunnskapen om domene, problem og løsning, som bør ha ansvaret for å videreutvikle produktet i hele dets levetid. Det betyr at vi ikke kan se på mennesker som ressurser som enkelt og uten videre kan erstatte hverandre, når vi driver med kunnskapsarbeid.

Tap av kunnskap er kostbart

Om teamet oppløses, nedskaleres eller utsettes for utskiftninger som medfører større tap av kunnskap om produktet, kan vi få store utfordringer med å ta vare på det. Det samme skjer om ansvaret for produktet overleveres til andre, som ikke har deltatt i den nevnte læringen og kunnskapsbyggingen underveis.

Peter Naur forklarer det slik:

“The death of a program happens when the programmer team possessing its theory is dissolved. [...] The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered”
– Peter Naur (Programming as Theory Building, 1985)

Her snakker han utelukkende om utviklere. I dagens kontekst kan vi trygt si at læringen og kunnskapsbyggingen, som han kaller theory building, er viktig på tvers av andre fagdisipliner i teamet også – som for eksempel juss, produktledelse og design.

Det er i hovedsak to måter å tilegne seg den nødvendige kunnskapen og oversikten på. Enten ved å være med fra starten, eller ved å arbeide sammen med noen som har vært med lenge og som kjenner detaljene. Hvor lang tid det tar for nye teammedlemmer å komme ordentlig i gang, avhenger blant annet av kompleksitet og omfang. La oss si det kan ta noen måneder. Relasjoner skal bygges, mentale modeller skal dannes og mye skal læres. Å flytte folk mellom team kan derfor være en kostbar affære. Onboarding kan for øvrig være en belastning for teamet også. Det er for eksempel ikke gitt at farten umiddelbart går opp, om teamet utvides. Fred Brooks påpeker snarere det motsatte; kapasiteten og farten vil mest sannsynlig først gå ned.

Vi må endre team med omhu

Dette betyr ikke at team aldri kan endres, men at endringen bør gjøres med nøysomhet og omhu, og ved å involvere teamet selv. For hva skjer om vi flytter på for mange folk på kort tid? Videre gir det oss noe å tenke på når vi endrer team og ansvarsområder, og kanskje flytter ansvar fra et team til et annet. Flytting av folk og ansvar er en sosioteknisk problemstilling hvor vi må se teknologi og mennesker i en større sammenheng.

Grep for å gjøre teamet mer fleksibelt og robust

En viss grad av stabilitet er nødvendig for at teamet skal kunne ivareta sin evne til å eie både problem og løsning. Samtidig trenger NAV fleksibilitet til å endre prioriteringer og å flytte folk mellom team ved behov. I tillegg kan det eksistere ønsker om rotasjon hos den enkelte. Å tilrettelegge for intern mobilitet er positivt fordi det hjelper oss å holde på medarbeidere. Det gjør også at gode praksiser og kunnskap deles og spres, og at team og avdelinger får nye kontaktpunkter mellom seg. Slik fleksibilitet går på bekostning av stabilitet, men det finnes heldigvis grep vi kan ta for å gjøre teamet mer robust og mindre sårbart for endring.

Tverrfaglig møljeprogrammering

Et opplagt nyttig grep er å dele kunnskap og kompetanse i teamet, slik at flere kan fylle hverandres sko. Det reduserer nøkkelpersonrisiko, fjerner flaskehalser og gjør oss mindre skadelidende om noen er fraværende eller forlater teamet. Parprogrammering og mobprogrammering – også kalt møljeprogrammering – hvor to eller flere løser problemer og lærer sammen, kan være en måte å gjøre det på. Det må være opp til teamet hvordan og hvor mye de gjør det ene eller det andre, men flere øyne på problemet gir bedre kvalitet. Slikt samarbeid kan gi raskere onboarding og styrke det kollektive eierskapet i teamet, slik at flere kan gjøre endringer flere steder.

Møljeprogrammering er ikke nødvendigvis bare for utviklere. Det har ofte stor nytteverdi om produktledere, designere, domeneeksperter, jurister eller andre med kunnskap om forretningsdomenet også deltar. Det setter oss som team og organisasjon i stand til å gjøre raske avklaringer underveis. Det gjør også at flere lærer og at vi oppnår en omforent forståelse av domene, problem og løsning. Om vi i tillegg skriver kode på en måte som gjør den lettere å lese og forstå, og dermed enklere å snakke om, får vi økt bærekraft i både team og produkt.

Event storming

Event storming er en workshop-teknikk som er velegnet for rask og kollektiv læring om hva som skjer i et system, domene eller forretningsprosess. Teknikken hjelper oss å danne oss et felles bilde av hvordan ting henger sammen, og hvordan det ene avhenger av og påvirkes av det andre. Det gjør det blant annet enklere å oppdage hvordan forretningsprosessen kan forbedres.

Event storming går kort fortalt ut på å samle teammedlemmer, domeneeksperter og andre interessenter i et rom hvor de i felleskap modellerer hendelsene som skjer innenfor domenet. Modelleringen gjøres med post-its i ulike farger på vegg eller tavle. Verdien er ikke modelleringen i seg selv, men diskusjonene, læringen og det omforente språket den resulterer i. Dette er i høyeste grad også en tverrfaglig øvelse. Tech-sjargong legges igjen utenfor døra, og alle kan bidra.

Event storming kan være spesielt nyttig ved onboarding og når vi trenger å gjenoppbygge tapt domenekunnskap i teamet.

Versjonshistorikk som spåkule

Versjonshistorikken inneholder både teknisk og sosial informasjon. Den viser hva som er endret og hvem som har gjort det. Dermed kan den være til hjelp for å se i hvilken grad teamets nåværende medlemmer har eierskap til kodebasen. Det betyr at vi også kan bruke versjonshistorikken til å spå om framtiden og hvor skadelidende teamet blir, i form av tapt kunnskap og eierskap, om noen forlater det. Kanskje finnes det komponenter eller deler av koden hvor enkeltpersoner har vært alene om å gjøre endringer, slik at det for disse delene ikke eksisterer et kollektivt eierskap? Hvor hyppig og nylig disse delene har vært endret kan si noe om hvor viktige de er, og hvor sannsynlig det er at de må endres også i nær fremtid. Om vi i tillegg gjør analyser på kodekompleksitet kan vi få en pekepinn på hvor krevende det er å sette seg inn i dem. Det peker oss i retning av hvor det er fornuftig at flere jobber sammen med hverandre, for å dele kunnskap og bygge kollektivt eierskap i teamet.

Dersom du er interessert i mer om analyser av versjonshistorikk og kode, kan boken Software Design X-rays av Adam Tornhill varmt anbefales.

Hva mer må vi tenke på?

Det finnes mange faktorer som påvirker teamets evne til å opprettholde verdi og kvalitet i produktene de eier. Rammer som inkluderer stabil og forutsigbar finansiering er opplagt en forutsetning. At teamet har nødvendig slakk til forbedringsarbeid og å gjøre det enkelt for seg selv, er en annen. Ansvarsområdet må i tillegg oppleves som håndterbart og få plass i teammedlemmenes hoder. Hva tenker du?

Ta gjerne kontakt på #team-sosioteknisk-værsågod (intern Slack-kanal i NAV) dersom det er noe du lurer på eller vil diskutere angående denne artikkelen.