No Part-Time Product Owner

Let me tell you about my experience working without a true product owner. At my company, we all heard that implementing some of the Scrum practices didn’t mean that we were implementing Scrum. We also learned that the only way to win stakeholders’ approval was to run a few sprints and let the product speak for itself.That’s all well and good, but be careful. In fact, I think your team should ask itself what it will be able to do in those few sprints if the stakeholders are not convinced at all about Scrum. Of course, you can start with a training session for businesspeople who are new to the Scrum framework. This is exactly what we did, in the hope of guaranteeing a common background to build upon. The problem is that after the initial training sessions, you either win or lose the customer. And if you lose the customer, what you get is something like, “OK, that’s great! Feel free to do that Scrum thing in the IT department, and deploy new features every two weeks.”This doesn’t feel like your business manager considers herself really involved in the process! Actually, it feels like there’s a lack of understanding the basics of what we’re talking about. But that’s just it — it’s a seismic change in mindset that occurs over time. In our case, this perception had not been pronounced explicitly in this flavor, but the meaning of all our talking and compromises sounded very much like it.

Wanted: Full-time product owner

But if we wanted to start a few iterations, we needed a Scrum Team, which is made up of a development team, a ScrumMaster, and a product owner. For the first few sprints, it was important to ensure that the company would put in place everything that was needed for the Scrum framework. It was a matter of individuals, time, and trust. The IT department could provide the development team and the ScrumMaster, but we needed a product owner who was accountable and whom the business managers trusted.

The business managers of the impacted area were new to Agile, so we invested time in making sure that they understood the crucial role of the product owner (PO), and that having a PO was not optional. To secure such a commitment, we made clear that what the company needed was one person dedicated full-time to this activity. This is what we advocated but couldn’t attain. We decided to give it a try anyway, but things could have gone better.

Challenges

Stakeholders came from several business areas, with competing priorities, skill sets, and mindsets. Several key users worked with us, but they struggled with the following tasks and responsibilities:

• Writing requirements and acceptance tests
• Assigning priorities
• Executing acceptance tests and reporting results and defects
• Meeting with the development team for analysis and backlog refinement
• Being available upon request

A PO could have done or facilitated the listed activities. Instead, we had the following two realities work against us:

These challenges produced the following results:

1. The development team was often either held up, waiting for requirements, or developing with raw requirements that were constantly changing in scope and meaning during the sprint.
2. The key users, feeling the burden of the PO role, perceived their new duty as a loss of time or as a job that someone else should do (maybe someone in the development team).
3. The gradual rise in misunderstandings spurred rude behavior and resentment, which was detrimental to team morale and performance.
4. Discussions were not about the scope and the product but about roles and responsibilities.
5. Some managers were not committed to helping the designated key users and did not allocate time for the required activities. Soon the managers looked for a scapegoat for the product–expectations mismatch.
6. Even the best results were not considered worth the effort, from the business side.

Setting requirements for the right PO

Given the situation, we decided to force the project interruption, and we explained the following to the stakeholders:

We then presented a precise definition of what we needed for the PO to be effective. Our explanation underlined the following points:

• The PO is not necessarily a business analyst with full domain knowledge. At least not at the beginning.
• The PO is a person who will be responsible for a product and who will be empowered by the company to make decisions that affect it.
• To write and refine the backlog items, the PO collaborates with analysts and key users.
• People in the company must answer the PO’s questions and provide information, dedicating as much time as possible to this activity. This is not optional.
• Business users, managers, and stakeholders must communicate with each other and with the PO in a clear, open, and transparent way.
• To enable effective decision making about priorities, the above points are necessary. These decisions are the sole responsibility of the PO.
• To refine and revise the backlog items, the PO, together with the rest of the Scrum Team, continuously analyzes the items.

We eventually appointed a PO, and our stakeholders planned a period of engagement with him before starting the project. They shared basic knowledge about their needs and learned to work together with him on business-as-usual situations. Then, the project was able to start.

In short, we were building trust — the main ingredient that had been missing.