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 qui ont permis à notre R&D de supprimer des gaspillages dans le processus de développement et d’obtenir des résultats encourageants.

Dans la première partie, nous décrivons le contexte, le problème sous forme d’écart de performance opérationnelle, et les premiers changements que nous avons mis en oeuvre.

Dans cette seconde partie nous décrivons quatre autres pratiques, les résultats obtenus ainsi que les enseignements.

(Article publié en anglais sur le site InfoQ en Juillet 2014 et édité par Ben Linders – traduction Florence Préault)

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.