Quelle taille de ticket pour mon Kanban ?

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.

Partager

Olivier MY

Olivier MY

Issu d'un cursus ingénieur, je me suis vite rendu compte que mes appétences et compétences tournaient plus autour de l'humain que de la technique. Je suis alors devenu Coach Agile et Coach Professionnel car j'ai toujours voulu contribuer à rendre le monde meilleur. J'accompagne aujourd'hui des individus, des équipes et des organisations vers une meilleure compréhension d'eux-mêmes afin de bâtir ensemble le futur qui leur correspond.

Commentaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles récents

L’origine fascinante du terme « Cérémonie Scrum »

Voici un des grands sujets de la communauté Agile concernant Scrum : parle-t-on de cérémonies ou d’événements ? Dans le Scrum Guide, on ne retrouve …

LIRE PLUS

Featureban : un atelier de simulation Kanban

Il existe un certain nombre d’ateliers pour illustrer la méthode Kanban. Cependant, la plupart d’entre-eux sont longs (au moins 2h) et nécessitent un matériel spécifique …

LIRE PLUS

Le Jeu des Prénoms

Vous est-il déjà arrivé de vous sentir noyé(e) par les demandes, sans en voir le bout, et ce malgré tous vos efforts ? Vous n’êtes …

LIRE PLUS

Démarrage d’équipe – Focus interactions

Un exercice que je trouve déterminant et pourtant si souvent oublié dans le démarrage d’une équipe est la détermination du cadre d’interactions. J’entends par là …

LIRE PLUS

Individual Map : apprendre à se connaître en quelques questions

Dans le cadre de mes accompagnements d’équipe, je cherche constamment à développer les relations entre personnes. Cela passe notamment par une meilleure connaissance interpersonnelle. Un …

LIRE PLUS

Stakeholder Mapping : visualiser l’écosystème pour mieux le gérer

Dans la plupart des écosystèmes dans lesquels j’ai pu intervenir, les dépendances entre équipes et services ont été de grandes sources de difficultés pour la …

LIRE PLUS
Retour haut de page

Prenons contact