Scrum: Is it okay for the development manager to be the Product Owner

Question

My company is going through an agile rollout and is currently considering options for what that means.

The ScrumMaster role is somewhat straightforward, but Product Owner has many candidates: Product Managers, UX, Software Analysts. The favored candidate for the moment is for each development manager to be the team Product Owner.

However, using development managers as product owners seems like it will discourage self-organization. What's the "right" way to select product managers in an Agile way?

Answer 1

Generally speaking, the person who knows the most about the application requirements or has the responsibility for interfacing with the client is the one who should be the Product Owner.

If the development managers in your organization have the best knowledge of the product's requirements, then they ought to by the Product Owner. Developers need to be able to go to the Product Owner in order to clarify requirements and make sure that what they're developing is actually meeting the requirements.

As far as self-organization is concerned, I don't believe it should have an effect unless the developers report the development managers.

If the developers do report to the individual development managers, then the developer's performance metrics should be adjusted so they are not penalized if they work on other manager's requirements. Likewise, rules need to be put in place so a particular development manager doesn't leverage their employees to gain priority for their product development at the expense of other requirements.

You may consider enhancing the scope of the ScrumMaster in order to make sure that the development managers don't exert undue pressure on the developers in order to change previously agreed upon priorities for the user stories.

Answer 2

As @Contrarian mentioned, the Product Owner needs to understand the requirements and is usually involved in a business perspective with clients or Product Managers who are influencing the overall product releases. Prioritization is a key feature here as well, so this person needs to be granted the power to decide on priority of what to do.

In most situations, a Business Analyst makes the jump to a Product Owner very easily. If you currently have somebody playing this role, they make a great PO.

In some organizations, however, the requirements are actually clarified to the team by an architect who has an overall vision of the product or of a particular module/component of the product. These individuals can act as the Product Owner and can help with prioritization, though they may not necessarily be involved in the business/client-facing side traditionally.

As for using a team's direct development manager, I would caution against this. It is one thing to have a colleague informing you of priorities and representing the client's needs, and quite another to have your boss doing it.

Imagine your colleague tells you: "Jay, the buttons here aren't going to work for the client. They don't match the branding guidelines." You can have a conversation about it, go back to your work, and ship out something new for a review.

Now put your boss in that place. Suddenly it's no longer about a conversation to get to the right deliverable and is now about performance. You will avoid showing things early on to get feedback because you might look bad to your boss. You will not necessarily be honest about what you are building or how much you have left. An agile team needs to be transparent to each other so that they can react and adjust.

That being said, we have put development managers in some of our teams, just not as the Product Owner. We will have them involved as a team member who happens to also be providing technical advice or support to the Product Owner and Scrum Master. This allows their knowledge and access to other levels of the organization to be a tool that the team can use, without them being able to have complete control over all aspects of the sprint.

Answer 3

Look for the person on the team that is strongest in these qualities:

1. Knows the general business (not just the customer's business)
2. Has the relationship with the customer
3. Good at logically breaking down customer wants into little business-value oriented stories (Pretty much the Agile BSA mentality)
4. Has process improvement skills
5. Has change management skills

As far as self-organization; a PO generally shouldn't have any direct reports on the delivery team as this can be a conflict in interest in terms of the team challenging the PO on requirements, priorities, etc.

A great PO will be a BSA at heart, but should always be considering the process and change management impacts that go along with delivering a technical solution. After-all, building a solution that doesn't fit within a current or future process, or that no one adopts doesn't provide much value to the customer.

Answer 4

After years of observing organizations struggle to effectively implement Agile processes in general and Scrum in particular, one thing became clear to me. The PO role has been defined incorrectly in most organizations which has led to wildly uneven results.

I am in favor of seeing a dev lead/manager assume the Scrum role of Product Owner (PO) over someone like a Product Manager (PM) or business stakeholder. In this scenario I am making the assumption that a PM or other business stakeholder is involved in curating the product roadmap and backlog at the Epic/Feature level and the PO and Scrum team will work with the PM/stakeholder to define User Stories, Tasks, and the development backlog.

With a dev lead/manager in the PO role I believe it becomes very natural for the PO to facilitate backlog refinement with the team where features are discussed and refined into individual user stories and tasks to the point that the team knows exactly what needs to be done and an idea of how they are going to do it as well as how long it will take. In this scenario, the PO and team also know the order in which they need to deliver stories in order to maximize dev efficiency while meeting the larger timelines of features/releases.

Scrum is a development methodology not a Product Management methodology. To this day organizations still try to shoehorn Product Managers into the PO role and in my opinion rarely works well. Let dev leads/managers do what they do best, lead highly productive dev teams.

I believe this has been one of the downfalls of Scrum and the primary contributor to uneven results and bashing of Scrum. If your organization is trying to implement Scrum, do yourself a favor and embrace the idea of using dev leads/managers in the Scrum role of PO and I think your results will be much better.