Min supre produkteier

Dette er en oppsummering av foredraget mitt på Smidig 2010 konferansen

Jeg har vært så heldig å være på et prosjekt med en produkteier som har sørget for at vår innsats har blitt brukt til å effektivt skape verdi for brukerne av systemet. Jeg vil trekke fram mine observasjoner om hvordan produkteieren på dette prosjektet brukte produktkøen, hvordan han skapte dialog med brukerne og hvordan han kommuniserte effektivt med utviklerne.

Produktkøen

Produktkøen er produkteiers fremste verktøy for å styre prosjektet dit han ønsker. Det viktigste med produktkøen er derfor at den er representert i et verktøy produkteieren er komfortabel med å bruke. Vår produkteier brukte Excel, noe som fungerte godt for dette prosjektet. Hver brukerhistorie var en rad i et regneark. Når vi skulle endre prioritet, kunne vi dra og slippe en brukerhistorie til riktig sted. (Dette er et lurt knep å lære i Excel).

Etter hver iterasjon gikk jeg som Scrum master og produkteieren gjennom alt som var levert i iterasjonen. Vi markerte i produktkøen hva som var levert og hva som ikke var levert. I iterasjon 4, 5 og 6 skjedde noe merkelig. Iterasjon 4 hadde vi planlagt 7 brukerhistorie-poeng, men leverte 4. I iterasjon 5 hadde vi planlagt 7 og leverte 7. I iterasjon 6 hadde vi planlagt 7 og leverte 10. Det som skjedde var et en stor brukerhistorie var nesten ferdig på slutten av iterasjon 4. En ny stor brukerhistorie var nesten ferdig på slutten av iterasjon 5, og denne brukerhistorien fikk vi endelig levert i iterasjon 6. Produkteier insisterte på at en brukerhistorie var enten ikke ferdig (0%) eller helt ferdig (100%). Dette gjorde at det aldri var noen skjønnsvurdering om hva vi hadde levert.

I prosjektet vårt skulle vi erstatte et eksisterende system. Produkteieren var veldig bevisst på å prioritere et sammenhengende sett med brukerhistorier som gjorde at brukerne kunne benytte de leveransene vi ble ferdig med i løpet av prosjektet. Det var to viktige vurderinger som produkteier tok: For det første må brukerne kunne utføre en arbeidsoppgave i den nye systemet, og ikke måtte hoppe mellom det nye og det gamle. For det andre må leveransene inneholde funksjonalitet som er interessant for brukerne.

Personer og samspill

Men produktkøen er den minst viktige delen av produkteiers jobb. Det smidige manifestet sier det selv: «Vi verdsetter personer og samspill over prosesser og verktøy.» Det er to viktige grupper som produkteieren må forholde seg til: Brukerne og utviklerne.

Involvere brukere

Før prosjektet startet, hadde produkteieren involvert brukerne i prosjektet. Mange brukere var blitt spurt om hva de mente var viktig med det nye systemet og noen brukere var valgt ut til en fokusgruppe. De to mest involverte brukerne deltok hele veien i prosjektet. Produkteieren identifiserte to brukere som de andre brukerne respekterte faglig, som forsto dagens system godt, som hadde meninger om hvordan ting burde være, og som ikke var redd for å si disse meningene.

Så snart vi hadde et produkt som kunne vises fram, satt vi dette i drift i demoversjon som brukerne kunne teste ut. Det viste seg å være vanskelig å få brukerne til å prioritere å teste det nye systemet. Det hjalp litt når produkteieren ga dem en oppgave de skulle utføre med det nye systemet (hjemmelekse). Det hjalp veldig når brukerne kunne bruke det nye systemet mot produksjonsdata som en del av jobbe sin.

Ekspertbrukerne deltok på alle demoer. Ettersom en av de bodde i Rogaland og en i Hedmark, var det vanskelig for dem å reise til Oslo for hver eneste to-ukers iterasjon. De første iterasjonene var de alltid til stede, men etter dette kjørte vi kun demo annen hver iterasjon. Etter et halvt år i prosjektet forsøkte vi også å kjøre noen demoer med screen sharing (go-to-meeting, tror jeg) og telefonkonferanse. Det fungerte ok, men vi fikk mye nyttigere feedback når vi møttes ansikt til ansikt. Ekspertbrukerne hjalp oss å bli flinkere og validerte arbeidet vårt når et var bra.

Kommuniserer med programmere

For å ha framdrift, var prosjektet avhengig av at produkteier og utviklere møtes hver dag. Produkteier deltok på standup-møtene hver morgen. Etter standup-møtene hadde han satt av opp til en time der en utvikler kan vise fram ny funksjonalitet og få tilbakemeldinger, der produkteier kan gi tilbakemeldinger til en utvikler på funksjonalitet han testet i går og der produkteier kan forklare detaljene rundt nye brukerhistorier.

Når produkteieren forklarte brukerhistorier, var han flink til å være konkret. Dette er alfa og omega når en produkteier snakker med utviklere. Forskjellen på å vise fram en skjermbildeskisse og å forsøke å beskrive et abstrakt behov er gigantisk. Forskjellen på å fortelle et eksempel og å forklare en abstrakt arbeidsprosess er enorm. Ved å bruke eksempler til å forklare brukerhistorier var produkteiers forklaringer gode for utviklerne.

Til slutt var produkteieren vår rask til å bestemme seg. Dersom det var et uklart valg, fikk vi ofte en avgjørelse der og da. Når produkteier måtte sjekke med andre, tok det en eller to dager før han kunne gi oss en beslutning. Noen ganger fant han senere ut at han måtte ombestemme seg. Da utførte vi ganske enkelt den endelig løsningen i en senere iterasjon. Det er mye mer effektivt å utvikle noe som er en rimelig hypotese, få tilbakemelding og så utvikle det riktige, enn det er å vente på en beslutning.

For å lykkes som produkteier, må du kunne bruke produktkøen effektivt, du må involvere brukerne dine gjennom hele prosjektet og du må kommunisere med utviklerne hver dag. Da vil du ha et vellykket Scrum-prosjekt!

Principal Software Engineer i Sopra Steria Norge. Har jobbet i 15 år med utviklingsprosjekter, hovedsaklig i Java. Arrangør og initiativtaker i fagmiljøet rundt Smidige utviklingsmetoder i Oslo.

3 thoughts on “Min supre produkteier

  1. Ahhh, Shift-dra rader! Dette har faktisk iritert meg, det at ikke var mulig ved bare å dra uten at det da ble overskrevet. Tusen takk for inspirasjon og svar på mail raskt, Johannes 🙂

Legg inn en kommentar