Il y a quelques mois, une responsable d’équipe IT souhaitait que je l’aide à démontrer à son manager que son équipe s’améliorait régulièrement. Dernièrement, elle m’expliquait les nouvelles difficultés de son équipe qui utilise la démarche Agile ; plus précisément des pratiques entre Water-Scrum-Fall et Scrum-But. La principale différence avec d’autres équipes fonctionnant ainsi, c’est qu’elle est consciente de cet écart par rapport à Agile et Scrum et qu’elle essaie de bouger les lignes pour se rapprocher des modèles.

Je disais donc que la responsable m’expliquait ses difficultés :

• Un client qui souhaite 4 livraisons par an, car il n’arrive pas à s’organiser pour tester régulièrement des livraisons de sprint de deux ou trois semaines. Il préfère donc des « grosses » livraisons à l’ancienne. Pour autant, l’équipe ne souhaite pas repartir dans un cycle en V et désire poursuivre sa pratique de la démarche Agile et ce même si le responsable d’équipe jouera le rôle de Product Owner (PO) à la place du client et si chaque livraison sera un ensemble de livraisons de sprints intermédiaires.
• Des stories incomplètes pour développer convenablement les fonctionnalités des différents sprints. Cela génère des échanges entre l’équipe et le client pendant les développements en plus de la frustration des développeurs.
• Une valeur ajoutée pour le client limitée dans les précédents sprints, car de nombreuses corrections ont dû être traitées après détection d’anomalies par le client.

Un coach n’apportant pas de solution, je commençais alors à la faire réfléchir.

Voir la valeur pour le client

• (moi) Ok, que cherchez-vous (l’équipe) à voir avec votre management visuel ?
• Ce que nous livrons au client.
• (moi) Mais encore ?
• Les nouvelles fonctionnalités et les corrections.
• (moi) Oui, et plus précisément ?
• Euh… La valeur que l’on délivre au client ?
• (moi) Oui ! Et comment connais-tu la valeur que l’équipe délivre ?
• Par le nombre de stories livrées à chaque sprint.
• (moi) Plus précisément le nombre de stories livrées et acceptées – c’est-à-dire celles que le client a vraiment commandées et qui sont sans défaut. Si tu lui livres des fonctionnalités qu’il n’a pas demandées, tu es dans la surproduction, une des 7 familles de gaspillages. Quant aux corrections intégrées à une livraison, il ne s’agit pas de valeur ajoutée mais de retouche, une autre famille de gaspillage. Et que fais-tu de ce nombre ?
• Nous souhaitons vérifier que nous livrons toujours un peu de plus de valeur au client. Chaque sprint doit être plus performant que le précédent, même si, in fine, la livraison au client sera un ensemble de sprints.
• (moi) Super ! Et comment l’équipe saura qu’elle progresse ou pas ?
• Cette valeur sera calculée à chaque fin de sprint et affichée sur le management visuel.
• (moi) Parfait ! Une dernière chose, comment l’équipe se challenge-t-elle sur le nombre de stories à réaliser dans le prochain sprint ?
• …
• (moi) C’est super de faire en sorte que l’équipe puisse s’améliorer et pour y arriver il est préférable qu’elle se fixe un objectif ambitieux mais crédible. Je ne sais pas combien de stories elle a l’habitude de livrer, mais elle pourrait se donner comme objectif +5 ou +10 % à chaque sprint. Il est important de noter qu’un objectif peut être revu à la baisse ou à la hausse en fonction des résultats obtenus et de la situation de l’équipe.
• Ok, j’ai compris.

Voilà maintenant une équipe capable de se fixer des objectifs d’amélioration et de suivre sa performance quant à la valeur délivrée au client. Voyons comment l’aider pour améliorer la qualité du produit qu’elle réalise.

Voir et comprendre les problèmes de qualité

• (moi) Passons aux problèmes de qualité ; comment les vois-tu aujourd’hui ?
• C’est le problème… le client en détecte bien plus que nous et quand j’essaie de voir avec l’équipe ce que nous avons identifié, je n’ai pas d’info ou si peu pour être exploitable.
• (moi) Je vois. As-tu une idée de comment faire ?
• À part augmenter la phase de recette, je ne vois pas.
• (moi) En informatique, les équipes testent déjà trop… ça fait bizarre dit ainsi, mais tu liras l’article Vous, les informaticiens, vous testez trop ! En Lean Management, il existe ce qu’on appelle le Mur de la qualité qui doit protéger le client de tout défaut. L’auto-qualité et le bac rouge permettront à l’équipe de ramener la qualité au cœur du processus de développement et réduire ainsi les anomalies. En mettant en œuvre ces principes, plus un autre que nous verrons un peu plus tard (le flux tiré avec le one piece flow), tu vas passer progressivement de contrôler la qualité des développements à réaliser des développement de qualité, ce qui réduira de facto ta charge de recette.
• L’auto-qualité et le bac rouge…
• (moi) Je te laisse regarder les vidéos de Christophe sur l’auto-qualité et le bac rouge. En synthèse :
  • L’auto-qualité permet à chaque membre de l’équipe de déterminer ce qui doit être contrôlé avant le passage à l’équipe suivante (ou au processus suivant). Ces vérifications sont spécifiques à chaque équipe. Le principe visé est de ne pas produire de défaut et surtout de ne pas les transmettre. Le processus suivant a le droit (et le devoir) de refuser les livraisons non conformes à ses attentes. L’auto-qualité (ou auto-contrôle) est source d’autonomie et de confiance comme l’explique Frédéric.
  • Le bac rouge, issu de l’industrie, permet à chaque étape du processus de rendre visible les défauts de qualité. Dans l’industrie, un opérateur détectant une pièce défectueuse la dépose dans un bac rouge. L’idée est d’appliquer le même raisonnement en développement logiciel. Dès qu’il y a plusieurs pièces dans le bac rouge, l’équipe s’y intéresse, réalise un Pareto des défauts et s’attaque ensuite à la résolution du principal sujet (la tête de Pareto). Il est également possible de réaliser un Pareto dynamique pour visualiser rapidement la tête de Pareto. En agissant ainsi, l’équipe est dans une démarche d’apprentissage et d’amélioration continue par les petits pas.
• L’auto-qualité, c’est des check-lists que l’équipe définit ?
• (moi) Oui. Tu les fais réfléchir à ce que veut le client et comment chaque étape de réalisation peut, à son propre niveau, contribuer à la qualité intrinsèque du produit.
• Et pour les bacs rouges, je fais comment sur le management visuel ? Une colonne par étape du processus ? Une colonne pour tout ?
• (moi) Rappelle-toi ce que j’ai dit… À chaque étape du processus.
• Oui, ok ! Donc, une colonne supplémentaire dans chaque étape. Si l’équipe détecte un défaut, elle met le post-it de l’étape ayant introduit le défaut dans le bac rouge ; c’est ça ?
• (moi) Oui, tu as tout compris.
• Je mets ça en place avec l’équipe.

Résultats

Deux semaines plus tard, je croise de nouveau la responsable d’équipe qui me dit – toute radieuse – que les bacs rouges sont en place et que l’équipe est capable d’identifier les types de défauts sur lesquels elle bute. Elle-même a pu, avec ce principe, s’apercevoir qu’elle devait faire un effort sur la rédaction des stories pour éviter les zones d’incertitude. L’équipe a également repris le principe du Pareto pour catégoriser les anomalies remontées par le client sur les 3 derniers sprints. Il est encore trop tôt pour voir un vrai changement sur le nombre de stories délivrées par l’équipe.

En fonctionnant ainsi l’équipe s’est mise dans de bonnes dispositions pour réussir :

• Elle apprend d’elle-même et de ses expériences (même si l’équipe n’a pas encore été coachée sur la résolution des problèmes et son PDCA).
• Elle se donne un nouvel objectif à chaque sprint.
• Elle réduit ses gaspillages (notamment les retouches) pour délivrer plus de valeur à son client.
• Elle intègre dans son temps de travail l’amélioration continue.

Et dans votre équipe, où en sont le management visuel, les Paretos et les bacs rouges ?

Photo : nébuleuse d’Orion, 2006, source Hubble Space Telescope, NASA