Une progression significative dans l’adoption des méthodes agiles s’affiche fièrement pour nos organisations européennes : 83% des sondés en 2013 contre 59% en 2012. 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 ? Nous vous livrons ici un mode d’emploi unique et innovant à usage immédiat pour vos DSI et DAF.
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.
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 avons identifié quatre freins qui se distinguent nettement.
Le premier frein tient à la mauvaise adoption des méthodes agiles. L’agilité donne les règles mais pas le ‘comment’ : ainsi un ‘product backlog’ doit être priorisé par l’apport de Valeur Métier où le retour sur investissement (ROI) est le composant essentiel. Ainsi, chaque ‘Minimum Marketable Feature’ devrait avoir son propre ROI. Par principe, les méthodes agiles découpent la Vision du Produit. En pratique dans les projets SCRUM en France, la planification des story mapping (ou livraisons des éléments fonctionnels ou techniques du produit) n’est pas suffisamment priorisée. De plus, ces incréments de produits livrés ne s’inscrivent pas dans l’actualisation d’un plan de release plus global où chaque MMF impose son ROI défini avec des objectifs mesurables, et cela tout au long du projet.
Le second frein s’illustre par une erreur de casting dans la distribution des rôles. SCRUM nous dit également que le pilotage par les bénéfices métiers (cf ‘Business Value’) est de la responsabilité du ‘Product Owner’ (PO), seulement personne n’explique concrètement au PO 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’. C’est le rôle le plus important dans une démarche SCRUM qui doit être incarné par un acteur très impliqué dans le projet. Pourtant, on constate encore en 2013 qu’il est le moins formé de tous les acteurs 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, endosse une responsabilité budgétaire. En France, par défaut, celle-ci est portée par les Directions des Systèmes d’Informations (DSI) qui encadrent les équipes de développements. 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éveloppements, etc.), omettant la contribution des métiers. Cela conduit immanquablement à une ‘non maîtrise’ du budget.
Enfin le quatrième frein s’explique par une présence d’indicateurs agiles réduits à un pilotage opérationnel du produit. Avez-vous déjà essayé de présenter ces indicateurs agiles en Comité de Direction, auprès du sponsor ou à un Directeur Financier, pour justifier un dépassement budgétaire ?
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’, vous pouvez calculer le coût du point d’un ensemble de fonctionnalités dans une approche prédictive et guidez vos décisions.Un ROI adapté au concept agile
Le ‘product backlog’ est bien plus qu’une liste d’histoires à coder par des équipes de développements. Il doit être priorisé en mettant en évidence les ‘stories’ les plus créatrices de valeur. Le modèle de gestion pour piloter votre ‘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, vous devez construire votre propre modèle. Modèle d’emploi : deux étapes essentielles.
- Définir le bon niveau de granularité des fonctions à périmètre constant dans le temps. Vous devez ventiler les points des ‘stories’ par ensembles fonctionnels homogènes et cohérents sur une période donnée. Ne soyez pas réducteur en établissant le modèle de gestion sur les stories mais gardez une vision fonctionnelle pour que ce modèle de gestion soit pérenne. Notre conviction repose sur un agrégat de fonctions EPIC ou Feature 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 de votre produit (Cf. modèle TBR, Think, Build, Run basé sur le cycle de vie d’une application). Vous affectez 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 de votre 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.
Un point d’attention : le contenu de votre ’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 donc être revu et priorisé à une fréquence régulière par le PO. Ainsi votre modèle devra s’adapter aux changements de l’agilité (valeur du point, changement de durée des sprints, reclassification fonctionnelle des ‘stories’…).
Notre conviction est que 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, vous devez construire des scénarios de ROI et y associer des objectifs mesurables. Rappelons que le ROI doit être calculé, dès la phase 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. C’est bien connu, selon leurs visions, tout est urgent et obligatoire. Comment arbitrer ces besoins et les gouverner économiquement ?
En Europe, les fonctions Marketing et Commercial ne sont pas en mesure d’évaluer systématiquement la ‘business value’ attendue d’un ensemble fonctionnel. Quel pourrait-être l’impact financier du non-respect d’un ‘time to market’ idéal ? Rappelons que le bénéfice d’une nouvelle fonctionnalité est lié à la conquête de nouveaux clients. Ce bénéfice est perdu ou amoindri si la période de livraison est décalée.
Ainsi, les multiples donneurs d’ordres expriment chacun au PO leurs niveaux de priorités, indépendamment les uns des autres. La lourde responsabilité porte sur le PO qui doit les ordonnancer. Comment peut-il prioriser ces besoins pour arriver à 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 pour arbitrer la ‘business value’ de la manière la plus objective qui soit, en présence de chacun. 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 et reposant toute décision sur des indicateurs de pilotage partagés.
Cette instance agile s’appelle le ‘Product Management Board’ où tous les donneurs d’ordres sont invités pour cet exercice de priorisation, sans déléguer leur responsabilité au PO. Le rôle du PO 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 time-boxée (2 à 4 heures) pour passer en revue les EPIC/features.
En amont, il revient aux experts opérationnels de chaque métier d’avoir préparé un ‘business case’ et d’estimer les bénéfices attendus par scénarios. La ‘business value’ doit être justifiée, motivé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).
Nos convictions
Après avoir essayé l’agilité, certains décideurs DSI et DAF s’interrogent sur l’intérêt de renouveler l’expérience 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 pour évaluer la ‘business value,’ utilisées Outre-Atlantique et encore méconnues en Europe, l’important est de ‘customiser’ votre modèle de gestion. En l’absence de ‘benchmarks’ et pour piloter efficacement vos projets agiles, vous devez garantir sa pérennité.
- Source Version one, éditeur de logiciel de gestion de projet Agiles qui réalise depuis 2008 des enquêtes annuelles, aux travers de sondages, sur l'utilisation des méthodes Agiles, dans plus de 88 pays.
- Cf. modèle de Kano, le theme screening ou encore le theme scoring
Ils interviennent dans le domaine de l’innovation,
de la transformation et du pilotage des Systèmes d’Information.
Décision Performance Conseil
Société de conseil spécialisée dans la définition et la maîtrise des projets d'amélioration de la performance
de l'activité et d'évolution des systèmes d'information.
