The product owner – team gap

Product owner team gap

A fully functional, high-performing scrum team includes both a product owner, a scrum master and a development team. The product owner’s formal responsibilities are prioritization and funneling requests from the outside world into the product backlog, while the team and the scrum master grabs work from the backlog and turns it into potentially shippable increments.

However, this is not the full story. Many product owners struggles with the many responsibilities that comes with the role, and therefore – sometimes as a desperate measure to prioritize among their many business activities – delegate a lot of the responsibility to the team and to the scrum master. On the other hand, many teams expect all contacts with the outside world to occur through the product owner,  or that they do not need to worry about managing the product backlog (since that is the responsibility of the product owner).

When the product owner delegates too much to the team, it might leave the team feeling abandoned by the product owner. A good team might seize the opportunity to go ahead a prioritize the backlog themselves – which might work, but also might lead to suboptimal end results. A more challenged team might loose their agile practices altogether. After all, what point is there in having a demo, if nobody cares about the results?

Similarily, when the product owner is unable to fulfil the team’s expectations, the product owner might be frustrated by the teams inability to take the initiative. From the product owner’s point of view, it might seem that the team is waiting around to be spoon-fed ready-to-go-tasks.

I think of this as the product owner-team gap. That is, there is a gap between the decision level, where the product owner has the majority of the responsibility, and the operative level, where the teams technical expertise is required to refine and execute work.

This gap might seem superficial, because in no overview of Scrum there is such a gap. In reality, though, it almost always exists, at least at first.

One of the key ingredients in getting the entire scrum team to a higher level of performance, is to make sure that this gap is bridged. Either the product owner understands the importance of taking a step towards the operative level, and makes an effort not only to be present at refinement meetings, sprint planning meetings and so on, but also to truly understand the teams work environment and the teams needs and wants. Or, the team takes a step up to the decision level, and helps the product owner understand and prioritize the backlog. This means – among other things – that the team must make an effort to explain the contents of technical work on a level that the product owner can understand and relate to. The team must also explain why they need a product owner present in their day-to-day work.

For either of these solutions to work, it requires patience,  good understanding of agile values and preferrably the presence of an agile coach. Also, a key to success is interest in making it work. Without that, as usual, all approaches will fail.

 

Annonser

How will they solve it?

I’m sure you have all been there. You know, that discussion that does not really solve anything. Perhaps you took part in it yourself, discussing that problem that your organization is having. All of you in that room agreed that it is a big problem for you, for your entire team, for the entire organization. You talk about how wonderful it would be if this problem could go away, you analyze all the terrible situations that will occur if it does not. You leave the meeting with a sense of having reached some profound conclusion, some deeper understanding of what is wrong with your organization, and you wish that they, the people really responsible for fixing what is wrong, could receive the same epiphany.

Here’s an unpleasant truth: unless you act on your new-found knowledge, what you just did constituted waste, and it should be eliminated.

”Come on”, you say, ”we must be allowed to have discussions about our problems. What about our retrospectives? Surely we can have those?”

Yes. Of course. But here’s an easy tell-tale sign if your discussions consititute waste:

  • If you are talking about ”how we will solve the problem”, it is a valuable discussion.
  • If you are talking about ”how they will solve the problem”, it is probably waste.

The difference in only one word, but it it makes all the difference in the world.


Please also see this  video from Jeff on this topic.