Savez-vous si votre équipe est performante ?
Délivre-t-elle fréquemment de la valeur ?
Est-elle efficace dans son mode de fonctionnement ? Comment peut-elle s’améliorer ?
Pour répondre à ces questions, il est nécessaire de mesurer le flux de travail, qui se caractérise par le déplacement de vos éléments de travail à travers toutes les étapes permettant de convertir une nouvelle idée (étape initiale) en valeur pour vos utilisateurs (étape finale).
Dans la perspective de livrer fréquemment de la valeur, analyser le flux de travail est primordial pour votre équipe et votre organisation.
Il doit donc être visualisé et mesuré.
Visualiser le flux
Dans la perspective d’analyser le flux de travail, la première étape consiste à rendre ce flux visible à l’aide d’un kanban.
Cela permet à l’équipe de mieux comprendre ses propres processus et d’identifier les axes d’amélioration.
Faites donc un atelier avec votre équipe pour déterminer les colonnes de votre kanban.
Elles représentent toutes les étapes qui permettent de livrer de la valeur à vos utilisateurs.
Ensuite, assurez-vous que tout le travail réalisé par l’équipe est bien visible, car votre kanban doit refléter parfaitement le travail de l’équipe.
Les 5 mesures du flux
5 mesures permettent de passer au crible un flux de travail.
L’analyse de ces 5 mesures fournit des informations précieuses pour améliorer le fonctionnement de votre équipe.
Pour chaque mesure, nous expliciterons ce que nous mesurons, comment nous le mesurons.
Enfin, comment nous utilisons cette mesure à des fins d’amélioration.
Mesure #1 : La distribution du flux
La distribution du flux est la quantité de chaque type de travail par itération.
Les types de travaux les plus courants sont les suivants :
- Les « User Story » (élément fonctionnel réalisable en une itération, porteur de valeur métier pour les utilisateurs)
- Les « Technical Story » (élément technique réalisable en une itération et utilisé pour prototyper ou bien supporter des futures User Story)
- Le refactoring (réécriture de portions de code pour garder un code propre, maintenable et évolutif)
- Les corrections de bugs
1) Comment mesurer ?
Vous pouvez très simplement compter le nombre d’éléments de chaque type par itération.
Pour garantir une meilleure précision, vous pourrez par la suite mesurer les points de complexité de chaque type par itération.
Dans tous les cas, la mesure est exprimée en pourcentage au regard de l’ensemble des éléments.
Le graphe ci-dessus montre la répartition des efforts d’une équipe entre les User Stories, les Technical Stories, le refactoring et les corrections de bugs, pendant 6 itérations.
2) Comment utiliser cette mesure ?
Cette répartition doit faire l’objet d’une surveillance accrue :
Lorsqu’un effort trop important est consacré aux User Story - exemple : itération 1 dans notre graphe - pendant plusieurs itérations, cela peut engendrer une baisse de qualité et de maintenabilité du code.
C’est notamment ce qui arrive lorsqu’un Product Owner met la pression sur une équipe pour embarquer le maximum de User Story dans les sprints.
À l’inverse, un investissement important sur le refactoring, même justifié, se fera forcément au détriment de la valeur délivrée aux utilisateurs (exemple : itérations 4, 5 et 6 dans notre graphe)
Tout est une histoire de compromis !
Pour éviter une dérive dans un sens ou dans l’autre, nous vous conseillons en début de projet de déterminer l’allocation de capacité désirée par type de travaux.
Cet exercice doit être le fruit d’une collaboration entre le Product Owner et son équipe.
Par ailleurs, il ne faut pas chercher à comparer les allocations de capacité entre équipes, car certaines équipes sont plus techniques que d’autres (équipe dédiée aux API par exemple).
L’allocation de capacité présentée dans le graphe ci-dessus reflète assez bien ce qui est pratiqué par une équipe classique.
Mais, il faut prendre en compte le contexte de chaque équipe pour déterminer les bons pourcentages.
Par exemple, une nouvelle équipe qui récupère une application mal codée aura tendance à investir davantage dans le refactoring que les 5% préconisés.
Durant chaque sprint planning, l’équipe essaie de se rapprocher au mieux de cette répartition cible.
Pour cela, elle sélectionne dans le Product Backlog les items les plus prioritaires de chaque type.
L’allocation de capacité peut, bien entendu, être revue en cours de projet, notamment lors des rétrospectives.
Le but est de mieux prendre en compte les éventuelles difficultés rencontrées (augmentation de la dette technique, augmentation du nombre de bugs, etc).
Mesure #2 : La vélocité du flux
La vélocité du flux, appelée aussi débit, mesure le nombre d’éléments terminés par itération.
1) Comment mesurer ?
La Sprint Review est l’évènement idéal pour mesurer ce qui a été terminé et accepté par le Product Owner.
Seuls les points terminés comptent dans le calcul de la vélocité.
Le graphe ci-dessus est le résultat d’une équipe qui délivre des points de manière régulière.
2) Comment utiliser cette mesure ?
Cette mesure permet de suivre l’efficacité de l’équipe et de calculer la capacité à faire du prochain sprint.
Une manière simple de la calculer est de faire la moyenne des 3 dernières vélocités.
L’analyse de l’évolution de la vélocité en fonction du temps, permet également de mieux connaître l’impact des événements importants sur l’équipe.
En voici quelques exemples :
- Création de l’équipe au démarrage du projet
- Turnover (remplacement d’un développeur par un autre)
- Vacances
Cette analyse permet là encore de mieux prédire la capacité à faire pour les prochains sprints.
Une chute de la vélocité doit systématiquement faire l’objet d’une investigation pour comprendre ce qui s’est passé et viser l’amélioration continue.
À l’inverse, une vélocité très élevée sur la durée peut être synonyme de mauvaise qualité.
Dans ce cas, nous vous conseillons d’enrichir la liste des critères de la DoD (définition du terminé).
La vélocité va alors probablement diminuer, mais la qualité sera meilleure !
Il ne faut jamais chercher à comparer la vélocité de deux équipes car :
- Chaque équipe possède sa propre manière d’estimer les User Story,
- Les User Story qui servent de référence pour les estimations sont différentes
- Les DoD sont différentes
- Les personnes sont différentes (compétences, séniorité…)
Mesure #3 : Le temps de cycle du flux
Le temps de cycle est le temps moyen mis par les éléments de travail pour traverser toutes les colonnes du kanban (de l’idée à la mise en service).
1) Comment mesurer ?
Pour chaque élément de travail, il est nécessaire de compter le temps mis pour traverser toutes les colonnes du kanban.
Fort heureusement, nos outils traditionnels de gestion de kanbans (JIRA, Mingle, Leankit…) réalisent automatiquement ces mesures pour nous !
L’histogramme ci-dessus donne la répartition du nombre d’éléments de travail délivrés en fonction du temps de cycle.
Concrètement, nous pouvons lire que :
- 23 éléments de travail ont été réalisés en 25 jours chacun
- 3 éléments de travail ont été réalisés en 110 jours chacun
Ce graphe permet de mettre en évidence que certains éléments de travail ont mis 2 à 3 fois plus de temps à être réalisés que le temps de cycle moyen (39 jours dans notre cas).
2) Comment utiliser cette mesure ?
L’évolution du temps de cycle moyen est un bon indicateur de l’impact ou non des axes d’améliorations mis en place par votre équipe.
Une analyse complémentaire est à mener pour comprendre pourquoi certains éléments de travail ont mis 2 à 3 fois plus de temps que les autres pour être terminés.
Étaient-ils plus gros que les autres ? moins détaillés ? plus complexes ? Certains types de travaux prennent-ils plus de temps que d’autres ?
Pour affiner l’analyse, il peut être également intéressant de mesurer le temps de cycle moyen sur une portion particulière de votre kanban (du développement au déploiement par exemple).
Mesure #4 : La charge du flux
La charge du flux mesure le nombre d’items actifs dans le kanban, c’est-à-dire le nombre d’items commencés, mais non terminés.
1) Comment mesurer ?
Un diagramme de flux cumulé est l’outil commun utilisé pour mesurer la charge d’un flux.
Il montre la quantité de travail par état, en fonction du temps, chaque état étant représenté par une zone colorée.
Pour déterminer la charge du flux, il faut mesurer la distance verticale entre l’état « À faire » et l’état « Terminé » à un temps donné.
2) Comment utiliser cette mesure ?
Le nombre d’items actifs doit rester raisonnable, car ils créent une instabilité de l’application.
Pour le maîtriser, il faut limiter le travail à faire dans les colonnes « en cours » pour établir un flux tiré permettant un meilleur débit.
Dans l’exemple ci-dessus, il n’est pas possible de commencer les tests de la User Story #4 avant d’avoir terminé les tests de la User Story #2 ou #3.
De même, il n’est pas possible de commencer les développements d’une User Story avant d’avoir terminé les développements de la User Story #5 ou #6.
Mesure #5 : L’efficience du flux
Un flux est composé d’activités (codage, tests, validations, déploiements, etc) et d’attentes (intervenants multiples, silos de l’organisation).
L’efficience d’un flux est le rapport entre la somme des temps d’activités et le temps total, le temps total étant la somme des temps d’activités et des temps d'attente.
1) Comment mesurer ?
Il faut commencer par cartographier votre flux en vous basant sur des User Story que vous avez déjà terminées.
Il faut ensuite mesurer le temps passé dans chaque activité ainsi que le temps d’attente entre chaque activité.
Le flux représenté ci-dessus est peu efficient (8,4 %).
2) Comment utiliser cette mesure ?
Une faible efficience s’explique le plus souvent par un nombre de délais important.
La première chose à faire est d’essayer de réduire au maximum tous les délais plutôt que de vouloir réduire la durée des activités.
Pour chaque délai, un atelier de résolution de problèmes devra être mené pour prendre les mesures adéquates :
- Casser les silos
- Embarquer des nouvelles compétences dans l’équipe
- Octroyer davantage de droits aux développeurs concernant les environnements
- Etc...
Conclusion
Nous avons analysé votre flux de travail à travers 5 mesures.
Chacune vous a donné un prisme différent sur le fonctionnement de votre équipe et vous a permis de détecter de nombreux axes d’améliorations.
Dans un prochain article, nous découvrirons des accélérateurs de flux permettant de délivrer toujours plus rapidement de la valeur pour vos utilisateurs.
