Martin Koksrud Bekkelund

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.

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:

Generelt