Imaginez que vous êtes le Product Owner d’une application de Sudoku : vous seriez probablement capable de décrire les règles du jeu à votre équipe de développement et de lui fournir comme condition de succès, une grille résolue à partir d’une grille de départ valide. Mais il serait plus difficile de spécifier une grille de départ sans la référence d’une grille résolue. Pour y parvenir, vous auriez probablement recours à plusieurs expériences pour découvrir des grilles de départ valides. Et c’est sans compter la conception de grilles avec des difficultés multiples : comment savoir si une grille sera difficile à résoudre si vous ne connaissez pas la solution et les étapes requises pour y arriver?
C’est un peu comme cela que je me sens dans mon nouveau rôle de Product Owner…
Je suis nouvellement le Product Owner d’un produit interactif dont la mission est de rendre plus pertinent l’enseignement en ligne des approches Lean. J’ai une grande expérience dans l’enseignement de ces approches et j’ai la chance de travailler avec Christian Bélisle, un programmeur d’expérience qui possède des connaissances dans le développement de jeux vidéo.
J’ai abordé mon rôle de Product Owner de la façon habituelle : en faisant mes demandes de développement via la rédaction d’un carnet de produit. Cependant, je me suis rapidement aperçu que même si la création de matériel pédagogique est facile pour moi, et même si Christian est en mesure de programmer les exercices Lean, il est difficile de connaître les configurations de départs dysfonctionnels sans faire des expériences.
Nous avons donc commencé un genre de partie de ping-pong : je lui décris les paramètres de mes expériences et il les programme. Mais c’est assez inefficace, car :
- Christian attend après moi lorsque je réfléchis aux paramètres des expériences.
- Sans les résultats des expériences, j’ai de la difficulté à poursuivre la rédaction du matériel pédagogique.
- Nous ne savons pas combien de tentatives seront requises pour trouver des paramètres satisfaisants.
Puisque je suis un ancien programmeur Java, j’ai maintenant envie de programmer mes expériences de mon côté afin de briser notre dynamique d’échange inefficace. Et cela m’ennuie, parce que je suis persuadé que normalement, un Product Owner ne devrait pas programmer.
Pourquoi est-ce une mauvaise idée pour un Product Owner de programmer?
Sans que cela soit une règle absolue, on préfère généralement les Products Owners ayant un bagage d’affaires plutôt que technique, parce que :
- Ils comprennent la valeur du produit à construire, ainsi que les besoins des clients/utilisateurs.
- Ils incarnent la réalité des utilisateurs.
- Ils ont l’information et l’autorité pour prendre des décisions de manière plus autonome.
- Ils ont un réseau de contacts pour trouver l’information manquante, confirmer leurs hypothèses et présenter les résultats.
Nous pouvons donc déduire qu’un candidat qui possède des connaissances sur le développement de produit et le marketing, ainsi qu’une compréhension de la clientèle et de la concurrence, aurait tout ce qu’il faut pour bien faire son travail.
“In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out.”
L’équipe s’attend donc à ce que le client exprime un besoin d’affaires qu’il faut résoudre et qu’il ne participe pas trop aux choix techniques, sauf lorsque ceux-ci ont une incidence sur le succès d’un produit.
Pire, une expertise dans le domaine technique pourrait devenir un dysfonctionnement au sein d’une équipe Scrum :
“It could be disastrous if they had worked as a programmer 15 years ago and pretended that their understanding of technical tradeoffs remained perfectly relevant today. I’ve worked with product owners who had stopped programming 15 years earlier and couldn’t understand why something that was easy to do on a Green Screen application took longer to do with Enterprise Java. This led in some cases to fights over cost estimates. It might help to know what’s feasible, but if they work with programmers that they can trust, then that becomes less of an issue.”
Billet No, a Product Owner doesn’t need programming skill de J.B. Rainsberger
Alors que puis-je faire ?
Voici les quelques options qui me viennent à l’esprit pour améliorer la dynamique entre Christian et moi :
- Programmer : Je suis chanceux, je sais programmer, au moins en Java. Et je ne suis pas le seul, de nombreux Product Owners sont d’excellents programmeurs Excel ou Access. Tant que cette programmation sert à spécifier le besoin plutôt qu’à programmer la solution logicielle, cela respecte l’esprit du rôle du Product Owner. Christian pourrait même apprécier le fait de recevoir les spécifications sous la forme de tests unitaires exécutables, et pas seulement sous forme textuelle.
- Rédiger des tests d’acceptation automatisés: Avec des plateformes comme SpecsFlow, Cucumber ou Selenium, il serait possible pour moi de rédiger les paramètres de mes expériences et de les exécuter directement sur le code de Christian. Cela réduirait les coûts de programmation, car je pourrais tester le moteur logique de Christian sans lui demander de mettre à jour l’interface de la solution finale. En plus, ces tests serviraient de spécifications pour Christian, et cela réduirait probablement les cycles de rétroaction entre nous.
- Utiliser une console : Les tests d’acceptation automatisés peuvent être intimidants pour un Product Owner moins technique. Si Christian me développait une console pour interagir avec son code, sans utiliser l’interface de la solution finale, alors je pourrais conduire mes tests de manière indépendante et je réduirais l’effort de développement pour Christian. Par contre, je devrais continuer à spécifier de façon textuelle.
Et VOUS, que me recommanderiez-vous?
Vous avez peut-être vécu des situations similaires comme développeur ou comme Product Owner. Comment avez-vous fait face à la situation?
Lectures complémentaires
- http://blog.jbrains.ca/permalink/no-a-product-owner-doesnt-need-programming-skill#
- https://www.scrumallianorg/agile-resources/7-skills-you-need-to-be-a-great-product-owner
- https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner
- https://www.romanpichler.com/blog/product-owners-and-technical-skills/
- http://agilemodeling.com/essays/businessAnalysts.htm
