Vi har i vår bedrift satt igang med ett Kaizen team. Altså ett slags scrum master forum der alle scrum mastere på de forskjellige teamene møtes og utveksler erfaringer. En av tingene vi skal diskutere er PO rollen. Problemstillingen er at PO’ene ofte mener det tar for mye av tiden deres å være med på all scrum aktiviteten. Dette fører igjen til at de gjerne vil delegere scrum forpliktelsene sine til andre. Noe som kan føre til miksing av rollene. F.eks får scrum master også en slags PO rolle eller andre på teamet ofte får en rolle som overlapper PO rollen. Er det noen som har erfaring fra lignende problemstillinger, hva er ulempene med å få en slik overlapping av roller og hvilke gode argumenter skal man selge til PO for å få de mer engasjert om de ikke er det fra før.

Det er viktig å ikke blande sammen rollene på den måten. Man skal ikke være både leverandør og kunde. Hvis PO sliter med å sette av nok tid så bør dere se på muligheter å forsterke PO rollen.

Jeg har skrevet litt om PO rollen og lignende problemer her: http://www.leanway.no/?p=324

Takk for svar. Enig at det er vanskelig å vite hva kundene vil ha hvis man ikke er ute blandt kundene, som en scrum master og utviklerne på teamet vårt sjeldent er. Fin artikkel skal ta den med videre!

Problemet er større enn så. Rolleblandingen vil ofte lede til overambisiøse løsninger. Jeg skal snakke om kunderollen på Software2010 konferansen: http://www.dataforeningen.no/index.php?id=4663451

Hei gegge, du har jo fått gode råd fra Niklas. Jeg mener i tillegg at rolleblanding er uheldig i seg selv. De tre rollene har en viss spenning seg i mellom og bør rendyrkes. Alt for ofte ser vi at Scrum Master – eller noen i Teamet – er “snille” mot PO og gjør en del av jobben hans. Da vil du tåkelegge problemet og det går lett ut over den andre rollen.

Jeg er usikker på hva du mener med “all scrum aktiviteten”.. Ikke uvanlig at PO får problemer med å få tiden til å strekke til, men bruk retrospectivene til å diskutere dere fram til mulige løsninger i stedet for å være “snille og greie”. Husk at PO må få opplæring i rollen.

Jeg har også skrevet litt om PO her: http://scrummaster.no/?p=276

Fulgte linken i artikkelen din og leste artikkelen:http://blog.xebia.com/2008/05/22/scrum-the-myth… av Machiel Groeneveld der forskjellige typener PO blir presentert. Dette er veldig sammenfallende med vår situasjon. Jeg vil si at vår PO ligner mest på “PO the Product Manager” beskrivelsen i artikkelen. Problemene som er mest aktuell for oss er at PO har en veldig kundeorientert jobb og derfor klager på at det går for mye tid på scrum teamet. Mitt mot argument mot dette er at tidligere har de som nå er PO måtte skrive kravspesifikkasjoner og dette tok vel også en god del tid. Dette er jo noe som nå er blitt erstattet med planlegging og backlog grooming sammen med teamet.

Vi har heller ikke noe konkret forhold til begrepet buisness value. Kanksje er dette det som kan få PO mer på skinner. Har noen her erfaringer med bruk av buisness value?

Det jeg mener med vår scrum aktiviete er ting teamet ønsker at PO skal være med på i løpet av en 2 ukers sprint:
• Være med på planning (2 timer hver sprint)
• Være med på review (2 timer hver sprint)
• Være med på så mange morgenmøter som mulig (hvis med på alle morgenmøter 2,5 time)
• Være med på backlog grooming møter (2 timer)
• Prioritere backloggen
• Avklare spørsmål og spesifiseringer i forhold user stories i etterkant av backlog grooming

Dette er ikke for mye deltakelse. Hvis PO ikke rekker dette må dere se på å forsterke PO rollen. Resursen kan hentes internt eller eksternt, men ikke fra leveransesiden. Merk, dette er ikke knyttet til Scrum. Det er like viktig uansett hvilken smidig tilnærming dere har.

Dette omfanget var da ikke mye! Det eneste han sikkert kan kutte på er dette med “Være med på så mange morgenmøter som mulig”. Hvorfor skal han det? Alt det andre virker som minimumsløsninger.

Jeg forstår på ordbruken din at Scrumforståelsen skranter en del hos dere. Begrepet “Scrum forpliktelsene” skurrer veldig. Brukt riktig skal ikke Scrum medføre “overhead”. Det aller viktigste å være god på innen smidig systemutvikling er retrospectiver. Man skal utfordre alt som “lukter waste”. Men første bud: Sørg for at PO (og alle andre) får skikkelig opplæring i Agile/Scrum. Om ikke det er på plass kan man ikke regne med å få sving på sakene. Desverre.

Men så vidt jeg forstår av de fleste erfaringene folk har gjort på bakgrunn av artikler og diskusjoner jeg har vært borti så er vel situasjonen i forbindelse med at PO ikke har nok tid enten ett spørsmål om vi har skjønt rollen korrekt eller om de faktisk ikke har tid fordi de har for mange andre oppgaver. Så dersom det er at vi har misforstått rollen så er det vel bare opplæring som mangler. Dersom det derimot ikke er tid pga andre oppgaver så kan vel å styrke PO rollen være en mulighet.

Har mye å lære ja:) det jeg mener med “scrum forpliktelser” er de tingene som går på PO altså å vedlikeholde/prioritere backloggen, være med på planning og review samt morgenmøter. De punktene som jeg beskriver over i lista er hvordan vi foreløpig prøver å gjennomføre dette pr idag. Mener ikke at det skal være forpliktet å gjøre disse tingene på en fast måte dersom det skaper overhead. Tenkte bare på de tingene jeg har fått inntrykk av skal være PO’s oppgaver i scrum. Dette har iallefall vært min oppfatning til nå. Men hvis dette ikke høres ut som om det er på rett veg så er jeg nok å se på neste smdig seminar for å prøve å få litt fart på sakene!

Tusen takk for gode tilbakemeldinger!!!