Projets Scrum : comment impliquer le client durablement ?
L'agilité est le cadre de travail de tout projet e-commerce, c’est pourquoi elle est au cœur des pratiques SQLI, à travers Scrum en particulier. Les organisations qui font appel à nous sont expertes de leurs métiers, mais pas toujours des technologies web et du cadre Agile.
Le client est généralement novice sur le sujet. Pourtant, il est essentiel au succès d'un produit conçu en Scrum. Comment lui expliquer le rôle des parties prenantes et surtout le rôle clé du Product Owner (PO pour les intimes) ? Comment lui donner les moyens de tenir son rôle et de progresser tout au long du projet ? Comment compenser les inévitables insuffisances ? Dans les faits, ce que nous appelons dans notre jargon « manque de maturité client », est classé comme « risque » en début de projet et partagé avec lui. Cette étape assurément nécessaire reste insuffisante. Encore faut-il définir les actions pour que le risque soit au mieux évité, et au minimum réduit.
Que faire pour engager le client dans un projet Scrum ?
L'engagement est une valeur Scrum qui doit tout particulièrement être transmise au client. Son engagement, surtout en tant que PO, est indispensable tout au long du projet. Tout d'abord, il faut veiller à ne pas sous-estimer le travail que cela va représenter pour le Chef de Projet ou le Business Analyst ; sur tout un projet, il peut se traduire en jours. Il faut l'anticiper en termes de planning, car en plus de ses tâches habituelles, le Chef de Projet/ Business Analyst devra former à l'utilisation d’outils, éduquer au vocabulaire (« sprint », « backlog », « review » …) et s'assurer que le client est invité et participe aux événements. Expliquer les grandes lignes de l'agilité est certes utile lors d'un kick-off, mais doit être doublé de ce que l'on pourrait appeler une formation continue jusqu’à l’accomplissement du projet. Inviter le client aux sprints reviews est essentiel, il sera là dans son rôle de partie prenante. C'est le plus évident de son point de vue et là ne réside pas la difficulté.
La difficulté réside dans le rôle du PO, qui n'est pas (seulement) un testeur de livrable, sollicité une fois en atelier de spécification puis une autre fois après livraison. Cette approche correspond plutôt au fameux cycle en V (ou cascade), où client et agence se rencontrent deux fois dans le projet. Evitons le piège qui consiste à reprendre ce fonctionnement, en le déportant simplement de l'échelle du projet à l'échelle du sprint. Impliquons nos clients à tous les événements qui requièrent le PO : sprint planning, sprint rétro et bien sûr sprint review (auxquels on invitera aussi les parties prenantes). Impliquons aussi davantage le PO hors événements pour valider avec lui les choix fonctionnels et techniques. Plus il sera invité, plus il sera présent, plus il sera engagé.
Et si le client manque de temps ? Souvent sollicité sur d'autres tâches, parfois absent (maternité, maladie…), il ne peut assumer ses fonctions en tout ou partie. Il me semble illusoire d'imaginer que l'accompagnement suffise toujours. Qu'avons-nous constaté sur nos projets ? Le Chef de Projet/ Business Analyst est intervenu comme filet de sécurité et a pris en main une bonne partie du rôle de Product Owner. Bien sûr, cela permet au produit d'être livré, mais est-ce l'idéal ?
Un Product Owner : pourquoi en avons-nous besoin ?
Pas de produit réussi sans Product Owner présent et actif du premier au dernier sprint. Que se passe-t-il sur un cycle en V ? La fonctionnalité est spécifiée, puis développée, puis livrée. Résultat : beaucoup d'insatisfaction des utilisateurs finaux qui n’utilisent pas ou peu les fonctionnalités. Et de la déception côté client lorsqu'il découvre le livrable, pas forcément tel qu'il l'avait imaginé. Souvent aussi du retard dans le planning lorsqu'il faut revoir le développement. Pour éviter cet effet de (mauvaise) surprise à la livraison, Scrum implique le client durant tous les sprints. Un PO droit dans son rôle ne devrait jamais être surpris en review. Voilà le gain pour les clients et la raison pour laquelle les équipes SQLI choisissent Scrum. À nous, et surtout au Chef de Projet, d'être le porte-parole de ce type de bénéfice auprès du client.
Allons plus loin, faisons de l’itératif !
Le manifeste Agile met en avant les individus et leurs interactions. SQLI ne peut pas être agile seul ; l'interaction avec le client est fondamentale. Nous avons besoin des meilleurs PO. Comment y parvenir ? Comment améliorer l'implication de nos clients au quotidien ? Comment assurer un accompagnement de qualité pour leur transmettre notre expertise ? Soyons Scrum et posons-nous ces questions de manière itérative, à chaque rétro de sprint par exemple, et bien sûr à chaque bilan projet. Pour nous améliorer continuellement.