Le Product Owner : « Le métier au cœur de la Technique ! »

Scrum a reçu les faveurs de nombre de sociétés – souvent par conviction, parfois par mimétisme. L’agilité, cependant, n’est pas sujet facile, et sa mise en œuvre ne requiert pas moins de discipline et de maîtrise que pour la méthode traditionnelle.

Avant toute chose, résumons Scrum simplement. Scrum est un framework de gestion de projets, d’inspiration « amélioration continue ». Par ailleurs, et c’est notamment ce qui l’a rendu populaire dans les cercles techniques, Scrum peut être aisément conjugué avec des pratiques d’excellence, propres au développement logiciel, comme eXtreme Programming. Dans cet article, nous allons apporter un éclairage sur le rôle du Product Owner pour Scrum, à travers un retour d’expérience depuis les tranchées.
François est créateur d’entreprise. Il souhaite proposer un service innovant aux entreprises, qui s’appuiera sur une solution logicielle spécifique. Problème : comment construire ce logiciel ? Amis lecteurs, mettez-vous à sa place : êtes vous prêts à puiser plusieurs dizaines de milliers d’euros de vos économies, pour les confier à un tiers ? Savez-vous qu’un projet informatique sur deux échoue ? Que les fonctionnalités réellement utilisées d’un logiciel ne représentent statistiquement que 20% des fonctionnalités développées ? Que le budget annoncé par les fournisseurs consultés est très souvent dépassé ?
Celui qui accepte la responsabilité du pilotage de la production logicielle, et garantit sa qualité et son adéquation aux besoins (non encore identifiés) est, dans Scrum, appelé Product Owner. François, riche de plusieurs années d’expérience dans le secteur informatique, assume ce rôle difficile.

« Au début, la sérénité n’est pas vraiment le sentiment qui prédomine ! », témoigne-t-il. « Les enjeux sont élevés, et les risques nombreux. Nous n’avons aucun droit à l’erreur. ».

Maîtrise des risques et création de valeur s’imposent de fait au Product Owner comme deux préoccupations à constamment garder à l’esprit.
Le projet, avant ses itérations officielles, démarre par une phase de cadrage. Ateliers avec Innovation Games pour mieux appréhender les besoins, exercices de définition et de sizing des User Stories, construction d’un prototype fonctionnel levant le maximum d’incertitudes techniques.

« A l’issue de cette première étape, j’étais nettement plus confiant pour la suite », se souvient François. « Nous avions démontré la faisabilité technique, travaillé sur chaque risque identifié, et commencé à cerner la solution de manière plus précise. ».

Commence alors la seconde phase, la production proprement dite, qui s’étendra sur sept sprints de deux semaines. Le premier sprint – toujours particulier dans Scrum – livre un produit non fonctionnel, que le Product Owner accepte pourtant volontiers :

« Pour ce premier sprint, nous avons élaboré toutes les maquettes significatives des écrans du produit. Les boutons sont bien là, mais ne fonctionnent pas encore. A ce stade, l’essentiel est de nous projeter vers la cible, de visualiser la valeur potentielle.».

Et les sprints s’enchaînent, les fonctionnalités fleurissent. L’écriture des User Stories, néanmoins, n’est pas toujours facile.

« Il a quand même fallu un peu de temps avant que nous trouvions un terrain d’entente, avec les développeurs, sur le niveau de détail des critères d’acceptation des stories », sourit François.

Mais une communication régulière avec l’équipe, quasi-quotidienne, permet de lever efficacement tous les doutes fonctionnels et d’éviter blocages ou dérives.
Aujourd’hui, François est satisfait de son logiciel, produit dans le respect du budget initial et des contraintes de Time-to-Market. Lorsqu’on lui demande quels facteurs ont été clés pour la réussite du projet, il cite notamment la transparence et le feedback.

« J’étais sur site quasiment tous les jours, dans le bureau des développeurs. Je pouvais répondre à leurs questions en temps réel, je mesurais leurs progrès et leurs difficultés tout aussi facilement. Voir le produit grandir sous mes yeux était non seulement satisfaisant, mais aussi nécessaire : j’ai pu ajuster les priorités de mon backlog au fil de l’eau. ».

Pour conclure, comment François a-t-il vécu cette expérience ?

« Scrum est loin d’être facile, ou tout du moins, pas plus facile qu’une quelconque autre méthodologie. Si je devais caractériser le rôle du Product Owner, je dirais que c’est un rôle central mais surtout engageant. Ceci dans la mesure où il faut être réactif, être capable de prendre et parfois d’imposer des décisions face à un parterre de techniciens dont les aspirations ne sont pas nécessairement les mêmes. Néanmoins, une formation « Product Owner », couplée à une écoute partagée et une présence soutenue, ont permis de surmonter tous les obstacles avec succès ».

Article paru dans l’édition d’avril du magazine Programmez !
Auteurs François Bouloré, Directeur associé TWIN CORP, Product Owner (certifié) et Yann Perio, Consultant technique ZENIKA, Scrum Master (certifié)