Agile, autonomie des devs et coaching

L’autonomie des devs est un sujet central dans l’agile.

On le croise de manière directe ou indirecte dans les différents manifestes, par exemple dans la place donnée aux personnes plutôt qu’aux process.

L’idée est grosso-modo que donner plus d’autonomie aux devs permet d’obtenir de meilleur résultats pour l’équipe.

Cette autonomie peut se présenter de différentes façons, par exemple organisation des tâches, manière de travailler ensemble, ou choix des outils.

Pour chacun de types d’autonomie, il s’agit de trouver des justification pour légitimer une liberté donnée.

Les discussions autour de l’artisanat logiciel en sont un bon exemple : en mettant en avant l’importance des outils et donc l’importance de choisir les bons outils pour le bon usage, cela peut permettre aux devs de choisir leurs propres outils.

En effet dans beaucoup d’organisations, le fonctionnement par défaut est d’essayer de limiter autant que possibles toutes les marges de manœuvre des personnes vues comme faisant un travail d’exécution, dont les devs font souvent partie.

Les raisons sont multiples : parce qu’on pense que le système sait mieux que les personnes, parce que des devs autonomes vont être plus difficiles à manager…

À l’inverse les personnes ressentent durement les limites qu’on leur impose quand on leur demande de travailler vite et bien tout en les empêchant de prendre les décisions qui leur permettraient de le faire.

Avoir de l’autonomie dans ces organisations est parfois comme un rapport de force constant : à chaque fois que nécessaire il faut pouvoir justifier ces espaces, pour qu’ils ne soit pas repris.

Parfois il est possible d’être tranquile plus longtemps ce qui permet de peut souffler, mais souvent c’est une épée de Damoclès qui menace toujours et qui consomme en permanence une partie de l’énergie de l’équipe.

Dans cette optique, le coaching agile peut être vue comme un paradoxe : commandité par un management pour “agilifier” une équipe, l’agile consiste à essayer de dégager une zone d’autonomie pour cette équipe, aux dépends de ce dont ce même management a envie.

Il faut donc argumenter, s’appuyer sur les buzzword du moment, justifier, pour permettre à des personnes de mieux travailler et donc pour le bien de l’organisation.

La solution de facilité est de se concentrer sur les “pratiques agiles”.

C’est à dire des pratiques inventées par des équipes qui avaient (de ce qu’on dit) cette liberté et qui, en expérimentant, ont pu trouver de nouvelles manières de faire les choses.

Copier ces pratiques de manière directive, ce n’est pas rendre agile, mais cela peut permettre de prétendre le faire.

Malheureusement cela fonctionne : cette approche peut donner des résultats, c’est-à-dire que des pratiques agiles peuvent améliorer les choses même dans un fonctionnement qui ne l’est pas.

Par exemple le fait de mettre en place des itérations plus courtes ou des rétrospectives va améliorer les choses dans un projet en cascade.

Ma conviction est que ces résultats sont limités par rapport à ce que l’autonomie pourrait permettre d’atteindre, mais ils peuvent être suffisants pour déclarer victoire : on a réussi on est agile !

Tout serait plus simple si l’agile était un tout ou rien (≧Д≦) !

Je ne peux pas jeter la pierre à ces coach·e·s : leur travail améliore souvent les choses, et je comprends très bien ne pas vouloir travailler dans une situation aussi compliquée.

Une fois le coaching terminé, la solution est de recommencer le bras de fer pour grappiller un peu d’espace, au moins temporairement.

La succession des manifestes agile correspond à un cycle :

Et ça fonctionne : petit à petit des espaces se créent, ça ne va pas toujours très vite, et parfois on régresse, mais ça avance malgré tout.

Si vous êtes frustré·e·s, peut-être est ce le signe qu’il est temps d’écrire le prochain manifeste ?