The role of the Product Owner in Scrum
Much has been written about the role of the Product Owner (PO) in Scrum over the years, and it seems to me that in the last month or so the issue has received a lot of attention on blogs, Twitter, and other social media. I don’t think there is a “best practice” answer. Let’s see what we know and then see if we can find an answer. The goal of the purchase order should be to deliver the right business value. To do this, they engage the team(s) to create solutions that deliver business value.
They are listening to and assessing the needs of the stakeholder community. They must have great business sense and understand their market and customers. They must understand what is technically possible. From all these inputs, they deliver a flow of information to the team about what the priorities are. They constantly update this information and review the team’s results to verify that they are complete and correct. While the team has the same goal of delivering business value, their problem space is very different. In all but the trivial domains and projects, this requires a team approach. Team building is not about money. Just ask Yankees owner George Steinbrenner!
Team building is not about technology or computers. Team building is about people. However, the problems the team faces in delivering the solutions have to do with technology. The team takes the direction (course) of the PO, but he or she cannot work in the engine room of the Scrum ship! It’s not that they’re not qualified (they may not be), it’s just that their primary role is so important and time consuming that they’d be neglecting that duty if they did. The team must take the direction (heading) from the PO. Your job demands your full attention. We know all this. The real question is how do we best create the communication and feedback that the Product needs in order for the business to succeed and thrive? Scrum provides a great starting point. Lean helps us understand the product vision and the business value stream. The product launch planning process should include input from the team. Sprint planning is a cooperative process between the team and the product owner.
The daily stand-up is a team meeting that is critical to team building. Scrum tells us that the Product Management Team can listen to this meeting, but it is the Team meeting. If I were a product owner, I’d be in daily stand-up if possible. The Sprint Review and Demo is about the team getting feedback from the Product Owner and any interested parties. If I were on a team, I would NEVER go into a Sprint Review without knowing what the Product Owner thought about the Sprint outcome. The Sprint retrospective is a team meeting. This meeting is primarily focused on team building and process refinement. This should be a private team meeting.
Can the Product Owner be a benefit to the Team in the daily solution development process? It depends. How much time do you have? How well do they understand technology? How well do they work within the team? No one can know the answers to these questions without looking at the Product Owner and the Team. Will the Product Owner be a useful, accepted, and valued member of the team? It depends. Can the Product Owner deliver the flow of information and decisions to the team with a high level of accuracy? It depends. With all these unknowns, I don’t think anyone can say how a particular Product Owner and Team will be able to work best together without first-hand knowledge.