L'agilité de démonstration

 Dans le cadre de mon travail, j’ai eu la chance de voir une grande organisation tenter un virage vers l’agilité. Je ne donnerais pas le nom de l’organisation, mais elle fait partie du gouvernement québécois. Décision précise par les hautes sphères, le virage agile a été planifiée en bonne et due forme : en utilisant la méthode cascade. Les dirigeants se sont rencontrés, ont planifiés un échéancier et des dates de mise en place et l’agilité était prête à être mise en place!

 Ils ont engagés une escouade de coach agile, ceux-ci ont préparés quelques activités, chaque équipe a eu droit à un tableau et plusieurs post-it et nous étions maintenant agile! Un scrum 2 fois par semaine et on se tapait dans le dos, l’organisation avait réussi son virage! J’ai personnellement beaucoup de misère avec cette vision, on a adopté l’agilité parce que c’était dans l’air, on l’a fait de façon superficielle et on se félicite de notre efficacité par la suite.

 Il semblerait que l’agilité est simplement un mot clef que l’on peut ajouter aux offres d’emplois sans vraiment comprendre ce que ça représente. L’équipe ne retire qu’une fraction des avantages de l’agilité présentement, maintenant tout le monde sait sur quoi tout le monde travaille. C’est définitivement un gros point dans une organisation ou le silo était maître! Mais on s’est arrêté bien avant d’en retirer les vrais bénéfices. Le client ne reçoit pas plus de fonctionnalité, la qualité du code n’est pas améliorée, les changements sont toujours aussi difficile à apporter. Certe, une requête est maintenant bien visible, mais elle est loin d’être réalisé. L’organisation maintient son pipeline de développement et on livre toujours deux fois par semaine le mardi et le vendredi. Si on veut monter en production, il faut prévoir le mercredi de la semaine précédente le déploiement pour la semaine suivante.

 Je ne doute pas que l’intention était bonne, et je crois qu’ils ont tous (j’espère!) lus le manifeste agile. Mais on a appliqué l’agilité comme si c’était une recette de gâteau sans se poser plus question. Passons ensemble le manifeste et voyons comment se positionne l’organisation aujourd’hui (5 mars 2020).

Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu’une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

 Il va s’en dire que le gouvernement tient mordicus à ses processus et ses outils. Même si une simple discussion pourrait avancer rapidement une situation, il est obligatoire de passer par un système de gestion de demande et attendre que chaque personne accepte la demande et fasse son petit bout de chemin. Vous avez un problème avec une partie de l’architecture qui devrait être changer? Un simple ajout d’une interface peut-être? Il faut que vous passiez par une requête à l’équipe d’architecture, et vous aurez probablement une réponse dans la prochaine semaine.

 La documentation est maître dans l’organisation. Comme je le disais précédemment, une personne va voir le client et prend en note les besoins, elle écrira ensuite un document exhaustif avec un guide précis de la demande du client. Cette demande ira à l’architecture qui jugera le comment, elle produira une documentation puis la passera à l’analyste fonctionnel. Celui produira ensuite un document fonctionnel, ce document sera approuvé par le client et retourner un développeur pourra alors coder la solution. Après toute cette chaîne, quelqu’un pourra enfin écrire quelques lignes de code! Bien sûr, il y a un document de test à écrire! On est bien loin du logiciel opérationnels avant une documentation exhaustive!

 Je ne crois pas qu’il soit nécessaire que j’ajoute plus d’information sur le troisième point du manifeste, l’ensemble du développement tourne autour d’un document contractuel avec le client.

 Finalement, l’organisation se base et roule sur une planification. Il va s’en dire que cette planification est inefficace, plusieurs projets considérés comme les pires gaffes informatiques le prouvent : SAGIR, RVSQ et Phoenix en sont des bons exemples. Mais de l’intérieur, c’est encore pire! Une multitude de petits projets sont complètement manqués et hors budget, ils ont toutefois l’avantage de ne pas se rendre jusqu’au média.

 En conclusion, est que notre tableau Kanban d’équipe nous a rendu agile? Définitivement pas, on a adopté une méthode sans adopté l’idée.

On a adopté l’agilité superficielle. Nous sommes agiles.