I recently received a question whether the Product Owner should participate in agile retrospectives. An interesting discussion took off about how “it should be by the book” and “common sense” which I have summarized in the below blog post.
The question if the product should participate in retrospectives was asked by a participant in a training from Erik Philippus (author of the guest blog post ervaringen met Agile en Scrum certificeringen and the overview of Agile / Scrum Certification) when preparing for his exam to become a Professional Scrum Master. The exam question asked if the Product Owner should participate in Sprint Retrospectives. Possible answers were that it was optional (if invited by the Scrum Master), mandatory (the retrospective is an opportunity for the Scrum team to assess themselves and improve) or not allowed (the retrospective is there for the development team).
Whether or not a Product Owner should participate in the retrospective
Where people tend to choose the first answer, the correct answer is actually the second one. Preferably, the Product Owner is there, after all, the entire Scrum team evaluates how the sprint has gone, and the Product Owner is part of the Scrum team. In addition, cooperation between the Product Owner and the development team is something that can be explored in retrospective, which makes it important that the Product Owner is there to participate in the discussions.
Where there is a strong hierarchy in the organization, and the team sees the Product Owner as someone who is above them instead of being a team member, and due to that team members do not dare to be open and to speak up about what is going wrong, then the Scrum master can ask the Product Owner to refrain from coming to the retrospectives. However, after several retrospectives the team should be capable enough to deal with such situations, and then it becomes important that the Product Owner joins the retrospective.
The first answer suggests that the Product Owner should only be there on invitation by the Scrum master. I see it differently, the Product Owner is there by definition unless the Scrum master requests him / her request not to come.
Erik’s reaction to my answer was:
I think the same about this, and in practice it is usually the case that the Product Owner attends the Retrospective. Makes sense.
Good, then we solved this? Well, almost. The rest of his response:
But as with many other topics, the correct answer to the exam question is not so logical. I have always understood that “if you play by the book” the Product Owner is not there, unless he / she is invited by the Development Team. It’s still unclear to me what the right answer to the exam question should be. Also it’s annoying that practice and common sense do not always match with the correct answers to exam questions …
What do “the books” tell us?
The Scrum Guide states that the retrospective is intended for the Scrum team. The Scrum team includes the Product Owner:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
This is consistent with the second answer of the exam question which stated that the retrospective is intended for the entire Scrum team, and it closes out the third answer (only the development team) clearly.
The Scrum Guide nowhere states that the entire Scrum team must always attend the retrospective, but given how things are described in the Scrum Guide that is what you would expect. It says nowhere in the Scrum Guide that the Product Owner must explicitly be invited.
Erik showed me a text from the Scrum Primer, which says that the presence of the Product Owner at the agile retrospective is optional:
Summary: Inspection and adaption related to the process and environment.
Participants: Team, ScrumMaster, Product Owner (optional). Other stakeholders may be invited by the Team, but are not otherwise allowed to attend.
Duration: Timeboxed to 45 minutes per week of Sprint.
This suggests that the Product Owner may participate in the retrospective, but it is not required to be there. Whether the team has to invite him / her or if the Product Owner can decide whether to take part or not is not clearly described in the Scrum Primer.
What I like in the the Scrum Primer:
Sometimes the ScrumMaster can act as an effective facilitator for the Retrospective, but it may be better to find a neutral outsider to facilitate the meeting; a good approach is for ScrumMasters to facilitate each others’ retrospectives, which enables cross-pollination among Teams.
This is something that I fully support, it’s important to assure that retrospectives are well facilitated!
Do what works for you!
As often with models and frameworks, multiple interpretations are possible. The healthy common sense from Erik and me tells us that we want to have the Product Owner in the agile retrospective. Fortunately in practice that is often the case, although there are teams that just need a little push to invite the Product Owner to the retrospective. Hence this blog post :-).
In the workshop Valuable Agile Retrospectives you will learn how to apply retrospectives effectively in your own organization. You will experience how to get the whole team involved to define improvement actions that will contribute to the goals and results of your organization.
This post is derived from the Dutch post Mag de Product Owner deelnemen aan de retrospective?
This frightens me, and this is why I believe Scrum has become detrimental to the Agile cause. My first concern is the, ‘play by the book’. Scrum has become (and it’s not its fault) a check-list recipe to what you should do to become Agile. Even the idea of an exam seems polar opposite to what you need to appreciate in order to be Agile. My second concern is the lack of humanity in the question. I’ve accused Waterfall practitioners of assuming teams are full of robots not people. As the number of ‘Scrum-check-list therefore Agile’ teams increases the understanding of Agile diminishes and therefore the likelihood of someone understand the responsibilities of any of the actors, especially the product owner, also decreases. When I see teams playing at agile the product owner is a stakeholder that often doesn’t understand, is typically very judgmental and always looking for problems. To invite them to a retrospective is sure way to ensure that no one says anything remotely negative. Of course the real outcome from those retrospectives is that you’re not agile, but in my experience the team just keeps going like the good waterfall team they really are.
Paul, I recognize and share your worries.
“Do it by the book” is not something that I desire, not at all. Agile nor Scrum nor any other framework like SAFe or Nexus is a rule book or a cookbook telling you how to do it. You have to find your own way of working and adjust along the way. My preference is to use the values and principles of the agile manifesto in doing this, simply because they make sense.
As I mentioned in my blog post, you can ask the Product Owner to not attend the retrospective initially if you’re afraid that team members won’t speak up. Then as a facilitator you can help the team to learn how to reflect and find a way of working that suits them, within a safe culture.
In almost all teams issues will pop up after time regarding the collaboration between the team and the Product Owner. Makes sense to invite him/her to the retrospective to discuss them. If the team then shuts up, I as a facilitator will give that back immediately during the meeting. Which gives the team several choices:
– The team keeps quit, doesn’t dare to speak
– The team recognizes this and speaks up
– The Product Owners opens up to team, invites them to give feedback
If the first happens, I’ll remind the team of the time when they were open and honest in retrospectives. Usually this signal is picked up, where we can work towards the team also becoming safe when the Product Owner is there. We can discuss safety and work on that.
When the other things happen, well, that’s where the interaction and feedback starts happening 🙂
Summing up, I share your worries, but a way to deal with it is to let it happen and make the team aware. If no action is taken after you’ve done everything that a facilitator/coach can do, then its clear that it will be a long trip before agility becomes in sight …
For me the issue is that you’re not Agile until everyone buys into it. That in itself isn’t a problem, striving to be Agile is a perfectly reasonable state to be in. What I dislike is the idea that, ‘we’re doing Scrum’ and yet I’m asking, ‘should I invite the product owner’? This is especially highlighted as this is related to an exam. If the question was, ‘as we’re introducing Scrum’ then it wouldn’t be a problem to me. I guess I’m just very skeptical about the quality of Scrum/Scrum-Master exams, training, etc. “I’m a Scrum-Master” seems to equate to we do stand-ups, have a backlog and a 2 week sprint…because that’s what I have in my Scrum Lesson Cheat Sheet. That’s not what Agile is about, ‘Individuals and interactions over processes and tools’. Scrum is in very real danger of just becoming a robotic process. I suppose I getting around to saying more companies need to employee coaches like yourself because they often make a mess of it when doing it on there own.
For me agile is not a state or goal, not something that an organization “is”. It’s a journey of continuous improvement which never ends.
Having said that I still share your worries on the level of understanding of agile. I did four years of full time schooling and then I was allowed to call myself a Bachelor in Science (BsC). But it took several more years to really understand what software engineering was about. Same for managing and coaching people, I’m still learning every day.
2 days of training are a tiny step. It can be an important step, and yes, helpful for many. But then you still have to learn how to walk, and keep on improving your walking skills!
I agree, in part. I would say a company is Agile when people understand the basic principals which included continuous improvement. I feel many companies believe they are agile simply because they have a Stand-Up. My bugbear is that they need to understand the value of agile rather than a prescribed approach. An exam format is likely to re-enforce this bad practice. The original post is a symptom that you have a problem, and yes you can address the symptom (by inviting or not inviting the owner) but the root cause needs to be resolved.
Agree with understanding the value Paul. This is also often lacking when organization say that they want to implement agile. When I ask them which benefits they expect from agile or why they want to do it, many don’t have a profound answer. Talking about root causes …