Apprendre + Équipe = Programmes


Météo du jour - Un frein aux nouvelles pratiques ?

Bonjour, c'est la météo du jour. 

Caen:      ☀️   +14°C
Lille:     ⛅️   +16°C
Marseille: 🌩   +24°C
Paris:     🌦   +18°C
Toulouse:  🌦   +20°C

En ce moment il fait beau à Caen, profitons en !

----

Ce matin, j'ai lu un post sur LinkedIn qui listait des raisons classiques pour ne pas écrire de tests unitaires, par exemple :

C'est intéressant comme partage, et j'ai pu (rarement) l'entendre, mais d'une part je trouve les formulations un peu accusatrices. Elles me donnent l'impression que des individus se braqueraient de manière irrationnelle ou provocatrice contre une bonne pratique qui n'attendrait qu'à être appliquée. Et d'autre part, en tant que Tech Lead ou Coach Technique, même si j'entends parfois des remarques qui peuvent ressembler à ce qui est dit, ce que j'observe en majorité est assez différent.

Le frein le plus important que j'observe là où j'interviens, c'est en extrapolant un peu pour rendre visible certains points :

On voit bien comment faire sur de petits exercices mais on ne sait pas faire sur notre code. Et comme on est déjà très stressés par les deadlines qui s'enchaînent et qu'on n'a pas assez de temps pour faire tout le travail qu'on a déjà à faire, on se sent débordés et c'est très compliqué pour nous d'expérimenter une nouvelle pratique dont on ne sait pas si elle va fonctionner dans notre contexte ni en combien de temps.

Dans cette situation c'est psychologiquement très compliqué de faire l'investissement collectif d'apprendre une nouvelle pratique, d'autant plus que souvent personne n'a vu faire et personne ne sait faire.

De mon point de vue le problème est systémique et concerne plus que l'équipe, et la réaction de l'équipe est plutôt à interpréter comme "on est en mode survie, et donc on préfère fonctionner comme on sait faire car on n'est pas certains de pouvoir survivre d'une autre façon". Avant de changer quelque chose c'est un point à bien évaluer et à prendre en compte car si on ne change pas le contexte de l'équipe, on risque d'ajouter du stress en plus de celui déjà présent.

Ça m'évoque une citation de Virginia Satir que j'aime relire de temps en temps :

I have such respect for the status quo because I know that it’s in the status quo where people are sensing the familiar, and therefore they are feeling they can survive. Whatever the price is, I can still survive. No matter how many times I need to get beaten, or how much I can’t eat, or whatever: I’m surviving. And if I don’t know what else is around, I’m going to cling to that.

When we start in the process of change, we encounter resistance. Resistance is our friend. Resistance says: I want to live. To break down resistance is to court death. So what do we want to do with resistance? First of all to hear it respectfully. This is the personality or ourselves telling us: we don’t know any other way to live yet. And therefore we want to respect this. As leaders of the change process, we want to find a way of encompassing resistance as a survival factor, and move into some new way to survive without the resistance.

Quand je prends en charge un process de changement, j'ai la responsabilité de proposer et d'expliquer une nouvelle façon de fonctionner. Si des personnes refusent le changement, en général elles ne le font pas par provocation ni par manque de rationalité. En tant que personne qui propose le changement, c'est ma responsabilité d'écouter ces freins et de proposer quelque chose qui convient au contexte et aux personnes. Parfois ça demande du temps et beaucoup de curiosité de ma part.

S'ajoute à ça le fait qu'apprendre une nouvelle pratique, comme l'écriture de tests unitaires par exemple, s'inscrit dans une liste de priorités : si on investit collectivement du temps et de l'énergie dans cet apprentissage, ça nous retire du temps pour faire autre chose, qui est potentiellement tout aussi important. Donc même si personnellement je pense que c'est très souvent une bonne idée d'investir ce temps d'apprentissage, c'est aussi ma responsabilité d'expliquer pourquoi je pense que c'est une bonne idée, et d'aider l'équipe à choisir si cet investissement est opportun pour elle maintenant, en fonction de tout ce qu'elle a à faire par ailleurs. Souvent, le ressenti collectif c'est que "on n'a jamais le temps." Mais même si le ressenti se ressemble souvent, les raisons de ce ressenti ne sont pas toujours les mêmes. Alors peut-être, par exemple, questionner pourquoi dans ce contexte donné on n'a jamais le temps ? Ou bien tenter de faire entrer dans l'équation le coût de ne pas poser de tests unitaires ?

Pour finir, en tant que coach ou tech lead, quand je vois l'équipe au complet, incluant le management et le pouvoir de décision, décider d'améliorer leurs pratiques et d'y consacrer du temps, mon intervention se passe beaucoup mieux de tous les points de vue. Même si parfois on ne peut pas faire mieux qu'une initiative individuelle qu'on peut réussir à rendre contagieuse grâce à de bons résultats, en mode bottom-up.

Pour ces raisons, je préfère m'intéresser à la question de qu'est-ce qui freine au niveau collectif ou systémique, plutôt que de recenser des freins individuels comme "Les bugs en prod c'est mon kif, surtout avec le client au bout du fil un samedi".

Fin.