Articles

L’agile ? Cela ne marche pas…

Je sors d’une réunion avec un éditeur de logiciel qui cherche à comprendre pourquoi chez lui “L’agile cela ne marche pas”. Cet article est la reformulation de sa demande et de mes premières observations, je le publie avec son autorisation en ayant enlevé les éléments personnels.

Le contexte

J’ai rendez-vous dans un incubateur de Sophia Antipolis avec Didier qui est à la tête d’une startup et qui développe un logiciel depuis plus de 3 ans. Il a décroché un premier financement et il a une jolie équipe de 9 développeurs. Par le biais d’une connaissance commune il m’a appelé pour me dire : “J’ai commencé à développer mon logiciel seul, puis pendant 1 an avec 2 développeurs, dans cette période tout marchait bien. On a sorti un proto, cela nous a permis de faire une levée de fonds et d’embaucher le reste de l’équipe. Je n’ai pris que des développeurs qui travaillent en mode agile.”

La formulation du besoin

Comme je n’ai plus de temps de faire du développement, mon premier développeur est devenu “Chef de projet”, il m’a dit que dans l’équipe tout le monde n’avait pas la même définition de l’agile et que cela créait des frictions. J’ai débloqué un budget et j’ai fait venir un formateur agile (d’une société connue !). J’ai laissé quelques mois pour que cela se mette en place, mais c’est de pire en pire. On me sollicite tout le temps pour arbitrer les choix de développement et surtout pour gérer les problèmes d’ego et de relations entre les développeurs. Je vais devoir remplacer le chef de projet car d’une part il ne comprend rien au produit et que d’autre part toute l’équipe est contre lui.

La semaine dernière j’ai déjeuné avec Gilbert (notre connaissance commune), je lui ai parlé de mes soucis et il m’a dit “Contacte Romain de ma part, il pourra t’aider…”.

La discussion

Romain : Qu’appelles-tu agile ? sais-tu qu’il existe plusieurs méthodes agiles ? sais-tu quelle méthode a été mise en place ?

Didier : Je ne sais plus le nom exact, mais ils font une réunion tous les matins et c’est avec la méthode des post-it ? Si tu veux j’ai les supports de cours on peut regarder…

Romain : non, je crois que cela va aller. Scrum, cela te dit quelque chose ?

Didier : ben oui, c’est ça, Scrum, agile en français, c’est la même chose. Moi je préfère en français…

Romain : En fait il y a deux choses dans “agile” :

  • Un état d’esprit, une façon d’envisager les relations : dans le jargon on dit “Le manifeste agile”. Il faut bien savoir que c’est la partie essentielle et que cela tu dois le partager avec ton équipe. On reviendra là dessus en détails !
  • La méthode (au sens technique de méthode), c’est à dire les protocoles qu’on va utiliser, en jargon on dit “les cérémonies”. Scrum c’est une des méthodes, il y en a d’autres, on ne va pas entrer dans les détails. Pour la taille de ton équipe et ce que vous avez à faire, Scrum est sans doute ce qui est adapté.

Didier : J’ai compris, de toute façon je suis quelqu’un d’agile, je percute vite et je m’adapte. Je pense que je vais facilement insuffler cet état d’esprit à l’équipe et que cela va résoudre les petits problèmes relationnels. Tu m’organises un Team building pour çà ? Et pour la méthode de travail ? Tu regardes comment ils font ? Je fais une formation avec une autre boîte ? Tu en connais une ? Et tu connais un bon chef de projet ?

Remarque pour le lecteur : vous l’avez compris, Didier veut que cela aille vite, son cerveau va à 1000 à l’heure, pas moyen d’en placer une. De toute façon il capte tellement vite qu’il sait déjà tout, il a son plan. Presque, il me dit : “merci de m’avoir donné le seul élément qui me manquait, combien je te dois et je vais me débrouiller”…

Romain : Didier, on a bien avancé aujourd’hui, je vais résumer cela et te faire mes remarques. Sache déjà que l’agilité et notamment le manifeste agile c’est un peu différent de ce que tu entends par “agile” et que cela va beaucoup plus loin. On va travailler là-dessus en premier. Je reviens vers toi dans quelques jours. Ha oui ! ne vire pas tout de suite donc chef de projet, c’est normal qu’il ne s’en sorte pas ! Tu comprendras cela plus tard.

Conclusion

On arrive à la conclusion de l’article et non à la conclusion de mon intervention chez Didier.

Former ses équipes aux méthodes agiles ne pose pas de problème particulier, cela est très bien accepté par les équipes qui sont la plupart du temps demandeuses. Mais, là n’est pas l’essentiel ! Il convient de préparer et d’adapter l’entreprise et le management à ce nouvel esprit ! De façon étonnante, si ce préalable est souvent évoqué, rares sont les formations spécifiques à ce sujet… Chez Aldibo… cela existe ! N’hésitez pas à nous contacter !

Communiquer avec un développeur

Cette image circule sur les réseaux et dans la plupart des cas elle fait rigoler. Mais, peut-on aller plus loin dans l’analogie avec la liste de courses ?

Pour le client (ici la maman) cela semble clair, elle voulait une bouteille de lait et six œufs.

L’informaticien a bien compris que le client veut du lait et il fait une fonction qui retourne du lait. Le nombre retourné dépendant d’une condition externe qui est la présence des œufs. Normalement on demande à un développeur de coder une chose à la fois, ce résultat est donc logique.

Le besoin est mal spécifié et le chef de projet ou le scrum master (qui n’existent pas dans le cas présent) n’ont pas fait leur travail (clarifier, reformuler, …). Si bien qu’on aurait aussi pu livrer 6 œufs et pas de lait (S’il y a des œufs prend en 6 et ne prend pas de lait).

Toi l’informaticien, tu dis que c’est la faute du client…

Vous me direz que dans le cas présent 99,99% des enfants auraient compris la demande de la maman (suis-je naïf ? ce n’est pas prouvé scientifiquement)… disons la plupart, sinon il y aurait peu de moqueurs sur les réseaux sociaux.

Je dois avoir des enfants dans les 0,01% (normal c’est des enfants d’informaticien), les miens auraient probablement rapporté : 1 bouteille de lait, 3 œufs et 1 kg de farine… Je sais, c’est des génies, ils ont compris que maman voulait faire des crêpes (ils aiment les crêpes) et qu’elle avait oublié la farine. Probablement qu’ils vont avoir une désillusion quand on leur dira que “non, ce n’était pas pour faire des crêpes, tu dois faire ce qu’on te demande ni plus ni moins”.

Autre cas courant : l’enfant ramène : 1 bouteille de lait, 2 œufs et un paquet de gâteaux. La maman demande : “mais pourquoi tu n’as pas ramené 6 œufs ?”, la sale gosse répond : “sinon je n’avais pas assez d’argent pour payer les gâteaux”.

Conclusion(s)

  • Il y a plusieurs types d’informaticiens.
  • Les clients ne spécifient pas toujours correctement leur besoin.
  • Le mieux est l’ennemi du bien : il ne faut pas supposer un besoin et faire plus que ce qui est requis.
  • On peut avoir compris un besoin et faire n’importe quoi, même en respectant le budget.