Dan Vacanti - The Secret History of Kanban and Why it Matters (EN)

[00:00:15] D'accord. Euh, Est-ce que tout le monde m'entend bien ? J'espère que tout le monde me voit. Oui, merveilleux. D'accord, tout a fonctionné. Très bien, euh, bonsoir mesdames et messieurs. Euh, merci d'être ici. C'est à peu près tout le français que vous aurez ce soir. Euh, j'ai failli dire, j'ai dit bonjour ou bonsoir ? Je suppose que c'est bonjour pour moi, peut-être bonsoir pour vous. Euh, donc désolé pour ça. Euh, mais merci, merci à tous de rester avec nous malgré ces difficultés techniques, je m'excuse pour le retard au démarrage. Euh, la bonne nouvelle est que cette conférence est assez courte, euh, donc nous devrions encore avoir beaucoup de temps pour les questions-réponses, euh, nous devrions encore avoir beaucoup de temps pour tout faire ce que nous devons faire.
[00:01:02] Donc merci beaucoup d'avoir tenu bon. Euh, en ce qui concerne les questions-réponses, puisque c'est une courte présentation, je pense que ce que je vais faire, c'est que je vais tout passer en revue, puis j'attendrai la fin pour prendre les questions. J'aime normalement avoir un peu plus d'interaction pendant que je présente cela. Euh, mais je pense que ça aura du sens pour que nous puissions juste passer en revue tout ce que j'ai à dire. Et puis parlons des choses les plus importantes, c'est-à-dire ce que vous voulez tous dire. Alors, faisons-le sans plus tarder, n'est-ce pas ? Euh, Entrons directement dans le vif du sujet. Donc, l'histoire secrète du combat et pourquoi c'est important. Tout d'abord, euh, je tiens à mentionner que cette conférence est basée presque entièrement sur, euh, une conférence et un article de blog qu'un gars du nom de Darren Davis a écrit il y a quelques années. Maintenant, je suppose que la plupart d'entre vous n'ont jamais entendu parler de Darren Davis, ce qui est plutôt le but de la conférence de ce soir. Euh, nous reviendrons sur qui était et qui est Darren Davis, euh, un peu plus tard. Mais je voulais m'assurer que vous mettiez un visage sur un nom, euh, dès le départ. Nous avons eu un petit débat avant cette conférence, quelle image est la meilleure ? Euh, il aime celle de gauche, j'aime celle de droite, c'est pourquoi nous avons inclus les deux. Voici donc Darren, et la raison pour laquelle vous devez connaître Darren et qui est Darren. euh, parce que Darren était un un senior manager dans une entreprise appelée Corbus, C O R B I S, une entreprise appelée Corbus à Seattle. euh, en 2006. Euh, et euh, Darren faisait partie de ce qu'on appelait une équipe de euh, support, euh, chez Corbus. Alors, le support, c'était le support, du moins dans le sens de Corbus, ce que le support signifiait, c'était, euh, de petites corrections, de petites améliorations, vous savez, euh, des correctifs pour des problèmes de production, des choses comme ça. C'était donc finalement une équipe du type « maintenir les lumières allumées ». Cette équipe se réunissait et était responsable de euh, de, vous savez, des logiciels en production, en s'assurant qu'ils étaient opérationnels et fonctionnaient bien. Euh, le processus de support en 2006, si nous remontons jusqu'en 2006. Le processus de support à cette époque ressemblait, euh, probablement le plus à ce que vous pourriez connaître comme un processus en cascade. Ils ont fait, euh, je crois trois ou quatre versions par an, ils ont essayé, euh, ils ont essayé de faire une version chaque trimestre de toute façon. Euh, ils avaient une grande planification en amont pour ce qui allait être inclus dans cette version, une fois leur grande planification faite en amont, cette portée était fixe et toute l'équipe devait se diriger vers ce calendrier. Euh, et comme vous pouvez l'imaginer, ils n'ont presque jamais respecté leur date de sortie. Euh, ils finissaient presque toujours par réduire la portée, euh, et presque toujours les clients n'obtenaient pas ce qu'ils voulaient quand ils le voulaient, n'est-ce pas ?
[00:03:57] Alors Darren et son équipe se sont réunis et ont été chargés de, euh, du travail de réparation de ce processus. Parce que, en général, leurs clients n'étaient pas satisfaits du déroulement du support. Certaines personnes qui faisaient partie de cette équipe, euh, une personne, vous en avez peut-être déjà entendu parler, Dominique De Grandis. Euh, je crois qu'elle a parlé en France à un autre moment par le passé. Mais Dominica Duranda était dans cette équipe, euh, un autre monsieur du nom de Marc.
[00:04:36] Et enfin, euh, il y avait Rick Garber, euh, qui faisait partie, euh, qui faisait partie de cette équipe. Et c'était Rick, la raison pour laquelle je veux particulièrement mentionner Rick est que, pendant que l'équipe traversait ce euh ce processus. Euh, Rick est allé assister par hasard à une conférence chez Microsoft donnée par un monsieur du nom de David Anderson. Euh, et quand, euh, Rick était à cette conférence, M. Anderson expliquait essentiellement des choses qu'il avait faites, euh, avec une autre équipe chez Microsoft, ce qui était essentiellement tout ce que l'équipe de Corbus essayait de résoudre. Euh, donc bien sûr, cela a éveillé l'intérêt de Rick et il s'est dit : eh bien, euh, tu sais quoi ? Peut-être que nous devrions, nous chez Corbus, commencer à examiner certaines de ces choses que M. Anderson faisait pour nous aider à résoudre nos problèmes. Maintenant, je veux prendre du recul, avant d'aller trop loin. Je veux prendre un peu de recul, je veux m'assurer que tout le monde comprend, euh, à ce moment précis, en 2006. Euh, ce dont David Anderson parlait était entièrement basé sur ce livre. Je ne sais pas, peut-être que des gens ont entendu parler de ce livre, peut-être pas, mais c'était un livre sur la gestion Agile pour l'ingénierie logicielle. Ce n'était en aucun cas du Kanban, et en fait, nous n'utilisions même pas le mot Kanban, vous savez, à cette époque. Mais tout ce travail, tout ce travail initial pour corriger le support chez Corbus, était basé, vous savez, sur ce euh, ce travail particulier. Alors, ce que l'équipe Corbus a fait, c'est que, vous savez, ils ont commencé à, vous savez, euh, à regarder ce qu'il y avait dans ce livre, ils ont commencé à regarder ce qui pourrait potentiellement aider, euh, aider leur processus de support. Et au cours de toutes ces recherches, ils ont fini par embaucher M. Anderson comme directeur principal de l'ingénierie logicielle. Euh,
[00:06:33] Maintenant, encore une fois, je ne saurais trop insister, euh, ce que vous connaissez comme Kanban n'est en aucun cas, euh, ce que nous faisions ce qu'ils faisaient chez Corbus à ce moment-là. Non seulement tout ce à quoi ils pensaient était basé sur ce livre de gestion agile. Mais tout ce qu'ils ont mis en œuvre a en fait été mis en œuvre dans un outil appelé Team Foundation Server. La plupart d'entre vous ont probablement entendu parler de Team Foundation Server, il a connu plusieurs itérations, vous savez, au fil des ans. Euh, mais l'idée était, l'idée était, vous savez, la solution initiale qu'ils ont trouvée. la solution initiale pour le processus de maintenance qu'ils ont mis au point, était, euh, ils ont mis en place un tas de ces, ces, faute de meilleur mot, files d'attente dans TFS, chaque personne de l'équipe, de l'équipe de maintenance, étant responsable de sa propre file d'attente. Et donc ce que vous feriez en tant qu'ingénieur de cette ou en tant que membre de l'équipe de maintenance, ce que vous feriez, c'est que vous vous connecterait chaque jour et que vous regarderiez votre file d'attente. Et de temps en temps, du travail apparaissait dans votre file d'attente, et chaque fois qu'un travail apparaissait dans votre file d'attente, vous deviez prendre ce travail, vous deviez y travailler, vous deviez le marquer comme terminé. Et quand vous faisiez cela, TFS en arrière-plan effectuait toute cette magie avec des transitions et des choses comme ça pour le faire passer à la personne suivante dans le processus. Donc, premièrement, et je dois être très, très clair à ce sujet, il n'y avait aucune visualisation globale. Personne n'avait une vue d'ensemble de ce qui se passait. En tant qu'ingénieur, tout ce que vous voyiez était votre propre file d'attente, et l'idée était censée être que en vous concentrant uniquement sur votre, en ayant des œillères et en vous concentrant uniquement sur votre partie du processus. que le système était censé s'auto-réguler, n'est-ce pas ? C'était juste, vous savez, le travail était censé gérer son propre cheminement à travers le processus. N'est-ce pas ? Bien sûr, vous savez, c'était c'était certainement l'idée. Nous reviendrons sur le succès de cela, euh, vous savez, ou non, peut-être juste un peu plus tard. Mais oui, donc pas de visuel à ce stade, pas de visualisation, pas de définition explicite des limites de travail en cours, pas de bout en bout, personne n'avait une vue de bout en bout de ce qui se passait, n'est-ce pas ? Alors, c'est l'idée, c'est l'idée qu'ils ont eue, euh, chez Corbus. Et donc après avoir travaillé sur cela pendant plusieurs semaines, potentiellement même quelques mois, euh, en novembre de cette année-là. Euh, tout ce design était fait, toute leur configuration initiale de TFS et tout, tout cela était fait. Et Monsieur Anderson a béni le résultat. a dit, hé, c'est exactement ce que je veux, c'est exactement ce dont nous avons besoin pour ce processus de maintenance. Darren, va faire en sorte que cela se produise. Alors,
[00:09:23] Ce que Darren a fait, c'est avec, vous savez, un certain enthousiasme parce que, vous savez, l'équipe était un peu excitée à l'idée d'implémenter toutes ces nouvelles idées. Donc, avec un certain enthousiasme et peut-être juste un peu de fanfare, Kanban a été lancé. Donc nous parlons de la fin de 2006 ici. Donc Kanban est lancé.
[00:09:40] et échoue. Échoue immédiatement. Pendant des mois. D'accord ? Euh, Darren aime dire qu'il y a cette citation que j'aime lui attribuer. Darren aime dire à ce stade que euh, vous savez, dans le cadre de ce ce lancement Kanban, euh, ils fonçaient vers le désastre, euh, mais cela implique beaucoup trop de vélocité.
[00:10:06] La vérité est qu'ils s'arrêtaient progressivement. Donc, dans l'ancien monde en cascade, au moins, ils continuaient à sortir des versions. Ces versions ont peut-être été en retard, elles n'avaient peut-être pas tout ce que leurs clients voulaient, mais elles sortaient quand même des versions. Avec ce tout nouveau système qu'ils avaient mis au point, ils n'étaient même plus capables de publier des logiciels. Tout s'est arrêté. N'est-ce pas ?
[00:10:32] Donc vous pouvez imaginer que les clients ne sont pas très contents de cela. N'est-ce pas ? Et quand les clients se mettent en colère, parce que comme je l'ai dit, avant ils recevaient du travail et maintenant ils ne reçoivent plus nécessairement de valeur ajoutée. Et donc, quand les clients se mettent en colère, ils n'appellent pas Darren Davis, ils n'appellent pas David Anderson. Ils appellent le chef général en charge de cette affaire, le CTO de Corbus, qui à l'époque était un monsieur du nom de Stephen Gillette. Donc Stephen Gillette reçoit tous ces coups de fil de clients en colère. Et donc Stephen convoque Darren. Darren est convoqué dans le bureau de Stephen. Et Stephen fait asseoir Darren et lui dit, Tu sais quoi ? Quelqu'un va devoir réparer ce processus, ou je vais devoir virer quelqu'un. N'est-ce pas ? Et vous pouvez imaginer, vous pouvez imaginer l'état d'esprit de Darren quand il est assis dans le bureau du CTO, disant, hé, je vais devoir virer quelqu'un. Darren pensait que la menace implicite était que son emploi était en jeu. Maintenant, il s'est avéré que c'était M. Anderson qui a fini par être licencié un peu plus tard, mais c'est pour un tout autre euh, un autre moment et une autre conversation. Donc ce n'était pas le travail de Darren qui était en jeu, c'était en fait le travail de David qui était en jeu.
[00:11:48] Alors Darren s'en va. Et il dit, il est comme, ok, nous, nous, nous devons résoudre ce problème, n'est-ce pas ? Nos clients ne reçoivent pas de valeur, même quand ils ne reçoivent pas de valeur, il n'y a aucun moyen pour nous d'aller voir où est cette valeur, où cette valeur est bloquée, vous savez, ce qui ce qui se passe, n'est-ce pas ? Alors, ce que Darren et l'équipe décident de faire.
[00:12:08] ils ont décidé de se réunir et ils se sont dit, vous savez quoi, euh, pour réparer ce processus. Dominica lève la main et dit, nous devrions peut-être commencer à faire quelque chose appelé un standup. N'est-ce pas ? Maintenant, rappelez-vous, Corbus était un peu dans ce monde en cascade, ils ne faisaient rien qui puisse ressembler à des pratiques agiles, non pas qu'un standup soit nécessairement une pratique agile ou non, mais, euh, Alors Darren, Dominica est comme, vous savez, essayons, essayons de faire quelque chose appelé un stand-up. Euh, et Darren était comme, et l'équipe, le reste de l'équipe était d'accord, oui, vous savez, c'est une excellente idée, réunissons-nous chaque jour et parlons de ce que nous allons faire. Euh, et il a été décidé que Darren serait celui qui animerait le standup. Maintenant, pendant le week-end, avant qu'ils ne commencent les standups. Darren commence à y penser, il est comme, d'accord. Nous allons faire le stand-up, mais de quoi allons-nous parler ? N'est-ce pas ? Alors souvenez-vous, j'ai dit, il y a TFS et puis il n'y a rien, n'est-ce pas ? Donc l'idée de Darren est, vous savez, nous devons. Nous devons visualiser ces choses. Nous devons faire connaître notre travail et, vous savez, là-bas et, vous savez, pour que tout le monde le voie, vous savez, nous devons avoir cela. cette vision unique de bout en bout de ce qui se passe, parce que je ne vais pas me lever. et devant un ordinateur, vous savez, commencer à afficher différentes files d'attente dans TFS et à faire un stand-up de cette manière. Alors il se dit, mettons un tableau blanc et nous discuterons de l'état de notre travail et nous discuterons de tout problème bloquant. Euh, c'est maintenant que notre héros entre en scène. Je sais que vous vous demandez probablement, euh, quand notre héros entrera dans l'histoire. Donc c'est à peu près à cette époque, euh, un peu par hasard à cette époque. euh, que j'étais chez Corbus en tant que consultant indépendant, euh, et je donnais un cours sur la modélisation de couleurs. Euh, certains d'entre vous ont peut-être déjà entendu parler de modélisation de couleurs, de modélisation de domaine, vous savez, c'est là que cette idée que, euh, vous savez, les objets dans un modèle prennent certains archétypes, et quand ils prennent certains archétypes, ils, euh, ils se connectent les uns aux autres de manière répétable et prévisible. Ce n'est pas important pour l'instant. Ce qu'il est important de savoir, c'est que, vous savez, la puissance de la visualisation de la modélisation des couleurs et l'utilisation de la couleur comme l'une de ces dimensions pour communiquer cette visualisation. Kirk Kwami, euh, se trouvait dans cette, euh, dans ce cours de modélisation de couleurs, et il faisait également partie de cette équipe de support. Alors à ce moment-là, Kirk a levé la main et a dit, Eh bien, tu sais quoi ? Si nous avons du mal à visualiser et à savoir comment le visualiser, pourquoi ne pas simplement prendre un tableau blanc et y coller des post-it de couleur et utiliser cela pour gérer notre travail ? Euh, et c'est exactement ce qu'ils ont fait. Donc vous pouvez voir que ceci est une image du euh, du tout premier tableau Kanban. C'est l'une des toutes premières itérations. Je ne sais pas si c'était la toute première, euh, mais c'était une très, très ancienne itération du premier tableau Kanban. Et vous pouvez voir que c'est assez rudimentaire. Euh, mais tous les aspects de Kanban sont là en termes de visualisation et de limitation du travail en cours et de choses comme ça. Et, euh, ça a évolué non seulement, ce n'est pas resté brut. parce qu'en utilisant Kanban, ils ont appris et ils ont évolué, et donc vous pouvez voir. ils sont passés de cette version d'un tableau à cette version plus meilleure d'un tableau. Vous pouvez voir beaucoup plus clair, beaucoup plus évident ce qui se passe, vous savez, des choses comme ça.
[00:15:36] La transformation a été si réussie qu'il a été décidé que, vous savez quoi, nous allons prendre ce processus Kanban. et l'appliquer au-delà de la simple maintenance, car à ce moment-là, il ne s'agissait que de maintenance, et nous allons essayer de l'appliquer à l'ensemble de notre département d'ingénierie, euh, tout entier.
[00:15:55] C'est donc là que notre héros revient. Notre héros est rappelé, euh, et donc mon travail, quand je suis retourné chez Corbus, un certain temps après que l'affaire de la maintenance ait été terminée. était de prendre tout ce que Darren et son équipe avaient fait et de l'appliquer au travail de produit ou de projet, n'est-ce pas ? Donc ce n'est plus seulement un travail de maintenance. C'est comme, comment faisons-nous cela ? Euh, Corbus essayait à l'époque de monter en puissance sur deux projets très, très complexes, euh. L'argument pourrait être fait qu'il est potentiellement trop complexe. Euh, mais euh, Corbus était en train de faire évoluer son équipe d'ingénieurs à l'époque, euh, vous savez, ils passaient par, euh, vous savez, une équipe d'environ, vous savez, environ 6 à 12 individus utilisant un moteur assez ad hoc, je pense que ce qui pourrait être décrit au mieux comme un processus d'ingénierie ad hoc. Euh, et ils essayaient d'augmenter cela à environ 60 ingénieurs, euh, donc, vous savez, 10, vous savez, cinq à 10 fois la taille de l'équipe, ainsi qu'un tas d'autres consultants qu'ils ont fait venir. Mon travail était donc de m'asseoir et cette photo est avec certains des chefs d'équipe de l'époque. En fait, ces individus, c'est une autre chose importante à souligner. Ces individus à l'époque, dans l'ancien processus d'ingénierie Corbus, étaient appelés architectes. Leur titre de poste était en fait architecte. Mais dans cette nouvelle façon de travailler, ils allaient être appelés chefs d'équipe, euh, parce qu'ils avaient les connaissances du domaine et l'attente était qu'ils mettraient en place leurs propres équipes ou sous-équipes, sous-équipes si vous voulez, euh, vous savez, pour faire ce travail. Alors nous avons changé leur non seulement nous avons changé leur titre de poste, nous avons changé leurs, euh, vous savez, leurs responsabilités tout de suite, dès le tout début. Alors, Nous avons littéralement réuni l'équipe à cause de cela. Nous avons réuni l'équipe et nous avons dit, d'accord, oublions comment vous travaillez en ce moment. Oublions ce processus ad hoc. Vous n'êtes plus des architectes, vous êtes maintenant des chefs d'équipe, réunissons-nous et décidons comment nous voulons travailler. Et nous avons fait essentiellement la même chose que Darren avec l'équipe de maintenance, c'est-à-dire que nous avons détourné un tableau blanc vierge, euh, et en équipe, nous avons fait un brainstorming sur ce que ce processus allait être. Euh, Alors, vous savez, je veux je veux que vous pensiez à cela en ce moment. Peut-être ceux d'entre vous qui connaissent Kanban ou qui ont entendu parler de Kanban avant. Vous remarquerez une sorte de fil conducteur commun entre toutes ces choses. Il n'y a pas eu de point de départ avec là où vous en êtes maintenant. C'était dans les deux cas, c'était plutôt : piratons un tableau blanc vierge et décidons comment nous voulons travailler. Maintenant, est-ce que cette façon de travailler que nous voulons avait une certaine ressemblance avec la façon dont ils travaillaient maintenant ? Eh bien, oui, en quelque sorte, vous savez, parce qu'ils utilisaient TFS et des choses comme ça, mais pour la plupart. nous n'étions pas entravés par l'obligation de commencer là où nous en sommes, nous devons respecter les responsabilités actuelles, nous devons rechercher un changement évolutif incrémental, nous n'avons rien fait de tout cela. N'est-ce pas ? Rien de tout cela avec le avec le premier ce premier tableau Kanban. Euh, Et vous pouvez aussi voir, vous pouvez en quelque sorte voir les résultats, vous savez. C'est donc cette équipe à grande échelle dont je parlais, euh, et remarquez tous les visages souriants et joyeux et des choses comme ça. Euh, vous savez, ce fut un succès formidable, même si nous n'avons pas fait, et je dirais que ces choses n'ont jamais fait partie, entre guillemets, de Kanban. Euh, la plupart d'entre vous savent que je ne peux pas faire une présentation sans mentionner le type de service. Euh, parce que c'est, vous savez, la classe de service est quelque chose, euh, qui est je pense souvent mentionné avec Kanban. même si encore une fois, cela n'a vraiment, vraiment, vraiment jamais fait partie du Kanban. Ce sont les mots de Darren Davis, d'ailleurs, ce ne sont pas les miens. Je veux juste que ses mots, vous savez, soient consignés. En ce qui concerne le niveau de service, il dit : ne le faites pas. C'est comme, vraiment, vraiment, ne le fais pas. Euh, chaque fois que nous avions ces accélérations ou ces choses qui apparaissaient, ils nous appelaient ces fluctuations et ces flux qui finissaient par aggraver les choses, et non les améliorer. Presque toujours, chaque fois qu'un nouveau type de classe de service apparaissait ou qu'un nouvel élément de travail, vous savez, basé sur un expéditeur ou une date de correction ou autre, cela finissait presque toujours par tout gâcher. Et en conséquence, nous avons fait tout ce que nous pouvions pour ne pas accélérer le travail. En fait, c'était notre objectif déclaré de concevoir notre processus de manière à ce que le travail s'écoule le plus rapidement possible à tout moment, afin qu'il n'y ait jamais besoin d'accélérer quoi que ce soit. Euh,
[00:20:30] et bien sûr, les demandes basées sur des dates ont également été éliminées très tôt, car nous avions un flux assez prévisible et parce que nous avions, euh, à l'époque ce que nous appelions un SLA. Euh, maintenant je pense que SLE est un bien meilleur langage, euh, en termes de temps que prenaient les éléments pour s'écouler dans le processus, nous n'avions même pas besoin de ces demandes basées sur des dates. Donc toutes ces choses de classe de service, non seulement elles ne faisaient pas partie du Kanban, mais nous avons tout fait pour ne pas les utiliser, vous savez, alors voici peut-être ma photo préférée.
[00:20:59] photo de euh de toute la présentation. Vous pouvez voir sur ce tableau, il n'y a pas de couloir d'accélération. Il n'y a pas, il n'y a rien de tout cela. Donc pour récapituler, et je veux être très, très clair à ce sujet. tous ceux d'entre vous qui ont travaillé avec Kanban ou qui ont, euh, vous savez, une quelconque compréhension de ce que vous pensez que Kanban pourrait être. Euh, des choses comme, comme je l'ai dit avant, vous savez, commencer là où vous en êtes maintenant, euh, vous savez, respecter les rôles actuels, euh, poursuivre le changement évolutif. Rien de tout cela, rien de tout cela ne faisait partie de Kanban. En fait, le premier système Kanban n'avait absolument aucune visualisation, il n'avait pas de réglage explicite des limites de travail en cours, toutes ces choses que vous pensez savoir sur Kanban, n'étaient en fait pas le résultat d'un seul individu. que vous pourriez penser qu'ils l'étaient, mais qui étaient en fait le résultat de cette équipe. cette équipe de soutien chez Corbus, qui s'est réunie, euh, et a développé ces techniques, et leur seul but était simplement d'améliorer leur travail, d'améliorer leurs vies. Et il s'est avéré que cela a évolué en cette autre chose, ce que je, ce que je trouve merveilleux. D'accord. Alors, pourquoi est-ce important ? Pourquoi est-ce que j'en parle même ? Pourquoi, c'est il y a 14, presque 15 ans, vous savez, qui s'en soucie vraiment ? Euh, vous savez, la réponse courte est que ce n'est vraiment pas si important. Euh, je veux dire, et dans le grand schéma des choses, en cette ère de pandémies mondiales, d'injustice raciale, vous savez, vous savez, de conflits économiques, quand nous pensons à toutes les choses auxquelles nous faisons face en ce moment, qui se soucie vraiment de ce qui s'est passé. vous savez, dans une équipe chez Corbus il y a 15 ans. Euh, et c'est en grande partie vrai. Cependant, euh, cela dit, toutes ces choses que je viens de mentionner concernant ce que vous pourriez associer à Kanban. Je crois juste que c'est d'une importance cruciale, premièrement, je crois juste qu'il est d'une importance cruciale de rendre à César ce qui appartient à César. Euh, vous savez, ce sont les gens qui ont fait que cela se produise. Il y a d'autres personnes ici comme Diana Kolet, qui était chef de projet, Doug Burrows, qui est ingénieur de build dans l'équipe, Tom Oderback. Ce sont les personnes qui se sont réunies. qui ont fait que Kanban a vu le jour, le Kanban que je pense que vous connaissez et aimez en ce moment, vous savez, euh, Ce sont eux qui ont eu les idées, euh, qui ont eu le, euh, le courage initial de faire les choses qu'ils devaient faire. Et le truc, c'est que ce n'est pas, je ne veux pas, je ne veux pas l'exprimer de la mauvaise manière, mais.
[00:23:39] ce n'est pas, ce n'est pas une coïncidence si vous n'avez jamais entendu parler de la plupart de ces gens avant. Vous savez, il y a eu. Je crois, euh, qu'il y a eu une tentative systématique de faire en sorte que leurs contributions soient soit ignorées, minimisées, banalisées, soit purement et simplement volées. N'est-ce pas ? Les idées qu'ils ont eues n'ont jamais été attribuées à eux. euh, ou en fait volé. Donc, premièrement, je pense qu'il est important que.
[00:24:04] les personnes qui ont réellement fait le travail devraient en être créditées, n'est-ce pas ? Et il est grand temps qu'ils obtiennent le crédit qu'ils méritent. Mais plus important encore, euh, bien que seulement légèrement, euh, la communauté Kanban au fil des ans, je pense, a un peu perdu son chemin. Euh, il y a eu une nouvelle fois une tentative d'usurper, euh, ce qu'est vraiment Kanban et ce qu'il devrait être, et surtout ce que la communauté devrait représenter. Je suppose, encore une fois, à mon avis. Et le fait est que je veux, quand je pense à une communauté Kanban, vous savez, je veux une communauté qui soit réellement au bénéfice de tous et non pas seulement au profit d'un seul. Vous savez, quand nous parlons de, vous savez, avoir ces gens qui se réunissent pour que leurs idées, euh, soient prises au sérieux, euh, je pense que c'est d'une importance cruciale. De plus, vous savez, je veux une communauté où les gens se sentent en sécurité pour participer. Vous savez, à l'abri de tout harcèlement sexuel, à l'abri de toute intimidation. Libre de, vous savez, de l'inquiétude dont je parlais avant que leurs contributions ne soient minimisées, banalisées, ou même purement et simplement volées. Vous savez, je veux je veux une communauté où il y a un endroit sûr, un endroit sûr, inclusif, diversifié où les gens peuvent se réunir et apprendre sur Kanban, euh, et il ne s'agit pas nécessairement seulement de remplir les poches d'un seul individu. Euh, je veux aussi une communauté qui reconnaisse qu'aucune méthodologie unique. ou cadre n'a le monopole de toutes les bonnes réponses. Si souvent, nous nous perdons dans des débats sans fin, des débats sans fin sur l'utilisation.
[00:25:56] autour de ce qui est mieux, Scrum ou Kanban, ce qui est mieux, Safe ou Kanban, ce qui est mieux, peu importe. Qui s'en soucie, n'est-ce pas ? Qui s'en soucie vraiment ? Personne n'a toutes les bonnes réponses. Absolument personne n'a toutes les bonnes réponses. Je pense donc que nous sommes mieux servis en consacrant notre énergie, en investissant notre énergie à construire des ponts plutôt qu'à ériger des murs. Vous savez, créer cet cet espace où nous pouvons tous apprendre ensemble, n'est-ce pas ? Euh, Donc, juste pour faire une petite publicité éhontée, plusieurs d'entre nous dans la communauté se sont réunis et ont lancé une organisation appelée proconban.org. Et encore une fois, tout le but de ce proconban.org est de créer une communauté sûre, inclusive et diversifiée où nous pouvons nous réunir et faire toutes ces choses que euh que j'espère que nous pourrons faire. Si je peux résumer cela en une phrase, c'est ce que j'ai ici : notre objectif est de ramener le professionnalisme au Kanban, n'est-ce pas ?
[00:26:58] Alors j'espère que c'est un peu l'appel à l'action si vous voulez. Euh, j'espère que vous nous rejoindrez pour construire cette communauté que nous désirons tous. Si vous êtes à une conférence comme FlowCon France, euh, je suppose que vous êtes intéressé par des choses comme Kanban. Euh, et si vous êtes intéressé par des choses comme Kanban, vous savez, l'invitation est ouverte à tous, euh, pour nous rejoindre dans cette, euh, vous savez, dans cette tentative. pour revenir là où je pense que nous devons être, vous savez, en tant que communauté. Et rappelez-vous,
[00:27:27] si jamais, jamais, jamais vous avez une chance, si jamais vous êtes de sortie, si jamais vous êtes à une conférence, si jamais vous êtes où que ce soit. Euh, et que vous tombez sur l'une de ces personnes. Euh, je veux m'assurer que, comme je veux le faire maintenant, je veux m'assurer que vous leur dites, dites merci à tous, car je ne pense pas que nous serions là euh sans leurs contributions. Alors,
[00:27:51] merci, merci à toutes les personnes qui ont créé Kanban, à toute l'équipe de Darren et au reste des gens. Merci à Flowcon France pour l'invitation à être ici. Ce fut, vous savez, certainement un plaisir. Merci à notre sponsor de ce soir d'avoir rendu cela possible, comme vous le savez tous, les conférences ne peuvent avoir lieu sans le dévouement et l'aide des sponsors. Mais surtout, merci à vous tous d'avoir pris du temps sur votre emploi du temps chargé, euh, du temps sur votre soirée, euh, pour venir discuter de choses comme comme Kanban et et de processus et peut-être d'histoire ésotérique. Alors.

Transcription (Traduit)