Stéphane Wojewoda

Je ne veux pas que vous soyez avec moi, c'est que vous n'allez rien apprendre. Je suis sûr que vous avez plein de super conférences à aller voir.
Non, mais je préfère éviter la déception. Je préfère éviter les déceptions à ce niveau-là.
Alors, je vais vous faire une petite confidence. Je déteste parler. En fait, je suis un grand bavard et je déteste parler parce que je pense que c'est le plus mauvais moyen pour faire passer un message. Le meilleur moyen pour moi étant que vous pratiquiez. Et donc, j'ai essayé de réfléchir à la manière de vous faire pratiquer, du coup, toucher et comprendre pour faire une conférence où je vais parler. De la partie métrique. Donc pour ça je vais utiliser Kaut. Donc le mode de fonctionnement avec vous c'est que par équipe, donc vous allez vous mettre par un groupe de 2 à 4, vous allez prendre un téléphone au maximum, une tablette, n'importe quel support pour vous connecter sur kaut.it, vous allez mettre le code PIN, vous allez mettre un petit nom à votre équipe et il va y avoir des questions au fur et à mesure qui vont agrémenter ma présentation. D'accord? Donc surtout, ne vous mettez pas tout seul, rencontrez des gens. D'habitude, je fais un petit warm-up, histoire que tout le monde soit bien chaud, etc. Le format s'y prête que moyennement.
Et comme on a 45 minutes, le format s'y prête doublement moins bien. Donc, je vais me présenter très vite. Je suis Stéphane Vaugevoda. Je fais deux choses dans la vie. La première, c'est que je suis coach agile le jour dans les équipes de Renault Digital. Je suis très content, j'ai intégré il n'y a pas longtemps et c'est une super équipe. La deuxième, c'est que la nuit, quand je ne dors pas, je suis chief editor de InfoQ et InfoQ France capte aujourd'hui et hier tout le Lean Camp en France. On est très fiers d'être partenaire du Lean Camp en France depuis de nombreuses années parce que je vois toujours plein de super conférences et je rencontre plein de gens extraordinaires. Donc pour moi, c'est vraiment un truc super chouette. Maintenant que j'ai dit tout ça, on va arrêter de blablater sur des bêtises, parce que ma vie ne vous intéresse pas, elle ne m'intéresse déjà que très moyennement, et on va rentrer dans le cœur du sujet. Donc je répète une dernière fois, on va travailler avec du K.O.U.T. Donc vous mettez vous par équipe, vous prenez un téléphone par équipe. Vous avez K.O.U.T. IT, le code PIN pour rentrer. Vous mettez un petit nom à votre équipe.
On va avoir plein de questions qui vont arriver au fur et à mesure. L'équipe qui gagne aura le droit de prendre un des deux livres, offerts généreusement par l'organisation du Lean Camp en France. Puis c'est plus rigolo quand il y a un truc à gagner. C'est toujours plus drôle quand il y a des trucs à gagner.
Et on est parti. Est-ce que tout le monde est prêt? Tout le monde est prêt?
Vous êtes prêts? Vous êtes presque prêts?
Vous êtes prêts?
Voilà, j'en ai tout plein d'équipes, super.
Allez, c'est parti. Donc, je vais vous présenter les basiques du Lin-Kamban et en particulier des métriques autour du Lin-Kamban, autour d'une petite histoire presque vraie. Bon, alors, avant ça, on va passer par quelques bases communes, histoire qu'on soit bien d'accord sur deux, trois fondamentaux.
Donc les graphiques classiques. D'abord ça, c'est un Kanban. C'est l'idéogramme japonais. C'est bien de rappeler d'où ça vient.
Et dans le monde de l'IT, ça s'est transformé en plutôt un truc qui va ressembler à ça, c'est-à-dire une carte. Objectivement, à la base, chez Toyota, le Kanban, c'est une carte perforée qui permettait de mesurer les stocks. Et donc dans le monde de l'IT, ça s'est traduit par un truc qui est assez proche d'une user story, que si finalement vous mettez sur un beau tableau. Et alors en tant que coach, moi ce que j'aime bien dans les Kanban, c'est avoir plein de trucs autour de ça. J'aime bien avoir le qui. J'aime bien savoir qui utilise et qui a tiré la carte. J'aime bien avoir des éléments sur la complexité, j'aime bien savoir combien est-ce que ça pourrait rapporter. J'aime bien aussi savoir quand... Il y a une classe de service, je reviendrai dessus plutôt à la fin. Et ce que j'apprécie particulièrement et qui pour moi est le mandatory, c'est ce morceau-là. C'est-à-dire toutes les dates qui permettent d'expliquer à quel moment on est passé d'un état de votre flux cambant à un autre. C'est super pratique sur toute la suite. En fait, c'est l'élément principal sur toute la suite. Si comme moi, vous êtes un aficionados des post-it, c'est vachement chouette. Et ça veut dire qu'une fois que vous avez fini vos cartes, il faut que vous reportiez toutes les dates dans un fichier Excel ou autre base de données quelconque. Si vous êtes plutôt R digital, R numérique, vous avez des outils qui font ça très bien. Je ne citerai personne, vous les connaissez probablement tous. Ah, alors il y a un dernier élément qui est intéressant sur les cartes Caman, c'est qu'on peut rajouter plein de trucs dessus. Alors j'aime bien en particulier avoir... Ça marche ça? Non, ça ne marche pas. Ah si, c'est celui-ci. J'aime bien avoir ce genre de petits trucs-là, qui sont des éléments qui permettent de donner une indication visuelle complémentaire. Typiquement, ça, pour moi, c'est un blocage. Ça signifie que la carte est bloquée à un endroit ou à un autre du flux.
Je vous laisse prendre des photos, j'ai l'impression d'être une rockstar.
Étape d'après. On a parlé du camban en tant que carte, on va parler du camban en tant que tableau. Le camban en tant que tableau, c'est un truc qui ressemble à ça. Alors ça, c'est l'étape du démarrage. En fait, c'est le camban parfait pour moi, c'est-à-dire qu'il n'y a rien dedans. C'est merveilleux, aucun gaspillage, rien du tout. Donc c'est génial. Généralement, ça ressemble plutôt à ça. Et alors là, tout d'un coup, on se dit OK, bon. Et puis en fait, ça va vite ressembler à ça, c'est-à-dire qu'on va se retrouver avec plein de blocages. Allez, vous avez des questions là-dessus? Je vais éviter de vous poser trop de questions parce que le timing est un peu serré. Donc, généralement, un tableau en commun ressemble un peu à ça. Et alors là, moi, en tant que coach, je me dis, j'ai un premier problème. Et donc, c'est quoi le problème? C'est long, on démarre qu'à août. Vous êtes prêts? Vous êtes prêts? Donc, je vais vous laisser des périodes de 90 secondes pour que vous ayez le temps de discuter entre vous. Ah ouais, c'est fait pour être...
C'est fait pour. Donc la question va arriver, c'est quoi, qu'est-ce qui manque à ce premier tableau cambant?
C'est quoi les manques? Qu'est-ce qui manque dans ce premier tableau cambant que je vous ai montré il y a trois secondes?
Vous devriez l'avoir. Hop, celui-ci.
C'est les réponses. Ah merde, vous ne les avez pas. Alors, le rouge, c'est non. En fait, il est parfait. Le bleu, c'est il manque des classes de service. Le jaune, c'est des limites de travail en cours. Et le vert, c'est des règles.
Il est parfait, des classes de service.
Il y en a une ou plusieurs.
L'important, c'est d'en avoir au moins une.
C'est que vous avez répondu trop vite, je suppose ? C'est juste un truc particulier. Ouhou! C'est que c'était bon.
Super! Je vois plein de super bonnes réponses.
Et donc vous avez le tableau tel que je le vois en première version. Donc en fait, qu'est-ce qui manque à ce tableau juste avant? En fait, il va manquer deux éléments pour répondre au principe de base de Kanban. C'est les premières étapes quand on monte un modèle Kanban. Qui sont ici des limites de travail en cours, là. Et ce qui est intéressant, on les voit moins bien, ici vous avez des règles qui permettent d'expliciter comment on passe d'une étape à l'autre. Ce sont les points essentiels pour démarrer un Kanban. Si vous ne les avez pas, vous ne faites pas vraiment du Kanban. Vous faites du proto-Kanban. C'est comme ça que certains l'appellent ça. Donc c'était le premier élément. Je dis bravo aux premières équipes qui ont très très bien répondu. Les autres, vous avez encore un peu le temps pour réussir à gagner, ne vous inquiétez pas.
Ah, je suis désolé.
C'est ça la technique. Allez, continuons. Donc on a parlé des cartes, on a parlé du tableau, on va parler du troisième élément essentiel en termes de basique qui est le diagramme de flux cumulé. Le diagramme de flux cumulé, c'est un peu l'alpha et l'oméga de toute bonne démarche en mode Kanban.
Concrètement, vous voyez quoi? Vous voyez s'empiler au fil du temps tous les éléments du flux de travail que vous avez développé. Et donc, ils vont avancer dans le temps. Donc, ça montre quoi? Ça montre l'évolution du flux de travail dans le temps. Vous avez une petite légende tout en bas.
En gris, c'est le backlog. Et donc, combien est-ce que vous avez d'éléments dans votre backlog? Et avec les couleurs, vous avez comment est-ce qu'avancent les différents éléments dedans. Ça va permettre de raconter plein de choses, ce truc-là, et c'est assez proche d'un burn-up, c'est juste que vous voyez les différentes phases ou les différentes étapes dans lesquelles vos éléments de travaux, donc vos fonctionnalités si on est dans le monde de l'IT, passent.
Élément d'après, qui est mon deuxième élément favori, c'est pour ça que je vous l'ai mis, ce sont les éléments bloqués. Alors c'est un truc qu'on ne fait pas toujours. C'est assez proche, en fait ça se calcule exactement de la même manière qu'un nombre de bugs. C'est-à-dire qu'à chaque instant, vous allez regarder combien d'éléments sont bloqués dans votre flux de travail. À quoi ça sert? Ça sert juste à vous dire, OK, j'ai plein d'éléments sur lesquels on est en train de bosser et un certain nombre ne bouge plus. Vous pouvez poser des règles là-dessus. Typiquement, si ça fait deux jours que c'est dans la même colonne, on peut considérer que c'est bloqué. Ou n'importe qui le vend la main en disant« je suis bloqué» signifie« c'est bloqué». Et donc, vous mettez un post-it particulier. Si vous êtes dans des outils, vous pouvez même mettre des tags particuliers directement sur vos fonctionnalités pour que ça marche. L'enjeu, c'est comme les bugs. Si vous avez un nombre d'éléments bloqués dans votre flux de travail qui est important, c'est que vous avez un problème.
Le troisième, qui en fait va prendre deux têtes différentes, c'est ce qu'on appelle un diagramme de temps de cycle. Alors il y a plein de sujets de discussion super pointus sur les temps de cycle, entre est-ce qu'on parle d'un tag time, lead time, cycle time, bon moi on ne va pas rentrer dans ce détail, pour moi ça n'a aucune espèce d'importance. Le temps de cycle pour moi c'est le temps qui s'écoule entre un élément, entre deux phases de votre flux de travail. Le plus simple dans le monde de l'IT, c'est entre le moment où je commence à développer et le moment où ça sort en prod. Ou c'est testé par votre PO ou autre joyeuseté si vous me faites de l'agilité.
À quoi ça sert?
C'est le premier élément pour discuter avec votre PO. Et sous cette forme-là, qui est juste un scatterplot, un nuage de points, vous voyez juste qu'ici, les premiers éléments du flux de travail, il a fallu deux jours pour les sortir. Celui-ci, il a fallu une journée. Celui-ci, il a fallu six jours. Celui-ci, il a fallu cinq jours. Ce n'est pas très représentatif. mais ça permet de commencer à discuter. Le deuxième format qui est plus intéressant, c'est celui-ci. Vous allez reprendre vos points et vous allez faire un histogramme très simple de quelle est la répartition de vos différents éléments au fil du temps. Et alors ça, c'est la base. Si vous n'avez pas ça, vous ne pourrez jamais faire de classe de service. Et l'enjeu des classes de service est complètement en dehors de stock. Je vous le dis tout de suite, je ne parlerai pas de classe de service, sauf à la fin si vous voulez.
Je crois qu'on a fait le tour, c'est exactement ça, des trois principaux éléments. Donc concrètement, vous avez quoi comme diagramme? Et comme élément d'analyse graphique, vous avez le CFD, vous avez les éléments bloqués, vous avez les temps de cycle.
Vous êtes content jusqu'à présent? Je vous ai raconté des trucs intéressants, tout ça? Oui, bon. Donc ça, c'était les basiques pour qu'on soit bien d'accord. Maintenant, je vais vous raconter l'histoire d'une équipe qui est presque vraie. Il se trouve qu'aujourd'hui, quand j'ai monté la conférence, cette équipe n'existait pas, je ne la connaissais pas. Depuis, je l'ai vraiment rencontrée, c'est le côté un peu marrant. Et donc, c'est une équipe magique, ce sont des gens qui sont merveilleux. Objectivement, ils sont vraiment merveilleux.
Et ils s'entendent super bien, ça fait des années qu'ils font de l'agilité, qu'ils font du Scrum, ils sont au top. Puis ils se disent que l'agilité, ça finit un peu par les bloquer. Et puis ils ont été au Lean comme en France et ils se disent« Ah, j'aimerais bien essayer un nouveau truc. » Par exemple, si on essayait de commencer à déployer du Kanban dans notre équipe. En tant que coach, aujourd'hui, vous êtes sûr, ça vous sert à quoi, pourquoi ? Si vous tirez une idée comme ça, ça n'a pas grand intérêt. Mais vous êtes fou, vous avez envie d'aller expérimenter, c'est une bonne idée.
Et donc le flux de travail de l'équipe, c'est celui-là. C'est un flux de travail très très simple, c'est à peu près celui que je vous ai montré avant. Il y a juste une différence qui est ici, on a posé une étape intermédiaire, c'est un peu ce que disait Romain Couturier hier matin.
On est en train de le faire et c'est terminé. C'est la seule différence par rapport à l'élément d'avant. Donc vous avez tout le backlog, vous avez ce qui est prêt, vous avez ce qui part en dev, ce qui est fini de développer, etc. La différence entre le test et la recette, c'est que le test est interne à l'équipe et la recette c'est fait par un PO quelconque joyeux et très amoureux de son produit.
Et donc, on est parti pour une première étape en commun.
Donc premier sprint. Premier sprint, voilà le résultat après 10 jours. Ils m'appellent et me disent, Stéphane, voilà notre premier sprint, qu'est-ce que tu en penses?
Qu'est-ce que vous en pensez ? C'est ça qui est rigolo. C'est quoi le problème? Quel est le problème quand vous arrivez sur un truc comme ça? Moi, j'appuie sur un petit bouton.
Alors, par rapport à l'étape d'avant, les premiers sont au braque. Qui est au braque? Vous êtes promis, mais alors pas de très loin, parce que Real et l'Ectra 1 sont juste derrière vous à entre 3 et 5 points.
Alors, question d'après, ça arrive. Donc quel est le problème mis en lumière par ce premier CFD? Vous avez quatre réponses. Rouge, le backlog est trop grand. Bleu, il manque des testeurs. Jaune, l'infra n'est pas prête. Vert, les conditions d'acceptation sont insuffisantes. Backlog trop grand. Manque de testeurs, un frappe à prête, conditions d'acceptation insuffisantes. C'est quoi la bonne réponse? C'est quoi le problème?
Il manque des testeurs.
La bleue. Bleu, il manque des testeurs. Donc, qu'est-ce qu'on voit? Backlog, prêt, on est en dev.
Alors je reviens, je reviens. Rouge, backlog trop grand. Jaune, l'infra n'est pas prête. Vert, les conditions d'acceptation sont insuffisantes. Backlog trop grand. Manque de testeurs, un frappe à prête, conditions d'acceptation insuffisantes. C'est quoi la bonne réponse? C'est quoi le problème?
Il manque des testeurs.
La bleue. Bleu, il manque des testeurs. Donc, qu'est-ce qu'on voit? Backlog, prêt, on est en dev.
Alors je reviens, je reviens. Rouge, backlog trop grand. Bleu, il manque des testeurs. Jaune, l'infra n'est pas prête. Vert, les conditions d'acceptation sont insuffisantes.
Je crois qu'on arrive au bout. Il vous reste 35 secondes.
Il ne veut toujours pas.
J'allais dire faites un rollback, mais je ne suis pas persuadé que ça résolve le problème.
J'ai 12 réponses.
Attention, attention, on arrive à la fin. Il reste 10 secondes.
Rouge, backlog trop grand. Bleu, manque des testeurs. Jaune, un frappe à prête. Vert, condition d'acceptation insuffisante.
Et la bonne réponse était la verte. Ah, pourquoi?
On va revenir.
La réponse verte, c'est les conditions d'acceptation sont insuffisantes. Qu'est-ce qu'on voit?
Qu'est-ce que le CFD permet de montrer? Le CFD montre quoi? Ici, vous avez un backlog qui grimpe, qui grimpe, qui grimpe. Vous avez un élément qui part en sépré. Et vous commencez à développer à partir du deuxième jour. Vous développez, vous développez, vous développez, puis tout d'un coup il y a un blocage. Puis vous restez exactement avec le même niveau de développement, puis vous avez un deuxième blocage, puis vous restez en fait à deux blocages tout du long. Il n'y a rien qui est terminé d'être développé. Vous n'arrivez pas à finir le développement. Donc concrètement, il ne vous manque pas des testeurs, vous n'avez toujours pas fini de développer. Donc concrètement, c'est à ça que sert un diagramme, un CFD sur ce type de cas. En fait, qu'est-ce que vous faites en tant que coach ou juste en tant qu'introspection d'équipe? Vous allez voir les gens. Vous avez des développements commencés, mais vous n'avez rien de fini. C'est l'opposé même de l'objectif de faire du Kanban. L'objectif, c'est que ça sorte. C'est que vous arriviez à sortir des fonctionnalités, à sortir vos éléments de travail. Donc, vous allez discuter avec les développeurs. Je ne suis pas assez souvent avec mes développeurs, donc je vais les voir. Pourquoi est-ce que c'est bloqué? Qu'est-ce qu'ils disent les développeurs? Ce n'est pas très clair. Qu'est-ce qui n'est pas clair? La fonctionnalité, le comment est-ce qu'on finit, comment est-ce qu'on sait qu'on a terminé, ce n'est pas clair.
Le bon... coach, mais que vous soyez lean ou autre, en fait, c'est, ok, concrètement, vous n'avez pas les conditions d'acceptation pour savoir quand vous avez terminé. Vous avez un élément bloqué parce qu'il vous manque une condition d'acceptation. Et donc concrètement, c'est quoi le problème? C'est que les règles n'existent pas. Vous n'avez pas posé les règles, l'équipe n'a pas posé les règles pour passer d'une étape à l'autre. Donc vous n'arrivez pas à finir. Qu'est-ce qu'on fait dans ce cas-là? C'est assez simple. On pose des règles. On commence à discuter. On amorce une discussion avec les parties prenantes sur quelles sont les règles qui permettent de dire qu'on a terminé. Ça s'arrête à ça. Le CFD n'a permis de mettre en avant que ceci. Ah, l'équipe est très contente, elle se dit qu'elle va enfin pouvoir avancer. On est parti sur le sprint 2. Et le sprint 2 ressemble à ça. Alors, je vais le faire un peu plus détaillé avec vous, du coup. Le sprint 2 ressemble à ça. Donc, qu'est-ce que vous voyez? Vous voyez qu'ici, vous avez votre prêt tout d'un coup qui se casse la figure. Parce que vous aviez plein de trucs, vous étiez sûr que c'était prêt, mais en fait, ça ne l'est plus. Donc, vous avez plutôt intérêt à le redescendre. Ah, oui, c'est... Bravo!
Merci!
Il y a de la couleur, c'est merveilleux. Je ne vous raconterai pas l'état du premier quand on m'a dit« Ah non mais Stéphane, on ne voit rien du tout, j'ai passé mon week-end à retailler toutes les couleurs pour que ce soit bien pour ceux qui sont daltoniens, ceux qui ne voient pas les... » Voilà, c'est le problème avec un CFD, si vous êtes daltonien, ça devient vite insupportable. Donc qu'est-ce qu'on voit sur ce magnifique CFD après 10 jours de plus à la fin du deuxième sprint? Donc la fin du premier sprint est ici, première action, ça tombe, le ready tout d'un coup diminue. Vous avez toujours vos éléments qui sont ici, puis tout d'un coup, hop, ça y est, c'est bon, vous avez réussi à poser vos conditions d'acceptation, on arrive à réavancer. On continue à développer, le backlog remonte, vous avez à nouveau des fonctionnalités qui sont prêtes, ok c'est pas mal. Ici vous avez un peu de blanc, ça veut dire que le développement est fini. Là, vous êtes sur le test. Vous avez du test, vous avez du test. Il y a un blocage. Vous avez du test qui est terminé. Vous avez à nouveau un blocage. Ici, vous avez plein de trucs qui sont finis. Là, tout d'un coup, on a fini plein de développement. Puis là, vous avez à nouveau plein de blocages.
On m'appelle comme d'habitude. Stéphane, on a l'impression qu'il y a un truc qui ne va pas. À ton avis, c'est quoi? Coach, qu'est-ce qu'on fait? Qu'est-ce qui va se passer là maintenant tout de suite? Question! Rendez-vous sur K.O.U.T. Allez, on est reparti. Je vous raconte tout de suite les résultats du précédent parce que c'est important.
Nous étions à Aubrac 1er.
L'Ectra est passé devant. Ouh là là là là, l'Ectra est passé devant avec 1900 points. Ils sont en train d'enterrer tout le monde. La question avait l'air d'être un peu difficile, donc on va essayer de reposer une question plus simple pour celui-ci. Donc, qu'est-ce qui ne va pas sur ce... C'est quoi le problème?
Je suis désolé, j'appuie sur le bouton. Ouais, quel est le problème que met ce CFD en lumière? Je vais vous le laisser afficher. Donc nous disions, en rouge, le backlog est trop grand. En bleu, les limites de WIP ne sont pas respectées. En jaune, il n'y a pas assez de testeurs. En vert, le métier n'est pas disponible pour la recette. Je répète, rouge, backlog trop grand. Bleu, les limites de WIP ne sont pas respectées. Jaune, il n'y a pas assez de testeurs. Vert, métier pas dispo.
Celui-là, là ? Ça, ça veut dire... Non, il ne se tourne pas forcément les pouces. Ça veut juste dire que le développement est terminé.
Sur le sprint, ils ont fini les devs.
Fin de sprint, ils ont fini tous les devs.
Je redonne les deux couleurs. Rouge, backlog trop grand. Bleu, limite de whip pas respectée. Jaune, pas assez de testeurs. Vert, métier pas dispo pour la recette.
Il vous reste 14 secondes. Attention, attention.
J'ai 14 réponses et j'ai oublié de regarder combien j'avais d'équipe. C'est dommage. Vous êtes tous bons? On va dire que vous êtes tous bons.
Et donc la bonne réponse est...
Ah! La bonne réponse était la jaune, il n'y a pas assez de testeurs. Donc le pourquoi. Rentrons dans le pourquoi, c'est là où ça devient intéressant.
Donc le pourquoi est ici. Qu'est-ce que vous voyez? On est sur de l'analyse graphique. Vous avez six éléments qui sont dans la partie développement. Et quand vous regardez la progression, ça monte, ça monte, ça monte, mais vous n'en avez qu'un qui est tiré en test. objectivement, et vous avez exactement le même sujet ici, vous avez des éléments qui sont là, mais vous n'en avez qu'un seul qui est tiré en test. Et là, il tient, là, vous voyez, il y a quand même un truc, moi, qui en tant que coach me choque toujours, c'est-à-dire que là, vous voyez que vous avez presque un smooth flow, vous avez juste un élément là, puis vous avez juste un élément là. Ce qui est bizarre, c'est que là, vous ne voyez pas cette progression.
Le coach qui a l'habitude, à l'intuition, ça sent les testeurs qui ne sont pas très disponibles. Qu'est-ce qu'on fait? On va commencer à discuter avec l'équipe.
Donc vous avez six éléments qui sont en fin de développement, mais vous n'avez rien qui est tiré en test. Pourquoi? Ah, le testeur est parti sur un projet critique. Au secours, c'est urgent, vite, il faut vite le prendre. Donc votre équipe qui devait être auto-organisée, dans laquelle vous aviez toutes les bonnes compétences, tout d'un coup, il en manque une de compétence. Et donc vous n'arrivez pas à tirer le flux de travail. Donc qu'est-ce que vous faites? Une proposition parmi d'autres. Vous pouvez commencer par faire du cross-testing. Vous faites du pair testing. Un développeur va tester les fonctionnalités d'un autre développeur. Ça permet de monter un peu ou d'accélérer. Et du coup, de prendre le testeur que quand il est disponible pour aller faire un test un peu plus profond. Et puis du coup, on va essayer de recruter un nouveau testeur parce que tant qu'il y a... Ça permettra d'aller plus vite et d'avancer la création de valeur. Voilà. Et donc ça, c'est vraiment ce que vous raconte ce CFD. Le CFD ne vous dit que ça. Alors il ne vous dit que ça parce que vous avez été discuté, il pourrait y avoir d'autres causes, d'autres problématiques. Mais là, concrètement, parce que vous avez discuté avec l'équipe, vous êtes en mesure de voir que vous avez trop d'éléments en développement, pas assez en test, et donc il y a un problème dans votre construction de flux de valeur.
C'était une très bonne rétrospective, équipe. Je vous remercie. Essayons de continuer à avancer et passons sur un nouveau sprint. Ouf! Ouh là là là là, ça commence à faire mal aux yeux.
Alors, arrivons à la fin du sprint 3, 30 jours après, qu'est-ce qu'on voit ? Alors déjà, je me dis, oulala, on voit beaucoup de couleurs.
C'est plutôt positif. On voit enfin un peu de valeur. Le truc en jaune que vous avez là, c'est les trucs qui sont déployés. Donc il y a des trucs qui sont partis en déploiement.
Mais il y a quand même beaucoup de trucs qui sont bloqués et tout d'un coup qui se débloquent. Mais on en garde un bloqué, on ne sait pas très bien pourquoi. Notre problématique du sprint précédent était les testeurs. Ok, on a une courbe de test qui remonte à peu près sur le format en fin de développement. Plutôt pas mal. Bon.
En recette, il y a un truc bizarre. Ouais, en effet, en recette, il pourrait y avoir un truc bizarre. Donc, vous êtes l'équipe. On va pouvoir continuer.
Avec une question. Qu'est-ce que c'est que le problème dessus? L'Ectra est toujours en avance, mais Justello a bien bien rattrapé. Qui est Justello?
Non, Justello. L'équipe Justello. Ouhou! On sent qu'il y a des équipes qui sont bien en forme.
Je ne les vois pas. Je suis désolé, je ne les vois pas. Non, je ne les vois pas. Non, non, je suis désolé, je ne les vois pas. Allez, on va repartir là. Hop, hop, hop. Donc, question. Qu'est-ce qui ne va pas sur ce CFD? Repartons.
C'est quoi le problème de CFD? Alors attention, 4 réponses. Comme d'habitude, je ne suis pas très innovant. Le backlog est trop grand. Les limites de WIP ne sont pas respectées. Il n'y a pas de testeur, le métier n'est pas disponible. Si vous trouvez que c'est une répétition, c'est en effet fait pour. Je répète, c'est les mêmes réponses que la fois précédente. Le backlog est trop grand, c'est rouge. Les limites de WIP ne sont pas respectées, c'est bleu. En jaune, il n'y a pas assez de testeurs. En vert, le métier n'est pas disponible.
Le métier n'est pas disponible.
Rouge, backlog trop grand. Bleu, whip pas respecté.
Vert. Non, jaune, pas assez de testeurs. Vert, pas de métier.
Il doit me rester une équipe qui n'a pas encore répondu.
Tout le monde a répondu« Ouh ouh! » Oh, mais vous êtes devenus des grands professionnels! Quasiment tout le monde a bien répondu. Désolé pour... Alors, le backlog est trop grand et probablement une difficulté complémentaire, mais ce n'est pas celle de maintenant. Objectivement, par rapport au flux de travail, la vraie difficulté immédiate n'est pas la taille du backlog. La difficulté, c'est qu'on ne livre pas en prod. C'est un des premiers basiques de la démarche Lean. L'enjeu, c'est de sécuriser le client et donc d'apporter de la valeur. Donc la taille du backlog, pour l'instant, n'est pas une question. La question, c'est que là, vous avez énormément d'éléments qui sont dans le flux de production et qui n'apportent pas de valeur, qui ont été objectivement développés. Vous avez tout ça là qui est développé, mais qui n'est pas encore testé par votre métier ou qui n'est pas encore recété. Le premier problème de l'équipe, c'est celui-ci. D'accord? Hop! Donc on a discuté. Donc on a plein d'éléments bloqués en début de sprint, ça tombe, c'est super chouette.
On a un élément qui reste bloqué. Et puis concrètement, l'équipe, quand on discute avec elle, parce que c'est finalement toujours la question la plus intéressante quand vous regardez des graphiques, ce n'est pas de regarder le graphique. On n'est pas là, je vais tacler exprès les spécialistes du Lean Six Sigma et du Black Belt, l'enjeu n'est pas l'indicateur, l'enjeu est ce que permet de faire l'indicateur ou le modèle graphique. Et donc que permet de faire le modèle graphique? Il permet d'initier une discussion avec l'équipe sur quel est le fond du problème. C'est le 5 pourquoi de la démarche Lean. Et donc le 5 pourquoi, c'est quoi? En fait, le métier n'est pas là. L'équipe n'a pas suffisamment échangé avec le business sur le comment est-ce qu'on fait pour recéter convenablement la fonctionnalité. Et du coup... Avancer sur un mode de déploiement. On est sur des sprints, mais ça reste des sprints très théoriques. D'accord? Donc, c'est quoi la bonne action ou c'est quoi une des actions possibles si vous faites une résolution de problème? L'enjeu, c'est fluidifier la recette et donc mettre le client plus à disposition. Une heure par jour, la moitié de la journée, peu importe. Régulièrement, le client est là pour faire la recette des fonctionnalités qui sont livrées.
En tant que bon coach, normalement, après 3 sprints et quasiment 30 jours de développement, Ma posture est de dire, les gars, maintenant, vous devriez être quasiment autonomes. Ça tombe bien avec les résultats qu'on a là, ça le prouve, vous êtes quasiment autonome. Et donc, on peut arriver à aller après 50 jours.
Ah, il va se passer beaucoup de choses en 50 jours. En fait, sur les 20 jours de plus. Donc il y a deux sprints qui se sont écoulés. Et ma question va être complètement différente du coup. Parce qu'en tant que coach, je suis quasiment sorti. L'équipe est devenue autonome, elle a compris le mode de fonctionnement. Et donc je vais revenir plutôt pour leur demander, mais qu'est-ce que vous avez fait? Non pas pour relever les compteurs, mais pour essayer de les challenger, pour essayer de les faire avancer encore plus. Et voir s'ils ont encore besoin d'un coach ou s'ils peuvent se débrouiller comme des grands. Donc après 50 jours, voilà ce qui s'est passé. Je vous laisse 30 secondes, une minute pour essayer de comprendre et de détailler. Je vais vous aider à détailler. On s'est arrêté ici.
On s'est arrêté ici. Fin du premier, fin du sprint 3. Qu'est-ce qu'on voit?
Premier niveau.
Deuxième niveau, ici vous avez plein d'éléments autour de ça termine, ça termine, ça termine, mais là vous avez une sorte de palier. En tant que coach, je suis quasiment sorti. L'équipe est devenue autonome, elle a compris le mode de fonctionnement. Et donc je vais revenir plutôt pour leur demander, mais qu'est-ce que vous avez fait? Non pas pour relever les compteurs, mais pour essayer de les challenger, pour essayer de les faire avancer encore plus. Et voir s'ils ont encore besoin d'un coach ou s'ils peuvent se débrouiller comme des grands. Donc après 50 jours, voilà ce qui s'est passé. Je vous laisse 30 secondes, une minute pour essayer de comprendre et de détailler. Je vais vous aider à détailler. On s'est arrêté ici. On s'est arrêté ici. Fin du premier, fin du sprint 3. Qu'est-ce qu'on voit?
Premier niveau.
Deuxième niveau. Ici, vous avez plein d'éléments autour de ça termine, ça termine, ça termine. Mais là, vous avez une sorte de palier.
Vous avez déjà compris le qu'est-ce qui va se passer derrière.
Exactement. L'Ectra est toujours premier. Racing 1985 talonne de pas grand-chose. Il y a 200 points. Cannes BE est à 2400, donc ils sont juste derrière également. Attention, il y a du challenge. Et on est sur l'avant-dernière question. Donc la question d'après est le... Mais qu'est-ce que l'équipe a fait? Quels sont les problèmes que l'équipe a résolus par elle-même durant ces deux sprints?
C'est une bonne question.
Quel problème l'équipe, le CFD a-t-il mis en lumière? Et donc, qu'est-ce que l'équipe a fait pour régler ces problèmes? Donc, je reprends. Le backlog est trop grand, on le réduit. Il manque des développeurs, on en recrute. Le déploiement est trop lent, livraison tous les trois jours. Les SLA ne sont pas définis, l'équipe les définit.
Qu'est-ce que l'équipe a fait durant ces deux sprints? Je vais vous les relire parce que là, on arrive sur des trucs un peu touchy. Rouge, le backlog est trop grand, on le réduit. Bleu, il manque des développeurs, on en rajoute. Jaune, le déploiement est trop lent, livraison tous les trois jours. Vert, les SLA ne sont pas définis, on les pose.
Les SLA ne sont pas définis, l'équipe les définit.
C'est vert.
Je répète une dernière fois.
Rouge, le backlog est trop grand. L'équipe le réduit. Bleu, il manque des développeurs, on en recrute. Jaune, le déploiement est trop lent, on fait une livraison tous les trois jours. Vers les SLA ne sont pas clairs, on les définit.
Non, vous ne pouvez pas changer de réponse, c'est pour ça que vous avez 90 secondes. Ouh là là!
Donc il y avait deux bonnes réponses.
Donc, quels sont les deux éléments qu'on arrive à voir là-dedans?
Ici, quand vous regardez, vous avez une taille de backlog qui est super élevée. Quelle est la prise de conscience de l'équipe? Vous arrivez à là. Vous êtes ici pour commencer la phase de prêt, vous avez un stock monstrueux. En fait, vous êtes en train de préparer du gaspillage.
Le rythme de croissance ou de développement de l'équipe, ne permettra pas dans un délai raisonnable de travailler l'intégralité du backlog. Du coup, quelle est la bonne démarche de l'équipe là-dessus? On fait tomber le backlog. On négocie avec le PO, avec les parties prenantes, pour se dire que raisonnablement, ça ne sert à rien d'avoir un TAC comme ça. C'est juste complètement déprimant pour tout le monde. Oui.
Le backlog, c'est le backlog par rapport au sprint ou c'est le backlog?
C'est le backlog du produit.
Du produit global.
Oui.
Quel est l'intérêt de le faire du mieux plus que ça? Après, on mettra peut-être un mois de plus, deux mois de plus pour le finaliser.
Et peut-être qu'en fait, ton équipe, elle n'a pas deux mois de plus à faire. Et donc du coup, plutôt que de te dire que tu te gardes un backlog dans lequel tu ne sais pas quoi faire, tu as une des pratiques qui est plutôt agile qui est de dire, si c'est dans le... Le backlog et que ça ne sera jamais fait, autant l'enlever du backlog.
Ce n'est pas toujours le cas.
On est d'accord. Ok, j'accepte.
Oui.
Ça peut être une conséquence de plein d'améliorations. Là, pour le coup, c'est le backlog est trop grand. L'équipe se dit, OK, coupons. OK. C'est, j'entends vos objections.
Non. Non.
C'est psychologique et c'est surtout un niveau de discussion. Alors, la taille du backlog en tant que telle a assez peu d'effet.
Maintenant, en termes de négociation et de discussion avec les parties prenantes, il est important de poser le qu'est-ce qu'on va faire dans un délai raisonnable. Et donc, la réduction du backlog est un élément pour aller discuter avec le client et dire, vous vouliez tout ça, objectivement, ce n'est pas raisonnable, on rescope et on découpe. Et peut-être qu'on le fera plus tard. Mais concrètement, on n'a plus besoin de l'avoir présent en tant que charge pour le produit. On peut se dire, il y a un moment, on a objectivement fini le produit. On est en face sur le quoi et on s'arrêtera là. Et ça n'empêchera pas de le faire augmenter un moment ou un autre. Ce n'est pas le sujet de cette conférence. Donc ça, c'est le premier élément. Ça grimpe, ça tombe. Deuxième élément, ici. Ici, qu'est-ce qu'on voit? On voit que c'est flat.
Exactement. Mais ça, encore une fois, c'est des éléments qui sont assez clairs. ou assez standard d'un mode de fonctionnement quand vous bossez dans une grande boîte, ou pas d'ailleurs. Qu'est-ce que vous avez? Vous avez des règles ou pas de règles avec la partie infrastructure sur le comment on déploie. L'enjeu, encore une fois, c'est de déployer de la valeur assez régulièrement pour le client. Donc si vous n'avez pas posé les règles avec votre infra, avec vos équipes d'infrastructure sur le comment est-ce que vous déployez, souvent vous ne déployez pas. Les furets sont très bons là-dedans. Petit bonjour fait exprès.
Donc si vous n'avez pas de règles, qu'est-ce que vous faites? Vous commencez à poser des règles avec l'infrastructure sur le comment est-ce qu'on fait le déploiement avec les ops. Et donc vous dites que vous n'avez peut-être pas besoin de livrer tous les jours. Vous pouvez, parce que c'est compliqué parfois de livrer tous les jours, vous pouvez vous dire, on va livrer tous les trois jours. Et donc vous posez une règle d'équipe avec les opérations en disant, tous les trois jours, on va livrer. Et donc ça permettra de sortir la valeur tous les trois jours dessus. C'est ce qui fait la forme un peu bizarre par plateau que vous voyez là. Tous les trois jours, on va livrer un élément. Et donc trois jours, c'est un délai raisonnable, c'est un trade-off entre quelle est la valeur que je garde en stock versus le coût de mon déploiement.
C'est un premier pas avant de faire autre chose. Ok? Il me semble qu'on a fait le tour de cette première journée de ces 50 jours et 5 sprints avec une magnifique équipe qui est passée d'un mode scrum pur à un mode avec quelques éléments cambans. Donc il va nous rester deux, trois trucs à voir intéressants pour continuer cette discussion. qu'on vient d'initier avec l'équipe, avec le PO, avec les parties prenantes.
Donc le premier élément, c'est le CFD. En fait, le CFD, c'est un peu comme un burn-up. Et finalement, c'est même très largement comme un burn-up. Donc là, j'ai pris un truc qui ressemblait à ce qui est du Excel pour faire des magnifiques graphes. Donc si vous prenez votre magnifique Excel, Vous avez plein de trucs super intéressants. Vous pouvez mettre des courbes de tendance sur un magnifique fichier Excel avec des graphes. Et donc, quand vous commencez à mettre des courbes de tendance, vous pouvez commencer à approximer plein de choses. Vous pouvez en fait tirer des traits. Toutes choses égales par ailleurs, si le rythme de l'équipe reste toujours le même, alors si je voulais sortir l'intégralité de mon backlog que vous avez là-haut, il me faudrait à peu près autant de temps. Ça sort largement, il faudrait quasiment multiplier par deux l'élément que vous avez là. Donc vous pouvez commencer à discuter avec votre client sur le est-ce que vous êtes prêt à investir autant pour pour faire, pour sortir. C'est exactement ce qu'on fait avec un burn-up habituellement. Le burn-up, c'est vraiment, étant donné la tendance, voilà ce qu'on fait. La différence fondamentale, c'est que là, vous pouvez aller travailler aussi bien sur le modèle de construction, de production, que de délivrer. Et donc c'est à ça que peut vous servir un CFD, c'est à construire ce type de discussion.
Oui, alors, par rapport à la question, en ordonnée, on a bien ici le nombre, moi j'appelle ça des éléments de travail. Mais en fait, ça peut être n'importe quoi. Je préfère travailler à un niveau unitaire. Pour moi, l'enjeu, c'est d'avoir de toute façon des fonctionnalités qui sont assez proches en termes de taille. Si les équipes ne sont pas matures, vous mettez des story points, des tailles de t-shirts qui sont plus compliquées à empiler que des story points, mais ce n'est pas très grave, ou des tâches, ou ce que vous voulez. Concrètement, l'enjeu est d'avoir un... Un indicateur, un format identique pour tout ce que vous mesurez dans votre flux. C'est le seul point important.
Ça, c'était le premier élément. Donc, à quoi ça sert un CFD? Ça sert à ça, à extrapoler des dates de fin. Un CFD va également vous servir à travailler sur vos encours de valeur. Donc imaginez, ou imaginons, que par rapport au premier graphique que je vous avais montré, vous aviez une valeur qui était positionnée sur chacune de vos fonctionnalités. Vous voulez savoir quelle est la valeur en stock. C'est-à-dire ce que Don Reinertsen appelle le coût du délai. Donc combien est-ce que ça va coûter ou à combien s'élève le coût de libérer des fonctionnalités? En fait, c'est des éléments que vous allez voir très vite. Ça, c'est tout votre stock. C'est tous les éléments sur lesquels vous avez commencé à travailler et qui ne sont pas encore déployés, disponibles par le client ou pour le client. Oui.
Tu as raison, c'est une erreur de ma part. Merci.
Donc ça, une fois que vous avez cet élément-là, vous pouvez très rapidement, non, ce n'est pas vous pouvez très rapidement, vous calculez la somme des valeurs de chacun des éléments. Si vous arrivez à le faire, ce n'est pas toujours facile qu'on soit bien d'accord. Et vous êtes capable de dire, voilà le coût ou voilà le montant qui est en stock aujourd'hui. L'enjeu, c'est plutôt qu'ils se réduisent, c'est un peu ce que vous avez ici.
C'est exactement ce qui se passe d'ailleurs avec l'équipe. C'est l'enjeu de rentrer dans une démarche ligne, c'est de travailler sur avoir le moins d'encours de valeur bloqués dedans.
À la fin, il n'y a plus de backlog, mais tu pourrais toujours...
Oui, parce que pour les films, tu ne peux pas avoir un...
C'est ça, exactement.
Le dernier élément avec un CFD que vous pouvez commencer à regarder, c'est les temps de cycle. Alors c'est une première représentation graphique, je reviens dessus juste après. Donc finalement, quand vous rentrez dans un modèle qui devient stable, c'est-à-dire que vous arrivez sur une certaine stabilité de votre flux de production, c'est le cas là, quand vous regardez, si vous tirez des droites, concrètement vous êtes assez stable. Ça ne veut pas dire que la stabilité est bien ou mal, c'est juste qu'objectivement votre système devient stable. Alors vous pouvez commencer à travailler sur des temps de cycle. Vous pouvez regarder quel est le temps qu'il vous faut pour passer d'un élément ici à un élément qui va être fini d'être développé, mis en recette, etc. Le à quoi ça sert est plus intéressant que juste présenter ça. Le à quoi ça sert est l'élément qui permet de faire des arbitrages aux parties prenantes. Si ici vous voyez qu'il vous faut 6 jours, pour un élément de prêt à un élément qui est en recette, le PO qui vient vous voir ou qui vient voir l'équipe en disant« j'ai cette fonctionnalité à sortir le plus vite possible, quel est le délai moyen pour le sortir, dans combien de temps je peux l'avoir? » La réponse est« il te faut six jours». Vous le voyez directement. Et alors là, ça commence à rentrer dans une dynamique où vous pouvez négocier avec votre PO. Vous pouvez négocier avec vos parties prenantes si vous n'avez pas de PO. Parce que quand vous êtes en mesure de dire, regardez, il nous faut six jours pour sortir un élément, tout d'un coup, on peut faire des... arbitrage, on va enlever ça, on remet ça, on peut poser un autre élément à droite, on peut poser un autre élément à gauche. Vous pouvez travailler le backlog de votre produit, non plus en mode sprint, mais en mode flux tiré. Ceci est plus important que cela, il me faut tant de temps pour le faire, j'en ai besoin maintenant.
On va arriver sur la dernière question. Attention, ça va être le challenge. Le smooth flow. Alors, on appelle smooth flow, ou j'appelle smooth flow, l'état du système dans lequel le flux avance en tendant vers la stabilité et la constance. C'est très, très aride. Concrètement, ça veut dire quoi? Ça veut dire que vous avez assez peu de variabilité à l'intérieur. Vous passez d'un truc où ça fait n'importe quoi, c'était le démarrage, où vous avez des gros tas qui s'empilent, qui bougent dans tous les sens, à un élément où, en moyenne, ça ne bouge pas trop.
À quoi ça sert ce smooth flow ? Pourquoi essayer de tendre vers le smooth flow?
Rendez-vous sur K.O.U.T. C'est la dernière question.
C'est pour vous faire réfléchir. L'Ectra est toujours premier, mais il est allié de très très près par Racing 1985. Je rappelle qu'à la clé, il y a un bouquin pour l'équipe.
Allez, pourquoi est-ce qu'on cherche un smooth flow dans la partie CFD? À quoi ça sert de faire du smooth flow dans le CFD? Quatre réponses possibles.
Première, rouge, c'est plus joli. En bleu, cela facilite la prédictibilité. En jaune, le client est content. En vert, l'équipe est contente. Je répète, rouge c'est plus joli, bleu prédictabilité, jaune client content, vert l'équipe est contente.
Bleu.
J'ai 12 réponses, je vois que vous êtes très très motivé là.
C'est quoi le bleu? Prédictibilité. Cela facilite la prédictibilité.
Je pense qu'on doit être bon. On est bon!
Cette question est trop facile.
Et oui, l'enjeu du smooth flow, c'est la prédictibilité.
L'enjeu du smooth flow, c'est la prédictibilité. Donc le flux continu, en fait, c'est quoi? Le smooth flow, c'est quoi? C'est un état du système dans lequel vous avez une livraison continue et stable des éléments de travail. C'est quoi le bleu ? Prédictibilité. Cela facilite la prédictibilité.
Je pense qu'on doit être bon. On est bon! Oh! Cette question est trop facile.
Et oui, l'enjeu du smooth flow, c'est la prédictibilité.
L'enjeu du smooth flow, c'est la prédictibilité. Donc le flux continu, en fait, c'est quoi? Le smooth flow, c'est quoi? C'est un état du système dans lequel vous avez une livraison continue et stable des éléments de travail.
C'est pour ça que j'aime bien le principe du robinet. Le principe d'un robinet, c'est que quand vous ouvrez, vous avez un flux continu. Quand vous ouvrez trop fort un robinet, ça m'arrive de temps en temps chez moi, vous prenez une énorme splash et vous êtes complètement trempé. Puis tout d'un coup, vous n'avez plus d'eau. Là, vous êtes super embêté et ça revient. Ce n'est pas super pratique ni pour le client. Là, en l'occurrence, c'est moi le client. Je n'aime pas être tout mouillé. Après, j'ai l'impression d'être mouillé. C'est désagréable.
L'enjeu, c'est d'éviter de bloquer la valeur. Encore une fois, l'enjeu du Lean, c'est d'éviter les gaspillages et de faire sortir la valeur au plus vite. La prédictibilité, c'est l'enjeu du smooth flow. Le smooth flow permet d'atteindre la prédictibilité. Et la prédictibilité... Ça va rendre vos clients contents. Si vous êtes en mesure de dire en moyenne, voilà en combien de temps je vais réussir à sortir vos éléments de travail, ça rejoint la discussion qu'on a eue ou que j'ai eue il y a deux minutes sur le comment est-ce qu'on sort des éléments et qu'est-ce que ça permet de dire un CFD. Et donc pour ça, peut-être bien qu'il me reste en fait une dernière question.
On va arriver sur les classes de service.
Et on va rejoindre les temps de cycle. Donc si je reprends les exemples qu'on avait précédemment, On va travailler sur un temps de cycle qui est de sa commence en dev à ses déployés. C'est une vision du temps de cycle. Tout le monde n'a pas les mêmes visions, etc. Différence entre l'Itaille. Time, cycle, time, tag, time, blablabla. Donc revenons là-dessus. Si on fait un nuage de points uniquement sur les 15 derniers jours du sprint, Vous voyez un truc qui ressemble à ça. Alors ce point-là est probablement déconnant, c'est sans doute le dernier point de la série d'avant. D'accord?
À partir de ce nuage de points, vous allez pouvoir construire un modèle comme celui-ci. Qui tout d'un coup est beaucoup plus lisible, parce que vous êtes passé d'un nuage de points, Donc chaque point est un élément du flux de travail avec la date de sortie ou le temps qu'il a fallu pour le sortir. Vous pouvez commencer à le regrouper. Excel fait ça très bien, mais tous les outils du marché font ça plutôt pas mal aussi. Et donc quand vous arrivez à un truc comme ça, c'est déjà pas mal, mais c'est encore un peu trop large. Donc l'enjeu c'est de rentrer sur des classes de service. Qui voit ce que c'est qu'une classe de service?
Oui, il y en a deux, trois. Je vais revenir très vite dessus. Une classe de service, c'est ce qui permet de typer un élément du flux de travail, une fonctionnalité, et de discuter avec une des parties prenantes pour lui donner un coût différent, par exemple, ou un délai de traitement différent. Et ou, d'ailleurs. Ou plein d'autres éléments en termes de qualité, etc. Donc là, on peut commencer à rentrer dans, ok, on voit qu'il y a des grands nuages de points et tout et tout, mais ça reste encore un peu en vrac.
Rajoutons un élément complémentaire, parce que j'avais une belle équipe. qui faisait du Scrum, donc avec une équipe Scrum, on arrive très vite à récupérer des informations comme par exemple des tailles de t-shirt. Des tailles de t-shirt, c'est plutôt simple. Donc on va dire qu'on a trois tailles de t-shirt, en vert dégoûtant un truc qui ressemble à du small, on a un bleu léger qui se voit très mal, celui qui est ici là, et on a un bleu très sombre, celui qui est ici.
D'accord? Ah ben là, tout d'un coup, on peut commencer à avoir un autre niveau de discussion. Quel est ce niveau de discussion? On va y arriver enfin avec mes gros sabots là.
C'est la prochaine grande question.
Hop, next.
Next. Allez.
Donc ma prochaine grande question sur K.O.U.T.
Je n'ai pas de participation chez K.O.U.T. Je vous le dis tout de suite. L'ECTRA est toujours premier. Racing BE talonne toujours autant. Attention, attention. Cambon BE est en train de prendre un peu la traîne. Il y a 100 points d'écart. Aubrac qui est le quatrième et un peu loin derrière, je dois vous le dire. Donc passons à la question d'après. Next. Que peut-on dire à son client avec ce diagramme? Avec un magnifique diagramme comme ça, qu'est-ce qu'on va dire?
Rouge, il faut plus de temps. Bleu, en moyenne, il faut moins de 6 jours pour livrer un taille M. Jaune. Les tailles L sont trop longues. Vers, nous pouvons livrer des S en moins d'une journée. Je répète, rouge, il faut plus de temps.
Bleu, en moyenne, il faut moins de 6 jours pour livrer une taille M. Jaune, M, M, M comme maman. Jaune, les tailles L sont trop longues, comme L, longue. Vers nous pouvons livrer des S en moins d'une journée.
Je crois que vous êtes en forme.
Bravo!
Super! On arrive au bout?
La réponse était la 2. En moyenne, il faut moins de 6 jours pour sortir une taille M. Le vainqueur, les vainqueurs, l'équipe vainqueur est donc Racing 1985. Vous pourrez venir me voir tout à l'heure, mais ne fermez pas votre caoutchouc, sinon je ne verrai pas que c'est vous, je serai un peu triste. De ne pas pouvoir donner des livres que l'équipe d'Orga du LKFR vous offre. Comment?
On est bien d'accord. On est bien d'accord, le L a une queue qui est très longue. Mais est-ce que c'est trop long?
Exactement. Donc concrètement, qu'est-ce que va dire un élément comme celui-ci? Un magnifique temps de cycle comme celui-ci. En fait, vous allez juste pouvoir dire des trucs très bêtes à votre client. Et j'aime bien dire des trucs qui ne sont pas bêtes en tant que tels, c'est juste qu'ils sont très simples à lire. En moyenne, on est en mesure de livrer des S en moins de 4 jours. Si tu me donnes un truc qu'on considère comme étant un S, dans 4 jours, c'est sorti.
C'est ça. En moyenne, d'ailleurs, ce n'est pas en moyenne, c'est dans tous les cas, on a des M qui sortent ici en moins de 6 jours. Et en moyenne, on les sort plutôt en 3 à 4 qu'en 5 à 6.
Et quand c'est L, on voit que c'est trop grand. Peut-être que c'est un problème. Mais peut-être que c'est un problème qu'on peut traiter avec le client. Pour l'instant, on ne peut juste que dire qu'un L, il faut plus de temps. Il y a une variabilité trop importante ou il y a une variabilité très importante sur les L.
Et concrètement, c'est déjà pas mal de pouvoir dire au client, quand tu me donnes un truc de taille L, je ne sais pas quand est-ce que je vais te le sortir, parce que c'est un peu compliqué. Peut-être qu'on peut travailler ensemble sur le comment est-ce qu'on fait pour casser, rendre plus simple, rentrer dans une autre classe de service. Et donc on arrive à une classe de service avec des éléments ou à premiers éléments de classe de service en travaillant avec ces diagrammes de temps de cycle qui sont déjà un peu customisés. On peut commencer à dire si tu me sors un S demain et que tu le veux en moins de 4 jours, Eh bien, écoute, mettons 20% de plus parce que tu me le considères comme étant une demande urgente. Eh bien, c'est très bien. Si on peut faire un markup de 20% sur le coût du développement, faisons un markup de 20% si c'est important pour toi.
Tu veux traiter des M plus vite? Ok, regardons ce qu'on peut faire pour traiter des M plus vite. Comment est-ce qu'on rentre sur des... les expédit lines, ce qu'on appelle généralement une ligne d'urgence, etc. Là, on commence à rentrer sur la vraie discussion et qui n'est pas de la discussion éthérée, c'est de la discussion qui est basée sur la donnée qui est propre à votre équipe. Ça implique évidemment que votre équipe ne bouge pas tous les deux jours parce que sinon vous allez casser votre système. Ça, c'est quand même quelques prédicats de base ou hypothèses de base pour réussir à avancer avec ce genre d'outils. Je crois que j'ai terminé sur la partie classe de service. Oui. Donc faisons une petite conclusion rapide. Histoire de poser tout ce avec quoi vous avez joué depuis tout à l'heure.
Vous pourriez avoir des tonnes de graphiques quand vous faites du Lean Kanban ou du Kanban ou du Lean. Moi, je ne vais en garder que trois. L'enjeu, ce n'est pas d'avoir des graphiques pour des graphiques, c'est d'avoir des graphiques qui vont vous servir à quelque chose. Et donc, les trois indicateurs clés pour moi sont le CFD, les blocages et les temps de cycle. C'est des graphiques qui sont assez peu larges. Donc, le point super chouette, c'est que vous pouvez même les mettre au-dessus de votre tableau. Vous les imprimez tous les jours, vous les imprimez toutes les semaines. C'est un bon élément de projection pour l'ensemble de l'équipe et même de projection pour les clients qui viennent voir l'équipe. Voilà comment on bosse. Transparence. C'est très simple à faire. Vous n'avez besoin de rien. Même si vous n'avez aucun outil, aucune technologie très compliquée, c'est simple à mettre en œuvre. C'est, dans le pire des cas, un post-it, un fichier Excel et sortir les éléments. Si vous en avez besoin, je vous en donne. Sinon, vous les construisez, ils seront à vos couleurs, ce sera plus sympa.
Et vraiment, le point important, c'est que vous êtes sur uniquement des éléments du flux de travail. Et pour moi, c'est ça le point important. En fait, la taille de vos t-shirts, la taille de vos stories, on s'en cogne. En tout cas, moi, ça ne m'intéresse pas en tant que coach. Ce qui m'intéresse, c'est de savoir combien vous en avez en stock. Si vous voulez compter les tailles, c'est très bien de compter les tailles. Moi, ce qui m'intéresse, c'est est-ce qu'on arrive à livrer de la valeur? Quelle est la taille de la valeur? C'est une autre question. Un CFD devrait... représenter vos éléments du flux de travail qui avance au fur et à mesure. Objectivement, quand vous développez, vous pourriez prendre votre post-it, le mettre sur votre écran, et quand vous l'avez fini, vous prenez votre post-it et vous le mettez sur l'écran de votre voisin qui doit aller sur l'étape d'après. Ou déplacer, parce que normalement c'est du flux tiré. Bon, passons. Je crois que j'ai fait le tour. Donc je vous laisserai... Ouais, donc là, je vais laisser... Oui, je vais finir avec un dernier élément.
L'analyse graphique en Kanban comme en analyse financière, ce n'est pas une science. qu'on soit bien d'accord, ce n'est que de l'analyse graphique.
Il n'y a aucun élément scientifique, il y a quelques éléments scientifiques sur la théorie des flux qui vont derrière, mais ce n'est pas une science à proprement parler. C'est un élément pour entamer une discussion. Et donc, c'est des éléments qui permettent de titiller l'intuition et d'aller chercher les blocages. L'enjeu, encore une fois, du Lean, c'est d'aller chercher tous les blocages, de faire sauter les blocages et tous les éléments de gaspillage. Un blocage est un élément de gaspillage particulier. Et donc, encore une fois, et un peu comme avec tout le monde, c'est très simple.
Mais ce n'est pas si facile que ça.
Sur ce, si vous voulez aller plus loin, je vous ai laissé... Pablo Pernaut, il n'y a pas longtemps, a écrit deux articles autour des CFD qui n'ont rien à voir avec ce que j'ai raconté, mais qui sont plutôt rigolos. C'est les CFD expliqués à mon gamin de 5 ans ou de 8 ans, je ne sais plus, avec des cookies. Et donc, ça m'a beaucoup fait rigoler. Et je trouve que c'est quand même une très bonne autre approche de comment est-ce qu'on raconte les CFD. Et sur InfoQ, vous trouverez un ouvrage qui s'appelle Priming Kanban, qui raconte les différentes étapes. Pour ceux qui étaient là l'année dernière, j'ai fait un atelier là-dessus. Voilà. Moi, j'ai terminé. Si vous avez des questions, n'hésitez pas. Je suis encore là pour vous. Et je crois qu'on a tenu le timing, ce qui est quand même super chouette.

Transcription