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.

Dans cette 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 la 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)

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 :

1. Développer des fonctionnalités est notre principal objectif car c’est ce qui a de la valeur pour les clients

1. 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.
2. 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 ?

1. De nombreuses anomalies en masquaient d’autres qui sont apparues au fur et à mesure que l’on en corrigeait
2. Les corrections d’anomalies ont introduit des régressions car une partie de notre patrimoine logiciel avait une faible couverture en tests automatiques
3. 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.
4. 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 :

1. La pièce (ou unité d’œuvre) qui parcourt le processus
2. Le processus lui-même et ses différentes étapes.
3. 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 :

1. 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).
2. 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.
3. 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é :

1. Considérer la User Story comme l’unité d’œuvre (ou la pièce)
2. Faire un suivi quotidien
3. Utiliser un management visuel pour le pilotage du projet
4. Faire le suivi formel de l’analyse fonctionnelle
5. Intégrer un testeur dans l’équipe
6. Geler les mises à jour à la fin du sprint
7. 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 :

1. Former les gens aux User Stories
2. Coacher les analystes fonctionnels pour les aider à définir les bonnes user stories (granularité, valeur, critères d’acceptation)
3. 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

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

à suivre …