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 (Bâtiment et travaux publics) ne sont pas parfaitement adaptées. Nous ne sommes pas pour autant obligés de rester sans repère.

Je souhaite vous proposer un concentré d’Agilité : trois principes qui vous serviront de mini-guide, de devise, voire de credo. Oui, oui, j’ai bien dit trois principes et non quatre valeurs. Lesdits principes sont inspirés des travaux de Simon Powers. En toute modestie, mais surtout pour le jeu de mots, 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. Nous ne pouvons é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és au processus de création d’un logiciel. Dans une situation complexe telle que celle-là, les prédictions sont peu fiables.

Principe de proactivité

Si faire quelque chose modifie le problème, nous pourrions être tentés de ne plus agir en nous disant que cela ne sert à rien. Mais c’est oublier que ce n’est pas parce que nous n’avons pas obtenu le résultat escompté ou que le problème s’est modifié que nous n’avons pas accompli quelque chose ou que nous ne sommes pas arrivés à 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 à l’origine d’une menace, ou pas.

La proactivité n’est possible que si nous disposons de la liberté de choisir. Elle nécessite du courage et de la volonté et surtout que nous soyons conscients 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, même 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éussisse 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 de l’analyse transactionnelle surtout).

Nous pourrions facilement nous prêter au jeu des correspondances entre ces trois principes de l’AME et les quatre valeurs du Manifeste Agile (l’original) ainsi que ses douze principes sous-jacents. Nous vérifierions ainsi que tout ce qui est dans le Manifeste Agile peut être rattaché à un des trois principes de l’AME ou à une combinaison de ceux-ci. D’où le nom 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 trois principes est bien plus simple (et efficace; d’après moi en tout cas) que de mémoriser les quatre valeurs et les douze principes du Manifeste Agile. Garder en tête et respecter ces trois 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 trois 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é. J’aborderai ce sujet dans un prochain billet.

Gaël Rebmann

L’Agilité, Gaël est tombé dedans, comme (presque) tout le monde, quand il était enfant. Puis, comme (presque) tout le monde, il l’a oubliée. Dans son cas, c’était pour la remplacer par des langages de programmation et des patrons d’architecture informatique. On lui a même décerné un diplôme d’ingénieur pour ça…

Puis, un jour, il a décidé de remettre cette Agilité infantile en avant dans son travail : il est devenu Scrum Master et, rapidement, Coach Agile. Il utilise le biais ludique pour aider les individus et les organisations à appréhender les notions inhérentes à l’Agilité. Il est persuadé que le jeu, méthode préférentielle des plus petits pour apprendre, devrait redevenir naturel chez les plus grands. Il devient le « FNU Coach », parce que « Fun Sheriff » était déjà pris. Il consacre du coup un blogue (https://thefnublog.com/) aux jeux agiles et autres métaphores professionnelles amusantes.

Ayant coaché des équipes chez de petits éditeurs ou au sein de grands groupes, en France et au Canada, Gaël est capable de s’adapter à tous les profils de joueurs, quelle que soit leur culture (d’entreprise ou personnelle).

Billet précédent

Quatre postures d'aide pour les coachs

Billet suivant

Équipes Agiles sous tension : Établir la confiance

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.