Episode 10: Gjærbaksten

Gjærbakst og programvare har én ting til felles. Sakte, sakte gror de større uten at du ser det.

Hei, Martin her, og du lytter til Fimbul!

Jeg uttalte en gang at «Det problemet der er som gjærbakst. Det ligger helt stille når man ser på det, men gjennom natten vokser det seg dobbelt så stort!»

Du har selvfølgelig bakt før. Og du har selvfølgelig også opplevd at gjærbaksten du har satt har hevet seg større enn du hadde tenkt.

Litt tilsvarende er det med problemer i programvare som du har kjørende i produksjon. Teknisk gjeld i din programvare og dine løsninger, som du kan høre mer om i episode 3 av Fimbul, er som gjærbakst. Selv uten at du at du tar i løsningene vil eksisterende problemer og teknisk gjeld over tid føre til at de kommer ut av kontroll. Man går tom for diskplass. Databaser går fulle. Loggfiler som hoper seg opp. Eller supportsaker i kø. Problemene er like gjerne administrative eller merkantile som tekniske.

Jeg skal ikke trekke metaforer lenger enn nødvendig, for de er egentlig svært dårlige for å illustrere et poeng.

I enhver løsning er det alltid problemer, alltid noe som skulle vært gjort, alltid noe som ikke fungerer som det ideelt sett burde. Og disse problemene øker i omfang over tid. Du får flere kunder, du får flere brukere, du får flere ansatte og ansatte kommer og går. Dette fører til at problemene som nevnt øker over tid, uten at du rører ved dem.

Hvis du er som meg, så elsker du å automatisere ting. Sånn er det også i løsningene du har i drift. Det meste kan og bør automatiseres. Men det betyr ikke at man skal automatisere alt alltid. La meg gi noen eksempler.

Et problem som kun oppstår en gang i året, og som tar en person et par timer å fikse, kan kanskje forbli som det er, fordi jobben med å lage robust automatisk håndtering av problemet overstiger jobben med å håndtere det manuelt.

På den andre siden, et problem som oppstår daglig, og som fører til at man binder opp verdifull tid på problemløsning gjør at man sjelden får hodet tilstrekkelig over vannet til å arbeide med nye verdiskapende aktiviteter.

Spennet mellom disse to ytterpunktene er åpenbare. Det første kan forbli som det er, mens det siste bør man ta tak i rotproblemet og løse. Men i mellom disse to ytterpunktene er det en stor gråsone, og det er her alle tvilstilfellene befinner seg. Isolert sett er kanskje mange små problemer hver for seg ikke noe problem? Men i sum stjeler de kanskje mye tid? Og det er her gjærbakstmetaforen melder seg.

Plutselig en dag hører man fra et utviklingsteam at de synes throughput av nye verdiskapende oppgaver går tregt. Det brukes for mye tid på feilretting eller manuelle oppgaver. Tidstyver som i sum blokkerer verdiskapende aktiviteter.

I en slik situasjon er det lett å bli problemorientert — og her er ordspillet bittelitt tilsiktet. Det er lett å bli stresset av mengden problemer og tidstyver. Det er lett å bli demotivert fordi man er tynget ned av ikke-verdiskapende aktiviteter.

I en slik situasjon skal du huske dette: Problemer som øker er et resultat av vekst. Vekst som følger av at du har fått nye kunder, nye brukere, at løsningene dine brukes og forhåpentligvis av at virksomheten går bra. Hvis ingen hadde brukt løsningene dine ville det heller ikke vært problemer i driften som økte over tid. Ingen kunder som kontaktet kundeservice.

Satt på spissen er problemer som vokser bra! Men det betyr ikke at du skal la dem forbli uhåndtert.

Problemer som vokser skal håndteres på lik linje med andre verdiskapende aktiviteter og oppgaver. En enkel kartlegging av hva vi bruker tid på, hva som er mest kritisk, hva som har høy risiko vil gi et godt utgangspunkt for å lage tiltak for å ta ned den tekniske gjelden — altså å slå ned gjærbaksten.

Ikke alle tiltak bør gjennomføres, men man starter med ett, to, tre prioriterte tiltak og evaluerer effekten. Har det blitt bedre? Har vi færre tidstyver? Får vi bedre throughput av nye oppgaver?

Dette er en nyttig øvelse man ideelt sett bør gjøre regelmessig, gjerne som en del av et retrospektiv, altså en retro som jeg må lage en egen episode om.

Det skal være slack og rom til å håndtere tidstyver og teknisk gjeld.

Tusen takk for at du lytter til Fimbul, vi høres!