Danger zone

Pitié pour moi, mon Dieu, dans ton amour,
Selon ta grande miséricorde, efface mon péché.
Lave-moi tout entier de ma faute,
Purifie-moi de mon offense,
Pardonne moi, Seigneur, car j’ai péché :
J'ai fait du coaching agile.

Parce que oui, aujourd'hui, mieux vaut ne pas se dire "coach agile" tant l'agilité est devenue ☢ radioactive ☢.

Oh, c'était beau, dans l'idée. C'était même tellement beau que personne ou presque n'y a rien compris.

Ce qui donne (morceaux choisis) :

• "Nous, on est 200% agiles" 🫣
• "Nous, on a pris les bonnes choses de l'agilité" 🤢
• "Nous, on fait de l'agile au forfait" 🤮
• "Nous, on fait des sprints de durée variable" 🤯
• "Nous, on applique la méthode agile" 😭
• "On cherche un chef de projet agile" 💩

Autrement dit, "on met des carrés dans des ronds et on fait comme si tout allait bien". On nage en pleine dissonance cognitive (*).

Quelqu'un qui comprend ce qu'est vraiment l'agilité dira plutôt : "on n'est clairement pas aussi agiles qu'on le voudrait".

Martin Fowler, un des pères de l'agilité, n'était pas loin de dire dans son discours d'ouverture de la conférence Agile Australia 2018 :

Faites ce que vous voulez, de toute façon je m'en fous je pars élever des chèvres dans l'Ardèche.

Donc après avoir jeté le bébé avec l'eau du bain, que reste-t-il ?

Il reste que l'on a toujours besoin d'agilité.

Scoop.

D'ailleurs, je parle d'agilité, mais ça n'est pas mon cœur de métier : mon expertise, c'est l'artisanat logiciel. Seulement, l'artisanat logiciel est indissociable de l'agilité.

Les deux émanent de l'Extreme Programming, invention géniale d'une bande de chevelus dans les années 90. Sauf qu'ils étaient tellement en avance sur leur temps qu'il a fallu attendre le manifeste agile (2001) puis le manifeste de l'artisanat logiciel (2009) pour que la bonne parole commence à porter.

L'agilité et l'artisanat logiciel reposent sur les mêmes raisonnements. C'est par exemple l'importance donnée au feedback :

• On ne veut pas bosser pendant des mois sans feedback utilisateur pour nous dire si l'on va dans la bonne direction (petites itérations) ;
• On ne veut pas bosser pendant 4 heures sans feedback des tests pour nous dire si le code fonctionne comme prévu (Test-driven development).

Et puis la spécification fonctionnelle…

Parlons seulement de l'example mapping, pratique phare du Behavior-driven development (BDD). L'example mapping, c'est une façon simple et efficace d'améliorer la qualité de la spécification fonctionnelle en redonnant de l'importance aux exemples. Car c'est bien connu : le diable est dans les détails.

Les exemples nous forcent à être concrets et à explorer tous les recoins de la spécification sans attendre le développement. Ils suscittent la discussion. Ainsi, on évite bien des allers-retours par la suite. Ultérieurement, ces exemples servent de tests d'acceptance, c'est-à-dire de contrat entre le product owner et le développeur.

Alors, est-ce une pratique de l'artisanat logiciel — ainsi qu'on la présente généralement — ou bien une pratique agile ? Peu importe : dans tous les cas il faut bien travailler la qualité de la spécification.

Ceci pour dire que le coaching technique empiète nécessairement sur l'agilité. Après, on le dit ou non. Pour ma part, je ne le dis plus vu que l'agilité sent le soufre, et je fais du coaching agile en loucedé. 😂

À la semaine prochaine 👋 !

(*) Et si vous avez des doutes et vous demandez : "pourquoi ?", j'ai créé une formation spécialement pour vous : L'Agilité au Marteau.