Série “Les indicateurs d’équipe” : Le Lead time et le Cycle time
Nous présentons dans cet article le Lead Time et le Cycle Time, 2 indicateurs essentiels pour:
- Suivre votre projet,
- Anticiper des risques,
- Avoir une référence pour travailler sur de prochaines Epopées,
- L’amélioration continue de l’équipe.
Le Lead Time, qu’est-ce que c’est ?
Il s’agit de la durée passée entre le démarrage de l’analyse d’un sujet jusqu’à son implémentation finale.
Le Cycle Time, cela veut dire quoi ?
Nous vous proposons de mesurer 2 Cycle Time :
- Le Cycle Time Cadrage, il s’agit de la durée du cadrage,
- Le Cycle Time Delivery correspond à la durée du delivery,
Comme vous pouvez le constater, ces 2 Cycle Time forment le Lead Time.
A quoi correspondent le Lead Time et le Cycle Time dans nos équipes ?
Comme nous travaillons sur 2 niveaux de Kanban (Epopées (ou Epic) et Minimum Marketable Feature (ou MMF)), nous aurons donc différents types de Lead Time et de Cycle Time.
Il peut exister aussi un cycle time de stories, mais nous ne le traiterons pas dans cet article.
Au niveau des Epopées
- Le Lead Time pour une Epopée est la durée qui démarre du lancement de l’analyse d’un sujet, jusqu’à sa dernière mise en production.
- Le Cycle Time Etude/Cadrage pour une Epopée est la durée de cadrage du sujet,
- Le Cycle Time Delivery pour une Epopée est la durée à partir du lancement du développement de la 1ère MMF de l’Epopée jusqu’à la mise en production de la dernière MMF.
Sa représentation graphique
Au niveau des MMF
- Le Lead Time pour une MMF est la durée de lancement de son cadrage jusqu’à sa mise en production,
- Le Cycle Time Cadrage pour une MMF est la durée de cadrage du sujet,
- Le Cycle Time Delivery pour une MMF est la durée à partir du lancement du développement de sa 1ère story jusqu’à la mise en production de la dernière story.
Sa représentation graphique
Un outil de communication
Comme tout graphique, l’objectif est la communication. Les Lead Time et Cycle Time permettent de partager les informations sur le fonctionnement de l’équipe, mais aussi et surtout permettra de les diffuser en dehors de l’équipe (Métier, contributeurs, équipe IT …).
C’est un outil factuel qui permet à l’équipe de :
- Echanger, expliquer,
- Remonter des risques,
- Mettre en place des actions pour lever les risques,
- Prendre des décisions.
Quand consulter ces indicateurs ?
Ces indicateurs seront surtout consultés en fin de release, afin de faire un bilan, ou lors de la prise en compte de nouveaux sujets, pour avoir des estimations en fonction de la capacité de l’équipe et de son fonctionnement.
Mais, attention, il y a des contraintes
Il est indispensable de responsabiliser chaque membre de l’équipe et surtout les propriétaires des Kanbans Epopée et MMF sur la mise à jour manuelle les Epopées et MMF dans votre outil Kanban (exemple: Jira). Leur statut doit être au plus près de la réalité pour avoir des indicateurs utilisables et fiables.
Pour interpréter de bons indicateurs, le kanban doit être à jour.
Quelques exemples
Tout d’abord, une mise en situation :
La Squad “John Doo” prévoir des Releases qui durent 7 semaines (environ 35 jours ouvrés). Elle a décidé de présenter ses indicateurs suite à la mise en production de la release 3.
Nous voici en début de réunion.
Important : Dans un soucis de simplification, nous indiquerons dans nos exemples des numéros de MMF. Dans la réalité, il sera bien nécessaire de donner un titre compréhensible par l’équipe et — surtout — par le Métier et non un chiffre. D’autre part, l’échelle des graphiques est définie en nombre de jours.
Cas d’une équipe travaillant avec des spécifications fonctionnelles
Marc (Le Scrum Master) — “Bonjour, je viens de mettre en place les indicateurs Lead Time et Cycle Time. Je voudrais partager quelque chose avec vous et voir si l’on ne pourrait pas changer notre mode de fonctionnement. Ca vous va ?”
L’équipe est intéressée.
Marc (Le Scrum Master) — “On remarque que pour l’Epopée sur laquelle nous travaillons, nous avons eu 70 jours de cadrage, et pour la 1ère MMF, son cadrage a duré 60 jours, alors que les autres MMF n’ont que 11 jours de cadrage, en moyenne. Il n’y aurait pas un soucis ?”
Jean (le Techlead) — “Je vois ce que tu veux dire, la 1ère MMF a servi à analyser l’Epopée et non uniquement la fonctionnalité de cette MMF. On a fait une sorte de Spec. fonctionnelle. C’est pour cela que les MMF suivantes ont des phases d’analyse très courte car presque tout a déjà été fait.”
Frédéric (Le Product Owner) — “C’est vrai que si l’on s’était concentré uniquement sur l’étude de la MM1, nous aurons pu apporter cette fonctionnalité plus tôt et sûrement les suivantes aussi !”
L’équipe a calculé que si elle ne s’était concentrée que sur la MMF1 et non l’ensemble de l’Epopée, le Métier aurait eu la fonctionnalité au bout de 9ème semaine et non de 15 semaines, comme actuellement ! Elle a décidé de présenter ce résultat au Métier et d’analyser avec lui uniquement les MMF prioritaires qui seront prises en compte dans la prochaine Release.
Nous pouvons penser que le fait de faire des spécifications fonctionnelles nous sécurise car nous allons connaitre le besoin global du Métier. En revanche, pendant ce temps :
- Nous n’apporterons aucune valeur ajoutée à notre produit,
- Ne pourrons tester cette nouveauté après des utilisateurs,
- Ne pourrons réagir rapidement et changer notre stratégie produit si cette nouveauté n’est finalement pas bien reçue par l’utilisateur.
Cas d’un kanban dont le statut des Epopées ou MMF n’a pas été mis à jour
Abdallahi (Le TestLead) — “Je crois qu’il y a un soucis sur la MMF1, car le temps d’analyse est extrêmement court, alors que le développement est très long. On a aussi une MMF2 avec un développement court, alors que normalement, on délivre par Release, donc toutes les 7 semaines. Qu’en pensez-vous ?”
Frédéric (Le Product Owner) — “Oui, j’ai eu un petit loupé pour la MMF1 car j’ai réalisé un peu tard que je n’avais pas associé les stories à une MMF. Je l’ai créée en urgence !”
Iman (développeuse) — “Pour la MMF2, souvenez-vous, c’est le sujet qui a été pris en urgence, hors version. Donc, c’est tout à fait normal.”
Le Product Owner a décidé d’être plus vigilant sur la mise à jour des kanban d’Epopées et de MMF.
Sans l’interprétation de l’équipe de ce graphique, nous aurions pu penser qu’il s’agissait d’un problème de déplacement de cartes dans le kanban.
Cas d’un cadrage par priorisation, mais sans indicateur de succès
Frédéric (Le Product Owner) — “Je voulais vous présenter le Lead Time de nos MMF. Comme vous le voyez, on a des MMF stables que l’on délivre régulièrement. Nous sommes sur une MMF par Release ! C’est super !”
Abdallahi (Le TestLead) — “C’est très bien, mais est-ce que tu sais si ce que l’on délivre apporte réellement de la valeur à notre produit ?”
Frédéric (Le Product Owner) — “Hélas non.”
L’équipe a décidé de définir avec le Métier pour chaque prochaine Release des objectifs avec des indicateurs de réussite (les OKR) pour vérifier que ce qui a été développé a apporté une réelle valeur fonctionnelle.
Des livraisons régulières avec des MMF équilibrées sont importantes, mais il faut toujours définir les indicateurs de réussite pour vérifier que ce qui a été développé a apporté de la valeur à notre produit.
Cas de MMF complexes
Marc (Le Scrum Master) — “Bonjour, je voulais remonter peut-être une alerte sur les MMF. On constate que l’on passe autant de temps pour cadrer que pour développer. De plus, on constate que les stories sont très compliquées à développer.”
Iman (développeuse) — “On le voit bien dans le débit de notre dernière Release. Nous sommes 5 développeurs, et pourtant nous n’arrivons pas à développer plus d’une story par semaine !”
L’équipe a décidé de revoir la phase de cadrage du besoin avec le Métier, le découpage des MMF, l’écriture des stories et de faire intervenir l’équipe au plus tôt.
Pour cela, ils ont fait appel à la CoP La Famille Produit pour avoir des retours d’expérience d’autres équipes. Suite à leurs retours, l’équipe a décidé de lancer les ateliers :
- Le Story Mapping sur la prochaine Epopée pour analyser, découper et prioriser,
- L’Event Modeling pour analyser les futures MMF.
Un moyen d’optimiser le temps d’analyse est de lancer des ateliers collaboratifs pour permettre à l’équipe d’avoir le même niveau de connaissance, de découper, de prioriser ensemble, et d’être performant sur toutes les phases d’une MMF.
Cas de décalage fréquent de version
Jean (le Techlead) — “Bonjour, je voulais remonter une alerte. Je constate que, pour les 2 dernières MMF, nous avons doublé le temps de delivery car nous les avons décalées de la Release 2 à la Release 3. Or, nous avions prévu initialement que les MMF ne devaient pas durer plus d’une Release.”
Marc (Le Scrum Master) — “Oui, c’était pour apporter de la valeur ajoutée le plus tôt possible à notre produit et avoir du feedback des utilisateurs.”
Abdallahi (Le TestLead) — “Sur les deux MMF, nous avons eu énormément d’anomalies bloquantes à traiter. Nous avons vu cela avec le Métier qui nous a répondu que l’on ne pouvait pas monter les MMF2 et 3 sans correctif des anomalies bloquantes. c’est pour cela que l’on a décalé les 2 MMF dans la Release 3.”
L’équipe a analysé la situation en remarquant que les anomalies étaient dues à plusieurs facteurs :
- Des stories non INVEST,
- Un soucis de montée en compétence d’une partie de l’équipe récemment arrivée.
Suite aux échanges avec les différentes Communautés de Pratiques, l’équipe a décidé de faire obligatoirement des 3 Amigos avec l’Example Mapping pour avoir des stories INVEST et de mettre en place du pair-programming pour ses développeurs.
La qualité des stories des MMF et leurs compréhension est indispensable pour avoir un Lead Time performant.
Cas d’une comparaison entre deux métiers
Frédéric (Le Product Owner) — “Suite aux indicateurs sur le Lead Time que l’on vient de mettre en place, on va pouvoir présenter au Métier B que la durée d’analyse des MMF est énorme par rapport au temps de développements, contrairement au métier A.”
Abdallahi (Le TestLead) — “Cela va nous permettre de proposer au Métier B nos ateliers collaboratifs déjà mis en place avec le métier A, car on voit que cela marche. On met moins de temps pour l’analyse et on apporte 2 fois plus vite de la valeur ajoutée entre les 2 Métiers.”
L’équipe a décidé de faire témoigner le Métier A, pour présenter au Métier B les bénéfices de ces ateliers (Story Mapping, Event Modeling …).
Les indicateurs sont de très bon moyens de comparaison de méthodes de travail au sein d’une même équipe, mais avec des interlocuteurs différents.
Cas d’une MMF avec des contributeurs avertis au dernier moment
Abdallahi (Le TestLead) — “On voit bien sur cet indicateur que nous avons eu un soucis sur la MMF4, par rapport à notre historique de Lead Time de MMF. Cette MMF était interminable, mais elle est enfin en Production.”
Jean (le Techlead) — “La prochaine fois, il ne faudra pas oublier ce nouveau contributeur au lancement de prochaines MMF. Il a fallu attendre qu’il priorise notre sujet pour pouvoir terminer cette MMF.”
Marc (Le Scrum Master) — “On aurait peut-être pu créer une MMF spécifique pour sortir cette story de la MMF4. Cela nous aurait permis de délivrer cette dernière, sans attendre cette évolution.”
L’équipe a décidé de faire un Event Modeling avec l’Architecte pour nous conseiller sur les contributeurs qui seront impactés. Elle aussi décidé d’ajouter tous les contributeurs dans leur Release Planning pour connaitre les dépendances et leurs disponibilité lors du lancement de la Release.
L’analyse des indicateurs est essentielle pour comprendre et s’améliorer.
Cas de tests automatisés pour réduire le Cycle Time
Abdallahi (Le TestLead) — “Vous vous souvenez que, depuis les MMF6 et 7, nous avons maintenant une dépendance avec une nouvelle équipe, ce qui a augmenté fortement notre Cycle Time de delivery.”
Jean (le Techlead) — “Oui, nous avons rajouté des procédures de tests complémentaires et pour tenter de baisser le Cycle Time, on a décidé de les automatiser dès la MMF8.”
Abdallahi (Le TestLead) — “Ca a payé, car cela nous a permis de retourner au Cycle Time moyen de delivery initial !”
L’équipe se donne des objectifs. Puis, elle étudie régulièrement les indicateurs, les analyse et teste des solutions pour se tenir à ses objectifs.
Cas de la prédictibilité
Marc (Le Scrum Master) — “Pour la nouvelle Epopée, pour avoir une notion de prédictibilité, nous pouvons indiquer au Métier qu’une Epopée dure, en moyenne, 6 mois avec :
- 1 mois de cadrage,
- Environ 5 mois de delivery,
- Pour 7 MMF traitées.”
Alice (la Business Analyst) — “Et au niveau des MMF une MMF dure, en moyenne, 10 semaines avec :
- Un peu moins de 3 semaines de cadrage,
- 7 semaines de delivery,
- Pour 8 stories (Userstories, Technical stories et bugs) traitées.”
Frédéric (Le Product Owner) — “Concernant le budget, il faut lui préciser qu’il reste figé, et que c’est uniquement le périmètre qui bouge !”
L’équipe a décidé de suivre la prédictibilité de l’Epopée avec l’indicateur de prédictibilité à la maille Epopée/MMF et de la présenter à son Métier.
Les indicateurs permettent à l’équipe de préparer leurs futures Epopées et MMF.
Maintenant, c’est à vous de jouer en interprétant ces Lead Time et Cycle Time …
… Pas si simple quand on n’appartient pas à cette Squad, non ?
Pour consulter les autres épisodes de la série
Episode 2 : Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
Episode 3 : Série “Les indicateurs d’équipe” : la prédiction | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
