Quand le changement semble nécessaire…

      Commentaires fermés sur Quand le changement semble nécessaire…

Au commencement…

IS2 petite PME de deux personnes à mon entrée en service et de 6 à mon départ. IS2 est spécialisé dans l’informatique et l’électronique en milieu industriel. Durant près d’une décennie, j’ai travaillé au développement et déploiement d’une solution de traçabilité de fabrication (IsTrac) pour le groupe L’Oréal. La solution permet de tracer les étapes d’une fabrication sur base d’un mode opératoire, communiquer avec des automates, afficher les étapes de fabrication à l’opérateur, générer des rapports, calculer des rendements et automatiser le processus de fabrication.

Les premières années, nous n’utilisions aucune méthodologie de planification ou de suivi de projet, nous travaillions au jour le jour sur base de « cahier des charges ».  Lors de mes trois dernières années au service de IS2, j’ai découvert l’agilité à travers différentes lectures (eXtrem Programming, Scrum et XP à partir des tranchées, …). En ce temps-là, nous éprouvions pas mal de problème de planification lié à l’extension de l’équipe et à l’arrivée de nouveau contrats.  Nous vivions une forte croissance grâce à notre savoir-faire et la qualité de notre solution IsTrac.

Pour toutes ces raisons, il m’a semblé que c’était le bon moment pour nous remettre en question.

En avant marche !

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

J’ai tout d’abord migré notre contrôleur de source SVN au profit de TFS qui permettait une meilleure intégration à Visual Studio et offrait des possibilités supplémentaires.  Nous avons pu décider en équipe de notre nouvelle stratégie de versioning.  Nous avons travaillé sur des branches, modifier les numéros de version et affiché des « About box » cohérentes. Nous avions maintenant la possibilité d’identifier une version en production, y corriger un bug et redéployer sans craintes. Nous venions de nous ôter une terrible épine hors du pied : nous avions un contrôleur de source fiable.

Pour notre collègue du support, j’ai installé Bug Tracker .Net et je l’ai personnalisé pour qu’il réponde à nos besoins.  Très vite, nous avons pu nous centraliser une liste de problèmes, la priorisé et travailler sur les correctifs. Les correctifs apportés, nous pouvions proposer au client un change log lors de nos mises à jour.  Un autre pas dans la bonne direction…

La situation de crise s’est stabilisée et nous avons pu envisager la suite : “les problèmes de planification”.  Après de longue recherche et expérimentation d’outils, nous avons décidé d’opter pour Ice Scrum.  A l’époque, nous n’avions ni l’infrastructure, ni les compétences suffisantes 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é.  Quelques sessions de rédaction plus tard, nous obtenions un premier product backlog ; certes il n’était pas parfait, mais il avait le mérite d’exister.

Tel des apprentis Jedi, nous essayions de maitriser, les premières cérémonies Scrum : L’évaluation et la priorisation. De nombreux ouvrages, articles ou retours d’expériences nous apprennent comment mener une réunion d’évaluation du product backlog mais aucun ne nous indique comment bien choisir un jalon ni comment en évaluer sa complexité (voici ma réponse : La face cachée du planning poker). Pour ce qui est de la priorisation, nous le faisions au feeling, selon notre expérience du terrain. Malheureusement, nous n’avions personne pour endosser la casquette de client/product owner, notre patron préférait regarder de loin tout en nous laissant faire.

A vos marques, prêt… partez !

Notre première cérémonie de sprint planning fût un peu particulière.  Nous avions un backlog et du travail à dispatcher à trois développeurs.  Chacun à notre tour nous nous sommes emparés de la souris et à partir du backlog de IceScrum, nous avons sélectionné les stories que nous avions priorisé et qui nous concernait personnellement. Etrange pour un soi-disant travail d’équipe ! Et pourtant …

Chaque matin, nous nous réunissions autour le tableau virtuel d’IceScrum où nous modifions l’état de nos tâches. Cette mêlé quotidienne nous permettait de fournir notre état d’avancement aux différents membres de l’équipe, le responsable support en profitait pour nous exposer les problèmes en cours et nous synchronisions nos tâches de la journée. Les comportements ont évolué, on assistait régulièrement à une entraide volontaire et spontanée en cas de blocage d’un collègue. L’appropriation du code était en marche et elle se traduisait par un « vol » de tâches. Selon les affinités et la charge de travail, nous avions le loisir de choisir sur quoi travailler. Nous avions enfin découvert le véritable travail en équipe.

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

Don Quichotte contre les moulins à vent.

Dans la mesure où votre patron ne soutient pas votre démarche, il est très difficile de maintenir la motivation nécessaire à la mise en place de pratique agile.  Cependant, l’équipe était demandeuse et nous avons maintenu le cap.  Je ne comprends toujours pas pourquoi, au sein d’une PME, refuser d’adopter un système de planification ? Pourquoi ne pas priorisé une « liste de tâche » ? Pourquoi ne pas tenter de diminuer les perturbations extérieures ? Pourquoi ne pas comprendre que c’est la principale source de frustration et d’anxiété ?

Jetons un œil dans le rétro.

Quand une démarche itérative est entamée, au terme des premiers sprints, il est fréquent d’être frustré par un nombre de story planifié non réalisées. Pour comprendre les raisons de cet échec, il faut pouvoir jeter un coup d’œil dans le rétroviseur, analyser les causes, faire ressortir les goulots d’étranglement, les perturbations interne ou externe et en retenir des leçons.

Dans notre cas, les raisons étaient simples à identifier. Dans le passé, sans planning à court terme, nous avions l’habitude de réagir à la plus petite sollicitude du client ou du patron.  Qui n’a jamais vu son boss passer la tête par la porte, cracher une vague description, vous demander au doigt mouillé le temps de réalisation et sens retourner vers le client pour lui promettre monts et merveilles ?  La cause principale résidait dans l’ajout de tâches non planifiées sur le tableau au fil des semaines.  Un autre problème était les analyses d’impacts manquantes ou bâclées. Il était impossible de planifier une liste de stories et de s’y tenir.

Bien que le boss ait fait l’effort de lire eXtrem Programming, il refusait de prendre part à nos réunions de planification prétextant que c’était une perte de temps. Son comportement vis-à-vis de notre tentative d’améliorer notre processus était contradictoire. Il refusait de prioriser notre backlog produit, nous laissait passer des heures à planifier le sprint et imposait ses priorités en cours de route !

The end !

La tentative d’introduction de principe agile s’est soldée par ce que je qualifierais de “Succhec” (à 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 bonne chose.  Il est vrai que mes anciens collègues subissent toujours des perturbations dans leur cycle de travail au 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…