Agilité : confessions d'un chef de projet digital converti

En tant que Chef de Projet dans le monde digital depuis plus de quinze ans, j'ai souvent entendu parler de la mise en œuvre des méthodes Agile avec des sentiments assez partagés. Il s’en dit le meilleur… comme le pire !

Le fait est que les entreprises sont de plus en plus attirées par une organisation Agile, réputée plus souple, flexible et adaptative, censée placer le client au centre de son fonctionnement. Il en découle que tout collaborateur impliqué dans un projet digital (Développeur, Testeur, Chef de Projet, Expert, Architecte) a donc aujourd’hui de grandes chances d’intégrer un projet se déroulant dans un cadre Agile. Il est difficile d’y couper, alors autant essayer d'intégrer ce type de projet avec le meilleur état d’esprit possible : mon expérience pourrait vous y aider. 

UNE MAUVAISE PRESSE POUR L’AGILITE ? 

C’est un travers très français : nous avons tendance à se souvenir des aspects négatifs au détriment de ceux positifs. C’est ce qui n’a pas manqué de se produire lors de mes premières discussions informelles sur le sujet. J’en ai retenu  : 

  • Agilité = Une méthode qui permet surtout au client de changer son besoin trop rapidement et amène l'équipe à faire et défaire sans cesse ; 

  • Agilité = Une méthode qui infantilise les collaborateurs avec l'application de rituels contenus dans un cadre perçu comme trop rigide ; 

  • Agilité = Une méthode qui donne l'impression d'être noyé par la répétition incessante des sprints et des rituels les composant.  

Bref, des aspects qui à première vue ne me donnaient pas envie de passer le cap ! 

UN 1ER ESSAI MITIGE 

Comme beaucoup de collaborateurs, je me suis retrouvé confronté du jour au lendemain à la méthodologie en rejoignant un projet estampillé « Pseudo Agile », « Pseudo Agile » car l’équipe en place essayait d’appliquer certaines composantes de la méthodologie telles que :  

  • La mise en place d'un backlog ; 

  • La création de sprints ; 

  • Des séances de planning poker. 

Cela peut fonctionner, mais sur ce projet certaines composantes essentielles n'avaient pas été appliquées telles que : 

  • Le calcul de la vélocité de l'équipe ; 

  • Une gestion millimétrée des priorités.  

Ce qui fait que l'équipe avait le sentiment de balancer constamment entre action et attentes.  Dans ces conditions, les préjugés précédemment entendus sur l’application de l’Agilité me semblaient se confirmer. Néanmoins mon constat penchait plus vers une conclusion de type : « AGILE : plus jamais COMME CA » plutôt que vers « AGILE : plus JAMAIS CA » 

En effet, comme dans la plupart des retours d’expérience sur les projets Agile, le sentiment de solidarité dans la collaboration de l’équipe s’avérait intéressant ; d'autre part, les raisons des difficultés rencontrées sur ce projet étaient en partie identifiées et des axes d'amélioration pouvaient se dégager : avec du temps, j’avais le sentiment que cela aurait pu s’arranger. 

UN 2EME ESSAI TRANSFORME 

La 2ème confrontation avec cette méthode s’est produite dans un cadre très différent. Cette fois-ci, j’étais acteur de la transformation Agile d'un projet alors géré en cycle en V, en tant que Scrum Master certifié. Cette transformation a été initiée à la suite d’améliorations identifiées par le client et SQLI : 

  • Supprimer les temps d'aller-retour sur l'aspect contractuel ; 

  • Permettre de livrer et tester plus tôt ; 

  • Améliorer les interactions entre l'équipe de développement et l'équipe de test ; 

  • Regrouper le référentiel de connaissance.  

Mon expérience précédente couplée à l'assistance d'un coach Agile a permis d'aborder cette expérience avec plus de sérénité. Plusieurs aspects fondamentaux ont contribué à correctement initier l’expérience :  

  • La formation au concept de l'Agilité, en l'occurrence la méthode SCRUM, de toute l'équipe avant de basculer sur le nouveau mode ; 

  • Un accompagnement d’un coach Agile sur les trois premiers sprints ; 

  • La définition précise des rôles et devoirs de chaque personne constituant l’équipe.   

Malgré ces conditions favorables, nous nous sommes retrouvés confrontés très rapidement à un certain nombre de situations problématiques :    

  • Un sentiment d’accumuler trop de réunions ou de n’être pas assez concernés par les sujets traités lors des rituels ; 

  • Certaines estimations manquant de fiabilité ont entraîné des dérives sur les tâches prévues dans le sprint backlog ; 

  • Certains développements embarqués trop tôt ont provoqué un surcroît d’allers-retours en cours de sprint ; 

  • Des aléas venus perturber le sprint backlog ont empêché l’équipe de réaliser la totalité de l’objectif fixé en début de sprint.    

Néanmoins les séances de formation au concept, ainsi que l’accompagnement du coach nous ont permis d’avoir de bonnes bases pour dialoguer, et de tout de suite rentrer dans un processus d’amélioration continue. Finalement, nous étions préparés à ce que tout ne se déroule pas comme décrit dans la méthodologie, et donc peu surpris de devoir corriger le tir. 

Nous avons donc retravaillé, entre autres :   

  • Les priorités du backlog, afin de ne rien oublier et éviter les mauvaises surprises en cours de sprint ; 

  • La mesure du pourcentage d’aléas dans le calcul de la vélocité de l’équipe ; 

  • L’optimisation du temps des rituels, en réexpliquant l’intérêt des rituels et en préparant mieux l’ordre du jour des réunions ; 

  • La réadaptation des critères nous permettant de dire qu’une US peut être embarquée dans un sprint ainsi que les critères nous permettant de dire qu’une US est terminée.  

Ces adaptations primordiales ont été appliquées lors des trois premiers sprints, ce qui nous a permis d’atteindre rapidement un mode de fonctionnement qui satisfasse toutes les parties, tout en donnant des résultats jugés positifs par la direction. 

Après un an et demi d’application de la méthode, ce mode de fonctionnement se solde d’un réel succès ! Certains développeurs marquent même un avis assez tranché en ne souhaitant plus travailler dans un autre mode. Pour ma part, même si je reconnais que la mise en place de cette méthode a résolu notre problématique sur ce projet, j’ai le sentiment que pour que cela fonctionne, il faut disposer des ingrédients nécessaires en termes d’analyse des nécessités d’application de la méthode, d’accompagnement et de formation, et d’engagement de toutes les parties. La connaissance de la méthodologie s’avère essentielle pour pouvoir s'adapter efficacement au cadre d'un projet. Et c’est encore plus vrai sur les premiers mois d’application de la méthode. Aujourd’hui cette expérience m’a confirmé l’importance d’être à l’aise sur ce type de méthodologie projet pour rester compétitif dans le monde des projets digitaux.  

Ça peut marcher ! 

Donc si vous ne connaissez pas cette méthode, essayez d’engranger un maximum de connaissances sur le sujet. Et si vous avez vécu une mauvaise expérience… donnez une seconde chance à l’Agilité, retentez !  

Bye bye cycle en V, welcome Agilité ?