Intelligence collective

L’agilité, infaillible… ou pas ?

16 janvier 2019

L’agilité, votre président en fait l’éloge et vos clients n’ont que ce mot à la bouche ! Nombreux sont les exemples pour lesquels la méthode agile, devenue synonyme de réactivité et d’adaptabilité a fait ses preuves. L’un de ses objectifs est de palier l’effet tunnel des méthodes telles que le cycle en V, qui engendre souvent un décalage important entre le besoin du client et le résultat final du projet. Les méthodes agiles telles que Scrum, XP-eXtreme Programming… découpent un projet en petites étapes ou sprints de quelques semaines. Elles permettent au client de suivre son développement et de revoir ses priorités à chaque itération. Des méthodes qui s’adaptent au changement donc, tout en garantissant une solution qui fonctionne et une collaboration étroite avec les clients.

Cependant l’agilité est-elle aussi infaillible que tout le monde semble le penser ? Par le biais de trois expériences, nous analysons les potentiels obstacles que l’on peut rencontrer lors d’un projet en mode Agile et les moyens d’y faire face.

Une organisation contraignante

Un grand groupe, souhaite mettre en œuvre un portail collaboratif pour assurer l’animation de ces clients. En vue de mettre en place des évolutions constantes sur ce portail, un des membres du projet se dit que l’agilité pourrait être appropriée et propose ce mode de fonctionnement.
Oui mais… Rapidement, son enthousiasme est atténué par un certain nombre de freins. L’application étant utilisée par les clients, elle est de niveau de service platine, et est donc jugée critique. Ce niveau de service implique une disponibilité importante et un délai de résolution d’incident très rapide. Elle implique également une procédure de mise en production lourde avec des tirs de performance obligatoires par une équipe externe. En supplément, des passages dans divers comités et d’autres freins du même type. Le délai entre la fin d’une recette et une mise en production est de 5 semaines, et le nombre de mises en production est limité à 3 par an, ce qui limite l’utilisation de la méthode Agile.
Enfin, des contraintes organisationnelles sont également venues se mettre sur le chemin de cette belle idée. Comme dans tous les grands groupes, un projet est lié à un nombre important d’interlocuteurs internes (métier, MOA, intégration…) et externes (intégrateur, hébergeur…). Difficile de planifier des sprints avec un ensemble d’équipes qui elles, ne fonctionnent pas en mode Agile.

Dans un tel contexte, avec ce type de contraintes administratives et organisationnelles, la mise en place de l’Agilité et son approche itérative et incrémentale est difficile.
Il est néanmoins possible de tendre vers l’Agilité en actionnant quelques leviers :
• Une mise en production peut être planifiée tous les 3 ou 4 sprints, en incluant le contenu de l’ensemble de ces sprints.
• Une automatisation de certains tests en vue d’en réduire le temps peut être mise en place.
• Il est également possible de développer l’Agilité à l’échelle au niveau de l’entreprise pour intégrer, à terme, l’ensemble des équipes dans ce mode de fonctionnement. Attention, pour que cela puisse fonctionner, un fort sponsorship du top management est primordial.

Un principe agile pris au pied de la lettre

Plaçons-nous maintenant dans un autre environnement ; un projet mené en Agile depuis son commencement…

Un client décide de lancer une plateforme permettant un suivi individuel et un parcours de formation personnalisé en vue d’améliorer la gestion de la formation de ses collaborateurs. Cornerstone, « pierre angulaire » pour les intimes, un projet pilote 100% Agile, avec l’ambition d’appliquer à la lettre les principes du Scrum : des sprints de 2 semaines, un product backlog priorisé, une démonstration à l’issue de chaque développement, bref…

Oui mais… Au bout de 3 mois, un nouveau collaborateur rejoint le projet afin de renforcer l’équipe. En application du principe « des logiciels opérationnels plus qu’une documentation exhaustive », aucun document de référence, aucun manuel, aucun cahier des charges ni de compte-rendu d’ateliers n’ont été rédigés. On demande au collaborateur de travailler très rapidement à la rédaction d’un manuel utilisateur sur une solution qu’il connaît à peine…

Et ce n’est pas tout ! La conduite du changement a également été impactée par ce manque de documentation, les utilisateurs ne se sont pas sentis suffisamment accompagnés et le lancement a été très difficile.
Il est vrai que la méthodologie Agile ne prévoit rien de spécifique concernant la documentation. « Un logiciel qui fonctionne plutôt qu’une documentation exhaustive ». Cependant encore faut-il que les utilisateurs soient capables d’utiliser ce « logiciel qui fonctionne » !

Ici on assiste à une mauvaise interprétation de l’agilité, liée à un réflexe issu de la recherche de confort via le suivi à la lettre d’une ligne directrice. Tout le contraire de ce que prône le Scrum, et l’Agilité de manière générale. Le principe « Des logiciels opérationnels plus qu’une documentation exhaustive », ne cherche pas à faire l’impasse sur toute la documentation… mais plutôt à inciter les équipes à se poser, de manière très pragmatique, les bonnes questions sur ce qui va vraiment être utile ou pas.

Il aurait été judicieux de rédiger des fiches de synthèse pour les utilisateurs finaux à chaque sprint, expliquant de manière simple les fonctionnalités qui y ont été développées. On aurait également pu permettre à tous les utilisateurs d’accéder à un environnement de recette afin qu’ils puissent s’exercer à la pratique de l’outil grâce à ces fiches. On aurait ainsi augmenté l’implication de chacun dans l’avancement du projet et favorisé l’assimilation progressive du nouvel outil.

Il est important de documenter un projet afin de garantir son bon déroulement en cas de changement d’intervenant. Un compte-rendu synthétique reprenant les points essentiels évoqués durant chaque atelier permettrait non seulement de sécuriser toute nouvelle arrivée mais aussi de pouvoir donner un état d’avancement précis du projet à n’importe quel moment. Une telle documentation serait elle-même Agile, puisqu’elle aurait une réelle valeur ajoutée et serait livrée de manière incrémentale, au fil des sprints..

Un cadrage un peu trop cadré

Nouveau projet Agile, phase de cadrage. Le métier souhaite un engagement ferme de l’équipe projet sur la livraison de fonctionnalités cibles. Un engagement ferme… mais que fait-on de la confiance réciproque en la capacité de faire ? Et de l’adaptabilité au changement ? Ces éléments de l’agilité sont pourtant essentiels. La requête du métier, jugée contraire au fonctionnement en mode Agile, n’a pas été approuvée par l’équipe projet.

Cette situation peut avoir lieu lorsque les métiers n’ont pas été réellement formés à l’Agilité et perçoivent l’Agile comme une méthode permettant de livrer plus rapidement avec moins d’effort de leur part. Il s’agit alors de rappeler aux métiers les principes fondamentaux de l’Agilité, ses avantages mais surtout les prérequis essentiels à son bon fonctionnement. En particulier la nécessité pour les métiers de collaborer avec les équipes de développement, de leur faire confiance sur l’estimation de la charge de travail et de les accompagner au fil de l’eau dans la définition du produit.

Si malgré ces clarifications le métier souhaite toujours un engagement ferme sur les livraisons, alors une préconisation pourrait être de partir en cycle en V plutôt qu’en Agile, sans pour autant oublier les prérequis qu’une telle méthodologie implique. Parmi ceux-là, la formalisation très claire, en amont, de spécifications fonctionnelles détaillées devant servir de base de travail à l’équipe de développement.

Les trois expériences décrites ci-dessus, démontrent que la majorité des problèmes rencontrés est souvent liée à une mauvaise compréhension des méthodes Agiles de la part des entreprises.

Mener un projet Agile n’est pas possible si l’environnement et les acteurs du projet vont à l’encontre de l’application de la méthode.

Par ailleurs, une mauvaise interprétation de ses principes ou encore un manque de confiance envers l’équipe projet sont également les conséquences d’une mauvaise compréhension des méthodes Agiles.

Attention à l’effet de mode… Avant de proposer la mise en place d’un projet en Agile chez vos clients, assurez-vous que ce dernier a bien compris les tenants et les aboutissants d’une telle méthode et que son organisation en permet l’application. Si c’est le cas, n’attendez plus, soyez Agiles !

Newsletter

Inscrivez-vous à notre newsletter pour recevoir nos dernières actualités*

Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé de gestion des Clients et Prospects (CRM).

Le Responsable de traitement est la société weave, 37 rue du rocher 75008 Paris RCS Paris 802 396 085.

Elles sont destinées à l’activité marketing du groupe weave ainsi quà celle de ses filiales, à l’exclusion de tout transfert hors de l’UE. Elles sont conservées pour une durée conforme aux dispositions légales (par exemple 3 ans pour les données prospects).

Ce traitement nécessite votre consentement que vous pourrez retirer à tout moment sans que cela ne remette en cause sa licéité.

Conformément à la loi « Informatique et Libertés » et au règlement européen n°2016/679, vous bénéficiez d’un droit d’accès, de rectification ou d’effacement, ainsi que d’un droit à la portabilité de vos données ou de limitation du traitement. Vous pouvez également pour des raisons tenant à votre situation particulière, vous opposer au traitement de vos données et donner des directives relatives à la conservation, à l’effacement et à la communication de vos données après votre décès. Vous disposez également du droit d’introduire une réclamation auprès de la Commission Nationale de l’Informatique et des Libertés (www.cnil.fr).

Vous pouvez exercer vos droits en nous contactant à l’adresse vosdonnees@weave.eu.

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour mesurer notre audience, vous proposer des contenus et des offres personnalisées, ainsi que des fonctionnalités de partage sur les réseaux sociaux. En savoir plus sur notre politique de cookies et notre charte des données personnelles