Une question récurrente lorsque l’on parle de flux est de connaître la taille d’un élément de travail. En effet, on part du principe que plus un élément est gros et plus il prendra de temps pour traverser le processus. Cependant, dans la culture Kanban, ce n’est pas tout à fait vrai !
Je vous propose ici la traduction d’un article d’Anna Radzikowska, du blog de David J. Anderson, traitant du sujet 🙂
Belle lecture à vous !
Kanban Evergreen : la taille d’un ticket
Chaque formateur Kanban a son set de questions favorites qui reviennent encore et encore durant chacune de leurs sessions.
Voici ma liste personnelle :
- Peut-on déplacer les éléments en arrière sur le tableau Kanban ?
- Comment établir sa toute première limite de travail en cours ?
- Quelle devrait être la taille du ticket dans le système Kanban ?
- Devrait-on inclure les éléments en attente (éléments du « parking lot ») dans les limites de travail en cours ?
Si vous vous êtes déjà posé une de ces questions, me voilà avec les réponses !
Quelle devrait-être la taille d’un ticket dans un système Kanban ?
Les tickets sur un tableau kanban devraient représenter les éléments de travail qui sont significatifs pour un client, c-à-d. qu’ils doivent refléter une demande. Si j’ai commandé une pizza, le ticket sur le tableau, visible du client, devrait représenter la demande d’une pizza. Si en interne du restaurant le chef demande au cuisinier de couper des oignons, alors le service fourni est du découpage d’oignons et le ticket devrait représenter cette demande.
Les tickets devraient toujours représenter la demande qui a été effectuée au fournisseur de service.
La taille du ticket n’a pas d’importance. Qu’est-ce que la « taille » d’ailleurs ? Est-ce le nombre d’heures dépensées ? Ou peut-être les story points assignés par les développeurs ?
Les tickets vont sur le tableau et ils se déplacent. Bien que cela puisse être contre-intuitif, Kanban ne se soucie pas vraiment de la taille des éléments. Comprendre les types d’éléments de travail que vous avez dans votre service est une manière plus naturelle de les regrouper plutôt que d’en estimer la taille. Pour vous guider, ce que vous voulez voir, c’est votre ticket circuler. Si un ticket ne bouge plus sur votre tableau pendant quelques jours ou plus, mais que du travail est tout de même terminé, alors peut-être que vous avez besoin de considérer un tableau à deux niveaux : avec des éléments de granularité plus petite issus de la demande client plus grosse.
La clé est de voir le flux et d’avoir des tickets représentant des morceaux de travail significatifs livrables au demandeur.
Alors, comment gérer les estimations ?
N’estimez pas !
Cette règle a été vraie depuis le tout premier cas d’étude Kanban à Microsoft XIT en 2004. Vous souvenez-vous de combien de temps ils ont gaspillé à livrer des estimations qui n’ont jamais été tenues plutôt que de se focaliser sur du vrai travail qui apporte de la valeur ?
Facile à dire : « n’estimez pas. » Que devriez-vous faire à la place ? Avec Kanban, vous prévoyez en utilisant le lead time observé historiquement. Le Lead time n’est pas corrélé à la taille, ou la complexité car l’efficience du flux est presque assurément très basse. La plus grande influence sur le lead time est le délai et la gestion des files d’attente. (ou du manque associé). La taille d’un morceau de travail n’est pas une information utile même si cette estimation était très précise.
Déceler les différents types d’éléments de travail
Je me rappelle avoir travaillé dans la construction de produits pour un département financier. Le premier type d’élément de travail que l’on avait était des « nouvelles constructions« . Après avoir commencé à livrer des incréments de produit, on a commencé à recevoir du feedback. Cela a résulté en un nouveau type d’élément de travail : les demandes de changement.
Les défauts étaient également résolus immédiatement vu qu’ils affectaient le produit visible du client. On a réalisé toutes ces nuances en analysant les données de lead time et en écoutant les feedbacks clients. En remarquant une distribution multi-modale de lead times et par l’analyse du lead time et des points de données, on a décelé non plus un seul type d’élément de travail, mais 3. On a alors créé 3 distributions de lead time à partir de la première et établi des SLA correspondants.
La « taille » de ces éléments était une conséquence naturelle de la compréhension de ces types d’éléments de travail. En regroupant ceux qui étaient similaires en nature, on les a finalement regroupés en taille.
L’exemple ci-dessous provenant de la formation Kanban Systems Improvement explique comment vous pouvez identifier et lire les données multi-modales :
Les éléments avec des tailles vraiment différentes seront différents types d’éléments de travail. Si vous ne voyez jamais un ticket bouger, alors peut-être qu’il est trop gros. Ou peut-être qu’il vous faut un tableau de portefeuille ou une hiérarchie à 2 niveaux pour voir les choses bouger.
Des bateaux de croisières ?
Vous cherchez à identifié des types de travail consistants, cela peut même être quelque chose d’énorme. Prenons un autre exemple. Si vous construisez des bateaux de croisière, un ticket pour un bateau de croisière va sur le tableau. Si l’on est dans le business des bateaux de croisière, alors le temps et l’énergie à fournir pour en construire un est quelque chose de connu et de compris. Avec un bateau, puis le suivant, puis le suivant, on peut commencer à construire un histogramme de lead times, vu que ce sont tous le même type de travail.
Puis un jour Richard Branson passe dans le coin et vous dit :
Je réfléchis à acheter un bateau de croisière pour Virgin Voyages et j’ai pensé à commander chez vous. Si je commande cette semaine, quand sera t-il prêt ?«
Si l’on sait ce que l’on fait parce-que l’on est une société de construction de bateau de croisière de niveau de maturité 3 ou 4, on peut lui donner une réponse.
On pourrait dire :
On pourrait l’avoir pour vous pour Juillet 2024 Richard. Qu’en pensez-vous ? Et on saurait que c’est une promesse que l’on pourrait tenir.
C’est un changement significatif entre le niveau de maturité 1 et le niveau de maturité 2 : vous commencez à voir différents types d’éléments de travail.
Que devriez-vous faire ?
Développer des compétences d’analyse, faire attention à votre environnement et au langage que les personnes utilisent : ils pourraient vous aider à identifier les types d’éléments de travail dans votre processus.
Il y a plus !
Imaginez que vous avez une efficience de flux de 2% dans votre organisation.
Cela signifie que seulement 2% du lead time est du travail effectif : où les choses sont dans une colonne d’activité et où on travaille vraiment dessus. 98% du temps est de l’attente.. Ainsi, la taille du ticket et son travail effectif sont des nombres triviaux par rapport à son lead time. Par conséquent, vous estimez la taille du temps d’attente ou de gaspillage, pas la taille du travail actuel..
Pour le même type d’élément de travail, l’efficience du flux va produire plus de variabilité que la taille elle-même.
Alors, quelle devrait être la « taille » de mon ticket ?
Focalisons-nous sur des conseils pragmatiques à cette question :
- Ne vous embêtez pas à estimer la taille. Laissez le ticket circuler dans le système. Analysez-le comme une option en amont et utilisez les données de lead time pour décider quand commencer à travailler dessus en aval.
- Comprenez vos types d’éléments de travail. Écoutez ce que les gens disent, quel langage ils utilisent lorsqu’ils parlent des processus et du travail effectué.
- L’élément de travail devrait être suffisamment « petit » pour vous permettre de voir sa progression (ou son manque – blocage, dépendance d’attente). Si votre élément reste pendant quelques jours / semaines dans un état,et que vous perdez le suivi des dépendances car il est toujours « en cours », alors cherchez à avoir quelque chose de plus petit.
- Votre élément de travail devrait être suffisamment « gros » pour ne pas créer de surcoût. Si vous dépensez plus de temps sur la création et le déplacement d’un élément dans votre système que sur du véritable travail dessus alors c’est que vous avez besoin d’un niveau au-dessus.
- Utiliser le design du ticket pour vous aider à prendre des décisions en confiance. L’idée est que lorsque vous le regardez, vous sachiez « ce qu’il se passe » sans avoir besoin de délibérer à son sujet. Bien évidemment, cette perspective, comme tout, nécessite du temps pour essayer et vous pourriez avoir besoin d’expérimenter avec différentes approches. Soyez patient. Améliorez collaborativement, évoluez expérimentalement.
2 réponses
Bonjour Olivier, merci c’est un super article !
Tu parles de création de 3 distributions de lead time avec des SLA correspondants. Cela correspond à 3 classes de service ? Y a t-il des indicateurs Lead Time / Cycle / time / Débit qui sont spécifiques pour chaque classe de service ou c’est plutot sur l’ensemble du système Kanban ?
Vos 3 leads time étaient regroupés par le tps de passage dans le système ou par des catégories (ex « nouvelle construction », « demande de changement » et « anomalie ») ?
Dans votre flux de travail, n’y a t-il pas un risque de prendre en priorité les tickets avec les délais les plus court type « demande de changement » et « anomalie » et de prendre du retard sur les tickets « nouvelle construction » ?
Merci d’avance,
Bonjour Guillaume,
Désolé pour ce délai de réponse 🙂
Avant de te répondre, je précise de nouveau que cet article est une traduction d’un billet original de la Kanban University qui me semblait intéressant à partager. Je ne connais donc pas tout le contexte qu’il y a autour donc ce que je vais te dire n’est que mon avis !
Point 1 – Distributions = classes de service ?
Réponse brève : cela correspond bien selon moi bien à 3 classes de service qui vont chacune avoir leurs propres indicateurs.
Réponse un peu plus longue : En effet, une classe de service peut s’apparenter au traitement d’un type d’élément particulier qui va donc passer dans un flux de travail potentiellement différent d’autres. C’est l’intérêt principal de les séparer dans des distributions différentes afin de pouvoir mettre en oeuvre des actions d’améliorations qui seront donc spécifiques et pertinentes.
Par exemple : une fonctionnalité peut avoir un lead time de 5 jours alors qu’un bug n’aura qu’un lead time de 2 jours, tout simplement car les règles de passage et leurs processus seront légèrement différents. Cela ne peut donc être que spécifique à la classe concernée.
Si tu souhaites avoir un indicateur de ton système, tu peux potentiellement travailler sur le débit d’éléments – indépendamment de tes classes – pour ensuite travailler sur un débit moyen par classe contraint par une répartition décidée par ton environnement. Par exemple : 75% de fonctionnalités, 15% de bugs et 10% de tâches techniques sous 2 semaines. Cela peut devenir intéressant dans ce cas de dire que dans ton système, de par ces contraintes, tu arrives à sortir X fonctionnalités, Y bugs et Z tâches techniques dans le temps imparti.
Après personnellement, je préfère jauger en « juste à temps » la sélection des éléments plutôt que de contraindre mon système à une répartition. Cela nécessite peut-être un peu plus de rigueur personnelle mais cela donne également beaucoup de flexibilité dans un environnement qui bouge tout le temps !
Point 2 : Temps de passage ou catégories ?
Je ne sais pas comment cela a été fait dans le contexte d’Anna mais ce que j’ai tendance à faire est d’abord de regrouper par catégorie et ensuite de jauger des temps de passage. En effet, l’idée est d’avoir une structure similaire d’apport de valeur que l’on va ensuite faire passer dans le même processus (on limite ce que l’on peut de complexité / variabilité (Mura)). Bien sûr cela part du postulat que la taille de l’élément a peu d’importance sur le temps de traversée comparée aux temps d’attente générés par le processus.
Maintenant, s’il s’avère qu’une nouvelle construction et une demande de changement prennent le même temps alors elles vont pouvoir faire partie du même paquet par la suite mais c’est un choix d’organisation que l’on pourra faire à posteriori.
Point 3 : Priorisation ?
Cela est effectivement un risque mais pour moi cela est totalement du ressort des critères de priorisation qui sont mis en place dans le système. Typiquement, si ton critère est d’apporter le maximum de valeur à chaque fois, tu vas potentiellement prendre un élément de travail plus long mais qui est essentiel pour ton client quitte à ne pas tout faire de ton backlog au final (c’est ce que l’on fait en Agile). Dans un autre cas, si tu penses vraiment pouvoir tout faire de ton backlog, des approches comme GTD ou Personal Kanban vont effectivement t’amener à prendre les tâches les plus courtes avant de t’attaquer aux plus longues – cela part par contre du principe que le temps que rien ne viendra s’empiler entre temps 😛
Dis autrement, les critères de choix sont importants et mieux vaut les partager collectivement pour avoir bien en tirer les avantages et les inconvénients.
J’espère avoir pu t’apporter quelques éclairages 🙂
Belle journée à toi.
Olivier