Organisation fails to deliver a Product Owner

Question

I am working in a Scrum-team that has been developing software for the past year. The organisation isn't used to agile product development and initially provided a weak product owner who was chosen because of his functional knowledge about the domain, but since we're developing both a functional system and a new technical architecture, he recently quit this position because he couldn't find himself adding much value to the team.

Besides the Scrum-team (programmers and testers), there is a relatively new separate project leader/manager who is responsible for budget, a software architect approving technical decisions and a requirements engineer (currenly 'interim product owner') who sees himself as chicken helping out the hypothetical product owner. And then there is the test department and operations. These all are the stakeholders in this project and the organization has trouble appointing a product owner, because they 'can't find anybody who has enough knowledge and time to take on the job'.

Fortunately most of my colleagues are smart, pro-active people and we are constantly debating among ourselves to make the right decisions and I think we're doing quite well under the circumstances.

However, not having a product owner does slow us down and demoralizes the team in my opinion, because nobody seems to want to take responsibility for the final product except for the project leader/manager who only appears for demos, when approving timesheets and in weekly 1 hour meetings to inform the team about future organizational plans regarding this product, but also giving us a chance to speak up if there are any issues. A while back, I have asked the project manager to invest more time in making and maintaining a full release planning, so we can plan ahead and make choices about priorities accordingly. Although he response was positive, I have yet to see any results.

How would you proceed?

Answer 1

TL;DR

The Scrum Master should work with the team to identify the costs to the team, the project, and the stakeholders that are related to the missing role. This information should be gathered in a transparent way, and the results should be highly-visible to the entire organization.

Ultimately, senior management must fix this problem. In the meantime, the team should do its best without violating the principles of Scrum, understanding that it's sub-optimal and will remain so until the organization invests in meeting the managerial and structural obligations of Scrum.

The Costs of Indirect Product Ownership

Only the Product Owner can add or remove stories from the Product Backlog. Only the Product Owner can change the priority of Product Backlog items. Therefore, having a missing, disengaged, or proxy Product Owner creates the following risks:

1. The project may build the wrong thing.
2. The stakeholders may lack proper input or visibility into the project.
3. Sprints may lack clear Sprint Goals.
4. The team may end up working on low-priority items (from the stakeholders' point of view) because the Product Backlog is not properly groomed.
5. The accuracy of estimates in Sprint Planning may be adversely affected.
6. The team may need to commit to fewer stories each Sprint in order to account for ambiguity resulting from lack of Product Owner input.

This is not an exhaustive list, but it's representative of the common issues a Scrum team can face when missing a framework-mandated role. Not having a real Product Owner will almost always cause problems for the framework and the project.

Make the Costs Visible

The biggest mistake you can make with Scrum is to sweep problems under the rug. The lack of strong leadership from a Product Owner should not be discounted; it should be made visible to the entire organization.

While there is certainly political risk for doing so, an ethical Scrum Master should:

1. Remind the organization of the important of the role of Product Owner.
2. Continue enforcing the framework rules.
3. Don't "fill in" for the missing Product Owner.
4. Don't allow stakeholders or the development team to manage the Product Backlog.
5. Attribute reduced velocity or productivity as process problems to the missing Product Owner role when appropriate.
6. Treat schedule slippage as a process problem attributable to the missing Product Owner role.
7. Ensure the process is transparent, and the cost of the missing role is highly visible to stakeholders.
8. When sprints fail, or fail to satisfy the expectations of stakeholders during the Sprint Review, invite them to the Sprint Retrospective.
9. Make the lack of a Product Owner a recurring agenda item for each Sprint Review until the issue is resolved.

In other words, if the project takes twice as long to deliver half as much because senior management can't or won't place the right person in the Product Owner role—well, that's their decision to make, but it comes at a cost that they need to live with. Under no circumstances should a Scrum team take improper responsibility for management decisions that violate fundamental framework principles.

The team's responsibility is to sustainably deliver product in a professional and workman-like fashion. It is the Product Owner's responsibility to define and prioritize that product, and management's responsibility to identify and empower the Product Owner. In framework terms, it really is just that simple.

Answer 2

Unfortunately, this is a common problem. Sometimes companies "buy" Scrum not fully understanding what will be required from them.

I see these possible action points:

1. Try to educate current stakeholders. Organize a meeting and explain them one more time that PO is a vital role. Perhaps one of them will willingly accept the role. Potential issue - you may find yourself in the same situation once again.
2. Designate a product owner proxy from your own team. Potential issue - your assumptions might be incorrect and the whole product will solve other business problems.
3. Add a Business Analyst to your team. You will lose cross-functionality; hence, it might be not pure scrum. However, if a successful project is a top priority it may be a good idea.

Answer 3

As ihar.k points out, this is a common problem. This is especially true in organizations that have a more traditional "project manager" role where the project manager is not a developer yet still is assigned responsibilities that in agile belong to the development team, such as estimating and assigning tasks.

It sounds also as if the organization doesn't have someone to step up and be a full-time product owner. This isn't necessarily a problem; a product owner can be a team instead of a single person, so long as they can send at least one representative of that team to sprint meetings and meet amongst themselves at other times to discuss the product owner decisions that were made and should be made in the future.

The first step is, within the development team itself (meaning only those who actually develop the software, not people who do just planning) to make clear and carefully follow the split between the developer and product owner (PO) roles. Even if there is no proper PO at the moment, and the developer team has to do some of the PO's work, you can at least make it clear amongst yourselves when any particular decision is a PO decision or a development team decision, and try to ensure that PO decisions are not being made based on what the developers want for their own reasons, rather than what a non-developer PO would want due to demonstrated business value. (For example, someone selecting stories for an iteration should refuse to select stories that produce no externally visible change to the product but only internal changes, such as "refactoring," forcing the development team to roll such things into stories that do produce obvious business value.)

You will probably end up during meetings having developers take off their "development hat" and put on the "product owner hat" from time to time. At this point they should try to find someone on the product side to confirm their choices and make the best decision they can where this can't happen. If you can get any non-developers into the sprint meetings, they're right there to ask and assist with this, learn more about the product owner's role, and hopefully take that information out to others in the company who are interested in helping form the product.