Smidig produkteierskap

I Scrum har vi Product Owner rollen, men uansett hvilket smidige rammeverk man velger vil den eller de som er ansvarlig for visjonen og verdien til produktet måtte beherske metoder og teknikker som harmonerer med smidige prinsipper. Hva er så alle disse metodene og teknikkene? Denne posten har til hensikt å gi et overblikk over dette fagfeltet.

Situasjonsbestemte suksessfaktorer

Det ofte slår meg at vår trang til å generalisere lett kommer i veien for å lykkes. Situasjonen, rammebetingelsene, modenhet, forutsetninger etc vil variere, men allikevel har vi lett for å svelge samme medisin. Produkteierrollen i Scrum er veldefinert. Du eier visjonen og skal på bakgrunn av denne lage en liste over produktkøelementer som da skal prioriteres i henhold til forretningsmessig verdi. Men hva er nå forretningsmessig verdi for de ulike produkeierne der ute? Det kan være utrolig mye forskjellig. Hvilke teknikker, metoder og hvilken tankegang skal du bruke for å lage en best mulig produktkø som gir mest mulig verdi? Dette “kommer an på”…

Verktøykassa til en produkteier

Det publiseres mye innenfor smidig produkteierskap for tiden, og det finnes helt ok gamle ting å være klar over. Jeg har laget en oversikt her.

Denne skyen er selvsagt ikke komplett på noen måte, men kan brukes som en rikholdig verktøykasse som er i utvikling. Hvordan velge riktig verktøy for den jobben som skal gjøres? Alle produkteiere behøver ikke beherske alle disse prinsippene og teknikkene. Men som produkteier bør du har en oversikt over hvilken del av verktøykassa som er relevant for deg.

Jeg har skrevet litt om tilpasning av selve Produkteierrollen her: http://scrummaster.no/?p=276. Vinklingen er at rollen er svært ulik avhengig av graden av innovasjon, av type kundeforhold og av avtale/kundeforholdet. Men hva bør en produkteier beherske av teknikker og metoder, avhengig av slike forhold?

Produktets livssyklus

Det er helt annerledes å lede produktutviklingen i et lite start-up enn i en veletablert organisasjon som vedlikeholder et modent produkt. Vi som lever av å veilede og kurse innenfor smidig må ha en solid forståelse av disse ulikhetene.

Figuren under viser de ulike fasene et programvareprodukt gjennomgår.


I oppstartsfasen gjelder det å opparbeide en visshet om at selve ideen og forretningsmodellen er levedyktige. Når beslutningen om å skalere opp utviklingen kommer, bør vi være tryggest mulig  på at investeringen vil bære frukter. Derfor ønsker vi å så raskt som mulig komme ut med et lite produktinkrement, eller lage noe som ligner produktet, slik at man kan komme i en god dialog med potensielle kunder. Lager man web-baserte tjenester “i skyen”, kan man gjennom smidig tankegang svært raskt komme i mål med et kjørbart, lite inkrement som man kan få noen interessert i å prøve. Om dette ikke er mulig kan man ty til prototyper av ulik art. Formålet med dette bør være å få mest mulig validert læring ut av innsatsen. Her vil blant annet tankegodset til Eric Ries med Lean Start-up være særlig relevant.

I utviklingsfasen gjelder det å gradvis bygge opp en organisasjon som er i stand til å levere de viktigste featurene til markedet. Dette er den fasen ren Scrum i utgangspuktet er laget for. Produkteier vet at de løpende vurderingene og prioriteringene han gjør vil være avgjørende for suksessen. Han vet også at han må jobbe hardt for å komme i dialog med de rette brukergruppene slik at han kan få god feedback på Sprint Reviewene. De som leverer på web, og som er i stand til å levere virkelig ofte, har muligheten til å teste ut nye ideer på markedet, og således få enda bedre feedback og beslutningsgrunnlag enn Sprint Reviewet vil kunne gi.

Innhøstingsfasen er det vi gjerne kaller vedlikeholdsfasen (jeg liker ikke helt det begrepet fordi dette arter seg veldig annerledes for programvareprodukter enn for fysiske produkter). I denne fasen vil fokus være på lave utgifter og høy inntjening. Det er jo her man skal høste fruktene av de to foregående fasene. Produkteier vil her fokusere mest på kost-nytte vurderinger. Mange vil ha SLA-avtaler som til en hviss grad regulerer prioriteringene som gjøres. Enkelte opplever mye bug-fix i denne fasen og da vil man lett komme i en “brannslukningsmodus” som gjør at Scrum fungerer dårlig. Man klarer rett og slett ikke å planlegge særlig store deler av neste Sprint. Kanban fungerer nok da bedre.

Fase Kjennetegn Teknikk Verdi
Oppstart Alt som har med Visjonen å gjøre er selvagt sentralt. Business Model Canvas, Elevator Statement, Personas etc.. Lean Startup teknikker som Minimal Viable Product, Validated Learning BMC, Elevator statement, MVP, One-pager, Personas, A/B testing Lærdom er hard valuta. Så også valgmuligheter (Real Options).
Utvikling Her gjelder det å produsere features på løpende bånd. Men det må være features som kundebasen virkelig trenger og som de vil ta ibruk. Avgjørende å holde høy fart uten å pådra seg teknisk gjeld. Avgjørende å få teamene til å fungere godt og å få de ulike teamene til å ta ansvar for helheten. Gi tydelig rom for innovasjon og nytekning! Alle verktøyene i “skyen” vil være relevante. Pull, US, Story Mapping, MMF, MVP, BDD, Effect Mapping, Real Options, Kano Analysis, A/B testing, Grooming, Release Planning, Product Roadmap, Kundetilfredshet (NPS), ROI, Technical Debt, Velocity
Innhøsting I denne fasen er det for mange viktig å holde produktet levende og kundene fornøyde, uten å legge for mye innsats i det. I denne kategorien ligger også Application Management og Service Management type oppdrag. Produkteier vil ha som hovedoppgave å prioritere. Det er typisk mange henvendelser og mange ulike interessenter som gjerne vi ha fikset på ting, mens teamet har begrenset kapasitet. Backlog Grooming, Technical Debt, WIP, flow, ROI, Kundetilfredshet, Flow, bunnlinja…

Modenhet

Smidig modenhet er i denne sammenheng et ganske meningsfullt begrep. Det er stor forskjell på å være produkteier der kulturen er tradisjonell/konservativ og der endringsviljen er stor. Det er stor forskjell på å operere i et miljø som har årlige leveranser, kontra firmaer som leverer ukentlig eller oftere. Dette er det også viktig å ta høyde for når man velger verktøy fra verktøykassa.

De med høy smidig modenhet leverer ofte, og er satt opp med stor grad av selvorganisering. Disse tingene henger sammen, det er vanskelig å tenke seg svært hyppige leveranser i et tradisjonelt, kommandoorientert selskap.

De med lav modenhet vil måtte fokusere på Release Planning og Road Map, samt å hente så mye og god feedback som mulig på Sprint Reviewer. Her vil også Produkteier måtte jobbe tett sammen med Scrum Master og fjerne organisasjonsmessige hindringer. En god produkteier vil evangelisere for hyppigere releaser, læring underveis og å innarbeide mer selvorganiserende arbeidsform.
De som har høy modenhet vil kunne fokusere på mer “avanserte” teknikker og metoder som A/B testing, Innovation accounting, MVP osv.

Kompleksitet

Det er stor forskjell på å kjøre komplekse og enkle prosjekter. I IT-bransjen finnes det faktisk en del forholdsvis enkle prosjekter. Dette kan være installasjon og tilpasning av standardsystemer som Visma eller SAP. Her kan tradisjonell, planorientert tenkning fungere fint. Andre er mer kompliserte, men allikevel ikke i det komplekse området i Cynefin modellen. Her kan det også fungere OK med en ganske tradisjonell tilnærming, gjerne kombinert med Kanban for å gradvis optimalisere. Men i det komplekse området er det selvorganisering og løpende læring som gjelder. Hvordan få validert løsninger og funksjoner raskest mulig, blir da spørsmålet. Scrum er skreddersydd her.

Posted on June 14, 2012 at 3:04 pm by gamsjo · Permalink
In: Kanban, kompleksitet, ledelse, produkteier, Scrum · Tagged with: , , , ,

Leave a Reply