Pourquoi une étape « Blocked » (« Bloquée ») dans votre Flux de Valeur est une fausse bonne idée !

16 octobre 2024

En tant que consultant en transformation Agile, je suis amené à accompagner des équipes, dans des secteurs d’activités très variés. Une pratique courante que je retrouve dans nombre de ces équipes est l’ajout d’une colonne “Blocked” sur leur tableau de suivi d’activités (souvent sous Jira).

L’intention derrière cette colonne est de mettre en avant les tickets qui se trouvent temporairement bloqués, pour une raison ou une autre, ce qui peut sembler une bonne idée au premier abord.

Néanmoins, je pense que cette approche pose des problèmes de gestion du flux et peu gravement nuire à la visibilité du travail en cours.

Dans cet article, je vous propose d’explorer pourquoi cette colonne « Blocked » peut créer des inefficacités et comment Jira propose une solution plus adaptée grâce à l’usage du champ Flagged.

C’est quoi le problème avec la Colonne « Blocked » ?

La création d’une étape « Blocked », dans le tableau de suivi du flux d’activité d’une équipe peut représenter, au prime abord, une pratique confortable, permettant de concentrer à un même endroit tous les tickets se retrouvant bloqués dans le Flux et cela quelque soit l’endroit ou ils ont été identifiés.

Cependant, cette approche est trompeuse et peut engendrer plusieurs problèmes.

1. Perturber la Fluidité du Flux de Travail : La visualisation de l’état de votre flux d’activité est un élément important dans la gestion de votre processus. En déplaçant les tickets bloqués vers une seule colonne, on sort les tâches de leur étape actuelle (par exemple, « En cours de développement », « En test », etc.), ce qui empêche de voir où le blocage se situe réellement dans le flux. Cela complique la gestion des goulots d’étranglement et peut masquer des inefficacités.
2. Perte de Contexte : Lorsqu’un ticket est déplacé vers une colonne « Blocked », il perd le contexte de l’étape du processus où il se trouve. L’équipe ne sait plus à quelle étape précise se trouve le blocage (développement, test, validation, etc.), ce qui rend plus difficile l’identification des problèmes systémiques.
3. Encourager un Comportement Passif : Avoir une colonne « Blocked » peut involontairement encourager un comportement passif au sein des équipes. Si un ticket est bloqué, il est déplacé dans la colonne, mais aucune action claire n’est définie pour débloquer la situation rapidement. Le blocage devient moins visible dans le flux principal, et il y a un risque qu’il soit ignoré jusqu’à ce que la situation soit critique.
4. Complexifier les Mesures : Une colonne « Blocked » rend plus difficile l’analyse des métriques de flux telles que le Lead Time (Temps de Traversé du Flux) et le Cycle Time (Temps de Cycle), car les tickets passent artificiellement par une étape supplémentaire qui n’a pas lieu d’être. Cela fausse également les mesures de l’efficience du flux et rend plus difficile la détection des opportunités d’amélioration.

L’Utilisation de l’Indicateur « Flagged » dans Jira

Si vous êtes amené à gérer votre activités via l’application Jira, celle-ci vous offre une solution au travers du champ Flagged.

Flagged est un indicateur visuel permettant de signaler les tickets bloqués ou méritant une attention particulière, sans les retirer de leur contexte, c’est à dire de l’étape du flux ou ils se trouvent.

Voici pourquoi l’utilisation de cet indicateur est préférable à une colonne dédiée :

1. Maintien du Contexte : L’un des avantages majeurs de l’indicateur « Flagged » est qu’il permet de marquer un ticket comme bloqué, tout en le maintenant dans son étape actuelle du processus. Cela offre une visibilité immédiate sur où dans le flux se trouvent les blocages (par exemple, « En développement », « En test »), ce qui facilite l’identification des causes profondes des interruptions.
2. Visibilité accrue : L’indicateur « Flagged » dans Jira affiche un visuel distinctif (généralement une couleur jaune) qui attire l’attention de l’équipe sur les tickets qui nécessitent une intervention. Ce système permet à l’équipe de continuer à se concentrer sur le flux tout en gardant les blocages bien visibles, sans avoir besoin de déplacer les tickets dans une colonne séparée.
3. Métriques Précises : En utilisant l’indicateur « Flagged », le ticket reste dans son flux normal, ce qui permet de capturer des données précises sur les métriques comme le Lead Time et le Cycle Time. Le temps passé bloqué peut toujours être mesuré grâce aux dates de début et de fin du flag, sans pour autant perturber le reste des métriques de flux.
4. Encourager des Actions Rapides : Le « flagging » met en lumière les tickets bloqués sans les sortir du flux, ce qui incite l’équipe à agir plus rapidement pour résoudre les blocages, tout en leur donnant une vision claire de leur progression générale.

Comment Utiliser « Flagged » dans Jira pour Gérer les Tickets Bloqués

1. Configurer l’indicateur « Flagged » : Jira propose nativement l’option « Flagged », mais si elle n’est pas encore active dans votre projet, vous pouvez facilement la configurer. Il suffit d’ajouter l’indicateur via le menu d’options du ticket et de sélectionner « Flag as Blocked » (ou un libellé similaire selon la configuration de votre instance Jira).
2. Créer une Vue Dynamique des Tickets Bloqués : En utilisant l’indicateur « Flagged », vous pouvez également configurer des filtres ou dashboards Jira qui listent uniquement les tickets marqués comme bloqués. Cela permet de visualiser rapidement les blocages dans un tableau de bord dédié sans perturber le flux principal.

Wiveez vous aide à suivre les Tickets Bloqués

Pour les équipes qui utilisent Jira et cherchent à aller plus loin dans le suivi et la gestion des tickets bloqués, Wiveez propose une solution idéale.

Cette plateforme enrichit l’expérience dans la gestion des Flow Metrics et permet une visualisation plus précise et détaillée des tickets bloqués grâce à plusieurs outils spécifiques :

1. Le Aging Chart pour Suivre les Tickets en Cours et Bloqués : Wiveez offre un Aging Chart qui permet de visualiser la progression des tickets dans le temps, en mettant en évidence ceux qui stagnent ou se retrouvent bloqués. Grâce à l’utilisation du champ Flagged de Jira, les tickets bloqués apparaissent clairement, ce qui permet aux équipes de rapidement identifier et résoudre les obstacles dans le flux de travail.
2. Suivi des Tickets Bloqués dans les Backlogs : Dans chaque backlog de dashboard (produit, version, fonctionnalité, etc.), Wiveez affiche le nombre de tickets bloqués. Cette visibilité directe sur les blocages, sans avoir à quitter l’écran principal, permet une prise de décision plus rapide et une intervention proactive de la part de l’équipe.
3. Accès à une Page de Synthèse des Tickets Bloqués : Wiveez va plus loin en offrant aux utilisateurs une page de synthèse dédiée qui regroupe tous les tickets bloqués au sein d’un projet. Cette vue globale permet à l’équipe de suivre en un seul coup d’œil l’ensemble des tickets bloqués et de prioriser les actions nécessaires pour lever ces obstacles.
4. Visualisation et Amélioration Continue : En utilisant ces outils Wiveez, les équipes peuvent suivre non seulement où et quand les blocages surviennent, mais aussi combien de temps ils durent. Ces informations sont essentielles pour identifier les goulots d’étranglement récurrents, les dépendances problématiques et les zones à améliorer dans le flux de travail.

Take Away… Faites des blocages une priorité

Dans vos réunions quotidienne (stand-up), faites en sorte que les blocages soient au cœur de la discussion, afin d’encourager l’équipe à travailler collectivement pour les résoudre.

Pour les blocages nécessitant une analyse plus approfondie, n’hésitez pas à mettre en place des pratiques Lean.

A3 Problem Solving

Le A3 Problem Solving est une méthode structurée qui tire son nom du format de papier A3 utilisé pour documenter le processus. C’est un outil puissant pour analyser et résoudre les problèmes tout en assurant un alignement collectif autour des actions à entreprendre.

Les Étapes Clés du A3 Problem Solving :

1. Définir le problème : Il est crucial d’identifier le problème de manière claire et précise. Cette étape permet de comprendre l’impact sur les objectifs de l’équipe ou de l’organisation.
2. Analyser la situation actuelle : Visualiser le processus ou le système actuel est important pour bien comprendre où se situe le problème. Souvent, on utilise des outils comme les cartes de flux de valeur (Value Stream Mapping).
3. Fixer des objectifs : En identifiant les cibles, l’équipe sait clairement quel résultat est attendu après la résolution du problème.
4. Analyse des causes racines : À l’aide d’outils comme les 5 Why’s ou le diagramme d’Ishikawa (ou diagramme de causes et effets), l’équipe cherche à comprendre la cause profonde du problème.
5. Proposer des solutions : À partir de l’analyse des causes racines, l’équipe propose des solutions pour éliminer le problème.
6. Plan d’action : Les solutions sont traduites en actions concrètes, attribuées à des responsables et accompagnées de délais.
7. Suivi et ajustement : Après la mise en place des actions, l’équipe évalue les résultats et ajuste les actions si nécessaire. L’idée est de garantir que les problèmes sont résolus durablement.

Le A3 n’est pas simplement un document, mais un processus collaboratif qui permet d’améliorer la communication, d’aligner les équipes sur les actions, et de s’assurer que les obstacles sont traités de manière efficace et durable.

Les 5 Why’s (Les 5 Pourquoi)

La technique des 5 Why’s est une méthode simple et efficace pour découvrir la cause racine d’un problème. Elle consiste à poser la question « Pourquoi ? » cinq fois (ou autant que nécessaire) afin de creuser chaque réponse et d’aller au cœur du problème.

Exemple :

• Problème : « Le développement d’une fonctionnalité a pris du retard. »
  • Pourquoi ? Parce que la tâche était bloquée pendant deux jours.
  • Pourquoi ? Parce qu’une information clé manquait.
  • Pourquoi ? Parce que le fournisseur n’a pas répondu à temps.
  • Pourquoi ? Parce que la demande n’a pas été clairement communiquée au fournisseur.
  • Pourquoi ? Parce que notre processus de demande d’information externe n’est pas standardisé.

La technique aide à ne pas se contenter d’une explication superficielle, mais à identifier les problèmes systémiques et à les corriger.

Le Diagramme d’Ishikawa (ou Diagramme de Cause et Effet)

Aussi appelé diagramme en arête de poisson, le diagramme d’Ishikawa est un outil visuel qui aide à cartographier les causes potentielles d’un problème. Il est souvent utilisé en complément des 5 Why’s pour explorer et organiser différentes catégories de causes.

Les causes sont généralement regroupées en six grandes catégories :

• Méthodes (processus),
• Main-d’œuvre (personnes impliquées),
• Machines (outils, technologies),
• Matériaux (intrants utilisés),
• Milieu (environnement, conditions),
• Mesures (indicateurs, données).

Le diagramme d’Ishikawa permet de structurer la réflexion et d’explorer les différentes causes qui peuvent conduire à un obstacle ou à un problème.

Conclusion

L’ajout d’une colonne « Blocked » dans un tableau de suivi peut sembler être une solution simple pour signaler les blocages, mais elle tend à compliquer la gestion du flux de travail et fausse les métriques de performance.

L’utilisation, dans Jira, de l’indicateur Flagged permet de maintenir une visibilité claire sur les tickets bloqués sans perturber leur flux naturel, tout en facilitant l’analyse des blocages et en encourageant des actions rapides.

Grâce à des outils comme Wiveez, vous pouvez suivre efficacement les tickets bloqués, visualiser leur impact sur votre flux à travers des graphiques tels que le Aging Chart, et accéder à une page de synthèse qui centralise tous les tickets bloqués dans un projet.

Ce suivi avancé et transparent permet d’améliorer continuellement la performance de votre équipe et d’assurer un flux de travail fluide et optimisé.