The Lean Tech Manifesto

0:00 Certains sont à la poursuite du diamant vert, alors pardonnez les rêves un peu boomers, rapport à l'âge. Lui, il est plutôt à la recherche du secret de l'agilité à grande échelle. Vous voyez de qui je veux parler ou pas? Un peu? Bon. Il s'agit de Fabrice Bernhard, notre Indiana Jones à nous, celui de la tech qui va nous dévoiler The Lean Tech Manifesto. À la manière d'un aventurier, il a exploré Amazon, Apple, et Tesla pour créer un manifeste qui combine l'in-thinking, thinking, j'ai répété plusieurs fois ce TH qui est toujours très compliqué en fait, quand on est plutôt d'origine portugaise, on a plutôt un cheu chez nous et là c'est un the, c'est pas toujours évident. L'in-thinking et autonomie des équipes, j'essaie de faire deux trois vannes mais j'ai pas tellement de réception ce matin, j'ai l'impression. Merci quand même, voilà. Donc ça va être 40 minutes avec Fabrice Bernhard de découverte, suivi évidemment, ça ne vous aura pas échappé, de 10 minutes de questions-réponses.

1:08 Voici donc sous vos applaudissements, nourri Fabrice Bernhard, qui est le co-founder et CTO de Theodo. Et voilà ! Alors Fabrice, je te laisse éventuellement la zapette. Je suis juste là, si tu as un problème, ne m'appelle pas. Bonjour à tous. Nous avons tous ici probablement été inspirés par les startups tech à la fin des années 90, début des années 2000, qui avaient une façon de travailler complètement différente. Je me rappelle encore de cet envoyé spécial où on voyait les bureaux de Google avec un toboggan. Je vous avoue que j'ai hésité à démarrer cette intervention en nous rappelant à tous que nous ne sommes plus tout jeunes. Mais déjà, je ne suis pas le premier, parce qu'il y a déjà eu des références à Indiana Jones et le diamant vert. Et je me suis aussi dit que c'était une preuve de résilience à nous tous d'avoir été inspirés par ces startups tech il y a plus de 20 ans.

2:12 Et d'avoir traversé des transformations dans l'industrie, et d'être toujours là et de réfléchir aux transformations de demain. Toujours est-il, ces startups étaient incroyablement inspirantes dans leur façon de travailler, mais elles étaient aussi incroyablement performantes, parce qu'elles ont réussi à disrupter leur industrie, Google dans les médias, Amazon dans le retail, Airbnb dans l'hôtellerie par exemple. Et donc tout le monde a commencé à se demander mais qu'est-ce qui fait leur différence? Et il se trouve que c'était à ce moment-là que plusieurs des pionniers de l'industrie du l'eau qui avaient réfléchi à travailler différemment, et donc qui avaient réfléchi à différentes méthodes pour faire du logiciel différemment, se sont retrouvés tous ensemble un week-end dans l'Utah, et ont cherché les principes communs, les principes qu'ils partageaient tous, et qu'ils ont réussi à identifier quatre principes. Et qu'ils ont appelé ça le manifeste agile. Et donc c'est comme ça qu'en fait cette transformation de façon de travailler qui permettait d'aller beaucoup plus vite, d'être plus innovant, s'est retrouvée à être associée au terme agilité.

3:23 Et donc sans surprise, Cette idée d'être à la fois plus autonome au niveau des équipes et d'être plus innovant, plus résilient aussi au niveau de l'organisation, c'est quelque chose qui a rapidement séduit toutes les organisations dans le monde. Donc ça, c'est un sondage assez récent de Deloitte où 94% des leaders interrogés disent que l'agilité est critique pour le succès de leur entreprise. Mais dans le même sondage, seuls 6% des leaders interrogés disent qu'ils considèrent avoir réussi à devenir très agiles. Et donc effectivement, c'est un des sujets qu'on a constaté assez rapidement chez Theodo, quand on a vraiment compris ce que c'était l'agilité, c'est qu'en fait, dans certains contextes, Et c'était indépendant de la taille de l'organisation, parce qu'on était capable, dans... pour Safran ou pour BNP, à construire des produits en quelques semaines, 6 semaines, 8 semaines, en faisant des itérations d'une semaine avec les utilisateurs finaux.

4:25 Donc non seulement on allait très vite, mais en plus, à la fin, comme on avait co-construit le produit avec les décideurs métiers et avec les utilisateurs finaux, on avait une adoption qui dépassait complètement les attentes. Mais à l'inverse, dans des contextes très différents, où il y avait des dépendances techniques, il y avait des sujets de compliance, il y avait des sujets de régulation, il y avait des besoins de se connecter, de s'intégrer à des architectures qui n'étaient pas du tout prévues pour, là on pouvait être aussi agile qu'on voulait. Ça nous a pris 18 mois pour sortir la première application en prod en suivant les... standard de sécurité qui était nécessaire. Et donc, une des premières idées que j'ai envie de vous partager aujourd'hui, c'est que pour trouver des solutions à l'agilité à l'échelle, en fait, il faut sortir du cadre du manifeste agile. Parce que le manifeste agile a été conçu par des personnes qui réfléchissaient à comment bien travailler au sein d'une équipe de développeurs et n'a jamais été pensé pour une grande organisation. Je pense que c'est suffisamment important pour regarder un peu, principe par principe, pourquoi ça ne fonctionne pas pour nous guider en tant que leader à implémenter de l'agilité dans nos organisations.

5:37 Le premier, c'est« individuals and interactions over processes and tools». L'idée que forcément pour être innovant, si on commence à tout de suite mettre en place des process ou à figer des outils, ça ne va pas du tout marcher. Dans une petite équipe, il suffit de se parler, ça marche beaucoup mieux. Mais en fait, cette idée fonctionne avec un nombre d'individus quand même assez restreint parce que le nombre d'interactions possibles augmente au carré du nombre d'individus. Et donc assez rapidement, déjà avec une douzaine d'individus, on se retrouve avec une soixantaine d'interactions possibles. Et puis dans une organisation comme Amazon, un million d'individus, on se retrouve avec des centaines de milliards d'interactions possibles. Donc ça ne fonctionne pas pour expliquer comment réussir à innover. Working software over comprehensive documentation, donc l'idée d'arrêter de passer autant de temps en conception, à écrire des documents de plusieurs centaines de pages de documents, et qu'en fait on peut adresser les problèmes de qualité de délivrerie en faisant des petits incréments. Pour ça, j'essaie de modéliser le logiciel de façon très simpliste. C'est une branche if avec deux choix. On voit une branche if, ça a deux chemins possibles.

6:40 On voit assez rapidement qu'en fait, quand on combine plusieurs branches, le nombre de chemins possibles augmente de façon exponentielle. Avec trois branches, on a déjà huit chemins possibles. Et en fait, assez rapidement, si on considère qu'un logiciel, c'est quand même déjà des milliers de chemins possibles, Chaque incrément, aussi petit soit-il, va rajouter des centaines, voire des milliers de nouveaux chemins. C'est très dur de gérer les problèmes de qualité juste en se disant« je rajoute des petits incréments». Là, j'ai caché un bug dans le logiciel. Je ne sais pas si vous le voyez. Il n'est pas très gros. Ensuite, il y a Customer Collaboration of a Contract Negotiation. C'est un truc qu'on a vraiment trouvé fascinant au début, quand on mettait pour la première fois le client dans l'équipe tech. C'était magique. Non seulement ça permettait d'aller beaucoup plus vite, mais ça permettait aussi d'arriver à des solutions vraiment plus créatives, parce qu'on confrontait les deux points de vue et on trouvait des solutions auxquelles on n'aurait jamais pensé initialement. Ensuite, dès qu'on pense à ce même principe à l'échelle, on a un premier problème qui est qu'on ne voit pas trop comment on va démultiplier la personne au sein de toutes les équipes.

7:44 Et puis ensuite, la personne, assez rapidement, quand on travaille avec des grandes organisations, c'est plusieurs parties prenantes, plusieurs stakeholders. Et un des gros sujets, c'est justement de réussir à les coordonner parce qu'ils ne sont pas représentés par une seule personne. Finalement, responding to change over following a plan. qui représente probablement le plus la résilience dans le manifeste agile, l'idée qu'une petite équipe qui est en direct avec ses utilisateurs est capable de sentir les changements du marché et la mieux placer pour réagir à ces changements. Dès qu'on imagine ça à très grande échelle, On se dit que si une grande organisation peut entièrement réagir à la moindre détection d'un changement par une équipe, on imagine plus des mouvements de foule et donc les catastrophes que cela peut engendrer. Et ce qu'on constate, c'est plutôt l'inverse, c'est-à-dire que les organisations décident de ne pas du tout bouger. Donc là, forcément, ça pose la question de comment font les organisations qui arrivent à garder une forme d'agilité à grande échelle. J'ai vu des gens qui pensaient que l'agile à grande échelle n'est pas possible.

8:45 C'est quelque chose auquel nous, on n'a jamais cru, parce qu'on voyait bien qu'il y avait des organisations qui arrivaient quand même à faire de l'hypercroissance, rester très innovants et pas forcément garder leur toboggan dans leur bureau, mais quand on se renseignait sur les façons de travailler à l'interne, il y avait quand même encore beaucoup d'autonomie au sein des équipes. Et puis après, on a des exemples qui sont encore plus extrêmes, par exemple Linux, où on voit quand même un projet open source où il y a eu plusieurs dizaines de milliers de contributeurs et qui ont été bénévoles. Donc forcément, on n'aurait jamais contribué si ça avait été une énorme bureaucratie. Et donc on s'est demandé qu'est-ce qui caractérise ces organisations. Et donc, on a pas mal regardé, étudié ce qui se faisait, et on a découvert deux choses. Deux choses que j'ai envie de vous partager. La première, c'est à quel point, et ça, ça nous a vraiment étonnés d'ailleurs, à quel point on retrouvait la pensée Lean souvent dans ces organisations. Et donc, par exemple, on découvre que quand Steve Jobs se fait virer d'Apple et crée sa deuxième boîte qui est Next, en fait, une des choses qu'il fait, c'est

10:00 justement les innovations managériales qui se passent au Japon, il fait directement appel à Duran, il se fait coacher par le docteur Duran. Et donc le docteur Duran, c'est quelqu'un qui en fait était allé au Japon après la seconde guerre mondiale pour partager toutes les innovations managériales autour du management de la qualité, qui étaient des innovations à l'époque américaine, mais l'Amérique, ayant une économie qui marchait très bien, n'était pas très intéressée par ces sujets-là. Et donc en fait, il est parti avec Deming au Japon. Et ils ont partagé ces idées qui ont été très bien reçues. Ils se sont retrouvés à partager ces idées avec le dirigeant de Toyota, avec les futurs fondateurs de Sony et plein de leaders de l'industrie japonaise. Déjà d'une part, et puis d'autre part, Deming et lui sont restés au Japon et ont vraiment aussi appris ensuite de l'implémentation de ces idées dans les différentes entreprises, dont Toyota. Et donc, en fait, Duran revient du Japon avec vraiment cette énorme expertise pour cette méthode de management japonaise qui, à l'époque, ne porte pas encore le nom de Lean.

11:02 Et coach Steve Jobs sur ces sujets. On a une vidéo qui date de 1990 où on découvre que Steve Jobs a vraiment été formé sur des principes très profonds et très intéressants de la pensée Lean. Un autre entrepreneur de la tech iconique qui a évidemment une énorme influence sur ce qu'on considère être l'agile à grande échelle, c'est Jeff Bezos chez Amazon. Effectivement, on apprend qu'il s'est non seulement formé à la méthode Toyota, autour des années 2000. Est-ce qu'il y a des anecdotes assez rigolotes? Par exemple, l'implémentation de ce qu'il appelle un gros bouton rouge dans le service client pour permettre à n'importe quel opérateur au téléphone d'arrêter la vente d'un produit s'il pense qu'il y a trop de défauts sur cette gamme de produits. Et en fait, il va passer ça à l'échelle en recrutant ensuite Marco Netto, un Français d'ailleurs, en 2006 comme VP of Operations, et qui a été formé au Lean chez GE par Ching U Jutsu, par Nakaosan, donc vraiment la source,

12:06 et qui va déployer ça dans toute la logistique d'Amazon, et qui va se faire coacher par Nakaosan, qui va amener Jeff sur le Gemba, sur le terrain, comme on dit en ligne, pour se faire former par Nakaosan. Donc ça c'est une première chose qu'on a constaté, c'est qu'en fait la pensée Lean était beaucoup plus présente que ce qu'on n'aurait jamais imaginé en fait dans ces organisations qui étaient assez emblématiques de l'agile à l'échelle. Alors là quand on s'arrête là, souvent la communauté agile ou surtout la communauté Lean dit« bon voilà, ça démontre ce que j'ai toujours pensé, c'est que le Lean c'est l'agile en mieux». Mais il y a une deuxième idée qu'on a découvert en fait en étudiant ces organisations. C'est l'importance de la technologie dans le fait de créer des organisations beaucoup plus distribuées. Comme on est dans des métiers qui sont très fortement dématérialisés, ce qu'on constate, c'est qu'il est possible, en étant malin, en utilisant bien la technologie, de beaucoup mieux distribuer nos organisations. Deux exemples un peu extrêmes de ça, c'est par exemple le projet Linux.

13:10 Le projet Linux, aujourd'hui utilisé par 4 milliards de personnes, entre autres utilisé par Android. Qui démarre dans la chambre d'étudiants de Linus Torvalds et qui assez rapidement se retrouve à avoir plusieurs centaines de contributeurs, à un moment passe par des crises de scaling où effectivement tout passe par Linus et ça devient un goulot d'étranglement qui est insupportable. Et donc les voix s'élèvent dans la communauté pour dire qu'il faut des couches de management. Il faut, Linus, que tu délègues une partie de ton travail. Et Linus a dit non, je n'ai vraiment pas envie de résoudre ce problème par une organisation pyramidale. J'ai envie de trouver une meilleure solution et j'aimerais bien qu'on travaille plus en réseau. Et je vous fais la version courte, mais la version courte c'est qu'en fait, un des membres de la communauté avait créé un outil qui s'appelait BitKeeper, qui était un gestionnaire de code source distribué. Et qui n'est pas open source, donc il y a pas mal de réticences à l'adopter, mais finalement Linux arrive à l'imposer au sein de la communauté Linux, et du jour au lendemain,

14:14 la plupart des problèmes de scale qu'ils ont sont complètement résolus, parce que ça permet de distribuer le travail de merging, et donc à avoir une organisation qui fonctionne beaucoup plus en réseau. Si vous n'avez jamais entendu parler de BitKeeper, c'est normal, C'est parce qu'à un moment, Larry, le créateur de BitKeeper, a menacé de rendre la licence payante. Et là, Linus s'est dit que c'était suffisamment critique pour le succès de Linux qu'il a pris quelques semaines de vacances pour recoder une alternative open source. Et le résultat, c'est Git. Que nous utilisons tous aujourd'hui. Donc si jamais vous croisez Linus, surtout ne le fâchez pas pour ne pas qu'il construise votre concurrent open source. Et un autre exemple assez iconique, encore une fois, Sur cette thématique de la technologie qui permet de rendre les organisations plus distribuées, c'est le API Mandate d'Amazon. Au début des années 2000, Amazon, comme nous l'avons probablement tous vécu, est un énorme monolithe. Tout devient très difficile.

15:15 Ils n'arrivent plus du tout à gérer leurs problématiques de scaling. Et avec des exemples assez caricaturaux, du genre, il faut soumettre une demande de changement de base de données au comité de la base de données qui se réunit quelques fois par mois. Donc, ça peut prendre plusieurs mois pour juste rajouter une colonne à la base de données. Et aussi sur les projets transverses, un peu la même idée, dès qu'on veut intervenir sur du code de quelqu'un d'autre, en fait il faut faire un business case de pourquoi notre projet est beaucoup plus prioritaire que les autres projets. Il y a une sorte de gros rendez-vous trimestriel pour décider qui sont les projets prioritaires. Et évidemment le problème c'est que non seulement il y a de fortes chances que son projet ne soit pas accepté, donc on se retrouve à ne pas pouvoir faire ce qu'on a besoin de faire pour réussir ses objectifs business. Et à l'inverse, au contraire, on dit que c'est le projet du voisin qui a été choisi. Donc non seulement c'est dur déjà de réussir tes objectifs business, mais maintenant il faut que tu consacres une partie de ton temps au projet de l'autre. Donc voilà, un système évidemment qui ne marche pas. Mais le génie de Jeff Bezos à ce moment-là, c'est de se dire que le but ce n'est pas de communiquer plus et de se coordonner plus, il faut qu'on réduise le besoin de coordination.

16:19 Et donc pour ça, il démarre un énorme chantier de réarchitecture d'Amazon. Pour aller vers une architecture beaucoup plus orientée service et avec une idée très intéressante qui est de se dire en fait non seulement on veut rendre l'architecture plus modulaires pour que les équipes sur chaque module soient plus autonomes. Mais en fait, on va travailler à faire vraiment des interfaces de très haute qualité, des API vraiment de très très bonne qualité, parce que c'est comme ça qu'on va vraiment avoir les bénéfices où chaque équipe va être en self-service par rapport aux données des autres équipes, plutôt que de devoir s'appeler encore pour dire j'ai envie de me connecter à ton service à toi. Et évidemment, non seulement cette révolution API chez Amazon a redémarré l'hypercroissance d'Amazon, mais en plus, cette idée qu'on pouvait accéder à n'importe quoi par API a à un moment inspiré certaines équipes pour se dire, mais en fait, maintenant, on arrive même à... À accéder à des nouveaux serveurs par API. Et donc, c'est ce qui a inspiré le cloud, qui est quand même une énorme source aujourd'hui de revenus et de rentabilité d'Amazon. Donc quand on a constaté que ces entreprises, ces organisations qui avaient réussi à garder une forme forte d'agilité à grande échelle, on s'est mis à fond là-dedans.

17:30 Et donc déjà, on est allé à toutes les conf tech, Tech.Rocks, Velocity, pour apprendre des géants de la tech et comprendre mieux ce qu'ils faisaient. Et puis, on a beaucoup étudié le Lean. Donc, on a lu des livres, on a fait des gambas. C'est un mot Lean qui vient du japonais pour dire on est allé sur le terrain. On a échangé avec des pairs qui étaient dans la même démarche, c'est-à-dire comment est-ce qu'on peut apporter la pensée Lean dans nos organisations tech. Et on s'est fait accompagner par les meilleurs sensei de France. On a de la chance, je pense, en France, d'avoir parmi les meilleurs sensei du monde, d'ailleurs. Et on est même allé jusqu'au Japon pour étudier le Lean à sa source. Et en fait, c'est passionnant parce que, à la fois, c'est des univers complètement différents des nôtres, mais en fait, on arrive à adapter assez facilement les principes quand on les voit en action sur le terrain. Et on s'est dit qu'on allait capturer tous ces apprentissages après avoir étudié tout ceci pendant dix ans et avoir justement utilisé ces idées pour grandir notre organisation de 10 à 700 personnes aujourd'hui.

18:33 Et on allait les capturer dans un livre. Et une des idées fortes, c'était de se dire qu'on a envie de construire sur le manifeste agile, sur le génie du manifeste agile, qui arrive quand même très bien à capturer ce qui est l'essence d'une équipe agile, pour essayer de bien capturer l'essence d'une organisation agile. Alors, quand on a fait 10 ans de Lean, déjà, et qu'on prend le manifeste agile, la première chose qu'on constate, c'est qu'il y a un petit problème parce qu'on ne démarre pas par le client. Et donc, effectivement, la première chose qu'on a faite, c'est de réordonner le manifeste agile pour mettre la valeur client en premier. Et ensuite, on s'est dit, comment est-ce qu'on combine notre compréhension maintenant de la pensée Lean et notre compréhension de comment la technologie peut aider à faire de l'agile à grande échelle pour réécrire ces principes. Et donc voilà ce qu'on a obtenu, qu'on a appelé le Lean Tech Manifesto, et que je vais essayer de vous décrire assez rapidement dans les minutes qui me restent. Déjà, la première valeur, c'est Value for the Customer. Comme je disais au début, Customer Collaboration, ça ne passe pas à grande échelle.

19:34 Par contre, le premier principe du livre Lean Thinking, c'est justement Value for the Customer. Et ça, ça fonctionne très bien parce qu'on peut très bien se dire, OK, je vais faire de la valeur pour le client, l'étoile du Nord de mon organisation. Et ça, ça va permettre d'aligner tout le monde, les parties prenantes et les équipes sur vraiment ce qui compte. Ça va aussi faire travailler toute l'organisation à mieux comprendre ce que c'est la valeur pour le client. qui est un travail permanent. Et puis ça va permettre à toutes les équipes, si on structure ensuite son organisation autour de la valeur client, de comprendre comment elles y contribuent de façon individuelle. Alors quelques exemples concrets, parce que là on est un peu dans les concepts. Concrètement chez nous ça veut dire quoi? Ça veut dire d'aller beaucoup sur le terrain, j'ai beaucoup utilisé le mot Gemba là déjà. C'est en allant sur le terrain qu'en tant que dirigeant, manager, leader tech, on comprend mieux notre compréhension de la valeur pour le client à la réalité du terrain, aux problèmes qui sont rencontrés

20:39 et aux apprentissages que peuvent avoir les équipes qui le pratiquent au quotidien. Un outil qu'on a inventé, c'est l'architecture produit. C'est un management visuel qui permet de mettre en une seule page les différentes contraintes, à la fois clients, fonctionnels et techniques, pour avoir des très bonnes discussions et rendre les équipes beaucoup plus autonomes sur leur stratégie face aux différents trade-offs. Parce qu'il y a forcément des moments, des choix qui vont avoir des impacts ailleurs. Et c'est une façon de beaucoup plus responsabiliser l'équipe là-dessus. Et finalement, beaucoup de management visuel. Donc là, j'ai triché, ça c'est une salle de réunion chez Aramisoto, mais c'est un superbe exemple de management visuel où en fait les équipes d'Aramisoto peuvent voir à tout moment comment... les différents dirigeants de la boîte travaillent à créer plus de valeur client. Et ça permet de communiquer la compréhension de la valeur client et des défis identifiés à toute l'organisation.

21:47 Le deuxième principe, c'est« take and enable network of teams». Individu-interaction, ça ne marche pas parce que le nombre d'interactions augmente au carré. Un des vrais défis, c'est de se dire comment j'arrive à réduire, à garder ce nombre d'interactions possibles faible malgré la croissance. C'est là où on voit que créer des architectures modulaires et utiliser des API est une façon de réduire ces dépendances et donc réduire la complexité. Et de créer des poches d'autonomie pour les équipes sur le terrain. Concrètement, j'en ai parlé, c'est créer des architectures modulaires, faiblement couplées, pour avoir cette ownership sur les différents modules, comprendre l'importance de faire des bons modèles de données et des bonnes API, parce que c'est comme ça qu'on crée vraiment une culture du self-service et du self-discovery. Une des anecdotes qu'on a apprises de Marco Netto, c'est que Jeff Bezos avait un rituel où il regardait les API. lui-même, parce qu'il avait compris que c'était un sujet sur lequel il fallait mettre beaucoup d'intensité.

22:52 Une autre anecdote, c'est un de nos coachs Lean qui est parti chez Google et qui nous disait« c'est incroyable, j'ai très rarement besoin de collaborer finalement, parce qu'à chaque fois que j'ai besoin d'une donnée, j'y vais. accès en toute autonomie. Et effectivement, pour parler, là c'est des sujets très tech, mais en fait c'est des sujets qu'on peut appliquer pas que sur la partie tech. Par exemple, tout ce qui est une data platform, c'est le service qui va permettre à n'importe qui dans l'organisation d'avoir accès à la donnée dont elle a besoin pour faire ses analyses et prendre ses décisions. Ça c'est un screenshot de notre looker chez nous, branché à notre Bitcoin. Ensuite, write first time and just in time. Donc oui, faire des petits incréments, ça ne suffit pas à adresser les problèmes de qualité et de delivery à très grande échelle. Par contre, pour le coup, Toyota a inventé un truc qui s'appelle le Toyota Production System. Ils ont des décennies d'expérience à faire de la production avec une qualité très supérieure et beaucoup plus rapidement que tous leurs concurrents à très grande échelle. Et donc les deux piliers du Toyota Production System, c'est Right First Time, bon du premier coup.

23:58 Et Just-in-Time, le juste-à-temps, et qui est un ensemble de principes qu'on peut appliquer à la tech et qui sont passionnants pour justement produire du code de meilleure qualité et le livrer de façon plus continue. Alors, quelques exemples concrets. Un des sous-principes de ces principes, c'est le J2K, c'est l'idée qu'on arrive à détecter les défauts le plus tôt possible et à arrêter la production à ce moment-là. Donc là, je vous donne un exemple. C'est assez simple. C'est un exemple de l'Inter où, en fait, grâce à du typage, C'est du JavaScript ou c'est du TypeScript? Bref. Grâce à du typage, on arrive à voir rapidement qu'il y a un bug possible dans cette ligne de code avant même de l'avoir commité. Ensuite, le dentotou, c'est le mot qu'on utilise pour parler de la culture d'analyser les défauts de façon systématique, et vraiment de les analyser sur comment on aurait pu ne pas les introduire et comment on aurait pu les détecter plus tôt. Et ça, ça permet effectivement aux équipes d'apprendre en permanence de leurs défauts, et puis petit à petit de voir des patterns et donc de pouvoir adresser certaines routes causes de façon définitive.

25:01 Et sur la partie plus délivrée, adopter un vrai Kanban pour visualiser le lead time et les stocks. J'utilise le mot vrai Kanban parce que le mot Kanban est utilisé pas mal dans notre monde digital maintenant depuis 10-15 ans. Mais en général, il est utilisé pour décrire n'importe quel système avec des colonnes. Et en fait, l'idée du Kanban chez Toyota, c'est un outil pour voir les goulots d'étranglement. Et donc, pour voir les goulots d'étranglement, il ne suffit pas juste d'avoir des colonnes. Il faut voir le temps de chaque incrément, depuis combien de temps il est dans le process. Souvent, ça fait très mal parce qu'on découvre qu'il y a des trucs, ça fait 253 jours qu'ils ont été démarrés. Il faut que les colonnes correspondent à des ressources. Donc, en fait, les colonnes, il vaut mieux que ce soit des colonnes d'équipe. Pas juste des colonnes d'étapes intermédiaires, ça c'est du management interne à l'équipe. Et il faut aussi visualiser la partie stock, c'est-à-dire la partie où personne ne travaille sur les sujets, pour visualiser s'il y a des piles de stock qui sont en train de se créer. Et finalement, sur building a learning decision, over responding to change, over following a plan, l'idée qu'on ne peut pas juste avoir une organisation qui réagit à chaque changement, mais par contre, on peut créer une culture

26:12 d'organisation apprenante, ce qui va permettre à n'importe qui dans l'organisation d'apprendre et d'écouter les signaux du marché, d'apprendre et de partager ensuite ses apprentissages avec tout le monde. Il me reste très peu de temps, donc je vais aller vite. Mais un des facteurs clés, c'est créer une culture du problem solving pour que tout le monde soit à l'aise pour remonter les problèmes et remonter les analyses qui vont avec. ce qui va permettre de mieux comprendre ce qui se passe sur le marché, et ensuite documenter ces apprentissages et les maintenir frais grâce à ce qu'on appelle le Kaizen, c'est-à-dire du temps dédié à l'introspection sur sa façon de travailler, pour se rendre compte qu'en fait la façon de travailler qu'on a peut être améliorée et mettre à jour les standards. Et finalement ce qu'on appelle les skills matrix, c'est-à-dire l'idée qu'un outil pour que les équipes implémentent une logique de formation continue au niveau des équipes. Voilà, tous ces learnings que j'ai dû aller vite sont aujourd'hui dans le livre, The Lean Tech Manifesto, que je vous invite à obtenir. Je serai sur le stand d'ailleurs pour en dédicacer quelques-uns si vous voulez.

27:15 Et sur ce, je vous remercie et je suis prêt pour vos questions. Bravo Fabrice ! Bravo quand je disais que vous étiez notre Indiana Jones à nous du Lean. Donc on retrouvera sur le stand le livre que vous pourrez donc dédicacer. Et ça, c'est plutôt vachement chouette. Alors on va démarrer une session de Q&A. On a 8 minutes devant nous. Y a-t-il des questions dans la salle? Je suis sûre que oui, parce que le Lean Management, ça fait toujours réagir. Alors, au troisième rang, merci beaucoup Amélie. Je pense que c'est Florent. Quatrième, c'est ça, j'ai mal compté. Bonjour Fabrice, merci beaucoup pour cette excellente présentation. Un des enjeux que je rencontre, moi je suis Florent chez Playplay, un des enjeux que je rencontre, c'est sur le Learning Organization. On essaie de créer des moments où les gens partagent et font des retours d'expérience, mais en même temps les développeurs nous disent, j'en ai marre de passer du temps en réunion, j'ai pas l'impression d'apprendre. Est-ce qu'il y a déjà des tips ou des choses que vous avez réussi? En tout cas, moi, c'est le principal truc sur lequel actuellement, je n'ai pas encore trouvé la recette.

28:20 C'est intéressant. Un des exemples, alors la culture d'apprentissage chez l'EDEP, un des exemples que j'aime bien, c'est quand on a mis en place le don tout dessous, c'est-à-dire que c'était vraiment de l'apprentissage, mais focus sur les défauts. Et c'est vrai que c'était pas, je sais pas si c'était en réunion, mais en fait, pour démarrer un peu la machine, on a été quelques-uns, dont moi, à vraiment dédier une demi-heure tous les soirs, où on se posait à côté d'un team leader et on regardait le défaut de la journée, on regardait son défaut. analyse et on creusait vraiment et c'était une super opportunité de partager notre expérience parce qu'en l'occurrence c'est vrai qu'on a de l'expérience, on a une façon de regarder les problèmes qui à mon avis est intéressante et qui est très formatrice et j'ai eu l'impression que ça a été très bien reçu donc c'est vrai que plutôt que de se dire c'est une réunion de plus dans cet exemple là C'était plus une opportunité de formation supplémentaire. Je pense que ça, ça a beaucoup aidé. Et effectivement, c'est plus ou moins une réponse à la question, parce que la partie partage d'apprentissage est un peu plus difficile.

29:23 Mais la partie, en fait, je crée la culture d'apprentissage en venant en tant que manager, Vraiment, en mettant de l'intensité sur cette partie analyse d'un problème, je trouve qu'elle marche plutôt très bien. Merci beaucoup. Y a-t-il une autre question dans la salle? Alors, quatrième... Enfin, je vais arrêter de dire quatrième rang à chaque fois. Bonjour, merci pour la présentation. De mon expérience, la difficulté du passage de l'agile à l'échelle, c'est de sortir de l'organisation d'engineering et produits et donc de passer toute l'entreprise à l'agile, puisque ça ne sert à rien d'itérer dans son coin si l'entreprise fonctionne encore avec des cycles annuels, de budget ou de roadmap à 18 mois. Comment, avec le Lean Tech, vous abordez ce passage à l'entreprise tout entière? C'est un excellent point. Effectivement, c'est un truc que j'entends souvent des gens qui disent« on est agile côté IT, par contre on n'est pas agile en tant qu'organisation».

30:29 Et effectivement, c'est un peu le sujet clé. Déjà, je trouve que nous, on essaie de l'aborder en démarrant une grosse partie sur la partie« value for the customer». C'est-à-dire qu'en disant, si l'organisation, et quand on dit l'organisation, on ne parle pas de l'organisation tech, on parle vraiment de toute l'organisation, n'a pas un vrai effort sur comprendre ce qu'est la valeur client, et la communiquer à l'organisation, et structurer son organisation autour de la valeur client, Et ça inclut des idées type team topologies, où on essaie de se dire comment mon organisation globale peut être plus orientée produit, par exemple. Ce n'est pas la seule solution, mais c'est une solution. C'est un peu la manière dont on dit que c'est le début. Il ne faut même pas parler de delivery, de comment mon équipe tech livre plus vite. Il faut vraiment commencer par comment l'équipe de direction s'intéresse aux clients et s'intéresse à comment son organisation est plus orientée client. Ça c'est une réponse à moyenne échelle et une réponse à très grande échelle. On ne l'aborde pas dans l'Intech Manifesto.

31:33 En vrai, ça ne nous concerne peut-être pas tous ici. Mais j'ai beaucoup aimé les idées de Bernhard Boxness, de Beyond Budgeting, où effectivement, lui, il met un des problèmes de l'agilité dans les process de budgeting. Qui dans les très grosses boîtes empêche de penser agile, parce qu'à partir du moment où le cycle budgétaire est à 12 mois, de toute façon tout sera à 12 mois. Et ça, dans des entreprises plus petites, on a un peu moins ce problème. Mais effectivement, on a des vrais sujets. Et donc ça, on fait ce qu'on peut. Mais je pense que si on a vraiment envie de démarrer une transformation de toute l'organisation, il faut que l'équipe de direction s'y intéresse. Et pour que l'équipe de direction s'y intéresse, un des outils qui marche bien, c'est le Gemba, la pratique du terrain. Et ça, je connais quelques organisations qui font ça et ça marche. C'est assez spectaculaire. Fabrice, est-ce qu'il ne faut pas des qualités humaines à la base avant même de calquer un process pour ce type de transformation dans l'organisation? C'est intéressant. D'avoir son manuel et de regarder les pages sans pour autant les conscientiser vraiment.

32:40 En fait, il y a des prérequis culturels. C'est très humain. Et effectivement, ce qui est assez intéressant, après, il y a certains outils qui... Nécessite quelque part ces prérequis culturels. Par exemple, c'est très dur de dire à un dirigeant ou une équipe de direction« va sur le terrain et sois... soit curieuse, si dans la culture ça ne se fait pas, et si les personnes n'ont pas ces qualités humaines d'être positives, constructives, curieuses, et de s'intéresser vraiment à ce qui se passe sur le terrain. Donc, oui, en fait, je le dis de façon détournée. Plutôt que de dire qu'il faut avoir cette curiosité, il faut avoir cette empathie, il faut avoir cette écoute, je dis qu'il faut aller sur le terrain. En général, c'est effectivement une bonne barrière à l'entrée. Parce que c'est une réinvention du rapport au pouvoir aussi dans l'entreprise. Exactement. C'est-à-dire qu'effectivement, aller sur le terrain, et encore une fois, quand on fait un game, on ne va pas sur le terrain pour engueuler les gens. On va pour s'intéresser à ce qu'ils font et poser des questions et éventuellement les confronter un peu à la stratégie plus globale.

33:45 On va en profiter pour partager la stratégie plus globale. Oui, ça demande certaines qualités humaines. Il y a des gens qui n'y arrivent pas. Il y a beaucoup de gens qui n'y arrivent pas. C'est sûr, toute une réinvention de société à faire. Un prochain bouquin sans doute? Non? On espère? Si, si, probablement. Il nous reste une minute éventuellement pour une question. Alors tout au fond, vous êtes hyper chanceux. Parce que vous avez la minute. Ah pardon, il y en avait deux. Désolée, vous êtes malchanceux pour le coup. Pardon. Il y a d'autres taux qu'après. Éventuellement, de toute façon, Fabrice, on vous retrouve tout à l'heure sur votre stand pendant la pause. Bonjour, merci beaucoup pour ce talk. Moi, j'ai une question. Vous parlez de Tech Enabled Network of Teams. Donc, on augmente encore de la dépendance sur la technologie plutôt que des interactions humaines. Vous parlez de scale. inspiré d'organisations qui sont à l'hyper-croissance, de l'hyper-scale, est-ce que dans un contexte de crise, de crise environnementale, de crise économique, etc., vous pensez qu'il y a vraiment de la résilience à chercher encore de l'hyper-croissance, à augmenter de la dépendance sur des nouvelles technologies, plutôt que de justement essayer de revenir à quelque chose qui est centré sur des interactions humaines, sur des choses qui sont plus low-tech et qui sont à des échelles, finalement, où l'intuition serait qu'on a plus de résilience?

34:55 Merci. Super question. Magnifique. Écoute, je vais te partager mon utopie. Je trouve qu'il y a quand même beaucoup de décisions qui nous impactent aujourd'hui, qui sont prises par une très grande organisation qui s'appelle le secteur public. Et que si le secteur public était plus agile, je pense que ça serait bénéfique pour tout le monde. Donc je pense qu'effectivement, c'est utile de réfléchir à comment... Des grandes organisations peuvent être plus agiles parce que notre vie est quand même pas mal régie par une très grande organisation qui n'est pas très agile. Et j'ai envie de croire que ça peut changer et que ça permettra effectivement d'apporter des meilleures solutions, plus ingénieuses, plus locales. Parce que l'idée de l'agilité à l'échelle, ce n'est justement pas de faire des éléphants encore plus gros, mais c'est plutôt d'aider des gros éléphants à coordonner des actions plus locales et plus ingénieuses, plus spécifiques aux petits problèmes du terrain. Et donc voilà, ça c'est ma réponse à cette question qui est très pertinente, mais je pense qu'effectivement, la démarche est inverse.

36:01 La démarche, c'est vraiment de rendre les grosses organisations plus proches du local. Je rappelle que c'était l'utopie uniquement de Fabrice. Qu'on soit bien clair, rapport au service public, au service privé, etc. Je crois qu'on pourrait en discuter, notamment sur le stand tout à l'heure. Mais merci beaucoup pour ce talk qui a donné envie à certains, j'espère, de creuser encore plus le Lean Management. Merci beaucoup. Merci beaucoup Fabrice. Je vous laisse repartir.