Should product managers and product owners be allowed in your team’s agile retrospectives?
When it comes to agile retrospectives, you hear this question a lot as product manager, product owner, or scrum master. It gets brought up because the scrum team is looking for a buffer to ensure they can openly discuss any topic or issue. I think the common answer is that they shouldn’t be — and if they are, they are only allowed to be facilitators, not participants. But if the underpinnings of your team require an artificial layer of privacy to communicate, the issues run much deeper than an agile retrospective. Here’s why I think you SHOULD allow your PMs and POs to join your agile retrospectives.
1. Definition of the Scrum team
According to the official Scrum Guide, the Sprint Agile Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Given that the scrum guide states that “the Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master”, we can officially declare POs eligible to attend. Digging a bit deeper, teams can have developers, testers, QA, database engineers, team leads, designers, and customer support members or more. Where would we draw the line?
2. Successful teams are cross-functional
Teams that have to ask that question might be framing the issue incorrectly to begin with. Thinking of the product owner or product manager as an outsider on the team is where things really go off the rails and veer away from seeing Agile results. Successful teams are cross-functional not solely technical and if the principles of Agile are to be maintained, key stakeholder perspective and feedback should be regarded.
Challenges to their inclusion revolving around lack of psychological safety in the culture or an inability to be truthful are revealing of significantly deeper concerns you should have for your team if trust is that big of an issue. Especially on smaller teams where everyone’s goals are so closely aligned and each person’s investment is so high, there really isn’t room or time for blame. It wouldn’t be agile if the team didn’t embrace openness and drive towards transparency to hear all of the opportunities for improvement for next sprint.
3. Actioning the outcomes of the meeting
Agile retrospectives without accountability are useless. They lead to weaker participation in meetings with less trust that feel like wastes of time. If these team members are part of the day to day activities but excluded from the ongoing process improvements, they’re being set up to fail at their jobs. The ongoing frustrations with scope creep, unrealistic expectations or the mythical man month will fall on deaf ears if the person them self doesn’t end up hearing them. Make the most out of your agile retrospectives by keeping these people looped in .
It can be tough to feel comfortable having these sensitive discussions. The answer unfortunately is similar to exposure therapy. The team needs to slowly get comfortable with it sprint by sprint because the ability to have your whole team present, listening and acting together saves time and bolsters empathy. Fragmenting the team literally splits your team apart. The team needs to grow, move, self-identify, and improve together.
