Prosess og rådgivning / 6 minutter /
Jobber du egentlig Smidig?
Mange sier de jobber smidig, men gjør de egentlig det? I løpet av mange år som konsulent har jeg ofte opplevd at ulike oppfatninger av begrepet “smidig” kan føre til dårlig kommunikasjon, og at vi ikke klarer å hente ut potensialet i teamet. Derfor er det veldig viktig at team blir enige om hva det innebærer å jobbe smidig. Dette er like relevant for de med lang erfaring som de som er ferske i arbeidslivet.
Hvorfor skrive en blogg om smidig i 2024? Jeg erfarer at ordet smidig har blitt et buzzword, der betydningen har blitt visket ut. Alle har hver sin oppfatning av hva det betyr, det gjelder både IT-kolleger og kunder, og disse oppfatningene kan gjerne sprike i alle retninger. Dette kan gjøre det vanskelig å ha en samtale rundt hvordan vi jobber sammen. På ett og samme team kan Geir tenke at vi jobber smidig, for vi har jo tatt i bruk Scrum. Mens Anne tenker at dette er det minst smidige teamet hun noen gang har jobbet i. I denne situasjonen vil vi typisk kunne oppleve at Anne ønsker å endre arbeidsprosessen til teamet, mens Geir ikke er motivert til å bruke energi på det. Dette kan skape grobunn for misnøye. Hvis man skal klare å samarbeide om å skape en god og smidig arbeidsprosess for teamet sitt, så er det en fordel om alle har samme oppfatning av hva man forsøker å oppnå. Da kan det hjelpe å ta utgangspunkt i en felles definisjon av smidig.
Det smidige manifestet definerer Smidig for oss som driver med digital produktutvikling. En ulempe med manifestet er at det inneholder mange ord, og at det derfor kan være vanskelig å bygge felles forståelse omkring all den informasjonen med teamet. Jeg har derfor forsøkt å hente ut kjernen i Smidig i en eneste setning:
Smidig er å oppdage og levere verdi kontinuerlig i uforutsigbare omgivelser.
Figuren under illustrerer denne setningen.
I avsnittene under vil jeg utdype litt mer hva jeg mener er kjernen i Smidig.
Uforutsigbare omgivelser
Hvorfor må vi jobbe smidig?
For det første skal vi lage produkter for mennesker, som ofte har ganske diffuse behov. Vi trenger gjerne flere forsøk for å avdekke behovene.
For det andre lever vi i en tid der endringer skjer veldig raskt. Noe som kjennetegner tiden vi lever i er at det finnes veldig mange produkter tilgjengelig for oss, og at disse endrer seg stadig vekk. Det gjør det vanskelig å forutsi at hvis vi lager vårt produkt slik, så vil markedet respondere sånn. Hvis man har monopol på tjenesten som tilbys er det jo en litt annen situasjon, men det gjelder de færreste.
For det tredje befinner ikke digitale produkter seg i et vakuum. De påvirkes derimot av mange eksterne faktorer. Eksempler kan være integrasjoner mot andre systemer som endrer seg, nye krav fra myndighetene, eller endringer i teknologien som benyttes.
Felles for punktene som nevnes over er at de gjør hele tilværelsen uforutsigbar når vi lager digitale produkter. Det betyr at vi må legge opp arbeidet slik at vi har frihet til å teste ut antagelser, for å finne ut hva som gir ønsket effekt.
Oppdage verdi
Som nevnt over er både mennesker og våre omgivelser uforutsigbare. Dermed kan det være en utfordrende oppgave å finne ut av hva som oppleves som verdifullt for målgruppene våre.
Verdien vi tilfører, innebærer gjerne at vi får brukerne til å gjøre noe annerledes en før. Fordi vi har utviklet løsninger som gjør hverdagen enklere eller bedre for dem. Hvis vi skal få til det må vi først skjønne hvordan de har det i dag. Hva er tungvint? Hva er det de ikke får til, som de har lyst til å gjøre? Hva er egentlig det underliggende behovet?
Etter at vi har forstått hvorfor brukerne trenger noe fra oss, kan vi begynne å tenke på mulige løsninger. Det er slett ikke sikkert at den første ideen vi har slår an. Vi må antagelig komme med flere løsningsforslag før vi treffer på noe som brukerne virkelig blir begeistret over. Vi vil jo at de skal bli så begeistret at de endrer vanene sine, og faktisk vil ta i bruk det vi lager. Og ofte endrer de atferden uten at de ytrer noen begeistring – fordi det bare fungerer som det skal.
Vi må gjøre antagelser om hva som vil begeistre, og så teste dem. Mange av antagelsene våre vil være “feil”. Det er en del av prosessen, og det er ikke bortkastet, fordi det hjelper oss å lære. Vi ønsker å sjekke ut antagelsene våre raskt, så vi slipper å legge mye arbeid i å lage noe som ingen vil bruke.
Det å oppdage verdi, er å være innovativ. I en slik innovasjonsprosess er det åpenbart mest effektivt om de som skal avdekke behovet får jobbe direkte med de som har behovet. Da er det enklere å komme opp med gode løsningsforslag.
Levere verdi
På et eller annet tidspunkt må vi også begynne å levere verdi. Det betyr ikke at vi slutter å teste ut antagelser, selv om vi har begynt å utvikle løsningen. Utviklerne må også delta i det å teste ut ulike hypoteser. Det er først når vi har fått endringene helt ut i produksjon at vi virkelig har mulighet til å sjekke om vi har skapt verdi. For da kan vi måle om brukerne faktisk gjør det de har sagt at de vil gjøre.
I tillegg til den verdien som brukerne ser, så legger utviklerne også inn merverdi i form av god kodekvalitet og sikkerhet.
Kontinuerlig
Da er vi inne på det å levere verdi hyppig, eller kontinuerlig. Kontinuerlig er relativt, og hvert team må finne ut hva som er riktig takt for dem. For noen team kan det være ukentlige leveranser, for andre daglige, eller at endringer fortløpende legges rett ut i produksjon.
Hvis vi skal levere kontinuerlig er det flere ting å tenke på:
- Vi må ta utgangspunkt i den arbeidsprosessen vi har, og steg for steg finne og fjerne flaskehalsene som hindrer oss i å levere hyppig. Det å lære, og stadig forbedre måten vi jobber på, er en hjørnestein i smidig.
- Det er mange rutinemessige steg som må tas når man jobber med en leveranse, og mye testing som må gjentas hver gang. Disse rutinemessige jobbene må automatiseres.
- Hyppige leveranser betyr ofte at hver leveranse er ganske liten. Og det forutsetter at vi klarer å bryte ned arbeidet i mindre elementer.
- Det er veldig mange beslutninger som må tas i forbindelse med hver leveranse. Hvis de som skal gjøre jobben får lov til å ta beslutninger, vil beslutningene bli bedre, og de kan tas raskere. De som skal oppdage og levere verdi må altså få avklare ting direkte med de som skal bruke produktet.
- For å klare å levere verdi med høy kvalitet dag ut og dag inn over lang tid, er det viktig at folk har det bra på jobb. Trygghet og trivsel må pleies i teamet som skal levere, og organisasjonen må sørge for at teamet har gode rammebetingelser.
Lean og Smidig har mye til felles, men ikke alt
Smidig og Lean har mye til felles, for eksempel fokus på å skape verdi for brukerne, og å hele tiden forbedre måten man jobber på. Det er likevel ulike bruksområder for Smidig og Lean.
Skal vi lage noe som er unikt velger vi Smidig. Hvis vi vet hva vi skal lage, og vi skal gjøre samme jobb flere ganger, velger vi Lean.
Lean sin opprinnelse er å optimalisere produksjonslinja til Toyota. Forutsetningen er at samme bil skal produseres igjen og igjen. Da er det viktig å perfeksjonere produksjonslinja, altså å fjerne alt som ikke bidrar direkte til verdi, også kalt waste.
Smidig er metodikken vi bruker når vi skal lage noe som er unikt, eller ukjent. Vi kan ikke strømlinjeforme det å oppdage hva som gir verdi for kunden. Det er en del av jobben å prøve og feile, og kaste ideer som ikke fungerer. Det må være rom for “waste”.
Selv om det å oppdage verdi forutsetter at det må være lov å feile, så har vi ting som ligner på produksjonslinjer i digital produktutvikling også. Eksempler er pipelines for bygging og deploy, og automatisering av tester. Når man jobber med disse kan man ha en lean tilnærming, og forsøke å fjerne stegene som ikke tilfører verdi.
Vannfall er IKKE Smidig
Vannfall og smidig kan begge brukes til å utvikle programvare, men dette er to metodikker som passer til helt ulike typer prosjekt/oppdrag.
Hvis vi skal lykkes med et vannfallsprosjekt så forutsetter det at omgivelsene er forutsigbare, og at vi vet akkurat hva vi skal lage. Vi lager en plan før vi starter, og leveransen kommer helt til slutt. Hvis vi klarer å holde planen, og levere det vi ble enige om i starten, defineres gjerne prosjektet som en suksess.
Forutsetningen for et smidigprosjekt er at omgivelsene er uforutsigbare, pluss at vi ikke vet helt på forhånd hva vi skal lage. Det må til en viss grad oppdages underveis i prosessen. Her må vi lage en plan hvor vi i parallell kan finne ut hva vi skal lage, og faktisk lage det, bit for bit. Suksess i smidig måles hovedsakelig i verdien vi skaper for brukerne.
Et vannfallsprosjekt og et smidig oppdrag må planlegges, styres og følges opp på to helt ulike måter. Vi må vurdere hvilken type jobb vi står ovenfor, og velge rett verktøy.
Oppsummering
Målet med smidig er å levere verdi kontinuerlig. Det krever at vi klarer å sjonglere to parallelle prosesser samtidig, innovasjon og leveranse av digitale produkter.
Jo hyppigere vi kan teste ut ideene våre sammen med de som skal bruke det vi lager, og få feedback, jo smidigere kan vi være.
Denne artikkelen har kun hatt som mål å forklare hva begrepet smidig betyr i konteksten digital produktutvikling.
Hvis man er enige om at smidig er riktig arbeidsmetodikk å velge for et team, er neste steg å implementere smidig. Da er det mange nye ting å tenke på. Hvordan skal teamet se ut? Hvordan skal vi samhandle på teamet? Hvordan skal vi sette opp arbeidsprosessene våre så vi får god flyt? Hvilke smidige verktøy og teknikker kan vi bruke? Hvordan vurderer og forbedrer vi arbeidsprosessen vår kontinuerlig? Hvordan planlegger vi når vi jobber smidig? Disse temaene er ikke berørt i denne artikkelen, men det kan være at jeg kommer tilbake med en artikkel eller to om å implementere smidig.