I dagens indlæg vil vi fokusere på de mest almindelige udfordringer, som Product Owners står overfor. Vi vil også fortælle dig, hvordan du kan forberede dig på situationer, hvor disse fejl fra Product Owner oftest opstår.
Fejl fra Product Owner – indholdsfortegnelse:
- Hvad kan gå galt mellem Product Owner og Kunde
- Udfordringer, som Product Owner står overfor i forhold til resten af Scrum Teamet
- Resumé
Hvad kan gå galt mellem Product Owner og Kunde
Product Owner er den person, der er personligt ansvarlig for fejlene i Scrum Teamet. På grund af denne position uden for teamets aktiviteter betragtes Product Owner som den eneste, der kan klandres. Med andre ord, det er Product Owner, der lider mest, når Scrum Teamet fejler. Så hvordan håndterer man problematiske situationer, når de opstår, eller bedre endnu, hvordan forhindrer man dem i at ske i første omgang?
For at besvare dette spørgsmål har vi givet en klar og dybdegående analyse af nogle af de største fejl fra Product Owners og Kunder i den følgende tabel sammen med en detaljeret diskussion af hver enkelt.
Fejl | Genereret problem | Forslag til løsning |
---|---|---|
Uden evne til at prioritere | Ikke-optimeret Product Backlog, uklarhed omkring Produktmål | Lytte, stille spørgsmål, forhandle Produktmålet med kunden, omhyggeligt bearbejde resultaterne af forhandlingen |
Mangel på selvsikkerhed | For mange opgaver til Scrum Teamet at fuldføre | Tænke realistisk, kende og huske teamets kapaciteter |
Utilstrækkelige forretningsfærdigheder | Risiko for at sænke den forretningsmæssige værdi af det Produkt, der skabes af Scrum Teamet | Kontinuerlig læring og tilegnelse af forretningskompetencer |
Uden evne til at prioritere
Fejlen ved ikke at vide, hvordan man prioriterer, er en plage for mange Product Owners. Hvorfor er opgaveprioritering en kernekompetence? Fordi når alt bliver lige vigtigt, forsvinder Produktmålet. Det er den tilsigtede effekt af Scrum Teamets aktivitet.
Problemet starter allerede under de første samtaler med kunderne om Produktmålet. Kunden ønsker som regel, at alle hans idéer skal realiseres så hurtigt og billigt som muligt. Product Owners opgave er at etablere en prioritetsliste. Hans opgave er at skabe en liste over klare og gennemførlige forventninger rangeret fra de mest til de mindst vigtige, baseret på ustrukturerede kunde-forventninger.
Problemet med prioritering stammer oftest fra misforståelse af kundens forventninger. Det opstår, når Product Owner ikke er i stand til at udtrække information om de reelle Produktmål fra Kunden. Det er svaret på spørgsmålet om, hvilke behov produktet skal imødekomme.
Så hvordan beskytter man sig mod denne fejl? Først – lyt nøje til kunden. For det andet, lær at stille spørgsmål om Målet og hvordan hver produktfunktion fungerer. For det tredje – forhandle og begrænse de mål, der skal opnås. Og til dette vil du have brug for selvsikkerhed.
Når Product Owner har en liste over opgaver, er der dokumenterede metoder til at forbedre deres fremdrift og udarbejdelse. For eksempel bruges den såkaldte Eisenhower-matrix til at prioritere opgaver efter vigtighed og hastende kriterier.
Mangel på selvsikkerhed hos Product Owner
Problemet, der er nært knyttet til manglende evne til at prioritere, er manglen på selvsikkerhed. Det resulterer i uhensigtsmæssigt køede opgaver og fører til blokering af realiseringen af Produktmålet ved at komplicere det med for mange opgaver. Derfor er evnen til at sige nej til kunden afgørende.
Product Owner’s selvsikkerhed bør være baseret på tre søjler:
- kendskab til teamets kapaciteter,
- kendskab til de løsninger, der anvendes og udvikles af teamet,
- bevidsthed om deres rolle og værdi baseret på deres plads i Scrum Teamet.
Derfor er en af de vigtigste måder at forhindre problemer med selvsikkerhed på, at Product Owner arbejder sammen med Scrum Teamet dagligt. Dette vil hjælpe ham med at opbygge realistiske overbevisninger om tid og evne til at implementere kundens idéer.
Utilstrækkelige forretningsfærdigheder
Den næste fejl, vi gerne vil diskutere, er manglen på ordentlige forretningskvalifikationer. Styrkerne hos disse Product Owners er som regel specialiserede kvalifikationer. Deres kompetencer er mere nært knyttet til udviklingsteamets område end til forretningen. Så der mangler veludviklet, praktisk viden om konkurrencen, om markedets regler og den endelige kunde af det produkt, der skabes af Scrum Teamet.
Der er ingen simpel kur for det, da det kan opstå i meget specifikke situationer. Dog er det helt sikkert en god handlingsplan for en Product Owner at anerkende det og fortsætte med at lære og opnå erfaring og forretningskompetencer.
Udfordringer, som Product Owner står overfor i forhold til resten af Scrum Teamet
Evnen til at prioritere opgaver, Product Owners selvsikkerhed og hans høje forretningsfærdigheder er de nødvendige forudsætninger for at skabe en eksemplarisk Product Backlog, det langsigtede fundament for Scrum Teamet. Hvis Backloggen ikke er skitseret konsekvent og præcist, vil problemerne i forholdet mellem Product Owner og Kunde sprede sig til forholdet mellem Product Owner og andre medlemmer af Scrum Teamet. Og i sin tur påvirker de direkte effektiviteten af Scrum Teamet. Hvilke andre faldgruber venter Product Owner i sine relationer med de andre medlemmer af Scrum Teamet?
For at gøre det lettere har vi præsenteret problemerne mellem Product Owner og Scrum Teamet i en tabel. Nedenfor kan du finde en detaljeret diskussion af hvert problem og forslag til løsninger.
Fejl | Genereret problem | Forslag til løsning |
---|---|---|
Utilstrækkelig karisma | Udviklingsteamet udfører ikke opgaverne i Backloggen, Product Owners mening udfordres | Opbygge autoritet baseret på bløde færdigheder og viden |
Utilstrækkelige specialiserede færdigheder | Misforståelse af de daglige operationer og kapaciteter i udviklingsteamet | Orientering mod teammedlemmernes specialer samt at opnå viden om teamets ekspertiseområde |
Afhængighed | Uddybning af ansvar | Empowerment |
Utilstrækkelig karisma
På daglig basis er Product Owners job at koordinere kundens retningslinjer med den måde, de implementeres af udviklingsteamet. Dette kræver uden tvivl at have den rette autoritet, lyttefærdigheder og karisma.
Problemet med utilstrækkelig autoritet kan ikke løses fra den ene dag til den anden. Det kræver langsigtet arbejde med bløde færdigheder. Og også at opnå viden om omfanget af opgaver og færdigheder hos andre teammedlemmer.
Utilstrækkelige specialiserede færdigheder
Som vi skrev i artiklen, der besvarer spørgsmålet Hvem er en Product Owner?, er rollen som Product Owner ikke strengt teknisk. Men at kende grundlæggende specialiserede færdigheder hos udviklingsteamets medlemmer kan betydeligt øge en Product Owners autoritet.
Utilstrækkelige kvalifikationer inden for teamets ekspertiseområde kan ikke kun generere problemer med Product Owners karisma og autoritet. Fejlen ved ikke at være interesseret i, hvad medlemmerne af udviklingsteamet specialiserer sig i, og grundlæggende kendskab til deres kompetencer kan generere sjove situationer, men også situations med katastrofale forretnings og interpersonelle konsekvenser.
Derfor, for at Scrum Teamet kan levere produkter af den bedste kvalitet, skal Product Owner have en grundig forståelse af produktet. Det bør ikke være svært at få de rette kvalifikationer, når man tager i betragtning at Product Owner er en del af et team af fagfolk. De kan give ikke kun forklaringer, men også forslag til, hvor man kan få viden om deres felt.
Afhængighed
Product Owner skal være i stand til at træffe beslutninger uafhængigt. Selvfølgelig er det centrale spørgsmål at kende Scrum Teamets betingelser og konstant kommunikere med udviklingsteamet. Men det er Product Owner, der holdes ansvarlig for effektiviteten af sine handlinger. Af denne grund skal Product Owners opbygge deres autoritet og tage ansvar for de beslutninger, de træffer. Den endelige beslutning om teamets retning, prioritering og accept af opgaver tilkommer dem.
Resumé
Vi har opdaget de mest almindelige fejl fra Product Owner. Rollen som Product Owner er ikke en nem en. Derfor, når man påtager sig den, er det værd at forberede sig på de problemer, som andre har mødt på deres vej.
Problemer i kunde-relationer stammer som regel fra mangel på selvsikkerhed, manglende evne til at prioritere og utilstrækkelige forretningsfærdigheder.
Fejl fra Product Owner, der opstår under arbejdet med resten af Scrum Teamet, skyldes manglende uafhængighed og utilstrækkelig karisma hos den person, der har påtaget sig rollen som Product Owner. En anden årsag kan vedrøre manglen på specialiserede færdigheder og uvillighed – eller mangel på tid til at udvide viden.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Linkedin og Twitter.
Caroline Becker
Som projektleder er Caroline en ekspert i at finde nye metoder til at designe de bedste arbejdsgange og optimere processer. Hendes organisatoriske færdigheder og evne til at arbejde under tidspres gør hende til den bedste person til at gøre komplicerede projekter til virkelighed.
Scrum Guide:
- Ordbog over grundlæggende termer, roller og begreber
- Hvad er Scrum?
- Scrum værdier
- Hvordan implementerer man Scrum i din virksomhed?
- Scrum Team - hvad er det, og hvordan fungerer det?
- Hvem er en Product Owner?
- De mest almindelige fejl hos Product Owner
- Hvem er Scrum Masteren?
- De mest almindelige fejl hos Scrum Master
- Hvilke statistikker og målinger bør Scrum Masteren følge?
- Udviklingsteam i Scrum
- De mest almindelige fejl hos udviklere
- Scrum artefakter
- Skalering af Scrum
- Sprint Backlog
- Hvad er produktbackloggen?
- Hvad er brugerhistorier?
- At skabe den bedste User Story med INVEST
- De mest almindelige fejl i User Stories
- Brugerhistorie Acceptkriterier
- Estimering og Story Points i Scrum
- Planlægningspoker
- Team Estimeringsspil
- Definere inkrement
- Scrum begivenheder
- Hvad er et Burndown-diagram?
- Fordele og ulemper ved burndown-diagrammet
- Kanban-tavler i Scrum og Scrumban
- Hastighed i Scrum - Udviklingsteamets hastighed
- Daglig Scrum
- Sprintplanlægning
- Sprintgennemgang
- Hvad er en Sprint Retrospektiv?
- Almindelige fejl under en Sprint Retrospektiv
- Produkt Backlog pleje
- Hvordan opretter og fortolker man et burndown-diagram?