How to focus a Product Owner’s efforts

Question

My agile team has no team lead (which I actually think is a great opportunity) they have me their scrum master and product owner.

I have noticed the product owner is not very experienced and has been trying to get involved in too much stuff: team lead stuff, workflow and process stuff and even some scrum master stuff and neglecting PO stuff which is so in need for this team.

Does anyone have advice about how to broach this subject with him. I don’t want to dampen their fire, I want to focus their fire in the right direction if that makes sense.

I want him to focus on PO stuff.

Answer 1

It is not, per se, a problem that the Product Owner is doing other work. I remember I was once on a Scrum Team which had a superwoman who was the PO... as well as a Project Manager, Business Analyst, Quality Assurance personnel, Salesforce expert and boss's personal secretary. Not at all optimal, but necessary given the circumstances.

The problem is that the PO is not getting actual PO work done. If the following is not being done:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Then you don't really have a PO in the first place. Which could be the start of the conversation in the Retrospective.

"Hey guys, I think we need to have a Product Owner on this Team. Should we hire someone new, or does one of us think we could do it?"

"Uh, I already am the PO."

"Oh, great! Then, can you make sure this (show the list of the PO duties in the Scrum Guide, as above) gets done?"

"I don't have time for that."

"Then we don't really have a PO. Which brings me back to my question: Do we hire someone else to be a PO, or can you find the time to complete the PO duties?"

Of course, that's just one way that conversation could go. It's possible he really can find the time to do the PO job while still working on other things (or perhaps only thinks he can, which would prompt another conversation later on, but give him a chance first). It's possible he'd really rather be a BA, and so hiring a dedicated PO may be a good idea.

Answer 2

My agile team has no team lead (which I actually think is a great opportunity)

Absolutely! "Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule"

Does anyone have advice about how to broach this subject with him. I don’t want to dampen their fire, I want to focus their fire in the right direction if that makes sense.

Reviewing The Scrum Guide with the Product Owner (even the entire Scrum Team) is an option. Utilizing the Sprint Retrospective to self-organize is probably a better option. There may a valid reason for a Product Owner to be involved with some of those items, especially "workflow and process stuff", so having an open, candid, collaborative, and constructive conversation is extremely important. Keeping the division of roles is important, but not at the expense of dysfunction within the Scrum Team.

Answer 3

While I am sure there is formal guidance available in various Scrum and PO guides, I am not sure this is an issue of your PO not knowing what their role is, but rather their enthusiasm (fire, as you said) or ambition in other aspects as well. A common team and organizational issue.

I think a great way would be to not focus on all the extra stuff your PO is working on, but only on solving the problems you are facing because of the lack of PO stuff that they should be working on. It would make sense to schedule a one-on-one session as well as a session with your full team where you could highlight specific challenges you might be facing - such as lack of sufficient user stories, lack of proper prioritization, ineffective Sprint planning sessions due to these reasons, loss of face with customer if applicable, etc.

Two observations I have made about software teams - irrespective of whether they follow Scrum or Kanban or other methods -

1. The biggest issue Dev teams have is not knowing what exactly is the priority of work they should take up. This is because the PO (or product manager) have a tough job on their hands about getting stakeholder agreement on what the next set of features or user stories need to be worked on next. Depending on your context, these could be external customers, internal customers such as Sales or Support or Marketing, or business users in a corporate IT context.

2. There isn’t enough focus or visibility for the work a PO needs to do in order to ensure a regular and timely availability of the right work for the Dev team to work on. The process of defining and managing a product/ application roadmap, and prioritizng a specific set of features or enhancements release after release, is often not understood either by the PO or the rest of the stakeholders and the Dev team.

Consequently, there is always friction between the PO/ PM group and the Dev team, with missed features/ release dates due to communication failure between the two groups. As a product manager for my company, I have faced this challenge and have spoken about it in several events. Here's one of my presentations that might be of help - https://www.slideshare.net/maheshsingh01/visual-requirements-management-with-kanban-v2

We solved this problem with our transition to Kanban - and specifically when we set up an "upstream" Kanban board for our PM team, supported by a couple of meetings - a bi-weekly Replenishment Meeting and a Monthly/ Quarterly Planning/ Strategy Review meeting. The latter helped all stakeholders - including the Dev Team - understand overall priority for the organization and the team, as well as specifically identifying the high-level themes and epics for the quarter/ month. The replenishment meeting serves as a Release planning and a mid-release course-correction meeting, and they ensure that each release is by and large delivering the stuff we need to deliver, and everyone is in agreement on that. Our release schedule is roughly 4-6 weeks.

Here's how our Kanban boards look - a Roadmap Planning board and a Dev Board -

The PO (PM for us) is responsible for this board - and making sure that user stories flow to the Dev board in a timely manner -

The Dev manager owns this board -

While the idea is not to dump a Kanban board at your situation, I suspect helping your PO might be done either by specifically discussing your Dev team's challenges or by trying to get the PO to understand their own process, so they can better focus on doing all the PO stuff they need to be doing (using the Kanban board above as an example). Or you can do both!

Hopefully, this will help you get their efforts focused with better outcomes for your Dev team. At the same time, the PO will have got a few tools to manage their own work better - and also highlight challenges they face in their own processes.