Uansvarlig produktutvikling vil straffe seg

I forrige artikkel snakket vi om sikkerhetsgjeld og hvordan man unngår å bli en gjeldsslave. Å betale ned økende gjeld hindrer gjelden i å løpe løpsk, men den langsiktige løsningen for å håndtere sikkerhetsgjeld mener vi er å jobbe mer bærekraftig.

Vi skal i denne artikkelen se nærmere på hvordan bærekraftig produktutvikling kan se ut og til slutt gi 4 konkrete tips til hvordan man unngår uansvarlig produktutvikling.

Vi fortsetter å melde at man må slutte med IT-prosjekter hvor det går i store leveranser, urealistiske og rigide tidsplaner, detaljert ressursplanlegging og tids- og kostnadsestimater. Vi må bli smidigere nå!

Her har man dårlige forutsetninger for å raskt omstille seg dersom det måtte komme endringer i prioriteringer og omstendighetene rundt det man lager. Å jobbe produktfokusert i et tverrfaglig autonomt team gir derimot teamet fart, fokus og rask omstillingsevne.

Økende grad av sikkerhetshendelser og sikkerhetsgjeld er enda flere argumenter for at vi må jobbe smidigere med sikkerhet og takle raske omprioriteringer med fokus og spisskompetanse.

På prioriteringsvektskålen hvor man allerede har teknisk gjeld og ny funksjonalitet, må man nå i tillegg plassere sikkerhetsgjeld og balansere dette opp mot hverandre.

– Derfor har omstillingsevnen aldri vært viktigere enn nå.

Bente Hoff, avdelingsdirektør i NSM, sa januar 2022 til NRK:

En kraftig økning i cyberangrep de siste årene tilsier at uansvarlig produktutvikling er et høyrisikospill.

Når vi jobber bærekraftig med produktutvikling i autonome og tverrfaglige team, hvor teamet kontinuerlig jobber med teknisk gjeld, sikkerhetsgjeld og ny funksjonalitet, får vi den balansen i vedlikehold og den omstillingsevnen som disse tider krever.

Hvordan vet du at ditt produkt har for høy sikkerhetsgjeld? Hvilke symptomer kan man se etter? Hvilke tiltak kan man innføre for å betale ned gjelden?

Og klarer vi å sikte mot bærekraftig produktutvikling?

Leveransefokus skaper falske frister som fører til stress for å nå fristene. IT-prosjektet leverer funksjonalitet i henhold til det som er bestilt og prosjektteamet legger fra seg arbeidet når leveransen er ferdig overlevert, puster ut og starter på nye oppgaver.

En gruppe tverrfaglige personer samlet rundt et produkt eller domene, får autonomitet via et tydelig mandat og fokus. Ved å jevnlig prioritere oppgaver sammen med en produkteier som ivaretar forretningsperspektivet, så vil man raskere kunne svare på behov, prioritere og levere verdi.

Tips: spill teamene gode ved å bygge DevOps-verktøystøtte for kontinuerlige leveranser, og sørg for at de leverer mange små endringer jevnlig enn få og store. Teknikker som f.eks. funksjonsbrytere lar deg lansere uferdig funksjonalitet, og man kan dermed innhente tilbakemeldinger med ekte brukere når bryteren er påslått. Slik vil man risikostyre bedre både risiko for, og konsekvenser av, at feil skjer. I tillegg leverer man verdi mer målrettet og behovsprøvd!

Interne overleveringskultur til egne forvaltere skaper skille mellom de som utvikler og de som driver vedlikehold. Vedlikehold i seg selv er ofte ikke spennende nok, dermed jobber utviklerteamet heller med spennende nyutvikling enn å prioritere vedlikehold som gjerne overlates til egne forvalterne.

Unngå overleveringer mellom personer og team — sørg istedet for at produktteamet har en overlapp i kalendertid med personen som besitter kompetansen man ønsker å tilegne seg.

Dyrk derfor heller en kultur hvor produktteamet har et tydelig ansvar og eierskap til det de lager og jobber på en bærekraftig måte. Når man selv må stå opp på natten for å fikse den litt for raske endringen på tampen av arbeidsdagen, så reflekterer man litt ekstra neste gangen man “skal bare”. Nå er det ditt problem i stedet for de på forvaltning.

Tips: ha en vedlikeholdsdag i uken der man jobber med teknisk gjeld (Kaizen-dag! Hack-day!).

Men ikke glem sikkerhetsgjeld også da. Kanskje arrangere en hack-deg-selv-dag i ny og ne?

Det nye stjerneproduktet får all oppmerksomhet og nye sårbarheter i eksisterende produktportefølje går uoppdaget hen fordi ingen overvåker eller kjenner ansvar for produktet som tidligere ble erklært for “ferdig” og som det ikke skal jobbes mer med. Alle pengene er investert i det nye stjerneproduktet.

En portefølje med digitale produkter og tjenester trenger jevnlig prioritering av vedlikehold opp mot ny funksjonalitet på tvers av hele porteføljen. Alle produktteamene i porteføljen må jobbe bærekraftig.

Tips: sørg for gjøre jevnlig sårbarhetsskanning på kode slik at man kan raskt oppdatere de produktene man har ansvaret for. Dermed holder man det svakeste leddet i porteføljen “i sjakk” og gir trusselaktørene en dør mindre å komme inn igjennom.

Bitrot er et begrep for data som råtner over tid. Det samme kan sies om tekniske løsninger som har ligget så lenge at de har råtnet på rot. Verktøy for å kompilere, testmiljø, integrasjoner, utviklingsverktøy osv. har sluttet å fungere fordi ingen har vedlikeholdt verdikjeden til løsningen man lagde

Med andre ord er den tekniske gjelden direkte synlig. Man har antageligvis høy sikkerhetsgjeld attpåtil.

Forsøk en data-drevet tilnærming hvor en måler tid siden forrige produksjonssetting eller hvor lang tid man har hatt kjente sårbarheter i produksjon, og sett grenseverdier som trigger handling av teamet.

Uansett om man måler eller ikke bør man holde hele verdikjeden varm ved å gjøre flere små og ufarlige endringer jevnlig. Ved å jevnlig oppdatere produktet sørger man for å holde hele verdikjeden i bruk samt beholde kompetansen i teamet for å jobbe med produktet. Det kommer godt med den dagen en kritisk sårbarhet blir oppdaget og man må handle raskt.

Tips: “vedlikeholdsdagen” er en fin dag i uken å gjøre gjøre oppdateringer på. Bruk verktøy som varsler om oppdateringer, som f.eks. Dependabot.

Sørg for at teamet balanserer teknisk gjeld og sikkerhetsgjeld opp mot ny funksjonalitet, og kan gjøre dette på en bærekraftig måte hvor man unngår å brenne lyset i begge ender.

Unngå uansvarlig produktutvikling ved å avdekke sikkerhetsgjelden du har, og håndter sikkerhetsgjelden du har igjen på en bærekraftig og smidig måte.

I neste artikkel skal vi se nærmere på hvorfor man bør ha en sikkerhetsutvikler i teamet, og hvorfor vi mener denne rollen er essensiell i hvordan man bør jobbe tverrfaglig og smidig med sikkerhet.