Martin Koksrud Bekkelund

Martin Koksrud Bekkelund

Teknologi • Samfunn • Politikk

De aller fleste av oss som arbeider med IT, gjør det fordi det er noen andre som skal bruke det vi lager. Lager du en nettbutikk har du kunder som skal handle der.

Til tross for dette er det allikevel overraskende mange som ikke klarer å tenke som en kunde. En ting er å gjennomføre en prosess, for eksempel finne noen varer i en nettbutikk og betale for dem. Dette klarer alle å lage. En annen ting er er å forstå hva som er viktig for kunden underveis og hvordan kunden tenker.

La meg ta et eksempel.

Jeg er ute etter å kjøpe ny fryser hjemme, og tenker å handle på nett. WhiteAway er en av nettbutikkene jeg er innom. Her finner jeg en fryser jeg har lyst på. Men finner jeg den samme fryseren billigere et annet sted? Jeg dobbeltklikker på modellbetegnelsen i nettbutikken, for å markere teksten, kopiere den og søke på prisjakt.no for å se om andre selger den billigere.

Det er her nettbutikken viser at de forstår hvordan jeg tenker. Idet jeg dobbeltklikker på modellbetegnelsen, dukker det opp en liten melding:

WhiteAway prismatch

Intensjonen min er åpenbar. Jeg vil se om noen andre selger den billigere. Dette har nettbutikken forstått, og de reagerer på min intensjon ved å si at «sjekk gjerne prisen andre steder, finner du den billigere et annet sted, så får du den til samme pris hos oss».

Ved å tenke som en kunde, øker nettbutikken sannsynligheten for at jeg handler hos dem og reduserer risikoen for et tapt salg fordi de ikke aner hva kundene faktisk gjør i nettbutikken.

Nettbutikken er brukt som et eksempel fordi det er lett å forstå. Men å tenke som en kunde, eller en bruker, går igjen i hver eneste IT-løsning som lages. Hva tenker egentlig folk når de bruker løsningene du lager?

Martin skriver regelmessig om hvordan teknologi, samfunn og politikk påvirker hverandre. Legg igjen din e-postadresse og få nye artikler via e-post:

Det er mange måter å konkurrere i et marked på. Men av alle alternativene er pris sannsynligvis den dårligste.

Pris skalerer kun én vei: nedover. Da ender du opp i en negativ spiral, hvor alt dreier seg om å kutte kostnader. Og når alt dreier seg om å kutte kostnader, kutter du vekk muligheten til å være innovativ, til å være unik, til å levere best kvalitet og ha best tilgjengelighet.

Den norske landbrukspolitikken er et godt eksempel. Det har vært et ensidig fokus på lave priser i både produsentleddene og dagligvarebransjen. I stedet for å trekke frem alle de gode og varierte produktene man finner i dette landet, har man i stedet valgt at alt skal smake likt, enten det er egg fra Hønefoss eller Hammerfest, eller melk fra Toten eller Trøndelag. Man har effektivt fjernet alle konkurransefortrinnene, og bøndene og forbrukerne står igjen som taperne.

På bunnen er det tett befolket. Markedet er fullt av aktører som kan konkurrere på pris. Kunsten er å skape betalingsvilje for den kvaliteten du leverer. Hva enn som blir ditt konkurransefortrinn, sørg for at det aldri blir pris.

Martin skriver regelmessig om hvordan teknologi, samfunn og politikk påvirker hverandre. Legg igjen din e-postadresse og få nye artikler via e-post:

Scrum er en fantastisk prosjektmetodikk. Forutsatt at du kommer fra en verden hvor vannfall er metodikken du kjenner. Men har du først fått taket på Scrum, er tiden inne for å komme seg videre. Scrum er intet blivende sted. Sånn sett er Scrum en avrusningsmetodikk for dem som kommer fra vannfall.

Man må lære å krabbe…

Når man kommer fra vannfall, representerer ofte smidige prosjektmetodikker noe fundamentalt annerledes enn hva man er vant med. Ikke bare er det en annerledes måte å jobbe på, det virker til og med uansvarlig ved første øyekast: ingen kravspekker, ingen dokumentasjon, ingen planlegging, ingen deadlines, ingen prosjektledere, ingen milepelplaner. Hvordan i all verden skal man få levert noe med så lite?

Og det er her Scrum kommer inn. Scrum innfører mye av tankegodset til smidig på en måte som gjør det spiselig for dem som trenger avrusning fra vannfall. Man har en Scrum Master som prosjektleder, man har sprinter som deadlines, man har Planning Meetings for planlegging og diverse andre artefakter som fungerer som pusteøvelser når savnet etter vannfall blir for stort.

Problemene med Scrum

Problemet er at flere av artefaktene fra Scrum blir en flaskehals straks man behersker Scrum. Når man innfører Scrum er det derfor viktig at man før innføringen klart og tydelig setter seg som mål at når Scrum beherskes, så må man komme seg videre. Kontinuerlig forbedring er sentralt i smidig.

Ta dette med sprinter. En sprint er en avgrenset tidsperiode som man driver utvikling i. En sprint varer for eksempel tre uker. Man starter en sprint med et planleggingsmøte. Deretter jobber man med å lage det man har definert i planleggingsmøtet. Og det er her problemene oppstår. Plutselig støter man på problemer og oppgaver må tas ut av sprinten for å rekke deadline. Ja, deadline. En kunstig, selvpåført deadline som kun fører til stress. Eller verden endrer seg underveis i sprinten, slik at forutsetningene du arbeider etter også har endret seg.

Løsningen? Fjern sprintene. Hvorfor ha selvpåførte deadlines hvis det ikke er noen reell grunn til å ha dem? Kast sprintene ut døra sammen med planleggingsmøtene.

Og Scrum Master? Hvorfor ha en person til å fotfølge utviklerne for å måle fremdriften deres til stadighet? Du klarer deg med en som leder utviklingsteamet og som selv utvikler og er produktiv.

Når passer Scrum?

Vi i Posten har gjennom flere år levert flere IT-prosjekter til offentlig sektor. Prosjektene ble levert på tid og pris. Det siste prosjektet ble gjennomført mer eller mindre etter Scrum-boka.

Scrum har etter mitt syn sin naturlige plass enten hvis man kommer fra vannfall og skal videre til noe mer smidig, eller hvis man har leveranser med faktiske deadlines.

… før man lærer å gå

For mange er Scrum et mål i seg selv. Jeg har tidligere skrevet at metoden ikke er målet. Sentralt i smidig står tanken om kontinuerlig prosessforbedring. Finn flaskehalser i utviklingen og fjern dem, en etter en.

I stedet for sprinter plukker utviklingsteamet oppgaver fra en prioritert backlog, utvikler, tester, aksepterer og produksjonssetter når de er ferdige med oppgaven. Alle utviklere bør kunne gjøre alle oppgaver: utvikle, teste, akseptere og produksjonssette alle deler av all kode. Gi utviklerne root.

DevOps og Extreme Programming (XP) har mye bra ved seg som du kan hente inspirasjon fra. Det samme har Kanban. I kombinasjon får du både elementene du trenger til å sette sammen en god prosess, i tillegg til å visualisere fremdrift og legge begrensninger på flaskehalsene.

Kommer du fra vannfall hjelper Scrum deg opp i knestående. Herfra må du selv komme deg videre, for eksempel med XP og Kanban som krykker. Hva som skal til videre herfra er helt opp til deg selv. Finn flaskehalsene og stressfaktorene, fjern dem og gjenta.

Martin skriver regelmessig om hvordan teknologi, samfunn og politikk påvirker hverandre. Legg igjen din e-postadresse og få nye artikler via e-post:

Flere artikler

Enda flere artikler? Besøk arkivet.

Om Martin

Martin Koksrud Bekkelund

Dette er Martin Koksrud Bekkelund sitt private nettsted, hvor han skriver om samspillet mellom teknologi, samfunn og politikk. Martin arbeider til daglig som direktør for produkt- og forretningsutvikling i et av Norges største selskaper. Les mer...

 

Facebook Twitter Instagram LinkedIn GitHub SlideShare Martin Koksrud Bekkelunds RSS-kanal

© 1995-2017 Martin Koksrud Bekkelund
OpphavsrettRSS og abonnementKontakt