Andréa Provaglio - What Agile can learn from Lean Manufacturing (EN)

[00:00:06] Bonjour. Bonjour. Et c'est probablement 50% de mon français. Ravi de vous rencontrer. Je m'appelle Andrea, Andrea Provaglio. Euh, êtes-vous prêts à commencer ? Avez-vous besoin de quelques minutes de plus ? Vous voulez un café, quelque chose ? Non. Je plaisante. Euh, merci d'être là. Euh, le sujet est un peu inhabituel pour cette conférence. Euh, il s'agit de, disons, comment vous pouvez coexister dans un environnement lean et agile ensemble. Et la raison pour laquelle j'ai décidé de parler de cela est que j'aimerais partager quelques expériences que j'ai eues au cours des trois dernières années, quatre ans, plus ou moins, euh, avec l'un de mes clients. Parce que, vous savez, ce que je fais dans la vie, c'est ça. Je suis un coach, consultant indépendant, euh, peu importe. Euh, et je ne m'attends pas à ce que vous lisiez tout ça, mais vous savez, c'est juste pour vous donner une idée d'où vient mon expérience. Euh, vous pouvez voir certains des clients avec lesquels j'ai travaillé, euh, ou avec lesquels je travaille toujours. Et, euh, et pour vous les gars qui avez un fétiche pour les badges, il y a aussi quelques certifications là. Alors, bref, euh, passons à autre chose. Laissez-moi vous dire pourquoi j'aimerais partager cette histoire avec vous et, j'espère, euh, je ne sais pas si vous êtes d'humeur. Je sais que la salle est grande, vous êtes loin, mais j'aime avoir une conversation avec vous, plutôt qu'une simple présentation avec des questions à la fin. Alors n'hésitez pas à interagir, n'hésitez pas à avoir une conversation. Alors, bref, euh, pourquoi suis-je ici ? Euh, un petit peu d'historique, euh, j'ai passé environ 20 ans de ma vie dans le développement de logiciels. Euh, et j'aidais, vous savez, les gens à écrire de meilleurs logiciels. J'ai travaillé pendant quatre ans aux États-Unis, à San Francisco, aidant la Silicon Valley à écrire de meilleurs logiciels. Euh, alors c'est ce que j'ai fait pendant un certain temps. Euh, et puis, comme je le dis, je me suis en quelque sorte plus intéressé aux formes de vie à base de carbone qu'aux machines à base de silicium. Et donc j'ai commencé à travailler avec des organisations. J'ai commencé à, en gros, les questions que je me posais étaient, eh bien, comment se fait-il que certaines équipes soient si géniales et d'autres pas si géniales, même si les conditions semblent être les mêmes de l'extérieur ? Et puis, des équipes, j'ai commencé à travailler avec des organisations, et donc ce que je fais aujourd'hui, c'est que je suis un conseiller et coach en agilité d'entreprise. Et j'ai toujours été indépendant toute ma vie. J'ai toujours été freelance. J'ai apprécié la liberté, j'ai apprécié la possibilité de faire mes propres choix et la possibilité de dire ce que je voulais dire, même quand quelqu'un était déçu. Euh, mais, comme je le disais, au cours des trois dernières années, parmi d'autres clients, j'ai travaillé avec une compagnie pétrolière et gazière. J'ai travaillé avec, avec une entreprise qui produit ce genre d'appareils que vous voyez là-haut, qui est spécifiquement un régulateur de gaz. Et mais elle a également produit un certain nombre d'autres choses, toutes liées à la distribution de gaz et de pétrole. Alors, comme vous pouvez l'imaginer, c'était un voyage intéressant pour moi, un parcours intéressant, venant du logiciel et finissant par essayer d'aider une entreprise qui crée des choses physiques à devenir plus agile. Et c'est pourquoi je voulais, je voulais partager cette expérience avec vous et peut-être la trouverez-vous intéressante comme je l'ai trouvée. Parce que j'ai appris quelque chose d'eux. Pas seulement, j'espère qu'ils ont appris quelque chose de moi. J'ai aussi beaucoup appris d'eux. Ce fut une expérience qui m'a aidé à regarder l'Agile sous une perspective différente. Alors, bref, cette entreprise est très, très axée sur le Lean. Cette entreprise pratique sérieusement la fabrication Lean depuis 20 ans. Et ce n'est pas une petite entreprise. Ils ont des bureaux partout dans le monde, c'est une entreprise très compliquée. Euh, ils ont traversé un certain nombre d'acquisitions, donc c'est une affaire très compliquée. Mais j'ai fait, ils ont fait de l'Agile, pardon, du Lean pendant deux décennies. Ils ont des senseis japonais qui vont dans l'entreprise tous les mois juste pour euh avancer avec, vous savez, l'amélioration continue et le Kaizen et des choses comme ça. Ils utilisent un certain nombre de techniques Lean différentes, des techniques de fabrication Lean. Et même leurs bureaux sont Lean. Même la façon dont le bureau est aménagé, la façon dont les crayons sont sur le tableau de bord, je veux dire, pardon, sur le, sur le tableau blanc, tout est très, très, très Lean. C'est une culture dans laquelle ils ont beaucoup investi. C'est une culture qui est très, très intégrée dans leur état d'esprit, dans leur façon de travailler. Alors, j'étais, j'étais dans cette situation, j'étais avec cette situation dans laquelle cette entreprise très, très Lean, euh, qui a fait un certain nombre de choses comme ce n'est qu'une simplification, bien sûr, mais ils définissent la valeur, ils cartographient la chaîne de valeur, ils optimisent la chaîne de valeur, ils reçoivent des retours. C'est ce qu'ils font. Euh, et c'est le pilier de leur entreprise, mais ils voulaient aussi être plus agiles, quoi que cela puisse signifier. Et juste pour représenter l'Agile, j'ai choisi la perspective de l'Agile moderne de Joshua Kerievsky. Euh, comme vous pouvez le voir là-haut, vous savez, il s'agit de sécurité et de livraison de valeur et de rendre les gens géniaux, d'expérimentation et ainsi de suite, et ainsi de suite, et ainsi de suite. Alors, je me suis demandé, d'accord, un défi intéressant. Comment pouvons-nous coexister dans le même écosystème si nous avons ces deux perspectives différentes ? Alors, laissez-moi vous donner quelques, laissez-moi partager quelques réflexions avant que nous n'entrions dans les détails de ce que nous avons fait. Et une chose que j'ai apprise en tant que coach Agile au cours des 15 dernières années en tant que coach Agile, c'est qu'il est beaucoup plus difficile que nous le pensons pour les gens de comprendre ce qu'est l'Agile. Du moins c'est mon expérience, vous pourriez avoir une perspective différente, mais c'est mon, mon expérience. Euh, mais laissez-moi vous poser une question. Combien d'entre vous sont dans le développement de logiciels ? Combien d'entre vous écrivent des logiciels ? Ok, pas mal. Oui, merci. Merci. J'avais l'habitude, comme je l'ai mentionné. Euh, alors laissez-moi vous poser une autre question. Euh, avez-vous déjà essayé d'expliquer à votre mère ce que vous faites dans la vie ?
[00:07:18] Avez-vous déjà essayé d'expliquer à votre mère ? Comment ça s'est passé ? Pas bien, hein ? Oui, le mieux que j'ai obtenu de ma mère après quelques années, surtout quand elle parle avec d'autres gens, elle parle avec d'autres gens de ce que je faisais il y a 15 ans. Le mieux que j'ai obtenu d'elle était, oh oui, il travaille sur l'ordinateur. D'accord, c'est la meilleure réponse que ma mère a pu donner. Et cela a beaucoup de sens, je veux dire, cela a beaucoup de sens parce qu'elle n'est pas, c'est une profession très technique, il est très difficile de comprendre ce que nous faisons, surtout parce que nous ne voyons pas ce que nous faisons. Les gens ne voient pas ce que nous faisons. Les gens voient juste d'autres personnes, vous savez, taper sur un clavier. Ce n'est pas comme construire quelque chose de physique, ce n'est pas comme construire un régulateur de gaz. Si vous construisez un régulateur de gaz, vous voyez ce qui se passe. Vous voyez les différents composants, vous voyez la chaîne d'approvisionnement, vous voyez le stockage, vous voyez les choses s'accumuler. Euh, vous voyez les goulets d'étranglement. Thierry parlait tout à l'heure de trouver les goulets d'étranglement. Si vous, si vous avez une ligne de production, il est très facile de voir les goulets d'étranglement parce que les choses commencent à s'accumuler. Ce n'est pas très difficile. Mais pour ce que nous faisons dans le développement de logiciels, il est en fait très difficile de comprendre de l'extérieur ce que diable nous faisons ? N'est-ce pas? Très difficile. Les gens ne voient pas ce que nous faisons. Ils voient les résultats. Ils voient les effets. Ils voient ce qui se passe quand ils utilisent notre logiciel, et surtout ils voient quand notre logiciel ne fonctionne pas comme prévu. D'accord ? Donc quand ils voient le résultat, ils commencent à comprendre ce que nous faisons. Eh bien, j'ai une autre question pour vous. Et la question est, pourquoi pensez-vous qu'Agile est né dans l'industrie très spécifique du développement de logiciels ? Parce que je veux dire, il aurait pu naître dans n'importe quelle autre industrie, n'est-ce pas ? Mais Agile est né dans les années 90 dans l'industrie du logiciel. Une idée ? Une idée pourquoi ?
[00:09:28] Ne soyez pas timides. C'est plus difficile pour moi d'être ici que pour vous d'être là. Allez. Complexité. Complexité. Merci. C'est une possibilité. Oui. Alors, par complexité, je suppose que vous entendez le fait que, euh, les choses changent constamment de manière imprévisible et nous devons nous adapter à ce que nous trouvons ou à ce qui se passe. D'accord ? Merci.
[00:09:57] Euh, quelqu'un d'autre ? Oui.
[00:10:00] Le développement de logiciels est un domaine plus jeune, donc il y a plus de place pour, euh, plus d'initiative et plus de moyens d'innover.
[00:10:09] D'accord. Donc, le développement de logiciels a, disons, moins, euh, de contraintes que le développement physique, le développement de produits physiques, donc vous pouvez expérimenter davantage, vous pouvez innover davantage, il est plus facile d'inventer de nouvelles choses parce que nous n'avons pas la physicalité d'autres produits, n'est-ce pas ? Si vous voulez créer une nouvelle voiture, vous devez composer avec les lois de la physique. D'accord ? Et c'est pourquoi les voitures volantes ne sont pas encore là parce qu'il y a cette petite chose appelée les lois de la physique. Mais en logiciel, vous pouvez faire pratiquement tout à l'intérieur de votre ordinateur, n'est-ce pas ? Donc, c'est une autre possibilité. Oui, absolument. Je suis totalement d'accord avec vous. Alors, et c'est l'idée. C'est l'idée. L'Agile est né dans l'industrie très spécifique du développement de logiciels parce que cette industrie n'existait pas avant. Dans l'histoire de l'humanité, il n'y a jamais eu d'industrie basée à 100% sur le travail cognitif.
[00:11:18] Ce fut la première industrie dans l'histoire de la race humaine où nous pouvions oublier les lois de la physique. D'accord ? Nous pourrions, nous pouvons simplement inventer, innover, nous adapter, explorer et réagir rapidement à tout ce qui se passe. C'est pourquoi Agile est né là-bas. Alors encore une fois, moi, en tant que gars venant du développement logiciel et faisant beaucoup de choses Agile, on m'a demandé de travailler avec une industrie qui était utilisant le Lean. Et le Lean a été créé pour gérer la production de biens physiques, pour optimiser la production de biens physiques. Des choses que vous pouvez voir, des choses que vous pouvez toucher, que vous pouvez compter, que vous pouvez gérer. Quelque chose de très, très, vous utilisez le mot complexité. Je dirais que ceci, si vous, si nous voulons parler un instant, d'accord ? C'est compliqué. D'accord ? Tout ce que nous faisons dans une production de masse est un problème très, très, très compliqué, très compliqué. Ce n'est pas complexe. Espérons que, dans un environnement de production, rien ne génère de surprises. Dans un environnement complexe, vous avez des surprises tout le temps, et c'est la raison pour laquelle c'est complexe. N'est-ce pas ? Donc, encore une fois, deux mondes très différents. Et si nous voulons avoir une sorte de perspective historique de mon point de vue, donc nous avons eu, euh, le système de production Toyota dans les années 60, puis le Lean manufacturing, et ensuite dans les années 80, nous avons commencé à voir les premières lueurs d'une industrie basée sur le développement de logiciels. Et puis ce que nous avons appris en Agile, nous l'avons exporté vers d'autres activités qui sont basées à 100% sur le travail cognitif. Comme le marketing, comme, comme vous pouvez le voir, euh, la recherche et le développement, les RH. Donc l'idée est, d'accord, nous apprenons à gérer la complexité grâce à l'Agile, maintenant nous pouvons exporter ces apprentissages vers quelque chose qui n'est pas du logiciel, mais qui est toujours complexe, intangible, et toujours basé sur le travail cognitif. C'est ce que je pense qu'il s'est passé. Et puis, ironiquement, maintenant, les gars de la production industrielle, disons, s'intéressent également à l'Agile parce qu'ils sont confrontés au problème que le monde change trop vite maintenant. Et les limitations imposées par les contraintes physiques deviennent un problème pour eux. Ils ont donc besoin d'acquérir quelque chose de notre part. Donc, ce que je dis, c'est qu'il y a deux perspectives différentes, et elles sont toutes les deux très, très bonnes. L'une est la perspective de la production matérielle, des biens physiques, un environnement compliqué, basé principalement sur le travail manuel ou le travail automatisé, mais le travail physique de toute façon. Et l'autre perspective est la perspective du travail cognitif, de la complexité, et ainsi de suite, et ainsi de suite. Cependant, et c'est mon expérience en travaillant avec cette entreprise, mais pas seulement celle-ci, même d'autres entreprises qui ne sont pas des entreprises manufacturières. Il y a une métaphore commune euh qui entoure les organisations. Et la métaphore est, notre organisation est une machine de production très bien huilée. Et vous pouvez le voir à la façon dont les organisations sont conçues. Les organisations sont généralement conçues de manière hiérarchique parce que c'est ainsi que nous gérons une machine complexe. Lorsque vous conduisez votre voiture, vous utilisez les pédales, vous utilisez le volant, et peut-être qu'ils changent, euh, mais en fin de compte, ces mouvements très simples que vous faites, ils gouvernent une machine très, très compliquée. N'est-ce pas ? Vous êtes au sommet de l'organisation, qui est votre voiture, et ensuite vous avez un certain nombre de sous-systèmes qui sont gouvernés par ce que vous décidez. Et c'est ainsi que les gens, euh, beaucoup de gens pensent aux organisations, ils n'y pensent même pas. C'est très intégré dans l'état d'esprit industriel que nous avons acquis au cours du dernier siècle ou et ainsi de suite. Euh et donc le fait est que oui, nous avons ces deux différentes, disons, étapes, euh, mais d'après mon expérience, nous pensons toujours beaucoup à des choses industrielles et nous parlons un peu, et c'est l'orateur là-haut, nous parlons un peu d'Agile, mais nous pensons beaucoup en termes industriels. Euh, je vais vous donner un exemple. Comme celle-ci. Je suis désolé si la police est un peu petite, peut-être que l'écran est grand, alors. Euh, c'est un véritable e-mail, euh, c'était un article qui est paru, c'était euh Wired, oui, un article du magazine Wired. Euh, c'est en gros un e-mail qui a fuité d'une entreprise. Je ne vais pas vous dire le nom, mais vous pouvez faire vos recherches si vous voulez. C'est une entreprise de FinTech, et l'e-mail provient du PDG de l'entreprise. Cette entreprise était très jeune et très, euh, disons, agressive dans la manière dont elle voulait évoluer sur le marché. Et je vais juste vous lire ça, avec vous. Je veux souligner l'importance d'atteindre les KPI convenus. Maintenant, si vous y réfléchissez, un KPI est un indicateur clé de performance. Un KPI montre combien de personnes travaillent, pas combien de valeur vous produisez. D'accord, un KPI par définition est l'indication du travail effectué, pas de la valeur générée. D'accord ? Mais de toute façon, ce gars-là insistait sur l'importance d'atteindre les KPI. Et si vous ne le faites pas, si vous ne le faites pas, votre bonus vous sera retiré. D'accord ? Donc beaucoup de commandement et de contrôle, n'est-ce pas ? Ce type menace en gros les gens, vous voulez votre argent, vous devez travailler plus dur. Et si vous lisez le texte, il est également surpris que les gens ne restent pas le week-end pour atteindre les KPI. Et je ne sais pas, je ne connais pas les organisations dans lesquelles vous avez travaillé, mais, euh, j'ai vu ce genre de mauvais comportement un certain nombre de fois, pas seulement de la part de ce gars. Parce que, encore une fois, l'idée est que nous devons produire, nous devons livrer et je contrôle cette machine de production. Même s'ils affirment être agiles, parce qu'ils parlent de product owners et d'équipes, mais ce n'est clairement qu'un rebranding d'autres noms. N'est-ce pas ? Donc, ils ne sont pas du tout agiles, même s'ils prétendent l'être. De toute façon, les choses ne sont pas si mal après tout, car si vous regardez l'Agile bien fait et si vous regardez le Lean bien fait, ils ont une chose en commun. Ce sont tous deux des modes de travail centrés sur l'humain. Il est vrai que le Lean a été conçu davantage pour la production industrielle et pour l'optimisation du travail. Il est vrai que l'Agile a été conçu davantage pour l'adaptabilité, la complexité, le travail cognitif et ainsi de suite, mais ce sont toujours des modèles centrés sur l'humain. La personne est une composante très, très importante de la fabrication Lean. Comme il se doit, d'ailleurs.
[00:19:20] Donc, il y a de l'espoir, c'est ce que j'essaie de dire. Il y a de l'espoir.
[00:19:25] Euh, comment ça va jusqu'à présent ? Est-ce que je vais trop lentement ? Est-ce que je suis trop ennuyeux ? Vous voulez que je Non, c'est bon. Bien. Ok, bien.
[00:18:49] il est vrai que Lean a été conçu davantage pour la production industrielle et pour l'optimisation du travail. Il est vrai qu'Agile a été conçu davantage pour l'adaptabilité, la complexité, le travail cognitif et ainsi de suite, mais ce sont toujours des modèles centrés sur l'humain. La personne est un composant très, très important du Lean Manufacturing, comme il se doit, d'ailleurs.
[00:19:19] Donc, il y a de l'espoir, c'est ce que j'essaie de dire. Il y a de l'espoir. Hum, comment ça va jusqu'à présent ? Est-ce que je vais trop lentement ? Est-ce que je suis trop ennuyeux ? Voulez-vous non, c'est bon. Bien. D'accord, bien. Je veux dire, j'ai des blagues, mais peut-être que je garderai les blagues pour plus tard. D'accord.
[00:19:40] D'accord, alors qu'avons-nous fait avec cette organisation ? Hum, nous avons utilisé Agile dans cette organisation dans diverses situations. Ils ont un service informatique interne, nous avons donc utilisé Agile là-bas. Euh, nous avons utilisé Agile pour certains euh, projets marketing. Nous utilisons Agile dans diverses situations, mais ce que j'ai appris, l'endroit où j'ai le plus appris, c'est quand j'ai travaillé avec des lignes de production. Maintenant, ces gars, comme je vous l'ai dit, ils ne produisent pas la Volkswagen Coccinelle, ils produisent des composants pétroliers et gaziers. Mais l'idée est la suivante : si vous avez une chaîne de production ou une chaîne d'assemblage, ce qui se passe sur la chaîne de production doit être très efficace pour une raison très simple. Parce que vous ne produisez pas une seule pièce et vous avez fini, vous devez en produire des centaines, des milliers ou même plus si vous produisez de petits appareils comme ce microphone, par exemple.
[00:20:39] Vous pourriez vouloir en produire 10 000 en une journée. Vous pourriez vouloir être capable de faire cela. Cela implique donc que vous avez besoin d'une chaîne d'approvisionnement, cela implique que vous avez besoin de stockage et ainsi de suite, et cela implique que le processus doit être très efficace. Parce que même si vous perdez une seconde, mais que vous voulez produire 1000 de ceux-ci, vous perdez 1000 secondes. D'accord ? C'est donc une perte de euh productivité.
[00:21:09] C'est pourquoi le Lean est très, très axé sur l'élimination du gaspillage, la suppression des goulots d'étranglement et des choses comme ça. Parce que vous ne produisez pas seulement un, d'accord, vous produisez beaucoup de biens physiques. Ce qui est différent du logiciel, n'est-ce pas ? En logiciel, vous n'écrivez pas le même code encore et encore. J'espère pour vous. N'est-ce pas ? J'espère pour vous. Euh, vous vous souvenez du film, euh, The Shining avec Jack Nicholson ? Vous vous souvenez de la scène où, avec horreur, la femme découvre qu'il a tapé la même phrase encore et encore sur une pile de papier ? Vous vous souvenez ? D'accord ? Je ne me souviens plus de la phrase, c'était genre, euh, tout travail et pas de jeu rend quelque chose. Bref. Vous vous souvenez de la scène, d'accord, comment j'espère que vous n'écrivez pas de logiciels comme ça. N'est-ce pas ? J'espère que vous devez livrer, euh, votre application à 10 personnes, vous n'écrivez pas l'application 10 fois. J'espère que vous ne faites pas ça. N'est-ce pas ? Mais si vous voulez donner ces microphones à 10 personnes, vous devez fabriquer 10 microphones. Donc vous devez optimiser. N'est-ce pas ? Maintenant, la chaîne de production est fondamentalement un processus. C'est un processus qui, à la fin, produit ce microphone. Vous avez donc un processus qui crée un produit. Mais ensuite il y a un autre processus. Oh, et d'ailleurs, ce processus est Lean. Nous n'avons jamais essayé, nous n'avons jamais eu la moindre idée d'essayer d'introduire Agile sur la chaîne de production. Cela n'a aucun sens. Le Lean est une approche très, très mature qui existe depuis 60 ans et ces gars savent bien faire du Lean. Alors, où avons-nous essayé d'implémenter Agile ? Eh bien, dans ce que j'appelle le méta-processus, parce que la chaîne de production n'est pas quelque chose qui est créé de nulle part.
[00:23:14] La chaîne de production, précisément parce qu'elle doit être hautement optimisée, doit être prototypée. Nous devons expérimenter, nous devons échouer, nous devons essayer de nouvelles solutions, nous devons apprendre. Il existe donc un méta-processus pour générer la ligne de production, qui est le processus qui crée le produit. Et l'agilité a beaucoup de sens à ce niveau, au niveau du méta-processus. Bien sûr.
[00:23:41] Mais cela exige un changement de mentalité chez les personnes habituées à créer ces méta-processus. Parce que dans la culture manufacturière traditionnelle, le méta-processus pour créer le processus est également Lean.
[00:23:56] Ce n'est pas Agile. C'est un processus Lean.
[00:24:01] Et donc, nous avons appris quelques choses là-bas.
[00:24:04] Certaines choses extrêmement importantes dans le lean manufacturing sont la livraison de valeur. Donc vous voulez que votre ligne de production fonctionne en douceur, euh, sans goulots d'étranglement, sans interruptions, garantissant la qualité. La qualité est un autre sujet important de la production. Euh, vous ne voulez pas que vos euh,
[00:24:25] vos produits soient retournés ou vous comprenez le concept de qualité pour un produit physique. Et il y a un autre euh, composant qui est extrêmement important dans le Lean, non seulement parce qu'il est éthique et avant tout parce qu'il est éthique, mais aussi parce qu'il affecte l'entreprise. Et c'est la sécurité. La sécurité des travailleurs. Vous ne voulez pas que vos employés se blessent sur la ligne de production. Premièrement, ce n'est pas éthique, et c'est la chose la plus importante. Deuxièmement, si les gens se blessent et qu'ils restent à la maison, votre production, votre euh, disons, comme on dirait en Agile, votre vélocité va en pâtir. N'est-ce pas ? Parce que vous avez moins de personnes qui travaillent sur la chaîne de production. La sécurité est donc une préoccupation très, très importante pour le Lean. La livraison de valeur, la qualité et la sécurité sont extrêmement importantes. Et je dois dire que lorsque le Lean est bien appliqué, la fabrication Lean est bien réalisée, ces trois aspects sont très bien pris en compte. Je dois aussi dire que dans Agile, nous ne sommes pas très bons en sécurité.
[00:25:37] Nous sommes très bons en Agile en matière de livraison de valeur et Thierry expliquait comment ils cartographiaient leur flux de valeur en essayant de trouver des goulots d'étranglement et des choses comme ça. Hum, lorsque nous sommes prudents dans le développement logiciel et que nous accordons également beaucoup d'attention à la qualité, si vous êtes discipliné, et que vous faites des tests unitaires, du développement piloté par les tests, de l'intégration continue, des tests d'acceptation. Il existe tout un corpus de connaissances autour de l'introduction de la qualité dans les produits non tangibles comme les logiciels. D'accord ?
[00:26:15] Mais la sécurité, nous devons en parler davantage. Et nous y reviendrons dans une seconde. Quoi qu'il en soit, hum, parlons de la livraison de valeur dans euh, dans le Lean.
[00:26:28] Comme je l'ai mentionné, nous devons optimiser le flux de valeur.
[00:26:33] Hum, vous devez éviter la surcharge.
[00:26:37] Encore une fois, c'est quelque chose de très, très visible sur une ligne de production. Si vous voyez un travailleur avec trop de travail à faire, c'est immédiatement visible. Vous voyez cette personne fatiguée, vous voyez cette personne faire des erreurs, vous voyez cette personne se blesser. Il est immédiatement visible lorsque vous surchargez votre processus ou lorsque vous surchargez vos employés, immédiatement visible. Un autre aspect du bon déroulement dans le Lean, bien sûr, est le partage des connaissances. Hum, parce que plus nous comprenons, plus nous connaissons le processus, plus nous pouvons l'améliorer. Et enfin, la détection précoce des défauts. Euh, c'est la raison pour laquelle, dans le système de production Toyota, chaque travailleur a l'autorité et l'autonomie d'arrêter la chaîne de production si la qualité se dégrade. D'accord, ils peuvent arrêter la ligne. Tout le monde peut arrêter la ligne s'il y a un problème de qualité. Immédiatement, immédiatement. Et ils font cela pour une raison très simple et c'est la même chose pour les logiciels. Euh, le coût de correction d'un défaut augmente exponentiellement plus vous êtes loin du point où le défaut, où le défaut a été introduit. En d'autres termes, corriger un bug lorsque le logiciel a été publié aux utilisateurs est incroyablement plus cher que de corriger le bug une minute après avoir écrit ce code. Et c'est pourquoi nous essayons de détecter les défauts le plus tôt possible.
[00:28:20] En Agile, nous essayons de faire tout ce qui précède, comme je viens de le mentionner. Hum, sauf que notre travail est généré à 100% par le travail cognitif. Le produit est généré par le travail cognitif. Et cela signifie que nous devons le rendre visible. Nous avons besoin et c'est la raison pour laquelle j'ai adoré la présentation de Thierry et j'ai adoré qu'il ait montré des post-it lorsqu'il a représenté le flux de valeur.
[00:28:50] Ce n'était pas une sorte de, vous savez, benchmark ou de graphique, haut, bas, des choses comme ça. C'était quelque chose de très, très physique et tangible. Il est bien mieux de rendre un travail intangible visible en utilisant un support physique plutôt qu'une autre chose intangible comme un affichage. D'accord, comme un affichage numérique.
[00:29:19] Hum, et c'est pourquoi j'ai écrit en théorie là-bas. Vous essayez de le rendre visible. Mais il y a des outils qui ne nous aident pas.
[00:29:29] Être Agile. Je ne veux pas citer de noms. D'accord. Euh, ce n'est pas poli quand j'ai un Microsoft dans la main. Mais nous connaissons tous des outils qui vous cachent des informations. N'est-ce pas ? Surtout les outils australiens.
[00:29:49] D'accord ?
[00:29:51] Ils ont tendance à vous cacher des informations plutôt qu'à les rendre visibles. Par exemple. La qualité est un autre sujet intéressant. Parce que comme je l'ai dit, dans le Lean, la qualité est vraiment multidimensionnelle. Quand ils parlent de qualité, ils parlent de la qualité du processus, de la qualité du produit, de la qualité perçue par l'utilisateur, de la qualité perçue par le travailleur. Donc, ils parlent de qualité d'une manière très holistique. Et puis encore une fois, la qualité peut être immédiatement observée, peut être immédiatement vérifiée, très très facile à faire. Hum, en Agile, la qualité est plus insaisissable. Il n'est pas facile pour un produit immatériel de euh, déclarer si la qualité est suffisante. Bien sûr, si votre logiciel ne se comporte pas comme prévu et génère des résultats incorrects ou des problèmes pour les utilisateurs, il est clair que la qualité n'est pas si bonne.
[00:30:56] Mais il y a une grande zone grise dans le logiciel concernant la qualité. Lorsque vous demandez à quelqu'un, d'accord, est-ce que c'est suffisant ?
[00:31:03] Différentes personnes peuvent avoir des opinions différentes.
[00:31:08] Et en termes de qualité technique, encore une fois, dans le développement logiciel Agile, en théorie, nous avons une qualité inculquée et soutenue par le processus que vous choisissez. Hum, si vous utilisez XP, par exemple, la programmation extrême, la programmation extrême est très, très attentive à la garantie de la qualité, même le pair programming. Le pair programming est un moyen de garantir la qualité. Parce que vous avez deux personnes qui regardent le même code en même temps, donc vous êtes moins susceptible d'introduire des défauts que lorsque vous êtes seul. C'est donc une boucle de rétroaction rapide, un système de contrôle qualité. D'accord, si vous le faites.
[00:31:55] Hum, et puis toutes les techniques que nous connaissons, les trucs techniques que nous faisons. Et c'est exactement ça.
[00:32:05] Hum, une chose que la fabrication Lean peut apprendre d'Agile est l'importance de l'agilité technique. En tant que développeurs de logiciels, au cours des 30 dernières années, nous avons créé un certain nombre de techniques très sophistiquées pour être agiles au niveau technique. Alors, qu'est-ce que cela signifie d'être Agile au niveau technique ? Cela signifie être capable de s'adapter au changement avec grâce. J'aime le terme « avec grâce » parce que cela ne signifie pas à coût zéro, chaque fois que vous changez quelque chose, cela va vous coûter quelque chose, mais cela peut être horriblement difficile et horriblement cher.
[00:32:49] Ou cela pourrait être plus facile à faire et pas si cher. Donc, tout l'intérêt de l'agilité technique est de pouvoir accepter le changement avec grâce. Donc des choses comme euh, des objets mock, par exemple, ou des conteneurs d'inversion de contrôle, toutes ces techniques ont été conçues par des personnes qui voulaient pouvoir accepter le changement avec grâce.
[00:33:17] Et la raison pour laquelle j'ai choisi cette image spécifique est que c'est un exemple de solution architecturale techniquement agile. Euh, c'est un bureau. D'accord, vous voyez les bureaux. Et ce que vous voyez au plafond, ce sont des câbles d'alimentation. D'accord ?
[00:33:38] Cela signifie donc que vous pouvez réorganiser ce bureau quand vous le souhaitez. Vous n'avez pas les alimentations électriques, les prises de courant au sol ou autour des murs. Si vous pouvez réorganiser les tables quand vous le souhaitez avec très peu de coût et d'effort. Tout ce que vous avez à faire est de descendre le câble d'alimentation là où vous voulez placer les tables maintenant. Point. Vous pouvez avoir de l'alimentation et de la connectivité réseau partout. C'est une solution technique. Probablement que la mise en œuvre de cette solution a coûté un peu plus cher que d'avoir simplement des prises au mur, mais elle vous offre une agilité technique. Cela signifie que vous pouvez changer l'utilisation de cette pièce à très peu de frais plus tard. Et c'est tout l'intérêt de l'agilité. Vous savez que le changement va arriver. Vous ne savez juste pas quand. Vous ne savez pas quoi. Vous ne savez pas combien.
[00:34:39] D'accord ? Juste trois petites choses. Vous ne savez pas quand, vous ne savez pas quoi, vous ne savez pas combien. Mais le changement arrivera. Si vous êtes dans un environnement Agile. D'accord, si vous utilisez Agile pour gérer la complexité. Mm. Donc l'agilité technique est essentielle. Et pour être honnête, hum, les gars du Lean manufacturing pourraient apprendre hum quelque chose de nous. Parce que moi, quand je travaillais avec les mécaniciens par exemple, ou les électriciens, euh, qui créaient les chaînes de production, leur approche est toujours de faire
[00:35:19] euh, les choses aussi bon marché que possible. Mais cela ne signifie pas que ce que vous ne payez pas aujourd'hui, vous devrez le payer 10 fois plus cher plus tard si vous devez changer quelque chose dans votre produit. Si le produit change, vous devez changer la ligne de production. Si cela change la ligne de production, c'est compliqué, c'est cher, cela prend beaucoup de temps, vous perdez quelque chose, n'est-ce pas ? Donc l'agilité technique est quelque chose qu'ils peuvent apprendre de nous.
[00:35:47] Ah, alors le déjeuner est à 1h45, n'est-ce pas ? Je suis donc très conscient que je me tiens entre vous et votre nourriture, alors je ne serai pas en retard, je le promets. Mais la sécurité est une autre chose intéressante. Comme je l'ai mentionné, la sécurité est essentielle dans le Lean. Nous ne voulons pas que quiconque se blesse. Pas immédiatement, ou cela pourrait aussi être une maladie professionnelle comme, par exemple, l'ergonomie. D'accord, laisser les gens travailler de manière ergonomique.
[00:36:24] Parce que puisque nous créons le même produit encore et encore, les gens devront faire le même mouvement, par exemple, des centaines de fois par jour. Et nous voulons être sûrs que ces mouvements que les gens font ne blessent pas ces personnes. D'accord, donc l'ergonomie du travail est très importante, pas seulement le fait que je ne me blesserai pas dans un accident. Dans Agile, cela m'a donné beaucoup de matière à réflexion concernant Agile, car je ne pense pas que dans Agile nous nous soucions suffisamment de la sécurité. Hum, et la raison est très simple. Parce que nous travaillons avec des produits intangibles, parce que ce que nous faisons n'est pas visible. Il est très, très facile de travailler dans un environnement non sûr, dans un environnement dangereux. Par exemple, il est très, très facile de surcharger les gens de trop de travail. Parce que vous ne voyez pas le travail.
[00:37:28] Si quelqu'un vous dit, même si vous faites du Scrum et que quelqu'un vous dit, et que vous n'utilisez pas bien Scrum, et que quelqu'un vous dit, d'accord, nous avons besoin de ces, vous savez, 10 fonctionnalités ou de ces 20 user stories prêtes dans ce sprint. Et vous dites, eh bien, vous savez, notre vélocité est généralement de sept user stories, maintenant nous avons besoin de 20 cette fois. D'accord ? Hum, ce serait très différent si chaque user story était une boîte, n'est-ce pas ? Si c'était une boîte, une boîte physique, vous pourriez dire, eh bien, vous voyez, nous n'avons pas, nous ne savons même pas où placer ces boîtes. Elles sont trop nombreuses. D'accord ? Mais si ce ne sont que, vous savez, des tickets dans un outil que vous utilisez, il est très facile de surcharger les gens. Il est très facile, euh, maintenant que vous travaillez à distance, il est très facile de ne pas remarquer si quelqu'un ne se sent pas bien, si quelqu'un est trop stressé, est débordé, parce que nous ne parlons plus maintenant, n'est-ce pas ?
[00:38:29] Hum, sur le lieu de travail, nous avions l'habitude de prendre des pauses café ensemble. Nous avions l'habitude de parler, comment allez-vous ? Comment ça va pour vous ?
[00:38:37] D'accord ? Mais maintenant, tout ce que nous avons, c'est, vous savez, des appels d'équipe, des appels Teams ou Zoom ou tout ce que vous utilisez, et tout est très efficace. Et dans certaines entreprises avec lesquelles je travaille, j'ai vu des gens en réunion, en réunions en ligne, vous savez, consécutives toutes les heures, vous savez, pendant trois ou quatre ou cinq heures d'affilée. Il n'y a donc plus la possibilité pour les gens de euh, partager comment ils vont, comment ils se portent. Nous ne nous soucions donc certainement pas assez de la sécurité des travailleurs du savoir. Il est facile de les surcharger, il est facile de négliger euh, leur état. Et donc vous obtenez du stress, vous êtes épuisé, épuisé, vous avez de l'anxiété, vous avez un certain nombre de problèmes physiques et psychologiques, parce que nous ne nous soucions pas de leur sécurité. Et c'est une chose que j'ai apprise du Lean. Prenez soin de la sécurité des gens.
[00:38:49] travailler avec, j'ai vu des gens être en réunion, des réunions en ligne, vous savez, consécutives toutes les heures, vous savez, pendant trois ou quatre ou cinq heures d'affilée. Il n'y a donc plus la possibilité pour les gens de partager ce qu'ils font, comment ils vont. Nous ne prenons donc manifestement pas bien soin de la sécurité des travailleurs du savoir. Il est facile de les surcharger, il est facile de négliger, euh, comment ils vont. Et donc vous êtes stressé, vous êtes épuisé, vous avez un burnout, vous avez de l'anxiété, vous avez un certain nombre de problèmes physiques et psychologiques, parce que nous ne nous soucions pas de leur sécurité. Et c'est une chose que j'ai apprise du Lean. Prenez soin de la sécurité des personnes. C'est une chose que j'ai apprise d'eux, pas eux de moi.
[00:39:40] Alors, euh, au fait, nous n'avons pas, j'ai j'ai j'ai introduit quelques diapositives ici juste au cas où vous seriez intéressés. Euh, je vais passer très vite sur ces diapositives, mais l'un des problèmes que j'avais, comme vous, je ne sais pas si vous essayez, si vous commencez à comprendre le problème que j'avais. Le problème que j'avais, c'est que je travaillais avec deux cultures différentes. Il y a une culture d'optimisation, une culture d'efficacité et ainsi de suite. Et il y a une autre culture, qui est une culture d'adaptabilité, d'exploration, de prise de risques, ne sachant pas ce qui se passe demain. D'accord. Deux cultures très différentes. Donc, l'un des problèmes que j'avais, euh, était de, comment, d'améliorer la compréhension mutuelle. Et donc j'ai j'ai j'ai commencé à penser aux métaphores, comme des concepts métaphoriques. Euh, parce que les métaphores sont très, très puissantes. Nous pensons en termes de métaphores, nous voyons le monde en termes de métaphores. Comme cette métaphore est très populaire.
[00:40:48] Vous comprenez ? Oui, le temps, c'est de l'argent. Métaphore très populaire. D'accord. Je ne sais pas si vous êtes d'accord, mais vous avez entendu cette métaphore : le temps, c'est de l'argent. Maintenant, quand quelqu'un dit que le temps, c'est de l'argent, il ne veut pas dire littéralement que le temps, c'est de l'argent. D'accord, vous ne pouvez pas payer votre facture de gaz avec du temps, vous devez la payer avec de l'argent. D'accord, donc le temps n'est pas de l'argent. En même temps, les gens pensent au temps comme si c'était de l'argent. C'est pourquoi nous avons des expressions comme passer du temps. Vous passez votre temps. Nous avons des expressions comme nous investissons notre temps. Nous avons des expressions comme nous perdons du temps. D'accord. Ce sont tous des verbes économiques. Investir, dépenser, gaspiller, quelque chose comme ça, vous voyez ? C'est pourquoi les gens pensent en ces termes et cela signifie qu'ils perçoivent la réalité à travers cette métaphore. Qu'ils investissent du temps, qu'ils dépensent du temps et ainsi de suite, et ainsi de suite. Et quand vous voyez le monde à travers certaines lentilles, alors vous agissez et vous parlez en fonction de votre perception. Et la façon dont vous agissez et dont vous parlez influence les mots que vous utilisez et ainsi de suite, et ainsi de suite. C'est donc une sorte de boucle, n'est-ce pas, c'est une boucle infinie.
[00:42:14] Alors une chose que j'ai essayé de faire pour eux, c'était de, euh, d'essayer de créer un langage, un langage commun basé sur des métaphores. Pour m'assurer que ces deux cultures différentes pouvaient commencer à communiquer au même niveau. Maintenant, je ne vais pas passer en revue toutes les choses ici, mais si vous voulez plus d'informations, je serai heureux de les fournir, euh, contactez-moi simplement sur LinkedIn. Je vous donnerai les références plus tard. Mais de toute façon, j'ai commencé à créer une compréhension commune en utilisant le langage. Euh, je vais vous donner un exemple. Euh, les gens utilisent le mot équipe très à la légère. D'accord. Oh oui, nous avons une équipe qui travaille là-dessus. Puis vous allez chercher et vous voyez que l'équipe est en fait composée de trois gars qui passent 30% de leur temps à différents moments.
[00:43:07] À différents moments, euh, ils travaillent sur quelque chose et ils n'interagissent pas vraiment. Parce que ces 30% ne sont jamais ensemble. D'accord. Mais nous utilisons le terme équipe. D'accord. Maintenant, si nous avons une petite discussion et que nous disons, d'accord, écoutez, il y a un groupe de travail. C'est comme, euh, comme les les travailleurs que vous vous faites venir pour rénover votre maison, parfois vous avez le plombier, parfois vous avez l'électricien, d'accord, c'est un groupe de travail. Et une autre chose est une équipe, une équipe est comme une équipe sportive. Ils se soutiennent, ils travaillent ensemble, ils jouent ensemble, ils souffrent ensemble, ils gagnent ensemble. Donc, deux choses différentes. Il suffit de clarifier la métaphore, équipe sportive, plombier, d'accord, est un moyen de, euh, d'aider à la compréhension, à la compréhension mutuelle. Euh, ces diapositives sont juste un zoom sur différents aspects. Nous avons des modèles organisationnels, nous avons des modèles opérationnels, nous avons des modèles commerciaux. Culturel et c'est tout. Encore une fois, je voulais juste mentionner ceci brièvement, mais si le sujet vous intéresse, n'hésitez pas à me contacter ici ou sur LinkedIn, qui est le seul réseau social que j'utilise. Et je serai heureux d'interagir. Hum, alors qu'ai-je appris en travaillant avec eux ? Une chose que j'ai apprise, c'est qu'il est inutile de penser en termes de dichotomies.
[00:44:38] Euh, avoir cette approche manichéenne, ce qui signifie ceci est bon, ceci est mauvais, euh, ceci est bien ou ceci est, euh, hum,
[00:44:49] C'est beau, c'est moche et des choses comme ça. Ce que vous voyez à l'écran est essentiellement une recherche que j'ai faite sur un moteur de recherche. J'ai juste tapé lean versus agile. Et vous avez comme 1 000 articles sur le lean versus agile. Il n'y a pas de lean versus agile, il y a le lean et l'agile. D'accord. Et si vous êtes intelligent, vous pouvez les assembler. D'accord. Euh, ou vous pouvez utiliser l'un ou l'autre, mais il n'y a pas, je veux dire, penser en termes de l'un ou de l'autre n'est certainement pas quelque chose qui aide à comprendre et à utiliser ce genre de choses. L'autre chose, une autre chose que j'ai apprise est les gens dans le lean et donc, les gens avec un état d'esprit industriel et puis encore une fois, l'état d'esprit industriel est beaucoup plus enraciné dans notre société que nous le pensons généralement. Donc, les gens avec cet état d'esprit, ils pensent en termes de mesure de choses.
[00:45:47] Comme, vous savez, les KPI. Les KPI sont excellents si vous voulez mesurer combien de pièces sortent de la ligne de production par heure. Merveilleux KPI. D'accord. Mais ils ne sont jamais, jamais une représentation directe de la valeur. Et donc ce que nous devons faire, c'est parce que dans Agile, nous nous concentrons davantage sur la valeur livrée. Plutôt que des choses livrées. D'accord. Les OKR peuvent fonctionner mieux dans certaines situations. Objectifs et résultats clés, je suis sûr que beaucoup d'entre vous ont entendu le terme. Mais les objectifs et les résultats clés sont beaucoup plus adaptés aux travailleurs cognitifs que les KPI qui ont été conçus pour les machines. Un KPI est un indicateur clé de performance d'un processus. D'accord. Vos gens ne sont pas un processus. Les idées, l'intention, les ambitions, les expériences, ne sont pas un processus. Vous ne pouvez pas utiliser de KPI dans cet environnement spécifique. L'autre chose est que lorsque vous définissez les attentes trop tôt, ce qui est une autre chose que les gars de la production Lean sont désireux de faire. Euh, comme, oui, nous devons, nous devons redessiner notre ligne de production, et nous voulons avoir notre délai d'exécution attendu, euh, c'est un terme technique ou autre, et ainsi de suite et ainsi de suite. Eh bien, le problème est que, lorsque vous, lorsque vous prenez toutes les décisions importantes au début, hum, il ne reste pas beaucoup d'agilité. Parce que si vous prenez toutes les décisions importantes au début, alors vous n'êtes qu'une liste de choses à faire. Et j'ai vu cela dans le développement logiciel également. Euh, j'ai travaillé avec une entreprise financière. Et une autre était une entreprise d'énergie. Ils ont souffert du même problème même s'ils sont dans des domaines différents. Alors, laissez-moi l'expliquer ainsi. Alors, à un moment donné, quelqu'un a eu une idée brillante. Et donc ils ont passé du temps à explorer cette idée si elle avait du sens en termes de marché. Et puis ils ont décidé que oui, ils voulaient financer l'idée. Alors ils commencent à monter le projet. Ils commencent à définir les objectifs du projet par rapport au budget qu'ils veulent dépenser. Et puis ils commencent à analyser le problème en détail. Et puis à un moment donné, ils engagent l'informatique. D'accord. Et puis le département informatique travaille en Agile et donc dans cette zone ici. Ils font des sprints, ils font ce qu'ils veulent, ils sont très agiles ici. Et puis la chose est mise en test final.
[00:48:41] Et puis c'est livré. Et puis ça donne des résultats sur le marché. D'accord. Et puis d'ici à là, c'est 18 mois.
[00:48:51] 18 mois, c'est la boucle de feedback. 18 mois sur un marché, sur un marché qui évolue à la vitesse que vous pouvez voir. Et l'agilité n'était que là.
[00:49:02] C'est là qu'ils avaient de l'agilité. Et pourquoi cela ? Parce que toutes les décisions importantes ont été prises là-bas. Ils ont pris toutes les décisions importantes, ce qu'ils pensaient être les décisions importantes là-bas, et ces gars, ils n'ont que la liste d'épicerie.
[00:49:18] Ces gars-là, ils reçoivent juste une liste de choses à implémenter, point final. Et l'expérience dure 18 mois. D'accord. Pas un merveilleux exemple d'agilité. Hm. Et c'est donc une autre chose que j'essaie d'enseigner en fait aux personnes lean et aux personnes agiles. L'autre chose est que se concentrer sur la quantité que vous produisez n'a rien à voir avec se concentrer sur la quantité de valeur que vous générez. Je lisais un article il y a quelques jours sur une banque australienne qui a essayé d'adopter Agile il y a cinq ans.
[00:49:59] Et euh, ça a horriblement mal tourné. Euh, l'une des choses qu'ils ont essayé d'améliorer était leur service de prêt immobilier. Et leurs concurrents, les petites banques, vous accordent généralement un prêt en sept jours. D'accord. Donc le processus de la demande à l'obtention du prêt est d'environ sept jours. Ces gars après leur transformation agile ont pris 51 jours. D'accord. Compétition sept jours, ces gars 51 jours. D'accord. Et ça a empiré quand ils ont essayé d'implémenter Agile.
[00:50:42] Pourquoi cela ? Eh bien, il faut lire entre les lignes, mais une déclaration qu'ils ont faite. Une déclaration que le PDG faisait, euh, lors de plusieurs entretiens au cours de l'année. Une déclaration était, oui,
[00:50:57] nous avons 10 000 transactions Jira par mois. D'accord.
[00:51:07] Métriques complètement inutiles. Il ne s'agit pas du nombre de transactions que vous avez par mois en termes de commits Jira. D'accord. Il s'agit de la valeur que vous délivrez au bout de la chaîne. N'est-ce pas ? Vous mesurez la mauvaise chose, vous mesurez le résultat, vous ne mesurez pas l'impact. Et d'ailleurs, c'est aussi une métrique qui est très, très facile à manipuler. D'accord. Si vous, si je dis en tant que développeur, si vous, hum, évaluez ma performance basée sur les transactions Jira, je vais vous dire quoi. Je peux avoir 10 000 transactions Jira par mois, par jour. Je peux écrire un bot qui génère des transactions Jira, si c'est ainsi que vous m'évaluez. D'accord.
[00:51:57] Donc, c'est une autre chose. Et je pense que nous avons presque terminé.
[00:52:02] Et l'autre chose importante, c'est la gestion. Qu'ils doivent passer de l'état d'esprit lean, qui est je suis l'expert, je sais tout et je suis là pour vous dire ce que vous devez faire. De passer de cela à : je suis là pour vous aider. D'accord. Si vous évoluez dans un environnement très adaptable, l'expert n'a pas toujours la solution. Parce qu'il ne pourrait pas y avoir une seule bonne solution, il pourrait y avoir plusieurs solutions différentes. Aussi bon ou aussi mauvais. D'accord. Ainsi, l'approche de l'expert fonctionne très, très bien dans un système compliqué, dans un environnement compliqué. Mais un style de leadership de soutien fonctionne beaucoup mieux dans un environnement complexe car il permet plus de, euh,
[00:52:57] pour un environnement plus sûr pour expérimenter et échouer. Alors j'ai fini, en gros. Euh, donc ce que j'ai essayé de vous dire, c'est que le lean et l'agile peuvent coexister avec des intentions différentes. Euh, le lean est bon pour l'épine dorsale de la production, il est bon pour la stabilisation, même l'organisation formelle est très bonne car elle donne de la structure à l'entreprise. Et puis pour tout le reste, euh, comme les réseaux informels de personnes, l'apprentissage, l'expérimentation, le partage des connaissances et ainsi de suite et ainsi de suite. Agile fonctionne très bien. Et si je dois revenir à la photo initiale de ma présentation, l'échange de cadeaux, je pense que ce sont les cadeaux. Que les deux disciplines différentes peuvent échanger l'une avec l'autre. Alors, une chose que le lean peut donner à, hum, à l'Agile est de, oh pardon, je
[00:53:58] Non, c'est bon, c'est bon. Une chose que l'Agile peut apprendre peut enseigner au, euh, au lean est d'être techniquement agile et d'avoir une approche différente de, euh, de la gestion. Désolé, j'ai juste appuyé sur le mauvais bouton. Je suis, et c'est tout, en gros. Alors, comme je l'ai dit, je suis très conscient que je me tiens entre vous et votre déjeuner et je n'ai aucune intention de me mettre en travers. Alors, merci beaucoup. Je serai disponible pour les questions même pendant l'heure du déjeuner. Et merci beaucoup.

Transcription (Traduit)