Comment réussir un projet agile ?

Le 4 janvier 2021 |

Il a été démontré que 70 % des projets informatiques utilisant la méthode traditionnelle dite cycle en V échouent. De nombreuses recherches montrent l’impact bénéfique des principes agiles. Ce cadre de référence est désormais utilisé de manière fréquente par 95% des DSI et souvent cité comme l’élément indispensable pour une transformation digitale réussie. Pourtant une part encore significative des projets agiles ne délivre pas les promesses attendues. Comment être assuré de tirer parti des bénéfices annoncés par l’agilité et quelles sont les meilleures manières de faire d’un projet agile un succès ?

Un changement culturel fort et la mise en place d’éléments structurants

Trop souvent, ces éléments sont oubliés, partant du principe que pour être agile, il ne faut pas s’encombrer de processus trop contraignant. Or l’agilité est au-contraire une démarche très structurée qui doit être bien préparée en amont. Soucieux de décliner la volonté de leur Direction, des chefs de projets et des équipes adoptent les méthodes agiles. Forts d’une séance de présentation, au mieux d’une formation et d’un conseil, ils lancent le projet, mais bien souvent les principes mêmes de l’agilité issus des valeurs prônées par le Manifeste Agile ou résumés dans les piliers Scrum (transparence, inspection, adaptation) sont incompris.

Fréquemment, les pratiques anciennes perdurent. Les sponsors souhaitent à la fois des engagements en termes de coûts/qualité/délais, à l’instar du cycle en V, et de l’agilité pour permettre de répondre à des besoins nouveaux et fluctuants. L’agilité n’est pas un addendum aux traditionnels cycles en V ou W et vouloir concilier les deux approches est souvent une source d’échecs. La réussite nécessite de comprendre les changements culturels nécessaires et de faire des renoncements. Les différentes parties prenantes, notamment les sponsors, doivent en être conscients et prêts à jouer le jeu de l’agilité.

Parmi les bonnes pratiques insuffisamment appliquées, il convient de préciser systématiquement le périmètre en début de projet. La co-construction d’un backlog produit et des critères d’acceptance permet de partager et de faire vivre l’analyse de la complexité fonctionnelle et technique.  C’est-à-dire un backlog produit évalué en complexité et priorisé selon la valeur apportée à l’utilisateur final. Au même titre que dans un projet classique, une gestion de périmètre précise doit être mise en place avec des mécanismes d’escalade en cas d’évolution forte ayant un impact sur le déroulement du projet.

Identifier de nouveaux rôles spécifiques

La notion de chef de projet disparait au profit d’une co-responsabilité envisagée comme modèle d’efficacité et la bonne compréhension de ces rôles et modes de fonctionnement associés constitue elle aussi une clé pour sécuriser un projet agile. Les méthodes agiles font référence à différents frameworks de mise en œuvre : de manière générale, on retrouve toujours, comme le prévoit la méthode Scrum, au minimum une organisation composée d’un Scrum master, d’un product owner et d’une équipe de développement. Mais comment conjuguer ces rôles avec les rôles historiques ?

De nombreux projets en échec ont fait le choix de la coexistence : ces nouveaux rôles s’ajoutent aux rôles et fonctions prédéfinies. Ainsi des clients optent parfois pour une équipe bénéficiant d’un chef de projet, d’un product owner client, d’un product owner fournisseurs et un Scrum master nommé — sans véritable capacité à agir sur les différents obstacles. Leurs périmètres respectifs ne sont pas toujours bien connus et génèrent des incompréhensions.

Le rôle du product owner est clé pour la réussite du projet. Il doit avoir une bonne compréhension des enjeux métiers, la capacité à arbitrer et prioriser mais également une bonne compréhension des éléments méthodologiques à respecter. Il n’est pas pour autant un chef de projet nouvelle vague. La notion de responsabilité collective de l’équipe doit elle aussi être bien comprise pour s’assurer d’un mode de fonctionnement fluide entre l’équipe de développement et le product owner. Paradoxalement, si l’accountabilité s’effrite pour certaines activités, d’autres restent souvent peu pourvues. Les travaux sur la donnée, la gestion des risques, la sécurité ou la conduite du changement sont encore insuffisamment adressés.

Limiter les rituels enthousiasmants, freiner les déplacements ou multiplier le nombre de sites géographiques distincts concourent également au risque d’échec en empêchant de constituer une équipe véritablement intégrée. Même si l’unité de lieu n’est pas toujours possible (et ceci tout spécialement dans la période actuelle), il est important de faciliter le plus possible l’émergence d’une équipe intégrée, et c’est le rôle du Scrum Master de faciliter cette émergence et protéger l’équipe des perturbations externes au projet.

Inventer de nouveaux modes d’engagements

En effet, en remettant à plat les modes de collaboration voire de contractualisation entre les différentes parties prenantes du projet, la question des nouveaux modes d’engagements se pose. Les organisations « produits » permettent de faire perdurer les logiques projets dans le temps afin de répondre à des objectifs spécifiques et mesurables. Elles permettent d’associer des expertises différentes en décloisonnant les modèles traditionnels. Pourtant l’organisation temporaire en mode projet reste un incontournable.

Une organisation projet composée de deux équipes — « client/métier » et « fournisseur / DSI » — endosse le risque de perpétuer des modèles de gestion séparés. Chaque équipe reportant séparément à sa hiérarchie, maintenant ses réunions de coordination interne et partageant l’information jugée suffisante. Dans ces conditions, les rituels agiles deviennent alors des exercices de style sans réelle valeur où s’exercent les positions déterminées à l’avance.

L’organisation « deux équipes, deux projets » complexifie les mécanismes de décision, le suivi de la progression et génère de la défiance, y compris entre les opérationnels. Au contraire, il convient de miser sur les outils agiles (JIRA, Confluence, etc.), partagés entre les deux équipes, pour créer les conditions de la transparence et avoir des indicateurs embarqués sur l’avancement.

Le fait de conserver deux équipes ne permet pas de résoudre le dilemme entre engagements de moyens et engagements de résultats et crée les conditions favorables à l’échec. La relation client fournisseur se noue alors sur une gestion fine des engagements et renonce à l’idée d’un partenariat en équipe intégrée. Fort d’une défiance réciproque, le client justifie toutes ses demandes en se référant au cahier des charges initial et le fournisseur opacifie ses processus pour couvrir ses marges de manœuvre.

La transparence et la collaboration au cœur du projet agile grâce à une mesure précise de l’efficacité

L’appréciation qualitative et quantitative de la valeur apportée doit être le guide de la planification agile. Cela implique de maintenir en continu le « cas d’affaire » ou « business case » du projet en recherchant l’innovation ou le perfectionnement qui correspondra aux utilisateurs finaux.

Pour optimiser l’équation coûts/bénéfices, l’équipe produit doit tester au plus tôt l’outil dans des conditions réelles pour s’assurer de la véracité du besoin. Le périmètre pourra ainsi évoluer à la hausse ou à la baisse selon l’arbitrage du sponsor.

La clé d’un projet agile réussi repose sur la capacité à démontrer cette valeur et pour l’équipe à réussir à évaluer de manière de plus en plus précise sa capacité de production et à se positionner dans une logique d’amélioration continue. Pour cela, les métriques de suivi (la vélocité notamment) doivent être définies dès le démarrage du projet et suivies de manière précise tout au long du projet. Ces métriques doivent être la référence pour le pilotage du projet et servir à alimenter les reportings. En mode agile, où toute tâche inutile doit être supprimée, les reportings utilisés par les équipes doivent être également ceux visibles par les sponsors. Finies les heures de préparation de COPIL servant uniquement à produire un reporting spécifique. La mise à disposition d’indicateurs partagés favorise la transparence et facilite la coopération entre les équipes.

En synthèse, si elle séduit par ses promesses, la gestion de projet agile doit faire l’objet d’une préparation et mise en place rigoureuses pour atteindre ses objectifs. Le changement culturel induit ne doit pas être sous-estimé car il sera le principal facteur d’échec. Le respect des modalités via la définition précise des rôles, la mise en place de règles et d’une organisation adaptée ainsi que la clarification des modes de fonctionnements entre l’ensemble des parties prenantes sont les clés. Enfin, une attention particulière devra être apportée à la mesure de l’efficacité du projet.

Tirer le meilleur parti du digital grâce à la DSI

Auteurs