Responsable de la démarche de Lean Software Development chez un éditeur de logiciel pendant deux ans, j’ai coaché une équipe dans le développement de deux versions successives (appelons les V2 et V3) du logiciel d’entreprise que nous commercialisons.
Nous avons graduellement apporté sept modifications majeures à notre organisation, modifications qui ont permis à notre R&D de supprimer des gaspillages dans le processus de développement et d’obtenir des résultats encourageants.
(Article publié en anglais sur le site InfoQ en Juillet 2014 et édité par Ben Linders – traduction Florence Préault)
Le contexte équipe et projet
70 personnes sont impliquées dans la nouvelle version du logiciel, réparties de la façon suivante :
Développement : 6 équipes Scrum, chacune développant une application de notre solution.
Intégration : l’équipe chargée des tests d’intégration de bout en bout.
Les analystes fonctionnels : grosso-modo ce qu’on appelle Product Owners en Agile
Les architectes fonctionnels : responsables de la cohérence des différentes applications.
Les architectes techniques
Les designers UX
L’équipe d’intégration continue et de release
Formuler le problème
Pour la V1 initiale (celle développée en suivant un processus de développement standard c’est à dire sans la démarche Lean Software Development), nous avions planifié 12 mois : 10 mois pour développer les fonctionnalités et 2 mois pour le gel des mises à jour logicielles et les tests d’intégration.
Il nous en faudra finalement 12 pour développer les fonctionnalités et les livrer à l’équipe de tests d’intégration. Soit deux mois de retard. Ensuite 11 mois (au lieu des 2 prévus) auront été nécessaires pour les tests d’intégration et la phase de stabilisation avant de pouvoir passer en production. Sans parler des 7 mois nécessaires à la livraison des deux versions de Service Pack.
Du point de vue du coût par activité, les 20 % de retard n’ont pas posé de problème majeur contrairement au retard sur la phase intégration/ maintenance qui a pris 11 mois au lieu des 2 mois prévus. Les 7 mois pour le service pack n’ont pas été pris en compte dans le lancement mais dans le budget général de maintenance.
D’un point de vue Lean (c’est à dire du point de vue du client), voici comment se définit le problème :
Un développement prévu sur 12 mois a été livre au client au bout de 23 mois (et même 30 si l’on prend en compte les service packs), l’écart est un retard de 11 mois. Ce qui a 3 conséquences principales :
En termes de retard : nous sommes en retard, donc le client est insatisfait.
En termes de coûts : l’entreprise doit payer 11 mois de ressources supplémentaires pour travailler sur la version.
En termes de retard, toujours : le fait de travailler sur la release N, nous empêche de travailler sur la N+1 qui sera également en retard.
En termes de CA : le time to cash est rallongé de 11 mois et l’on accumule des stocks de logiciels qui représentent un investissement pour l’entreprise.
Figure 1: Le problème du point de vue des délais
L’essentiel du temps et des efforts est passé sur des gaspillages: on retravaille le logiciel livré pour corriger les anomalies pendant la phase de stabilisation et les services packs.
Figure 2: Le problème en termes de gaspillage
Ce qu’en disent les équipes
Quelques extraits des entretiens menés au démarrage du projet :
« II est difficile pour la R&D de faire quelques chose de simple. Une fonctionnalité qui a de la valeur pour le client mais qui est simple à développer n’intéresse personne là-bas. »
« Personne au sein de la R&D ne sait ce que les clients font du produit. Le marketing trouve 20 bugs en 5 minutes sur les premières versions livrées par la R&D. »
« Comme les responsabilités sont diluées au sein de l’organisation, on observe des stratégies de survie individuelles plutôt qu’une stratégie collective orientée vers la performance. »
Analyse des causes : comprendre les idées fausses
Nos principales idées fausses lors de ce développement :
Développer des fonctionnalités est notre principal objectif car c’est ce qui a de la valeur pour les clients
Le fait qu’il y ait quelques bugs ici et là n’est pas un problème car nous les traiterons dans la phase de stabilisation.
Deux mois suffisent à geler les fonctionnalités et livrer un logiciel de qualité.
Comme évoqué précédemment, ceci résulte de notre perspective “coût par activité” qui nous laisse à penser que notre processus de développement logiciel est satisfaisant et que c’est notre maintenance qui n’est pas bonne.
Le résultat est que les équipes se dépêchent de développer des fonctionnalités sans trop se préoccuper de la qualité, en se disant : « nous aurons deux mois pour réparer tous les problèmes de qualité et cela suffira largement ».
Que s’est-il passé pendant la période de code freeze ?
De nombreuses anomalies en masquaient d’autres qui sont apparues au fur et à mesure que l’on en corrigeait
Les corrections d’anomalies ont introduit des régressions car une partie de notre patrimoine logiciel avait une faible couverture en tests automatiques
Conséquence des points 1 et 2 : nous étions incapables de prévoir quand le code serait d’assez bonne qualité pour être livré. Et cela a pris 11 mois.
Nous avons du développer 2 service packs dans les 7 mois qui ont suivi.
Partant de ce constat à l’issue de la V1, passons à ce que nous avons mis en place dans le cadre du Lean Software Development pour les deux versions suivantes.
Notre hypothèse
L’approche Lean Software Development nous a permis de voir les choses différemment. Notre hypothèse était la suivante : c’est la non-qualité dans le processus qui ralentit notre lead-time et créé du rework et 18 (11+7) mois de retard.
Le Standard
En matière de qualité, le standard Lean dit la chose suivante : on ne transmet rien à l’étape suivante du processus quand on sait qu’il y a un problème de qualité.
Dit comme cela, cela parait simple. Mais en réalité, c’est un peu compliqué à mettre en oeuvre au quotidien.
Comprendre le processus
En développement logiciel, maîtriser le processus implique de le comprendre et d’être au clair sur les trois points suivants :
La pièce (ou unité d’œuvre) qui parcourt le processus
Le processus lui-même et ses différentes étapes.
Les interfaces entre chaque étape : comment peut-on dire que le niveau de qualité entre chaque étape est ok et que l’on peut passer à l’étape suivante ?
Notre culture Agile nous a permis de rapidement identifier la pièce : la User Story (cf le paragraphe dédié).
Le processus est divisé en 3 phases principales (chacune étant elle-même divisée en quelques sous-étapes) :
L’analyse fonctionnelle : la définition d’une user story.
Le développement et les tests.
Les tests d’intégration.
Enfin, nous avons défini nos interfaces et les conditions du OK/NOK :
La User Story ne part en développement que si elle est prête à développer (Ready To Develop). Un statut qui est défini par les analystes fonctionnels, les architectes fonctionnels (responsables de la cohérence fonctionnelle de toute la solution), le designer UX, les développeurs et les testeurs (inclus dans l’équipe).
La User Story part à l’étape d’intégration si et seulement si elle est prête (statut Done). Ce qui signifie : aucune anomalie dans le cadre fonctionnel (non seulement le cas nominal est bon, mais tous les tests définis par le testeur intégré dans l’équipe ont été réalisés avec succès) et l’analyste fonctionnel ainsi que le designer UX ont donné leur accord.
On ne livre que s’il ne reste aucune anomalie dans le processus de test d’intégration de bout en bout.
Les 7 changements nécessaires pour supprimer les gaspillages
Une fois les règles définies, il faut donner à l’équipe les moyens de les appliquer. Voici les 7 points sur lesquels nous avons travaillé :
Considérer la User Story comme l’unité d’œuvre (ou la pièce)
Faire un suivi quotidien
Utiliser un management visuel pour le pilotage du projet
Faire le suivi formel de l’analyse fonctionnelle
Intégrer un testeur dans l’équipe
Geler les mises à jour à la fin du sprint
S’arrêter à chaque incident
1. Les User Stories
En général dans le design d’un processus, les gens portent beaucoup plus d’attention aux étapes du processus, et beaucoup moins à la nature de la pièce qui le traverse et qui représente la valeur. L’avantage des User Stories est qu’elles sont courtes, simples et surtout décrites du point de vue de l’utilisateur. Elles rendent la valeur client visible et peuvent facilement être évaluées en terme de charge et de complexité.
Plutôt que définir le système en termes de capacités (le système doit faire ceci et faire cela), la User Story définit le système depuis la perspective du client et la valeur qu’il lui apporte : En tant que {Rôle} je peux faire {une Action} pour obtenir {de la Valeur}. Exemple : en tant qu’acheteur (rôle) sur un site marchand, je peux mettre la paire de chaussure qui me convient dans mon caddie (action) pour pouvoir la commander et l’avoir 3 jours plus tard chez moi (valeur). A ce sujet voir le support de ma présentation à Agile Bordeaux 2014 : Eloge de la User Story.
Le fait de se mettre d’accord sur ces pièces nous a beaucoup aidés à aligner l’effort de l’ensemble de l’équipe sur la demande client. Au lieu de pousser des fonctionnalités vers l’utilisateur pour qu’il se débrouille avec pour faire fonctionner le système, les user stories tirent le développement depuis la demande et le besoin du client. Comme l’a rappelé l’inventeur du mot Lean, Daniel T Jones, lors du Lean IT Summit 2013 :
« La stratégie IT doit passer du mode push de fonctionnalités à un mode où les solutions sont tirées par la demande client ».
Ce qui, à première vue, peut passer par une subtilité sémantique représente en fait un changement majeur de façon de travailler pour les ingénieurs. Cela implique de les inciter à travailler selon le principe de conception Vertical Slice. Dans certains cas de figure techniques, concevoir une User Story s’est avéré difficile. Nous avons alors demandé aux ingénieurs logiciel de réfléchir différemment et d’intégrer des solutions techniques aux User Stories, en partant du point de vue de l’utilisateur. Les quelques fois où cela n’a pas été possible, nous avons opté pour les spécifications techniques. Mais d’une façon générale, nous avons réussi à modifier le comportement habituel des équipes pour leur faire faire la conception technique en se basant sur ces stories.
Le succès de cette démarche repose sur trois points critiques. Il est nécessaire de :
Former les gens aux User Stories
Coacher les analystes fonctionnels pour les aider à définir les bonnes user stories (granularité, valeur, critères d’acceptation)
Lancer des sessions d’analyse fonctionnelle pour que chaque rôle (développement, tests, UX) contribue à l’élaboration de chaque user story design et la rende prête à développer. Ce que l’on veut est construire une compréhension partagée de ce que l’on va réaliser.
2. Le suivi quotidien
Au départ, comme beaucoup d’équipes de développement logiciel, nous pensions maîtriser notre processus grâce à nos réunions hebdomadaires longues et formelles. Grâce à la présence des managers autour de la table et aux compte rendus écrits, nous avions la ferme impression de contrôler notre projet. Hélas, comme l’a prouvé le retard de 18 mois sur la V1, nous ne contrôlions rien du tout.
Dans un premier temps pour la V2, nous avons appliqué la méthode SCRUM : toutes les équipes se réunissaient pour une réunion de 15 minutes chaque matin et nous l’avons déclinée au niveau du projet.
9:30: Scrum meeting de chacune des 6 équipes de développement d’applications, incluant les développeurs mais aussi les testeurs et les analystes fonctionnels.
9:45: Scrum Projet incluant tous les Scrum Masters, analystes fonctionnels, responsables de test, architecte principal et managers des différentes équipes fonctionnelles
Figure 3a : Passage à l’échelle du point de suivi quotidien
Rapidement, nous nous sommes aperçus qu’il nous manquait des informations. Un développeur de l’équipe business Scrum A n’avait pas la possibilité de se coordonner avec un autre développeur de l’équipe Scrum B, ou encore un testeur de l’équipe A n’avait pas l’occasion d’échanger sur ce qu’il faisait avec un autre testeur de l’équipe B. Cela générait des problèmes de coordination et de rework.
Dans un deuxième temps (version V3) nous avons donc décidé d’ajouter un point supplémentaire entre les équipes Scrum et les projets Scrum :
9:30: Scrum meeting de chacune des 6 équipes de développement d’applications, incluant les développeurs mais aussi les testeurs et les analystes fonctionnels.
9:45 : Scrum des fonctions. Chaque équipe fonctionnelle participe à un point pour mettre en commun les informations issues des différentes équipes d’applications.
10:00 : Project Scrum incluant tous les Scrum Masters, analystes fonctionnels, responsables de test, architecte principal et managers des différentes équipes fonctionnelles
A l’issue du dernier point du matin, à 10h15 tout le monde sait où en est le projet, quelles sont les principaux problèmes, qui en est responsable et quelles sont les chances de réussite pour l’équipe à l’issue du sprint.
Figure 3b : Passage à l’échelle du point de suivi quotidien
C’est cette organisation, découverte dans le livre Lean From The Trenches de Henrik Kniberg, que je souhaitais mettre en place dès le départ. Je craignais toutefois que cela ne rebute l’équipe en raison d’une perception de surcroît inutile de communication. Nous avons donc commencé avec les 2 réunions mais rapidement les équipes fonctionnelles ce sont aperçues qu’elles avaient aussi besoin d’un point de coordination. Elles ont commencé avec un point hebdomadaire d’une heure. Mais cela ne les satisfaisait pas : ils sont donc passés à un point bihebdomadaire de 30 mns. Voyant que cela ne fonctionnait pas mieux, ils ont opté pour ce point quotidien. L’équipe a immédiatement vu le bénéfice de ces réunions quotidiennes et n’a jamais évoqué la surcharge de communication car cela leur permettait de traiter leurs problèmes.
Sans imposer le format, j’ai créé les conditions pour que l’équipe y vienne naturellement. Il aura fallu une livraison et six mois pour que cela se mette en place, mais comme il s’agissait de l’initiative de l’équipe elle-même (et non d’une décision du coach), le format s’est pérennisé.
3. Le management visuel
A la fin de la V1, nous avons interrogé plusieurs collaborateurs pour savoir s’ils savaient où se trouvaient les informations clef du projet. Nous avons rapidement constaté qu’ils n’avaient aucune idée du statut du projet et décidé d’y remédier.
Pour que chaque personne sache où elle en est, nous avons mis en place un management visuel au niveau du projet. Comme pour le point quotidien, nous ajustons les tableaux visuels Scrum à l’échelle du projet. Au lieu d’un suivi par tâche, nous suivons le statut de la pièce : sur chacun de ces grands tableaux, chaque Scrum Master partage l’avancée de la pièce – la user story – avec l’analyste fonctionnel, le chef de projet, le designer UX, le Release Manager, Lead Tester.
Figure 4: Tableau projet de suivi des développements
Chaque ligne représente une équipe Scrum applicative et chaque colonne une étape du processus. L’objectif est de faire avancer les User Stories de gauche à droite rapidement et avec un grand niveau de qualité. Chaque problème externe (qui ne peut pas être résolu par l’équipe Scrum lors du meeting quotidien pour cause de dépendance externe) est soulevé et géré par quelqu’un au niveau du projet. Ainsi les problèmes transverses sont gérés immédiatement ce qui évite à l’équipe d’être bloquée. Les problèmes sont mis en évidence par des post-its roses où figure aussi le nom de la personne qui en est responsable. Et l’on constate que les problèmes sont pris en charge beaucoup plus vite que lorsqu’il sont évoqués dans un e-mail de compte rendu que personne ne lit.
Dans un premier temps, pour la V2, nous avons uniquement suivi le processus de développement sur le tableau.
A partir de la la V3, nous avons ajouté des tableaux supplémentaires :
Pour les équipes fonctionnelles, et leurs réunions quotidiennes de suivi : couche Business, couche Web, Intégration. L’unité de travail ici est le composant en cours de modification (développement) ou la campagne de test pour l’équipe d’intégration.
Pour le suivi de l’analyse fonctionnelle, cf ci-dessous
4. Le suivi formel de l’analyse fonctionnelle
Des problèmes liés aux User Stories sont apparus lors de la V2 : certaines arrivaient en phase de développement sans être véritablement prêtes à développer (Ready To Develop). Dans certains cas pour des problèmes d’UX, dans d’autres cas elles ne pouvaient pas être correctement évaluées par les équipes faute de temps lors de la préparation de l’itération. Cela générait de nombreux allers retours entre le Scrum Master et le Product Owner lors du développement, et donc énormément de gaspillages.
Pour la V3, nous avons décidé de formaliser la phase d’analyse fonctionnelle afin d’amener les User Stories au stade « Prêt à développer ». Cela a pris deux aspects.
Tout d’abord une session hebdomadaire d’une heure d’analyse fonctionnelle pour chaque équipe avec tous les participants : développeurs, testeurs, ingénieurs UX et architectes fonctionnels. Avec un objectif clair : traiter un nombre limité de User Stories pour les faire passer au stade « Prêt à développer » pour l’itération suivante. Chaque problème qui pouvait être résolu en interne l’était durant cette réunion. Les autres, avec dépendances externes, étaient remontées à la session hebdomadaire d’architecture fonctionnelle générale.
Ensuite, à coté du tableau de développement, nous avons ajouté un tableau consacré à l’analyse fonctionnelle pour pouvoir l’évoquer lors des réunions du matin. Cela a permis, non seulement de donner un statut clair et consolidé sur le développement des user stories du sprint en cours mais aussi de préparer l’analyse des user stories pour le sprint suivant.
Figure 5: Tableau de suivi d’analyse fonctionnelle (conception des User Stories)
L’objectif là encore est de faire avancer la User Story vers le stade ”Prêt à développer” pour qu’elle soit prise en charge efficacement à l’itération suivante de développement.
De fait nous suivons à partir de ce moment là, sur le management visuel, le cycle complet de réalisation d’une User Story : depuis les premières phase de conception fonctionnelle jusqu’à la livraison.
5. Les testeurs intégrés
Dans un premier temps (version V2), nous avons mis en place une équipe de développement pluri-disciplinaire (voir l’article Corriger des bugs vs. résoudre des problèmes) pour améliorer la qualité et l’efficacité de l’équipe, puis nous avons décidé d’intégrer l’un des deux testeurs à l’équipe de dév pour la V3.
Jusqu’alors, les testeurs étaient localisés dans un autre espace que les développeurs, occupés à sortir une livraison par semaine et à mener des tests sur cette version, tout en échangeant avec les développeurs principalement par email.
Le fait d’intégrer les testeurs à l’équipe, à côté des développeurs a tout changé. Leur rôle :
Participer à l’analyse fonctionnelle et donner leur accord pour le statut “Prêt à développer” des user stories. Ce qui implique que le testeur comprenne la user story et qu’il sache comment il va la tester.
Ecrire les tests qui vont permettre de s’assurer que la qualité de la User Story est bonne et qu’elle est « terminée».
Donner un statut sur les anomalies de test et les problèmes, non seulement pendant les réunions d’équipe du matin mais aussi avec l’équipe scrum d’intégration fonctionnelle juste après.
Exécuter les tests chaque jour sur des livraisons données pour trouver les anomalies le plus tôt possible et les corriger.
Coordonner la validation de la user story par l’analyste fonctionnel et le représentant UX.
Et cela a fonctionné au dela de nos espérances. Cela a surtout fait réalisé aux développeurs que tout le monde était responsable de la qualité. Nous sommes ainsi passé d’une version par semaine à 2 versions par jour et cela a démultiplié les retours du testeurs sur leur travail. Lorsque la bouvcle de rétro-action passe de la semaine à 2 fois par jour, on mutliplie la fréquence de feedback par 10 et on met en place un authentique système d’apprentissage, au quotidien.
6. Le gel des mises à jour en de fin de sprint
Nous avons cherché à comprendre pourquoi les équipes trasnsmettaient du code contenant des anomalies connues à l’étape en aval du processus, à savoir l’équipe d’intégration et de test. La plupart des Scrum Masters nous ont répondu qu’ils manquaient de temps et qu’ils devaient livrer de la valeur avec les fonctionnalités.
Nous leur avons alors demandé, ainsi qu’aux équipes ce qui les aiderait à livrer des fonctionnalités sans bug. Leur réponse a été unanime : « une semaine supplémentaire ». Nous avons donc décidé que dans nos Sprints de 4 semaines, la dernière semaine serait entièrement consacrée au gel des mises à jour pour permettre à l’équipe de :
Livrer des User Stories sans aucun bug.
Consacrer suffisamment de temps pour concevoir des Stories prêtes à développer pour le sprint suivant.
Dans la pratique, cela signifie qu’une équipe de 5 développeurs consacre seulement 5 développeurs x 5 jours x 3 semaines = 75 jours de travail estimé par sprint de 4 semaines (sur leurs 100 jours de disponibilité).
Certes, tout cela n’est pas très Lean : on ne fait ici qu’étaler des petites phases de gaspillage sur différents sprints. Mais il a fallu trouver des compromis car cela représentait de gros changements dans la façon de travailler de l’équipe.
La bataille a été rude en particulier avec le management qui considérait que le coût du développement allait augmenter brutalement de 25 % (à juste titre du point de vue de leur analyse activité / coût). Nous leur avons expliqué que nous souhaitions vérifier notre contre-mesure et mesurer son impact sur le lead-time total.
Le critère zéro anomalie pour qu’une User Story soit “prête” a rendu le processus très exigeant en termes de rigueur et de qualité. La semaine de gel des mises à jour a permis à l’équipe d’atteindre cet objectif.
Cette définition du “prêt” a aussi permis de rendre visibles les estimations optimistes et les difficultés rencontrées par les équipes. Elles ont rapidement pu ajuster et faire des estimations plus précises pour chaque User Story.
Alors que l’équipe s’améliorait sur ses estimations et s’organisait mieux sur l’analyse fonctionnelle, nous avons supprimé la semaine de gel des mises à jour des sprints qui durent maintenant 3 semaines. L’équipe est devenue mature en termes de qualité. Et l’on peut considérer cette étape comme la première marche de l’échafaudage vers la prédictibilité.
7. Arrêter la production
L’arrêt de la production ici n’est pas équivalent au véritable ”andon” Lean où l’on interrompt la chaîne de production et l’on demande de l’aide à son manager au premier problème rencontré. En arrêtant la production, notre objectif était d’instiller l’idée qu’en matière de développement d’application, développer de nouvelles User Stories alors qu’il reste des anomalies est une mauvaise idée. La règle était donc que le développement devait s’interrompre s’il y avait plus d’un bug majeur par développeur. Dans une équipe de 5 développeurs, si on a 5 bugs majeurs, on arrête le travail sur le développement pour se consacrer uniquement à la résolution de bugs.
Si l’on avait fait du vrai Lean orthodoxe, il faurait fallu s’arrêter au premier bug mais là encore, nous avons mis de l’eau dans notre vin pour que ce principe soit accepté par l’équipe.
Et cela a eu un impact extraordinaire sur la qualité : en réduisant quasiment à néant le backlog d’anomalies à la phase de code freeze, nous avons atteint l’objectif de livraison comme par magie. Certes il restait encore quelques activités sans valeur ajoutée mais au moins la livraison est intervenue à la date prévue.
Lean Informatique : Check
En mettant progressivement en place ces 7 changements organisationnels au cours de 2 versions, nous avons pu voir les résultats sur les délais dont les Product Owners étaient évidemment très satisfaits.
Avant d’entrer dans le détail des résultats, voyons comment ces changements ont été progressivement introduits par l’approche Lean Software Development (LSD) :
Figure 6: Mise en oeuvre graduelle des changements sur 3 versions
Les résultats sont décrits dans les diagrammes ci-dessous :
Qualité
Figure 7: Evolution de la qualité
L’évolution du ratio de qualité (le nombre d’anomalies restant au moment de la livraison divisé par le nombre de jours/homme de développement) prouve que la conjonction des deux éléments – intégration des testeurs à l’équipe et arrêt au défaut – a eu des résultats extraordinaires en termes de qualité. Dans une véritable démarche Lean, on aurait testé les deux contre-mesures séparément pour comprendre véritablement l’impact de chacune sur la qualité et la performance.
Retards
Figure 8: Évolution des retards
Lean Informatique : ce qu’en disent les équipes
Comme au démarrage du projet, nous avons mené des entretiens individuels avec chaque personne impliquée à la fin de cette version, et voici quelques verbatims :
Grâce à cette version, nous avons appris qu’il est possible de livrer un logiciel dans les délais et avec un excellent niveau de qualité.
Nous avons utilisé le produit dans tous les sens pendant une journée entière sans trouver aucune anomalie. Cela recrée de la confiance à l’égard de la R&D.
L’intégration régulière de toutes les applications nous facilite la tâche et nous permet à nous au marketing de raconter une super histoire à nos clients.
Le fait d’avoir une vision globale du projet chaque jour et de voir comment nous allons y contribuer nous aide à progresser.
L’équipe n’a cessé de s’améliorer. Nous avons adapté notre processus à nos besoins spécifiques et cela nous a aidé à résoudre de nombreux problèmes.
Le fait que toute l’équipe soit impliquée dans les User Stories depuis leur conception jusqu’au test permet à tout le monde de s’approprier ce que l’on développe. C’est très motivant.
Et les résultats économiques ?
Lorsque l’on raconte une expérience à Michael Ballé, le célèbre expert Lean, il demande systématiquement : “Et alors ? Quel est le ROI ?”
Le point de départ c’est 100 % de retard sur la V1. Si l’on avait fait la même chose avec la V3, un projet de 7 mois impliquant 70 personnes, le même effort de développement aurait coûté 490 mois / homme de plus (70×7). On peut donc considérer que l’on a économisé 490 mois / homme, l’équivalent de 40 FTE (Full Time Equivalent). Ce même logiciel a couté 40 FTE de moins qu’il aurait couté 2 ans auparavant. La conversion en K€ pour l’entreprise est de l’ordre de 2,5 millions d’Euros d’économies. Pour chaque version. Ce n’est pas négligeable.
Le time-to-cash est aussi impacté. Quand vous livrez un logiciel à temps et non avec 7 mois de retard, les revenus générés par les ventes sont sur votre compte en banque 7 mois plus tôt.
Lean Informatique : Act – ce que nous avons appris
La principale leçon à retenir de ce projet c’est que s’assurer de la qualité à chaque étape du processus a des effets spectaculaires sur la réduction des gaspillages, la suppression des retards, ainsi que sur l’engagement de l’équipe. L’arrêt de la production à chaque défaut a été déterminant pour rendre l’ensemble du processus plus efficient.
Deuxième leçon : rendre le processus visible favorise l’appropriation collective par l’ensemble de l’équipe. Non seulement cela permet de rendre les problèmes visibles mais cela transforme aussi la dynamique de l’équipe. Quand toutes les User Stories sont bloquées dans la colonne de test, on voit tous les développeurs proposer spontanément leur contribution à l’effort de test, ce qui relevait de l’impensable quelques mois avant.
Troisième avantage : une petite série de stand up meetings consécutifs permet de partager l’état d’avancement des projets tout en alignant l’ensemble des équipes sur des priorités communes. Cela a aussi permis de construire la confiance entre les équipes. Je me souviens d’un Scrum Master venant au point projet tous les matins pendant une semaine pour annoncer qu’ils n’avaient fait aucun nouveau développement parce qu’ils étaient occupés à corriger des anomalies à cause de la règle de l’ « Arrêt de la production ». Il faut du courage pour répéter cela tous les jours et de la bienveillance de la part de toute l’équipe pour ne pas commenter ni se lamenter sur la non-qualité. C’est à ce moment-là que l’on réalise qu’un changement de culture s’est opéré : finie la culture du blâme, place à la résolution de problème.
Quatrième enseignement : la gestion du changement prend du temps et exige de la part de l’agent du changement de la patience, de l’écoute active et de la bienveillance. Les sessions de coaching de 30 minutes en face à face avec les différentes personnes (Scrum Masters, Tests Lead, analystes fonctionnels, chefs de projet, managers) se sont avérées les plus efficaces. Toute initiative de changement génère beaucoup d’anxiété (cf le travail d’Edgar Schein sur ce sujet). Il faut donner aux gens un espace pour soulager cette anxiété et ce format de face à face a très bien fonctionné dans le cadre de notre projet.
Et ensuite
Avec le recul, on peut considérer qu’il a manqué deux éléments qui sont au cœur même d’une démarche Lean : le flux tiré et la résolution de problème quotidienne par le PDCA avec les équipes et par l’A3 avec les managers.
Le flux tiré organise le travail en fonction de la demande client : une User Story ne progressera vers l’étape suivante que si l’étape suivante du processus est disponible et est en mesure de la traiter. Les tableaux pour gérer les User Stories ne sont pas des kanbans. Comme notre flux était poussé et sans limite de WIP, nous nous sommes retrouvés avec des testeurs submergés de user stories à valider.
Malgré les résultats, il reste des challenges et des défauts à supprimer : autant de place pour s’améliorer comme toujours en Lean. Mais dorénavant l’équipe est sur la bonne voie.