Laurent Morisseau

Bien, bonjour à tous.
C'est une session en français. Je ne sais pas s'il y a des...
Tout le monde comprend, c'est bon?
Bienvenue pour cette session plutôt d'introduction. L'idée c'est, pour ceux qui ne connaissent pas forcément bien le Kanban, d'avoir les clés pour apprécier à leur juste valeur toutes les autres sessions que vous allez pouvoir voir.
Vous donner un contexte, vous donner un peu plus d'informations sur les fondations, sur le pourquoi. Ok.
Ça va, tout le monde m'entend ou j'utilise le micro? C'est bon?
Super!
Non merci.
Je ne suis pas à l'aise avec les micros.
Bien, je me présente, Laurent Morisseau, je suis rennais. Pour ceux qui ont vu certaines de mes sessions au fil des années, vous aurez remarqué que ma photo grandit, grandit, grandit, ça va prendre tout l'espace.
Je suis coach agile et coach Kanban et j'ai écrit un livre Kanban pour l'IT, donc aux éditions du Nau l'année dernière.
Je vais vous donner un petit peu de contexte sur le Kanban, le pourquoi, et également quelques pratiques associées au Kanban.
Déjà, m'assurer que le comment a du sens pour vous, dans votre contexte. Est-ce que vous avez un flux de demandes, et surtout un flux de demandes de nature différente?
Comme une équipe de MCO, de TMA, avec des évolutifs, des correctifs, un peu de support.
Ou même un grand projet, mais avec des demandes d'évolution, et de l'évolution technique, fonctionnelle, des choses comme ça. Oui? Vous avez le droit d'interagir. Oui? Ok.
Et est-ce que votre flux de demande... Et un petit peu déséquilibré par rapport à votre capacité à faire. Il y en a qui sont dans ce cas-là?
Problème de riche, là. C'est rare. Mais ça arrive de temps en temps.
Je pense que vous êtes plutôt dans ce cas-là.
Avec un petit peu de surcharge, des demandes un petit peu différentes, des urgences à traiter, des changements de priorité.
Dans ce cas-là, le Kanban va être fait pour vous, parce que l'objectif du Kanban, un des objectifs, vous avez vu avec la keynote de David qu'on peut voir le Kanban de différentes manières, moi je vais en privilégier une,
et entre autres d'équilibrer la capacité de notre système à réaliser et la demande.
Alors qu'est-ce que ça veut dire? Il y a plusieurs points de vue. Ça va être d'équilibrer la demande au niveau microscopique entre le travail planifié et non planifié.
Avec Scrum, on connaît, le Scrum Master doit protéger l'équipe des perturbations, c'est le travail non planifié. Oui, mais ça arrive. Quand on a une application en production, il y a des bugs qu'il faut gérer, des bugs bloquants, ce genre de choses.
Mais également équilibrer les types de demandes, entre des évolutifs, entre du correctif, entre l'investissement du désendettement technique par exemple,
des demandes de nature un petit peu différentes, avec des contraintes différentes, par exemple avec des dates fixes, Si vous êtes éditeur de logiciels, de jeux par exemple, Noël va être un petit peu important pour vous.
Donc ça c'est un type de demande relativement spécifique qui perturbe notre travail avec une contrainte forte sur les dates. Et au niveau macroscopique entre la demande client et la demande interne,
Également, équilibrer les demandes à court terme. Quand on pilote par la valeur, on va privilégier la création de valeur à court terme, sur un sprint, sur une version. Mais il faut bien également ajuster notre investissement sur les demandes à moyen terme et à plus long terme, pour que ce que l'on est en train de produire ait une pérennité au-delà de la version. Donc c'est un petit peu ce qu'on va faire.
J'ai commencé le Kanban, mais à l'époque ça s'appelait plutôt le développement en flux. J'ai commencé il y a 5-6 ans, et en l'occurrence c'était sur mon premier projet en tant qu'indépendant.
Et donc à l'époque, j'avais plutôt une casquette Scrum. Et par contre, il y avait un fort besoin d'agilité, mais de l'agilité métier. Et moi, je suis arrivé avec une réponse au niveau de la méthode, d'agilité au niveau de la méthode. Mais c'était un contexte qui était très loin du cœur de cible de l'agilité. Pourtant le besoin était là. Le besoin métier, surtout améliorer les délais.
Et le problème c'est que Scrum dans ce contexte-là n'a pas marché. Donc il a bien fallu, surtout quand c'est le premier projet en tant qu'indépendant, il faut bien le réussir. Donc il a fallu que je retombe sur mes pieds, donc j'ai été chercher d'autres manières de faire. Qui permettait de répondre à certains enjeux. Et les enjeux là, donc les attentes de métier, augmenter la satisfaction de l'utilisateur, améliorer le délai, ce sont des attentes, ce sont des enjeux stratégiques. que l'on rencontre évidemment dans nos contextes. Alors il y a différentes manières d'y répondre. Typiquement, augmenter la satisfaction utilisateur, l'agilité, Scrum y répond très très bien. Avec les boucles de feedback, avec les sprints, les démos, donc c'est parfait. Sur l'amélioration des délais, c'est plus compliqué. Et surtout, il y a des contextes où on n'arrive pas à améliorer les délais, même avec une approche Scrum.
Le besoin d'améliorer les délais, donc ça va être un petit peu mon angle de vue pour cette session, elle repose sur deux besoins, typiquement le TTM, le Time to Market, c'est-à-dire pouvoir livrer fréquemment avec une fréquence qui répond à la volatilité du marché, aux besoins de... Aux besoins de changement de vos utilisateurs. Et également, pour les décideurs, sur le juste-attend. C'est-à-dire repousser le moment où je dois prendre une décision le plus tard possible pour que j'ai les meilleures informations pour prendre les meilleures décisions. Que ce soit le TTM ou le juste-attend, on a besoin d'améliorer les délais. La problématique qu'on rencontre dans les contextes où l'agilité ne marche pas, bien, J'ai fait ma petite enquête, j'avais fait un sondage à l'époque auprès d'une centaine de DSI. Et on s'en surprise, les problèmes numéro un, les problèmes qui sont remontés par rapport à l'amélioration des délais, le premier c'est de faire travailler tous les acteurs de la chaîne ensemble. Ok, c'est facile.
La problématique qu'il y a derrière, c'est que chaque équipe a ses propres contraintes, ses propres perturbations, sa propre productivité, sa propre manière de faire.
Et lorsqu'on les met les uns à la suite des autres, on n'est pas dans une optimisation globale.
On va généralement, les contextes où on évolue, demander aux équipes de s'améliorer localement.
Et la somme des améliorations locales ne font pas forcément une amélioration globale. Donc ça c'est un problème fondamental qu'on va essayer de résoudre lorsque l'on veut améliorer des délais bout en bout, c'est-à-dire des améliorations qui sont visibles des utilisateurs. Donc là on a un enjeu fort, et le deuxième, comme je l'ai dit, c'est optimiser globalement la chaîne plutôt que localement les équipes. Le problème de l'optimisation globale, c'est que, David l'a dit tout à l'heure, c'est qu'on est dans des systèmes complexes, et que pour améliorer un système complexe, on ne peut pas le faire de manière prédictive, c'est très compliqué. Donc on va plutôt avoir une approche pragmatique. Et une approche évolutive. C'est un vrai problème. Quand on fait des enquêtes, notamment, je cite l'enquête du French Chrome User Group, un projet sur trois, pour un projet sur trois, la complexité est une barrière à l'adoption de l'agilité. Vous avez peut-être rencontré ce type de problème?
Oui, non? Non, ce n'est pas votre problème? Oui, il y en a quelques-uns, bien. Ok. Et donc là, il va falloir trouver une autre solution pour s'améliorer. Un autre problème, c'est qu'un problème sur deux en agile provient également des interactions avec des entités non agiles. C'est un problème également. Oui?
Pardon, je croyais que tu avais... Tu confirmes, on confirme tous, on l'a tous vécu, c'est dans les dysfonctionnements en général. Donc, si je reviens ici, l'agilité, globalement, répond sur une partie du processus,
Et on a du mal à avoir une, comment dire, à appréhender, à adresser toute la chaîne complète. Et dans certaines DSI, on a des équipes spécialisées. Il est difficile d'être dans la cible de l'agilité, c'est-à-dire une équipe pluridisciplinaire avec toutes les compétences qui permettent de prendre une demande et de la sortir. Dans ces contextes où on ne peut pas avoir une équipe pluridisciplinaire, comment on fait?
Les résultats que l'on constate, alors c'est des chiffres qui viennent du Lean, et puis des ateliers, moi je rencontre régulièrement ce chiffre dans les ateliers que je fais avec mes clients, c'est que globalement si on se place du point de vue d'une demande, la demande passe 95% de son temps dans la chaîne à attendre. Et globalement 5% de son temps,
ce qu'on appelle le touch time, c'est-à-dire le moment où on la valorise, où on la transforme pour arriver jusqu'à une solution. Est-ce que ce chiffre vous parle? Ça me semble réaliste pour vous. Oui?
De la demande d'utilisateur jusqu'au moment où j'utilise. Donc si je veux améliorer mes délais, je ne vais pas chercher à optimiser les 5% En tout cas, c'est notre point de vue. Les 5% où je valorise, où je transforme ma demande, mais plutôt j'ai un grand levier sur les 95% en attente. Donc là, il y a un vrai levier. Et ces 95% du temps en attente, si je suis schématique, ils proviennent principalement des interactions que l'on a entre les équipes, ou entre des demandes, entre des activités.
Entre deux activités, entre le métier et la réalisation, je vais avoir du stock. Le stock, c'est mes spécifications qui ne sont pas en train d'être codées.
Donc là, je suis une demande, j'ai été spécifié et j'attends qu'on s'occupe de moi, qu'on va me développer. Ah, c'est du stock, c'est du temps passé et du temps perdu. Et ainsi de suite, d'équipe en équipe, d'activité en activité. on va avoir ce stock. Le problème dans notre métier, c'est que ce stock est non visible. D'ailleurs, on n'a jamais parlé de stock.
Le vocabulaire vous choque peut-être.
Ok, donc voilà un petit peu toutes les problématiques qu'on va avoir à adresser dans les contextes où typiquement on n'est pas dans le cœur de cible de l'agilité, mais où les attentes sont fortes au niveau du respect des délais, c'est la première des choses, et ensuite de l'amélioration de ces délais.
Donc on va arriver doucement au Kanban, l'image qu'on utilise souvent.
c'est d'imaginer une course de relais où le relais, c'est la demande. C'est-à-dire qu'on ne se positionne plus du point de vue d'une version, d'un ensemble de périmètres, mais plutôt d'une demande et on va la regarder traverser tout notre système. On utilise cette métaphore parce que Scrum a une autre métaphore qui est le sprint.
Sprint sur une partie du processus.
Là, on va avoir une vision un peu plus globale et on va avoir une course de relais. Le problème que j'ai évoqué tout à l'heure, c'est que les équipes ont des contraintes, une manière de faire différente. C'est une course de relais, mais en triathlon. Je vais passer de la piscine au vélo, etc. Avec chacun ses difficultés, ses manières de prioriser tout ça.
Ça devient compliqué à faire tout, quand on met bout à bout toutes ces problématiques, mais c'est des problématiques qu'on rencontre effectivement.
Et donc le point de vue, ici, va être de s'adresser au système, processus, et aux règles qui régissent ce processus-là. Diminuer les délais, on va s'adresser aux processus et aux interactions, interactivités. Mais ça, ce n'est pas évident. Parce qu'on a des silos, parce qu'on a des équipes spécialisées, ils ne se parlent pas forcément. Donc on va amener des déclencheurs qui permettent justement d'interagir plus fortement. Pourquoi, si on veut un petit peu expliquer pourquoi on s'adresse au processus, Je me réfère souvent à Deming, vous le connaissez, la route Deming, cycle PDCA, c'est celui qui a un petit peu formalisé les approches empiriques, plan de check act, ça parle à tous ? Et donc Deming, son point de vue, c'est 95% de la capacité d'un système, Alors la capacité en France, on n'est pas à l'aise avec la notion de performance, on appelle ça capacité, mais c'est la performance du système. Ce sont les fitness criteria que David a évoqués dans sa keynote. Donc on va plutôt adresser les 95% de la capacité qui sont influencées par la conception du système, plutôt que les 5% qui sont portées par les gens.
C'est un point de vue.
Et on va le faire avec le bon niveau d'abstraction. Parce que du camban, il y en a plusieurs.
Mazette.
Si l'image que je prends, si je veux regarder un plan, si je veux aller d'une ville à une autre, je vais avoir un certain niveau d'information. Par contre, si je veux aller dans une rue à une adresse très précise, je vais aller plus finement, un niveau d'information plus fin pour pouvoir me localiser. Donc on va retrouver un petit peu ce même schéma dans l'approche Kanban.
Vous imaginez comment ? Des idées?
On va voir comment au niveau portfolio, gestion de portefeuille. Et on va le faire avec le bon niveau d'abstraction. Parce que du camban, il y en a plusieurs.
Mazette.
Si l'image que je prends, si je veux regarder un plan, si je veux aller d'une ville à une autre, je vais avoir un certain niveau d'information. Par contre, si je veux aller dans une rue à une adresse très précise, je vais aller plus finement, à un niveau d'information plus fin pour pouvoir me localiser. Donc on va retrouver un petit peu ce même schéma dans l'approche Kanban.
Vous imaginez comment ? Des idées?
On va voir comment au niveau portfolio, gestion de portefeuille,
Vous avez ces problématiques, certains ont ces problématiques de gestion de portefeuille?
Oui, quelques-uns. Imaginez une DSI qui gère annuellement 200, 300, 400 projets. On peut le voir comme un flux, un flux de demandes, mais avec une granularité de projet.
Et bien ça, on va pouvoir aller sur un pilotage en termes de flux. Il y a un interrupteur par là, c'est ça? Qui permet de changer la lumière.
Donc on peut adresser cette problématique de pilotage de flux au niveau d'une entreprise avec la gestion de portefeuille. Alors autant vous dire tout de suite qu'en France, il y a très peu de REX, il y a très peu d'initiatives encore à ce niveau-là, donc en manque de maturité, en manque de retour d'expérience. Je vous invite à expérimenter ça dans votre contexte. Mais certaines DSI sont leurs premiers pilotes à ce sujet-là. Ce qu'on connaît le plus, c'est le Kanban classique, c'est-à-dire sur un flux de valeur, sur une famille de produits, sur un produit, et on prend les demandes des utilisateurs à la mise en production, c'est ce qu'on connaît le plus.
On a également du Kanban au niveau équipe. Là, par exemple, si je fais un petit focus, ça pourrait être le cas, comme Claude va nous en parler. parler juste après, d'avoir une vision centrée sur l'équipe, avec du Scrum par exemple, et à l'intérieur de cette équipe, essayer de fluidifier notre travail. Évidemment, vous voyez qu'on n'a pas les bénéfices attendus par un Kanban de plus haut niveau, qui est donc fluidifié jusqu'à l'utilisateur. Et puis au niveau personnel, on a le personnel Kanban, ça je le dis pour la culture, et on a un digne représentant ici de cette lignée-là, qui est Guillaume Lours. Je ne sais pas si tu en parles pendant les deux jours. Non, vous pouvez aller lui demander en tout cas. Donc voilà, on a plusieurs niveaux d'abstraction pour le Kanban, à vous de choisir là où vous voulez intervenir. Bon, évidemment, généralement, c'est plutôt, on va commencer pragmatiquement au niveau des équipes, et puis on va essayer d'aller au niveau produit, et on se posera la question à un moment donné de la gestion du portefeuille. Les enjeux organisationnels du Kanban sont donc améliorer l'agilité, mais l'agilité métier, On va utiliser une méthode sans méthodologie, j'ai appris ça tout à l'heure. Donc on va plutôt chercher à améliorer l'agilité métier avec toutes les problématiques que ça tire.
Améliorer la prédictibilité du processus qui y répond. Si c'est une problématique pour vous, on l'a dit tout à l'heure, les métriques qui vous intéressent, gardez-les, celles qui ne vous intéressent pas, vous les mettez de côté.
Avoir une approche évolutive du changement, on l'a dit et répété déjà autour de la keynote, et puis avoir une approche de gestion de risque. Voilà les enjeux organisationnels. qu'il y a derrière le campement.
Avec quelques enjeux opérationnels, concrètement pour les équipes, c'est rendre transparent le processus, boîte blanche.
Alors déjà, c'est l'identifier et la rendre transparente vis-à-vis de l'extérieur de notre équipe, de l'organisation. On va décentraliser les prises de décision si on veut fluidifier tout au long de notre processus.
Il ne faut pas qu'on ait un coordinateur central qui prenne toutes les bonnes décisions au quotidien. Mais on veut déléguer cette prise de micro-décision quotidienne aux équipes. Et que chaque équipe, chaque personne, prenne la bonne petite décision pour globalement fluidifier notre travail. Ça, ça va être un enjeu très fort. Simplifier la complexité, parce qu'on l'a vu, c'est un frein à l'adoption. Simplifier la complexité, c'est-à-dire qu'on va être pragmatique, on va modéliser le plus simplement possible la manière dont on travaille. Et lorsqu'on commence une approche Kanban, on ne va pas chercher à modéliser un système qui marche pour toutes nos demandes, pour 100% de ce que l'on traite. On va peut-être commencer par 80% de ce que l'on traite, et les 20% autres, au début ça ne va pas bien marcher. Mais quand on aura suffisamment appris et mûri sur notre système Kanban, on va pouvoir l'améliorer pour ouvrir le scope des demandes, savoir traiter les demandes de plus en plus marginales, et ouvrir la portée également de notre processus.
Développer la collaboration. Entre équipes.
Et tout ça pour fluidifier le travail.
Donc ça, c'est quels étaient les enjeux.
Et j'aimerais bien vous parler de quelques contextes d'organisation qui aujourd'hui basculent sur le Kanban, et notamment tous les premiers clients, tous les early adopteurs finalement du Kanban, notamment en France, qu'on a rencontrés.
J'aimerais bien savoir qui en fait déjà du comment.
Mise à part tous les coachs, les vrais gens qui font du vrai boulot,
Non, pas toi. Pas toi, pas toi. Oui, oui, on sait. Vous êtes dans quel contexte?
Non, pas toi. Pas toi, Pierre. Les autres, vous êtes dans quel contexte? Enfin, start-up.
Voilà, start-up.
Pardon ? Boîte internet.
Du portfolio. Ok. Très bien. D'autres contextes?
Équipe.
Équipe support, désolé.
C'est très compliqué.
D'autres équipes, d'autres contextes? Donc, start-up, support, équipe web? Support et delivery. Bon, moi, les contextes que j'ai rencontrés, qui ont été les premiers demandeurs de passer au Kanban, c'est, sans surprise, les organisations en silo, où on a essayé du Scrum. À l'intérieur d'un process, développement recette. On avait des équipes tellement spécialisées, tellement distribuées géographiquement qu'on n'arrivait pas à passer le cap de l'agilité, on l'a tous connu. Et puis également jusqu'à la pré-exploitation. Et donc à un moment donné, on se pose la question, Scrum c'est très bien, on a beaucoup de bénéfices, satisfaction utilisateur, tout ça, ça a bien marché. Maintenant sur les délais, on a encore des problématiques. Et on a bien optimisé cette partie-là, mais ce n'est pas visible de toute la chaîne, donc comment on fait la bascule. Et donc là, on va aller travailler en amont avec le métier et en aval avec l'après-exploit pour avoir des cambans qui vont s'enchaîner en cascade, d'équipe en équipe, pour pouvoir fluidifier toute la chaîne de travail. C'est vraiment bizarre la lumière. Il faut que je fasse des tests.
L'autre contexte, je l'ai rencontré également dans les DSI, c'est le contexte où on a fait une première version en Scrum, pareil qui a très bien marché, ou enfin qui a bien marché, en tout cas on veut garder le bénéfice de cette organisation pour les prochaines versions. Mais la première version se finit, elle va en prod. Et puis, bon, ça a bien marché, mais il y a quand même pas mal, il y a quelques bugs. Donc le support, la maintenance corrective, c'est une activité en tant que telle. Et puis Scrum nous dit... s'engager sur un périmètre, sur un sprint, geler le changement au sein d'un sprint, pour justement être discipliné là-dessus. Et donc, l'un dans l'autre, ils prennent la décision d'avoir une équipe Scrum pour les gros évolutifs, et puis une équipe, je dirais, plus traditionnelle pour la partie maintenance corrective.
Vous avez ce contexte-là? Oui, bon Pierre, tu as tous les contextes, de toute façon.
Vous avez rencontré ce contexte-là? Donc c'est plutôt un contexte de transition, on veut garder le bénéfice de l'agilité, mais on ne sait pas encore comment bien gérer tout ça, et il y a des problèmes, parce qu'évidemment on travaille sur le même socle, sur le même produit, Donc on a des interactions qui sont artificielles du coup, avec deux équipes séparées. Et l'idée ici, c'est de pouvoir reconverger ces deux équipes vers une... équipe avec une approche un petit peu le meilleur des deux, en gardant le bénéfice de Scrum, mais en pouvant prendre, augmenter la portée de ce que l'on traite et prendre justement du correctif, du support, ce genre de choses.
Et donc, elle est convergée vers du Kanban. Les contextes des éditeurs de logiciels également. Avec petites équipes qui font tout, mais qui font tellement tout qu'ils s'occupent de plein de produits, de plein de clients, du support, etc. Et là, planifier ne serait-ce qu'à une semaine ou à deux semaines, c'est juste pas possible.
Donc on va chercher dans ces contextes-là à travailler vraiment en mode flux. Il y en a qui sont dans ce contexte? Les éditeurs? Oui, Pierre, tu es dans ce contexte?
Et le dernier contexte qui arrive, c'est la gestion de portefeuille. Là, à titre d'exemple, c'est un atelier que j'ai fait la semaine dernière. On a cinq projets sur tout le processus. Ça, c'est juste le sorti de l'atelier qu'on a fait la semaine dernière. Sauf que derrière, il y en a 80 des projets en live.
Donc là, c'est qu'une petite vue de ce que représente le pilotage de portefeuille dans ce contexte-là. Et là, on a encore beaucoup de travail.
Ça va, donc si on regarde un petit peu les domaines, le plus intuitif pour aller vers du comment, c'est la maintenance, le MCO. C'est là où on sent qu'on est dans le cœur de CIP, parce que justement on a ce flux de nature différente,
Flux de nature différente, David a parlé d'avoir une approche orientée service. Il va y avoir des niveaux de service différents par rapport aux natures de demande. Un bug bloquant de prod, évidemment, on va réagir beaucoup plus vite, c'est évident, qu'une évolution, que la migration d'une version mineure d'un framework technique, par exemple, qui reste important à plus long terme. Mais on a bien des niveaux de service différents. Et ce que l'on veut, c'est avoir une équipe et un système qui encaissent justement des niveaux de service différents.
Donc maintenance applicative, c'est vraiment le cœur de cible, mais ce que l'on a appris également sur les gros projets,
c'est que, comment peut être très intéressant également, en fait, partout où on a un bon contexte pour de l'amélioration continue, c'est-à-dire les gros projets qui vont s'inscrire dans le temps,
ou des flux de petits projets, mais avec une équipe stable dans le temps.
Bien que ce soit orienté service, Kanban, on a également une vraie valeur ajoutée d'avoir cette approche dans ces contextes-là, pour l'approche d'amélioration continue et d'évolution. Et puis l'activité de support, qui est donc une vraie problématique à part entière. Vous avez une communauté de Kanban Ops.
Pierre n'est pas d'accord.
Non, je... Hein?
Je ne l'ai pas mis, le portefeuille. Pour l'instant, sur le portefeuille, encore une fois, on n'a pas encore assez de retours. Enfin, moi, personnellement, je n'ai pas assez de retours d'expérience pour en parler plus que ça. Donc, je ne l'ai pas mis à ce niveau-là.
Donc l'activité de support, ce que je disais, c'est que c'est des pratiques à part entière, qui ne sont pas exactement les mêmes que le Kanban pour l'IT. Et donc la communauté, c'est Kanban Ops. Je ne sais pas si vous la suivez. Sur les groupes Yahoo, c'est porté par Dominique de Grandis, par exemple. Je ne sais pas si vous la connaissez. Donc c'est une vraie filière. Bon, donc on a vu les enjeux, on a vu des contextes.
C'est quoi le Kanban? On a un petit peu dévoilé le sujet ce matin.
Sur certains slides, j'irai plus vite. Donc le Kanban, les grands principes,
C'est que pour réduire le délai, encore c'est un point de vue, on va travailler sur des petits lots, on va fluidifier notre travail, ça c'est une première chose, et on va aller chercher à travailler en flux. Ça c'est la première des étapes, c'est travailler en flux. C'est déjà un vrai enjeu de travailler en flux.
Qu'est-ce que ça veut dire? On va le voir tout à l'heure. Et ensuite, pour que chacun travaille au bon rythme, parce que si vous vous rappelez les problématiques précédentes, C'était qu'on a des équipes qui s'enchaînent, avec chacun leur propre manière de faire, leur propre contrainte ou vitesse, Il faut que tout ça s'orchestre bien. Donc pour que chacun travaille au bon rythme, on va créer un système tiré. Et tout ça fait le camban.
Notre expérience montre que d'aller sur un système tiré, c'est assez difficile, qu'il faut prendre le temps, qu'on ne va pas y aller du jour au lendemain. Par contre, mettre en place le flux, ça, ça va être notre vraie première étape.
Qui travaille en système tiré, déjà.
Il n'y a plus que des personnes qui font le camban.
C'est rigolo.
Vous avez eu quelques retours d'expérience, donc ceux qui travaillent en système tiré. C'est difficile, il faut prendre le temps, on ne va pas y aller du jour au lendemain. Par contre, mettre en place le flux, ça, ça va être notre vraie première étape.
Qui travaille en système tiré, déjà.
Il n'y a plus que des personnes qui font le camban.
C'est rigolo.
Vous avez eu quelques retours d'expérience, donc ceux qui travaillent en système tiré.
Ça, c'est notre culture, c'est notre profession, ça. C'est bien ancré dans notre profession. Alors il est évident que déjà travailler en flux, ça nous apporte du bénéfice. Mais si on veut toucher le bénéfice qui permet de répondre aux enjeux que j'ai cités tout à l'heure, il faut aller sur du système tiré.
Et ça, ce n'est pas si simple. Donc, pousser, alors tirer, ça parle à tout le monde ou pas? Donc nous, on est plutôt dans un mode poussé. Enfin, on a connu plutôt le mode poussé.
Je produis toutes les spécifications si je suis analyste, et puis je les pousse au développeur ou à l'équipe de développement.
Je caricature et je ne juge pas le cycle en V, tout ça. Je pousse que l'équipe de réalisation soit en capacité ou non de le traiter. Si elle n'est pas en capacité, ça va créer une file d'attente. Si elle est en capacité, parfait. On voit bien que le risque, c'est de créer cette file d'attente, donc des délais, et on revient sur les problématiques précédentes. Le système tiré, donc là c'est un changement de perspective, et effectivement on n'a pas l'habitude de ça dans notre métier, c'est que là c'est le développeur qui va déclencher Alors un petit peu en avance de phase, là il est quand même très très tiré le travail. Il va déclencher avec un petit peu d'avance, il va dire à l'analyste, je vais bientôt avoir besoin, d'un petit bout de spec à implémenter. Toute la spec, mais un petit bout. Il va y avoir des déclencheurs. Et les déclencheurs, la pratique simple, mécanique, pour aller vers du système tiré, pour avoir ces déclencheurs, pour discuter entre équipes, ce que l'on propose, pour commencer, c'est de mettre des limites. Les limites qu'en vont. C'est simple, efficace, mais difficile dans la réalité. En tout cas, ce qui est difficile, ce n'est pas forcément de mettre une limite à une équipe, C'est d'équilibrer toutes les limites tout au long de la chaîne pour que tout ça soit fluide. La difficulté, elle est vraiment là. Il n'y a aucun modèle mathématique, scientifique, n'importe, qui va nous permettre, dans notre métier, qui va nous permettre de définir ces limites. Donc, on va avoir une approche pragmatique et empirique. On va essayer, on va tuner, jusqu'à ce que, justement, le flux s'installe bien et soit régulé.
Donc là, très rapidement, comment ça marche les limites. J'ai pris quelques activités un petit peu génériques. Chaque activité, j'ai mis une limite de 3 pour la première, 2 les autres. Et là, mon système est rempli. Rempli, il y a autant de travail que les limites.
Donc la petite étoile bleue, ça veut dire que moi, j'ai fini ma tâche, et que du coup, naturellement, je vais aller en prendre une nouvelle. Mais pour en prendre une nouvelle, il faut que je pousse ma tâche dans cette activité-là, qui pour l'instant est pleine, donc je ne vais pas le faire maintenant. que l'activité N libère une place, et pour qu'elle libère une place, il faut qu'elle finisse une tâche et la pousse à son voisin. De proche en proche, on arrive en bout de chaîne, et à un moment donné, arrive ce qui doit arriver, c'est qu'une place se libère.
Une place se libère, ça veut dire par rapport à ma limite, la limite étant liée à ma capacité à faire, Donc par rapport à ma limite, j'ai maintenant de la capacité d'aller chercher plus de travail. Donc je vais aller le faire dans l'activité en amont.
Donc je tire une tâche, ce qui libère une place dans mon activité N, et de proche en proche, ça va arriver jusqu'à moi. Et là, je vais être en capacité maintenant d'aller prendre une nouvelle tâche en amont. Donc là, on est dans le pur système tiré, dans la mécanique. Alors, ça pose plein de questions. Qu'est-ce que je fais en attendant? Est-ce que je tourne des pouces? Est-ce que je vais aider les uns ou les autres? Est-ce que je travaille en avance de phase?
Ça pose évidemment plein de questions, mais la mécanique, elle est là.
Pourquoi du flux tiré ?
Je l'ai dit, pour équilibrer tout le système, mais au-delà, en termes de création de valeur,
Éviter le gâchis, le stock. Voilà.
Est-ce que c'est nécessaire? On est vraiment sur la valeur pour diminuer les stocks à l'intérieur. C'est un mot qui m'écorche la bouche, diminuer le stock. Mais voilà, c'est un petit peu ça. Donc là, j'ai repris les mots de Coré Ladas. Je ne sais pas si vous le connaissez. C'était à l'époque celui qui a sorti un essai sur le Scrum Band, il y a très très longtemps. C'était un essai, mais c'était une vraie source d'informations. Et lui, il a traduit ça comme ça suit. On ne construit pas plus de fonctionnalités dont personne n'a besoin maintenant. Ok? On ne décrit pas plus de spécifications que l'on ne peut coder.
On ne code pas plus que ce qu'on sait tester, on ne teste pas plus que ce qu'on peut déployer, et surtout à la fin, on ne déploie pas plus que l'utilisateur ne peut utiliser. Ça c'est important également.
Et donc si on remonte la pente, notre système, je vais déployer que ce que l'utilisateur est en capacité d'utiliser maintenant,
Voilà, ce que je peux... Non, pardon, je vais coder plus que ce que je peux... Je ne vais pas coder plus que ce que je peux déployer maintenant, etc. Et je remonte. Donc on est vraiment, c'est un système tiré, qui vient de l'aval et qui remonte notre processus, et tiré par notre capacité à faire tout au long de la chaîne. C'est ce qui va réguler notre flux. C'est comme ça que vous travaillez, donc. Système tiré, vous arrivez à aller jusqu'au bout de la chaîne ou pas? Ouais?
On peut très bien commencer, quand on initialise une démarche Kanban, sur un bout de la chaîne, parce que c'est quelquefois assez difficile d'aller jusqu'aux utilisateurs. Donc on va commencer sur une partie de la chaîne, et après on va chercher à augmenter la portée de notre système Kanban de plus en plus. Et ça, pareil, ça va prendre du temps. Quand je dis que ça prend du temps, C'est plusieurs mois, quelques années, on est dans l'amélioration continue, on considère qu'on a le temps.
Il y a des pratiques pour réussir, donc là je les passe vite parce qu'on les a vues tout à l'heure. Donc on a six pratiques de visualisation, limiter le travail en cours, mesurer, gérer le flux de travail, rendre explicite les règles de gestion, implémenter des boucles de feedback et ensuite s'améliorer de manière collaborative.
Toutes les premières, les quatre premières là.
L'objectif de ces règles sont d'abord de réguler notre flux. De maîtriser notre flux.
On ne va pas chercher à s'améliorer tant qu'on n'a pas régulé notre système. Parce qu'améliorer le chaos, ou avec beaucoup de variabilité, c'est très compliqué. Et surtout, on ne va pas apprendre.
Donc ça, on va chercher à réguler. Une fois qu'on est en maîtrise, on va apprendre et ensuite s'améliorer et faire évoluer notre processus.
Qui va jusqu'au bout des pratiques.
On va parler de Guillaume.
Et à part Pierre.
C'est intéressant de... C'est une autre discussion, par contre.
Je te propose d'en parler à la pause. Non, on ne va pas avoir le temps de finir.
Ok, donc on a des fondations, on a une pratique, Moi, je propose également une démarche empirique qui s'appuie sur le cycle PDCA de Deming.
Avec une phase de conception où on conçoit le processus. Alors cette phase-là, elle peut durer quelques heures avec l'équipe et on y va. Mais une phase de conception de notre système pour identifier, visualiser, modéliser. Faire la photo de notre système à un instant donné, et ensuite la mettre en œuvre, la mettre en action. La mettre en action pour le faire vivre.
Et le faire vivre pour voir tous les dysfonctionnements, toutes les problématiques que ça va remonter. Et toutes ces problématiques, tous ces dysfonctionnements vont nous permettre d'étudier notre système et de le comprendre, d'apprendre de notre système. Et l'apprentissage va permettre... de l'améliorer et de repartir sur des boucles d'amélioration. Schématiquement, la démarche d'amélioration continue du campement va s'appuyer sur ces cycles-là. Et tout ça, on va le faire en douceur. Donc ça, pareil, ce sont les fondations, on va commencer là où on en est.
Par contre, on ne s'arrête pas là, parce que sinon il ne se passe rien. Donc on va commencer là où on en est, respectant le processus actuel, les rôles et les responsabilités. Typiquement, le Kanban ne vient pas avec des nouveaux rôles, il n'y a pas de Kanban Master, il n'y a pas tout ça. On fait avec l'existant, chef de projet, scrum master, peu importe, chef d'équipe, peu importe ce qu'il y a dans... qu'il y a dans notre environnement. Par contre, on s'engage à changer de manière incrémentale. Incrémentale, ça va être nos tours de cycle. Et tours de cycle, ce sont des tours qui sont de l'an.
avec du leadership à tous les niveaux, là on est dans la décentralisation, et pour donner du poids aux équipes, leur donner le droit de faire évoluer leur processus,
Et on y va!
On a conçu, on a modélisé, on a fait la photo et on a nos tableaux. Là, je vous ai mis différents tableaux.
Qui peut me dire, alors ils sont très différents les uns des autres, qui a une idée de l'équipe dans ces tableaux-là, qui est la plus avancée en termes de maturité sur son processus.
Une idée ?
Celle du bas?
Non?
C'est difficile de savoir.
On a quand même quelques signaux forts.
Les signaux forts, c'est que celui-là... Je vais commencer par celui-là. Je m'attendais à ce que certains disent celui-là, parce qu'il est super propre.
Il est nickel. Par contre, il est tellement nickel que moi, je n'ose pas y toucher. Et d'ailleurs, personne n'ose y toucher. Ça fait six mois que j'essaie d'intervenir dans cette équipe. Processus, il n'a jamais évolué en six mois.
On n'est pas dans la boucle d'amélioration continue. Par contre, effectivement, celui-là, l'équipe,
Et d'ailleurs, c'est la même équipe que celle-là. Mais un an et demi après, Impression qu'ils se sont dégradés, parce que là, c'était propre. Et là, pas super sale. Mais ça, c'est un tableau qui vit tellement bien que tout le monde, toutes les personnes de l'équipe, toutes ces personnes-là se sentent capables d'être force de proposition sur faire évoluer la manière dont ils travaillent. Et ça se ressent, on sent qu'il est très évolutif ce tableau-là.
Donc voilà quelques exemples.
Et comment ça se passe au quotidien?
On va avoir une réunion quotidienne avec toutes les équipes, par contre, le plus possible. Et on va gérer le flux de travail, donc cette fois on va faire un focus sur le mouvement des éléments, Pas forcément sur les personnes, Scrum, l'objectif des meetings, c'est l'auto-organisation à plus long terme. Donc c'est normal d'avoir un format qui s'appuie sur les personnes. Là, le focus, il est plus sur le flux de travail. Donc on va regarder quels éléments bloquent, lesquels on injecte, lesquels on va finir. Donc plutôt sur le mouvement.
Le problème, c'est que... Puisqu'on va mettre des règles, notamment des limites, ça ne va pas être un long fleuve tranquille tout ça. On va avoir quelques dysfonctionnements, quelques obstacles. Comme par exemple ici, l'activité 2 qui est bloquée.
Bloquée par l'activité 3. Elle est bloquée, elle pourrait aller chercher d'autres tâches. Donc là, il y a un vrai blocage. Donc l'équipe, au jour le jour, va devoir apprendre à gérer ça.
Et c'est typiquement ce genre de blocage qui va l'emmener à parler avec les autres. Comment je peux t'aider? Est-ce que je peux commencer quelque chose? Qu'est-ce que je peux faire, en gros? C'est toutes ces discussions qui vont permettre de gagner en maturité, de trouver des solutions et de faire évoluer la manière dont on travaille ensemble, cette fois.
Bon, il y en a plein d'autres des dysfonctionnements. Et au final, ce que disait David tout à l'heure, le Jeet Kune Do du Kanban, c'est que le Kanban n'apporte pas tout dans la méthode, on n'a pas toutes les solutions aux problématiques qu'on fait ressurgir avec le Kanban. Par contre, on va aller piocher dans les différentes méthodes. Une fois qu'on a vu nos dysfonctionnements, savoir comment on va les améliorer, comment on va les comprendre. On va les piocher dans différentes méthodes. Par exemple, on va chercher à fluidifier le travail. Là, on s'appuiera sur la théorie des files d'attente. On va chercher à travailler à la bonne vitesse. Et travailler à la bonne vitesse par rapport à des goulets d'étranglement ou des contraintes. Ça, c'est la théorie des contraintes qui va nous apprendre un petit peu comment sécuriser ce travail-là. On peut chercher à réduire la variabilité. Si la variabilité est un problème pour vous, on va identifier les limites naturelles de variabilité de notre système pour pouvoir faire des focus sur les analyses de cause-effet, sur pourquoi on a... On a autant de variabilité, donc ça c'est la maîtrise statistique des procédés, c'est bouh! 6 sigma, bouh!
On ne va pas jusqu'à là, mais ils nous ont apporté des choses intéressantes, comme les cartes de contrôle et ce genre d'analyse. On va aussi chercher à réduire les délais, donc là on va aller creuser dans le lean, la résolution de problèmes, etc. Vous voyez qu'on a des pointeurs vers d'autres méthodes. qui, elles, vont nous apporter une meilleure compréhension. et éventuellement des solutions pour s'améliorer. Il y en a d'autres, j'ai mis les principales. On parle de plus en plus des options réelles, ça a de plus en plus de sens lorsqu'on va au niveau de la gestion de projet.
On continue notre boucle. On a conçu, ça s'est traduit par des tableaux, on a géré au quotidien, ça a alimenté nos conversations, on a pu voir des dysfonctionnements, on a étudié notre système avec différents modèles, et maintenant on le fait évoluer, on va ajuster notre système. Et là on a pas mal de leviers dans l'ajustement. Notamment le processus. Est-ce que je rajoute ou non un buffer entre deux activités, justement pour amortir ou pour sécuriser un goût d'étranglement? On va faire évoluer notre processus. Ou enlever une file d'attente finie, par exemple, si deux équipes ont tellement appris à travailler ensemble que maintenant elles n'ont plus besoin de ce stock intermédiaire, de cette file d'attente intermédiaire, ça arrive.
On va faire également évoluer les règles, les règles explicites qui permettent justement aux éléments de passer d'une activité à une autre.
Évidemment, celle qui tombe sous le sens, c'est d'ajuster les limites. On va plutôt chercher à les réduire.
Pour diminuer les files d'attente, diminuer les délais, et également la variabilité.
Maintenant, on ne va pas les réduire de trop, parce qu'on veut quand même conserver du flux avant toute chose. Si on réduit trop, on peut être amené à avoir un effet de barrage et des lâchés de barrage, et là, on n'est plus dans le flux.
Donc ajuster les limites de manière empirique. Également les éléments, là les boucles de feedback, si on a des problématiques de blocage ou de congestion, vont aussi nous apprendre à savoir mieux découper, découper à la bonne granularité les éléments qui vont traverser tout notre système. Ça c'est un vrai apprentissage.
Et donc juste assez, on va ajuster le système juste assez pour provoquer le prochain tour. Et apprendre de ça.
Apprendre du système Kanban, on va le faire évoluer et on va l'évaluer pour que le système évolue et ça va être une évolution propre à chaque équipe, on l'a dit encore une fois ce matin. Apprendre des comportements émergents, vous voyez que le Kanban là, c'est tout. Il y a peu de pratiques. Par contre, il y a beaucoup de comportements émergents ou de modèles de conception émergentes, comme les tableaux à deux niveaux, l'essai-mage, on parlait de fourmillement, mais je vais parler d'essai-mage maintenant, parce que Claude a...
trouver un meilleur vocabulaire, les classes de service. Tout ça, ce sont des modèles de conception qui émergent. Ce n'est pas parce que vous ne faites pas de classe de service, vous ne faites pas de Kanban. Mais par contre, vous êtes amené à un moment donné à identifier des classes de service parce que, justement, il y a de la variabilité, il y a une opportunité pour créer différents niveaux de service.
Et donc on va apprendre de ces comportements émergents pour aller vers plus de maturité organisationnelle du côté des équipes et également du côté du management.
Donc juste pour information, je raconte un petit peu une histoire de cette évolution de maturité dans le très bon livre collectif, Rupture douce, vous pouvez le feuilleter derrière, il y a un exemplaire. Donc le Kanban, une méthode agile, une méthode de gestion de projet, une méthode de gestion de tâches? Oui, ça pourrait être un petit peu tout ça, mais... Non, c'est une méthode de conduite du changement par l'amélioration des processus pour aller vers du flux tiré. Mais attention, amélioration continue, tout ça dans le respect des équipes. Le respect des équipes passe par le fait que ce sont les équipes qui apportent le changement et surtout qui l'apportent à leur rythme. Quand on est dans l'opérationnel, on ne peut pas encaisser tout le temps du changement, et donc il faut accepter que ce changement soit lent. Et il s'applique dans différents contextes, cycle en V, bureau d'études, Ça, c'est un petit peu l'ironie. De la chose, c'est-à-dire qu'on revient vers le bureau d'études des industries avec une super nouvelle méthode, le Kanban, qu'ils ne connaissent pas du tout depuis 40 ans.
Et je vais finir par ça, notamment dans Scrum. Et donc vous avez une super session qui suit avec Claude Aubry pour cabmaniser votre Scrum, donc savoir concrètement ce que ça veut dire.
Et voilà.

Transcription