The Product Owner as seen by developers

Introduction

Agility is often discussed in a very positive light. It is not uncommon, however, to hear developers complaining among themselves about its implementation, which, if properly applied, can be a real strength for a development team. The product owner, with his central role, is often the source of frustration for the development team. Through interviews with developers, we will highlight the reasons for this divergence of views on Agile and the role of the product owner.

Firstly, the role of the Product Owner will be outlined to better situate him within the Agile team. We will then look at the opinion of developers on the implementation of Agility and the role that the Product Owner has in this organization. Next, we’ll look at the mistakes to avoid and the signs that indicate a poor relationship between the product and the Product Owner. Finally, this article will briefly present the positive aspects of the Product Owner’s role in a development team that the developers interviewed wanted to highlight.

The aim of this article is twofold:

• To make young Product Owners aware of these mistakes and give them the keys to avoid making them.
• To enable a Product Owner already working with developers to better understand the feelings of some of them and to initiate a conversation with their team to see whether or not these feelings are shared to improve.

1.      The role of the Product Owner

Within a Scrum team, the Product Owner is responsible for gathering requirements from the business for which the product is being developed. He formalizes these needs and prioritizes them in the Product Backlog to supply the development team with tasks to be carried out during the sprints.

The Product Owner also has other tasks, including leading certain ceremonies such as Sprint Planning. He is also the bearer of the product vision.

The Product Owner has therefore a key role when it comes to giving direction to the product. As a result, he or she will be in regular contact with the development team.

2.     Agility according to developers

2.1.  The many facets of Agile

Many people reduce Agility to the Scrum method, but other methods exist with different modes of application:

“Agility should be seen as a way of looking at how a product is managed and organized”.
G.E. – Developer, 8 years experience

For example, the famous sprint doesn’t exist with the Kanban method[i], so you need to choose a method that’s adapted to the profile of each development team and the product being developed.

“I don’t think the Agile methodology is a methodology, but rather a way of thinking about how to lead and organize a product.
G.E. – Developer, 8 years experience

2.2.  Adapting the framework to suit the development team

Every team is different. A team of seasoned developers will not necessarily have the same organizational needs as a team with mixed or completely junior experience[ii]. The application of an agile method should be done naturally in collaboration with the development team. If this is not the case, some developers see this forced application as a counter-productive means of monitoring. In particular, some developers report an excessive reliance on justifying “progress” through meetings that give rise to exchanges with little added value for them, resulting in a loss of productivity.

“Agility has to grow from the bottom up, not be parachuted in from above”. A.S. – Developer, 4 years experience

The developers interviewed all seemed hostile to the forced introduction of a common sprint duration for all the teams on a platform. In particular, to carry out sprint reviews on the same day for everyone. Although practical from an organizational point of view, each team often works on very different products and this day is perceived by some as a waste of time. 

In reality, it’s difficult to grow Agile from the bottom up without hierarchical support. If the developers don’t seem to understand the point of a ceremony, it can be useful to involve the Scrum Master. He can explain the reasons for a particular ceremony.

2.3.  Agile by developers, for developers?

According to some of the developers interviewed, one of the reasons why the application of Agile can cause problems in certain teams is the lack of knowledge of development on the part of the people who lead and implement this framework.

In the testimonials received, the difference between a Scrum Master or Product Owner who has been a developer (and with an IT background) and one who hasn’t is obvious work seems to be much more valued and respected by the former than by the latter. Time constraints, explanations, and support also seem to be much better with a developer’s experience.

“A technical Product Owner is less skeptical, but also more demanding, and in my opinion pulls the product upwards.
A.S. – Developer, 4 years experience

Despite everything, even without any development experience, it is possible to be a good asset in an Agile team[iii]. It’s advisable to be curious. The Product Owner should not hesitate to ask for details of how the product works technically. There are many resources available online to help a consultant understand the logic behind the code. This knowledge can make all the difference when it comes to making decisions about a product under development.

“The Product Owner shouldn’t be afraid to get his hands dirty when it’s urgent. Make an SQL query, lend a hand during testing”.
L.M. – Developer, 2 years experience

3.      Mistakes to avoid according to developers

3.1. Mistakes to avoid according to developers

If, as a Product Owner, you find it difficult to break the ice with the development team, you may be making one of the mistakes below.

a.       Product vision :

• Writing incomplete User Stories. In a User Story, developers cannot be content with a screen capture of a mock-up of a page to be developed. A good Product Owner must make sure that they describe how they want the page to work and give details of the rules that allow the page to be structured.
• Lack of interest in the product. To maximize the value of a product, it is preferable to have a real interest in it.
• Little interaction with developers to improve the product. Developers are often good sources of suggestions for improving the product because they see it from another angle and this gives a broader view of the product’s possibilities. They need to be given time for technical tasks. In the long term, this will ensure that the product remains easily upgradeable. These tasks can include refactoring code, updating libraries or environments, etc.
• Inability to “get your hands dirty”, for testing, executing a SQL query, or analyzing an API response. It’s in the Product Owner’s interest to be able (or at least curious) to delve into the product to get to grips with it and analyze/anticipate any bugs.
• Not knowing the advantages and disadvantages of your product. When it comes to deciding on the product’s direction, the Product Owner must be clear about the strengths and weaknesses of his product. He will then try to remedy them or prevent them from going in a direction that would accentuate their weaknesses.
• Not thinking about the consequences of a given requirement on the product in the medium term. How functionality B can impact functionality A that has already been developed, rendering the latter obsolete.

b.       Link with development team :

• Don’t ask developers for their expertise when breaking down User Stories into tasks. At the end of the day, a User Story is intended for a developer, so it is important to rely on them for the breakdown.
• Not communicating a clear expression of need, particularly in situations where the developer has to develop prototypes of a product and there is no designer. An unclear statement of requirements is bound to hurt the team’s efficiency.
• Not giving clear priority to tickets. The developer won’t necessarily have the time to have a clear vision of the priorities if they aren’t indicated in the User Stories, so it’s important to indicate these priorities in the backlog.
• Not trusting developers’ estimates. The development teams are responsible for making estimates using different methods (poker planning, T-shirt size, etc.). When the estimate is made, the team agrees. As a Product Owner, questioning this estimate would not send a good signal to the development team. If the estimates seem inappropriate, it’s better to ask questions to understand why, rather than rejecting them.
• Ask the development team too much about the progress of developments. It’s better to use the tools already in place to monitor the processing of User Stories (Jira, Trello, etc.).
• Don’t protect developers from an anxiety-inducing environment. To develop reliably and efficiently, developers should be protected from any pressure that could result in work being done too quickly and unreliably.

c.       Link with other teams :

• Let people (developers or not) from outside the Agile team estimate instead of the developers on the development team. It is very difficult to estimate the complexity and size of a User Story without knowing how the code is constructed, so the developers who carry out the estimation must be familiar with the structure of the product.
• Let members of the company “bypass” the backlog entry and prioritization process. It may be difficult to refuse to allow the CEO of your company to make “express” requests to developers. However, it is important to make him aware that “express” requests do not exist. Each function developed goes through a cycle of verification and validation by the developers. To respect the workload, depending on the method chosen, the Product Owner must be as far as possible the only point of entry and prioritization.
• There is too little direct interaction with the business to pass on positive or negative feedback to the developers. This feedback will enable them to situate themselves in terms of what is expected and the quality of their deliveries.
• Preventing meetings between developers and the business. Some development teams are far removed from the business. As a result, developers cannot present their work to future users. This often reduces the developers’ commitment to the success of the product.

4.      The positive aspects of a Product Owner for a development team

The developers interviewed nevertheless stressed the importance of a Product Owner in a project. They were keen to share the points that make the Product Owner a major asset in the development of a product.

• The Product Owner is the developer’s best ally. His presence enables developers to develop new features based on precise instructions. The Product Owner will be able to answer developers’ questions or know where to find the answers.
• The Product Owner also acts as a “shield” in the face of business requests, which can sometimes lack structure. This allows developers to concentrate fully on their tasks in as stable an environment as possible.
• The Product Owner is a source of motivation for developers, especially if the he loves his product. He or she is the one with the vision, and discussions with the Product Owner will help developers find their place in the development team and take
  ownership of the product.

The role of the Product Owner is key in the development of a product. It is beneficial to seek the best possible relationship with the development team. Scrum, for example, does not recognize a hierarchy between the Product Owner and the development team. They form a single team with the common goal of the success of their product.

Depending on the product being developed and the development team, the role of the Product Owner can sometimes seem complicated. Although the developers interviewed seem to prefer a technical Product Owner, they feel that it is entirely possible to be good in this role without being technical. The Product Owner must be able to show curiosity about how his product works behind the scenes.

If the relationship between the Product Owner and the development team doesn’t seem to be working, this article can be a good basis for analyzing and identifying the blocking points. The aim is to initiate a process of reflection and discussion with the teams to implement actions for improvement.

At HeadMind Partners, we’re keen to have consultants working hand in hand with developers for our customers. With this in mind, we offer training and certification to our consultants to prepare them for the role of Product Owner.

The article was written by Mehdi Abdellaoui, Associate Consultant HeadMind Partners, a member of the Agility Lab.

Sources

This article is based on discussions with five developers working in different fields (retail, government, transport). Their professional experience ranges from 2 to 8 years.

[i] Différences entre Scrum, Kanban et Scrumban (anglais) : https://medium.com/agileinsider/comparison-of-scrum-vs-scrumban-vs-kanban-1d1d2b9a9fd5

[ii] Scrum, Kanban, Scrumban : quelle méthode Agile choisir ? :  https://www.blogdumoderateur.com/scrum-kanban-scrumban-methode/

[iii] Comment devenir Product Owner : https://www.leproductowner.com/carriere/comment-devenir-product-owner