Product Owner Trainer

A ScrumMaster training a Product Owner . . .

… organizations moving to Scrum find that the transition can be difficult. It can be especially hard for people other than developers – the developers still develop, but other roles face significant upheavals in the nature of their responsibilities.

The Product Owner should be a powerful role. The Product Owner should set the strategic direction for teams and thus give the entire organization a competitive advantage over competitors. However, it seems as though the vast majority of Scrum teams are tactical rather than strategic. They get the tactical benefits through an effective Development Team, but they do not have good product ownership.

✥ ✥ ✥

Some Product Owners, especially new ones, do not know what they are supposed to do.

Scrum is a different model than many people are used to. As such, people need training to learn their new roles. Unfortunately, while it is obvious that developers and ScrumMasters need training, training for the Product Owner is often neglected. However, the Product Owner is a crucial role in Scrum, and must be done right.

One way to learn a new role is to grow together with others in the same role. Developers and ScrumMasters might trade notes with their counterparts in other teams. However, organizations have few Product Owners; often only one. So there is no opportunity to learn from others.

An old-school manager may find him/herself in the unfamiliar role of a Product Owner. Trying to act in the old manner just won’t work, and in fact may well be counterproductive.

People are almost always committed to the success of the enterprise. However, if they don’t know what to do, they might do things that are hurt more than they help.

Sometimes a Product Owner just doesn't really know what he/she wants, or can't express it concretely. “A manager who doesn't know how to describe what he wants will want what he can describe.”

Some symptoms of an ineffective Product Owner (for that matter, they are danger signs) are:

• • The Product Owner does not create or manage the Product Backlog

  • The Product Owner does not put the Product Backlog in delivery order

  • The Product Owner is not actively engaged in the team, and isn't around when needed by the Development Team.

In order to make progress, the development team may decide to use a Development Team member fill the Product Owner role. That is a viable temporary solution. Shadowing an ineffective Product Owner with someone who takes on most of the work of product ownership hides, perpetuates and reinforces the dysfunction.

Therefore:

The ScrumMaster asks the Product Owner to give the team the things the Product Owner should already be creating (or doing). In this way the Product Owner both produces the required artifacts (or assistance), and learns how to do their job better.

The whole idea of this pattern is that the ScrumMaster helps Product Owners succeed by gently teaching them. In particular, the Product Owner should learn to (and how to) take ownership of the product under development.

A key to success is not to tell the Product Owner how to do their job, but instead to frame the training as requests for help. The Product Owner will be much happier to respond, and will figure out quickly that it is part of their job. People are always happy to help.

Note that requests for help must be specific. Vague requests will not help, and may even be counterproductive. After all, the whole problem is often that the Product Owner doesn't know how to help.

Specific requests for help are often more effective if the ScrumMaster then works with the Product Owner to jointly solve the stated problem.

Note that the Product Owner is a representative of the client side, while the ScrumMaster is a representative of the development side. Thus there is natural tension between the two. This means that the ScrumMaster must be aware of the different perspectives and allegiances, and navigate carefully through the company politics.

A similar issue is that the Product Owner may have come from upper management, and is still very aware of status. If the ScrumMaster is perceived by the Product Owner as having lower status, this will greatly impede effective training. Therefore, the ScrumMaster should have sufficient status to gain the respect of the Product Owner. However, note that the ScrumMaster must at the same time be viewed as a peer by the development team. This is a potentially difficult tension for which we have no really good answers. Note that perception of status is one reason for the ScrumMaster to avoid taking on development tasks — the Product Owner will then view the ScrumMaster as “just another developer,” and not listen to him/her.

The Product Owner's perception is another compelling reason to avoid doing the Product Owner's work for them. If the Product Owner believes that the team is doing their work, it can be taken as a threat. The Product Owner can believe that their job is threatened; that they are not needed. A common reaction to such a threat is to try to make oneself indispensable, usually by withholding information from others. This attacks the very heart of Scrum.

Keeping these in mind, let us explore a few simple examples:

• • Suppose the Product Owner does not order the Product Backlog. The ScrumMaster could simply ask the Product Owner to order it, but a better approach would be to provide subtle guidance on how the Product Owner should go about putting PBIs in order. The ScrumMaster might ask a question like this: “We will be planning our next Sprint in the next few days, and the development team is wondering what we should work on next. It appears that items A and B are both important, but we don't know which is most important. You have insight into the company's vision, business model, and finances. You also have a good perspective on user needs and desires. Based on these, can you figure out which we should work on now?” (This approach has overtones of flattery, but it's not the purpose. Instead, it shows the Product Owner how and why they are valuable.)

  • If the Product Owner is only a reluctant passive attendee at Sprint Planning, try something like this: “At our last Sprint Planning, we uncovered some technical challenges that forced us to make tradeoffs and compromises. We couldn't do it well because of our limited knowledge of the business priorities. At our next Sprint Planning, can you help us make these decisions?”

  • If there is an impediment the Product Owner should take care of: “In yesterday's stand-up meeting, we learned that there are some problems with the server we use for building and regression testing. This morning it was confirmed as a major impediment. Let's go visit the IT department — you can use your clout to make the issue highest priority for them, and I will explain the technical details of what is going on.” The ScrumMaster might give an additional comment: “I know how you like to be on top of things. We would love to have you attend our daily stand-up meetings. You will get timely information, and we will get quick response on impediments like this one.”

The teacher-pupil relationship must be temporary. The ScrumMaster's goal should always be to stop being the Product Owner trainer as soon as possible.

✥ ✥ ✥

If done well, the end result is that the Product Owner is more capable of meeting the needs of the Scrum team. And the team gets what it needs. But the more important result is that Scrum is expanded from just tactical within the development team to a more strategic role. Thus it can help change the culture of the entire organization.

Some Product Owners might stubbornly refuse to get the message. In these rare cases, extreme measures such as frying the Product Owner might be tried, though it may not be possible. Or you might force the issue by making outrageous claims or demands that make the problem obvious to all.