Article écrit par Matthieu Lallemand

Cette semaine, j’ai lu plusieurs articles visant à démontrer aux chefs d’entreprises et aux décideurs à quel point les méthodes agiles sont une perte de temps et d’argent. Je vais tenter dans ce billet de poser une réflexion sur ce sujet, qui selon moi est loin d’être aussi tranché qu’on pourrait le penser.

Le premier article est rédigé par Michel PASOTTI, un avocat du barreau de Paris ayant officié chez IBM. Si je résume rapidement son article, il estime que les méthodes agiles sont dangereuses car les clients sont facilement manipulables tant au niveau technique que financier à cause du manque de limites claires dans les gestions de projets Agiles. C’est dommage car si la forme de son article est vraiment un amas de préjugés (il ne semble pas, par exemple, avoir entendu parler les livrables utilisables), eh bien dans le fond, si on gratte bien, il y a quelque chose de fortement intéressant :

Son article fait tout simplement ressortir que les grandes entreprises ne sont pas agiles, et s’engager dans une démarche agile pour elles est très périlleux ! Je partage tout à fait ce point de vue car pour moi aussi, les grandes entreprises et multinationales (occidentales) ne peuvent pas être agiles.

Prenons l’exemple de Toyota et du Kanban. Quand on en parle, il faut garder à l’esprit que Toyota est une société Japonaise et que par conséquent :

  1. La direction de Toyota semble disposée à transmettre à ses employés une partie du pouvoir de décision (au Japon tout du moins).
  2. Le 1. est vrai car les employés de Toyota (comme une majeure partie des salariés japonais) sont fidèles et dévoués à leur entreprise – de nombreux décès par Karōshi sont d’ailleurs recensés dans ce pays.

Or, si vous avez eu l’occasion dans votre carrière d’observer le clivage Patronat / Syndicats en France, vous comprendrez que :

  1. Les employés des grands groupes semblent souvent éprouver le sentiment d’être exploités, et vont par conséquent être resistants au changement. “On en fait déjà assez pour ce qu’on est payé !”
  2. Les dirigeants des grands groupes ont très souvent l’impression que leurs salariés mettent de la mauvaise volonté à s’adapter ou même à effectuer leur tâche et vont donc accroitre leur surveillance pour être sûrs que “The Job is done”. “Il n’en font jamais assez pour ce qu’on leur donne !”

Je ne blâme ni les uns, ni les autres : il s’agit simplement d’un constat Français et chacun des acteurs a sans doute d’excellents arguments pour penser ce qu’il pense. Il est d’ailleurs remarquable de voir que plus le nombre de salariés augmente, plus cette tension est intense car moins le dialogue entre les deux factions est présent.

Oui mais ! Attendez un peu… Ces grands groupes sont-ils les plus représentatifs de l’écosystème de nos entreprises ?

Si on en croit les chiffres de l’INSEE, pour le secteur “Information et Communication” (en retirant évidement les entreprises sans salariés), il existerait plus de 30 000 entreprises de moins de 200 salariés contre moins de… 400 de plus de 200 salariés…

Ah ben ça alors ! Tiens donc…

Par conséquent, le constat de M. PASOTTI est parfaitement recevable pour 1,3% des entreprises informatique Françaises. Mais pour le reste ? Les 98,7% des entreprises restantes ? Est-il rentable d’utiliser les méthodes agiles ? Personnellement j’aurais tendance à penser que oui, et voici une petite démonstration grâce à une réflexion venue d’un second article.

Ce deuxième article est en effet beaucoup plus intéressant car il touche un cas précis de mise en œuvre d’une méthode Agile : l’eXtrem Programming (XP). Il a été écrit par un “jeune cadre dynamique” Capers Jones. Pour vous situer ce monsieur, c’est un américain spécialiste des prédictions de risques et de la mise en œuvre de “Best Practice” lors des développements de logiciels. Ses références clients sont des grands groupes de l’industrie, de la communication ou de la finance. J’en profite pour vous indiquer qu’il a travaillé dans des “petites” structures à taille humaine comme IBM (tiens ! lui aussi ?!) et ITT. Sa société est d’ailleurs une jeune pousse de 30 ans complètement indépendante des “gros poissons” du secteur vous l’imaginez bien !

C’est donc avec perplexité que j’ai lu son billet : en effet il démontre magistralement que le pair-programming est une pure perte, au mieux de temps, sinon d’argent. Cependant au fil de la lecture, deux choses m’interpellent :

  1. Comme dans le premier exemple, il s’agit de ses clients. C’est à dire de “petites” entreprises de 10 000 développeurs…
  2. Il semblerait que pour ce monsieur, l’utilisation du pair-programming soit binaire : soit tous ses développeurs font du pair-programming en même temps et tout le temps, soit personne n’en fait jamais. Une magnifique illustration du manichéisme américain.

N’importe qui, un tant soit peu doté de bon sens, peut comprendre qu’il est absurde de pratiquer le peer-programming (et par extension les méthodes Agiles) de cette façon. Cela revient ni plus ni moins à appuyer à fond sur l’accélérateur d’une voiture et à incriminer la voiture ou mieux la route et le manque de signalisation en cas d’accident… qui arrivera inéluctablement !

Car voilà le cœur du problème : la réussite ou l’échec ne vient pas de la méthode en elle-même, mais de celui qui a choisi cette méthode et surtout de l’adaptation qu’il en a fait par son degré de maitrise.

Chez IBM, ils ont peut être pensé :

“Allez les gars, on va s’y mettre nous aussi aux méthodes Agiles ! Ça n’a pas l’air compliqué, d’ailleurs les petites start’ups qui bouffent nos client s’y sont mises et s’adaptent bien mieux que nous à leur demande ! Joe, ils utilisent quoi ? Hein ? Scrum ?”.

Du coup, allez, tout le monde au SCRUM ! Ça ne marche pas ?!

“Joe ça marche pas ! On fait quoi ? L’eXtrem Programming ? Allez go ! Passons à l’XP ! Si eux y arrivent, nous aussi on va y arriver aussi !”.

Obvious isn’t it?

Beh oui mais nan : si les gens d’IBM ont vraiment eu cette réflexion (j’espère que non !) ça revient à penser qu’ils pouvaient s’inscrire pour les jeux olympiques pour l’épreuve de saut en longueur sans avoir remarqué qu’ils pesaient 230 kg et qu’il y avait une différence non négligeable entre lire les techniques de courses dans un livre et courir avec ses propres jambes !

Vous n’aurez pas du tout le même investissement à faire pour être champion olympique de saut en longueur si vous êtes déjà sportif, habitué à courir, que si votre inertie corporelle vous empêche de courir et que d’ailleurs vous n’avez aucune idée de comment utiliser ces foutues chaussures à crampons !

Pour gagner, vous devez savoir ce dont vous êtes capable, mais aussi si l’objectif “réaliste” est d’être en finale ou sur la première marche du podium.

À titre d’exemple, en tant que Chef de Projet Agile, je sais que si je laisse mes développeurs toute une journée ensemble leur niveau de concentration va inéluctablement baisser et ils vont finir par parler d’un film ou d’un jeu vidéo (c’est normal !). Donc “connaissant mes développeurs” et ayant repéré “ceux qui savent travailler en binôme sans glander” je peux utiliser le pair-programming avec pertinence et efficacité.

C’est en général le cas quand :

  1. Je n’ai pas d’idée précise de comment résoudre un problème complexe car j’ai en tête plusieurs réponses valides.
  2. Les deux développeurs s’entendent bien (pas de conflits de valeurs entre eux).
  3. Je souhaite que les deux sachent comment a été traité le problème.
  4. Je souhaite que les deux sachent pourquoi le problème a été résolu de cette manière.

Le gain de temps en cas d’indisponibilité d’un de mes développeur pour adapter / corriger la fonction est alors évident et ma société gagne de l’argent car ses employés deviennent “polyvalents” sur les morceaux de code épineux.

Pour le reste du code, la trivialité exclue (en tout cas pour moi) l’utilisation du pair-programming (la trivialité ou la sortie d’une nouvelle version de League of Legends).

En conclusion (et pour parler à nos décideurs) nous pourrions faire l’analogie avec un golfeur expérimenté. Il sait jouer une balle de multiples manières, mais en fonction de la position de la balle et grâce à la parfaite connaissance du parcours, il choisira le club et la technique la plus adaptée en fonction de la situation. Le golfeur amateur se contentera de râler sur la qualité de ses clubs (payés à prix d’or !) sans se remettre un seul instant en cause.

Voilà selon moi deux des axes de réflexion de la rentabilité Agile :

Si vous faites parties des 1,3% du 1er exemple, fuyez les méthodes agiles, car vous faites 230 kg et il vaut mieux concourir pour le plus solide appétit du pays (l’entreprise faisant le plus gros bénéfice) que pour la meilleure performance sportive (l’entreprise augmentant le plus fortement son bénéfice en embauchant des salariés).

De plus, pour que les méthodes Agile soient rentables, vous devez connaitre les techniques Agiles, mais aussi (et c’est tout aussi important) connaitre la société dans laquelle vous êtes : son inertie, ses valeurs, ses clients et ses buts à longs terme car ils peuvent être purement incompatibles avec l’Agilité.

Le monde est fait de diversités et c’est justement là sa richesse !

Article par Matthieu Lallemand