Scrum-produktledelse: Komplett veiledning + eksempler

Scrum er ikke noe nytt innen produktledelse. De fleste av oss bruker Scrum i virksomhetene våre og prøver å navigere i rammeverkets roller og prinsipper for å nå målene våre.

Det er dessverre vanlig at virksomheter feiltolker prinsippene i Scrum og bruker dem feil, og dermed fratar brukerne de mange fordelene ved Scrum.

Så denne lille, nyttige veiledningen handler om å hjelpe deg med å bruke dette rammeverket bedre ved å forklare hva det dreier seg om, hvorfor det finnes ulike Scrum-roller, hvilke ansvarsområder produktledelse har, og hvordan du kan lykkes med tverrfunksjonelt samarbeid.

Hva er Scrum innen produktledelse?

Mange av oss liker å diskutere rollen til en produktleder innenfor virkeligheten i Scrum-prosesser og smidig metodikk (med andre ord, hva PM-en gjør i et Scrum-team). I stedet for bare å forklare det synes jeg det er enklere å vise deg hvor PM-en befinner seg i organisasjonskartet for teamet.

I denne veiledningen ønsker jeg imidlertid å gå tilnærmingen fra motsatt retning og vise hvordan Scrum passer inn i din virkelighet som fagperson innen produktledelse, og hvordan det kan hjelpe deg med å nå produktmålene dine.

Jeg vil begynne med å diskutere hvilken effekt kjerneprinsippene i Scrum har på effektiviteten i arbeidet vårt.

Forfatterens merknad

Hvis du trenger å friske opp minnet om disse prinsippene, har Agile Alliance en flott veiledning for deg.

Sannsynligvis er det mest verdifulle Scrum-prinsippet for oss den kontinuerlige leveringen av verdi til brukerne. Jo raskere folk kan løse problemer, desto bedre vil produktet ditt prestere. I tillegg får du tilgang til tidlige tilbakemeldinger fra personer som har brukt funksjonen i en reell situasjon.

Den andre fordelen du får med Scrum, er fleksibilitet. Hvis markedsvirkeligheten endrer seg, kan du raskt tilpasse deg ved å gjøre en fullstendig omlegging av produktkøen og overlevere nye funksjoner til teamet ditt i neste sprint (dette er noe KI i sprintplanlegging kan hjelpe med).

Dette er to ting som er svært vanskelige (eller nesten umulige) å gjøre med tradisjonelle rammeverk som fossefallsmodellen, der alt er fastsatt når det gjelder omfang, og brukerne får tilgang til produktet helt på slutten av SDLC.

Eksempler på produktsuksess takket være integrering av Scrum

Etter å ha jobbet med Scrum-team i mange år er jeg helt klart partisk i favør av dette smidige rammeverket. Så ikke ta mine ord som den fulle sannheten. La oss heller se på virkelige eksempler der overgangen til Scrum hjalp produktteam med å lykkes raskere.

Microsoft Visual Studio: Teknologigigantens viktigste verktøy for redigering av kode var beryktet for sine gjentakende runder med produksjonskaos, med feilfylte lanseringer og utrolig sjeldne utgivelser. Fra det øyeblikket produktteamet begynte å dra nytte av Scrum, opplevde selskapet en kraftig økning i produktstabiliteten, sammen med langt hyppigere utgivelsessykluser – noe som gjenopprettet konkurranseevnen i markedet.

Spotify: Den kjære musikkstrømmetjenestens innføring av Scrum er blant de mest kjente i bransjen. Spotify hadde problemer med å tilpasse seg og skalere raskt nok til å løse prosessutfordringene sine ... helt til organisasjonen innførte Scrum. Det som imidlertid skiller Spotify fra andre, er utviklingen av deres egen modell for prosjektstyring med Scrum, som forutsatte en gruppe autonome smidige team med tilgang til all ekspertisen de trengte for å eksperimentere raskt og innarbeide tilbakemeldinger fra brukerne.

ING: Den nederlandske bankgiganten var blant de første finansinstitusjonene som innså at bankvirksomhetens fremtid er digital. De innså også at de svært tradisjonelle prosessene for prosjektstyring ikke var levedyktige for programvareutvikling. Derfor innførte de raskt lean- og Scrum-metodikk og ble, ikke overraskende, ledende innen nettbank.

Viktige roller innen produktledelse med Scrum

Hvis du som PM bestemmer deg for at Scrum er veien å gå, får du her en rask oversikt over de viktigste rollene i dette rammeverket, slik at du kan skille mellom rollen din som produktleder og produkteier i Scrum.

La meg begynne med rollene. Et typisk Scrum-team består av følgende personer:

• Scrum-master: Denne personen hjelper teamet med å følge Scrum-reglene og optimalisere prosessene sine.
• Produkteier: Denne personen representerer virksomheten og brukerne i Scrum-teamet. Produkteiere eier produktkøen og setter sprintmål og prioriteringer for brukerhistorier.
• Scrum-team: Utviklerne, designerne, kvalitetssikrerne og andre spesialister som bygger produktet.

Når det gjelder Scrum-teamet, kan du ha mange andre typer spesialister der. Konseptet med tverrfunksjonelle team forutsetter at teamet er selvstendig når det gjelder tilgang til faglig ekspertise. Hvis produktet ditt for eksempel er sterkt basert på analyse, kan du også ha en dataanalytiker på teamet.

Produktsjef kontra produkteier: Hva er forskjellen?

Definisjonen av produkteier som jeg ga, kan forvirre deg litt siden den høres veldig lik ut som det en produktsjef vanligvis gjør.

Så hva er i dette tilfellet forskjellen mellom produktsjef og produkteier?

For å forstå forskjellen kan vi først se på kjerneansvaret til hver av dem.

Produktsjefer

• Gjennomføre produktoppdagelse og forstå kundenes behov og utfordringer.
• Definere produktvisjonen og retningen teamet skal følge.
• Finne produktløsninger som kan møte kundenes behov.
• Lede prosessen for levering av produktet.
• Videreutvikle produktet i små trinn basert på tilbakemeldinger fra kunder og datadrevet beslutningstaking.
• Forvalte produktvisjonen og gjennomføringen på tvers av hele virksomheten.

Produkteiere

• Opprette og vedlikeholde produktkøen.
• Være én enkelt kilde til sannhet når det gjelder strategi, design og forretningslogikk for Scrum-teamet.
• Prioritere elementene i produktkøen og skape tydelighet for teamet når det gjelder hva som er viktig.
• Definere akseptansekriterier for funksjoner og godkjenne sprintresultatene basert på disse.
• Fjerne hindringer for teammedlemmer ved å klargjøre krav og løse problemene knyttet til dem.
• Delta i Scrum-hendelser og være virksomhetens og kundenes stemme i teamet.

Som vi kan se, gjør de fleste av oss ting som finnes på begge listene. Det er ganske normalt og vanlig, siden mange av oss fungerer som både produktsjefer og produkteiere samtidig.

Kjerneforskjellen mellom de to er at produktledelse er et yrke og et ferdighetssett, mens produkteierskap er en rolle i Scrum-teamet.

Men hva betyr det?

Det betyr at produkteieren ikke trenger å være en produktsjef. I en liten oppstartsbedrift, der du har en administrerende direktør sammen med tre utviklere, vil den administrerende direktøren ta på seg rollen som produkteier ved å gi utviklerne en prioritert produktkø.

Det motsatte er også mulig. Du kan være produktsjef uten å være produkteier. Jeg er et godt eksempel på dette, siden et av mine tidligere team ikke brukte Scrum. Ingen Scrum, ingen produkteier i teamet. Vi fulgte imidlertid lean- og smidige prinsipper.

For å gi deg en bedre forståelse av forskjellen mellom disse to kommer her en sammenligning side ved side av hva de gjør.

Men hva var egentlig poenget med å ha en egen rolle i Scrum-teamet? Kunne de ikke bare samarbeide med produktsjefer som ikke er en del av teamet? Jeg liker veldig godt hvordan Teresa Torres svarer på dette.

Hovedårsaken til at det finnes en spesifikk produktrolle i Scrum-teamet, er altså å bidra med intern produktkunnskap og ekspertise og ytterligere styrke tverrfunksjonaliteten deres. 

Hvordan produktsjefen samhandler med Scrum-team

Hvis du har bestemt deg for å følge Scrum, må du vite hvordan du skal være medlem av teamet og hvordan du skal samarbeide med kollegene dine. La meg gi deg en kort oversikt over dette for hver Scrum-hendelse og hvert artefakt.

• Daglig Scrum (også kalt ståmøter): Det viktigste arbeidet du gjør under disse tidsavgrensede møtene, er å besvare de produktrelaterte spørsmålene fra utviklingsteamet ditt og fjerne hindringer.
• Sprintplanleggingsmøte: Her er du personen som setter målet for sprinten ved å tydelig definere forventningene dine når det gjelder funksjonene du forventer å levere.
• Sprintretrospektiv: Prosessene du bruker for å levere prioriteringer og krav til teamet, kan avgjøre hvor effektive de er. Derfor kan du bruke dette møtet til å samle inn tilbakemeldinger fra teamet og forbedre prosessene dine.
• Sprintgjennomgang: Her er oppgaven din å godkjenne de ferdige funksjonene fra sprinten og gi teamet tilbakemeldinger på arbeidet deres.
• Produktforfining (også kalt forfining): Du eier dette møtet og må bruke tiden som er satt av til deg, til å diskutere prioriteringene og detaljene i brukerhistoriene du har for teamet. Oppmuntre alltid teamet til å utfordre kravene dine og finne «produktfeil» som du har lagt igjen der.
• Produktkø: Det er ditt ansvar å administrere produktkøen og holde den ryddig og prioritert, ettersom teamet vil bygge sprinten sin basert på den.
• Sprintkø: Det er ikke du som eier denne. Ditt viktigste samarbeidspunkt er å veilede teamet slik at de velger de riktige brukerhistoriene til sprintkøen, for å sikre at de kan nå sprintmålet ditt.

I tillegg til dette vil du utføre andre typer produktarbeid, for eksempel interessenthåndtering eller produktutforskning. Som medlem av Scrum-teamet er oppgaven din å holde teamet informert om både interessentenes og brukernes behov etter at du har avklart dem.

Hvis du for eksempel har et intervju med en bruker og oppdager at brukeropplevelsen i innloggingsflyten din generelt er forvirrende, er det viktig å dele denne informasjonen med teamet for å sikre at de følger med på denne delen i de påfølgende sprintene.

Beste praksis for produktstyring med Scrum

Selv om produktstyring virker enkelt når man ser det gjennom Scrums perspektiv (og smidig utvikling generelt), gjør vi ofte mange feil i arbeidet vårt i selvorganiserende team.

Her er derfor noen gode Scrum-praksiser som kan hjelpe deg med å unngå dem:

• Sett tydelige forventninger: Den største feilen du kan gjøre, er å gi teamet ditt uklare prioriteringer og krav. Manglende tydelighet er en viktig årsak til forsinkelser i utviklingen og spenninger mellom deg og teamet. Vi går snart grundig gjennom hvordan du kan oppnå dette.
• Ikke misbruk tilpasningsevnen: Det er flott å kunne endre kurs, men du kan bare gjøre det i produktkøen, ikke i sprintkøen. Så snart sprinten starter, må du ikke legge til eller fjerne brukerhistorier fra den. Det forstyrrer teamets planer og fremdrift og fører til uferdige sprinter.
• Skap et følelsesmessig trygt miljø: Du er medlem av teamet, ikke sjefen deres. Ikke press derfor teamet til å påta seg større forpliktelser eller bli ferdig tidlig. Scrum-veiledninger overalt, inkludert den fra Scrum.org, legger stor vekt på å opprettholde sunne relasjoner med lagkameratene dine, ettersom dette er en av grunnpilarene for effektivt teamarbeid.

Disse tre gode praksisene er de viktigste basert på min erfaring. Men hvis du ønsker flere tips om smidige arbeidsflyter og god Scrum-praksis for produktledere, bør du lese vår separate veiledning om smidig produktstyring.

Effektivt håndtering av produktkøen

Som jeg nevnte tidligere, er det å gi teamet ditt tydelighet en av de viktigste oppgavene til en produktleder. Den gode nyheten er at produktkøen din sannsynligvis er det aller beste verktøyet for å oppnå dette. Her er derfor noen tips om håndtering av produktkøen som kan hjelpe deg:

Forbedringsmøter: Uansett hvor godt du skriver brukerhistoriene dine, vil du etterlate «feil» der, og du vil at utviklingsteamet ditt skal kontrollere dem og gjøre deg oppmerksom på dem. I tillegg er du ikke utvikler og kan komme til å skrive krav som er vanskelige å implementere. Igjen vil teamet fortelle deg om dette under forbedringsprosessen.

Prioriteringsteknikker: Dra nytte av de mange prioriteringsrammeverkene for å forstå hvilke funksjoner som er viktigere enn andre. Min personlige favoritt er MoScoW på grunn av enkelheten.

Samsvar med veikart og visjon: Eposene og brukerhistoriene i produktkøen din bør representere de overordnede produktmålene og måltallene du ønsker å oppnå. Sørg derfor for å gjennomgå veikartet ditt jevnlig når du legger til noe i produktkøen.

Samordning av interessenter i Scrum

Kjernen i rollen som produktsjef i Scrum er at du i hovedsak fungerer som bindeleddet mellom det selvorganiserte teamet og omverdenen, enten det er brukere, interessenter eller andre team.

Så i tillegg til å utføre de vanlige oppgavene dine innen interessenthåndtering som produktsjef, må du også videreformidle denne informasjonen til teamet ditt, og omvendt. Det vil også være tilfeller der du må videreformidle informasjon fra teamet til interessentene.

Et godt eksempel er at det oppstår tekniske utfordringer, som problemer med kontinuerlig integrasjon, som kan påvirke tidsplanen eller omfanget til en gitt funksjon. Dette er noe du må diskutere med interessentene og enten akseptere den nye tidsplanen eller det nye omfanget, eller finne en annen løsning (for eksempel å styrke teamet med mer ekspertise på området).

Det finnes også tilfeller der teamet ditt kan ha kommet opp med en interessant idé til en funksjon eller en løsning som er verdt å legge til i veikartet. Igjen videreformidler du denne informasjonen til interessentene og avgjør om du skal legge den til i planen eller ikke.

Betydningen av smidig veikartlegging i Scrum

Selv om smidige veikart ikke er en direkte del av Scrum, er de et av verktøyene som gjør Scrum mulig. For hva er egentlig poenget med iterativ planlegging hvis du bruker fossefallsrammeverket for produktet ditt i stedet for et smidig veikart?

I så fall vil det du kaller produktstrategi for Scrum, ganske enkelt være å dele en forhåndsdefinert og fast plan med klassisk SDLC inn i deler på to uker (eller så lenge sprintene dine varer). For å gjøre Scrum meningsfullt for teamet ditt må du derfor drive med interaktiv, smidig planlegging og utarbeide et veikart som kan endres over tid.

For å knytte det smidige veikartet ditt ordentlig sammen med teamets Scrum-prosesser foreslår jeg at du gjør følgende:

• Knytt veikartelementer (vanligvis epos) til brukerhistorier i produktkøen. På denne måten får du en direkte kobling mellom det taktiske arbeidet ditt (historier) og strategien din (veikartet).
• Presenter veikartet ditt for Scrum-teamet. På denne måten vet de hvor produktet er på vei, og kan ta kommende funksjoner i betraktning når de utformer frontend- eller backend-arkitekturen.
• Utnytt spesialiserte verktøy som Jira, Monday.com og Clickup for å effektivisere prosessen for veikartlegging og håndtering av produktkøen.

Når det gjelder det siste punktet, er disse tre verktøyene de jeg har brukt i praksis. Det finnes imidlertid mange andre verktøy for produktledelse som du kan vurdere å bruke i stedet.

Utfordringer innen produktledelse i Scrum

Selv om Scrum er et godt rammeverk for å nå produktmålene dine, medfører bruken av dette rammeverket sine egne utfordringer, for eksempel:

• Teamet ditt eller interessentene dine forstår kanskje ikke hva Scrum handler om. Dette kan selvsagt føre til betydelige utfordringer med å ta i bruk Scrum, for eksempel at man nekter å bruke visse artefakter. Jeg anbefaler å ligge i forkant av dette ved å illustrere den ønskede «sluttilstanden» for hvordan teamet og arbeidsflyten vil se ut når rammeverket er fullt implementert.
• Folk (og du) kan bli forvirret over rollen din i teamet og utenfor teamet. Alle selskapene jeg hadde jobbet for i løpet av karrieren, hadde sin egen forståelse av hva en Scrum PO innebærer. Det er best å avklare hva det er – og hva det ikke er – for teamet ditt.
• Omfanget av funksjonene du jobber med, har en tendens til å vokse uten ende. Det gjør det ikke overraskende svært enkelt å havne i en situasjon med stadig økende omfang. Scrum-team må være kompromissløse når det gjelder hva de skal ta på seg, og hva de skal si «nei» til.
• Veikartet kan lett komme ut av kurs. Når du har et relativt uavhengig team som kan velge hva de skal jobbe med, kan du ende opp med at de bygger ting som ikke er en del av veikartet ditt. Å holde sluttmålet tydelig i fokus er avgjørende for å unngå denne fallgruven.

Selv om disse utfordringene er ganske vanlige, er den gode nyheten at det bare tar et par sprinter for produktlederen å finne ut av Scrum-prosessen og overvinne de aller fleste av dem. For dem som ønsker å formalisere ekspertisen sin, kan det å lære hvordan man blir Scrum Master gi ledere et troverdig fortrinn når de skal veilede teamene sine gjennom rammeverket.

Konklusjon

Scrum er en av de beste gavene til produktledere. Takket være balansen mellom å være smidig på lang sikt og streng innenfor korte iterasjoner kan du unngå kaoset i en smidig utviklingsprosess uten rammeverk, samtidig som du beholder muligheten til å endre kursen for produktet ditt basert på markedets respons.

Vi håper du likte veiledningen vår. Hvis du gjorde det, må du ikke glemme å abonnere på nyhetsbrevet vårt for flere ressurser og veiledninger om produktledelse, i tillegg til de nyeste podkastene, intervjuene og annen innsikt fra bransjeledere og eksperter.