Bien souvent je travaille avec des équipes, agiles ou non, dont l’attention se porte naturellement sur la fourniture de nouvelles fonctionnalités. Or, dans cette course à la production de valeur pour rester compétitif face à la concurrence, les équipes doivent faire un choix. Elles se retrouvent régulièrement dans cette situation compliquée où il faut faire un compromis entre développer une nouvelle fonctionnalité ou corriger des anomalies.

Sous la pression du marché, le choix se porte un peu trop souvent sur la livraison de la nouvelle fonctionnalité. La dette technique s’accumule et imperceptiblement le nombre d’anomalies augmente. Et par conséquent les délais de résolution, avec les conséquences qui en résultent sur la satisfaction des clients et du métier, ainsi que sur le moral des équipes. Ceci est contraire à l’esprit DevOps qui préconise de travailler sur 4 indicateurs clef dont l’un est le « Mean Time To Repair » (MTTR – cf Wikipedia), le temps moyen de réparation.

Je vais vous expliquer comment je traite ce problème dans une équipe produit avec certaines pratiques de DevOps s’appuyant sur le management lean dans l’IT.

Prenons l’exemple d’une équipe en charge du développement d’une application mobile dans une grande société de distribution. L’équipe fait face à un stock de 40 incidents non traités. Ce stock est en constante progression. Malgré la mise en place ponctuelle de « tasks forces » pour le résorber, rien n’y fait. Au bout de quelques semaines, il repart à la hausse et la satisfaction des clients, elle, repart à la baisse. L’équipe, prise sous le feu croisé de la production et du business, est démoralisée. Une trop grande part de l’activité de l’équipe est imputée sur le budget du RUN sans que le DSI ne voie cette charge diminuer. La mise en œuvre des « tasks forces » est coûteuse à la fois sur le plan économique, sur le plan humain et sur le plan organisationnel. Or, réduire cette non qualité permettrait de réallouer ce budget au développement de nouvelles fonctionnalités et diminuerait le stress des équipes et l’impact sur l’organisation.

La démarche que j’adopte, en parallèle de la production de valeur, pour contrer cette situation est la suivante :

1 – Identifier les indicateurs de performance permettant de gérer la qualité

Le plus souvent nous avons 4 indicateurs clefs :

• La satisfaction des clients
• Le stock d’incidents
• Le volume d’incidents entrants chaque jour
• La productivité de l’équipe (le # d’incidents traités par jour et par personne)

2 – Construire le management visuel de traitement des incidents

Ensuite, il s’agit de rendre le processus de traitement des incidents visible. La raison est de mettre en place un système visuel montrant à chaque étape ce qui bloque le processus afin de pouvoir déclencher les résolutions de problème/expérimentations sur les bons sujets. C’est à dire les causes de blocage du processus : problème de qualité dans la production intermédiaire, l’attente, les problèmes de compétences…

L’équipe construit son management visuel en représentant chacune des étapes du processus de résolution d’incidents. Elle le complète ensuite en plaçant les tickets d’incidents à l’étape de correction : analyse, développement, revue de code, test par exemple.

La mise en œuvre de ce management visuel demande de la pédagogie car c’est une évolution de ce que les équipes ont l’habitude de faire dans une démarche Scrum ou Kanban.

3 – Fixer la cible d’incidents à traiter par jour

L’étape suivante est de déterminer la cible (C). L’objectif dans le cas présent est de supprimer un stock d’incidents afin de retrouver la pleine satisfaction des utilisateurs. Notre cible est donc le nombre d’incidents à corriger par jour par l’équipe.

Pour cela, j’utilise une formule magique : C = V + S/D

• Un délai raisonnable mais ambitieux en jours pour supprimer le stock (D)
• Le nombre d’incidents dans le stock (S)
• Le volume moyen de nouveaux incidents par jour (V)

Dans notre cas :

• D = 40 jours
• S = 40 incidents
• V = 2

Pour supprimer le stock en deux mois, soit 40 jours, l’équipe doit résoudre 3 incidents chaque jour (2 + 40/40).

Bien entendu cette cible doit être raisonnable et s’inscrit dans la production globale de l’équipe. La variable d’ajustement étant la période de temps choisie pour supprimer le stock.

4 – Tirer le flux

Après avoir calculé cette cible quotidienne, l’équipe choisit chaque matin quels seront les incidents à traiter dans la journée. Ces incidents sont visualisés à la sortie du processus avec une couleur rouge. A chaque fois qu’un incident est corrigé l’équipe change la couleur de l’incident correspondant en vert. De la sorte, à la fin de la journée, d’un seul coup d’œil, elle peut se rendre compte si la journée a été réussie ou pas.

Je vous épargne le cours sur le flux tiré, mais c’est bien avec ce principe qu’on arrivera à augmenter significativement le nombre de tickets traités par les équipes.

5 – Résoudre les problèmes

Si à la fin de la journée tous les incidents choisis le matin ne sont pas au vert, c’est que l’équipe a rencontré un obstacle et qu’elle n’a pas réussi à le surmonter. C’est une excellente opportunité pour faire de la résolution de problème et apprendre quelque chose de nouveau.

L’équipe se concentre sur les incidents restés en rouge et se pose la question : pourquoi ? Une technique très puissante est de le faire 5 fois. C’est la technique des 5 pourquoi qui permet de remonter à la cause racine du problème et d’éviter de se jeter sur des actions approximatives trop rapidement. Tout le travail ici est de comprendre très précisément ce qu’il est advenu pour mettre en place des contre-mesures efficaces qui vont apporter une amélioration définitive. Les causes peuvent être multiples : les logs ne sont pas assez précis pour identifier clairement les causes de l’incident, la personne en charge de la résolution n’a pas toutes les compétences, la correction a eu un effet de bord décelé pendant la phase de tests, etc.

Une des forces du flux tiré est de montrer aussi les dépendances avec les autres équipes. Cela permet de développer le travail en équipe au sens large, en faisant travailler des collaborateurs de différents services sur un même sujet et donc de mieux comprendre les dépendances entre les systèmes et les organisations. Cette meilleure compréhension peut conduire à repenser les systèmes afin de réduire ces dépendances.

Les contre-mesures apportées sont de plusieurs ordres :

• Le renforcement de la collaboration en supprimant les silos par exemple et en construisant des équipes pluridisciplinaires Business, Développement, Opérations, Assurance Qualité.
• L’automatisation de certaines parties du flux de production avec des systèmes de « Continuous Integration » et de « Continuous Delivery » permettant de réduire les boucles de feedback pour réduire le MTTR, « MeanTime to Repair »
• La mise en place de formations spécifiques à la fois sur les aspects fonctionnels de l’application mais aussi sur des pratiques opérationnelles différentes comme l’utilisation des design pattern, le « Test Driven Development » ou le « Behavior Driven Development » (liste non exhaustive). Ces dernières permettant d’améliorer significativement la robustesse des applications.
• L’outillage des applications avec des systèmes renforçant leur sécurité ou leur capacité à être auditées (meilleure politique de log pour le « trouble shooting » par exemple).

6 – Mettre à jour les indicateurs de performance

Chaque jour l’équipe met ses indicateurs de performance à jour. Plus spécifiquement les indicateurs concernant le stock, le volume d’incidents entrants, ainsi que l’indicateur de productivité.

Ce dernier est un des plus intéressants car il mesure l’efficacité des contremesures mises en place par l’équipe. En effet, au fur et à mesure des améliorations, l’équipe gagne en capacité et peut traiter plus d’incidents tant qu’il y en a, et reverser cette nouvelle capacité à la production de valeur quand la qualité est au maximum.

Il montre aussi la variabilité dans le processus. En effet la multitude des problèmes que rencontre l’équipe chaque jour influence sa capacité de livraison. Un jour elle livrera 2 incidents le lendemain 0 puis le surlendemain 1 puis 4 et ainsi de suite. Or, pour que l’équipe travaille sereinement, on recherche une certaine forme de stabilité. Cela fait partie de mon expertise lean de montrer aux collaborateurs comment y parvenir.

7 – Mettre à jour l’indicateur de satisfaction client

L’indicateur de satisfaction client est particulièrement important car il permet de mesurer la valeur perçue de l’application mise à disposition des utilisateurs. A chaque fois que j’ai travaillé de cette manière, la suppression des bugs a permis de remonter la satisfaction des clients de manière spectaculaire.

En revanche, arriver à la mesurer demande un peu d’imagination. En effet, plus on s’en éloigne de l’utilisateur final, plus il est compliqué pour les équipes d’obtenir un retour pertinent sur cette amélioration de la qualité.

Conclusion

Dans notre cas, l’équipe a réussi son pari de supprimer son stock d’incidents en 2 mois. Elle a continué à progresser dans la maitrise de la qualité en éliminant les récurrences, ce qui a contribué à réduire le volume de nouveaux incidents quotidiens. Au bout de 4 mois supplémentaires, le nombre de nouveaux incidents est passé de 40 par mois à 15. Tout ceci pour un bénéfice partagé par tous : le client avec une application beaucoup plus stable, le service support avec une charge moindre, le métier avec une capacité de production beaucoup plus importante et les collaborateurs avec beaucoup moins de stress, un métier intéressant et des perspectives enthousiasmantes.

---

Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous avec le formulaire ci-dessous !