Portfolio Kanban – Comment Gérer les Epics et les Caractéristiques

Lors d’une implémentation portfolio Kanban typique, les Epics se trouvent sur un tableau portfolio Kanban et sont fragmentés en ‘stories’ d’utilisateurs placées sur différents tableaux Kanban d’équipe. 

Par exemple, on peut avoir un seul  Portfolio Kanban et trois tableaux Kanban d’équipe – Dev Team 1, Dev Team 2 et Dev Team 3. Voyez ci-après un exemple de structure possible : 

Cette structure est d’une grande aide pour la visualisation et la transparence, mais un problème important est souvent négligé. Il arrive un peu plus tard dans le process et c’est une forme de gaspillage, de perte, appelé « Scatter » (dispersion). 

Définition de scatter : actions ou inactions rendant la connaissance et l’information inefficace en interrompant son flow. 

Mais qu’est ce que cela veut dire en réalité ? Dans neuf compagnies sur dix, l’équipe 1 ne sera pas au courant de ce que fait l’équipe 2 ou l’équipe 3. Les équipes travaillent généralement en vase clos et sont rarement informées de ce qu’il se passe en dehors de leur bulle.  

Cela ne sera pas un souci si les équipes travaillent sur des Epics différents, mais sitôt que deux équipes ou plus travaillent sur le même, les choses prennent presque toujours une tournure dramatique. 

Imaginez une situation dans laquelle quatre équipes travaillent sur le même Epic et que chacune d’entre-elles doit contribuer à une seule Story (une seule tâche). Si vous allez plus loin et que vous mesurez les temps de chaque Story et que vous les comparez au cycle de temps de l’Epic, vous noterez quasiment toujours quelque chose comme ce qui suit (nombres extrapolés) : 

Attendez un peu ! Comment se fait-il que les temps de cycles des stories d’utilisateurs font 28 jours (approx. 1 mois) alors que l’Epic quant à lui a nécessité 4 mois pour être complété ? 

Et bien, c’est à cause du scatter (la dispersion) – l’information et la connaissance sont tellement dispersés entre les équipes que le flow au niveau du Portfolio Kanban est interrompu. 

Il y a aussi très souvent des problèmes de synchronisation, de communication, de nombreuses stories urgentes etc. Pour régler tout cela, il nous faut regarder de plus près une mesure appelée Efficacité du Flow. 

Qu’est-ce que l’Efficacité du Flow ? 

Une version courte de la définition des termes ‘efficacité du flow’ pourrait être « Ratio entre le temps passé à créer/ajouter de la valeur (valoriser) et le temps de cycle total. » Créer/Ajouter (valoriser) de la valeur correspond au temps hors attente et hors blocage. Prenons l’exemple suivant pour simplifier les choses : 

Si vous avez besoin de 8 heures pour terminer une tâche donnée mais que vous ne travaillez dessus que 2 heures sur la journée (temps de valorisation), alors l’efficacité du flow sera de 2/8 x 100 = 25 %. 

Efficacité de Cycle du Process [%] = Temps de Valorisation / Temps de Cycle x 100 

Nous avons déjà parlé du temps de non-attente et de non-blocage, alors il convient de les définir. 

Temps d’attente 

C’est le temps qu’une carte donnée de votre tableau Kanban passe à attendre quoi que ce soit. L’attente est l’une des sources de perte/gaspillage les plus communes dans toutes les entreprises. 

Temps de blocage 

C’est le temps passé par une carte Kanban donnée de votre tableau dans un état de blocage. On considère qu’une carte est bloquée lorsqu’elle ne peut pas avancer dans le workflow pour quelque raison que ce soit. Typiquement on parle souvent de défaut, de manque de ressources ou de capacité, etc. 

Afin d’adapter le calcul au temps de blocage en utilisant la formule ci-dessus, il faut noter ce qui suit : 

Temps de Valorisation – Temps de Cycle – Temps d’Attente – Temps de Blocage 

Efficacité du Flow au Niveau Portfolio Kanban 

La formule pour calculer l’efficacité du flow au niveau portfolio est toujours la même. Cependant les définitions de Temps de blocage et d’attente sont différentes. 

Calculer les temps d’attente devient un petit peu plus complexe car il existe plusieurs scénarii en fonction du fait que les ‘stories’ d’utilisateurs puissent ou non être traitées en parallèle. Penchons-nous sur ces différentes possibilités une à une : 

Scénario 1 : Toutes les ‘stories’ d’utilisateur doivent être exécutées successivement. 

Dans ce scénario, tout retard pris dans le démarrage d’une nouvelle story dès la complétion de la précédente entraînera du temps d’attente. De même, tout bloqueur présent dans les ‘stories’ d’utilisateur affectera directement le temps de cycle de l’Epic en entier, on considère d’ailleurs que cela représente du temps de blocage pour ce dernier. 

Toute attente au niveau des stories d’utilisateurs s’accumule pour l’Epic dans sa globalité et est donc considéré comme tel. 

Scénario 2 : Toutes les ‘stories’ d’utilisateur peuvent être exécutées en parallèle. 

Idéalement, dans ce scénario, le temps de cycle de l’Epic entier devrait correspondre exactement au temps de cycle de la plus grande story d’utilisateur. Le temps de non valorisation serait donc représenté par le temps séparant le temps de cycle actuel de l’Epic et le temps de cycle idéal de la story d’utilisateur la plus longue. 

Scénario 3 : Quelques stories d’utilisateur ne peuvent pas être démarrées avant d’autres, mais certaines peuvent être traitées en parallèle. 

Dans la pratique, c’est le scénario le plus courant (avec quelques variations cependant…). Calculer le temps d’attente ici s’apparente au concept de management de projet de Chaîne Critique (CCPM). Voici les différents cas possibles : 

• Tout retard dans le démarrage d’une story dès la complétion de la précédente est considéré comme du temps d’attente
• Tout blocage sur une story non-parallèle est considéré comme du temps de blocage
• Tout blocage sur la plus grande story parallèle est considéré comme du temps de blocage
• Un blocage sur une story parallèle qui n’est pas la plus longue ne doit pas systématiquement être considéré comme du temps de blocage. Cela dépend s’il peut ou non être ‘caché’ derrière la plus grande story
• Tout temps d’attente au niveau story d’utilisateur s’accumule en temps d’attente pour l’Epic entier s’il concerne la Chaîne Critique. 

Pourquoi l’Efficacité du Flow est Elle aussi Importante au Niveau Portfolio Kanban ? 

Imaginez un scénario du réel dans lequel un département de R&D travaille sur plus de 50 Epics. Ces derniers sont fragmentés en plus de 200 stories d’utilisateur qui seront traitées par plus de 5 équipes différentes. Voilà une situation vraiment compliquée à gérer, et la plupart du temps personne ne sait où se trouvent les éléments et pourquoi cela prend tant de temps pour les terminer. 

Si l’on ne prête pas une attention toute particulière au management de l’efficacité du flow au niveau Portfolio Kanban, alors une équipe pourrait très bien entamer la première story d’un Epic alors qu’un autre Epic aurait nécessité d’être bouclé. Mais encore aurait-il fallut être mis au courant. 

Le manque de synchronisation au niveau Portfolio peut entraîner une inefficacité et des retards monstrueux. C’est la raison pour laquelle lorsque l’on gère l’efficacité du Flow au niveau Portfolio Kanban, il est tout à fait envisageable d’atteindre une progression de 300 %, parfois même davantage.

In Summary

Surveiller et gérer l’efficacité du flow au niveau global est un prérequis important pour parvenir à des process de travail performants et efficaces. Mesurer l’efficacité du flow au niveau Portfolio Kanban vous permettra de : 

• Améliorer l’efficacité du cycle des opérations
• Distinguer et mesurer les données de manière plus précise pour diverses structures du workflow
• Identifier les bloqueurs qui ralentissent le process de travail dans son ensemble