Le nouveau cas d’étude que je vous propose aujourd’hui porte sur le thème de la qualité et de la gestion des anomalies par une équipe Scrum.

 

Le contexte de l’étude de cas

 

Hélène est une jeune ScrumMaster d’une équipe Scrum dans une société d’édition de logiciel.

 

Elle a des difficultés pour amener à l’équipe à avoir une production dite prédictive. Sa ligne managériale et la ligne managériale du Product Owner sont aussi inquiètes. Ils n’ont pas les éléments leur permettant de faire des projections pour identifier les éléments qui pourront être embarqués dans la prochaine version. Cette projection doit pouvoir aider l’équipe marketing à préparer le discourt de vente de la prochaine version de leur logiciel phare. Ce discours de vente est capital. En effet, le produit bien qu’il soit le produit phare, commence à perdre des parts de marchés.

 

L’enjeu est fort. Il amène du stress à l’équipe pour sortir un maximum de chose d’ici la date qui a déjà été annoncé. Le stress est accentué quand des défauts de fonctionnement sont détectés et remontés par les clients. L’urgence du correctif passe avant la construction et l’équipe pour diminuer le temps de sa sortie effectue un bon nombre de raccourcis qui provoqueront à leur tour des dysfonctionnements. L’équipe est consciente que le nombre de défaut croissant est un vrai handicap pour elle et les futures versions. Cette dégradation est de mal en pis.

 

Le thème évident de l’intervention est essentiellement sur la qualité du produit et ses conséquences. Or la demande formalisée par l’équipe est une assistance pour mieux gérer les anomalies dans un cadre Scrum.

 

Première phase d’intervention : comprendre ce qui pose problème à cette équipe et à l’organisation

 

En écoutant l’équipe Scrum, les plaintes qu’elles me remontaient étaient :

 

  • Les utilisateurs ne savent pas bien exploité la solution, ils ne lisent pas le manuel d’utilisateur qui est fourni avec la solution.
  • Les clients ne savent pas ce qu’ils veulent
  • Ils nous disent que c’est un bug alors que pour nous c’est une évolution car nous avons livré ce qui a été demandé nous livrons ce qui a été demandé

 

Pour commencer, il est important d’identifier les sources des défauts. Sans typologie et catégorisation des défauts, nous ne pourrons pas apporter une solution adéquate pour tarir la source.

 

Nous avons 3 grandes familles de défaut.

 

  • Les erreurs de fabrication : issues de notre processus et de notre manière de proceder, y est inclue l’accompagnement au changement. En effet, c’est les moyens mis à disposition des utilisateurs pour appréhender la nouvelle solution.
  • Les erreurs d’usage : issues de la façon le client et l’utilisateur exploite la solution dans le leur contexte, en fonction de leurs contraintes. Elles portent souvent sur des aspects d’ergonomie ou est la résultante d’une défaillance de notre accompagnement au changement soit par une rédaction d’un manuel d’utilisation non adéquat, soit que l’accompagnement n’a pas été en phase avec les contraintes des utilisateurs.
  • L’évolution des besoins : malgré le temps passé et la qualité de la rédaction d’expression de besoin détaillée et le temps mis à livrer le produit. Il peut s’écouler plusieurs mois entre ce qui était important pour les utilisateurs et les clients et la livraison. Or, dans nos univers si changeant, les besoins évoluent. La réponse apporté plusieurs mois après n’est plus forcement la plus adapté au problème du moment. Ce décalage, du point de vue des utilisateurs et des clients, est un défaut.

 

Le retour d’un client quelqu’il soit est précieux et nous donne une indication de ce qui peut être améliorer.
Ce retour est toujours une source d’apprentissage même pour nous relever quelque chose qui fait mal à notre égo puisqu’il nous renvoie à nos imperfections.

 

Deuxième phase d’intervention : de qualifier et quantifier les sources du problèmes

 

Pour cela, l’équipe d’Hélène a mis en place un mécanisme de catégorisation et de mesure du temps réellement consacré à l’analyse et la correction des défauts. Pendant cette periode, la vélocité est un peu plus faible puisque qu’une partie de l’énergie de l’équipe se focalise sur la mesure et la qualification des défauts. Une communication préparatoire a été faite pour prévenir des différents effets de la mise en place d’un tel dispositif. Hélène avec le Product Owner ont été chargé d’expliquer aux différentes parties prenantes du produit le but rechercher et les effets potentiels comme la diminution du volume de ce qui sera produit durant les prochaines semaines.

 

Lors de cette qualification l’équipe c’est posé une autre question : Est ce que les anomalies se concentrent sur une partie de la solution ?

 

Après un certain temps de mesure, l’équipe avait besoin de pouvoir communiquer et de décider sur quoi elle devait commencer à travailler. Pour cela, elle a décidé d’utiliser un diagramme de Pareto.

 

A la lecture des diagrammes, l’équipe constat le résultat sans appel suivant : 75 % des anomalies proviennent du processus de fabrication, 20% sur l’évolution des besoins et 5% sur les usages.
Quant aux zones touchés par la solution, seulement 3 modules la constituant concentrent 80% des retouches.

 

Troisième phase d’intervention : Définir une cible à atteindre

 

La mesure sur 2 sprints a donné l’information du temps passé malgré sa volatilité, l’équipe passe entre 35 % et 55 % de son temps à corriger les défauts avec les urgences associées.

 

Avec ces informations, l’équipe souhaite passer moins de 15 % de son temps à la correction d’anomalie. Pour obtenir ce résultat, elle doit apporter des modifications sur son processus de fabrication.

 

Pour s’assurer de la progression, l’équipe continuera à mesurer le temps passé et identifier les sources des anomalies.

 

Quatrième phase d’intervention : identifier et mettre en oeuvre les premiers expérimentations

 

Maintenant, l’équipe et Hélène s’orientent vers une philosophie Zero-Défaut. Tout ne sera pas parfait tout de suite et l’équipe et son entourage en sont conscients.

 

Pour commencer, l’équipe et Hélène vont devoir définir une nouvelle approche pour améliorer la façon dont elles procèdent pour construire le produit. Pour commencer, elles doivent revoir la façon dont elles utilisent et effectuent la rétrospective. Car si elle en est là c’est que l’objectif premier de la rétrospective n’est pas exploité à leur juste valeur.

 

Les actions à court terme

 

L’équipe décide de revoir sa façon de définir ce qui est terminé (DoD – Definition of Done) pour y intégrer plus de vérifications au fils de l’eau.
Lors de la réalisation du Sprint, l’équipe se partage en 2. 50 % de l’équipe s’occupent des nouvelles fonctionnalités et 50 % de gérer les anomalies et les urgences. Le sprint d’après, il y a une rotation pour que cela ne soit pas toujours les mêmes qui corrigent et gèrent les urgences de production afin de maintenir le niveau d’implication, de concentration et de motivation des uns et des autres.

 

Pour avoir une meilleure efficacité en termes de qualité, l’équipe décide de mettre en place des relectures croisées et de prendre 1/2 journée pour comprendre les besoins exprimés et à construire dans le sprint suivant.

 

Pour cette demi-journée, les membres de l’équipe doivent apprendre à explorer le besoin. Or ils ont été habitués à ne pas poser de question et ne pas chercher à comprendre le besoin car c’est le rôle du PO. Pour être efficace, il faut que le PO puisse donner tous les détails du besoin.

 

Cependant, et force de constater avec l’équipe que cela ne fait que renforcer les erreurs de fabrication du produit car le PO ne peut pas tout savoir. D’autre part, une partie des membres n’osent pas poser de question par peur et crainte de passer pour des personnes incompétentes. Il va falloir faire tomber les barrières mises. Pour dépasser cela, je leur ai proposé une forme d’atelier différent et sur un sujet qu’ils maîtrisent afin de ne pas compliquer la démarche entreprise. La forme de l’atelier est simple. Les membres de l’équipe doivent chercher à surmonter une difficulté technique actuelle.

 

Pour cela, ils doivent respecter une unique règle : les échanges ne se font que part des questions. Au début, il est nécessaire de rappeler la règle mais au fur et à mesure, cela n’est plus nécessaire l’équipe s’habitue. Il a été aussi important de donner un exemple de ce que j’attendais sur la forme. Ils apporteront le fond. L’exercice fut un grand succès. Il leur a permis de surmonter la peur et la crainte qu’ils avaient. D’ailleurs, ils m’ont surpris car lors d’un des ateliers ou j’étais présent en supervision, l’équipe a utilisé ce format pour résoudre un problème fonctionnel.

 

Pour finir, l’équipe et Hélène ont décidé aussi de rendre visible les axes d’amélioration de leur processus et d’inclure un temps de partage avec les parties prenantes lors des présentations des travaux réalisés.

 

Les actions à moyen terme et long terme

 

Hélène va se former à la facilitation et approfondir sa connaissance sur les mécanismes du coaching qui sont sous-jacents à l’animation d’une démarche d’amélioration continue.

 

Comme le produit est un logiciel, l’équipe souhaite s’initier au Craftsmanchip et aux techniques d’ingénierie logicielle de l’eXtrem Programming comme l’intégration continue, le pair-programming ou le test driven development. Nous planifions ensemble plusieurs dates pour travailler ces points en particulier et voir comment ils vont les intégrer dans leur processus de fabrication.

 

L’autre point a été d’aider le Product Owner à identifier en amont les moyens d’assurer les compréhensions des besoins en utilisant la technique Acceptance Test Driven Development et Acceptance Test Driven Requirement.

 

Cinquième phase d’intervention : consolidation et bilan de l’intervention

 

Après plusieurs mois d’intervention, il était temps de la clôturer. Pour cela j’ai recours à un atelier de bilan et de clôture avec l’équipe et avec Hélène.
La réunion de clôture et de bilan a 2 objectifs majeurs :
Le premier objectif est de se rendre compte du chemin parcouru par l’équipe. C’est elle qui l’a fait !

 

Le deuxième est de permettre à l’équipe d’identifier ses nouvelles ressources et savoir qu’elle a maintenant à disposition pour résoudre ses difficultés provoquer par une variation de qualité.

 

Pour aller plus loin …

 

Actions …

 

Pour finir, ce cas d’étude peut être résolu de différentes façons, et si vous partagiez ce que vous auriez fait dans cette situation en commentaire ?

 

Références bibliographiques

 

Scrum – the Art of doing twice the work in Half the time – Jeff Sutherland

 

Visual teams – graphic tools for commitment, innovation, & high performance – David Sibbet

 

Toyota Kata – Managing people for improvement, adaptiveness, and superior results – Mike Rother

 

Atdd by example – A practical guide to acceptance test-driven development – Markus Gärtner

 

The coaching habit – Say Less, Ask More & change the way yo lead Forever – Michael Bungay Stanier

 

Humble Inquiry – Edgar H. Schein

 

Lean Software development – An Agile Toolkit – Mary & Tom Poppendieck

 

Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor and Lead – John Shook

 

Vous avez aimé ce billet ? Vous souhaitez recevoir chaque nouveau billet dans votre messagerie ? Histoire de Réussir