Business : Le voyage du développeur au propriétaire du produit

Un malentendu courant est de savoir qui représente le propriétaire du produit, bien que cela semble évident; pourtant, certains développeurs le confondent. Le Product Owner représente le client et non l’équipe de développement.

Une fois qu’un développeur en transition vers le rôle PO m’a demandé « si le bon de commande ne représente pas l’équipe de développement, qui le fait? « , cela m’a montré un énorme malentendu par rapport aux Principes Agiles car tout le monde devrait travailler vers le même objectif. Nous devons tous nous concentrer sur la fourniture de logiciels de haute qualité pour résoudre les problèmes du monde réel. L’ère des silos doit se terminer!

Les gens d’affaires et les développeurs doivent travailler
ensemble quotidiennement tout au long du projet.

– Manifeste Agile

Les développeurs qui pensent que les propriétaires de produits les représentent ont tendance à se concentrer sur des sujets techniques au lieu de maximiser la valeur commerciale. Il devrait y avoir un équilibre, où le côté technique est en harmonie avec l’entreprise. Nous devons veiller à ne pas trop concevoir une solution plus complexe que ce dont nous avons besoin. La technologie est un moyen pour arriver à une fin.

Les décisions prises par les propriétaires de produits et les développeurs sont différentes. Le Product Owner doit fournir le quoi, et Pourquoi, tandis que l’équipe de développement décide Comment. Pour réussir la transition, le nouveau Product Owner doit respecter cette frontière et avoir confiance que l’équipe prendra la meilleure décision sur la façon de construire quelque chose. Parfois, le Product Owner doit défier l’équipe, principalement s’il y a un sentiment que la solution pourrait ne pas conduire à l’objectif souhaité.

Je mets au défi mon équipe si je pense que la solution technique n’est pas adaptée à ce que nous voulons réaliser. Je pense que les propriétaires de produits devraient pouvoir contester l’équipe de développement sur la solution technique.

– Maarten Dalmijn, Pourquoi les propriétaires de produits devraient contester les solutions techniques

Les décisions sont l’un des aspects les plus difficiles de cette transition. Le développeur qui devient Product Owner doit prendre du recul par rapport aux décisions techniques et laisser l’équipe le faire. Aussi, il est essentiel de faire confiance à l’équipe et d’éviter de les influencer sur les choix techniques.

Le Product Owner doit prendre de nombreuses décisions; nous voulons prendre des décisions importantes; c’est pourquoi nous devons nous concentrer sur cela, qui est:

• Pourquoi: pour quelle raison devons-nous résoudre ces problèmes? Quelle est la motivation derrière cela?
• Quoi: quel est le problème que nous voulons résoudre?
• Quand: à quel moment faut-il résoudre le problème?

«Si vous pouvez prendre une décision avec analyse, vous devez le faire. Mais il s’avère dans la vie que vos décisions les plus importantes sont toujours prises avec instinct et intuition, goût, cœur. » – Jeff Bezos

L’un des aspects essentiels d’un propriétaire de produit réussi est d’avoir une vue d’ensemble, de comprendre comment connecter les points et où aller. Cependant, l’équipe de développement a généralement une vision limitée, ce qui signifie que la vue d’ensemble n’est pas toujours disponible de leur point de vue.

Ne vous méprenez pas; l’équipe de développement travaille sur de petits morceaux d’un ensemble plus grand et ne connaît donc pas la situation dans son ensemble. C’est la nature de leur travail. D’un autre côté, la direction devient plus lumineuse une fois que le Product Owner fournit une vision du produit convaincante. Un excellent Product Owner s’assurera que l’équipe de développement comprend bien la situation dans son ensemble.

Maarten Dalmijn a écrit un article sur Qu’est-ce qu’une vision de produit?. Il définit la vision du produit comme:

« Une direction pour où votre produit devrait être dans le futur qui applique la concentration et aide à prendre des décisions sur la façon d’y arriver. » – Maarten Dalmijn

Au cours de ma transition, j’ai dû apprendre à créer la vision du produit, à avoir une vue d’ensemble. J’étais habitué à me concentrer de manière excessive sur les fonctionnalités que nous avons fournies, donc la transition a été complexe pour moi. Je devais m’adapter au rôle de Product Owner et fournir une mission à l’équipe plutôt que des fonctionnalités.

La façon dont un Product Owner réussi communique est différente de la plupart des développeurs. Pourquoi dis-je ça? Eh bien, j’étais développeur et une fois devenu Product Owner, j’ai appris que je devais changer cela. D’après mon expérience, la plupart des développeurs préfèrent généralement la communication écrite à la communication verbale, en tant que Product Owner, qui peut fonctionner parfois, mais pas toujours.

Le secret de la communication est: savoir communiquer droite morceau de information à la droite public au bon moment par la droite méthode.

Il y a un dicton « N’apportez de mauvaises nouvelles qu’en personne », une fois que j’ai demandé à un développeur en transition comment allait-il annoncer la mauvaise nouvelle à un intervenant, il a simplement répondu « J’écrirais un e-mail, c’est simple et rapide. «  Il ne pouvait pas comprendre les avantages de transmettre ce message en personne. Le premier avantage est de montrer que nous nous soucions des parties prenantes et que nous pouvons également clarifier tout doute immédiat.

Juste pour information, plus de 50% de la communication se fait avec la communication non verbale. Soyez prudent en vous concentrant sur la communication verbale. Nous ne pouvons obtenir les meilleurs résultats que personnellement, encore mieux devant un tableau blanc.

Lorsque vous prenez un marqueur et que vous vous dirigez vers le tableau blanc, la dynamique de la pièce change et les gens ont tendance à participer davantage. Le fait d’avoir des idées, les vôtres et celles de vos équipes, au tableau donne une pause à la conversation alors que l’équipe se concentre pour s’assurer que les idées communiquées sont exactes. Les membres de l’équipe sont plus enclins à signaler les lacunes lorsqu’ils les fixent en face.

– Kedron Rhodes, 3 façons dont un tableau blanc peut améliorer la communication et la participation

Les propriétaires de produits qui étaient des développeurs ont tendance à faire des hypothèses techniques au nom de l’équipe; c’est faux et dangereux. Les développeurs ne s’engagent pas dans les décisions qu’ils n’ont pas prises. Je suis tombé dans cet écueil au début de ma transition. Certaines questions auxquelles les propriétaires de produits ne peuvent pas répondre sans l’équipe de développement:

• Quand cela peut-il être livré?
• Est-ce complexe?
• Quelles sont les solutions possibles à ce problème?

Le Product Owner doit apporter ces questions à l’équipe; en tant que PO, nous devons nous assurer que l’équipe a une compréhension complète de nos objectifs, ce qui signifie qu’il n’y a aucun doute. L’équipe de développement est chargée de définir la solution, c’est pourquoi nous devons collaborer et porter le problème à l’équipe afin qu’ensemble nous puissions trouver les réponses.

Le voyage d’un développeur à un propriétaire de produit peut être très réussi une fois que nous utilisons tous les avantages disponibles et en apprenons davantage sur les différences entre les rôles. Les principaux aspects dont nous devons être sûrs sont:

• Le PO représente les clients; par conséquent, la priorité est de résoudre les problèmes des clients réels.
• Soyez audacieux dans la prise de décisions commerciales, tout en laissant les décisions techniques uniquement à l’équipe.
• Soyez propriétaire de la vision du produit, assurez-vous que la vue d’ensemble est claire et que vous savez comment relier les points.
• Ne répondez pas aux questions techniques sans l’équipe de développement.
• Assurez-vous d’adapter votre style de communication en fonction de votre public et du message que vous souhaitez transmettre.

Voulez-vous écrire pour Serious Scrum ou discuter sérieusement de Scrum?