Une floraison de post-it : le printemps de l’Agilité

Il va sans dire que les méthodes agiles ont fait florès dans les organisations du public ou du privé depuis la publication du Manifeste Agile (Agile Manifesto) il y a presque 20 ans.

Nous continuons d’observer cette propagation massive chez nos clients et ce à divers niveaux. Outre la démultiplication des post-it et autre management visuel sur les murs, le constat est sans appel : on veut instaurer la culture agile dans l’entreprise (de la multinationale centenaire à la start up en gestation), mettre en place une organisation agile dans les services, gérer ses projets en agile, développer en agile… Scrum, Kanban, Lean, Extrem Programing (XP), Devops, Feature Driven Developpment (FDD),… l’offre agile est pléthorique et complexe. Toutes ces méthodes s’appuient sur une multitude de concepts et de principes qui se recoupent, pour tout ou partie, mais avec une déclinaison opérationnelle différente. Comble de l’agilité, certaines méthodes ont même donné naissance à de nouvelles méthodes comme le ScrumBan issue de la méthode Scrum et Kanban ! Comment donc se positionner face à ce bouquet de méthodologies ? Faut-il forcément mettre en place l’agilité ? Au commencement de ces réflexions, il est indispensable de se (re)poser les questions suivantes :

• Quelles sont mes problématiques ?
• Quel est l’objectif à atteindre ?
• Et enfin, quelles sont les limites de ma situation actuelle ?

A ces questions, les méthodes agiles apporteront des réponses sur les moyens à mettre en œuvre pour dépasser les limites initiales mais ne seront en aucun cas des réponses de fond. L’agilité n’est pas une fin en soi. Questionner et dépasser les limites existantes, c’est d’ailleurs ce qui fit le succès de ces méthodes :

• Là où le client constatait un écart entre l’expression de son besoin initial et le livrable final (déception courante lors des projets en cycle en V), on mit en place des feedback réguliers, un backlog, un système de priorisation des tâches et une livraison des travaux de manière itérative.
• Là où il devenait nécessaire de gérer les interactions entre les ressources/équipes, on constitua des équipes pluridisciplinaires, mit en place un plateau projet et organisa des daily meeting pour partager l’état d’avancement, les succès et les difficultés.
• Là où il fallait suivre de manière simple l’avancement du projet et impulser du dynamisme dans les travaux, on redéfinit le découpage des livrables à un niveau de maille plus fin, on créa les visions, story map, les personas et user stories

C’est donc en amont de l’application de l’Agilité qu’il convient de se poser les bonnes questions face à une situation donnée. Le contenu ou l’application de ces méthodes peut parfois apparaître aux yeux des décideurs ou des opérationnels, comme la panacée face aux limites des méthodes traditionnelles des années 1980 (méthodologie en cascade, cycle en V,…). Combien de fois voyons-nous les mots « mise en place de la méthode agile » en réponse à une matrice des risques dans les supports de comité de pilotage, ou dans les premières lignes d’une démarche projet ? Mais la mise en place n’est pas tout. Une fois déployée une agilité non contrôlée peut mener l’organisation ou les projets à la dérive. Le facteur temps est un élément indispensable à prendre en compte.

Gare à la chute des post-it : l’automne de l’Agilité...

Le mot « agilité » rassure et sa mise en place au sein des organisations et des projets peut s’avérer fructueuse. Pour autant, un succès sur la durée nécessite deux attributs majeurs : Formation et Discipline.

Si les coachs agiles préconisent de choisir la méthode la plus adaptée aux besoins de leurs clients, il est rare dans des projets d’ampleurs que l’ensemble des parties prenantes soit sensibilisé aux mêmes méthodes. De là peut naître la fracture. Côté métier, les équipes peuvent se trouver fort dépourvues au regard du principe « des logiciels opérationnels, plus qu’une documentation exhaustive ». Agilité ne doit pas rimer avec absence de documentation. Côté IT, les équipes peuvent se sentir surchargées au regard d’un backlog grandissant sans nouvelle priorisation des tâches. Agilité ne doit pas rimer avec « évolution erratique du besoin ». Tels sont des risques fréquemment rencontrés lorsqu’une partie de l’écosystème de l’organisation choisit l’agilité alors que les autres parties prenantes du projet ont un autre mode de fonctionnement.

Si la mise en place d’outils agiles peut impulser du dynamisme et participer à la résolution de problème ou tout simplement au bon lancement d’un projet, maintenir une telle dynamique n’est pas chose aisée. Des post-it qui ne « vivent » pas tombent… Les aléas des projets font que la tentation de sacrifier la « routine agile » sur l’autel du traitement des urgences n’est jamais loin. Annuler un daily meeting en cas d’absence du Scrum Master ou de réunions peut sembler compréhensible et anodin, mais on constate que cela peut devenir le grain de sable qui enraille la machine… les outils agiles sont efficaces lorsqu’il y a constance et fréquence d’utilisation.

Par-delà le bien et le mal de telles ou telles méthodologies au regard d’un projet, il revient au chef de donner le cap, le tempo et de s’assurer de l’adhésion et de la motivation de chacun. Agilité, cycle en V ou méthodes hybrides, plus que le choix de la méthode la plus adaptée, il convient de s’en remettre au bon sens, de garder à l’esprit l’objectif à atteindre, de composer de manière pragmatique avec l’existant et de prendre en compte le facteur temps. La véritable agilité ne reviendrait-elle donc pas à extraire, le cas échéant, la substantifique moelle d’une ou plusieurs méthodologies au regard de l’organisation en place et de son rythme de vie ? In medio stat virtus conseillerait Aristote.