NOS ACTUALITES
—
L’agilité à l’épreuve des faits : retour d’expérience sur un projet réussi
Trop souvent l‘agilité s’envisage dans un contexte idéal : nouveau projet, start-up, nouveau service, dans les faits, cette approche s’inscrit dans des projets existants, des refontes d’applications, elle trouve sa place dans un système d’information parfois conséquent, dans une organisation dont la robustesse et la qualité ont été mises à l’épreuve avec succès. Nous proposons un retour d’expérience, l’occasion de donner la parole à Javier Miranda, chef de projet sur un projet organisé en agile. Regard porté sur les enjeux, les difficultés et les écueils à contourner avec habileté.
Pendant 4 ans, j’ai eu l’opportunité de travailler sur un programme de refonte d’outils de déclarations de sinistres pour offrir aux gestionnaires une vision complète du client assuré.
Nous avons choisi l’agilité pour développer un outil qui réponde aux besoins des utilisateurs (gestionnaires sinistres et managers d’équipes), déployer des fonctionnalités au fil des livraisons (2 livraisons majeures dans l’année), et favoriser l’implication des métiers dans l’expression des besoins et l’écriture des Users Stories. Leitmotiv de la MOA : »Un outil fait pour les métiers, par les métiers ».
L’équipe était composée d’environ 40 personnes, avec un équilibre entre collaborateurs internes et externes. Grâce à elle, le projet a pu être mené à bien, les fonctionnalités ont été déployées en temps et en heure.
Nous nous sommes confrontés à plusieurs difficultés, à commencer par la méconnaissance des processus et de l’environnement par les collaborateurs externes (dont je faisais partie). La force de l’équipe a été de créer un climat favorable à une montée en compétences rapide (orchestrée par les collaborateurs internes).
Un projet mené en agile suppose la mise en place d’un cadre particulier avec des réunions et des temps de partage, des rituels (nommés cérémonies SCRUM). Celles-ci réunissaient beaucoup d’intervenants, ce qui a conduit à la mise en place de vidéos filmées (pour les démos) avec des circuits de validation (ce qui suppose aussi une charge complémentaire).
Par ailleurs, il fallait également gérer beaucoup d’interactions avec d’autres équipes projets (agile ou non) avec la mise en place de points de synchronisation réguliers pour échanger sur nos objectifs et s’assurer que les échéances soient cohérentes.
Un premier écueil tient à la manière dont l’équipe va s’approprier les fondamentaux de l’agilité. Prenons l’exemple du macro chiffrage du product backlog (et sa planification) : bien que nécessaire pour déterminer les budgets, il devrait être possible de l’amender, de le moduler en fonction des priorités, du contexte, du périmètre ou du planning. Lorsqu’un projet agile débute, les Users Stories ne sont pas écrites, elles sont tout au plus esquissées. A l’épreuve des faits, l’exercice se révèle sensible et il devient difficile de tenir ce principe. Il en va de même pour la planification : elle doit pouvoir évoluer dans le temps : planifier l’ensemble des sprints dès le début du projet est une tentation à laquelle il faut savoir résister – le planning doit participer en tant que variable d’ajustement – dans le cas contraire, le PO s’expose à un risque de frustration de l’équipe, un sentiment qui augmente au fur à mesure des déplacements systématiques de chaque sprint.
Sur le plan humain, le turnover des équipes (les équipes de développement notamment) est une composante importante. A compétences, expérience ou engagement égal, un remplacement est toujours délicat à réaliser. Pour maintenir le niveau de performance élevé qu’exige l’agilité, la connaissance acquise tout au long des sprints passés est un point clé. Pour y faire face, nous avons opté pour des périodes de recouvrement significatives sur le projet, c’est un facteur clé de succès.
Un autre retour d’expérience à partager : les phases de recette, ce que je retiens, c’est qu’il ne faut pas les sous-estimer. Le découpage d’un projet agile en différents sprints permet à l’équipe de développement de se concentrer sur les Users Stories. Dès le second, les choses s’accélèrent et il devient indispensable de préserver du temps (et ceci à chaque sprint) pour effectuer la recette dans de bonnes conditions et traiter les correctifs nécessaires en parallèle. L’astuce consiste à estimer convenablement cette charge – pour ne pas prendre le risque que les correctifs mettent en danger les objectifs du sprint.
Le projet s’est confronté à des changements de priorités : les Users Stories (US) lorsqu’elles sont regroupées au sein d’une EPIC forment un ensemble de fonctionnalités cohérentes. Or il peut arriver que des changements de priorité apparaissent et bouleversent le product backlog. Bien que chaque US doit être terminée durant un sprint, le retour d’expérience montre qu’il est essentiel de terminer l’EPIC entamée (à moins de décider de tout jeter). Dans le cas contraire, le code contiendra des parties inutilisées qui nuiront à sa maintenance et à sa qualité. La reprise a posteriori de l’EPIC suspendue nécessitera une analyse de ce qui a été réalisé et de ce qui reste à produire.
Évitez de multiplier les indicateurs de suivi du projet : nous aimons tous les chiffres, mais reconnaissons que certains n’ont que très peu d’intérêt. Le nombre d’US composant un product backlog n’apporte aucune information quant à la complexité d’un projet ou de sa valeur métier. Il est important de rester focalisé sur les indicateurs clés : Capacité À Faire (réajustée si nécessaire), macro chiffrage du product backlog (réajusté régulièrement).
Tout l’enjeu est le fait de monter une organisation SCRUM tout en gardant les réflexes d’une organisation « classique ». Par exemple, la présence de chef de projets dans une équipe agile scrum amène une superposition, et parfois le risque de faire doublon avec le rôle de Scrum Master. Or tous les chefs de projets ne sont pas des Scrum Master, et réciproquement.
Les aspects « classiques » de la gestion de projet (gestion des budgets, des ressources humaines, des relations avec le reste de l’entreprise) ne sont pas ou pas très peu développés dans le manifeste agile (et donc dans les formations Agiles). A mon sens, il est important de définir un RACI afin que chacun puisse s’y retrouver sans équivoque.