Maximiser la valeur

Délivrer le produit

Comme indiqué dans l’introduction et dans le chapitre De la stratégie au plan opérationnel à la section La valeur du produit, le Product Owner cherche à maximiser la valeur du produit, et ce n’est que lorsqu’il délivre le produit que cette valeur peut être réellement mesurée. Tant que le produit n’est pas mis à disposition des utilisateurs pour lesquels il est conçu, sa valeur réelle est inconnue et peut être en dessous des prévisions ou des espérances.

La valeur peut être nulle lorsqu’un projet mené avec un cycle séquentiel est stoppé en cours de développement, parce que le marché a évolué ou que la dérive par rapport à la planification (coût, délai ou qualité) est trop importante. Le commanditaire du projet ne dispose alors que d’un cahier de spécifications détaillées et d’une fraction d’un produit inutilisable. Ces éléments ont un coût important mais presque aucune valeur. Il est peu probable qu’un autre maître d’œuvre accepte de s’engager à délivrer un produit sur la base de spécifications détaillées qu’il n’a pas lui-même écrites, et il est inconcevable qu’il s’engage sur un quelconque résultat.

Inspecter régulièrement

Le Product Owner est un champion de l’inspection, mais attention, inspection ne signifie pas contrôle mais investigation. Ce n’est pas au Product Owner d’inspecter la manière dont l’équipe transforme le Backlog de produit en un incrément « Fini », ni même au Scrum Master. Les Developers se chargent de cette inspection de manière autonome.

Le Product Owner inspecte en premier lieu son Backlog de produit et chaque élément qui le compose afin de s’assurer qu’ils sont clairs, qu’ils font sens et indiquent bien la direction que le Product Owner souhaite suivre pour atteindre les objectifs du produit.

En revanche, si le Product Owner ne contrôle pas le travail de l’équipe, il contribue avec elle, en tant que membre de la Scrum Team, à inspecter les processus qu’elle a mis en place et leur efficacité. Il doit également inspecter ses propres processus, notamment son organisation du Backlog de produit et la manière dont il décrit les éléments qui le composent.

Adapter les processus

L’adaptation des processus est la suite logique d’une inspection. Inspecter permet de faire un constat et d’identifier des points d’amélioration pour converger dans un sens positif. Il ne s’agit pas de modifier des processus ou des méthodes parce qu’il est écrit dans le guide Scrum que c’est indispensable. La Scrum Team doit comprendre pourquoi elle adapte ses processus.

Le Product Owner peut voir trois aspects majeurs dans l’adaptation des processus :

Dans tous les cas, avant même d’imaginer de quelle manière il sera possible de modifier un processus, il est important d’identifier la valeur que cette modification peut produire, et si possible son amplitude.

Améliorer la transparence

Ce dernier pilier de Scrum permet également au Product Owner de maximiser la valeur du produit et du travail de l’équipe de développement.

Rappelons que la transparence consiste à rendre visibles et compréhensibles de nombreux aspects du développement d’un produit (relire le chapitre Le patron Scrum à la section Les piliers de Scrum - Transparence). 

Du point de vue du Product Owner, la transparence concerne principalement le Backlog de produit, qui doit être constamment visible et compréhensible. A minima, il doit donc être accessible par toutes les personnes concernées par le développement du produit, que ce soient les Developers ou les parties prenantes. Idéalement, en étudiant le Backlog de produit, même une personne qui ne connaît strictement rien au cadre de processus Scrum doit pouvoir comprendre les points suivants :

Si le Backlog de produit ne véhicule pas ces informations et qu’il n’a de sens qu’aux yeux du Product Owner, alors il y a un problème de transparence à corriger rapidement. Si un néophyte doit poser des questions au Product Owner pour comprendre ce qui se passe sur le produit en ce moment ou sur ce qui est prévu prochainement, c’est également un problème de transparence. Le Backlog de produit doit faire sens.

Le Scrum Master étant garant de la transparence, il est possible de l’interroger régulièrement pour vérifier si le Backlog de produit lui semble suffisamment clair. Son appréciation ou sa critique ne doit pas être vécue ou anticipée comme un jugement et encore moins comme une condamnation, mais au contraire comme une mise en lumière permettant d’améliorer la communication.

Le Product Owner doit être vigilant sur la transparence de son Backlog de produit et des éléments qui le composent. Le plan de release peut servir à construire le Backlog de produit et à l’organiser, mais...

Piloter le budget

Scrum indique que le Product Owner est le seul responsable du produit. Il doit en gérer le budget, et cela ne signifie pas seulement en maîtriser les coûts de production.

Le Product Owner doit à la fois maîtriser les coûts de production et anticiper les coûts de maintenance et de retrait du produit. De plus, il doit s’adapter aux gains réellement mesurés lors des différentes itérations. 

Cette mesure factuelle est une source d’information essentielle à la prise de décision de financer ou non d’autres Sprints lors d’une revue de Sprint. Cette décision doit dépendre davantage de la mesure factuelle que de la planification initiale. C’est un changement radical induit par Scrum entre les métiers de chef de projet et de Product Owner.

L’exemple suivant permet d’illustrer cette activité de pilotage budgétaire réalisée par le Product Owner. Il est prévu de consacrer cinq releases (de 0.6 à 1.2) au développement d’un produit. Le coût total estimé est de 800. Dans un projet classique, ce serait le budget du projet. Le projet devra générer une valeur (VA) estimée à 3 200. Dans le « scénario estimé », il est donc prévu qu’à l’issue de la release 1.2 les coûts ne dépassent pas 800 et que le produit puisse délivrer une valeur de 3 200, soit une valeur ajoutée de 2 400.

Dans le scénario no 1, l’attention du Product Owner est focalisée sur la gestion des coûts. Il se félicite de la réussite de la première release et décide de réduire le budget alloué au développement. L’impact se fait ressentir sur la valeur lors de la seconde release, mais le ratio étant conforme à ce qui était planifié, il maintient la pression sur les coûts. À l’issue de la troisième release (1.0), il apparaît clairement que l’équipe parviendra difficilement à atteindre l’objectif de valeur (voir l’illustration de l’évolution de la VA). Il est important de comprendre que le Product Owner n’obtient cette information...

Piloter les délais

Dernier axe permettant de maximiser la valeur d’un produit, le délai peut être considéré comme une contrainte ou comme un objectif. Ce distinguo est important pour affiner sa stratégie en cours de développement et faire efficacement face aux imprévus.

Si le délai est une contrainte, il convient de la respecter, sans quoi la valeur du produit risque d’être fortement réduite. Par exemple, un produit lié à un évènement doit être disponible avant celui-ci. Si le produit est disponible alors que l’évènement est terminé, il n’a plus aucune valeur.

Mais si le délai est un objectif, il faut alors tenter de saisir la moindre opportunité permettant de réduire la durée avant la première mise en service. Lorsque le législateur français a autorisé la dématérialisation des contrats d’assurance, la première compagnie qui était en capacité de proposer des produits numériques a pris d’importantes parts de marché à ses concurrents. Dans un cadre concurrentiel, plus l’écart de délai est important, plus la valeur du produit est accrue.

Dans ce contexte fluctuant, le Product Owner doit pouvoir adapter sa stratégie à n’importe quel moment en fonction d’évènements externes, sur lesquels il n’a aucun poids.

Dans certains cas, il sera nécessaire d’accélérer la mise à disposition d’une version du produit, donc d’adapter le plan de release, pour faire face à la pression concurrentielle. Il est alors aisé de comprendre pourquoi Scrum recommande que l’incrément soit toujours dans un état « Fini », prêt à être déployé en production, et que la release soit planifiée à l’issue du Sprint en cours ou bien dans plusieurs Sprints.

C’est un principe majeur de l’agilité et de Scrum : pouvoir s’adapter en fonction des conditions de marché sans être contraint...