[Hors-série #7] Fluidité, responsabilité et agilité : une conversation sur Kanban – Code, Café et Agilité – Olivier My

Olivier My  00:00

– Ça fait international.

Khamphon Inthavong  00:02

– Exact. Je leur ai dit hier, est-ce qu’on en réussit avec quelqu’un qui est en France ? Comment vous allez faire et tout ? Je dis, t’inquiète, on va gérer.

Benoit Bourcier  00:09

– On va se débrouiller.

Khamphon Inthavong  00:10

– Pour l’instant, ça a l’air de fonctionner. Tu nous entends bien ?

Benoit Bourcier  00:13

– Oui, je vous entends très bien.

Khamphon Inthavong  00:14

– Nickel.

Benoit Bourcier  00:21

– Et puis, on s’est déjà présenté en off un petit peu avant. Exact. On a Olivier avec nous, Kanban toujours qui est avec nous, et je suis là pour… pour vous poser des questions. J’aime m’intéresser à l’agilité, à tout ce qui s’y passe. Et Olivier, toi, aujourd’hui, tu viens nous parler surtout de Kanban. Tu es spécialisé là-dedans.

Olivier My  00:40

– En tout cas, je crois que c’est pour ça que vous m’avez appelé, oui.

Benoit Bourcier  00:43

– Exactement. Si on devait revenir aux bases, si jamais tu avais un enfant devant toi, comment tu lui expliquerais ce que c’est Kanban, comment ça fonctionne ?

Olivier My  00:54

– Je n’étais pas prêt à ça. Un enfant, qu’est-ce que je lui dirais ? En fait, je pense que la métaphore que j’utiliserais, parce que je suppose que cet enfant est déjà allé dans une voiture, je dirais que c’est comme sur l’autoroute. Tu vois, sur une autoroute, il y a des fois une autoroute qui est fluide et ton voyage se passe vachement bien. Tu peux regarder les paysages et tu arrives à l’heure qu’on t’avait dit que tu arriverais. Parce que la plupart du temps, tu demandes toujours « mais c’est quand qu’on arrive ? » Au moins, on peut te répondre, en tout cas, et que justement, ce qu’on t’a dit s’avère être vrai. Mais des fois, il y a des bouchons et malheureusement, quand il y a des bouchons, tout devient un peu plus difficile, moins prévisible et tu es moins content. Et bien, Kanban, c’est une manière pour toi d’avoir plutôt la première image que la deuxième.

Benoit Bourcier  01:50

– On évite les bouchons.

Olivier My  01:52

– Voilà, c’est ça. Vous limitez au maximum les bouchons.

Khamphon Inthavong  01:55

– Donc là, ce que je comprends… ton image c’est en fait on a une voie qui est toute tracée mais il se peut qu’il y ait des obstacles dans le chemin que tu as vu.

Olivier My  02:05

– Que tu as tracé en tout cas dans l’image que j’ai eu dans ma tête quand la question est arrivée c’est plus de dire que tu as un espace qui est plutôt fluide c’est pas tellement un chemin tout tracé c’est juste qu’effectivement l’autoroute est toute droite mais c’est plus de se dire un chemin où il y a de l’espace et un autre où il n’y a pas d’espace Et dans le monde de l’entreprise, j’ai l’impression, en tout cas, je ne sais pas si vous vivez la même chose, mais s’il y avait un choix entre les deux de ce qui est le plus représentatif en entreprise sur le travail, la quantité de travail à faire notamment, ça ressemble souvent beaucoup plus à une autoroute embouteillée qu’à une autoroute qui est fluide.

Khamphon Inthavong  02:47

– Exact. On arrive à avancer quand même.

Benoit Bourcier  02:50

– Oui, on arrive à avancer quand même.

Khamphon Inthavong  02:54

– Et justement… Donc là, tu as expliqué un peu, tu as imagé un petit peu le Kanban et tout ça. Mais on parle depuis le début avec Benoît de l’agilité. On a vu le Scrum ensemble. Et donc, c’est pour ça qu’on t’a invité. C’était pour que tu nous parles un peu du Kanban. À ton avis, pourquoi est-ce qu’il faudrait utiliser le Kanban sur un projet ?

Olivier My  03:19

– Déjà, un premier aspect, au-delà d’utiliser du Kanban, je pense que le fait d’avoir plusieurs… corde à son arc, c’est une manière d’avoir la capacité de pouvoir réagir de manière différente. C’est-à-dire que si on dit je veux aller vers plus d’agilité et je n’ai que Scrum pour le faire, c’est peut-être un peu réducteur. Donc déjà, c’est un premier aspect. Ensuite, le fait d’utiliser du Kanban, de ma fenêtre en tout cas, c’est s’accorder énormément de flexibilité. Parce que du coup, la manière dont Kanban fonctionne est… extrêmement flexible, avec un petit peu moins de règles, mais qui dit plus de flexibilité, dit aussi plus de responsabilité. Parce que comme on sait, avec de grands pouvoirs viennent de grandes responsabilités. Et pour moi, c’est ça en fait qui est la grande force de Kanban, mais du coup qui dit beaucoup de responsabilités, dit beaucoup de choix à faire, beaucoup d’initiatives à prendre, mais également en assumer les conséquences. Ce qui est en fait moins le cas quand on fait du Scrum, alors je dis pas qu’on n’assume pas les conséquences. mais il y a un cadre qui est posé. Du coup, c’est beaucoup plus facile de se plaindre du cadre que de se plaindre de ses propres décisions. Pour moi, quand tu fais du Kanban, ce que j’aime dire aux gens parfois dans une boutade, c’est à quoi ça ressemblerait un Scrum où on ferait vraiment confiance aux gens. Pour moi, en fait, ce serait du Kanban. Pourquoi je dis ça ? D’accord, et c’est pas juste un troll, c’est juste une vision que j’ai de la chose. C’est que dans Scrum, ce qui est très rassurant, et c’est ça qui fait que ça marche bien, c’est qu’on a une impression de contrôle parce qu’on le limite en temps. Et donc c’est la contrainte de temps qui amène les gens à produire d’une certaine manière. Donc à découper différemment et à produire d’une certaine manière.

Khamphon Inthavong  05:12

– Tu parles de temps, tu parles de sprint, c’est ça ?

Olivier My  05:14

– Oui c’est ça. En tout cas ce qu’on appelle sprint c’est bien une time box, donc c’est bien une limite de temps. Donc c’est exactement ça. En fait quand tu fais du Kanban, tu pars du principe que les gens font de leur mieux lorsqu’ils sont en train de faire quelque chose. Et du coup tu ne vas pas leur mettre une contrainte à eux en termes de temps. Tu vas limiter le nombre d’éléments de travail sur lesquels ils sont en train de travailler justement pour enlever le maximum d’obstacles sur leur chemin. Tu vois ce que je veux dire ? Donc en fait, la philosophie derrière est légèrement différente. Mais qui dit philosophie différente ne dit pas incompatibilité. Et c’est ça qui, pour moi, est une dérive majeure ou en tout cas un mythe qui existe encore, c’est d’opposer l’un et l’autre. C’est comme si tu comparais des choux et des carottes ou tout autre légume que tu souhaites. Et pour moi, c’est vraiment ça qui est important à remettre en exergue. Moi, un truc que j’avais lu justement à l’époque quand moi je me formais, j’avais lu le bouquin de Laurent Morisseau, qui est quand même la référence, on va dire, française sur le sujet. Il y avait un truc qu’il avait écrit qui m’a beaucoup éclairé, c’est qu’il avait décrit Kanban comme un méta-processus. Et en fait, quand tu comprends que Kanban, c’est un méta-processus, c’est-à-dire que c’est quelque chose qui se met sur un processus. tu comprends en fait que tu peux très bien mettre du Kanban sur du Scrum.

Khamphon Inthavong  06:38

– Exact.

Olivier My  06:39

– Parce que Scrum, c’est un processus. Donc du coup, tu ne peux pas opposer les deux, parce que du coup, la fonction est différente.

Khamphon Inthavong  06:47

– Oui.

Olivier My  06:47

– Et ce qui est intéressant… Pardon, vas-y.

Khamphon Inthavong  06:50

– Non, non, pardon, je te coupais. Mais c’est vrai que tu as raison, parce que souvent, nous, quand on parle entre nous, même entre collègues, on dit toujours, tu utilises du Kanban ou du Scrum. On ne met jamais… On ne dit pas que tu peux faire du Kanban dans du Scrum, comme tu dis, comme c’est un métaprocessus. Mais c’est vrai que même dans tout ce qu’on entend, c’est soit tu fais du Kanban, soit c’est du Scrum. C’est deux méthodes agiles complètement différentes, alors que non, en fait. C’est ce que tu nous dis.

Olivier My  07:14

– Oui, c’est ça. C’est-à-dire que pour moi, par contre, c’est différent de faire du Kanban dans du Scrum ou du Scrum dans du Kanban.

Khamphon Inthavong  07:21

– Tu peux faire du Scrum dans du Kanban ?

Olivier My  07:23

– Oui.

Khamphon Inthavong  07:25

– OK.

Benoit Bourcier  07:25

– En tout cas, moi.

Olivier My  07:27

– C’est l’impression que j’ai.

Benoit Bourcier  07:29

– Il n’y a pas de souci, mais le fonctionnement du Kanban, exactement, ça ressemble à quoi ? Une équipe qui fonctionne en mode Kanban. Parce qu’aujourd’hui, moi, je connais Scrum, j’ai toujours travaillé en Scrum, en Sprint. Je viens de comprendre que Kanban, il n’y avait pas cette notion de Sprint. Moi, si aujourd’hui, je dois résumer ma compréhension de Kanban, c’est un tableau avec des colonnes et des post-its à l’intérieur. Ce qui, en fait.

Olivier My  07:50

– Est le cas de 90% des gens.

Benoit Bourcier  07:52

– Oui, oui, oui. Et qu’est-ce qu’il y a de plus, en fait, que ça aujourd’hui en Kanban ? Comment ça… Ça fonctionne ?

Olivier My  08:01

– En fait, ce qui est intéressant, c’est que ce n’est pas forcément en plus. Parce que du coup, en fait, Kanban est très léger. Donc vraiment, ce n’est pas forcément en plus. Mais pour moi, une équipe fonctionnelle en Kanban, c’est une équipe qui prend les bonnes décisions avec les bonnes personnes au bon moment. C’est un peu idéaliste quand je te le dis comme ça. Mais la différence que je fais avec du Scrum, c’est que Scrum va te déterminer qui prend les décisions. quand elles vont être prises et espérons sur la bonne chose. Je caricature, mais c’est juste pour faire la différence. Parce que du coup, quand tu fais des sprints, la manière dont tes événements sont organisés, tu sais qu’il y en a au début, il y en a qui sont pendant, il y en a qui sont à la fin. Et typiquement, tu en arrives à avoir ce genre de questionnement, de te dire, ok, mais il y a un truc qui m’irrite dans la manière dont on fonctionne, je vais attendre l’arrêt trop. C’est des fois le plus grand de trucs qu’on peut avoir. Ce qui n’est pas dit, encore une fois. C’est juste que les gens peuvent avoir l’habitude de penser, mais la structure même amène à ce genre de réflexion-là. En cambant, on ne réfléchit pas comme ça. En cambant, il y a cette logique de, est-ce que c’est le bon moment ? De par les règles du système que l’on a mis en œuvre, qui grosso modo sont stop starting, start finishing, et tout ce qui peut être un bloqueur sur ce chemin-là. mérite d’être levée d’accord ce qui veut pas dire que les gens le font mais c’est la logique c’est vraiment que c’est en continu on essaye de faire que ton autoroute soit la plus fluide possible c’est vraiment en fait c’est ce qu’on fait déjà sans.

Khamphon Inthavong  09:40

– Savoir toi par exemple dans mon équipe je leur dis toujours on le disait la fois avec anders il faut pas attendre le délimiting faut pas attendre la rétrospective si il y a quelque chose qui nous bloque etc faut tout de suite communiquer et c’est que moi dans les délimiting je demande toujours à l’équipe est ce que vous avez des bloquants est ce qu’il est des choses qui me bloque et c’est de de voir ensemble dans la journée de communiquer ensemble pour travailler ensemble et de faire avancer les choses exactement donc Si on caricature, comme tu dis, c’est avec les gens attendre le daily meeting, les rétrospectives pour se parler. Mais nous, dans notre quotidien, on sait qu’il ne faut pas attendre ces événements-là, mais qu’il faut se communiquer au fur et à mesure. Donc c’est ce que Kanban propose, en fait, de ce que j’entends.

Olivier My  10:24

– En tout cas, c’est ce qui est amené de manière, je pense, plus naturelle. C’est juste que quand tu commences à avoir des événements, ce que Scrum a amené et qui, en fait, est plutôt positif, c’est quoi le strict minimum qu’on considère être nécessaire pour qu’une équipe fonctionne correctement ? Et donc en fait, les événements aujourd’hui dans beaucoup d’entreprises sont considérés comme étant le cadre qu’il faut respecter de cette manière-là. Alors que pour moi, quand Scrum a amené ça, c’est au pire des cas, c’est ça qu’il faut faire. Tu vois ce que je veux dire ? C’est-à-dire que si par exemple, les gens n’ont pas l’habitude de se parler, en gros, on va leur dire que c’est bien de faire une revue, j’en sais rien, toutes les deux semaines. Donc au pire des cas, vous parlez toutes les deux semaines. Mais en vrai, ce qu’on voudrait, c’est que vous parliez tous les jours. Tu vois ce que je veux dire ? Et par souci, on va dire, de facilité, on va caler ces trucs dans les agendas, parce qu’on va être content que ce soit calé dans les agendas. Parce que tout le monde fait toujours plein de trucs, parce qu’on est toujours dans l’autoroute qui est blindée, en fait, on essaie de le caler en avance. Mais en vrai, en faisant ça, on peut aussi générer beaucoup de déchets. Donc du coup, il y a ce juste milieu à trouver entre qu’est-ce qui est la bonne chose à faire au bon moment, Quelles sont les règles de ton système qui te permettent de prendre les bonnes décisions au bon moment et de réunir les bonnes personnes pour prendre des décisions ? C’est ça qu’on cherche à faire.

Benoit Bourcier  11:45

– Ok, je comprends. Mais est-ce que ça veut dire que toutes les équipes pourraient faire du Kanban ? De ce que j’en comprends.

Olivier My  11:52

– Tout à fait. Pour moi, la beauté de Kanban par rapport à du Scrum, c’est que pour moi, Scrum n’est pas adapté de partout ou en tout cas génère énormément de contraintes qu’on a tendance à tordre d’une manière ou d’une autre. Typiquement un exemple, et encore une fois c’est ma vision, elle peut être erronée mais c’est basé simplement sur mon expérience et ma vision des choses, c’est typiquement Scrum part du principe que tu as un product backlog qui est priorisé, ordonné, etc. Mais ça veut dire que tu peux planifier la chose. Donc tu as une liste de trucs et après voilà, il y a le long cours qui arrive. Mais ça veut dire que tu peux planifier les choses. Et donc, après, tu fais ton sprint, tu fais tes trucs, etc. Et comment font les gens qui ont des éléments qui ne sont pas prévus, qui débarquent ? Ils s’allouent un temps, ils s’allouent un espace dans leur planification. La question qui se pose, c’est comment est-ce que tu alloues ce truc-là ? Je ne sais pas, tu dis 30%, mais pourquoi 30%, pourquoi pas 40%, pourquoi pas quelque chose ? En fait, tu sens que c’est un truc qui est fait parce que tu veux contourner une règle. Je le dis comme ça, mais c’est juste pour comprendre la logique de poser des trucs comme ça, parce qu’on se rend bien compte qu’il y a quelque chose qui est quand même compliqué à faire, au sens natif du terme.

Benoit Bourcier  13:15

– Tu enlèves un bon point, c’est ça. Je fais le parallèle, mais c’est ce qu’on vit nous dans mon équipe. En tout cas, cette notion de support qu’on va devoir apporter, on avait au début cette règle des 30%, et on essaye de… de la transformer, on n’a plus 30% exactement. On se garde un petit buffer, mais qui n’est pas vraiment quantifié. On sait qu’on a un petit peu de marge par rapport à tout ce qu’on a fait avant. On prend une moyenne de notre vélocité et on la baisse un petit peu sur notre planification. Donc effectivement, ça revient à ça. Mais on n’a pas de règles définies et c’est impossible à définir.

Khamphon Inthavong  13:49

– Toi, les 30%, qu’est-ce qui les a définis, toi, ton côté ?

Benoit Bourcier  13:52

– Les 30%, historiquement, quand je suis arrivé, c’était déjà en place. Et on s’est rendu compte que par moment, on utilisait 60%, d’autres moments que 10%. Donc en fait, comme dit Olivier, c’est vrai que c’est une règle qui a été mise en place, mais elle est ingérable. C’est quelque chose qui est…

Khamphon Inthavong  14:08

– Et toi, en tant que product owner, tu as un backlog pour le sprint. Si tu as des choses qui arrivent comme ça en plus ?

Benoit Bourcier  14:15

– Je fonctionne en safe. Alors, c’est encore plus différent. Mais globalement, sur un sprint, si j’ai des imprévus qui arrivent, je sais que j’ai un buffer dedans dans mon sprint. qui me permet de prendre ça en compte. Et si jamais ce n’est vraiment pas possible, on rediscute. On revoit avec l’équipe comment on peut fonctionner, on revoit l’objectif, etc. Mais ça nous fait encore plus de travail ou de cérémonie. C’est peut-être la réponse qu’apporte Camban au final, quand on y regarde, c’est qu’on communique pendant le sprint, on n’attend pas tous les événements. Donc on fait plus de Camban pour le savoir.

Olivier My  14:48

– En tout cas, il y a un élément supplémentaire que je trouve être spécifique, en tout cas dans la manière dont je vois le Camban. c’est que notre focale n’est pas la même. Ça veut dire que, encore une fois, les spécialistes de Scrum diront le contraire, mais en tout cas, c’est moi ce que je vois vraiment qui diffère, c’est que dans Scrum, le cadre fait qu’on se focalise sur les gens. Ce qu’on leur donne dans le cadre, c’est comment vous, vous allez vous organiser. C’est-à-dire qu’on dit, vous allez faire un événement qui fera ça, un événement qui fera ça, toi tu auras tel titre, toi tu auras tel titre, et puis il faudra que vous sortiez ce truc de cette manière-là. Ok, incrément de valeur, etc. Alors que dans Kanban, encore une fois, je fais des gros morceaux, mais c’est juste pour comprendre un peu les différences. Dans Kanban, en fait, tu ne gères pas les gens, tu gères le travail. Donc dans… ton histoire, tu vois, ça devient problématique de ne pas sortir un truc parce que c’est une notion de temps et d’organisation des gens. Alors qu’en campement, ce sera mais est-ce que ce truc-là, c’est le plus important ? Si oui, fais juste ce truc-là, mais tu ne feras pas autre chose.

Benoit Bourcier  15:53

– Vous mettez de la priorisation par rapport aux ressources que vous avez. Vous priorisez en fait, vous refaites vos priorités. On fonctionne en permanence.

Olivier My  16:04

– Oui, c’est ça. C’est aussi pour ça. que ça fait que même si les gens peuvent avoir tendance à penser le contraire, que la taille des éléments n’est pas si importante au début. On a toujours l’impression quand on fait du camp-vent qu’il faut que tous les éléments soient de la même taille, etc. C’est toujours mieux, mais ça ne veut pas dire que ça fonctionne comme ça. Ce que tu veux en réflexion, si tu gères le travail, c’est que tu fais ton mieux pour le découper, mais si c’est le truc le plus important, autant se focaliser dessus. Tu vois ce que je veux dire ? Il n’y a pas cette contrainte. Tu vas te dire … Ok, je n’ai pas réussi à le sortir en deux semaines parce que mon sprint c’était deux semaines, etc. Donc il y a moins ce côté culpabilisant de ne pas répondre à la règle. Parce que derrière, il y a une vraie vision de c’est quoi qui a de la valeur aujourd’hui pour nous, maintenant. Et donc c’est ça qu’il faut qu’on traite.

Khamphon Inthavong  16:56

– Juste pour reprendre la différence, en fait, en Scrum, on va travailler en sprint, donc avec une timebox de deux, trois semaines par exemple. Donc, on va essayer de sortir quelque chose dans 2-3 semaines, l’incrément qui apporte de la valeur, etc. Encore qu’en banque, tu n’as pas cette notion de time box, tu as plus cette notion de, il faut apporter de la valeur, prioriser le plus possible. Et donc, si ça sort dans 1, 2 ou 3 jours ou dans 2 semaines, ça sortira dans 1, 2, 3 jours ou dans 2 semaines, c’est ça ?

Olivier My  17:23

– Alors, oui et non. C’est là où je vais rentrer un peu dans des petits éléments de détail qui sont importants. Le fond de la chose, ce que l’on veut, c’est que quand je commence quelque chose, je le termine le plus vite. Déjà, la base initiale, c’est qu’on va réfléchir à l’élément de valeur individuel plutôt que par l’eau d’éléments de valeur. Déjà, c’est une différence. La deuxième chose, c’est qu’il y a une pratique dans Kanban qui fait un peu flou et vague, mais qui répond justement à cette notion de temps. qui est la cinquième, il me semble, qui est implémenter des boucles de feedback. En fait, ce qu’on met derrière implémenter des boucles de feedback, c’est justement cette capacité à revoir quelque chose. D’accord, nourrir en arrière un feedback, c’est ça l’idée. Et donc, du coup, c’est comme ça que tu vas créer en comment ce qu’on appelle des cadences.

Khamphon Inthavong  18:22

– D’accord.

Olivier My  18:23

– On n’appelle pas ça des sprints, on appelle ça des cadences. Mais il y a quand même bien une notion de temps qu’on va injecter. C’est juste que la différence que tu as en Scrum qui simplifie la chose, c’est que tout est couplé. Quand tu fais un sprint, tu sais qu’au début tu as ton planning, à la fin tu as ta rétro, ta revue, etc. C’est toujours la même temporalité. Alors qu’en Kanban, tu vas te donner la liberté de par les besoins et la vie de ton équipe, de te dire, ça se trouve, je préfère faire un weekly planning, qu’on va appeler replenishment plutôt, réapprovisionnement en Kanban. Et te dire, tiens, je vais faire une rétrospective, par exemple, d’équipe, toutes les trois ou toutes les quatre semaines, parce que la manière dont on fait les choses aujourd’hui font que c’est suffisant. Donc, tu as bien cette boucle de feedback et cette notion de temps derrière. C’est juste que, encore une fois, c’est une décision à prendre dans les équipes de par leurs propres besoins. Et quand je vous dis ça, c’est comme ça que moi, je considère faire du Scrum dans du Kanban. C’est que ma logique globale est du Kanban. et je réutilise potentiellement des événements Scrum dans mes boucles de feedback, mais qui sont découplées. C’est ça qui fait la différence. Lorsque tu fais du Scrum et que dedans tu fais du Kanban, ça veut dire que tu es contraint par le rythme Scrum et tu utilises les pratiques Kanban à l’intérieur.

Khamphon Inthavong  19:48

– C’est ce que nous on fait.

Olivier My  19:48

– C’est ce que la plupart des gens font.

Khamphon Inthavong  19:50

– C’est intéressant ce que tu dis, parce que j’ai été appelé pour coacher une équipe qui… qui, chez mon client actuel, une autre équipe qui est un peu plus opérationnelle. Et quand je suis arrivé, normalement, toutes les équipes de l’organisation doivent travailler en Scrum. Et quand ils m’ont montré comment ils travaillaient, quel type de ticket ils travaillaient, je leur ai dit non, on ne peut pas travailler en Scrum, il faut qu’on travaille en Kanban. Donc j’ai fait exactement comme tu as dit, on a un board Kanban, ils délivrent au fur et à mesure en fonction de leurs priorités, et par contre, toutes les trois semaines, calées sur les sprints de l’organisation, ils font une rétrospective. Mais ils n’attendent pas la rétrospective ou la revue pour délivrer. Ils délivrent tout au long des semaines. Par contre, on garde toutes les trois semaines une rétrospective pour faire du feedback.

Olivier My  20:41

– Mais du coup, tu parles de revue ou de rétrospective ? Rétrospective.

Khamphon Inthavong  20:45

– Ok, rétrospective. Oui, exact.

Olivier My  20:47

– Ça veut dire, si tu dis rétrospective, ce que tu dis, ils n’attendent pas pour se faire du feedback, mais c’est du coup sur leur process.

Khamphon Inthavong  20:52

– C’est ça.

Olivier My  20:53

– D’accord, parce que tu parlais de délivrer, alors du coup, c’est pour ça que j’ai mélangé.

Khamphon Inthavong  20:56

– Ils peuvent délivrer, en fait, c’est des tickets qu’ils doivent produire pour le client. Par exemple, ils doivent monter des plateformes, ils doivent créer un SharePoint, etc. Donc ça, ils le font au fur et à mesure. Alors que normalement, en Scrum, tu fais un lot d’incréments, tu le livres à la fin, tu sais. Là, en fait, tu le livres au fur et à mesure, c’est ça que je veux dire.

Olivier My  21:18

– Alors en vrai, tu pourrais le livrer pendant, mais en tout cas, effectivement, la plupart des gens le feront. Oui.

Khamphon Inthavong  21:23

– Tu pourrais le livrer pendant, c’est vrai.

Olivier My  21:24

– Il y a une notion que je trouve intéressante, que je trouve plus marquée quand j’y réfléchis pendant, parce que je n’avais jamais réfléchi à la question comme ça. Mais un élément qui est important, c’est… ce qu’on met derrière les SLA et les SLE. Donc, avant, SLA, c’est Service Level Agreement. SLE, Service Level Expectations. Et en fait, l’intérêt de ces éléments-là, moi, je l’ai assez rarement vu dans les équipes que j’accompagne, mais ce n’est pas ça qui est grave. La notion est intéressante. C’est que la première chose à se poser, c’est, en fait, c’est quoi ton contrat avec ton client ? Parce que quand tu fais du Scrum, tu as une sorte de contrat. implicite, qui est, toutes les deux semaines, tu vas me sortir un truc. Qui est un petit peu, d’ailleurs, imposé aux équipes, et on ne sait même pas si ton client, il est en mesure de réceptionner autant de choses, dans le rythme que vous avez. Alors qu’en grand, il y a cette réflexion de se dire, ok, en fait, qu’est-ce que nous, on a en capacité de faire ? Qu’est-ce que le client, il aimerait avoir ? en termes de delivery. Et du coup, quel est l’agreement, quel est le contrat qu’on se donne ? Le fait d’avoir cette réflexion flux, c’est-à-dire jusqu’au service rendu, je trouve que ça donne une conscience client qui est plus forte. Parce que ça rentre dans les notions qui sont mises en avant. Ça ne veut pas dire qu’en Scrum, on ne le fait pas, parce que normalement, tu fais bien un truc pour un client. Mais je trouve que cette notion de SLA, c’est un temps qui est déterminé normalement avec ton client. dans sa capacité à pouvoir réceptionner les choses, ce qui fait que c’est moins grave que tu te focalises toi sur un élément sans avoir des sprints qui s’enchaînent. Parce que normalement, la question qui se pose, en tout cas moi c’est la question que je pose souvent aux équipes quand j’arrive, au-delà de « est-ce que c’est du Scrum, du Kanban ? » c’est « est-ce qu’aujourd’hui, la manière dont vous fonctionnez dans votre quotidien, est-ce que vous répondez à vos objectifs et donc à vos clients ? » Si on me dit oui, pourquoi changer ? Moi, c’est la première question que je pose. Si aujourd’hui, les gens sont satisfaits de partout, pourquoi changer ? S’il y a une insatisfaction qui commence à arriver ou une envie de progresser parce qu’on peut faire mieux qui est interne, alors là, on peut discuter. Mais moi, je n’ai pas cette vocation, même si quand même pour moi, c’est souvent le choix, non seulement le plus facile, je trouve le plus efficace à l’heure actuelle. Je ne vais pas leur imposer ça. Mais d’ailleurs, ça, c’est un exemple que je peux vous donner, que je trouve marrant. C’est une équipe qui m’appelle, on fait un atelier, et elle me dit, voilà, je veux passer de Scrum à Camban. D’accord ? Donc, typiquement, il y a beaucoup d’équipes qui font ça.

Speaker 3  24:15

– Ouais.

Olivier My  24:16

– Et donc, moi, la première question que je leur pose, c’est ce que je vous dis. Je dis, en fait, est-ce que vous avez une insatisfaction particulière ? Donc, je commence par insatisfaction externe. Est-ce que les clients à qui vous livrez ça, qui sont des clients internes ou externes, peu importe, Il y a une insatisfaction. Ils me disent non. Ok. Du coup, pourquoi vous voulez changer ? Et ils me disent, en fait, là, on est dans une période où on n’arrive pas à trouver d’objectif de sprint. Parce que c’est une période creuse, qui est entre des sprints de build, des choses comme ça. Et du coup, ils se sentent tellement coupables qu’ils se disent, il faut qu’on fasse autrement. Ah oui.

Speaker 4  24:54

– Ok.

Olivier My  24:56

– C’est le seul cas que j’ai eu, mais qui… montre bien ce qui peut se passer dans des gens qui sont de très bonne volonté c’est qu’en fait le cadre scrum tel qu’il est il peut être culpabilisant Et même dans la manière dont des fois on accompagne, et un Scrum Master, si on regarde bien, il doit être garant du cadre. Donc il y a un côté, tu fais bien du Scrum ou tu ne fais pas bien du Scrum, et il y a ce côté un peu culpabilisant qui arrive. Et qu’en bon, c’était une voie pour leur permettre de se libérer l’esprit. Donc on est allé dans cette direction-là, pas pour ces raisons-là, moi j’ai juste voulu cibler le fait que vous n’avez pas de raison véritable au sens délivré, mais c’est plus… une manière d’explorer autre chose. Donc, en fait, on allait dans cette direction d’apprentissage. Mais c’est de comprendre que, tu vois, des fois, Scrum peut avoir ces impacts-là. En tout cas, après, c’est un exemple que moi, j’ai eu. Forcément, plein d’autres exemples. Mais je trouve que c’est intéressant de voir cette vision-là toujours orientée. Mais en fait, c’est pour qui que tu fais ça ? Et est-ce qu’aujourd’hui, c’est acceptable ? Si ce n’est pas acceptable, du coup, autant essayer autre chose. Sinon, plus de la même chose amène toujours plus de mêmes résultats.

Benoit Bourcier  26:04

– Ça se comprend.

Khamphon Inthavong  26:04

– Ok.

Benoit Bourcier  26:05

– Et en termes de vision, parce que je me posais la question, puis on y revient un tout petit peu là en termes de délurie, puis le fait qu’ils n’aient pas d’objectif, comment c’est accepté par les personnes au-dessus ? Vous on fonctionne en safe, tu veux ? Et on sait sur trois mois, les personnes business, en fait, ceux qui financent nos projets, ont une vision sur trois mois, ils savent où on va aller, etc. Comment c’est accepté ça qu’en banque vis-à-vis des autres ? Parce que j’imagine que… on a moins une vision sur le long terme. Scrum, toutes les deux semaines, on sait qu’on va livrer. Kanban, on sait est-ce qu’on va livrer dans une semaine, est-ce qu’on va livrer dans un mois ? On a un peu ce flou-là. Et comment c’est accepté ? Comment la vision est transmise, en fait, à ce niveau-là ?

Olivier My  26:50

– Pour moi, il y a deux aspects dans ta question, et des choses que je ne mets pas, d’ailleurs, en corrélation. La première, c’est la vision, c’est-à-dire est-ce que je sais que je fais la bonne chose ? C’est ça que j’entends quand tu parles de vision. Je ne sais pas si tu parles de visibilité du coup.

Benoit Bourcier  27:07

– De visibilité du coup, effectivement.

Olivier My  27:09

– Parce que du coup, pour moi, au niveau vision, ça ne change rien. Tu peux très bien avoir un backlog avec une story map qui est bien claire et une roadmap, peu importe ce que tu veux, que ce soit l’un ou l’autre, peu importe. Par contre, en termes de visibilité, ce qui est intéressant, c’est que Scrum te donne une impression que tu auras quelque chose en deux semaines. Mais c’est un peu. D’accord ? On est d’accord sur ça ? Et combien d’équipes, grosso modo, n’atteignent pas leurs objectifs et font déborder leurs trucs sur le sprint d’après. On en connaît tous. Et c’est OK. Pour moi, il y a déjà un premier aspect, c’est que oui, tu crois que toutes les deux semaines, tu auras des trucs. C’est un aspect. Encore un moment, on ne va pas réfléchir exactement de la même manière parce que du coup, ce que tu vas remettre, si je peux dire, en Scrum, c’est un incrément qui répond à un objectif, bien évidemment. En commandant, tu vas promettre, si je puis dire, un temps de délivrer d’un élément de travail. Par exemple, si en Scrum, tu délivres 10 éléments de travail toutes les deux semaines, ton objectif va être un condensé de ce que ces 10 sont censés apporter. C’est ça que tu vas faire en Scrum quand tu vas prévoir. En commandant, tu vas dire, moi, chaque élément de travail, je les sors en temps de temps. Donc du coup… Par rapport à un client, si tu as bien découpé tes choses, chaque élément est quelque chose qui a de la valeur pour ton client, de manière indépendante, etc. Du coup, selon la place qu’il a dans l’ordre, tu peux savoir quand est-ce qu’il va sortir. C’est une autre manière, si tu veux, de planifier, mais qui a beaucoup d’intérêt dans le sens où elle est basée sur du temps réel, et donc du délai, et non pas de la charge. Et ça, pour moi, c’est vraiment ce qui fait la différence. Parce que, encore une fois, moi, ce que je dis souvent, je dérive un peu du Camban mais pour moi, c’est vraiment au cœur de Camban c’est l’illusion de la charge pour planifier. Et je ne parle pas des story points et de tout ça.

Khamphon Inthavong  29:18

– Quand tu parles de charge, c’est la capacité de travail que peut faire une personne.

Olivier My  29:24

– Oui, c’est ça. C’est le temps que moi, je pense pouvoir passer sur un élément de travail pour qu’il sorte. ou une équipe. Pourquoi je parle de ça ? Parce que je vais reprendre les deux images. Vous avez l’autoroute qui est fluide et vous avez l’autoroute qui est embouteillée. Ce qui est intéressant. Moi, c’est quelque chose que j’ai appris il n’y a pas si longtemps que ça, mais j’aime bien l’image. L’autoroute où vous êtes seul, il y a une corrélation très forte entre votre vitesse personnelle et votre temps d’arrivée, parce que vous êtes seul sur l’autoroute. Donc si tu conduis à 100 km heure ou tu conduis à 130 km heure, forcément tu iras plus vite à 130. Ça va jusque là ?

Benoit Bourcier  30:05

– Exact.

Olivier My  30:06

– Alors que dans une autoroute qui est embouteillée… Ce qui est intéressant, c’est que le facteur qui va avoir le plus d’impact sur ton temps d’arrivée, ce n’est pas ta vitesse à toi, c’est le temps d’attente qu’il va y avoir dans le système.

Speaker 3  30:19

– Exactement.

Olivier My  30:21

– Et donc, ce qui est intéressant, c’est que souvent, on va essayer de mesurer, ou en tout cas d’estimer très précisément une charge qui a en fait très peu d’impact sur le temps de délivrer. C’est juste que vu qu’on va faire toujours la même chose. On va juste être continuellement faux, mais vu qu’on fait continuellement la même chose, on arrive en fait à gérer les écarts. D’accord ?

Khamphon Inthavong  30:42

– Ok, oui.

Olivier My  30:43

– D’accord ? Mais en fait, ce qui est intéressant, quand tu commences à gérer non plus la charge, mais les délais, ce qu’on cherche à faire en comment, d’accord ? Quand est-ce qu’il est rentré, quand est-ce qu’il est sorti, quand est-ce qu’il a été mis dans les mains du client ? Déjà, c’est beaucoup plus facile à communiquer avec un client, parce que lui, il veut savoir quand est-ce qu’il l’aura. donc tu ne vas pas lui dire par exemple Il sortira peut-être dans deux sprints, sachant que tes sprints, c’est plus ou moins quelque chose, etc. Tu peux lui dire, ça sortira dans tant de temps, avec un pourcentage de confiance que tu peux déterminer. Ça, c’est un aspect. Mais le deuxième aspect, c’est qu’en mesurant le temps du délai, tu prends en compte aussi tout le système tel qu’il est. C’est-à-dire, toutes les étapes par lesquelles ton travail va passer. mais également tous les temps d’attente qu’il y a eu au milieu. Tu sais, ce fameux truc où, en gros, c’était urgent, mais genre urgent, urgent, tu vois, on t’a appelé, c’était le feu, etc. Toi, tu te démerdes dans ton équipe pour sortir le truc, et après, quand tu l’envoies chez ton client, pas de son, pas d’image pendant trois mois.

Benoit Bourcier  31:51

– Oui, c’était pas si urgent.

Olivier My  31:53

– Tu vois, c’était pas si urgent, et après, on te tape dessus parce que tu sors jamais les trucs à l’heure. En fait, quand tu mesures le délai, tu arrives en fait à aussi voir… entre le moment où c’est rentré et c’est sorti, il y a tant de temps qui est passé chez vous, il y a tant de temps qui est passé chez les autres, et ça te permet d’avoir une conversation, encore une fois, c’est pas là pour pointer du doigt, mais si tu ne regardes que la charge, ça ne marche pas, parce que c’est pas représentatif. Il y a beaucoup d’éléments, aujourd’hui, on le voit dans les entreprises, statistiquement parlant, c’est ce qu’on avait dans les formations Camban de David Anderson, je trouve ça intéressant d’avoir cette notion-là, c’est qu’un élément de travail, en fait, d’une boîte qui n’a pas optimisé son flux. On parle d’efficience. Je pose juste ce terme-là. L’efficience d’un flux, c’est le rapport entre le temps où je passe effectivement à travailler sur quelque chose, sur le temps total. Donc c’est un pourcentage. Vous ce qu’on voudrait, c’est avoir du 100%. Dans l’idéal, on voudrait avoir 100%. Toch, c’est fluide. Parce qu’il faut savoir quand tu commences à étudier souvent ton système et que ça n’a pas été optimisé, donc un état initial, l’efficience est à un chiffre. Et donc quand on dit qu’une efficience est à un chiffre, et c’est intéressant d’avoir cette notion-là, c’est de se dire que souvent un élément de travail passe plus de 90% de son temps à attendre quelque part. Et ça c’est intéressant parce que du coup, vous pouvez écouter ça dans les conversations des gens, en daily par exemple. Combien de fois… Vous entendez le terme « j’attends » ? Quelque chose de quelque part dans vos délits. Et en fait, ça revient très souvent. Et ce qu’on cherche à faire en camp-vent au départ, plutôt que d’accélérer en travaillant sur la charge et en poussant chez les gens, c’est qu’on travaille sur les temps d’attente. Parce qu’attendre en camp-vent, ce n’est pas acceptable. Donc en fait, c’est toute cette dynamique-là qui est intéressante parce que tu vas décaler certaines prises de décision. pour aller vers plus d’efficacité et d’efficience opérationnelle.

Khamphon Inthavong  34:00

– C’est un peu comme tu disais, quand tu parles de charge et de travail, la charge c’est plus au niveau humain, et le délai c’est plus au niveau travail. C’est le travail que tu essaies de gérer.

Olivier My  34:15

– Effectivement. C’est pour ça qu’on va regarder le travail, on s’en fout de combien de temps la personne a passé dessus, ce qu’on veut c’est de voir comment le travail se balade. C’est pour ça que… Le fait de dire qu’en bon, c’est un tableau sur lequel il se balade des trucs avec des colonnes, en fait, c’est le cas. C’est juste que moi, tu vois, il y avait une histoire qu’on m’avait racontée dans le passé, que je trouve intéressante. Alors, je te l’ai dit, enfin, je vous l’ai dit comme ça, je ne suis pas très bon pour raconter des histoires, mais je crois que c’est l’histoire d’un Américain qui va voir quelqu’un dans les usines Toyota, parce que bon, ça vient de par là-bas, et en fait, les usines Toyota lui ouvrent la voie. Il dit, viens voir, c’est à l’époque où Toyota devenait leader, et puis suite à la guerre, les Américain se sont dit, c’est bizarre quand même, comment est-ce qu’ils ont fait pour devenir au-dessus de nous alors qu’ils étaient en-dessous de nous il y a quelques dizaines d’années ? Et donc il y a les gens, ils se disent mais c’est quand même bizarre, vous êtes des concurrents et ils vous ouvrent la porte, comme ça, pour vous montrer comment ils travaillent, etc. Et en fait, les employés de Toyota ont répondu à cette réponse-là en disant, mais en fait, ce que tu vois n’est que le résultat de notre pensée, mais pas notre pensée. Je ne sais pas si c’est clair quand je vous dis ça. Et je trouve ce qui était intéressant, c’est ça, c’est qu’en fait… Kanban aujourd’hui est vu de par le résultat qui est visible. Le résultat qui est visible, c’est simplement le tableau, avec des trucs qui se baladent dessus. Mais la pensée qu’il y a derrière Kanban, c’est comment est-ce que j’ai réussi à avoir déclenché des bonnes conversations avec les bonnes personnes pour prendre des décisions au bon moment. C’est ça la subtilité, en fait, je trouve, de cette démarche-là. Et moi, cette histoire m’a… pas mal inspiré dans ce sens-là, pour bien comprendre qu’en fait, quand on pense, c’est quelque chose qui est un peu plus large dans la manière de voir les choses. Tu essaies de toucher à des trucs qui sont finalement émotionnellement assez difficiles. Typiquement, c’est la capacité à dire non. Quand tu fais ça tout le temps, et comment est-ce que tu retardes le démarrage d’un élément pour plutôt en terminer un autre ? C’est émotionnel.

Khamphon Inthavong  36:36

– Tu dis non parce que… Il faut d’abord que tu termines ta tâche avant de prendre une nouvelle tâche.

Olivier My  36:41

– En fait, c’est un nom conditionnel qui, de par les règles de ton système, qui sont des règles d’efficience d’ensemble, vont te permettre d’avoir une conversation avec des gens. Ce n’est pas un nom, je n’aime pas ta gueule, tu vois. C’est un nom conditionné par rapport à une efficacité ou une efficience d’ensemble d’un système. Parce que, grosso modo, comment ça se passe dans beaucoup d’entreprises, c’est que tu as une équipe, ce que je mets derrière système de production, tu vois. tu as une équipe qui a potentiellement plusieurs clients, mais ces clients, ils ne se voient pas. Du coup, quand moi je viens et que je te dis tu pourrais me faire ce petit truc-là, et l’équipe va poser son crayon à faire ce truc-là, tu ne te rends pas compte que derrière, ça impacte tous les autres trucs qui étaient déjà en cours. Et pendant que client, je ne vois que mon truc à moi qui m’intéresse. Et donc en fait, quand tu crées des règles de système, ça te permet en fait, dès l’entrée de ton système, de mettre une pancarte et de dire attention, vous avez aussi une responsabilité. est-ce que ton truc, il vaut la peine que je ralentisse tous les éléments qui sont déjà en cours ? Est-ce que tu es prêt à prendre ces responsabilités ou pas ? Et donc c’est tous ces éléments de règles du système, je trouve, qui sont extrêmement intéressantes dans Kanban.

Khamphon Inthavong  37:51

– Ok, ok.

Benoit Bourcier  37:53

– Et pour être certain d’avoir bien compris, je comprends le fonctionnement de Kanban beaucoup mieux. Est-ce qu’on a des rôles associés ? Parce qu’au début, je crois que tu as dit qu’il n’y avait pas vraiment de rôle et que l’équipe était assez autonome là-dedans. Et c’est toi qui…

Olivier My  38:06

– Je n’ai rien dit. J’ai juste dit que dans Scrum, c’était le cas.

Benoit Bourcier  38:10

– C’est ça. Mais du coup, si tu as dit que dans Scrum, c’était le cas, qu’est-ce qu’on retrouve dans Camban ??

Olivier My  38:18

– C’est juste que je vais te dire oui et non, du coup. Parce qu’en fait, encore une fois, moi, je sépare la dimension, on va dire, de l’usage et de l’utilité d’une approche et la partie un peu business qu’il y a derrière. Parce qu’il faut la garder, ça pourrait être une autre conversation. entre David Anderson et puis ce qu’il y a autour. Je trouve ça vachement intéressant en termes d’évolution de l’approche. Mais au delà de ça, en fait, fut-ce un temps, il n’y avait pas de rôle. Parce que la base de Kanban, c’est tu pars de là où tu es. Donc, généralement, les gens travaillent d’une certaine manière. En tout cas, ils sont embauchés avec un titre de poste, donc tu pars avec ces trucs là. Et en vrai, on n’aurait pas tellement besoin. Ça veut dire que est-ce que tu as toutes les compétences pour aller au bout ? oui, essayons d’optimiser déjà ce que vous faites. Parce que, encore une fois, ce qu’on cherche à optimiser, c’est le flux de travail, ce n’est pas qui sont les gens. Ça, c’est un premier aspect. Mais avec l’usage, on s’est rendu compte que finalement, il y a des besoins qui émergeaient en termes de compétences pour le collectif. Grosso modo, il fallait donner des noms différents parce que business fait que je peux vendre des formations après sur ces rôles-là. C’est pour ça que je sépare les deux. Je ne dis pas que ça n’a pas de valeur, mais je dis juste qu’il y a cette dimension-là. Finalement, on se rend compte qu’il y a un besoin autour de la facilitation de l’équipe pour s’assurer que dès que j’accepte de délivrer un truc, ça se délivre le plus rapidement possible. Ce que tu pourrais associer, je caricature, mais à Scrum Master, c’est de l’efficacité. Mais en Camban, on appelle ça le service delivery manager.

Speaker 3  40:03

– Ok.

Olivier My  40:04

– Parce qu’en grand, on parle beaucoup de service. Et je trouve que c’est aussi intéressant que l’antille. Donc, service delivery manager. Et un autre rôle qui émerge, où on se dit, justement, si le service delivery manager, il est là pour s’assurer que tout se passe au mieux quand on a accepté une demande, il y a aussi un rôle qui est intéressant pour comment est-ce que j’affine une demande jusqu’au moment où elle sera acceptée. C’est un peu le gardien de la boîte. Tu ne rentres pas avec tes baskets. Oui. Et en fait, cette personne-là, on pourrait associer ça finalement à un rôle de product owner, si je puis dire. Et en fait, en Kanban, on va appeler ça service request manager. Tu gères en fait la requête. Donc non, au départ, il n’y a pas de rôle parce que ce n’est pas ça que tu veux changer en premier. Les dizaines d’années d’expérience ont montré que c’est des rôles qui émergent. Donc on parle plutôt de rôle émergent. Puis ce n’est juste pas qu’ils les ont structurés.

Khamphon Inthavong  40:59

– Il faut que tu gagnes des responsabilités, je pense. Du coup, tu es obligé de work comme des personnes qui sont responsables de choses. Ok, je vois le temps qui passe, il y a 46. Je crois qu’on pourrait encore parler, je ne sais pas combien de temps, mais je crois qu’on n’aura plus assez de place sur nos caméras si on continue.

Olivier My  41:19

– Vous m’avez lancé.

Khamphon Inthavong  41:21

– C’est super intéressant. On pourrait passer encore des heures à parler de commandes, mais là, on a déjà vu pas mal de choses.

Benoit Bourcier  41:28

– Moi, je suis content parce que je ne connaissais pas Kanban. Je connaissais le mot, je savais à quoi ressemblait un tableau Kanban mais je ne connaissais pas l’état d’esprit derrière, le fonctionnement, etc. Et j’en apprends beaucoup. Je pense qu’il faudrait qu’on se revoie quand même au Chili un moment pour aller creuser encore plus en détail. Moi, ce que je te propose.

Olivier My  41:49

– Juste avant que ça se termine, je vais te raconter l’histoire que je raconte quand j’explique comment ça marche comment. et à quoi ça peut correspondre. Et puis après, je vais aller plus loin. Donc, je devrais pouvoir réussir en 4 minutes, 5 minutes.

Khamphon Inthavong  42:05

– Allez.

Olivier My  42:07

– Quand bon, d’accord, il y a 6 pratiques. OK ? En fait, ce qui est intéressant dans ces 6 pratiques-là, c’est que je vais vous les décrire dans l’ordre. Pour vous expliquer, en fait, c’est quoi la logique ? En tout cas, moi, quand j’accompagne les équipes, c’est un peu la logique que j’essaie d’avoir. Il y a toujours un intérêt, on va dire, un problème auquel on veut répondre, et ensuite, il y a une pratique. Première pratique, c’est visualiser le flux. Pourquoi ? Parce que du coup, initialement, quand on ne voit pas, on ne peut pas maîtriser. Des fois, on a une impression qu’on fait beaucoup de choses, mais quand on le voit, on voit que c’est le bordel. Et donc, quand tu matérialises ton flux la première fois, tu as deux cas qui émergent. Soit tu as un système qui est globalement saturé, tu as des tickets partout, soit tu as de la chance et ça sature juste à un endroit. Donc, tu as pu identifier ça, mais au moins, tu commences à… pouvoir prendre des décisions ensemble et gérer ton quotidien. Sauf que tu te rends compte qu’il y a un problème d’équilibre entre ta capacité à faire et la demande. Et donc, ce que tu veux faire, c’est justement rééquilibrer cette charge-là, globale. Et donc, pour rééquilibrer la charge globale, qu’est-ce qu’on fait ? On met des limites. Donc, deuxième pratique qu’on vend, limiter le travail en cours. C’est ce qui va nous permettre de rééquilibrer notre capacité à faire avec la demande entrante. C’est exactement ce qu’on fait quand il y a des soldes et que du coup tu bloques à l’entrée les gens. Parce que du coup tu bloques à l’entrée pour que quand la personne elle rentre, elle soit en fait la plus fluide possible à l’intérieur et qu’elle ressorte. Limiter le travail en cours c’est fait pour ça. Donc je vois mon travail, j’ai cette sensation, c’est fluide, donc je ne me sens plus inondé à faire des trucs, je vois des trucs qui commencent à sortir. Ce qui pourrait être intéressant maintenant, c’est de mettre un peu des chiffres dessus. Et donc, troisième pratique, gérer le flux. Gérer le flux, c’est d’avoir cette capacité à mieux appréhender les entrants, les sortants, et combien d’éléments j’ai à l’intérieur. Donc je commence à mettre des chiffres. Ce qui fait que là, je deviens beaucoup plus solide dans ma manière de faire les choses, parce que j’ai une sensation où je maîtrise les choses, je peux le voir. J’ai des limites qui me permettent de me sentir beaucoup plus fluide et de ne pas être surchargé. Et en plus, j’ai des chiffres à l’appui. à la pluie, donc à la pluie même.

Speaker 4  44:26

– Parce que la pluie.

Olivier My  44:29

– C’est pas trop en ce moment, et ça me permet d’avoir des conversations avec l’extérieur, parce que là, effectivement, comme on a discuté tout à l’heure, je peux leur expliquer, nous, nos éléments, ils sortent en temps de temps, on peut sortir tant d’éléments dans cette période de temps, et avec tel pourcentage de confiance. Vu que j’ai tout ça, c’est intéressant, mais ce que je vais vouloir faire, c’est absolument de rendre explicite ses règles. D’accord ? Je visualise, je limite, j’ai des chiffres et j’ai des noms de mesure. On va rendre explicite ces règles-là. Parce que si ce n’est pas explicite, il y a un risque que un degré de différence dans ma compréhension de la chose puisse amener à des décisions qui ne soient pas les bonnes. Donc, on va les écrire. Rendre explicite, c’est ça, je vais écrire. Parce que quand c’est écrit, on va le lire ensemble et on va pouvoir être d’accord. Parce que combien d’équipes on va voir et on va leur demander « Vous fonctionnez comment ? » Est-ce que vous savez comment vous fonctionnez ? Tout le monde dit oui. Et puis dès que tu commences à le faire, tu vois qu’il y a des divergences qui sont monstrueuses. Rendre explicite, c’est une manière de t’assurer que tout le monde a la même compréhension. C’est une manière de standardiser, si je puis dire. Donc du coup, on voit les choses, on limite. On a des éléments de mesure, donc on l’a écrit. Ce qui facilite aussi le travail de downboarding, le cas échéant. Sauf que ce qui va se poser comme question, c’est est-ce que dans la durée, Les règles que l’on a mises en œuvre, donc de visualisation, de limites et de mesures, elles vont tenir parce que les éléments de travail vont arriver, ils vont peut-être changer, les objectifs vont peut-être changer, mais est-ce que ça, ça tient ? Dans la durée, comment est-ce qu’on fait pour s’assurer que quelque chose est toujours à jour ou utile dans la durée ? On implémente des boucles de feedback. Et donc, les boucles de feedback qu’on peut mettre en œuvre, on peut mettre une boucle de feedback sur le plan, on peut mettre une boucle de feedback sur la synchronisation, sur comment est-ce que ça se déroule dans une période de temps. On peut mettre une boucle de feedback sur les résultats que l’on obtient et on peut mettre une boucle de feedback sur notre processus. Et là, tu as récupéré les quatre boucles de feedback que les événements Scrum te proposent. Et la dernière pratique, c’est parce que tu commences à avoir une vision d’ensemble, tu vas améliorer collaborativement, c’est-à-dire que tu ne prends pas de décision seul, tu prends des décisions avec le système qui t’entoure, et tu vas évoluer expérimentalement, c’est que tu vas mettre en œuvre des expérimentations. qui après validation, que ça répond bien à un problème réel, tu vas intégrer dans ta pratique et donc que tu vas mettre dans tes règles. Donc là, tu as les six pratiques, je crois que j’ai fait cinq minutes, mais qui te montrent, voilà ce qu’on cherche à faire quand tu fais du canvon, avec un niveau de profondeur qui évolue et qui répond toujours à un besoin.

Benoit Bourcier  47:11

– C’est clair.

Khamphon Inthavong  47:12

– Mais je pense que c’est quelque chose qu’on fait, en tout cas, c’est quelque chose que je fais naturellement dans les équipes sans vraiment savoir que… tu as tout l’esprit camban derrière, visualiser le flux, gérer le travail et tout ça.

Benoit Bourcier  47:26

– Tout fait partie de nous parce que SAFe nous cadre énormément.

Khamphon Inthavong  47:29

– Oui, on SAFe peut-être.

Benoit Bourcier  47:30

– Mais on y reconnaît quand même effectivement un petit peu.

Khamphon Inthavong  47:34

– Exact. Ok, je pense que ça conclut bien la session.

Benoit Bourcier  47:41

– Oui, pour une introduction à courant.

Khamphon Inthavong  47:44

– C’est déjà pas mal. En tout cas, merci beaucoup Olivier.

Benoit Bourcier  47:48

– Au plaisir.

Khamphon Inthavong  47:50

– On a appris pas mal de choses. Je pense que ça va servir aussi à pas mal de personnes pour faire la différence, pour comprendre comment. Et en tout cas, ce que je disais à Benoît au début de nos podcasts, si on arrive à inviter Olivier My à nos podcasts, on aura atteint un objectif. Donc là, on a atteint un premier objectif, c’est d’avoir une.

Olivier My  48:09

– Et franchement.

Khamphon Inthavong  48:11

– C’est toi qui nous fais l’honneur d’être là. Donc ça, c’est super sympa. Et merci beaucoup de t’être rendu disponible. En France, il est tard déjà, je pense.

Olivier My  48:20

– Il est 20h.

Khamphon Inthavong  48:21

– 20h. Vous on va commencer notre après-midi.

Benoit Bourcier  48:25

– Vous on va reprendre le boulot. On va te souhaiter un bon appétit.

Olivier My  48:27

– Merci bien. Au plaisir d’un vrai café.

Benoit Bourcier  48:30

– Dès que tu remontes à Montréal.

Khamphon Inthavong  48:35

– On fait ça.

Benoit Bourcier  48:36

– On croisera.

Olivier My  48:37

– Belle journée à vous.

Khamphon Inthavong  48:39

– Merci beaucoup. Bonne journée.

Benoit Bourcier  48:41

– Merci beaucoup Olivier.

Khamphon Inthavong  48:42

– Benoît.

Benoit Bourcier  48:43

– Et puis au prochain café.

Khamphon Inthavong  48:44

– Merci.

Olivier My  48:44

– A la prochaine.

Khamphon Inthavong  48:45

– A la prochaine Olivier. A plus tard. Bye.

Olivier My  48:46

– Salut.

Khamphon Inthavong  48:48

– Salut.