Si j’ai appris une grande leçon dans ma vie de professionnelle, c’est grâce à l’agilité.
J’ai eu la chance de devenir Product Owner et de rencontrer des personnes très intéressantes qui m’ont fait comprendre que la manière dont j’avais toujours travaillé jusqu’à maintenant n’était pas nécessairement la seule façon possible de travailler.
En 10 ans, j’ai été chef de projet, chef de projet utilisateur, responsable d’application ou encore chef de produit. Peu importe le titre, j’ai géré des projets dans une structure hiérarchique en mode “command & control” où j’avais toutes les responsabilités mais aucune autonomie pour les exercer. Un contexte anxiogène et aliénant.
Il m’a fallu presque 10 ans pour comprendre que ce malaise d’aller bosser tous les matins, était dû au fait que je ne m’épanouis pas dans une telle structure. Et pas seulement moi d’ailleurs, beaucoup de mes collègues “agilisés” ou non ressentaient les mêmes doutes.
Avec la découverte de l’agile, j’ai aussi découvert une méthode de travail plus humaine, à l’écoute, bienveillante et efficace ! Certains parlent de slow business, “happiness at work”, pour moi, c’est un état d’esprit dans la lignée de l’agilité. L’objectif est d’établir un environnement de travail propice à l’épanouissement, le sien et celui de ses collaborateurs.
La promesse est belle, la mise en pratique souvent plus compliquée.
Cet état d’esprit s’incarne très bien dans les 4 accords toltèques et je souhaitais dans cet article expliquer comment je l’applique dans ma vie de Product Owner.
Les 4 accords toltèques dans le quotidien d’un Product Owner
Au quotidien, être Product Owner est un défi. Si vous lisez comme moi de nombreux articles sur le product management, la liste des qualités attendues chez un PO, le nombre de sujets sur lesquels il doit se former ou qu’il doit maîtriser est impressionnante. Dans cette complexité aussi bien intellectuelle que relationnelle, j’essaie d’appliquer les préceptes du chaman mexicain Miguel Ruiz. Ce dernier a publié en 1997 le livre intitulé The Four Agreements qui explique comment nous nous enfermons dans un système de croyances qui nous ait néfaste. Ces 4 accords donnent des pistes pour sortir de ce cercle vicieux et d’enrichir nos relations aux autres.
Que ta parole soit impeccable
Être Product Owner, c’est travailler à mi-chemin entre les parties prenantes et les développeurs. On entend 2 points de vues en permanence.
Il est primordial de respecter les 2 parties, par exemple :
- ne pas accabler les parties prenantes quand elles ne savent pas prioriser
- ne pas accabler l’équipe de développement quand on prend du retard
L’objectif n’est pas de trouver le coupable mais bien de comprendre d’où vient le problème et tenter de le résoudre.
En ce sens, dire du mal d’un collègue n’aide en rien (bien que la tentation puisse être forte parfois). Au contraire, vous avez tout à gagner à les respecter pour établir une relation de confiance autant avec les parties prenantes que les développeurs de votre équipe.
Ne prends rien personnellement
Régulièrement, en tant que Product Owner, j’ai eu des convictions : “telle fonctionnalité est plus prioritaire” ou “c’est comme ça que cette partie du produit devrait être”. Seulement, on a pas toujours le dernier mot. Et cela peut être frustrant.
Il est important de savoir que celui qui vous met en colère vit, de son côté, sa propre réalité. Qui vous dit qu’il n’a pas eu un très mauvais début de journée car ses enfants traînaient pour s’habiller et l’ont mis en retard. Alors il n’a pas envie de discuter là tout de suite ...
Son obstination à refuser votre point de vue n’a rien à voir avec qui vous êtes. Le savoir permet de dégonfler cette bulle d’énervement qui monte en vous. Je dis souvent : “Cela ne m’appartient pas”. Son énervement n’a rien à voir avec moi. Son énervement lui appartient.
Mettre un espace entre “ce que je suis” et la réaction de l’autre permet de réagir de façon factuelle à la discussion et ne pas s’embarquer dans des luttes d’égo. Je fais la distinction entre le message et la forme du message.
“Cela ne m’appartient pas” me permet de passer à autre chose, et continuer à faire mon travail sereinement.
Ne fais pas de supposition
Lors d’un atelier organisé par le Scrum Master, ce dernier propose de mettre en place un nouveau process. Dans mon enthousiasme à le tester, je me lance directement en sortant de l’atelier dans l’installation d’un nouveau board.
Sauf que je n’avais pas fini de le placer au mur que l’on me fait remarquer que l’emplacement n’est pas du tout adéquat et qu’il faudrait le mettre ailleurs… Petite crispation…
La faute que j’ai commise, c’est que j’ai supposé que cela conviendrait à tout le monde si j’installais le board à cet endroit. Mais je n’ai jamais posé la question.
En tant que Product Owner, quand on écrit des User Stories ou lorsque l’on accompagne les développeurs lors de la conception, il est indispensable d’expliciter TOUT.
Certes, un PO ne comprend pas toujours tous les points techniques, mais il est important qu’il pose les questions pour vérifier que tout le monde autour de la table a la même vision que lui concernant la finalité de cette User Story.
Cela évitera des déconvenues en fin de sprint quand on découvre en testant qu’il manque tout un pan fonctionnel.
Fais toujours de ton mieux
Fais toujours de ton mieux à l’instant présent, cela veut dire en fonction de tes capacités, de ta connaissance sur le produit, des utilisateurs, du marché, des concurrents... à cet instant précis.
En tant que Product Owner nous pouvons être tenté de faire le produit le plus beau, le plus performant. Quitte à voir trop grand au début et rater notre cible. Bref, pêcher par perfectionnisme.
Si vous êtes déjà coutumier de la méthode Lean startup, vous savez déjà qu’on ne construit pas un produit à succès du premier coup. Faire de son mieux ce sera donc construire, pas à pas, le meilleur produit en évitant de faire des suppositions, en testant nos hypothèses. En faisant avec ce que l’on sait, ce qu’on a pu prouvé par des tests utilisateurs.
C’est également ne pas sortir un produit en sachant qu’il contient des bugs bloquants.
Trouver la voie du milieu, celle qui vous permet de faire avancer votre produit mais qui ne vous coûte pas trop cher : réaliser un MVP (Minimal Valuable Product), par exemple.
Namaste.
