Au commencement…

Pendant près d’une décennie, j’ai eu le privilège de travailler pour IS2, une petite PME composée de deux personnes à mon arrivée et de six à mon départ. IS2 se spécialisait dans le domaine de l’informatique et de l’électronique en milieu industriel. Mon principal projet au sein de cette entreprise a été le développement et le déploiement d’une solution de traçabilité de fabrication appelée IsTrac, destinée au groupe L’Oréal. Cette solution permettait de tracer les différentes étapes de fabrication, de communiquer avec des automates, d’afficher les instructions pour les opérateurs, de générer des rapports, de calculer les rendements et d’automatiser le processus de fabrication.

Au cours des premières années, nous n’avions pas de méthodologie de planification ou de suivi de projet structurée ; nous travaillions au jour le jour en nous basant sur des cahiers des charges. Cependant, au cours de mes trois dernières années chez IS2, j’ai eu l’opportunité de découvrir l’agilité à travers diverses lectures, notamment sur l’Extreme Programming et le Scrum (eXtrem Programming, Scrum et XP à partir des tranchées, …). À cette époque, nous faisions face à des défis de planification liés à l’expansion de l’équipe et à l’acquisition de nouveaux contrats. Malgré ces défis, nous avons connu une croissance significative grâce à notre expertise et à la qualité de notre solution IsTrac.

C’est dans ce contexte de croissance et de remise en question que j’ai estimé qu’il était crucial pour nous d’adopter de nouvelles pratiques.

En avant marche !

Après réflexion, j’ai entrepris de travailler sur différents aspects de notre environnement professionnel.

Tout d’abord, j’ai décidé de migrer notre contrôleur de source SVN vers TFS, ce qui offrait une meilleure intégration avec Visual Studio ainsi que des fonctionnalités supplémentaires. En équipe, nous avons pu décider de notre nouvelle stratégie de versioning. Nous avons travaillé sur des branches, modifié les numéros de version et créé des “About box” cohérentes. Désormais, nous pouvions identifier une version en production, corriger un bug et redéployer en toute confiance. Cette migration nous a débarrassés d’un poids considérable : nous disposions désormais d’un contrôleur de source fiable.

Ensuite, pour notre équipe de support, j’ai installé Bug Tracker .Net et je l’ai personnalisé pour répondre à nos besoins spécifiques. Rapidement, nous avons pu centraliser une liste de problèmes, les prioriser et travailler sur les correctifs. Une fois les correctifs apportés, nous étions en mesure de fournir au client un changelog lors de nos mises à jour. C’était un autre pas dans la bonne direction.

La situation de crise s’étant stabilisée, nous avons pu envisager de nous attaquer aux problèmes de planification. Après de nombreuses recherches et expérimentations d’outils, nous avons décidé d’opter pour Ice Scrum. À l’époque, nous ne disposions ni de l’infrastructure ni des compétences nécessaires pour déployer un serveur TFS/Sharepoint. IceScrum, le produit de Claude Aubry, était simple à installer, visuel, réactif et gratuit. Les premières rédactions des user stories ont été difficiles, mais nous nous sommes accrochés et avons persévéré. Après quelques sessions, nous avons obtenu un premier product backlog ; certes, il n’était pas parfait, mais il avait le mérite d’exister.

Tel des apprentis Jedi, nous avons essayé de maîtriser les premières cérémonies Scrum : l’évaluation et la priorisation. Bien que de nombreux ouvrages, articles et retours d’expérience nous aient appris comment mener une réunion d’évaluation du product backlog, aucun ne nous indiquait comment bien choisir un jalon ni évaluer sa complexité (voici ma réponse : La face cachée du planning poker). Pour ce qui est de la priorisation, nous nous basions sur notre expérience terrain. Malheureusement, nous n’avions personne pour endosser le rôle de client/product owner, notre patron préférait observer de loin tout en nous laissant faire.

A vos marques, prêt… partez !

Notre première cérémonie de sprint planning a été un peu inhabituelle. Avec un backlog établi et du travail à répartir entre trois développeurs, chacun a pris la souris à tour de rôle pour sélectionner les user stories que nous avions priorisées et qui nous concernaient personnellement à partir du backlog IceScrum. Cela peut sembler étrange pour un travail d’équipe, mais cela a fonctionné…

Chaque matin, nous nous sommes réunis autour du tableau virtuel d’IceScrum pour mettre à jour l’état de nos tâches. Cette réunion quotidienne nous a permis de partager notre progression avec les autres membres de l’équipe. Le responsable du support en a également profité pour nous exposer les problèmes en cours, ce qui nous a permis de synchroniser nos efforts pour la journée. Au fil du temps, nous avons remarqué une évolution des comportements : une entraide volontaire et spontanée s’est développée en cas de blocage chez l’un des collègues. L’appropriation du code s’est renforcée, se manifestant par un partage naturel des tâches. Selon nos affinités et notre charge de travail, nous pouvions choisir sur quoi travailler. Nous avons enfin découvert ce que signifie véritablement travailler en équipe.

« Nous n’étions plus 4 équipes de 1 membre, mais une équipe de 4 ! »

Don Quichotte contre les moulins à vent.

Malgré le manque d’intérêt de notre hiérarchie, l’équipe était pleine de volonté et nous avons persévéré dans notre démarche agile. Bien que cela ait été un défi de maintenir notre motivation, nous avons réussi à rester concentrés sur nos objectifs.

J’ai été étonné de constater qu’au sein d’une PME, l’adoption d’un système de planification soit négligée. Pourquoi ne pas donner la priorité à l’établissement d’une simple liste de tâches ? Pourquoi ne pas essayer de réduire les perturbations extérieures ? Il est crucial de comprendre que ces actions sont essentielles pour atténuer la frustration et l’anxiété au sein de l’équipe. En dépit des obstacles, nous avons maintenu notre détermination à progresser vers des pratiques plus efficaces et plus collaboratives.

Jetons un œil dans le rétro.

Lorsqu’une démarche itérative est entamée, il est fréquent d’être déçu par le nombre de user stories planifiées mais non réalisées à la fin des premiers sprints. Pour comprendre les raisons de ces difficultés, il est nécessaire de prendre du recul, d’analyser les causes sous-jacentes et d’identifier les goulots d’étranglement ainsi que les perturbations internes ou externes, afin d’en tirer des enseignements.

Dans notre cas, les raisons étaient claires. Dans le passé, faute de planification à court terme, nous étions constamment réactifs aux demandes spontanées du client ou du patron. Qui n’a jamais été interrompu par son supérieur, lui fournissant une description sommaire d’une tâche et demandant un délai de réalisation à la va-vite, avant de promettre des résultats au client ? Le principal problème résidait dans l’ajout de tâches non planifiées au tableau au fil des semaines. De plus, les analyses d’impacts étaient souvent inexistantes ou réalisées de manière superficielle, ce qui rendait impossible la planification et le suivi des user stories.

Bien que le patron ait pris la peine de lire sur l’ eXtrem Programming, il refusait de participer à nos réunions de planification, arguant que c’était une perte de temps. Son attitude vis-à-vis de notre tentative d’améliorer notre processus était paradoxale : d’une part, il refusait de prioriser notre backlog produit et nous laissait passer des heures à planifier le sprint, et d’autre part, il imposait ses propres priorités en cours de route. Malgré tout, il nous laissait faire, et peut-être que c’était là l’aspect le plus important !

The end !

La tentative d’introduction de principes agiles s’est soldée par ce que je qualifierais de “SucChèc” (à mi-chemin entre l’échec et le succès). Bien que je ne puisse prétendre que la méthode Scrum ait été correctement implémentée, après mon départ, il en est quand même resté de très bonnes choses. Il est vrai que mes anciens collègues subissent toujours des perturbations dans leur cycle de travail quotidien, mais ils ont maintenu bon nombre de nos nouvelles pratiques. Peut-être devrais-je les revoir pour savoir s’ils continuent à s’améliorer…