Reprendre la maîtrise de son delivery avec le Lean grâce à la qualité à la source

Dans nos métiers, nous sommes amenés à rencontrer des équipes, des personnes et des personnalités bien différentes. Des entreprises avec leurs propres vécus, leur propre histoire qui façonnent des missions très différentes : parfois complexes, souvent exigeantes… mais toujours passionnantes.

De ce fait, il y a des missions qui marquent plus que d’autres. Cet article est un retour d’expérience de l’une d’elles. L’accompagnement d’une équipe de développement chez un éditeur de logiciels dans le domaine de la santé, travaillant depuis des années sur la partie du logiciel la plus stratégique et critique de l’entreprise : la prescription médicale. Elle vit au quotidien avec un niveau de complexité que nous avons rarement observé dans nos missions, et les risques liés aux prescriptions rendent chaque décision particulièrement délicate avec potentiellement des vies humaines en jeu. L’entreprise comprend la situation, mais ne sait plus comment aider l’équipe à reprendre la maîtrise de son travail.

Comprendre la situation

Nous commençons par une immersion afin de comprendre la situation. 8 jours pendant lesquels nous allons être dans l’équipe, ses rituels, son quotidien, pour poser notre regard sur les sujets suivants :

1. Leurs clients, leur satisfaction et celle des équipiers
2. La valeur livrée, et son pilotage
3. Ce qui est fait par le système pour mettre chacun en situation de réaliser son travail avec le niveau de qualité attendu
4. Le processus et son efficacité (et les gaspillages qu’il contient) pour savoir s’il permet de livrer en continu de la valeur aux clients (comment évolue la performance, la qualité, la variabilité, etc.)

Satisfaction des clients et de l’équipe

Pour comprendre la satisfaction des clients, nous réalisons des entretiens : les VOC (Voice of Customer). Les interviews de 9 clients mettent en évidence des problèmes de qualité, des régressions, des effets de bord, des écarts fonctionnels avec les attentes utilisateurs et des évolutions qui traînent à être livrées. Le NPS (Net Promoter Score) des clients est de -44. Pourtant, l’entreprise investit dans sa qualité. Autour des 5 développeurs (tous experts), gravitent 3 QA issus du monde médical pour maîtriser les sujets fonctionnels et 2 PO (pour confronter les idées), eux aussi issus du monde hospitalier. Un investissement cohérent au regard de la sensibilité du sujet.

L’équipe partage malheureusement cette insatisfaction avec une tension palpable. L’eNPS, à -20, en atteste.

Delivery et le pilotage

L’analyse des 66 US terminées depuis le début d’année montre une forte variabilité dans le delivery. En effet, entre 1 et 11 US sont livrées chaque semaine, soit une variabilité de 1100 %. L’analyse de l’engagement des Epics et des Stories sur des périodes de 6 semaines montre un écart significatif entre ce qui est engagé et ce qui est réalisé.

Du point de vue pilotage, on constate là aussi de la variabilité dans l’engagement des sprints qui est tenu entre 0 % et 500 %. L’observation du daily montre un pilotage en flux poussé, comme nous l’observons dans l’immense majorité des cas (pour ne pas dire tous). Lors des daily par exemple, le questionnement se focalise sur l’activité de chacun. Tous déroulent à tour de rôle leur activité : ce qu’ils ont fait hier, ce qu’ils feront aujourd’hui. Mais personne ne sait vraiment s’ils sont en train de réussir leur journée. Les critères de réussite de la journée (le challenge) ne sont pas clarifiés dans les rituels de pilotage, ni quotidiennement par le daily, ni même de façon hebdomadaire. Or, ce challenge est nécessaire pour observer les écarts et lancer l’amélioration continue par la résolution de problèmes. C’est cela qui permet au Lean d’intégrer l’apprentissage dans le temps de travail.

Qualité à chaque étape

L’analyse de la qualité montre que 42 % des tickets traités sont des retours de QA, de PO ou de développement (lors des Pair Reviews). Le processus semble bien avoir l’ambition de protéger le client final, mais au détriment des fonctionnalités qui ne représentent que 19 % des tickets livrés. En termes de temps passé, l’analyse montre que plus de la moitié du temps est consacrée à la réparation de valeur.

Pour comprendre les causes de cette non-qualité, nous analysons avec l’équipe 62 retours. Nous constatons alors que 17 causes sont des cas oubliés (soit 27 %), 7 sont des spécifications incomplètes (11 %), 6 % des champs mal définis (10 %). En d’autres termes, 48 % des retours sont des sujets de qualité entrante. Des sujets pas suffisamment définis qui ne permettent pas au développeur de réaliser son travail “bon du premier coup”.

Nous demandons à voir la DOR (Definition Of Ready). Nous constatons alors que l’équipe en a bien une, mais à l’instar de ce que nous observons régulièrement, celle-ci dort paisiblement dans un coin de Confluence et n’a pas été mise à jour depuis plusieurs mois. On me confie alors que la complexité rend impossible l’usage de cet outil. Et en effet, le format « checklist » souvent utilisé pour définir la DOR est trop simple par rapport à leur situation. Ce constat, en toute objectivité, je le partage, à la vue de la complexité importante des cas analysés. L’équipe n’a pas trouvé le moyen de standardiser son travail, ce qui est un obstacle à l'apprentissage.

Analyse du flux

L’analyse des délais montre que 23 des 66 US terminées depuis le début de l’année ont un Lead Time (durée de bout en bout) supérieur à 30 jours, soit 35 % (dont 13 avec un Lead Time supérieur à 100 jours). En moyenne, le temps réellement passé par les équipes, divisé par le Lead Time, est de 4,1 %. Ce qui signifie qu’en moyenne, les US attendent 95,9 % du temps.

L’analyse des temps passés montre que 90 % du temps des US est passé sur des étapes d’attente. 31 % du temps est passé en attente de packaging et 32 % en attente de validation par les QA. Cela met en évidence un manque de pilotage de la chaîne de valeur de bout en bout, et une désynchronisation des processus de développement et de test. C’est à ce moment-là que nous apprenons que dans cette organisation, les QA sont des experts métiers, sortes de consultants transverses dans toute l’organisation. Leur expérience du monde de la santé, souvent en tant qu’anciens praticiens, fait qu’ils opèrent dans une entité spécifique mêlant expertise médicale et pratiques de test logiciel.

Mettre l’équipe en mouvement

Nous comprenons maintenant les problèmes rencontrés, la difficulté de la direction et des clients, et nous partageons la tension vécue par les collaborateurs. Il est temps de lancer le mouvement pour redonner à l’équipe la capacité d’agir pour reprendre le contrôle de son delivery. Nous proposons de passer 3 jours ensemble pour travailler sur les sujets identifiés. L’équipe va apprendre le regard particulier que le Lean porte sur l’activité. Nous partageons avec eux les interviews de leurs clients, leurs verbatims, les US ayant pris particulièrement longtemps, dans le but d’identifier avec eux les gaspillages qu’elles ont subis. Nous travaillons sur la qualité, en analysant les causes racines d’un ensemble d’anomalies, de retours QA, de retours PO. Nous investiguons les problèmes de flux au travers de l’analyse des temps passés à chaque étape du processus des derniers tickets traités afin de mettre en avant la déconnexion des processus déjà évoqués plus haut. Pour chacun de ces éléments analysés, nous travaillons ensemble pour identifier des contre-mesures à expérimenter dans les prochaines semaines. Enfin, nous leur présentons le concept de standardisation pour leur donner un moyen de capitaliser les apprentissages, quand nous aurons testé les contre-mesures.

À la fin des 3 jours, l’équipe présente le résultat de l’atelier à sa ligne managériale (du N+1 au N+3 dans notre cas) pour créer un consensus autour des problèmes qu’elle rencontre et obtenir soutien et support pour la mise en place des contre-mesures envisagées. Un moyen d’engager le management pour lui redonner la capacité d’agir.

Accompagnement

L’équipe est sortie de l’atelier avec une envie et une motivation débordante et contagieuse de reprendre son activité en main. Au grand plaisir des managers qui sentaient le mal-être sans savoir comment agir. C’est peut-être là la particularité qui m’a personnellement marqué avec cet accompagnement et qui me pousse à écrire ces lignes.

Reprendre la maîtrise de la qualité

Grâce à cette énergie post-atelier, l’équipe décide de s’emparer de son sujet principal de qualité et de maîtrise des entrants. Ce qui engendre des régressions, des effets de bord, des écarts fonctionnels chez les clients, comme partagé dans les VOC. Ils décident dans un premier temps de faire participer les QA à chaque écriture d’US afin qu’ils puissent compléter les tests d’acceptation imaginés par les deux PO, afin de maximiser leurs chances de réussite (prendre le temps de bien faire, avant de faire vite). Sur les sujets les plus complexes, ou soulevant le plus de questions, ils organisent des points directement avec les consultants internes de l’entreprise, voire directement avec les clients. Mais comment faire pour se poser les bonnes questions et ne pas en oublier quand la technique et le fonctionnel sont si complexes ? Pour répondre à ce point, les développeurs créent une mindmap représentant l’ensemble des chemins possibles pour une fonctionnalité touchée. Le but est de limiter au maximum les oublis de cas, de faciliter la conception et les tests, mais également de pouvoir avoir un support d’apprentissage lorsqu’un cas sera effectivement oublié et remonté lors des tests PO ou QA. Cela semble représenter un travail titanesque au regard de la complexité de l’application. Cependant, on décide de ne pas faire d’atelier pour l’initier, mais de la mettre à jour de manière incrémentale à chaque retour, en gardant à l’esprit l’objectif de ne plus avoir ce retour en question. Avoir un retour n’est pas grave en soi, on fait cependant tout ce qu’il faut pour ne pas avoir deux fois le même. Au bout d’un mois, 62 cas sont déjà décrits, sur des branches dont la profondeur va de 3 à 7 niveaux. Un mois plus tard, la mind map a plus de 100 cas décrits. Une partie de la charge mentale a diminué, l’équipe semble gagner en maîtrise et retrouver de l’assurance.

Une décision structurante est également prise : ne plus accepter de travailler sur des US non prêtes d’après leurs critères. Cela paraît plutôt naturel, mais vous n’imaginez pas le nombre d'équipes qui n’appliquent pas ce principe de base malgré une DOR existante. La mind map permettant de se poser de nombreuses questions (auparavant oubliées), la définition complète d’une US par les PO devient plus complexe, plus longue, mais tout le monde est aligné sur l’importance d’avoir des US prêtes.

Reprendre la maîtrise de son processus

L’équipe travaille également sur la reconnexion des processus de développement et de validation. Pour ce faire, elle intègre les QA en les alignant sur leurs objectifs. Comme décrit précédemment, l’activité QA est pilotée par une entité à part, ils ont donc leurs propres objectifs. Nous allons alors mettre en place un pilotage commun en flux tiré. Lors du daily, on va clarifier les conditions de réussite de la journée. Non pas en précisant sur quel sujet le temps va passer (hier j’ai fait ça et aujourd’hui j’avance là-dessus), mais en termes de sujets terminés. Pour ce faire, on va regarder l’engagement des Epics sur le trimestre. On va regarder le nombre d’US inclus dans ces Epics, et faire l’exercice de les distribuer sur chaque semaine. Cela permet d’avoir un rythme, celui qu’il faudrait idéalement tenir pour réussir notre trimestre. À la suite de ce nombre d’US à terminer sur chaque semaine, on peut ensuite décliner ce qui doit être terminé chaque jour. On a ainsi l’objectif du daily. Mais ce qui change le plus, c’est que le « terminé » n’est plus sur la fin du développement, mais sur la fin de la validation. Mécaniquement, cela permet de reconnecter les processus avec les QA qui viennent maintenant naturellement aux daily, et s'organisent chaque jour pour valider de manière continue et sans attente ce que les développeurs ont fini de développer.

Dans sa quête de reprise de contrôle de son flux, l’équipe étend la définition du prêt (DOR) à l’ensemble du processus. C’est ainsi que se pose la question de ce qu’est un développement prêt pour la revue, de ce qu’est une revue bien faite et prête pour les tests d’intégration, et ce que sont de bons tests d’intégration pour pouvoir partir en production. L'objectif est de reprendre la maîtrise de la qualité à chaque étape du processus. Cela leur permet d’avoir également des supports pour capitaliser les apprentissages issus des différentes analyses des retours clients, de QA, de PO, de Dev, etc.

Reprendre la maîtrise des stocks

Comme toute équipe débordée par la complexité, elle souffre également de stock, avec 66 tickets « À qualifier », qui sont des retours, des demandes d’évolution ou des anomalies, nécessitant une pré-analyse par les PO pour être qualifiés. Le flux entrant est incessant… et non piloté. Les PO mettent en place un pilotage pour en reprendre la maîtrise. Une analyse montre qu’en moyenne, 3 tickets entrent par semaine dans ce statut (par les clients, le support, etc.). Les PO ont alors mis en place un point de pilotage pour traiter 5 tickets par semaine afin de gérer le flux entrant et réduire petit à petit le stock. Ils ont également standardisé le traitement de ces tickets via un graphe de décision, ce qui a accéléré leur traitement. La définition claire de l’objectif hebdomadaire et la standardisation du traitement des tickets a permis, là aussi, de soulager la charge mentale des PO.

Il existe aussi un stock de bugs divers, venant d’autres équipes, des PO, des QA, des clients, du support. Le Team Lead a alors suivi le même chemin que les PO en reprenant également le contrôle de ce stock. De la même manière, il a défini un objectif hebdomadaire pour pouvoir piloter ce stock. Cet objectif était, comme pour les PO, de 5 par semaine.

Quel est l’objectif de tout cela ?

À ce moment, vous vous demandez peut-être : Pourquoi faire tout cela ? En quoi changer la nature des questions du daily apporte vraiment quelque chose ? En quoi clarifier les conditions de la réussite suffirait à atteindre l’objectif ? Est-ce que le fait de se dire qu’on va traiter 5 tickets par semaine suffit à traiter ces 5 tickets ? Il y a, en réalité, deux réponses à cela. La première est un apport rapide, presque immédiat : la réduction du champ d’attention. Clarifier les conditions de la réussite permet à chacun de considérer cela comme la priorité. En se focalisant dessus, elle libère son esprit de plusieurs sujets annexes qui viendraient la perturber. En cela, elle se retrouve parfois à dire non. On comprend ici l’une des raisons du soutien nécessaire de la ligne managériale. La seconde réponse, plus efficace à long terme, est de rendre les écarts visibles. Clarifier les conditions de réussite via des éléments quantifiables permet de mesurer rapidement ces écarts. Et les écarts en Lean, c’est un problème, et c’est bien cela que nous cherchons à faire : développer les personnes par la résolution de problèmes. Un problème est donc une opportunité d’apprendre. C’est l’analyse quasi-quotidienne de ces problèmes qui permet de mettre en lumière des choses que l’équipe ignore. Les identifier permet de changer nos pratiques, et c’est pour cela que les standards existent. C’est ainsi que la machine pouvait se lancer. Tout cela mis en place, plus de 50 écarts sont analysés en 2 mois. Ces problèmes étaient circonscrits à une situation précise, ce qui a permis d’identifier des contre-mesures spécifiques et actionnables, qui ont toutes mené à un apprentissage. Et je ne compte pas les analyses qu’ils ont menées en toute autonomie.

Résultats

La pugnacité de l’équipe à suivre sa performance et à saisir toute opportunité d'amélioration pour changer ses pratiques a eu un effet très significatif. En 2 mois, elle a transformé son système de production : plus de qualité, plus de débit, moins de tension.

• Elle a diminué de 59 % ses retours QA par US, et de 19 % les retours PO. Un signal fort : les problèmes de qualité qui embolisaient l’équipe depuis des années devenaient enfin actionnables en changeant de regard.

• Le temps libéré et la diminution des aller / retours a permis à l’équipe de reprendre la maîtrise de son flux de production, ce qui a fait gagner 39 % de delivery, en livrant 7,1 US par semaine contre 5,1 auparavant.

• La reconnexion des processus entre dev et QA, combinée à la mise en place du pilotage opérationnel et à la résolution des problèmes qui en ont émergé, a permis de réduire le Lead Time des US de 81 %.

• Quant aux stocks des Bugs et des tickets à revoir par les PO, la mise en place du pilotage et des standards pour les traiter a fait diminuer de respectivement 23 % et 24 % les stocks avec une rupture nette de la tendance sur la semaine de mise en place.

• Enfin, l’équipe a repris la maîtrise de son flux : elle livre plus, plus vite, avec moins de tension. Et cela se ressent sur l’eNPS, passé de -20 à +56.

Le NPS sur l’accompagnement est de +67 (question posée : Sur une échelle de 1 à 10, à quel point recommanderais-tu la démarche Lean ?).

En changeant leur regard sur l’activité, et en se concentrant sur les pièces unitaires et spécifiques, les collaborateurs ont repris le contrôle là où tout se jouait réellement : la qualité à la source. En reconnectant les processus et en pilotant l’activité de manière très opérationnelle, l’équipe a fait émerger de nombreux problèmes qu’elle a su saisir comme des opportunités d’amélioration. Peu à peu, elle a reconstruit ses standards, renforcé sa maîtrise… et surtout, sécurisé sa capacité à produire bon, du premier coup.

Ce faisant, elle n’a pas seulement amélioré sa performance, elle a changé sa manière de travailler, sa manière de s’améliorer et d’apprendre, faisant de la qualité son véritable moteur de progrès.