Question (should PO to participate retrospective meeting)?
should PO similar to other Scrum Team members attend and participate actively in discussions in the retrospective meeting?
I myself think that he/she must attend and support the improvment process by sharing his/her feedbacks and geting ideas from disscusions.
But I have read recently that is controversal and the presence of PO might have impact on Dev. memebers' safety feeling (hidden gun effect) ?
What is your oponion/ experience from project? pros / contras?
Ask the team to decide, would they like PO there for the first time if its not been done before.
Explain the benefits of having the PO there from an end to end perspective.
Ask the PO to get involved at the retro, don't just turn up and sit there with no input as prep work,
If the team agree and goes ahead and find it useful re vote it at the end of the retrospective.
"Team would you like the PO in or out at the next Retrospective, is it useful to you"?
If the team find the PO is a hindrance then they can choose not to have them there, but do seek to find out why.
Coach the PO on the points that the team don't like and try again and see what the result is.
Scrum team includes the PO and the PO can always share what their experience was, i think this is also valid.
We have had this dilemma recently and now its the teams wish that the PO is there and contributes.
Ultimately it was their choice to run with it and see, and now they like it so we re vote it every retro at the end.
Before they had never even considered it.
@michael : Thanks to share your experience.
I am/was just suprised why a group of scrum member (here: Dev.Team) are allowed to decide about excluding / including of another member of the team( PO)!
It could also be a memeber of Dev Team, who is dominant and suppresses the others in the retro meeting. We do not try to exclud him/her from retro , do we?the SM should find a way (coach) the dominant and passive members and help the team to find a balance among participants. For me excluding PO from meeting is similar to taking asprin for get rid of high fever instead of searching and solving the root cause. The confrontation with the conflict in such a internal meeting could be a great chance of improvement.
I found also the explaination on pages 54, 55 in chapter 4 in the book "Scrum Product Ownership written by Robert Galen" very helpful. he is also against excluding PO and gave following two reasons:
First, I like the model where the Product Owner IS an included member of the team. They engage, are accountable to, and collaborate with their team. It's a central theme in this book and to becoming a great Product Owner.
Second, as a team member , I want them to be involved in the retrospective.Yes, They have a different point of view and role. And yes, they might have a tendency to de-rail the meeting. But , that's why the scrum Master is there as the facilitator and also their partner. To me , the positive influence that the Product Owner can have in partnering with the team in continious improvement journey is far outweighed by any dangers. But that's just me..
I agree with that write up, the benefits are greater.
It all depends on the team, a team that is more mature may find this easy, a new team to scrum may not find this a simple task, last thing you want is a non productive retro as that defeats the purpose.
This could happen as they never move on from the person they don't want there.
If the focus always drifts back to someone they don't want there, if we think scrum its the teams responsibility when it comes to problematic members so they should self organize.
There could be history between the PO and the dev team, all number of reasons.
If you vote it each session at least they are included and decide, you get to test what their thoughts are and why.
Its the teams responsibility to deal with problematic members if its not working or cant work.
Inclusion for the PO if the PO can contribute is great, the team also see that the PO wants to be part of the team.
The plus is if its a PO improvement they are aware of the discussion and feeling around it, this is the big plus.
Bringing together the whole scrum team as a team as an end to end unit, this is where the real benefits are.
This is what i would sell if they haven't done this, but do make sure the stage is set.
Good luck with what ever the outcome is with the team
The Scrum Guide states clearly that a Sprint Retrospective is held by the Scrum Team. By definition that must of course must include the Product Owner. This is because the process that is subject to inspection and adaptation is not merely one of development. It is also one of backlog management, planning, and incremental delivery. The PO is a stakeholder in this process and must therefore have a voice.
It's often assumed that this is not the case, and I'd say that the pathology of an "excluded PO" is common enough to be an anti-pattern of sorts. The forces behind it can often be traced to an established cultural separation between IT and Business. This can - but does not necessarily - involve a lack of trust. In either case it's important to hammer out any differences and to establish ground rules so a PO can usefully participate. The Scrum Prime Directive, although non-canonical to the framework and arguably overkill, can be used as an acid test. It's conditions must hold true before a Retrospective can even start.
Other factors influencing a PO's absence might include:
- A lack of commitment by a PO to the Scrum process
- PO's might see Scrum as a development thing, and not "their" concern
- PO's might think they have better things to do with their time than to attend a Retrospective
Again, these are contra-indications to the good application of Scrum. It's important that these problems are *not* accepted, but instead are actively resolved.
Often, the dev-team members use the retrospective to deal with very technical subject, and they don't want / don't need the PO for that.
Maybe they don't want to annoy the PO or don't want to expose their weakness.
These reasons sound bad to me. More often, the real issues are communication issues and the PO is very concerned about that.
If the dev team members don't want to expose their weakness to the PO, that mean they don't count him as a Scrum-team member, they deliberately lower the transparency of the process. I saw this recently with a dev-team full of geek, very focus on coding User-stories, instead on delivering value to customers.