Martin Bekkelund

Martin Koksrud Bekkelund

Teknologi • Samfunn • Politikk

I slutten av oktober ble konferansen Smidig 2014 arrangert. Her er de viktigste erfaringene jeg tok meg meg hjem, satt i kontekst av egne erfaringer.

Smidig 2014

One size doesn’t fit all

Det fine med smidig (med liten s) er at det ikke finnes en one size fits all-prosess. Innleder Jim Benson poengterte det samme som jeg tidligere har messet om, at det viktigste er ikke å implementere en prosess etter boken, men å finne en prosess som passer ens eget behov. Kort oppsummert: drit i reglene, finn noe som passer for deg og forbedre deg kontinuerlig.

Scrum er bare sååå 2013

Det er stadig flere som kritiserer Scrum, meg selv inkludert. Metodikken som før var det heiteste man kunne gjøre, blir nå uglesett i bransjen. Scrum har allikevel noe godt ved seg. Jeg pleier å si at Scrum er fint som avrusning for dem som kommer fra vannfall eller ustrukturerte metoder. Som en overgang til å bli smidig er Scrum et godt sted å starte, men man må komme seg videre.

Optimalisering > standardisering

Det ble gitt eksempler på smidige team i store organisasjoner, hvor teamene opererer helt selvstendig og fungerer fint på denne måten. Fra et ledelsesperspektiv kan dette virke rart, hvor det er nærliggende å tro at standardisering vil gi bedre effektivitet enn individuell optimalisering. Det er ikke tilfelle. Optimalisering innen team handler om at menneskene som arbeider i teamene responderer forskjellig og har forskjellige behov. Optimalisering på teamenes premisser gir bedre resultat fordi optimaliseringen tar hensyn til teamenes egne behov.

Du trenger ikke en prosess for alt

Du trenger ikke nødvendigvis en prosess for alt. For deler av virksomheten er det vanskelig å lage en fleksibel prosess som kan ta hensyn til alle de varierte oppgavene programvareutvikling medfører. Hvis man prøver å lage slike prosesser, vil ofte det administrative byråkratiet bli større enn gevinsten. Erfaring eller enkle målepunkter kan fungere vel så godt og sørge for at man får gjort mer.

Flaskehalser

Et av de mest sentrale elementene i smidig er kontinuerlig forbedring. Og for at man skal forbedre seg, må man finne flaskehalsene. Hvor går det tregt? Hvor er det frustrasjon? Hva bruker man alltid mye tid på? Hvor er det kø? Flaskehalser kjennetegnes gjerne ved at det er mye i arbeid, men kø foran og vakuum bak. Så, når du ser hvor flaskehalsene er, passer det fint med noen Lean Startup-teknikker. Du har et problem: So what? Hva er konsekvensene av problemet? Blir det flere feil enn nødvendig i produksjon? Tar det lengre tid mellom hver produksjonssetting? Og videre. Du har et problem: Why? Hva er årsakene til problemet? Løs dem!

Estimering

Jeg synes estimater gir meg et godt underlag for beslutning. Men trenger vi egentlig estimere hvis vi allikevel vet hva som er viktigst å gjøre først? Uansett hva du velger er det viktig å ikke grave seg ned i detaljene. Jo mer tid du bruker på estimering, jo mindre tid har du til andre ting. Hos oss estimerer vi i dagsverk, og selve estimeringen skjer ved behov på svært overordnet nivå.

Kutt artefakter

En del smidige prosesser har artefakter som standup, retrospekt, Scrum Master, produkteier, sprinter og grooming, for å nevne noe. Men du trenger ikke å benytte deg av alt sammen. Tvert i mot. Jo mindre artefakter du har, jo mer tid har du til andre ting, til å utvikle selve produktet. En artefakt er noe du innfører for å løse et problem, ikke fordi en prosess forteller deg at du skal gjøre det.

Prioritering av oppgaver

Grovt sett kan produktutviklingsprosessen deles i to. Analyse og utvikling. Første del handler om innsanking av ideer, hvordan man analyserer og prioriterer dem. Andre del handler som selve utviklingen, fra ideene dukker opp i backlog til de er ferdig i produksjon.

En av mine personlige utfordringer handler om prioritering av oppgaver opp mot hverandre. Gitt at man har to gode ideer, hvor mye arbeid skal man legge ned i analyse for å finne ut av hva man bør arbeide med først? På den ene siden kan man arbeide seg ihjel med business case og estimater, på den annen side trekker man det inn i backlog basert på magefølelse og hva man har lyst til å gjøre først. Et sted mellom disse to ytterpunktene ligger det som vil være fornuftig bruk av tid for å få riktig resultat.

Om ikke det finnes en konsensus på området, ser det ut til å være enighet om at man kun bør legge ned et minimum av innsats før utvikling starter. Det harmonerer godt med egne erfaringer. En initiell vurdering med forslag til løsning, et enkelt forslag til forretningsmodell, en enkel oversikt over kostnader og inntekter og ikke minst en prat med potensielle kunder og brukere før du utvikler, kan danne grunnlaget for prioritering av ideene opp mot hverandre. Et enkelt use case som med en håndfull setninger beskriver hva vi skal løse. Et utvalg av elementene fra Business Model Canvas som forretningsmodell. Et lite nano case, som vi kaller et forenklet business case hos oss. Og litt geriljatesting på Oslo S for å snakke med brukere, eller intervjuer av en håndfull bedrifter.

Definition of awesome

Har du noen flaskehalser i produktutviklingsprosessen din? Er release vanskelig og tidkrevende og risikofylt? Start med å definere hva som vil være awesome og sett deg delmål for å komme dit. Henrik Kniberg holdt innledning om temaet og har også skrevet om en enkel sjekk du kan gjøre. Sjekk også Henriks innledning på Vimeo eller les hans slides.

God stemning med Henrik Kniberg:

God stemning med Henrik Kniberg og Martin Koksrud Bekkelund

Kan og vil

12.11.14

Når du forteller en kunde som venter på et forsinket produkt at «vi har dessverre ikke mulighet til å kompensere for denne forsinkelsen», så sier du egentlig at «vi velger å ikke bry oss, salget er allerede i boks».

Du kunne lagt ved en liten sjokolade.

Du kunne lagt ved et lite kort og beklaget.

Du kunne gjort så mye, som hadde kostet så lite, og allikevel etterlatt kunden med et positivt inntrykk.

I stedet velger du altså å si at «vi har dessverre ikke mulighet til å kompensere for denne forsinkelsen».

Hvis dine kunder har en negativ opplevelse hos deg, bør du i det minste gjøre noe positivt ut av det som i utgangspunktet var negativt.

8. oktober ble Friprogsenteret strøket fra statsbudsjettet. 17. oktober ble samtlige ansatte ved senteret sagt opp. Ettersom jeg selv jobbet ved senteret i fire år, er det på sin plass med noen betraktninger.

Friprogsenteret så dagens lys sent i 2007. Bjørn Venn var sentral initiativtaker og senterets første ansatte var Heidi Arnesen Austlid før Christer Gundersen, meg selv og Morten Amundsen kom ombord. Senere har også Rune Strømme kommet innom, i tillegg til også Salve J. Nilsen og flere andre.

Strategien var enkel: offentlig sektor har mye å hente på å dele kunnskap om programvare som anskaffes for offentlige midler. Strategien er like aktuell i dag. Offentlig sektor har knapt nok skrapt i overflaten av potensialet. Systematisert deling, gjenbruk og samarbeid om IT-løsninger ville skapt bedre løsninger til lavere kostnader. I resten av verden skalerer man opp fagmiljøer med denne kompetansen, mest nærliggende i Storbritania, mens vi i Norge velger å avvikle den.

I dag har jeg selv det daglige ansvaret for store løsninger som er bygget på fri programvare. Fordelene er så mange at de fortjener en egen artikkel. Jeg ville aldri byttet.

Jeg vet at kunnskapen Friprogsenteret har formidlet gjennom de syv årene det har vært i drift har kommet til nytte. Konferansen GoOpen har hvert år samlet flere hundre mennesker for å utveksle erfaringer og knytte kontakter. Magasinet Smart har bidratt til å etablere et nytt tankesett som utfordrer det etablerte.

Nå er begge deler historie.

En viktig stemme har forsvunnet fra norsk IT-bransje.

Flere artikler

Enda flere artikler? Besøk arkivet.

Martin Koksrud Bekkelund

Martin Bekkelund

Bekkelund.net er en blogg av Martin Koksrud Bekkelund, hvor han lufter sine tanker 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...

Følg Martin

Facebook Twitter Instagram LinkedIn Flickr Vimeo GitHub Google+ SlideShare Martin Bekkelunds RSS-kanal

Søk

© 1995-2014 Martin Koksrud Bekkelund
OpphavsrettRSS og abonnementKontakt