Begrebet “Product Owner” er navnet på en rolle i det meget udbredte rammeværk for agil udvikling kaldet ”Scrum”. I et hvert Scrum team skal være én med rollen som Product Owner.
Det er forklaret udemærket i Scrum-guiden på scrumguides.org hvad en Product Owner laver: som Product Owner er det dit ansvar at maksimere værdien af det dit team laver og at sætte klare mål for teamet. Det er også Product Owners opgave at teamets backlog forbliver forståelig og prioriteret.
Product Owner er ansvarlig for at maksimere produktets værdi som er resultatet af Scrum Teams arbejde. Hvordan dette gøres, kan variere meget på tværs af organisationer, Scrum Teams og enkeltpersoner.
https://scrumguides.org
Der er, som det også står i Scrumguiden, mange måder man kan gøre det på. Og Product Owners har almindeligvis også andre opgaver, end dem som Scrumguiden peger direkte på.
En Product Owners grundlæggende opgaver
Jeg har samlet et par typiske rejser ind i Product Owner rollen, og beskrevet de fordele og udfordringer, som følger med, for at forsøge at give et billede af hvad en Product Owner laver.
Men først en helt grundlæggende beskrivelse af, hvad en Product Owner laver.
En prioriteret og forståelig backlog
Product Owner har ansvaret for, at produktets backlog altid er prioriteret og forståelig. Det vil i praksis sige, at de opgaver som ligger øverst i backloggen er de opgaver som er højest prioritet og er dem som teamet skal tage hul på næste gang. Opgaverne som ligger øverst i backloggen skal være klar til at teamet kan starte på opgaven, fx ved at tage dem med i sprintet ved næste sprint planning.
Jeg har skrevet mere om hvad en backlog er.
Prioriteringen sker i samarbejde med teamet, når i sammen refiner backloggen, eller sammen med stakeholders uden for teamet, når i holder Sprint Review. Opgaverne på backloggen skal være forståelige for både team og stakeholders, som læser med på backloggen. På den måde er det tydeligt, hvilke problemer teamet arbejder på at løse.
Tydelige og inspirerende mål for produktet
Product Owner skal sætte retning for produktets udvikling og har ansvar for at udvikle og formidle et produktmål. Produktmålet kan være en ønsket tilstand for produktet, eksempelvis 6 måneder ude i fremtiden. Det skal ikke være et digert værk med underbyggende business cases og planer for implementering og gevinstrealisering. Det skal være en kortfattet og inspirerende beskrivelse af, hvad produktet skal kunne. Målet skal bruges som pejlemærke hver gang et nyt sprint planlægges.
Læs mere om produktmål, sprintmål og visioner i min guide.
Målet udarbejdes sammen med teamets og produktets stakeholders og Product Owner skal bringe målet i spil under samarbejdet med teamet og stakeholders. Når teamet refiner opgaver på backloggen, skal de ses i sammenhæng med produktmålet. Det kan være at produktmålet er skrevet ud på en plakat, som hænger i rummet – hvad end der virker, for at holde produktmålet present for teamet.
Optimere værdien af teamets arbejde
Når du har rollen som Product Owner i et Scrumteam er det dit ansvar at der kommer så meget værdi som muligt ud af det, som teamet laver. Derfor er det typisk efterspurgt hos personer i Product Owner rollen at de er gode til kommunikere og bygge relationer, så de kan komme i markedet med de ting, som teamet bygger.
Product Owner som er leder for teamet
Ofte vil en mindre virksomhed eller udviklingsafdeling, der går over til en mere produktorienteret udviklingsform placere lederen i rollen som Product Owner. Det vil ligge naturligt til den person at varetage opgaveprioritering. Det har også været den person, som i den tidligere organisering har haft ansvaret for retning som produkterne har udviklet sig i. Begge dele noget, som også ligger i Product Owners ansvar.
Evnen til at prioritere, og især at vælge opgaver fra, som ikke skal laves er essentiel for en Product Owner. Kontakten til vigtige stakeholders og resten af ledergruppen, som en leder vil have, er et vigtigt redskab, som en Product Owner kan få rigtig stor gavn af. Product Owner er leder af sit produkt og af sin backlog og skal have teamet og sine stakeholders med på den rejse, som produktet skal igennem.
Skeler vi til Scrum Guiden kan vi hurtigt se, at det er Scrum Master som er leder for teamet. Og altså ikke Product Owner. I denne situation, hvor lederen bliver Product Owner, er det altså vigtigt, at Product Owner finder sig en Scrum Master, som kan begynde at tage ansvar for teamet, teamets trivsel og udvikling. Det kan være svært, især hvis Product Owner bevarer en formel linjeledelse over team-medlemmerne.
En Product Owner som også er eller har været leder for en afdeling, er vandt til at kunne få sin vilje igennem et formelt mandat man har som leder. Et mandat man har fået, fordi man har vist sit værd, demonstreret et man har en god næse for at udvikle et eller en portefølje af produkter. Men som Product Owner med et godt agilt team i ryggen, er det ikke nok at bruge sin næse og sine tidligere erfaringer til at kalde skuddene. Man har som Product Owner en opgave i at gå empirisk til værks, og hente bevis for, at det man beder teamet om at investere tid i, rent faktisk har en værdi, kan lade sig gøre at bygge og er indsatsen der er at bygge det værd.
Product Owner som projektleder
Det er ret almindeligt at de første reelle forsøg man laver med Scrum, foregår i regi af et projekt. Det er også meget almindeligt, at man bliver hængende i en model, hvor projekter igangsættes af ledelsen, varer 6-18 måneder og implementeres af et scrum team. Teamet sidder typisk i IT-afdelingen eller sammensættes fra flere dele af forretning til projektet, som en projektgruppe. I denne form for organisering vil projektlederen typisk fungere som Product Owner for teamet der arbejder for projektet, samtidig med at personen varetager ansvaret som projektleder.
Projektlederen vil føle sig godt til rette i rollen som Product Owner, og vil kunne bruge mange værktøjer fra sin “projektleder-værktøjskasse”.
Arbejdet med teamet er i mange henseender ens for en Product Owner og en projektleder. Teamet skal arbejde sammen om et fælles mål og det enkelte team medlem skal både kunne bruge sine spidskompetencer og have plads til at udvikle nye.
Stakeholders skal plejes uanset om man er Product Owner eller projektleder og erfaringen med at arbejde med styregrupper og andre projektinteressenter, vil være guld værd for en Product Owner, som skal kunne prioritere og træffe beslutning med opbakning fra sit bagland.
Som projektleder er man vandt til at have et skarpt fokus på projekternes gevinster, og projektlederens erfaring med at arbejde med gevinster og gevinstrealisering er direkte overførbart på arbejdet som Product Owner, som er ansvarlig for at teamet leverer “værdi”, som på mange måder er det samme som projekternes “gevinster”. Arbejdet som skal laves for at opnå gevinsterne skal forståes og drøftes med relevante samarbejdspartnere og arbejdet skal nedbrydes i overskuelige størrelser, som kan sættes i gang.
Et fokusområde som måske vil være nyt for projektlederen, der bliver Product Owner er den helhedsorienteret udvikling. En Product Owner skal forvalte både drift og udvikling af sit produkt, ofte samtidig. Der skal rettes fejl, laves vedligehold og eksperimenteres med nye tiltag hele tiden, når man som Product Owner ejer sit produkt og har ansvar for at udvikle det.
Projektlederen som er vandt til at arbejde med projekter som “forløser sig” til sidst, når det store release er overstået og projektet lukkes, skal vende sig til en anden måde at arbejde på: Hyppige releases, løbende værdifulde leverancer og fraværet af en projektplan kan få det til at svimle for en projektleder – forståeligt nok. Det er min erfaring at det er her, projektlederen som skifter til Product Owner virkelig skal forholde sig åbent til nye måder at arbejde på.
Projektgovernance og rammer for styring af udviklingstiltag har de fleste projektledere omkring sig, på den ene eller anden måde. Det har Product Owners også, men rammerne er ikke ligeså veldefineret af flere årsager. Skiftet fra en projektdrevet til en agil udviklingsmodel indebærer ofte at man smider nogle af projektverdenens rammer væk, helt bevidst. For at slippe af med et slags bureaukrati som har vist nogle skyggesider, nogle uheldige magtstrukturer eller noget unødvendigt papirarbejde. Og de rammer der så trods alt er for den nye agile udviklingsmodel, er ikke ligeså gennemprøvet eller ligeså velkendte i organisationen, hvilket overlader meget til fortolkninger og de enkelte parters forventninger.
Specialist som Product Owner
Det er vigtigt at en Product Owner har et indgående kendskab til det produkt, som teamet skal varetage. Derfor er det nærliggende at rekruttere en fra “forretningen” som i forvejen er specialist, superbruger eller på anden måde har ekspertise inden for produktet. Den praktiske erfaring som en specialist bringer med sig ind i Product Owner rollen, kan virkelig sætte et team på sporet af at bygge de forandringer på produktet, som reelt skaber værdi for dem der bruger det. Fordi en specialist har førstehåndskendskab til hvordan produktet reelt bliver brugt og har en god forståelse for den forretning, som produktet indgår i.
Den erfaring som en specialist bringer med sig fra “driften”, kan også give specialisten som bliver Product Owner nogle blinde vinkler, som der skal arbejdes struktureret med at fjerne.
Måske har specialisten stor erfaring med en del af produktet eller med et udvalg af arbejdsgange, hvori produktet spiller en rolle, og har tendens til at optimere produktet imod lige netop de arbejdsgange og mister dermed blikket på helheden. Derfor er den for specialisten i forvejen gode relation til andre brugere af produktet særligt vigtig, når andre arbejdsgange skal forstås prioriteres.
En dybdegående viden om “hvordan vi plejer at gøre” kan komme i vejen, når teamet kommer op med nye ideer til, hvordan produktet kan udvikle sig. En Product Owner med specialistviden om produktet og dets anvendelse må gøre en dyd ud af at åbne sindet for alternative måder at anvende produktet på, for at være sikker på at kunne indfange ideen bag de muligheder som viser sig i samarbejdet med andre.