Dans un précédent article, nous avons vu que créer un produit logiciel n’était pas compliqué… Et que par conséquent les méthodologies inspirées des industries lourdes et du BTP ne sont pas parfaitement adaptés. Nous ne sommes pas obligés de rester sans repère pour autant. Je vous propose un concentré d’agilité, 3 principes qui vous serviront de mini guide, de motto, voire de credo. Oui, oui, j’ai bien dit 3 principes et non 4 valeurs. Lesdits principes sont inspirés des travaux de Simon Powers.
En toute modestie mais surtout pour le jeu de mot, je me permets de les regrouper sous le terme Agile Manifesto Essence. AME donc !

Principe de complexité

La première chose à faire c’est de se souvenir, comme on l’a déjà vu, que créer un logiciel est une situation qui n’est certes pas compliquée mais qui reste complexe. Et même complexe et adaptative.
Cela signifie que chercher à apporter une solution à cette situation va la modifier. Il est donc impossible de prévoir les résultats de nos actions à l’avance. On ne peut établir de liens causes-conséquences qu’a posteriori. Quand j’obtiens quelque chose, je peux établir que c’est le fruit d’une action que j’ai réalisée au préalable. Il est impossible de procéder en sens inverse.
Par conséquent, les planifications très fines, les estimations utilisant des règles lourdes de calcul, et les engagements à très long terme sont peu adaptées au processus de création d’un logiciel. Les prédictions dans une situation complexe telle que celle-là sont peu fiables.

Principe de proactivité

Si faire quelque chose modifie le problème, on pourrait être tenté de ne plus agir en se disant que ça ne sert à rien. Mais c’est oublier que ce n’est pas parce qu’on a pas obtenu le résultat escompté ou que le problème s’est modifié qu’on n’a pas accompli quelque chose ou qu’on n’est pas arrivé à créer une situation intéressante.
C’est exactement ce que notre deuxième principe met en avant. Il s’agit du principe de proactivité.
Même si la proactivité, telle que définie à l’origine par Viktor Frankl, comporte un volet sur l’appréhension des risques, ce n’est pas pour autant le fait de faire des actions par anticipation. Ce n’est donc pas l’opposé de la réactivité.
La proactivité consiste bien en la réalisation d’actions pouvant être faites après un événement (en réaction, donc) mais visant toujours à tirer le meilleur parti d’une situation, voire à tenter d’en extraire une occasion intéressante qu’il s’agisse d’une menace ou non à l’origine.
La proactivité n’est possible que si on dispose de la liberté de choisir. Elle nécessite du courage et de la volonté et surtout que l’on soit conscient de ses responsabilités.

Principe de personnes

Ces qualités, ce sont surtout ceux qui agissent qui doivent en être munis. C’est le troisième et dernier principe : le principe de personnes.
« Ce sont ceux qui font qui savent ». C’est comme cela que je le résumerais. Cela signifie que ceux qui sont sur le terrain, dans le feu de l’action, sont les mieux placés pour prendre les décisions les plus adaptées, pour savoir quelles qualités, talents, ressources sont nécessaires, etc. Ces personnes vont faire les meilleurs choix parmi les possibilités qu’ils entrevoient. Il n’y a donc pas de personne malfaisante, souhaitant que la création du produit logiciel ne réussissent pas pour le simple plaisir de la faire échouer.
Il est néanmoins important de garantir les conditions idéales pour que les personnes expriment leur plein potentiel et leurs pleines capacités. Il faut notamment satisfaire au maximum leurs besoins de base (au sens analyse transactionnelle surtout).

On pourrait facilement se prêter au jeu des correspondances entre ces trois principes de l’AME et les 4 valeurs du Manifeste Agile (l’original, donc) ainsi que ses 12 principes sous-jacents. On vérifierait ainsi que tout ce qui est dans le Manifeste Agile peut être rattaché à un des 3 principes de l’AME ou à une combinaison de ceux-ci. D’où le surnom d’essence, voire de quintessence du Manifeste Agile que je me suis permis d’accoler à ces principes.
Certains sont même allés plus loin dans l’esprit de resserrement du manifeste et pensent qu’on peut condenser l’agilité en un seul principe ! C’est le cas de Michael Sahota et de Alexey Krivitsky.

Retenir ces 3 principes est bien plus simple (et efficace; d’après moi en tout cas) que de mémoriser les 4 valeurs et les 12 principes du Manifeste Agile original. Garder en tête et respecter ces 3 principes permet de créer un produit logiciel de la meilleure façon possible.

Mais outre cette facilité de mémorisation qui nous rappelle à quel point les fondements de l’agilité sont simples et pleins de bon sens, outre la beauté de l’exercice de réduction quasi mathématique du Manifeste Agile, suffisant, certes, en une version nécessaire, c’est surtout la mise en lumière d’angles d’approches différents de ceux utilisés habituellement qui constitue l’intérêt premier de L’AME. Prenons ce premier exemple : la mise en oeuvre des 3 principes (surtout des deux derniers) n’est pas forcément aisée. Mais leur énoncé permet de définir assez rapidement les contours d’un rôle d’accompagnateur agile spécialisé tel que construit ici.