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.

1. Le plus tôt possible

La première livraison du produit sur le marché est une véritable source d’angoisse. C’est pour cette raison qu’elle est souvent reportée, ce qui est une stratégie dysfonctionnelle de gestion de n’importe quelle angoisse.

Avoir une réelle approche empirique permet de mieux gérer cet évènement et la tension émotionnelle induite.

Le Product Owner ayant peur de la réaction des utilisateurs face à un produit qui n’est pas terminé reporte alors sa première release. Au lieu de présenter un morceau du produit, il organise un atelier et montre des maquettes à un panel d’utilisateurs. Pour mener à bien cette activité, il s’appuie sur des consultants, des UX designers ou même certains membres de l’équipe. Non seulement cette stratégie...

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.

1. Inspection du Backlog de produit

Le Product Owner n’a pas besoin de mobiliser toute l’équipe pour inspecter régulièrement son Backlog de produit. Il peut le faire avec le Scrum Master, et éventuellement inviter un membre de l’équipe qui serait disponible. Il peut même le faire seul, bien que l’exercice soit alors un peu plus complexe.

La première question à se poser lorsqu’on inspecte le Backlog de produit est :

« Est-ce qu’en lisant la description des premiers éléments on retrouve une cohérence avec le plan de release ? »

Si dans le plan de release il est prévu qu’à ce moment l’objectif à atteindre consiste à accroître le taux de satisfaction des utilisateurs, alors les prochains éléments du Backlog de produit doivent permettre d’atteindre ce but. S’ils n’ont aucun rapport avec cet objectif, il y a un problème, soit dans le plan de release, soit dans le Backlog de produit, et il faut le régler.

Si ce problème de cohérence n’est pas réglé avant le prochain Sprint, la Scrum Team aura beaucoup...

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 :

Un accroissement de la valeur du produit, des processus étant modifiés afin de s’adapter au mieux aux contraintes ou aux exigences du produit.
Un accroissement de la transparence, ce qui permet une communication plus fluide et une maximisation de la valeur du travail réalisé par la Scrum Team et les parties prenantes.
Un accroissement de la valeur résultant du travail de l’équipe de développement, ce qui permet de délivrer un produit de plus grande valeur ajoutée dans le même laps de temps.

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.

1. Pour accroître la valeur

L’équipe ne s’organisera pas de la même manière pour produire une interface uniquement destinée à tester le fonctionnement d’une brique métier et une interface qui sera utilisée en environnement de production avec une forte charge. La différence entre ces deux environnements est tellement grande que la seule adaptation de la définition de « Fini » ne permet pas de maximiser totalement la valeur du produit ; il faut également adapter les processus de production.

Le curseur est donc difficile à placer, et le Product Owner doit donner une orientation claire à toute la Scrum Team, car c’est lui qui a la meilleure vision du produit.

a. Marie face au RGPD

Marie travaille pour une grande banque et doit mettre le site Internet de consultation des comptes des clients en conformité avec le RGPD (Règlement général sur la protection des données).

Plutôt que de travailler directement sur l’environnement...

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 :

Sur quels aspects du produit la Scrum Team est en train d’investir ses efforts.
Sur quels aspects du produit elle projette d’investir des efforts à court terme.
À quel stade du développement du produit la Scrum Team en est arrivée à ce jour.

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...