Les approches agiles séduisent de plus en plus. Alors que la mesure du retour sur investissement est essentielle, elles pêchent par un manque de pilotage économique. Mais celui-ci doit s’adapter au contexte particulier de l’agilité.
Selon l’étude The State of Agile Survey réalisé par Version One, 88 % des entreprises recourent aux développements agiles en 2013, contre 80 % en 2011. Les early adopters de ces méthodes sont les concepteurs d’applications et les sociétés de services IT. Cependant, l’ambition d’un projet agile reste principalement motivée par des objectifs opérationnels : l’accélération du time to market, l’arbitrage des priorités, l’alignement des besoins (IT/métier) et la maximisation des gains de productivité. La motivation économique n’est donc pas la priorité. Pourquoi ? Comment piloter économiquement les projets agiles, avec quelle gouvernance ?
Concilier agilité et maîtrise économique
Dans un contexte économique sous pression permanente, où l’enjeu fort est d’optimiser le ratio coûts/performance, on peut s’interroger sur l’absence de pilotage économique des projets agiles. Dans les faits, peu d’organisations se posent la question. Nous pouvons identifier quatre freins principaux.
Le premier frein : une mauvaise utilisation des méthodes agiles. L’agilité donne les règles, mais pas la marche à suivre : ainsi, un product backlog (voir encadré) doit être priorisé par l’apport de valeur métier, dont le retour sur investissement (ROI) est le composant essentiel. Chaque Minimum Marketable Feature (MMF) devrait avoir son propre ROI. Par principe, les méthodes agiles fractionnent la vision du produit. En pratique, dans les projets Scrum en France, la planification des story mapping (livraisons des éléments fonctionnels ou techniques du produit) n’est pas suffisamment priorisée.
Second frein : une erreur de casting dans la distribution des rôles. Scrum estime que le pilotage par les bénéfices métiers relève de la responsabilité du Product Owner (PO), seulement personne ne lui explique concrètement comment la définir et encore moins comment calculer son ROI. Cet acteur-clé porte la vision du produit, il administre et priorise la liste des fonctions à délivrer (product backlog) contenant les User Stories (voir encadré). C’est le rôle principal de la démarche Scrum. Il doit être incarné par un acteur très impliqué dans le projet. Pourtant, on constate encore qu’il est le moins formé aux méthodes agiles.
Le troisième frein repose sur une réelle difficulté à maîtriser le budget. Les bonnes pratiques des méthodes agiles indiquent que le PO est garant du ROI et donc, par construction, a une responsabilité budgétaire. En France, par défaut, celle-ci est portée par les directions des systèmes d’information qui encadrent les équipes de développement. Le flou est donc entretenu. L’évaluation des investissements est réduite à comptabiliser la totalité des coûts de la DSI (licences, infrastructure, jours hommes de développement, etc.), omettant la contribution des métiers. Cela conduit immanquablement à une dérive du budget.
Quatrième frein : une présence d’indicateurs agiles réduits à un pilotage opérationnel du produit. Présenter ces indicateurs agiles en comité de direction, auprès du sponsor ou à un directeur financier, pour justifier un dépassement budgétaire relève de la gageure. Pourtant, il est possible de construire un modèle de gestion permettant d’avoir une gouvernance économique d’un projet agile. Sans opposer « vélocité » à « capacité à faire », il est possible de calculer le coût du point d’un ensemble de fonctionnalités dans une approche prédictive et, ainsi, de guider les décisions.
Un retour sur investissement adapté au concept agile
Le product backlog est bien plus qu’une liste d’histoires à coder par des équipes de développement. Il doit être priorisé en mettant en évidence les stories les plus créatrices de valeur. Le modèle de gestion pour piloter le backlog doit d’abord s’articuler autour d’un calcul de ROI adapté aux méthodes agiles. Mais il ne suffit pas de l’adopter, il importe de construire son propre modèle.
Un point mérite attention : le contenu du product backlog (taille, poids, complexité) évolue au rythme des cycles itératifs des sprints et s’autoalimente. S’appuyant sur des livraisons fréquentes, il se transforme dans le temps avec de nouvelles priorités, de nouvelles histoires ajoutées et/ou modifiées, supprimées. Il doit être révisé, revu et priorisé régulièrement par le PO. Ainsi, le modèle devra s’adapter aux changements de l’agilité (valeur du point, changement de durée des sprints, reclassification fonctionnelle des stories…).
Le ROI d’un produit agile a du sens. Cependant, il s’avère complexe de l’estimer sur un petit ensemble fonctionnel ou sur une fonction transverse. Sur des hypothèses engageantes du métier, il importe de construire des scénarios de ROI et d’y associer des objectifs mesurables. Rappelons qu’il doit être calculé, dès la phase de design, puis tout au long du projet et, surtout, après la mise en production de l’application.
Une nouvelle gouvernance pour piloter
L’alimentation du product backlog est réalisée en fonction des demandes exprimées par un ou plusieurs contributeurs fonctionnels, pour qui tout est urgent et obligatoire. Comment arbitrer ces besoins et les gouverner économiquement ?
En Europe, les fonctions marketing et commerciales ne sont pas en mesure d’évaluer systématiquement la valeur métier attendue d’un ensemble fonctionnel. Quel pourrait être l’impact financier du non-respect d’un time to market idéal ? Comme le bénéfice d’une nouvelle fonctionnalité est lié à la conquête de nouveaux clients, il est amoindri, voire perdu, si la période de livraison est décalée.
Les multiples donneurs d’ordres expriment chacun au PO leurs niveaux de priorités, indépendamment les uns des autres. Ce dernier a la lourde responsabilité de les ordonnancer. Comment peut-il parvenir à un consensus ? Les priorités doivent être définies pour l’entreprise et non pour les responsables métiers. Aussi, pour un fonctionnement efficace, il convient de construire une gouvernance afin d’arbitrer la valeur métier de la manière la plus objective possible. Certaines difficultés peuvent faire émerger des conflits d’intérêts. Cette gouvernance s’articule autour d’une nouvelle instance, neutre, réunissant ces acteurs décidants grâce à des indicateurs de pilotage partagés.
Cette instance agile s’appelle le Product Management Board. Tous les donneurs d’ordres sont invités à s’exercer à la priorisation, sans déléguer leur responsabilité au PO. Le rôle de ce dernier est de faire converger les besoins dans la vision du produit. Il préside cette instance et s’assure de la représentativité des métiers avec un devoir d’alerte si certains se démobilisent. La séance de priorisation peut être limitée dans le temps (deux à quatre heures) pour passer en revue les fonctionnalités.
En amont, les experts opérationnels de chaque métier doivent avoir préparé un business case et estimer les bénéfices attendus par l’élaboration de scénarios. La business value doit être justifiée, avec des éléments chiffrables selon les quatre catégories suivantes : les revenus de nouveaux clients, le chiffre d’affaires additionnel des clients existants, la perte potentielle de clients et enfin l’excellence opérationnelle d’un nouveau service (coûts/performance).
Après avoir tenté l’expérience de l’agilité, certains DSI et DAF s’interrogent sur l’intérêt de la renouveler et à quel prix. L’objectif de réduire les coûts arrive seulement en 9ème position sur 12 dans les entreprises qui pratiquent l’agilité. Dès lors, si 70 % des entreprises sont globalement satisfaites, elles reconnaissent une réduction des temps de production et de livraison avec l’agilité. Sur un plan économique, les bénéfices visibles de cette expérience sont plus nuancés et peuvent limiter le développement de l’agilité.
Bien qu’il existe d’autres méthodes (Cf. modèle de Kan, le theme screening ou encore le theme scoring) pour évaluer la valeur métier, utilisées outre-Atlantique et encore méconnues en Europe, l’important est de personnaliser le modèle de gestion. En l’absence de benchmarks et pour piloter efficacement les projets agiles, il faut en garantir la pérennité.
Cet article a été écrit par Sandrine Allard, senior manager, et John Bilquez, senior consultant chez Decision Performance Conseil.
Deux étapes essentielles
- Définir le bon niveau de granularité des fonctions à périmètre constant dans le temps. Il faut ventiler les points des stories par ensembles fonctionnels homogènes et cohérents sur une période donnée, ne pas être réducteur en établissant le modèle de gestion sur les stories, mais en garder une vision fonctionnelle pour qu’il soit pérenne. Notre conviction repose sur un agrégat de fonctions Epic dont on saura déterminer les bénéfices. Si, sur une période passée, votre ventilation est calculée selon votre vélocité constatée, la prédictibilité est, elle, évaluée en Kanban avec le cycle time (durée moyenne de traversée d’une‘User story’).
- Appliquer une approche en coûts complets ou partiels, calquée sur le cycle de vie du produit (Cf. modèle TBR, Think, Build, Run basé sur le cycle de vie d’une application). Il convient d’affecter les coûts de vos rubriques budgétaires aux Epic et Feature afin d’en déterminer le coût moyen du point. La force du modèle est de garantir la transparence des coûts internes et externes des développements, de la conception à la recette jusqu’à la mise en production.
Glossaire
Story Mapping : cartographie des stories permettant de montrer en une vue unique l’ensemble du produit.
Minimum Marketable Feature (MMF) : le plus petit ensemble de fonctionnalités permettant de fournir une réelle valeur à l’utilisateur.
Product Backlog : liste des besoins et demandes fonctionnelles d’un métier.
User Stories : description d’une fonctionnalité ayant de la valeur pour un utilisateur et qui s’inscrit dans la vision du produit.
Vélocité : mesure de la quantité de travail terminé par l’équipe de développement lors du précédent sprint.