La radicalité comme ligne de conduite
Je me définis volontiers comme quelqu’un de radical. Qu’est-ce à dire ? Pouvons-nous travailler ensemble ?
Les mots ont un sens
Est « radical » ce qui tient à l’essence des choses. La radicalité commence donc par le refus de pervertir une idée. Et pour cela, il suffit généralement d’écouter le mot. Exemple : l’Agilité.
L’agilité désignait, bien avant l’informatique, la capacité à se mouvoir avec aisance. Les pères fondateurs de l’Agilité n’ont pas choisi ce mot par hasard. L’idée était bien de faire émerger de nouvelles pratiques, mieux à même de favoriser cette qualité au sein d’un système d’information. Donc si vous souhaitez absolument faire de l’Agilité en rédigeant un cahier des charges de 1 000 pages, en chiffrant le tout et que vous partez la fleur au fusil pour 2 ans de développement, faites, mes amis, je ne vous retiens pas. Seulement, ne parlez pas d’Agilité. Parlez plutôt d’un « bon projet à l’ancienne, comme on a toujours fait », je survivrai !
Même chose pour le Test-Driven Development. Vous pouvez tordre la chose dans tous les sens, ce n’est pas du Test-First, encore moins du Test-After, ce n’est même pas « écrire les tests en même temps que le code », c’est une pratique de développement. Du développement guidé par les tests. C’est dans le titre.
Même chose pour les pratiques du DevOps : quelqu’un au sein d’une équipe qui ne fait plus que de l’Ops, ce n’est pas du DevOps. Vous passez à côté de la chose, puisque toute l’idée est que la compétence Ops diffuse au sein de l’équipe de Dev. Dites que je pinaille si vous voulez, c’est bien ce que dit le mot lui-même : Dev-Ops.
Non à l’entre-deux mou
La radicalité, c’est donc le refus de la compromission. Je préfère un affrontement d’idées claires, il en sortira toujours quelque chose, pour peu que les conditions du débat soient réunies. Agilité vs. Cycle en V ? Parlons-en ! Dès que l’on agite un peu nos neurones, des nuances intéressantes émergent : 1. Tout dépend du contexte, l’informatique de gestion, ce n’est pas la même chose que l’informatique embarquée ; et 2. Tout dépend de la taille des projets : 1 semaine, ce n’est pas 1 an. Des évidences que l’on entend finalement assez peu.
En revanche, faire du Cycle en V et déguiser cela en « projet agile » (une contradiction dans les termes), c’est s’empêcher de nommer le problème, donc de réfléchir. Autrement dit, c’est du déni. Difficile d’avancer dans ces conditions.
Que dire alors à une équipe qui souhaite vraiment faire du Cycle en V alors que le sujet ne s’y prête pas ? Tout dépend de votre rôle (manager, coach) mais aussi de la criticité du sujet. Dans certains cas, il serait souhaitable de la laisser expérimenter, pour peu que cela ne prête pas à conséquence, et de constater ensemble ce qui sera une erreur… ou pas. Quelqu’un aura peut-être raison, mais ce n’est pas le sujet. L’important est que vous en sortirez tous grandis, car plus instruits.
Discutez, argumentez, expérimentez, tout cela, mais, s’il vous plaît, ne vous vautrez pas dans un entre-deux mou. Par pitié, ne faites pas de sprints au forfait (rien que de l’écrire, je perds des points de vie).
Aller à la source des problèmes
La radicalité, c’est enfin oser se confronter aux causes d’un problème plutôt que de pallier indéfiniment ses conséquences, à la manière des Danaïdes.
Prenez les sujets de qualité : oui, vous pouvez mettre en place une batterie de KPIs d’output, mais vous ne ferez que stresser vos équipes en pointant du doigt le fait que rien ne va (« oui, ça on le sait »). Vous pouvez aussi mettre en place une armée de testeurs, mais leur activité consistera essentiellement à courir après le train, vu que les bugs continueront d’affluer. Ou bien vous pouvez vous attaquer aux causes du problème, c’est-à-dire aux pratiques de développement, de test, et bien avant tout cela à la conception fonctionnelle. Autrement dit, vous ne pouvez pas dissocier le faire et le faire mieux.
En parlant des causes profondes : « On ne résout pas un problème avec les modes de pensée qui l’ont engendré », disait Albert Einstein (citation apocryphe). Cela veut dire que votre culture d’entreprise doit changer, ce qui va parfois jusqu’au changement des personnes. La formation est utile, mais soyons honnêtes : on ne transforme pas un âne en cheval de course… D’autant qu’une personne peut avoir été la personne idoine à un stade donné de l’entreprise, au bootstrap par exemple, et ne plus être à sa place quand il s’agit d’aborder la phase suivante, l’industrialisation. Maintenir la personne dans sa position ne rend service ni à l’organisation, ni à la personne. Je constate assez souvent une forme de fidélité du CEO aux employés qui l’ont accompagné jusque-là, quand bien-même les données du problème ont changé. Cette fidélité, je la comprends, mais je pense qu’elle vous retient.
Un contrat pour nos travaux communs
Radicalité implique donc courage et audace. Audace de viser haut, d’être ambitieux. Si l’on ne cherche pas à faire très bien, on ne cherche pas à faire mieux et on ne cherche plus à faire bien. Non, la perfection n’est pas un gros mot, pour peu que l’amélioration continue vous en rapproche jour après jour.
Cette radicalité est clivante, et c’est pour le mieux : en m’éloignant d’organisations avec lesquelles je ne saurais travailler, elle me rapproche d’organisations saines et réellement désireuses de changer. C’est du temps gagné, pour tout le monde. Disons ainsi que cette radicalité vaut contrat entre nous.