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 Responses
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