Fabrice Bernhard - Tech-enabled Network of Teams

[00:00:03] Bonjour à tous. Euh, je suis très heureux d'être ici aujourd'hui pour, euh, vous parler du réseau d'équipes technologiques. C'est la première fois que je parle de ce sujet en public, donc je suis très excité. Euh, et donc mon histoire commence il y a quelques années et tout commence lors d'un voyage d'études sur le lean au Japon, organisé par Mike. Alors, qu'est-ce qu'un voyage d'études lean ? En gros, vous visitez beaucoup d'usines.
[00:00:33] Euh, principalement des usines Toyota et des fournisseurs Toyota pour essayer de comprendre ce qu'est vraiment le lean à la source. Donc vous voyez des choses comme ça, par exemple. Euh, et bien sûr, c'est fascinant, très intéressant.
[00:00:49] Et, euh, juste pour ceux qui ne savent pas qui est Mike, il est, euh, l'auteur de plusieurs, euh, ouvrages de référence sur le Lean. Euh, pour lesquels il a remporté le prix Shingo quatre fois. Donc un expert assez pointu dans son domaine. Et, euh, nous étions dans le bus parce que l'un des inconvénients de ces voyages d'études est que l'on passe beaucoup de temps à se déplacer d'une usine à l'autre en bus et Michael et moi débattions, utilisant notre temps pour débattre du Manifeste Agile. Et comme vous pouvez le voir sur la photo, que j'ai la chance d'avoir, c'était un débat tendu.
[00:01:29] Et en fait, Michael soutenait que le Manifeste Agile n'est pas scalable.
[00:01:37] Euh, et j'étais, euh, très défensif. Euh, donc mon premier point était que, euh, les grandes, il existe de grandes organisations qui sont agiles, donc je n'ai pas vraiment compris son point.
[00:01:50] Euh, mais en fait, je pense que la raison principale pour laquelle j'étais si défensif à propos de l'Agile, c'est parce que j'adore l'Agile. Euh, j'ai, vous savez, comme beaucoup de gens ici probablement, j'ai vécu la transformation de travailler de manière plus traditionnelle à travailler de manière vraiment agile et j'adore ce que cela a créé en termes d'autonomisation des équipes et d'ingéniosité que cela a créé au sein de l'équipe. Donc je ne voulais pas que l'Agile ne soit pas parfait.
[00:02:20] Mais le point de Michael était juste. Euh, il y a des cultures agiles qui ont évolué, mais ce n'était pas son propos. Son point était vraiment que, euh, le Manifeste Agile n'était pas utile en cela parce que ses principes ne sont pas applicables à grande échelle. Donc si vous prenez chaque principe du Manifeste Agile individuellement, vous pouvez faire toute cette expérience et réaliser que oui, ce n'est pas le genre de principe que je peux utiliser dans une organisation de 100, 200, 300 personnes et plus. Pour vraiment m'aider à définir et à communiquer ce qu'est être Agile à une telle échelle.
[00:02:54] Et pour être juste envers lui, je n'aurais pas été dans un voyage d'études lean dans ce bus en premier lieu si, vous savez, nous avions trouvé toutes les réponses pour faire évoluer notre propre organisation dans le Manifeste Agile. Euh, mais la réalité est que dès que nous avons atteint une certaine taille, euh, nous avons pu voir que, vous savez, ce que nous voulions retenir de l'Agile, nous ne pouvions pas le trouver dans le manifeste et nous devions chercher ailleurs.
[00:03:24] C'est ainsi que le voyage pour trouver, mais parce que je suis une personne assez déterminée, je voulais prouver que Michael avait un peu tort, euh, j'ai commencé un voyage pour trouver des principes qui s'adaptent et qui sont fidèles à l'esprit du Manifeste Agile. Pour lui montrer que oui, d'accord, le Manifeste Agile en soi ne s'adapte pas, mais il y a des façons de le modifier, ce qui le rend adaptable. Et ce voyage se termine maintenant. Parce que je suis très fier d'annoncer la sortie d'un livre que j'ai écrit, la chose la plus difficile que j'aie jamais faite dans ma vie, euh, qui sort aux États-Unis le 19 mars et en Europe le 7 mai.
[00:04:02] Alors aujourd'hui, euh, je voudrais partager un peu ce voyage avec vous, euh, à la recherche de principes qui pourraient aider à développer une culture agile. Euh, et ensuite me concentrer vraiment sur l'un d'entre eux, euh, parce que c'est ce qu'on m'a demandé de faire. Euh, et, euh, et sur celui-ci, partager avec vous les histoires que j'ai examinées, en particulier, l'histoire de Linux. Et comment ils ont développé la collaboration avec la technologie, puis terminer par ce que cela signifie réellement dans nos propres organisations.
[00:04:35] Donc, la recherche de principes pour aider à développer une culture Agile, euh, vous amène, bien sûr, à commencer par poser la question : que signifie Agile ? Quelle est l'essence du Manifeste Agile ? Et pour cela, il y a une ressource très utile, qui est, euh, le lien 'À propos' sur le site web du Manifeste Agile. Euh, où il vous raconte l'histoire et comment, vous savez, on s'est senti le jour où il a été, enfin, la semaine où il a été rédigé. Et ils disent quelque chose de très intéressant. Ils disent qu'au fond, je crois, les méthodologies Agiles visent réellement à livrer de bons produits aux clients. En opérant dans un environnement qui agit en fait comme si les gens étaient les plus importants. Maintenant, ayant été sur un nouveau chemin depuis déjà pas mal de temps, cela a tellement résonné avec ce que nous avions appris et, vous savez, essayé de mettre en œuvre à grande échelle dans notre organisation en utilisant la pensée lean. Et c'est, euh, et je pense que c'est ce qui, vous savez, est vraiment intéressant dans la pensée lean, c'est qu'elle partage vraiment le même objectif que le Manifeste Agile. Voici, par exemple, une démonstration anecdotique, mais c'est un passage de la stratégie lean. Et il est dit : La pensée Lean combat la maladie des grandes entreprises en stimulant la pensée managériale pour fournir un travail significatif aux personnes qui travaillent en pleine conscience afin de toujours offrir une meilleure valeur aux clients. Donc une formulation très, très similaire à ce que l'on peut trouver dans le Manifeste Agile.
[00:05:57] Ce lien, ce lien fort entre l'Agile et le Lean Thinking n'est pas si surprenant. Euh, si vous regardez l'histoire d'Agile, Scrum a une grande influence sur le mouvement Agile. Sand le critiquait beaucoup ce matin, mais je pense que c'était, vous savez, l'une des forces, euh, euh, clés dans la diffusion d'Agile dans le monde entier. Et Scrum, quand vous regardez le premier article en 1995, publié par Ken Schwaber, il, euh, cite le, euh, un article de Takeuchi et Nonaka intitulé The New New Product Development Game, publié dans la Harvard Business Review en 1986. C'est en fait Takeuchi et Nonaka qui, euh, ont inventé le mot Scrum pour décrire comment, euh, des équipes de projet innovantes, des équipes de projets d'innovation dans certaines entreprises japonaises fonctionnaient. Euh, et Takeuchi et Nonaka sont en fait des professeurs japonais, euh, spécialisés, je crois, en gestion, gestion de l'innovation. Et ils ont étudié de nombreuses entreprises japonaises, y compris Toyota, voici un livre de, euh, Takeuchi intitulé Extreme Toyota. Donc vous pouvez voir cette, cette, vous savez, lignée entre, euh, lignée directe entre Lean et et Agile. C'est assez bien connu. Euh, je pense qu'une chose qui était peut-être moins bien connue, du moins pour moi, je l'ai découverte au cours du voyage, c'est que pas mal de grandes entreprises technologiques ont également été directement influencées par le Lean et ce, avant même que l'Agile n'existe. Je pense que la découverte la plus, euh, spectaculaire pour moi a été une interview de Steve Jobs. Dans une, euh, vieille interview, c'est en 1990, il est chez NeXT et il explique son expérience d'avoir été coaché par le Dr Duran. C'est une interview incroyable et, euh, je dois vous donner un peu de contexte pour comprendre ce que cela signifie. Euh, la première partie est, en termes de chronologie, c'est, c'est après que Steve Jobs ait été viré de, euh, d'Apple.
[00:07:58] Et c'est une période intéressante car Steve Jobs est quelqu'un d'obsédé par la qualité, mais avant d'être renvoyé par, euh, par Apple, il avait déjà démissionné de son poste de PDG. Et il avait été remplacé par, euh, Scully, je crois, John Scully, euh, l'ancien PDG de Pepsi. Et l'une des choses que l'on peut voir quand on regarde un peu l'histoire d'Apple à l'époque, c'est que la qualité avait baissé. Il y avait eu des problèmes de qualité, des batteries qui explosaient et des choses comme ça. Donc je pense que probablement quand, quand Steve Jobs quitte Apple et lance NeXT, sa prochaine entreprise, euh, je pense qu'il y avait pour lui probablement une vraie curiosité sur la façon dont il pourrait atteindre ce genre de standards de qualité qu'il recherchait, le positionnement de NeXT était vraiment de créer des ordinateurs incroyables, super haut de gamme. Euh, et c'est pourquoi il s'est intéressé à la, euh, théorie de la qualité et est entré en contact avec le Dr Duran. Le Dr Duran est l'un des deux experts américains en qualité qui ont été envoyés au Japon, pardon, c'est une longue histoire, qui ont été envoyés au Japon après la Seconde Guerre mondiale pour aider à la reconstruction du Japon. Et l'un des deux, donc avec Deming, et donc Deming et Duran donnaient des conférences aux hauts dirigeants japonais, euh, sur ce qu'est la gestion de la qualité, et ce qu'ils enseignaient à l'époque est en grande partie crédité pour, euh, le, le, en fait, le début de la pensée lean.
[00:09:23] Dans différentes entreprises japonaises, mais en particulier, Toyota. Donc, et bien sûr, Duran avait influencé ces entreprises japonaises, mais il est resté au Japon, donc il a appris d'elles et était clairement un expert des principes qui, vous savez, sont très proches de la pensée lean. Et vous pouvez voir comment Steve Jobs a été influencé par eux et ce qu'il dit est très, très fortement, euh, en accord avec la pensée lean, mais aussi en accord avec ce que nous considérerions comme Agile aujourd'hui. Une autre connexion forte de ce type est Amazon. Donc Amazon, c'est probablement mieux connu. Vous pouvez trouver dans la lettre aux actionnaires des références au Kaizen, aux Sensei japonais et à des choses comme ça. Euh, il y a une référence plus, euh, maintenant plus évidente à ce sujet dans le livre Working Backwards où, euh, Colin Bryar et Bill Carr racontent l'histoire de, euh, Jeff Bezos. Étant sur l'une de ses missions de service client. Donc, vous savez, chez Amazon, ils ont cette culture d'envoyer chaque top manager deux jours tous les deux ans pour, euh, être réellement dans le service client. Et, euh, et c'est une histoire super intéressante, c'est que Jeff Bezos réalise qu'une des personnes du support client reçoit un appel concernant un produit et sait immédiatement de quel produit il s'agit. Et il a demandé, genre, comment avez-vous deviné que la personne allait se plaindre de ce produit ? Il répond : Oui, je connais ce produit. J'ai déjà eu quelques plaintes, il y a un schéma, je le vois. Et et et Jeff Bezos, qui étudiait le lean à l'époque, euh, a immédiatement fait le lien avec le concept d'Andon et a décidé que c'était fou que quelqu'un puisse réellement savoir qu'il y avait un problème sur un produit mais ne pas arrêter l'apparition de ce produit sur le site web. Il a donc créé ce qu'il a appelé le gros bouton rouge. Et c'était assez compliqué à mettre en œuvre, mais ils l'ont fait, parce que Jeff Bezos doit être assez convaincant. Et, euh, et depuis, en fait, les gens du service client peuvent décider d'appuyer sur le bouton rouge pour arrêter de vendre un produit particulier s'ils constatent un schéma de défauts et, euh, et cela, bien sûr, déclenche une escalade complète afin que les équipes produits doivent ensuite faire quelque chose à ce sujet. Euh, cela est allé encore plus loin quand en 2006, il a en fait embauché un expert en Lean, Mark, en tant que SVP Worldwide Operations and Customer Service, déployant réellement le Lean, euh, dans toutes les opérations d'Amazon.
[00:11:57] C'est pourquoi, euh, lorsque vous avez étudié à la fois l'Agile et le Lean Thinking, vous pouvez voir que le Lean Thinking est un très bon candidat pour trouver des principes qui partagent le but du Manifeste Agile, Tout en étant éprouvé à l'échelle, car pour le dire simplement, la pensée lean est l'étude de ce que Toyota fait si incroyablement bien et il y a 300 000 employés, une entreprise humaine, donc bien sûr, euh, cela va au-delà d'une seule équipe d'ingénieurs logiciels intelligents.
[00:12:26] Ainsi, en utilisant nos 10 ans d'expérience dans la mise à l'échelle de notre propre entreprise en utilisant le lean thinking, de 10 employés à environ 700 personnes, Voici les principes que j'ai, euh, que j'ai trouvés pertinents. Alors premièrement,
[00:12:46] Premièrement, lorsque vous faites beaucoup de pensée lean et que vous voyez ce Manifeste Agile, vous réalisez que vous devriez vraiment mettre le client en premier, alors réorganisons le Manifeste Agile. C'est probablement l'une des premières, la première influence de la pensée lean. Et puis, en examinant chaque principe, euh, eh bien, nous pouvons prendre le premier principe du lean thinking, le lean thinking est le deuxième livre sur le lean par Dan Jones et Jim Womac.
[00:13:14] Et ce principe est la valeur pour le client. Et je pense que la valeur pour le client est un excellent principe en termes de mise à l'échelle de ce que le Manifeste Agile appelle la collaboration client. Parce que c'est un principe qui fonctionne dans une très, très grande entreprise. Vous savez, vous pouvez diriger en fonction de la valeur pour le client. Il est beaucoup plus difficile de diriger une entreprise de 100 000 personnes en matière de collaboration client, car tout le monde ne peut pas collaborer avec le client.
[00:13:41] Un deuxième principe est, euh, est à propos du logiciel fonctionnel. Logiciel fonctionnel, il y a deux idées que je trouve dans le logiciel fonctionnel, l'une est que vous devriez faire un logiciel qui, vous savez, fonctionne, n'a pas de bugs, et l'autre est que, vous savez, vous devriez itérer sur de courts incréments de logiciel fonctionnel que vous pouvez déployer en production. Euh, eh bien, quand il s'agit de déployer, vous savez, produire une qualité beaucoup plus élevée, beaucoup plus rapidement, le, vous savez, l'état de l'art est, est, euh, le système de production Toyota. Et pour cela, ils ont deux principes appelés Jidoka et Jit, ou du premier coup et juste à temps. Et ce sont des principes qui ont prouvé qu'ils, je veux dire, ils viennent, bien sûr, avec beaucoup d'outils et de systèmes autour d'eux pour vous aider, euh, à faire évoluer la livraison à une très grande échelle. Enfin, pour répondre au changement plutôt que de suivre un plan.
[00:14:38] Il y a cette idée que lorsque vous commencez à grandir, vous voulez mettre à l'échelle toutes les équipes qui répondent au changement, mais vous ne voulez pas qu'elles fassent, vous savez, réinventent la roue tout le temps ou prennent des risques qui pourraient mettre en péril toute l'organisation. Et donc pour cela, quand vous regardez, euh, les grandes organisations qui ont réussi à faire quelque chose comme ça, elles essaient en fait de répondre au changement, mais en s'appuyant sur les apprentissages précédents et les connaissances externes, euh, euh, et c'est ce que je traduis par la construction d'une organisation apprenante, qui est बेसिकली le résultat de, euh,
[00:15:10] ce qui se passe lorsque vous créez réellement une culture de Kaizen et de normes dans votre, dans votre organisation. Euh, donc malheureusement, je ne peux pas vous en dire beaucoup plus sur ces trois principes.
[00:15:25] Euh, mais bien sûr, vous pouvez tout apprendre à leur sujet dans le livre et vous pouvez déjà le précommander si vous le souhaitez. Euh, pourquoi ? Parce qu'aujourd'hui on m'a demandé de me concentrer sur le seul principe où j'ai senti que je devais regarder plus loin que la simple pensée lean pour trouver quelque chose qui soit convaincant. Et c'est les individus et les interactions.
[00:15:51] Et la raison pour laquelle j'ai senti que, euh, il y avait quelque chose de différent dans le monde Agile et dans le monde de la technologie, c'est que, vous savez, je je pouvais voir qu'il y avait quelque chose à propos de l'autonomisation des équipes que je ne pouvais pas vraiment voir dans ce que je connaissais du lean thinking, du moins pas autant. Et donc j'ai décidé de faire l'expérience de pensée de chercher vraiment le genre d'organisations qui mettent à l'échelle les individus et les interactions de la manière la plus extrême. Et je me suis dit, vous savez quoi, l'organisation la plus extrême en termes de mise à l'échelle des individus et des interactions sont probablement les organisations open source. Parce qu'ils sont vraiment composés de bénévoles, vraiment, s'il y a trop de bureaucratie, ils s'enfuient. Et, euh, et bien sûr, le projet open source le plus emblématique est Linux. J'ai donc décidé d'étudier l'histoire de Linux.
[00:16:45] Donc Linux, un peu de contexte, commence en août 1991, il y a cet étudiant appelé un étudiant finlandais appelé Linus Torvalds qui poste un message sur le groupe de discussion Minix en disant, hé les gars, je fais un système d'exploitation gratuit, bien sûr, cela ne sera pas du tout commercial. Qu'en pensez-vous ?
[00:17:03] Et, euh, vous savez, 30 ans plus tard, 55 000 personnes ont contribué au noyau Linux. Et Linux alimente tous les 500 meilleurs superordinateurs du monde. Euh, le graphique représente la part, euh, des systèmes d'exploitation parmi les 500 meilleurs superordinateurs, donc les superordinateurs les plus rapides, les plus grands, les plus énormes. Euh, et vous pouvez voir qu'il a déjà atteint 100% il y a quelques années. Linux représente 96 % des 1 million de serveurs web les plus importants et, via Android, alimente en fait 4 milliards d'utilisateurs de smartphones.
[00:17:40] Donc, la mise à l'échelle pour atteindre les 55 000 contributeurs cumulés n'a pas été sans ses défis, donc bien sûr pour moi c'était le plus intéressant, c'est vraiment de comprendre quand les défis sont survenus et ce qui a été fait pour les résoudre.
[00:17:53] J'ai trouvé cette pauvre photo de Linus. La première crise de mise à l'échelle frappe vraiment en 1996, soit cinq ans après le début du projet.
[00:18:07] Euh, le symptôme est cet aveu de Linus qu'il est enterré vivant sous les emails. Euh, et c'est vraiment comme, vous savez, la chose a atteint, je pense, déjà 100 contributeurs, comme quelques-uns, comme 100 ou 200. Et, euh, et la, je veux dire, la façon dont ils sont organisés signifie que Linus reçoit tous ces e-mails, doit les gérer, et est clairement, complètement dépassé. Euh, mais ils ont réussi à y remédier, euh, par deux changements. L'un est, euh, l'introduction d'une architecture beaucoup plus modulaire. Euh, et concrètement, c'est l'introduction de l'architecture des modules de noyau chargeable, qui a vraiment deux effets principaux. Premièrement, cela retire beaucoup de code du noyau, ce qui signifie que Linus n'a plus besoin de le regarder. Euh, et officialise aussi qu'il y a des gens qui gèrent les modules et cela correspond aussi à la création du rôle de mainteneur. Donc cette idée que ce n'est pas comme si, euh, tout le monde contribuait au hasard, tout à coup, il y a des gens qui, vous savez, sont autonomisés et prennent un leadership sur l'équipe autour du module.
[00:18:37] L'un est l'introduction d'une architecture beaucoup plus modulaire. Euh, et concrètement, c'est l'introduction de l'architecture modulaire cannibal chargeable, qui a vraiment deux effets principaux. Premièrement, cela retire beaucoup de code du noyau, ce qui signifie que Linus n'a plus à s'en occuper. Euh, et cela officialise également le fait qu'il y a des gens qui s'occupent des modules, et cela correspond aussi à la création du rôle des mainteneurs. Donc cette idée que ce n'est pas comme si, vous savez, tout le monde contribuait au hasard.
[00:19:13] Tout d'un coup, il y a des gens qui, vous savez, sont habilités et prennent un leadership au sein d'une équipe autour du module.
[00:19:23] Euh, cela fonctionne pendant environ deux ans. Et puis il y a une deuxième, euh, euh, crise en 1998, où Linus se met très en colère et disparaît ensuite pendant quelques jours. Euh, oui, le fait qu'il soit en colère n'est probablement pas le symptôme. Le fait qu'il disparaisse est comme le grand symptôme. Euh, et ceci, c'est '98 et cela inspire quelqu'un dans la communauté, Larry Macvoy, à créer BitKeeper. Donc BitKeeper est le précurseur de Git, c'est donc un outil pour, euh, pour aider à fusionner le code source beaucoup mieux et d'une manière beaucoup plus distribuée, ce qui était ce qui était fait à l'époque. À l'époque, je crois qu'ils faisaient encore, euh, des patchs par e-mail, non ?
[00:20:12] Euh, et c'est intéressant, c'est comme le le premier message de Larry qui dit, vous savez, il serait formidable d'avoir un outil qui permette aux gens de faire une partie du travail. Euh, BitKeeper n'est pas adopté tout de suite, donc les problèmes continuent pendant environ quatre ans.
[00:20:30] Euh, il y a beaucoup de controverse autour de ça, euh, parce que BitKeeper n'est pas open source. Et donc beaucoup de gens préféreraient en fait, euh, euh, créer ce qu'ils appellent un, euh, pingouin de patch adjoint. Mais il y a quelque chose de très intéressant dans la réaction de Linus à cela, car il voit juste la bureaucratie créée en créant des assistants, etc. Il cherche donc une solution très différente. Et c'est pourquoi en 2002, il est finalement convaincu que, euh, BitKeeper est probablement la chose qu'il devrait, euh, adopter officiellement. Et il a donc réussi à convaincre le reste de la communauté et la situation, et ce qui est très intéressant, c'est qu'en adoptant BitKeeper, la situation s'est immédiatement améliorée. Donc avant cela, beaucoup de contributions étaient perdues, après cela, plus aucune.
[00:21:18] Si vous ne connaissez pas BitKeeper, et si vous vous demandez ce que c'est, euh, ce qui s'est passé, c'est qu'en 2005, Larry, le créateur de BitKeeper, a menacé de révoquer la licence gratuite de BitKeeper. Et Linus s'est mis en colère, a donc pris quelques semaines de congé et a créé un outil, vous savez, comme un projet annexe appelé Git pour remplacer BitKeeper. J'adore cette histoire parce qu'elle te rappelle juste de ne pas t'embêter avec Linus.
[00:21:47] Et ce qui est très intéressant, c'est que quand vous lisez, euh, vous savez, les les les entretiens de Linus depuis lors, son message est vraiment clair : ils n'ont eu aucun défi de mise à l'échelle depuis, aucun défi de mise à l'échelle énorme. Ça a vraiment marché. Et donc la question est de savoir quels sont les enseignements de ces deux défis de mise à l'échelle et de la manière dont ils les ont abordés.
[00:22:10] Je pense que le premier enseignement est cette idée de réseau d'équipes autonomes. Il s'agit donc d'une animation de la contribution à Linux. Et vous pouvez voir qu'il y a cette idée de petits groupes de personnes contribuant dans certains espaces, puis étant fusionnés et ensuite fusionnés plus loin dans la branche principale. Donc il y a vraiment cette idée de, ok, à un moment donné, tu dois créer des équipes et tu dois trouver un moyen de les faire, euh, euh, fusionner leurs contributions, euh, ensemble pour former, vous savez, pour contribuer à la vision globale. Et ce, ce, euh, euh, ce, euh, réseau d'équipes fonctionne parce qu'il est aidé par des technologies qui distribuent la collaboration entre les équipes. Et en termes de technologies, dans l'histoire de Linus, j'en vois vraiment deux qui se distinguent. Il y a l'architecture modulaire qui est très importante pour, disons, concevoir le travail de manière à ce que, vous savez, vous puissiez, oui, euh, délimiter un peu le problème autour des équipes. Et puis il y a une technologie incroyable appelée Git pour ensuite distribuer la fusion de ce travail et le remettre ensemble dans la branche principale.
[00:23:26] Et, euh, et puis bien sûr, une fois que j'ai eu fait, vous savez, eu ces deux réalisations, j'ai commencé à chercher si c'était un modèle dans, vous savez, les grandes organisations avec des coachs agiles. Et c'est très intéressant car pour moi, l'une des organisations agiles les plus auto-organisées, euh, euh, qui est inspirante, c'est Burdsorg, c'est étudié dans le livre de Frederick Lalu intitulé Reinventing Organization, et c'est en gros un réseau de 10 000 infirmières aux Pays-Bas. Euh, auto-organisées en petites, euh, euh, équipes. Euh, et je pense que en néerlandais signifie équipes de quartier, donc c'est en gros comme une organisation de quartier. Euh, et quand vous, euh, lisez les les interviews, lisez les livres, lisez le livre, euh, ça parle beaucoup d'auto-organisation et et de but, etc. Mais j'étais très content parce que j'ai pu rencontrer Yos de Block un week-end. Et donc j'ai réussi à m'asseoir à côté de lui au dîner et, vous savez, à essayer de tester mon hypothèse. Et il m'a finalement donné cette information, à savoir que Yos et son cofondateur, avant de créer Burdsorg, travaillaient sur le projet informatique de leur ancien employeur. Et donc son cofondateur est en fait un cofondateur technique. Et vraiment l'un des principaux catalyseurs de Burdsorg est une plateforme technologique qu'ils ont créée pour réduire toutes les tracasseries, toutes les, vous savez, toutes les tâches administratives que les infirmières doivent généralement faire, qu'elles faisaient chez les concurrents, et aussi un moyen de responsabiliser les les les équipes d'infirmières sur leur PNL. Donc, j'étais content. J'avais ma preuve que la technologie était aussi essentielle chez Burdsorg.
[00:25:15] Euh, et puis bien sûr, vous pouvez le retrouver dans d'autres exemples, euh, Amazon et son célèbre mandat API. Euh, c'est donc une transformation qui est maintenant décrite dans, euh, c'était une sorte de légende d'Internet, euh, basée sur un article de blog d'un gars appelé Steve Yage. Mais maintenant il y a en fait beaucoup plus de détails à ce sujet dans Working Backwards de Colin Bryan, euh, McCarr, et vous avez cette incroyable, euh, sorte de citation, euh, de Jeff Bezos qui dit, si vous voulez qu'Amazon soit un endroit où les bâtisseurs peuvent bâtir,
[00:25:47] nous devons éliminer la communication, pas l'encourager. Et c'est vraiment comme une, vous savez, c'était vraiment pour contrer l'idée que les gens disaient, oh, il y a tellement de problèmes, il y a tellement de dépendances entre les équipes, nous devons créer plus de structures de communication. Et le message de Jeff Bezos était : en fait, ce n'est pas ce que nous devons faire, nous devons éliminer la communication. Et comment le faisons-nous en faisant en sorte que les équipes logicielles construisent et documentent clairement un ensemble d'API pour tous les systèmes et services.
[00:26:18] Euh, mais vous pouvez aussi le trouver chez Tesla, et Tesla, bien sûr, est très intéressant parce que c'est, vous savez, on pourrait l'appeler la némésis de Toyota. Et Tesla a vraiment, euh, euh, introduit une révolution en termes de construction automobile, qui est l'architecture modulaire des voitures. Et ici, vous pouvez voir que ce qui est très révolutionnaire, c'est que la voiture est en fait divisée en trois grandes parties qui sont construites séparément puis assemblées.
[00:26:48] Et c'est très, euh, c'est très, très intéressant, et bien sûr, Toyota, étant une bonne organisation d'apprentissage, a maintenant introduit sa nouvelle architecture modulaire.
[00:26:58] Euh, et c'est assez intéressant, il y a un livre, euh, appelé Team of Teams du Général Stanley McChrystal, qui était en charge des opérations spéciales conjointes en Irak. Euh, et explique comment, vous savez, ils avaient ce, ce budget incroyable, et ils avaient ces équipes incroyables, mais quand quand toutes ces équipes se sont réunies, elles étaient si bureaucratiques qu'elles perdaient toujours contre les insurgés en Irak. Et il explique comment il a essayé de transformer cette bureaucratie en une équipe d'équipes, c'était son mot pour cela, et l'une des choses clés qu'il a faites, ce qui est très intéressant, c'est qu'il a introduit essentiellement un stand-up quotidien de tout le monde. Et bien sûr, cela a été rendu possible par le fait qu'ils disposaient de la technologie de vidéoconférence, ce qui, vous savez, de nos jours ne semble pas si fou, mais nous parlons de 91 en Irak en temps de guerre, donc cela a dû leur coûter cher en câble à fibre optique, mais ça a marché.
[00:27:54] Alors pourquoi ce, euh, ce modèle technologique est-il, je pense, si si répandu partout ? C'est parce que la mise à l'échelle des individus et des interactions consiste vraiment à maintenir les équipes autonomes.
[00:28:09] Donc vous voulez garder ce sentiment que vous avez dans une équipe agile de, vous savez, aller vite, être autonome, euh, être capable de vraiment contribuer à la valeur.
[00:28:20] Euh, mais à mesure que vous évoluez, vous devenez de plus en plus dépendant, de plus en plus de dépendances, euh, et, vous savez, des interactions nécessaires avec d'autres équipes, et cela, vous savez, c'est le le défi contre lequel vous devez lutter.
[00:28:36] Et les grandes organisations agiles ont relevé ce défi grâce à une technologie qui leur permet de réduire un grand nombre de ces dépendances et de permettre aux équipes de collaborer en réseau sans vraiment attendre les autres, tandis que chaque équipe reste autonome sur son module. Donc, cela dit,
[00:28:58] Je décide d'appeler cela un réseau d'équipes habilité par la technologie.
[00:29:08] Alors concrètement, qu'est-ce que cela signifie de, euh, essayer d'introduire un principe de réseau d'équipes habilité par la technologie dans vos propres organisations ?
[00:29:18] Alors, euh, eh bien, premièrement, n'oublions pas qu'il y a le mot équipe dans le réseau d'équipes habilité par la technologie. Et c'est donc là que nous ne devrions pas nous jeter sur la technologie, il s'agit d'abord de s'assurer que nous avons de bonnes équipes. Euh, j'adore cette citation de Bill Campbell, euh, aussi connu comme le coach à un billion de dollars parce qu'il a coaché Steve Jobs et et euh, Larry Page et euh, beaucoup d'autres. Euh, oui, euh, je crois qu'il a coaché Mark Zuckerberg ou Sheryl Sandberg. Il est donc vraiment le coach derrière toutes les grandes entreprises technologiques et l'une de ses grandes citations est : travaillez l'équipe, puis le problème.
[00:29:58] Alors, rapidement sur ce point, je pense que si vous voulez avoir, euh, de bonnes équipes, euh, elles sont le résultat de bons chefs d'équipe bienveillants, et ensuite de bons chefs d'équipe bienveillants sont, c'est notre modèle, vous pouvez le prendre ou non. Euh, mais je pense que les bons chefs d'équipe de soutien sont compétents.
[00:30:18] Euh, j'ai mis la photo de Steve Jobs parce qu'il y a cette incroyable interview de Steve Jobs expliquant comment à un moment donné Apple se développe. Donc ils pensent, d'accord, peut-être que nous devrions embaucher, nous devrions embaucher des managers externes, euh, des managers professionnels. Et bien sûr, ce fut un et il explique comment pour eux ce fut un désastre parce qu'ils avaient ces ingénieurs incroyables et ces ingénieurs incroyables voulaient travailler pour quelqu'un dont ils pouvaient apprendre et ils ne pouvaient pas apprendre d'un manager professionnel. Alors ils ont choisi la voie beaucoup plus difficile en disant, d'accord, nous devrons former des managers à partir de nos ingénieurs incroyables. Et ils vont être très mécontents de cela, mais ils seront toujours de meilleurs managers. Et ce sera mieux pour toute l'organisation. Donc clairement, un bon chef d'équipe est quelqu'un de compétent qui peut soutenir les membres de l'équipe et et leur enseigner et, vous savez, améliorer leurs compétences. Un bon chef d'équipe de soutien est bienveillant.
[00:31:13] Euh, et, euh, c'est la photo de Simon Sinek, qui, vous savez, est très attaché à la bienveillance. Et je pense qu'une des idées que nous avons trouvées très inspirantes dans un livre intitulé Donc l'idée est de dire, nous ne cherchons pas quelqu'un de polyvalent, nous ne voulons pas quelqu'un qui est incroyable en technologie et incroyable avec les gens et incroyable en bienveillance et au moins un peu bon en bienveillance. Euh, mais nous voulons quelqu'un qui est vraiment fort sur quelque chose, très, vous savez, qui a, euh,
[00:31:42] euh, une forte croyance en quelque chose et qui inspire les gens à le suivre, à les suivre.
[00:31:54] Euh, deuxièmement, des équipes organisées de manière à ce que chaque équipe soit autonome en matière de valeur pour le client. Je veux dire, c'est vraiment la grande idée de l'architecture modulaire. Euh, et ça commence par l'organisation, euh, j'aime bien même le Euh, il y a aussi une référence espiègle au fait que si ça vous intéresse, vous auriez dû être à l'autre conférence, parce que c'est Alberto et il parle en ce moment. Donc oui. Je n'ai pas mis la photo trop tôt dans la conférence parce que je ne voulais pas que vous partiez tous et alliez à l'autre conférence.
[00:32:33] Alors maintenant, imaginons que nous ayons, vous savez, de bonnes équipes et, vous savez, organisées de manière à ce qu'elles puissent apporter de la valeur au client de manière significative. Euh, comment permettons-nous une collaboration d'équipe transparente, comment créons-nous ce réseau d'équipes ? Eh bien, nous pouvons utiliser des technologies révolutionnaires telles que Git.
[00:32:52] Euh, Google Docs, incroyable. Euh, Notion, euh, Trello, Miro.
[00:33:02] Euh, donc vous pourriez penser, d'accord, ce qu'il disait était assez intéressant, mais si la conclusion est que je dois utiliser Google Docs, qu'est-ce que je fous ici ?
[00:33:13] Eh bien, je pense, je pense, vous savez, dans notre monde, maintenant que nous sommes de grands consommateurs de ces technologies de collaboration en temps réel, nous ne réalisons pas la valeur qu'elles ont. Il y a beaucoup d'industries là-bas qui n'ont encore aucune idée de leur existence, et ne savent pas comment les adopter. Euh, et aussi, je pense que la réflexion sur tous ces apprentissages tout au long de ce parcours, je pense que cela m'a également fait respecter davantage la technologie et la valeur qu'elle apporte. Et typiquement, si vous regardez Git,
[00:33:46] une fois que vous réalisez à quel point il est puissant en termes de facilitation de la collaboration en réseau, alors vous êtes probablement plus critique quand vous voyez un projet faire 25 repos différents. Parce que tout d'un coup, vous voyez que, vous savez, vous n'utilisez même pas Git pour ce qu'il est, qui est une technologie de fusion. Et c'est mon opinion personnelle, mais apparemment Google, Meta, Microsoft, Twitter, Uber, tous utilisent un mono repo. Donc je pense qu'il y a probablement quelque chose de juste là-dedans. Euh, bien sûr, si vous commencez à faire beaucoup de multi-repo, je veux dire, c'est un débat compliqué, mais Je pousserais vraiment pour le mono repo car avec le multi repo, vous perdez ce facilitateur de collaboration réseau.
[00:34:31] Euh, encore une fois, quand vous pensez à l'importance de la collaboration en réseau, vous réalisez aussi l'importance de ce n'est pas seulement un outil, c'est la façon dont vous l'utilisez, et typiquement, vous devez repenser, euh, la la la conception de de la façon dont vous la conception de l'information que vous stockez dans ces outils. Typiquement, voici un exemple de notre modèle pour l'analyse des défauts que nous utilisons dans Notion. Et nous avons itéré plusieurs fois sur cette conception car nous avons réalisé que les conceptions initiales n'étaient pas en libre-service. Donc typiquement, quelqu'un aurait un défaut, l'analyserait et analyserait le défaut, mais ils seraient liés à, je ne sais pas, un Trello, un Jira auquel personne n'avait accès. Et tout d'un coup, vous avez perdu le genre de collaboration en réseau où les équipes peuvent obtenir l'information de manière autonome. Parce que tu devais les appeler et dire, oh, tu peux me donner accès à ton Jira ou quoi que ce soit ? Il y a donc eu beaucoup de travail sur la façon de s'assurer que nous obtenions les informations pertinentes, toutes au sein de ce modèle, afin que nous puissions réellement, euh, afin que les gens puissent réellement l'utiliser sans contacter le créateur.
[00:35:40] Et enfin, un gros, euh, gros sujet, l'architecture modulaire, donc investir dans la conception, la maintenance d'une architecture modulaire avec des API robustes. J'illustre ceci avec Stripe parce que je pense que Stripe a vraiment fait une percée en nous montrant à quoi peut ressembler une API incroyable. Euh, je ne suis pas vraiment sûr quel mot il y a pour ce terme, une API de produit ou une API de qualité de produit. Euh, mais oui, il y a quelque chose à propos de s'assurer que l'API est très bien conçue pour que tout fonctionne.
[00:36:14] Euh, je peux vous partager notre expérience, donc, euh, clairement, nous ne construisons ou n'adoptons que des systèmes avec de bonnes API maintenant dans vos organisations. Euh, bizarrement, il y a encore quelques systèmes qui n'ont pas d'API. Euh, et cela est maintenant clairement un grand signal d'alarme pour nous. Et aussi, quand vous examinez des systèmes, la qualité de l'API est maintenant un argument important pour nous.
[00:36:40] Euh, c'est malheureusement une image réelle de notre système informatique, alors que vous pouvez voir qu'il n'est pas entièrement modulaire. C'est un peu non. Euh, et bien sûr, l'utilisation de ces API nous permet de synchroniser toutes les données dans un entrepôt de données bien conçu, bien conçu pour le moment, j'espère que nous maintiendrons cela. Euh, et cela apporte beaucoup de valeur en termes de permettre aux équipes partout de faire des choses sans compter sur, sans être dépendantes d'autres équipes. Euh, un exemple que je peux vous donner, euh, il y a pas mal de petits exemples, mais il y en a pas mal et je pense qu'ils sont très très gratifiants. De, euh, équipes qui proposent des initiatives ingénieuses sans nécessiter l'approbation préalable de quiconque d'autre. Je pense que, euh, l'exemple que j'ai choisi est, euh, est ce que l'équipe de sécurité a fait. Ils ont donc créé un cockpit en utilisant un script qui se connecte à tous les différents systèmes informatiques et, encore une fois, en utilisant les API, est capable de détecter s'il y a, euh, des problèmes de sécurité potentiels. Et ce que je trouve inspirant, c'est que cela leur permet de signaler les problèmes, mais sans avoir à mettre en place un processus, imposer un processus, comme un processus de sécurité à chaque équipe pour vérifier, oh, vous savez, avez-vous fait cette liste de contrôle de sécurité ou autre, parce qu'ils sont capables de consommer les données et de le signaler si nécessaire.
[00:38:09] Et puis je suppose, euh, l'exemple le plus spectaculaire que je puisse vous donner, euh, d'architectures modulaires et de la manière dont elles peuvent autonomiser les équipes logicielles, euh, est lié au confinement du COVID-19. Euh, belle image. Euh, moins bonne période, mais bref, euh, donc le 19 mars 2020, euh, le gouvernement décide de, euh, mettre en place un confinement. Et il y a vraiment cette question, comment allons-nous aider l'économie à être résiliente et ils décident de donner des prêts, je veux dire, des prêts garantis aux entreprises. Et donc nous avons été chargés de construire la plateforme avec, vous savez, cette idée d'essayer de déployer 300 milliards d'euros. De prêts garantis par l'État. Et bien sûr, nous avons eu cinq jours pour construire ça.
[00:39:04] Euh, et, vous savez, la combinaison d'aller vite et bien sûr comme la la la la mission inspirante, euh, nous a fait, vous savez, livrer la plateforme moins de cinq jours plus tard. Et ce n'était pas seulement, euh, prêt, mais c'était, vous savez, prêt à l'échelle. vont aider l'économie à être résiliente et ils décident d'accorder des prêts, je veux dire des prêts garantis aux entreprises. Et donc, nous nous sommes retrouvés chargés de construire la plateforme avec, vous savez, cette idée d'essayer de déployer 300 milliards d'euros de prêts garantis par l'État. Et bien sûr, on nous a donné cinq jours pour construire ça. Et, vous savez, la combinaison d'aller vite et bien sûr, comme la la la mission inspirante, euh, nous a fait, vous savez, livrer la plateforme moins de cinq jours plus tard. Et ce n'était pas seulement, euh, prêt, mais c'était, vous savez, prêt à l'échelle. Et, euh, donc nous avons réussi à le mettre en production et en moins de 28 heures, nous avions déjà, euh, euh, répondu à 1 milliard d'euros de demandes de prêts. C'était donc assez incroyable. Euh, et bien sûr, en conséquence, ce succès a entraîné de nouvelles demandes et le nombre d'équipes a augmenté. Et vous avez toutes ces, vous savez, nouvelles fonctionnalités à construire, et cetera, et cetera. Et, euh, et bientôt ce que vous réalisez, c'est que l'étape de déploiement prend plus de jours qu'il n'en avait fallu pour construire et, vous savez, déployer toute la plateforme initiale. Donc vous avez pu, vous savez, créer une plateforme très précieuse en production en cinq jours et tout ce qu'il vous faut, c'est cinq jours juste pour faire des Q&A sur une fonctionnalité. Vous vous dites, wow, vous savez, quelque chose ne va pas. Euh, ici vous pouvez voir le graphique de, euh, euh, notre fréquence de déploiement, qui était d'environ quatre, cinq par jour. Il y avait beaucoup d'équipes. Euh, mais, vous savez, pas très frustrant d'attendre, je pense, au moins cinq ou six jours pour parfois, euh, déployer. Et, donc nous C'est très intéressant d'ailleurs, parce que vous vous vous retrouvez dans cette situation un peu comme une grenouille qui bout, parce que vous devez ajouter des fonctionnalités. Et, euh, ce n'est que lorsque la situation devient vraiment trop mauvaise que vous vous dites, ok, il faut faire quelque chose à ce sujet. Alors, il est temps de réagir, de prendre du recul par rapport à la pression de la livraison. Une certaine résolution de problèmes et certaines des réactions étaient une architecture plus modulaire, plus de services. Euh, un apprentissage intéressant, euh, de cette expérience, d'ailleurs, était le basculement de fonctionnalités pour, encore une fois, si vous voulez donner aux équipes le pouvoir de déployer en production, vous devez probablement séparer l'idée de déployer techniquement de déployer, euh, euh, au niveau du produit. Donc le basculement de fonctionnalités était essentiel là-bas. Et beaucoup plus de tests d'intégration automatisés. Euh, parce que vous voulez détecter les changements d'API, vous voulez détecter les problèmes de dépendances. Et cela a vraiment fait une énorme différence. Euh, parce que très rapidement la fréquence de déploiement est passée de cinq par jour à 40 par jour.
[00:41:49] Euh, et, euh, c'est la boucle, toute la boucle de cette présentation parce que ce que je trouve assez, euh, assez intéressant, c'est que, euh,
[00:42:01] réduire le temps de déploiement pour augmenter la fréquence des changements est fondamentalement l'équivalent logiciel de, euh, ce que je vous ai montré sur la première photo. Donc la première photo était une démonstration du SMED, le SMED est, euh, est l'acronyme de Single Minute Exchange of Die, qui est ce concept lean, euh, de travailler dur pour réduire le temps nécessaire pour changer la machine. Donc pour ceux qui ne sont pas de grands experts du lean, vous avez cette énorme machine et elle produit, je ne sais pas, une sorte de pièce. Et, euh, et et la question est, si vous, si ça vous prend des heures pour reconfigurer la machine afin de créer une nouvelle pièce, alors vous ne voudrez pas changer la, euh, la machine souvent et cela crée un énorme problème de flexibilité et cela a des effets d'entraînement dans toute la, la, la, l'usine et ensuite l'entreprise. Et si vous travaillez au contraire à rendre la reconfiguration de la machine super facile, alors vous pouvez changer très fréquemment pendant la journée et vous avez alors une énorme flexibilité. Et donc vous pouvez voir le parallèle entre, vous savez, un grand concept lean et, et je pense un grand concept devops ici.
[00:43:20] Et je suppose que c'est, euh, pour moi, le message à retenir. Euh, c'est que, euh, Nous aimons Agile. Je dis nous, j'espère que j'ai, j'espère que j'ai raison. J'aime Agile, nous aimons Agile. Parce que, et je pense que la raison pour laquelle nous, nous, vous savez, les gens qui ont adopté Agile, vous savez, l'aiment et ne veulent pas revenir en arrière, c'est parce que cela favorise vraiment cette, vous savez, étincelle magique d'ingéniosité lorsque, vous savez, dans une petite équipe, comme créer des solutions plus précieuses, plus créatives. De meilleures solutions. Euh, et, euh, la pensée Lean est, est vraiment un endroit où vous pouvez trouver un principe éprouvé par le temps pour étendre ces avantages à une plus grande organisation. Euh, et, et tout en partageant, tout en maintenant cet objectif du Manifeste Agile. Mais vous pouvez aussi ajouter à cela l'innovation technologique et maintenir l'autonomisation de l'équipe à mesure que l'organisation grandit.
[00:44:21] Donc, j'espère, euh, vous avoir donné quelques idées supplémentaires sur la façon de développer votre organisation et de maintenir une culture Agile à l'échelle. Euh, parce que nous avons besoin de plus d'organisations déployant de l'ingéniosité à grande échelle. Merci.
[00:44:45] Et juste un rappel, vous pouvez précommander le livre. Avez-vous des questions?
[00:44:52] Ok, première question, ah, avez-vous besoin d'un, je n'ai pas besoin d'un micro.
[00:45:01] Euh, le point de départ de votre présentation était, euh, le manifeste agile qui le fait pour le jeu. Et j'ai adopté les principes lean pour le début et pour expliquer aux gens pourquoi adopter la culture agile. Pouvez-vous nous donner une première ligne ou un conseil ?
[00:45:25] Alors, euh, c'est très intéressant parce que je me demandais, vous savez, combien je devrais dire sur différentes choses et on m'a demandé de me concentrer sur le réseau d'équipes technologiques et je pense que c'était une très très bonne idée parce que cela permet d'aller un peu plus loin. Et j'ai fait allusion à pourquoi, euh, les individus en interaction ne s'adaptent pas. Euh, je pense que c'est, vous savez, la bonne illustration est que, euh, le nombre d'interactions est le carré du nombre d'individus. Donc il y a quelque chose qui ne fonctionne pas si si vous Donc pour celui-ci, pour les individus et les interactions, je pense que c'est un argument un peu simpliste, mais je pense qu'il saisit toujours le problème. C'est que le nombre d'interactions est le carré du nombre d'individus. Donc si vous ne trouvez pas un moyen de couper ces interactions, ce que, vous savez, Jeff Bezos appelle l'élimination de la communication, vous avez quelque chose qui ne fonctionne pas. Je peux essayer de bien sûr, tout cela est dans le livre. Euh, mais je peux essayer de le faire rapidement et, oui, j'aurai quelques minutes.
[00:46:31] Donc, la collaboration client, je pense que c'est une chose intéressante, euh, vous savez, ce que j'aime dans mon expérience Agile, c'est vous avez le client dans l'équipe, c'est quelque chose que vous retrouvez dans, euh,
[00:46:44] Je pense que c'est Ward Cunningham ou Ken Beck, vous savez, qui dit en programmation extrême, le client est dans l'équipe. Le client est dans l'équipe. Donc le client, vous avez donc vraiment cette collaboration intense. C'est et c'est c'est incroyable. Je pense que c'est incroyable. Euh, maintenant, expérience de pensée, vous grandissez pour devenir une très grande organisation. Votre client est une très grande organisation. Comment créez-vous cette collaboration ? Il y aura des gens qui ne seront pas en contact indirect avec le client. Donc il y a, vous savez, encore une fois, vous pouvez utiliser un peu de technologie, vous pouvez utiliser les tests AB, les plateformes d'expérimentation, beaucoup de choses comme ça. Ce qui permet à beaucoup de personnes dans l'organisation d'avoir un, euh, pas un contact direct, mais disons un accès direct à ce que les clients veulent. Euh, mais il y a quelque chose, en tant que leader de l'organisation, vous avez probablement besoin de quelque chose d'un peu légèrement différent parce que si vous dites aux gens, dans cette organisation, je veux que tout le monde collabore avec le client, je suis presque sûr que beaucoup de gens diront, qu'est-ce que vous voulez dire, vous savez, c'est, euh, tandis que si vous dites, vous savez, disons que, dans cette organisation, je veux que tout le monde se concentre sur la valeur pour le client et voit comment il est lié à cette valeur pour le client. Ça, ça marche.
[00:48:00] Euh, euh, Commençons par réagir au changement. Répondre au changement, euh, je pense que c'est une idée très intéressante et je fais d'ailleurs la comparaison entre Google et Amazon dans le livre. C'est parce que Google et Amazon sont tous deux incroyables pour répondre au changement. Euh, Google est probablement la première organisation à avoir rendu célèbre les tests AB. Euh, et puis en même temps, quand vous regardez leur taux de réussite en termes de lancement de nouveaux produits, ce n'est pas si incroyable que ça. Et donc je pense qu'il y a quelque chose où, lorsque vous êtes une très grande organisation, euh, vous savez, vous devez vous appuyer sur les apprentissages passés et les connaissances passées. Et si vous n'avez pas cela, alors vous avez soit des équipes qui, vous savez, réagissent au changement mais n'ont en fait aucun impact sur l'ensemble de l'organisation parce qu'elles sont, vous savez, elles n'influencent pas l'ensemble de l'organisation, elles sont autonomes. Ou vous avez la haute direction qui essaie de réagir au changement et parce qu'ils sont très loin du terrain, ils réagissent probablement trop tard, ils réagissent probablement mal. La question est donc vraiment : comment habiliter les équipes sur le terrain à réagir au changement de manière à ce qu'elles puissent ensuite le transmettre à l'ensemble de l'organisation et ne pas mettre en danger l'ensemble de l'organisation ? Et ma réponse à cela est : si vous avez une organisation apprenante forte, où vous savez que les gens, vous savez, expérimentent, donc ils, vous savez, ils font ils essaient avant de de de s'engager dans des changements, ils apprennent, ils réutilisent aussi les apprentissages passés, ils s'assurent d'apprendre aussi sur les autres ce que font les autres. Alors vous obtenez alors le bénéfice de répondre au changement dans une grande organisation. Et puis le logiciel fonctionnel, c'est un peu plus difficile parce que, euh,
[00:49:54] ce qui n'est pas ce qui n'est pas scalable dans un logiciel fonctionnel, c'est, euh, plutôt le fait qu'il ne traite pas vraiment ce qui se passe quand le logiciel devient très complexe. Vous savez, si vous dites à quelqu'un, vous savez, je veux que vous sortiez un logiciel fonctionnel 40 fois par jour, et vous êtes une organisation de mille ingénieurs logiciels, ça va être assez, euh, vague comme, comme, comme ligne directrice. Donc vous pouvez dire DevOps, vous pouvez dire déploiement continu. Ce que j'aime à dire du premier coup et juste à temps, c'est que je pense que vous pouvez vraiment voir comment DevOps et le déploiement continu ont beaucoup appris sur ces sujets. Donc, en revenant à la source, vous, vous élargissez votre compréhension.
[00:50:40] Est-ce que ça répond à votre question ?
[00:50:44] D'autres questions?
[00:50:53] Eh bien, le timing était bon.
[00:50:56] Merci beaucoup, euh, et j'ai hâte d'en discuter.

Transcription (Traduit)