Un collègue me demandait il y a quelques jours comment faire pour convaincre une équipe d’abandonner le mode projet pour passer à l’agilité. Ce verbe “convaincre” m’a toujours laissé cette impression sous-jacente d’impératif belliqueux, qui impliquait une sorte de combat rhétorique, opinion contre opinion.
Je ne peux m’empêcher de penser à l’ouvrage L’art de la guerre dans lequel Sun Tzu explique que le meilleur moyen de remporter une bataille est d’inciter l’ennemi à s’avouer vaincu sans même avoir à combattre. Même si les collaborateurs opposés à la mise en oeuvre de l’agilité ne sont évidemment pas des ennemis, leur réticence reste un obstacle à surmonter dans la démarche de transformation.
Dans les pratiques Lean, pour avancer en évitant ces combats d’opinion, nous nous efforçons de montrer la réalité dans sa lumière la plus crue, sans jugement, afin de créer le consensus. Il n’est alors plus nécessaire de convaincre mais de laisser les personnes voir les choses telles qu’elles sont. Si le geste est bien réalisé, nos interlocuteurs peuvent alors être en situation d’écoute de proposition d’approches alternatives.
Cet article présente un retour d’expérience illustrant ce parti-pris d’une conduite de changement Lean, qui n’a jamais besoin de se présenter comme telle.
Contexte
Je suis avec Julien un coach agile. Nous accompagnons ensemble une équipe TMA au sein d’un centre de services d’une ESN, regroupant une dizaine de personnes qui maintiennent, pour le compte d’une institution publique, un logiciel très complexe de remboursement de cotisations pour une catégorie socio-professionnelle donnée.
Nous ne sommes pas exactement dans le contexte d’une startup innovante. Le dispositif est contractuellement construit autour d’un processus en cycle en V avec :
- un cahier des charges qui est soumis par la maitrise d’ouvrage du client ;
- une Business Analyst de l’équipe qui formalise alors une spécification et un devis avec l’aide du Lead Technique ;
- Lorsque le devis est validé, l’équipe technique prépare des spécifications techniques et lancent les développements ;
- Qui sont validés en interne par les Business Analysts;
- Puis soumis pour recette aux MOAs client;
- Enfin mis en production
Mise en oeuvre de l’agilité sur un premier contexte
Julien a déjà mis en place un certain nombre de pratiques agiles pour aider cette équipe à mieux travailler sur les étapes 2, 3 et 4 : du management visuel qui montre le flux de production d’évolutions ; un point quotidien de 15 mns le matin pour aider l’équipe à clarifier les objectifs de la journée et remonter les problèmes rencontrés ; un travail de décomposition fonctionnelle pour travailler sur de plus petits lots organisés autour de cas d’utilisation client (des User Stories).
Pourtant le client demeure insatisfait : si la qualité s’améliore sur les évolutions logicielles livrées, il y a toujours des problèmes sur la phase amont qui cause des délais sur la partie de spécifications fonctionnelles réalisée par Alix la Business Analyst de l’équipe.
Embarquer les équipes amont
L’agilité s’arrête cependant aux portes de l’équipe et Julien souhaite naturellement l’étendre pour intégrer les responsables maîtrise d’ouvrage (MOA) chez le client. Il s’avère que ces deux professionnelles sont plutôt réticentes envers cette approche qu’elles jugent risquée et non adaptée à la nature du contrat qui lie l’ESN avec ce client public.
Julien et l’équipe, convaincus de l’apport de cette approche agile, souhaitent embarquer ces deux responsables MOA dans la démarche et Julien me demande comment faire pour convaincre ces personnes récalcitrantes à adopter la démarche agile. A chaque fois qu’ils ont évoqué la possibilité de mettre en oeuvre cette approche avec les clientes de la MOA ils ont été éconduits. Celles-ci n’ont été que peu enclines à partager leur enthousiasme pour l’agilité, présentée par Julien avec son manifeste et ses principes.
Comprendre le point de vue des clientes
Je leur demande alors de se mettre à la place de leur cliente et de se poser la question ; dans quelle mesure ce manifeste qui leur a été présenté va leur permettre de mieux traiter leurs problèmes ? D’ailleurs quels sont ces problèmes qui contrarient nos clientes ?
“Elles ne sont jamais satisfaites de nos spécifications” répond Alix, “Il y a toujours un truc qui ne va pas. Et du coup on sent de l’irritation dans leur façon de communiquer que ce soit par écrit ou à l’oral. Ce qui est rageant c’est que ce n’est pas toujours de notre faute.”
Ah c’est intéressant tu as des exemples ? je m’empresse de lui demander
“Oui et elles nous rajoutent tout le temps des Règles de Gestion (RG)”
Aha ! – tout le temps ça veut dire quoi ? Tu as des exemples ? m’enquière-je
“Et bien sur AAA1 on en a eu plein !”
“Très bien tu veux bien me montrer s’il te plait?” je demande, ravi de cette nouvelle perspective de partir sur le Gemba.
Analyser des pièces
Dans le Lean, pour couper court à toutes les opinions, nous décidons de regarder de façon très spécifique les derniers produits livrés afin d’avoir quelque chose de spécifique sur lequel travailler. Cet objet (la “pièce”) sur lequel nous portons notre attention ensemble nous permet de converger vers une réalité commune. On parle alors de construire le consensus.
Tout d’abord nous regardons les spécifications de l’évolution AAA1 : nous regardons le nombre de versions du document et l’impact en termes de délais (jours calendaires) et de charge (nombre de jours passés par Alix pour sa réalisation Vs. le nombre de jours prévus initialement.
Nous faisons un focus sur les trois dernières versions et dénombrons le nombre de retours. Nous catégorisons ces retours pour identifier ce qui représente des évolutions du besoin du client et des retours qui relèvent de problèmes de qualité au sein de l’équipe. Au passage l’équipe constate certains manquements internes sur leur processus de mise à jour des maquettes suite aux modifications des règles de gestion, leur formalisation des RG qui n’est pas suffisamment précis en ce qui concerne l’objectif, ou encore le besoin de valider avec le Tech Lead une RG proposée à la MOA afin d’éviter d’avoir à la modifier pour contraintes techniques une fois validée par la MOA.
Analyser les dernières livraisons en recette
Nous regardons ensuite les dernières livraisons en recette. Nous constatons que suite à la livraison de la version majeur précédente MMM2 qui représentait 64 jours de développement, il y a eu deux nouvelles évolution complexes identifiées et 4 mineures.
Enfin le client a demandé de faire des spécifications sur deux évolutions XXX3 et YYY4, spécifications qui leur ont coûté un investissement et qui ont vu leur priorisation baisser. Les deux autres évolutions précédemment citées ont été livrées avant et tout le travail de spécification de XXX3 et YYY4 est devenu obsolète en raison des évolutions du logiciel depuis.
Construire le consensus
Après avoir fait une synthèse chiffrée des problèmes rencontrés, nous nous déplaçons pour rendre visite à notre client dont le site est à trois heures de route des bureaux de l’ESN. La direction informatique et la direction du métier concernée sont aussi présentes.
Nous leur présentons ainsi les élément chiffrés, spécifiques et factuels suivants :
- De très nombreux A/R en phase de spécification : AAA1 :
- 8 versions des spécifications en 1 mois ;
- passage de 30 à 73 RG à modifier (i.e. 43 RGs non identifiées initialement par le client) avec un impact de 1 mois de délais sur la livraison du document ;
- Sur les 3 dernières versions (celles avec le plus de sujets), 70 retours dont 36 nouvelles demandes posées par le client (que l’on retrouve dans les 43 RG vues ci-dessus) et 34 problèmes de qualité de notre côté. Nous démarrons par présenter nos 34 problèmes et leurs causes afin de montrer que nous sommes là dans une approche constructive et pas pour avoir raison ;
- Identification de nouveaux besoins au moment de la recette de MMM2 : 2 évolutions majeures (>10 jours) et 4 évolutions standard identifiées en recette ;
- Des spécifications réalisées (XXX3 et YYY4 pour une dizaine de jours de charge d’Alix chacune) puis mises en attente en raison de priorités de réalisation qui changent : elles sont devenues obsolètes ;
- Un processus organisé autour d’unités d’œuvre opérationnelles de trop grosse taille pour pouvoir accélérer (les 64 jours de MMM2 pourraient être découpées en cas d’utilisation d’une dizaine de jours et livrés plus vite : on aurait ainsi pu voir les 2 évolutions majeures plus vite et les développer pus tôt, au détriment d’autres fonctionnalités moins critiques).
La direction informatique ainsi que la direction des métiers et les responsables MOA partagent le constat avec nous. Le fait que nous ayons présenté les sujets qui nous appartiennent en premier permet de créer les conditions d’un échange constructif et de faciliter le partage du constat. Enfin, les éléments chiffrés et irréfutables participent de cette vision commune et de ce consensus. La première étape de la transformation est bien engagée.
Corpus de connaissance du développement logiciel
Après nous être assurés que le problème est bien partagé nous passons à la deuxième étape : les enseignements du corpus de connaissance de 25 années de l’industrie du développement logiciel :
- Vision Partagée : Favoriser les phases de dialogue en face à face dans le cadre d’ateliers collaboratifs pour construire plus rapidement une vision partagée des besoins et de la solution en phase de spécification ;
- Valeur utilisateur : Formuler les besoins selon la perspective des utilisateurs en partageant la valeur apportée par le logiciel ;
- Lots plus petits : Définir des lots plus petits, plus faciles à livrer et à tester par les utilisateurs pour soumettre un feedback rapide à l’équipe de réalisation ;
- Livrer plus régulièrement des versions avec des cas d’utilisation complets et faire des démonstrations du logiciel pour identifier au plus tôt l’intégralité des besoins ;
- Prioriser les besoins afin de ne travailler que sur des éléments qui vont être réalisés à court terme (juste à temps) pour donner plus de flexibilité au changement éventuel de priorités et éviter de gaspiller des efforts sur des choses qui ne sont pas importantes maintenant.
Nous pouvons ainsi présenter les principes opérationnels de l’agilité sans évoquer ce terme qui provoque une réaction épidermique chez nos interlocutrices MOA. Le parallèle entre la nature spécifique des problèmes identifiés (et leur impact) et ces contre-mesures qui sont présentées comme des bonnes pratiques génériques permet une meilleure acceptabilité de l’approche.
Nous concluons enfin par notre interprétation de ces pratiques éprouvées pour proposer un pilote et tenter de résoudre ensemble les problèmes spécifiques inhérents à notre contexte. Dans un premier temps nous proposons de rester sur le même modèle contractuel, ce que le client accepte pour le pilote.
Pilote du nouveau dispositif
Au terme du premier pilote (l’évolution DDD3), la MOA est ravie. La phase de cadrage initiale n’a pris que 3 jours calendaires en délais. Cette évolution de 53 jours a été lotie en cinq lots d’une dizaine de jours de charge qui sont livrés régulièrement chaque semaine sur l’environnement de recette. A la seconde livraison la MOA a identifié un sujet qui rend une partie du 4eme lot inutile avec une simple petite modification dans le second.
Au final l’équipe n’a “que” 5 jours de retard sur la livraison par rapport au planning initial prévu plusieurs mois avant, comparé à des retards de 30 ou 40 jours pour les évolutions précédentes. Le point principal est que la plus grande proximité avec la MOA (Alix se déplace sur site un jour par semaine pour clarifier les spécifications) a changé la nature de la relation. Les incompréhensions sont traitées rapidement au téléphone si elle n’est pas sur site : la collaboration est plus fructueuse et bien moins conflictuelle.
Montrer plutôt que convaincre
Sans ne jamais évoquer le A-word, la MOA est passée à un mode agile dont elle voit la valeur. Il n’a à aucun moment été nécessaire de les convaincre : montrer la nature et les causes des problèmes spécifiques rencontrés, leur impact sur l’avancement, et évoquer comment le corpus de connaissance de l’ingénierie logicielle règle ces sujets standards les a incitées à tester cette nouvelle approche avec succès.
#hypertextual 