Le rôle clé du client dans la réussite d'un projet agile

Les entreprises qui se tournent vers de nouveaux cadres de travail tels que Scrum sous-estiment largement l’importance de leur implication dans la réussite des projets pilotés en mode Agile.

L’intérêt pour les approches Agiles se confirme année après année. Mais les entreprises qui se tournent vers de nouveaux cadres de travail tels que Scrum1 sous-estiment largement l’importance de leur implication dans la réussite des projets pilotés en mode Agile. Comprendre le rôle central du "Product Owner" est un premier pas décisif vers le succès.

Chaque année, les statistiques du Standish Group mettent en évidence le faible taux de réussite des projets informatiques réalisés selon la méthode dite du « Cycle en V », encore majoritairement utilisée dans les entreprises. Avec des taux de réussite 3,5 fois plus élevés – voire 6 fois plus, pour les grands projets – on comprend qu’un nombre croissant d’organisations souhaitent que leurs équipes internes et leurs prestataires travaillent en mode Agile, notamment en adoptant le cadre de travail Scrum. Si l’engouement pour Scrum est réel, sa philosophie – centrée sur la création de valeur pour les utilisateurs – est encore trop souvent mal comprise ou mal interprétée pour que son adoption délivre tous les bénéfices attendus.

Identifier les causes d’échec à la source

Une des principales causes d’échec des projets IT est le manque d’implication du client. En simplifiant, on peut dire qu’avec les anciennes méthodes, le rôle du client se limite peu ou prou à passer commande et, au bout de x temps, à réceptionner un produit fini, qui conviendra ou ne conviendra pas... Un principe fondamental des approches Agiles est au contraire que le client doit être impliqué de bout en bout dans le processus de création.

Cette implication continue est incarnée dans Scrum par deux acteurs : le sponsor, idéalement membre du comité exécutif, à la fois facilitateur et protecteur de l’équipe projet ; et surtout le Product Owner (PO) qui, au sein de l’équipe, est le représentant permanent du client – ou, plus exactement, des utilisateurs du produit à construire. Ni chef de projet au sens classique du terme, ni donneur d’ordres, le PO est avant tout le maître des besoins et l’arbitre des priorités. Une partie essentielle de son rôle est de gérer, hiérarchiser et prioriser le backlog, c’est-à-dire tout ce qui doit exister dans le produit pour que celui-ci réponde de manière optimale aux besoins.

Le backlog n’est pas un cahier des charges établi une fois pour toute. Il est enrichi et affiné tout au long du projet, avec une particularité importante : le PO veille à ce que tout ce qui y figure soit exprimé non pas en termes de fonctionnalités à développer quoi qu’il arrive, mais sous forme de besoins explicites appelés User Stories (US), précisant toujours qui est l’utilisateur, ce qu’il veut et pourquoi, sans préjuger de la manière dont il faut y répondre techniquement. Cette façon de procéder élimine les nombreuses fonctionnalités demandées "à priori" et "au cas où", sans réelle justification d’usage. Quand on sait qu’en moyenne seulement 20% de ce qui a été développé est réellement utilisé2, on mesure le gaspillage – d’énergie, de temps et d’argent – qui pourrait être évité dans la plupart des projets…

Orchestrer les itérations pour maximiser la valeur produite

Un projet Agile est fait d’itérations se traduisant chacune par un incrément fonctionnel pouvant être testé et validé par les utilisateurs. Une tâche importante du Product Owner est d’organiser ces itérations et de les préparer en estimant chaque User Story du backlog en termes de valeur "métier". Par contre, c’est l’équipe de développement et elle seule qui estime l’effort à fournir pour chaque User Story. Il peut ainsi proposer aux développeurs des itérations courtes au contenu réaliste, c’est-à-dire réalisable par l’équipe et délivrant une valeur mesurable par l’utilisateur. Dans le cadre Scrum, ces itérations appelées sprints ont en général une durée de 2 semaines. En pratique, chaque sprint vise à réaliser un ensemble déterminé de user stories.

 Il commence par une réunion où le contenu proposé par le PO est discuté avec les développeurs et ajusté en fonction des ressources et compétences disponibles. À l’issue de cette réunion, l’équipe de développement a confirmé ce qu’elle était en mesure de terminer au cours du sprint. Elle se répartit le travail et sait comment il va être réalisé, charge au PO de réintégrer dans le backlog ce qui a été écarté.

Exigeant, le rythme soutenu des sprints présente l’avantage de maintenir l’implication des parties prenantes dans la durée et évite de s’éloigner des besoins réels. Chaque sprint se termine en effet par une revue où les utilisateurs sont invités à s’exprimer sur l’incrément livré. On évite ainsi de pousser plus avant le développement de fonctionnalités ne donnant pas satisfaction ou n’étant plus d’actualité.

Choisir le bon Product Owner et lui donner les moyens de réussir

Les organisations peu rompues aux approches Agiles ont du mal à comprendre, d’une part, leur nature itérative et incrémentale et, d’autre part, les principes d’autonomie, de polyvalence et d’auto-organisation qui régissent le fonctionnement de l’équipe projet. Beaucoup se trompent aussi dans le choix du PO en pensant que ce rôle exige un profil IT. Il n’en est rien : le PO n’intervient pas dans le « comment » de la réalisation et sa valeur ajoutée réside dans sa capacité à maximiser la valeur du produit et du travail de l’équipe de développement. Pour cette raison, ce rôle gagne à être confié à une personne d’envergure, connaissant de l’intérieur le métier concerné par le produit, et dotée de solides aptitudes communicationnelles.

Une deuxième erreur courante est d’imaginer que le PO peut, parallèlement à ce rôle, assumer des responsabilités extérieures au projet. Son travail de liaison avec les utilisateurs, l’ordonnancement et l’affinage du backlog, la préparation des sprints et l’accompagnement des équipiers requièrent 100% de son temps. Enfin, il n’est pas nécessaire que le PO ait une connaissance approfondie de Scrum, car il est épaulé tout au long du projet par un autre acteur indispensable : le Scrum Master, qui veille en permanence au respect de la règle du jeu et au bien-être de l’équipe. Pas plus technicien que le PO, extérieur au métier, le Scrum Master doit en revanche très bien maîtriser les arcanes de Scrum pour être en mesure de transmettre et d’ancrer durablement dans l’organisation les 3 principes sur lesquels reposent la philosophie Scrum et la réussite des projets pilotés dans ce cadre : la transparence, l’inspection et l’adaptation.