That time I kicked the Product Owner out of the Retrospectives
Mistakes were made
Long ago, and not so far away, I was a Scrum Master for a team of developers. We were all new to the codebase. Our Product Owner had years of experience with our domain and our codebase. We deferred to his opinion in all things, unnaturally so in the Retrospective meetings. I asked him to stop attending.
Not having the Product Owner at the retrospective for a meeting or two while we found our groove might not have been too bad, but I never thought to reinvite him. Imagine all of the valuable input we could have had!
What I've since learned
- This Product Owner was extremely coachable. Had I identified the problem to him, we could have worked together on strengthening the developers and the team.
- There are many techniques to help gather input from the whole team to avoid the "loudest talker" problem, or in this case, the most influential voice. Two of my favorites are retromat.org and liberatingstructures.com.
- mob programming exists
What I hope to do in the future
- Try to keep the team whole. Coach the Product Owner and the developers about how deferring to the product owner in the Retrospective reduces our chances of having great new out-of-the-box ideas for improvement.
- Intentionally use retrospective techniques that are designed to balance the individual input.
- Be intentional with team building. Help the Product Owner see the developers' strengths and the developers see the Product Owner's humanity.
- Coach the Product Owner to vocalize the value of each developer in order to help them know that their voices are valued.
- Mob program with the Product Owner, particularly as we were ramping up on the code base and domain.
- Follow-up with the Product owner if I kicked them out despite my hindsight.
- Target (at least some of the) retrospectives on specific issues that the whole group can contribute to.
- Train the group on the domain more.
- Train the group on the codebase more.
How can you improve based on my mistakes?
