L’art de travailler en « mode agile »

Méthodes singulières

Par Diane Toko

 

Pour commencer, inutile de préciser que l’agilité c’est quasiment l’opium des projets informatiques de notre siècle. De plus en plus, on fait appel à l’agilité à toutes les sauces. Bien sûr elle est  bénéfique pour les projets, mais mal appliquée, le scénario peut devenir très sombre pour l’entreprise. Force est de constater qu’aujourd’hui, l’agilité s’est vidée de son sens. Beaucoup de personnes pensent faire de l’agile, alors que ce n’est pas le cas. En réalité, on a réduit l’agilité à un concept marketing. Dire qu’on travaille sur un projet en mode agile ça fait plutôt classe non ? Après tout c’est à la mode ! D’autant plus que personne n’aimerait être tagué de « old school ».  Seulement, il y a une différence entre vouloir être agile et l’être véritablement. Alors, C’est quoi au juste être agile ? Et comment rendre son organisation agile ?

 

Ce que l’agilité n’est pas : retour d’expérience

 

J’ai personnellement déjà eu l’opportunité de travailler sur un projet dit « agile » pour un grand groupe il y a quelques années. La méthode utilisée était celle qui est la plus répandue aujourd’hui dans les entreprises : la méthode SCRUM1. Nous avions adopté certains « rituels » qui nous permettaient quelque part de justifier, peut être inconsciemment, que nous travaillions en mode agile. Voici quelques-uns de ces rituels :

  • Réunions hebdomadaires d’1h tous les mardis matin, qui avait pour but de rendre compte à la hiérarchie de l’état d’avancement du projet, et surtout de mettre en lumière les alertes et les points de blocage,  
  • Des rôles bien définis au sein du projet : Scrum master, product owner, équipe de développement. Le travail de chaque acteur de l’équipe était clairement défini et délimité,
  • La pratique de sprints : pour rappel, les sprints permettent de diviser le projet global en plusieurs petits projets avec des phases de développements incrémentaux,
  • Des « daily meeting » , qui ne duraient pas plus de 20min avec les principaux acteurs du projet, des échanges réguliers avec les clients finaux du projet pour recueillir les besoins d’évolution à intégrer dans les prochains sprints, entre autres.

Ceux pour qui l’agilité se résume à des rituels pourraient défendre qu’il s’agit bien là d’un projet en mode agile. Je m’attire peut-être des foudres mais aujourd’hui, avec du recul, je me rends compte que ce projet n’avait d’agile que le nom….je m’explique.

L’agilité ce n’est pas un ensemble de rituels cantonné à des méthodes. Ce n’est pas parce qu’on fait du Scrum qu’on est agile. En d’autres termes, ce n’est pas parce qu’on applique une « méthode agile » qu’on est agile car l’agilité est fondée sur des principes. Si ces principes ne sont pas respectés, on a beau organiser des réunions hebdomadaires, mettre en place des sprints, des « daily meeting », etc., on est dans l’illusion. Il est quasiment impossible d’espérer en la réussite d’un projet qui se veut agile sans qu’il y ait une diffusion de la culture agile, même si on prétend utiliser un outil agile ou une méthode particulière.

Dans le cadre de ce projet auquel j’ai participé, j’ai relevé 2 principaux freins à la concrétisation de l’agilité ou encore à la diffusion de la culture agile :

  • Le poids de l’organisation hiérarchique qui ralentit la prise de décision. Oui, une structure hiérarchique forte peut constituer un véritable frein à la réussite d’un projet agile. Certaines décisions du projet devaient attendre l’aval du plus haut niveau de la hiérarchie pour se concrétiser. Bref, un vrai parcours de combattant ! Or si les délais et le budget n’évoluent pas, la méthode agile peut virer au cauchemar. Toutes les personnes de la structure hiérarchique doivent être imprégnées de la culture agile, et plus la structure est forte, plus il est difficile de faire inculquer cette culture car on aura à faire à une multiplicité d’acteurs, tous différents les uns des autres, ayant des sources de pouvoir à des échelles différentes, des « zones d’incertitude2» variables, etc. J’ai réalisé la véracité de cette citation de Gustave Flaubert : « à chacun ce qui lui convient. Toutes les plantes ne veulent pas la même culture3».

 

  • Le style de management par objectif qui individualise les enjeux. Cela peut paraitre anodin mais le style de management joue un très grand rôle dans les projets agiles. Je me suis rendu compte que le style de management par objectif était un véritable frein à la concrétisation de l’agilité car comme dans toute entreprise, on ne consacre du temps à des tâches qu’à condition qu’elles nous rapportent ! Ceci va totalement à l’opposé de l’un des principes de l’agilité : la collaboration avec le client plus que la négociation contractuelle. Pour que le projet avance, il fallait qu’il soit dans les objectifs personnels. L’avancement d’un projet en mode agile ne doit pas être conditionné à ce qui est contractuel. Vouloir atteindre les objectifs annuels personnels à tout prix impose de devoir respecter certaines règles. Or l’agilité n’est pas compatible avec l’application stricte des règles.

 

Ce que l’agilité est…

 

Maintenant, pour qualifier ce qu’est un véritable projet agile, revenons aux fondements de l’agilité. En 2001, 17 experts du développement logiciel se ressemblent dans le but d’améliorer la gestion de projet en termes de respect des délais, de budget et surtout de satisfaction client. De cette réunion, ils ont donné naissance à un bébé qu’ils ont appelé le « Manifeste agile », essentiellement basé sur 4 valeurs, desquels découlent 12 principes. Ces valeurs sont les suivantes4:

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

L’agilité c’est une culture à transmettre, un état d’esprit à inculquer à tous, et pas seulement aux équipes IT. On est agile si on est capable de changer de méthode au cours du projet parce qu’on s’est rendu compte que la méthode utilisée n’était pas appropriée. On ne fonce pas tête baissée pour entrer dans un effet de mode. Autrement, on demeure dans l’illusion. Il faudrait se poser les bonnes questions : nos « Scrum meeting » sont-elles productives ? Nous permettent-elles de nous améliorer ? D’être plus efficace ? Sommes-nous véritablement ouverts aux changements en cours de projet ou sommes-nous cantonnés aux règles ? Le projet tend –t –il vraiment vers la satisfaction du client ? Etc. Les rétrospectives en cours de projet sont très utiles, et elles doivent permettre de nous améliorer, quitte à changer de process, d’outil, de règle et de fonctionnement. Pour moi, c’est cela un projet agile.

Je me suis rendue compte, in fine, de l’importance d’effectuer un diagnostic organisationnel en amont lorsqu’on veut travailler en mode agile. Cela permet de déceler des incohérences entre la structure de l’entreprise, son organisation et la culture agile en elle-même. La plupart des organisations sont encore trop rigides pour évoluer pleinement en agilité. Au regard de ce retour d’expérience, je soutiens l’idée qu’il est plus difficile de gérer un projet en mode agile dans les grands groupes que dans les petites structures. Cela ne veut pas dire que c’est impossible, mais l’une des manières la plus sûre d’y arriver, c’est que la culture agile soit impulsée par le haut de la hiérarchie. Après tout, il est plus facile de changer de chef que de faire changer le chef ! Disait François PROUST.

 

Bon alors…et vous, êtes-vous vraiment agile ?

 


1. SCRUM signifie « mêlée » en anglais. C’est une méthode qui est basée sur des phases de développement de quelques semaines, pendant lesquelles le produit est développé sous forme de sprints  qui se concentrent généralement sur quelques fonctionnalités, voire même sur une seule fonctionnalité. Les fonctionnalités à développer lors des sprints sont souvent répertoriées et priorisées dans le cadre d’un backlog produit.

2. Concept sociologique qui désigne ce sur quoi se fonde le pouvoir (la connaissance de process, de procédures, de règles, la maitrise de l’information, l’expertise, etc.).

3. Lettre à Maxime Du Camp, le 7 juillet 1852

4. https://agilemanifesto.org/iso/fr/manifesto.html

Nous sommes à votre disposition pour répondre à toutes vos questions.

SCROLL