Reflection workshop on the role of PO

The role of PO brings a lot of questions in Scrum-based transformations. Indeed, it changes a lot more things in an organization than one might think. Combining these new responsibilities with the old ones can sometimes generate frustrations, fears and misunderstandings.

As part of a mission, I was asked to lead a PO training to explain what this role consisted of. However, in this context already sensitized to Scrum, I preferred to opt for a more participative approach, similar to This article. The idea being to limit debate sterile and generate the good conversations.

Here's how it happened.

Design

Context

To get this design started, let's first take some background.

1. A role already in place at the IT department

We can therefore consider that these people have a notion of what this role is, since it is the hat they wear today.

However, it is quite recurrent to give labels to people without taking the time to fully explain to them the contours of this new responsibility. In other words, it often happens that it is more than renaming what a real change.

In addition, due to the diversity of people, it is highly likely that everyone has their own own way of understanding his role. This obviously depends on the context of each, the needs and the structure of the team.

It may therefore be interesting to bring out elements directly from the participants. This will make visible the differences in interpretation and implementation in the field. For this, we can use a Consensus Workshop.

2. An ecosystem not consistent with the theory

The organizational structure does not leave with the initial recommendations of Scrum. It's not a problem in itself, but I don't know if people are aware of it.

It therefore seems important to me to recall where this mode of organization comes from and the interest of the proposed theoretical structure. Indeed, to reap all the benefits, Scrum requires a few prerequisites.

It is therefore essential to be aware of these elements in order to be able to exchange information in an informed manner.

3. Possible confusion

We can see here that we already use the same term to designate 2 different things. This can only fuel confusion and interpretations.

We will then seek to develop a common understanding to be able to distinguish the different concepts. I think it will therefore be necessary to lay the theoretical foundations that come with the OP. This will be a good opportunity to share a searchable reference on this subject: the scrum guide.

Here the important thing will be to tell a simple and coherent story to clarify gray areas.

4. A heterogeneous audience

For the sake of transversality and of shared understanding, people from the trade will also be invited. This is rather a good thing because the role of the PO could very well be on their side depending on the choices the organization makes. It is therefore necessary to take into account theheterogeneity of their knowledge but also value their contribution in conversation.

It will therefore be taken into account that the results of the workshop will include:

Due to the Power Point culture, which is particularly well established in the company, I will produce a summary document following the workshop for the management committee. The idea being not only to share the results of the workshop but also my observations, some directions as well as issues outstanding.

Structure

To define our animation structure, we will also take into account the following elements:

• Duration : 1h30
• Number of persons : 14 people + facilitators
• Format : Remote (Miro)

The provisional schedule is therefore as follows:

Thus, at the heart of the approach, we propose to create meaning around the subject of the PO by having the participants work on the material. It is therefore no longer a question of imposing a truth on them but of getting them to have a conversation allowing them to define what truth suits them to meet their challenges.

My role, however, will remain to ensure that overall consistency and of clarify misunderstandings.

Animation

To start the workshop, I welcome all the participants by sharing the link to the Miro support provided for this purpose. I also share my screen to facilitate the animation.

In the introduction, as usual, I recall the intentions of this collective moment and display the provisional agenda.

As you can see it is slightly more accurate than the design. It's a spontaneous choice on my part. Indeed, it can sometimes be useful to give a little more detail to the participants so that they can better identify themselves in the animation and in the time management of the workshop.

Part 1: Consensus Workshop

We then start part 1 by asking the participants directly about their vision of the PO role. For this, they will be divided into sub-groups to discuss their ideas.

I quickly create breakout rooms with random fill and show them where to drop their results. I can finally send them to the room where they will have a good ten minutes to interact and make their ideas visible. Of course, I will go to each room to see how the discussions are going.

My role here is not to correct or contribute my knowledge but rather to facilitate exchanges, of to question orbring new options to the current conversation.

The time being up, we all come back to the main room to debrief. Here is what the content of each subgroup looks like:

Each group comes in turn to share their ideas.

As the Consensus Workshop process dictates:

• We first gather the post-its that seem to belong to the same theme under the same column.

• Then, when all the ideas have been submitted, we work collectively to name these themes. This is one of the strong moments because these exchanges refine the collective understanding of the group on the subject studied. It happens then that groupings or separations of themes occur.

We arrive at the following result:

To close this part, I formulate a sentence aloud to answer the question, taking up the different themes. This seems to resonate within the group. Further proof that the Consensus Workshop is an extremely powerful tool for collective facilitation! 😉

Part 2: Theory

In this section, it's my turn to play. I then present a theoretical vision of the role (in my opinion) with the concern of constructing a simple and coherent story. Here is what I shared with them:

From Project Manager to Product Owner

To understand the role of the Product Owner, it is important to understand its context.

A rich set of responsibilities

In the Traditional approach, the Project Manager took charge of different activities:

A focused separation of responsibilities

In the Agile approach, especially in the Scrum Framework, these different activities have been distributed within well-defined areas of responsibility:

We can then understand why project managers often have the impression of having a overlapping responsibilities with Product Owners and/or Scrum Masters. In fact, it's simply because it is 🙂

The marked separation of these 2 responsibilities aims to provide more focus in each of these areas. Indeed, by dint of multiplying the hats, it becomes more difficult to do everything correctly.

Moreover, it often happens that the human part is neglected in favor of the “production” part. The creation of the Scrum Master is therefore a way of ensuring that this does not happen.

The Scrum Team

The Product Owner is a scope of responsibility mentioned in Scrum, one of the most used Agile frameworks. He combines with the Scrum Master and the DEV (realization) team within the Scrum-Team.​

Scrum is based on the triptych of the Scrum Team. Each part therefore has a clear and complementary objective.

For the PO, we have:

Maximize the value produced by the production team

– Objective of the OP

​Today, the Scrum Team triptych in the company looks more like this (see below): there is no dedicated Scrum Master, integrated into a team.​

It is rather a team of Scrum Masters / Facilitators who distribute the support of the different teams. The constraint being of course that there is less capacity to do than things to do! 😉

This can then create a blur in the activities of the Product Owner who can sometimes take actions initially dedicated to the Scrum Master / Facilitator.

Product Owner as interface

We can consider the Product Owner as the interface between the Need space and the Solution space

We then see here the Scrum team with the Realization team and the Scrum Master representing the space of the solution. On the other side, in the space of need are the business referents, THE users but also the managerial layer which may sometimes sponsor the product in question.

The Product Owner therefore acts here as theinterface between these 2 spaces by paying particular attention to the refinement of the need (hence its shift on this side). Indeed, the idea is to leave sufficient freedom to the Production team to propose the best solutions.

It is always the great difficulty to succeed in communicate a need rather than a solution !

During this time, the Product Owner can interact with his interlocutors to clarify the needs, clarify priorities and plan strategically the development of its product.

The activities of the Product Owner

Thus, the activities and responsibilities of the Product Owner, as defined in the Scrum Guide, can be summarized as:

We then find there:

Note: I also find that the term " Schedule is often more explicit than the term " To prioritize“. Indeed, on the one hand we have a notion of order, implying that no element will be at the same level as another. On the other hand, we have all seen work items with the same priority levels! 😛

Additional Notes

• The above items can be delegates but the primary responsibility remains with the PO.​

• A single PO, not a committee. It can however be the representative of the needs of different stakeholders.

• The OP must have the mandate to make decisions, which must be respected by the organization.

• PB cannot be amended that after seeing had theagreement of the PO.

• The Scrum guide does not specify the activities of the PO in upstream of the implementation phase, despite the fact that they do exist.

Questions answers

The question and answer session will not be very long given the time left for the workshop.

However, the confrontation of the theory with the field vision seems to have clarified a certain number of gray areas on the subject. The participants leave the workshop in a rather positive mood and seem satisfied with what has been collectively produced.

I take this opportunity to specify the next steps to give visibility. Indeed, a session will be organized with the management committee to study these results and answer outstanding questions. Then a consolidation workshop all together will finalize the structure of the PO role for its first version.

Synthesis

As mentioned at the beginning of the article, I worked on a summary support for the management committee. To be honest, I've never been very good at this kind of exercise, but at least the elements could be laid down.

Here are a few things:

Product Owner Activities

Answer co-constructed by the participants in 1h30:

Comparison of the 2 visions

I have tried here to bring together the ideas that converged in the 2 visions of the PO role. Here is the result I shared:

Theme: Managing a team

To better understand what lies behind, here are the activities that were grouped together:

This led me to ask the following questions:

Guidance

Below are the guidelines shared for this topic:

These elements are not intended to be the "truth" but it helps to contribute to the reflection with a well-argued point of view.

General questions

Finally, to conclude, I invite the management committee to reflect more specifically on the following questions:

Ratings :

• Indeed, it is important to take into account the ecosystem around the PO to clearly define its scope of responsibility (in the sense of accountability)

• There is also the size internal external to be taken into account in the reflections because according to the status, the rights and duties may differ.

Conclusion

This article was an opportunity to describe an alternative approach to the usual training approach. Indeed, to avoid debates between experts and useless conflicts, it is an approach which seems to me to favor collective work by co-construction of meaning.

Our role in this kind of workshop is therefore no longer to bring the truth but to facilitate the appropriation of the subject by the participants. This seems to lead to a result more adapted to the context at a time t because more engaging and requesting more curiosity.

However, the starting assumption isacceptance of an imperfect result, refined in successive iterations thereafter: did you say Agile? 🙂

Hoping that this article has been able to open up some perspectives for you, do not hesitate to test this in your contexts and share your learnings with me! 🙂