Rehia, le blog

Old and recent learnings and thoughts

En finir avec les méthodes agiles !

07 February 2011

Depuis bien longtemps, j’avoue avoir une petite irritation lorsque j’entends parler de « méthodes agiles ». Laissez-moi vous expliquer pourquoi.

Je vous rassure tout de suite, mon intention n’est pas de dire que l’agilité ne sert à rien ! Bien au contraire, je reste, malgré ce titre peut-être un peu provocateur, un fervent supporter de l’adoption des principes qui guident l’agilité pour permettre d’atteindre le but ultime : produire de la valeur.

Non, là n’est pas mon intention. Ce qui m’irrite, donc, c’est d’entendre ces deux mots si plein de sens ensemble : Comment peut-on parler de « méthode » lorsque l’on parle d’agilité ?

La méthode

Si l’on s’en réfert à Wikipedia, une méthode de travail est « une marche à suivre pour réussir ». Clairement, rien n’indique que la « marche à suivre » est prescrite et définie dans ses moindres détails.

De manière purement sémantique, donc, rien ne contre-indique l’utilisation du mot « méthode » pour parler de Scrum, Crystal Clear, ou DSDM par exemple.

Le poids du passé

Pourtant, l’opposition couramment faite est celle entre les « méthodes agiles » et les méthodes classiques ou traditionnelles.

Or, le reproche que l’on fait généralement à ces dernières est de fournir un cadre trop rigide, qui ne laisse aucune place à l’adaptation, ni même à l’introspection. Elles définissent très exactement les étapes et les tâches (séquentielles) à suivre pour réussir le « projet », sans tenir compte de l’organisation présente, et surtout des gens qui vont la mettre en oeuvre.

Pour mémoire, la Cascade a été décrite (et non inventée) pour l’une des premières fois en 1970 par Winston Royce, et ne date donc pas d’hier. Elle a été imaginée dans le but de fournir au département américain de la défense un moyen de faciliter l’externalisation du développement de logiciels ou de systèmes informatiques. Cette théorie s’appuyait également, en pleine période d’intense développement industriel, sur les modèles connus basés sur l’hyper-spécialisation, tels que le taylorisme et le fordisme.

Jusque là, je n’ai malheureusement jamais rencontré de chef de projet connaissant et maitrisant suffisamment bien la méthode pour « réussir le projet », expression qui reste à définir, sans quelques péripéties. En règle générale, tout se passe suffisamment « bien » pour que l’on ne se rende compte du retard que quelques jours avant la livraison. A partir de ce moment là, il devient difficile de rester dans le cadre imposé, et on tombe tout naturellement dans l’arrache !

Les méthodes agiles : une nouvelle recette de cuisine

On ne peut pas sérieusement parler de réussite lorsque tout le monde a travaillé nuits et jours, soirs et week-ends, sans discontinu pour arriver à un résultat bancal. Ces échecs à répétition, puisqu’il s’agit de cela, finissent par agacer les équipes.

Dès lors, lorsque l’on propose de nouvelles approches, basées sur des valeurs et des principes bien différents, on entend régulièrement ces mêmes équipes faire de l’ironie en taxant les méthodes agiles de « nouvelle recette de cuisine » qui permet de faire des miracles. Le coach peut donc se heurter à ce type d’idée reçue qu’il n’est pas toujours aisé d’adresser.

Je pense que parler régulièrement de « méthodes agiles » contribue fortement à cette image négative que peuvent avoir certains. Mais cela ne s’arrête pas là. Il est aussi fréquent d’entendre parler de chef de projet pour le scrum master, de la MOA pour le PO, alors que les rôles de Scrum sont bien différents de ce que l’on connaît déjà. Vouloir utiliser les mêmes termes, en se disant « c’est pareil ! », c’est se résoudre à penser que finalement, l’agile, ça ne change rien à avant !

Très bien, mais quel terme utiliser ?

Il me parait en effet bien osé de critiquer sans faire aucune proposition concrète.

Tout d’abord, il faut bien avouer que le mot « méthode » est très largement adopté, quoique je ne l’ai jamais vu écrit en anglais, que ce soit dans un bouquin ou sur internet. Les sociétés utilisatrices, la presse, et dans une moindre mesure, la communauté continuent d’employer cette expression. Elle a donc un certain poids.

Néanmoins, lorsque j’interviens en coach, en avant-vente et même en conférence, je me refuse toujours à l’employer. Je parle donc :

  • d’approches agiles,
  • de démarches agiles, terme qui a ma préférence
  • de pratiques agiles,
  • voire de cadre méthodologique, terme certes plus pompeux, mais au sens plus nuancé.

Dans tous les cas, une nuance, moins portée sur l’aspect prescriptif, telles que peuvent l’être les méthodes traditionnelles, me parait être de rigueur. L’Agile vaut bien cela !

Pourquoi ce débat ?

Mon but n’est pas de pinailler, mais de faire progresser les choses. L’adoption de l’Agile ne peut pas aboutir avec une conduite du changement trop superficielle. Il est nécessaire de faire prendre conscience assez tôt et progressivement des changements culturels que cela induit. Et cela passe par un vocabulaire suffisamment clair et en déphasage avec les méthodes traditionnelles, que la communauté, à juste titre, ne cesse de critiquer.

Comme je ne pense pas détenir la vérité, je vous invite à profiter des commentaires pour donner votre avis sur la question. Je serai ravi d’échanger avec vous !