Alexey Krivitsky & Roland Flemm - The value of Org Topologies in the era of DIY-frameworks

[00:00:05] Comme nous n'avons pas de papier, je pense que nous allons devoir improviser, Roland, aujourd'hui.
[00:00:09] Faisons cela.
[00:00:11] En français ?
[00:00:12] Non. Merci non.
[00:00:17] Bonjour à tous. Ola. Bonjour à tous.
[00:00:22] Oui, donc, euh, ce sera en anglais. Désolé, mon français est un peu.
[00:00:28] Cette conférence porte sur les ologies à l'ère des cadres de travail DIY.
[00:00:34] Attends, attends. C'est quoi ces frameworks DIY, Roland ?
[00:00:37] DIY. Bricolage. Oui. Alors, faites-le vous-même. Nous sommes maintenant un peu habitués à Agile, c'est là depuis des années déjà. Et ce que nous voyons, en tant que consultants, c'est que les organisations vont commencer à choisir et, vous savez, à sélectionner des choses de différents cadres de travail et à les combiner. Et il y a des frameworks destinés à, eh bien, voici un tas d'éléments et essayez simplement de faire quelque chose de sympa. C'est l'ère du 'faites-le vous-même'.
[00:01:09] Oui, et euh, vous savez, nous vous présentons le sujet des topologies de travail. Nous venons de terminer un cours de deux jours ici à Paris. C'est donc un grand sujet, c'est un sujet vaste. Nous avons à peine réussi à le traiter en deux jours. Donc maintenant, nous avons moins d'une heure. Et nous devons toujours trouver une fenêtre à travers laquelle expliquer ce sujet. Et cette fois, le choix était évident. Parce que nous sommes à une conférence complète, nous avons décidé de nous concentrer sur le flux. Alors, euh, en parlant de flux.
[00:01:41] Je dois vous mettre en garde. Car ce que vous êtes sur le point d'entendre et de voir pourrait être troublant et provoquer des effets secondaires inattendus. D'accord ?
[00:01:54] Donc, euh, nous parlons de choses qui iront un peu à contre-courant ou de choses qui pourraient être considérées comme normales et acceptées, peut-être dans votre tête, peut-être au sein de votre équipe, de votre entreprise ou de votre industrie. Alors, soyez prévenus, d'accord ?
[00:02:10] Oui, et pourquoi est-ce ainsi ? Parce que comme le dit notre mentor et coach Craig Larman, on ne peut pas 'dés-voir' une optimisation locale. Vous ne le ferez pas une fois que vous l'aurez vu, alors j'espère que dans cette conférence, vous pourrez apprendre.
[00:02:24] Et voir quelques optimisations locales que lorsque vous retournerez aux bureaux demain ou les jours suivants, vous commencerez à les voir et des pensées différentes pourraient surgir dans votre esprit. C'est du moins notre espoir pour cette discussion. Quelques mots sur nous, afin que vous connaissiez notre contexte et ce dans quoi nous sommes bons.
[00:02:46] Oui, ce sont les meilleures versions de nous-mêmes, générées avec l'IA. Euh, mon nom est Roland Flam, voici Alexey Krivitsky. Nous avons sué pendant environ deux ans, plus de deux ans sur le sujet du développement organisationnel, nous appelons notre projet 'orgologies'. Et nous consacrons des décennies de connaissances, euh, à la fois au développement logiciel et au conseil.
[00:03:14] Nous sommes tous les deux formateurs Scrum, mais de différentes églises. Donc, comme nous disons, nous allons à différentes églises. Nous prions les mêmes dieux de l'agilité. L'adaptabilité, le côté droit de cette image cependant, encore une fois, à propos du flux, n'est-ce pas ? Nous nous sommes retrouvés à nager à contre-courant en quelque sorte. Donc nous avons assisté à quelques conférences ici et bien sûr nous savons ce qui se passe dans l'industrie en suivant beaucoup d'entre vous sur LinkedIn. Alors nous nous sommes rendus compte que nous ne sommes pas vraiment des gens grand public. Nous n'essayons pas de dire des choses populaires. Nous n'essayons pas de dire des choses qui vous mettent à l'aise. Euh, non pas parce que nous voulons être spéciaux, euh, mais parce que nous croyons que le monde n'est pas noir et blanc, n'est-ce pas ? Et la mission des topologies est de nous aider tous à créer des organisations un peu plus réfléchies, n'est-ce pas ? Et parce que ce monde n'est pas noir et blanc, bien sûr, nous aimerions vous montrer plus d'options. N'est-ce pas ? Nous ne disons pas que certaines options sont meilleures ou pires que d'autres, tout dépend du contexte. Donc ceci est la carte des org topologies et nous n'allons pas entrer dans chaque case. Aujourd'hui, vous parlerez en dehors des sentiers battus. Si je peux me permettre. Euh, mais essentiellement, nous allons parler de ce panel multicolore de différentes options que vous avez, dans l'espoir d'élargir votre compréhension de ce qui est possible dans votre organisation.
[00:04:47] Quand nous regardons la boîte, la carte que nous avons, elle contient 16 boîtes. Et nous pouvons les utiliser pour cartographier, tracer et voir des écosystèmes, donc la combinaison de cases crée de la valeur, et la carte est une invitation pour vous à essayer de voir qui est impliqué dans la création de valeur au sein d'un département ou de toute l'organisation et à créer ces choses que nous appelons des écosystèmes. Et une fois que vous voyez votre écosystème, vous pouvez en parler, et vous pouvez voir ce que cela nous apporte. Et peut-être aussi quels types d'options vous voyez pour, eh bien, redessiner votre écosystème.
[00:05:26] Oui, nous essayons donc de rendre les choses invisibles un peu plus visibles afin que vous puissiez avoir des discussions merveilleuses et significatives sur votre organisation et sur le vecteur de développement de votre organisation. Bref, euh, revenons au flux.
[00:05:41] Oui.
[00:05:44] Présentons Flowtech. C'est une entreprise imaginaire. Et leur énoncé de vision est : nous créons un monde d'IoT alimenté par l'IA sur la blockchain, l'Internet des objets.
[00:05:55] Quelqu'un travaille chez Flowtech ?
[00:05:57] Non. Bien, bien, bien.
[00:06:01] Maintenant, il y a un cas d'utilisation décrit. Je vais vous le lire pour que vous compreniez le genre de défis qu'ils rencontrent. Ils créent des mondes où votre grille-pain élabore la stratégie de votre petit-déjeuner grâce à l'IA. Votre réfrigérateur échange des crédits d'énergie sur la blockchain pour garder vos légumes frais, et votre cafetière est alimentée par le cloud pour préparer votre café à la perfection avant même que vous ne vous réveilliez.
[00:06:25] Waouh.
[00:06:29] Quoi qu'il en soit, euh, bien sûr, ils ont des défis et d'abord, regardons ce qui se passe au niveau du terrain de cette entreprise dans l'IT. Bien sûr, l'IT est toujours quelque part au niveau du sol ou parfois sous le sol, n'est-ce pas ?
[00:06:40] Eh bien, ils ne sont pas au sous-sol.
[00:06:41] Eh bien.
[00:06:42] Pas celui-ci.
[00:06:44] Ces gars ne sont pas au sous-sol, n'est-ce pas ? Ils ont déjà été élevés, améliorés, portés à un meilleur état d'être. Et au département IT, il y a ce gars appelé Florian, aussi connu sous le nom de Flow, n'est-ce pas ? Et ce gars est notre chef d'ingénierie. Et au cours des dernières années, il a visité différentes conférences, lu tous les livres que l'on peut trouver sur ce sujet et il a beaucoup investi dans la création d'équipes à flux rapide comme certains d'entre vous, ou peut-être la plupart d'entre vous et la plupart d'entre nous l'ont fait, n'est-ce pas ? Euh, il a lu tous ces livres et il a pratiqué avec succès des frameworks modernes comme Scrum et Slave. Et bien sûr, il s'est plongé dans la nouvelle ère des frameworks DIY comme unkicks et team apologies. Donc il est vraiment, vous savez, bien informé.
[00:07:34] Il est compétent.
[00:07:35] En quelque sorte.
[00:07:38] Vous savez, il a exploré tout l'espace et a essayé d'en tirer les meilleures pièces, comme la plupart d'entre nous, parce que nous sommes à l'ère des frameworks DIY, comme quelqu'un l'a dit avant nous, n'est-ce pas ? Nous ne croyons pas aux frameworks agiles, etc. Donc nous devons choisir différentes choses, et cetera, et cetera, et cetera. Il n'est pas seul dans l'entreprise. C'est un bon.
[00:07:57] Non, nous avons une deuxième personne que nous voulons présenter. C'est Florence, nous avons pensé utiliser un nom français pour l'occasion. Et elle est développeuse et elle travaille dans une équipe très spécialisée qui travaille sur l'IAM, c'est-à-dire la gestion des identités et des accès. Et ils ont des solutions de stockage de références distribuées et basées sur le cloud. Waouh.
[00:08:21] Cette équipe est aussi connue sous le nom d'équipe des mots de passe oubliés.
[00:08:24] D'accord, d'accord, eh bien, ça ne sonne pas aussi sexy.
[00:08:29] Eh bien, elle est heureuse dans son équipe, donc elle a beaucoup à faire. Elle est occupée.
[00:08:35] Oui, et ils suivent les conseils du conférencier principal d'hier et d'autres conférenciers, Sunday Hog et Dawn, n'est-ce pas ? Parlait hier. Et bien sûr, ce n'est pas nouveau que, eh bien, il faut casser le monolithe en morceaux et il faut accélérer le développement. Et son équipe se débrouillait à merveille, n'est-ce pas ? C'est le flux de l'équipe des mots de passe oubliés. Ils sont l'équipe la plus rapide de l'entreprise. Ils peuvent mettre les choses en production. Et nous en fait, nous pourrions paraître sarcastiques, mais nous ne le sommes pas. Je veux dire, c'est vraiment important, n'est-ce pas ? De décomposer les choses. En tant que développeur, je fais cela depuis de nombreuses années et j'aide d'autres entreprises à le faire. C'est donc juste. Ce n'est pas vraiment une caricature. C'est ce qui se passe réellement dans l'industrie. Beaucoup de gens se concentrent sur ces choses et ces choses sont les bonnes choses sur lesquelles se concentrer.
[00:09:25] Exactement, et surtout si vous regardez ce qui se passe dans l'IT, alors nous pouvons célébrer toutes sortes de succès avec ces stratégies. Je veux dire, en IT, nous voyons des équipes avec des gens heureux et c'est parce que la direction a déployé tant d'efforts pour réduire leur charge cognitive. Et en créant cette propriété privée, c'est donc très clair, vous savez, tout le monde connaît sa zone de responsabilité. Il y a de la clarté partout et cela crée des équipes, de nombreuses équipes qui sont vraiment dans un état d'hyper-flux. Ce n'est pas sarcastique. C'est ce que les gens font.
[00:10:01] Très bien, alors prenons l'ascenseur et montons à la salle de réunion pour voir ce qui s'y passe. Et actuellement, il y a une réunion dans la salle du conseil. Très bien, et quelqu'un dit pour aller plus vite, l'année dernière, nous avons doublé le nombre d'équipes de 30 à 65.
[00:10:20] Mais euh, oh, je ne le vois pas. Et nos coûts ont augmenté de 300%.
[00:10:25] Et notre retour sur investissement a chuté de 25% et les CAPEX, OPEX, SCHMEX, tout est en baisse. Que se passe-t-il ?
[00:10:33] Oui.
[00:10:34] En d'autres termes.
[00:10:35] Waouh, l'IT est en train de bousculer les choses. Ouais, ouais.
[00:10:40] Qui blâmer ? Toujours l'IT, n'est-ce pas ?
[00:10:42] Alors.
[00:10:45] Mais, oui, c'est ça. Des têtes vont tomber. Nous avons besoin de quelqu'un pour en être responsable.
[00:10:50] Apportez-nous la tête.
[00:10:51] Le chef de l'informatique. Oui, nous avons besoin de lui ici.
[00:10:53] Alors maintenant, Florian prend l'ascenseur, interrompt son travail et doit monter à l'étage supérieur pour avoir une discussion. Alors s'il vous plaît, dans une minute, ayez une discussion.
[00:11:06] Tournez-vous vers vos voisins, dites bonjour et vous pouvez parler en français ou dans toute autre langue. Ayez une discussion, quel genre de conversation pensez-vous qu'il se passe dans la salle du conseil quand Florian entre dans ce groupe de personnes intéressant.
[00:11:21] Ayez une discussion. Quelques minutes.
[00:11:26] Oui, n'est-ce pas ? Certaines personnes n'ont même pas besoin de parler, elles ont déjà eu cette discussion. Ils savent juste ce qui se passe là-bas. Oui. Peu importe ce que vous avez discuté et réalisé, nous pouvons probablement tous être d'accord sur une chose, c'est que, vous savez, ces gens, Florian et les membres du conseil, ils parlent des langues un peu différentes, n'est-ce pas ? Eh bien, que disent les membres du conseil ?
[00:11:47] Eh bien, ils parlent de parts de marché, de profits, ils voient le ROI, ils ont des actionnaires à qui ils doivent rendre des comptes.
[00:11:53] Et il dit qu'il vient, laissez les excuses d'équipe, ça va flotter, toutes ces choses qu'il a essayées et qu'il croit fonctionner.
[00:12:00] Oui, parce qu'il n'est pas réticent, mais écoutez, tous les chiffres sont dans le rouge, vous savez, le ROI baisse, l'OPEX, quoi que ce soit.
[00:12:08] Et Florence dit, vous savez, mes mesures, que je peux collecter, sont en fait vertes. C'est la vélocité de l'équipe, c'est le temps de cycle, c'est la fréquence des déploiements, toutes les métriques Door sont vertes, donc.
[00:12:19] Quel est le problème ?
[00:12:22] Il y a un problème, cependant.
[00:12:24] Mesdames et messieurs, dernières nouvelles. Dernières nouvelles.
[00:12:32] Essentiellement, Haier a construit une machine qui vous permet de faire l'impossible. Vous pouvez maintenant tout cuisiner chez vous.
[00:12:44] C'est la publicité qu'ils diffusent partout en Europe. L'expérience du canard laqué. Mettez-le au four le matin. Rentrez à la maison le soir et vous avez le parfait canard laqué. C'est une vraie menace pour Flowtech.
[00:12:58] Haier est en train de prendre tout le marché avec les appareils électroménagers IA, ils peuvent en fait remplacer tout ce que Flowtech a construit. Alors, réparez-le.
[00:13:10] Réparez l'IT.
[00:13:12] Tous sur le pont.
[00:13:16] Maintenant, sortons de l'histoire et devenons un peu plus sérieux, n'est-ce pas ? Alors Florian, il a cherché ces différentes choses. Là-bas dans les livres, les conférences, et il a expérimenté différentes choses. Et bien, il voulait résoudre les problèmes qu'ils avaient. Mais ensuite, il a réalisé avec le temps et surtout après cette discussion qu'ils ont eue dans la salle du conseil, en fait, j'espère que personne n'a volé par la fenêtre pendant cette discussion, c'est que la solution. Elles résolvent des problèmes existants, et étonnamment, elles peuvent aussi en créer de nouveaux. Ainsi, chaque solution que vous apportez actuellement pour résoudre vos problèmes connus, finira par créer un nouveau problème, de manière imprévisible, qui, espérons-le, sera un meilleur problème à résoudre. Alors il dit, eh bien, chaque équipe est très rapide dans son propre contexte délimité. Mais essentiellement, aucune des équipes ne peut relever le défi actuel que nous avons. Et bien, si nous devons replanifier et réagir à cette menace que nous avons dans l'entreprise, toute la feuille de route de la R&D doit être abandonnée et cela prendrait une éternité car nous ne le faisons qu'une fois par an lorsque les cycles budgétaires arrivent, n'est-ce pas ? Nous devons donc être plus rapides que nous le sommes maintenant. Et il dit aussi, vous savez, je pensais que ma R&D était adaptative parce que, eh bien, partout où je vais, toutes ces méthodes disent, nous vous aidons à construire des systèmes adaptatifs, plus adaptatifs, plus adaptatifs.
[00:14:42] Système, mais oui, ils sont peut-être adaptatifs dans une certaine mesure. Mais en fait, nous étions juste en train de nous améliorer à faire ce que nous savions déjà. Nous pouvions donc nous adapter lorsque la stratégie était stable, mais maintenant que tout le paysage change.
[00:14:58] Nous avons réalisé, oh, l'adaptabilité est coûteuse. Les coûts de commutation seront trop élevés. Oui.
[00:15:04] Donc il y a des choses qui se passent maintenant dans le monde pour lesquelles nous n'étions pas préparés, et c'est une surprise. C'est vraiment une surprise. Bonne nouvelle. Y en a-t-il ?
[00:15:17] J'espère bien.
[00:15:17] Oh.
[00:15:20] Il y a cette conférence à laquelle vous pouvez aller, comme Flowcon.
[00:15:24] Et c'est ce que Florence et Florian ont fait. Ils ont pris le train et sont venus à Paris et bien, ils étaient dans l'audience. Et ils sont en fait allés à cette super euh, comment ça s'appelle, keynote à 14h.
[00:15:39] Oui, alors ils sont allés à cette conférence d'Alexey et Roland, ces deux messieurs. Et dans cette conférence, Flo et Flo, Florian et Florence. Ils ont été initiés à l'idée que, oui, l'optimisation des flux est importante, n'est-ce pas ? Donc ce que vous avez fait chez Flowtech est génial. Vous avez essayé de compléter ces compétences, d'ajouter les compétences nécessaires, alias les capacités, de développer ces équipes et c'est un travail dont chaque membre de l'équipe, chaque Scrum master, chaque coach, chaque responsable de l'ingénierie. Devrait être fier. Oui.
[00:16:15] C'est ce que nous avons fait au cours des dernières années, en nous préparant, vous savez, avec l'Agile. Nous avons investi dans la création de ces équipes à flux plus rapides. Nous essayions de les rendre plus capables, d'améliorer les définitions de 'fini', plus rapidement, afin de réduire leur déficit de capacités pour essayer de leur permettre de tout faire.
[00:16:36] Une autre chose que Flo et Flo ont apprise lors de cette conférence, n'est-ce pas ? C'est que ce mouvement, ce mouvement horizontal, cette direction dans laquelle ils ont investi peut aussi être appelé une première vague agile. Ce n'est pas le agile complet, mais c'est un vecteur important, c'est une partie importante, un composant important de l'agilité. Et certaines personnes l'appellent la première voie de l'agilité. Eh bien, vraisemblablement, il y a plus que juste.
[00:17:02] Ces gens l'appellent un, oui, ces messieurs.
[00:17:09] Mais bien sûr, il y a un autre fossé là-haut, que ces gens appellent un écart de valeur.
[00:17:15] Et un écart de valeur est une chose différente, n'est-ce pas ? L'écart de valeur est différent dans la façon dont les équipes comprennent la valeur et ce qu'elles appellent des produits. Et ce que les parties prenantes de l'entreprise et les clients extérieurs à votre bâtiment appellent valeur et appellent produits. Et ce qu'on leur a dit lors de cette conférence, c'est que. Eh bien, si vous créez ces équipes qui sont super étroitement concentrées parce que vous voulez vraiment les rendre rapides, n'est-ce pas ? Et la seule façon, essentiellement, de rendre les équipes vraiment rapides est de limiter le nombre de choses qu'elles possèdent et dont elles sont responsables. Mais alors ces gens pourraient penser qu'une application iOS d'une banque est un produit.
[00:17:57] Un service qui fait quelque chose est un produit. Ce composant d'authentification sur lequel Florence a travaillé est un produit ou une plateforme.
[00:18:04] Exactement.
[00:18:06] Mais essentiellement du point de vue du client, une application bancaire n'est pas un produit, c'est juste une interface pour aller au fond de la banque et parler au système bancaire dorsal pour voir mes transactions sur mon écran mobile, n'est-ce pas ?
[00:18:23] Ainsi, l'axe vertical que nous proposons d'introduire pour améliorer votre entreprise a à voir avec l'étendue du travail, c'est une orientation produit. Non seulement en regardant à quel point mon équipe est performante, quelles sont ses capacités, mais aussi à quel point elle connaît le produit que le client achète réellement chez nous. Et ce n'est pas exactement dans le flux des autres conférences que nous avons entendues auparavant.
[00:18:52] N'est-ce pas, et la véritable agilité organisationnelle ou, si vous voulez, l'agilité d'entreprise ou quoi que nous puissions l'appeler dans notre industrie qui se produit maintenant. Et cela va devenir de plus en plus courant grâce à l'IA et à d'autres entreprises qui essaient cela. Aidera à créer ce haut niveau d'organisation qui maîtrise les deux. Non seulement les capacités et le flux dans les équipes, mais aussi aider les équipes et les développeurs à avoir une compréhension plus large de la valeur et du client, idéalement proche de la définition de la valeur et du produit que les clients ont.
[00:19:30] Oui. C'est ce que nous appellerions une deuxième vague du mouvement agile. Pour inclure cette connaissance produit, pour commencer à combler cet écart de valeur.
[00:19:42] Maintenant, peut-être que c'était un peu trop philosophique et qu'il y avait trop de mots et trop d'images difficiles à comprendre. Donc nous aimerions que vous rameniez cela à la maison et encore une fois, cette fois s'il vous plaît parlez à quelqu'un, n'est-ce pas ? Vous pourriez en fait vouloir vous asseoir plus près de quelqu'un et avoir une discussion de quatre minutes. Eh bien, si votre organisation décidait d'y aller, vous savez, euh, qu'est-ce que cela signifierait pour l'organisation de combler les deux lacunes ? D'accord, alors s'il vous plaît, discutez, qu'est-ce que cela signifiera dans votre organisation si vous décidez d'essayer de combler ces deux lacunes ? Et si vous n'avez pas compris ce que sont ces lacunes, demandez à l'autre personne. Peut-être qu'elle comprend, discutez-en s'il vous plaît. Très bien, merci.
[00:20:26] C'est bien d'entendre les gens discuter à la conférence. Merci de l'avoir fait.
[00:20:32] Il faut le faire en français. On reprend, mesdames et messieurs.
[00:20:38] Ils m'ont dit de dire ça, je ne sais pas.
[00:20:40] Roland parle bien français, ouais.
[00:20:42] Toi aussi.
[00:20:43] D'accord.
[00:20:44] D'accord.
[00:20:46] D'accord, alors, euh, peut-être que c'était déroutant, n'est-ce pas ? Peut-être que ce n'était pas clair parce que ce mouvement ascendant n'est pas vraiment, vraiment connu dans l'industrie, je pense. Tout le monde parle de flow. N'est-ce pas ? Peu de gens parlent, oui. Peut-être que, peut-être que quelque chose d'autre est aussi important. Nous ne disons pas que le flux n'est pas important. Le flux est super important. Mais est-ce le seul composant ? Nous en connaissons au moins deux, peut-être qu'il y a 5, 10, 100 autres composants différents auxquels nous devrions penser. Et si nous connaissons de nombreux composants, lequel est votre composant principal à optimiser et lequel sacrifier ou vice versa ? Donc Flo avait aussi beaucoup de ces idées en tête maintenant.
[00:21:32] Peut-être nous sommes-nous trop concentrés sur le flux au niveau de l'équipe. Dépensez beaucoup d'argent pour ça.
[00:21:43] Eh bien, et en fait, je n'ai jamais considéré le produit que je mentionne. À quoi cela ressemblerait-il avec mes équipes actuelles ? C'est difficile.
[00:21:54] Et euh, est-ce que cela signifie que toutes les équipes vont réellement collaborer intensivement sur la même stratégie produit, c'est comme grand. Eh bien, difficile. Hmm.
[00:22:06] Et bien sûr, d'autres pensées lui traversent l'esprit, comme : eh bien, toutes les équipes travaillent comme une seule équipe d'équipes. Comment cela est-il censé fonctionner, n'est-ce pas ?
[00:22:17] Cela signifiera-t-il que nous devrons partager le même contexte plus large, non pas divisé, mais réellement partager un espace de travail plus vaste ?
[00:21:32] Peut-être nous sommes-nous trop concentrés sur le flux au niveau de l'équipe. Dépenser beaucoup d'argent là-dessus.
[00:21:42] Eh bien, et en fait, je n'ai jamais considéré le produit que je mentionne. À quoi cela ressemblerait-il avec mes équipes actuelles ? C'est un peu difficile.
[00:21:53] Et cela signifie-t-il que toutes les équipes vont vraiment collaborer intensivement sur la même stratégie produit, ce qui est énorme. Eh bien, difficile.
[00:22:06] Et bien sûr, d'autres pensées se bousculent dans sa tête, comme, eh bien, toutes les équipes travaillent comme une seule équipe d'équipes. Comment ça doit fonctionner, n'est-ce pas ? Cela signifiera-t-il que nous devons partager le même contexte plus large, non pas divisé, mais réellement partager un espace de travail plus large ? Elle pense que ça pourrait être intéressant, dit-elle. Mais alors nous devrons abandonner le backlog individuel de notre équipe, la feuille de route et le travail de découverte que nous avons fait pour le travail d'équipe sur l'authentification et les mots de passe oubliés. Et alors, qu'en est-il des autres équipes ? L'équipe de recherche, l'équipe de catalogue, l'équipe de caisse, l'équipe de reporting, l'équipe de surveillance ? Doivent-elles toutes simplement arrêter de faire ce qu'elles font ? Juste unir leurs forces et faire d'autres choses ? Qu'arrive-t-il aux backlogs des propriétaires de produits et à tout cet investissement ?
[00:22:59] Des équipes travaillant comme une seule grande équipe. Eh bien, vous savez,
[00:23:04] Je ne pense pas. Ce n'est pas efficace. Ça ne va pas marcher.
[00:23:09] Et qu'en est-il de la copropriété ? Si vous avez tous une certaine responsabilité, alors personne n'a cette responsabilité. Nous le savons tous, n'est-ce pas ? Cela ne va pas marcher. Surcharge cognitive. Je veux dire, comment pouvez-vous tout savoir d'un produit ? Les têtes vont exploser. Et comment serons-nous responsables ? D'accord ? Pas sous ma surveillance.
[00:23:30] Les équipes seront occupées à apprendre. L'apprentissage ne nous rapporte pas d'argent, n'est-ce pas ? Cela tuera le flux. Cela ne se produira pas.
[00:23:38] Justes remarques, n'est-ce pas ? Ces choses devraient se produire dans la tête des gens parce que ce sont des dilemmes, n'est-ce pas ? Ils n'ont pas vraiment une seule réponse. Et d'autres choses se passant dans sa tête, c'est comme si elle pensait, hé, J'ai travaillé dans une startup où nous programmions cinq systèmes différents dans trois langages différents. Et nous travaillons en fait comme une seule grande équipe. Elle pense. Et puis nous parlons aussi aux clients nous-mêmes. Eh bien, et tout ce sur quoi nous avons travaillé était pertinent, n'est-ce pas ? Si vous parlez au client au quotidien et que vous possédez tout ce qui s'y passe, comme si vous étiez dans une startup, tout ce sur quoi vous travaillez est pertinent. Votre équipe est toujours pertinente. Mais elle pense, hmm, je me demande si cela peut réellement être appliqué aux entreprises. Comme flo tec, ce ne sont pas des startups. bla bla bla, de nombreuses autres pensées et dilemmes se bousculent dans leur tête, n'est-ce pas ?
[00:24:37] D'accord, nous avons commencé avec cette citation, n'est-ce pas, de Craig Larman. On ne peut pas désapprendre l'optimisation locale. Une fois que vous l'avez vu, ça reste toujours avec vous, avec vous, n'est-ce pas ? Alors, plongeons, allons un peu plus loin dans cette pensée systémique appliquée au concept de conception d'organisation et approfondissons un peu plus ce sujet. Du point de vue de la pensée systémique, n'est-ce pas ? Si vous optimisez les parties individuelles du système, vous avez la garantie de ne pas obtenir un système optimisé dans son ensemble. C'est comme
[00:25:10] C'est une loi.
[00:25:11] C'est presque une loi, elle a été découverte dans les années 70, lorsque la pensée systémique a été réellement inventée, étudiée, prouvée dans différentes universités. Encore une fois, si vous essayez d'optimiser des parties individuelles, vous êtes garanti que ce n'est que par chance, que par hasard que l'ensemble du système s'améliorera. Nous comprenons tous cela. Et plus il y a de pièces, plus il y a de connexions, moins il y a de chances que cela se produise.
[00:25:36] Alors, pour rendre cela un peu moins abstrait, le système, c'est ce que nous appelons l'organisation qui essaie de produire de la valeur. Et les parties de ce système sont les équipes. Donc si vous continuez à injecter beaucoup d'énergie et à optimiser des équipes individuelles, alors les chances sont, eh bien, il n'y a aucune chance, alors vous savez avec certitude que toute votre organisation ralentira finalement. Et nous voyons cela arriver.
[00:26:03] C'est la pensée systémique. Tous ceux qui ont étudié, appris, fait des recherches sur la pensée systémique sur Wikipédia, connaissent cette chose. Mais il y a un aspect contre-intuitif à cela, n'est-ce pas ? Donc, afin d'optimiser l'ensemble, nous devons en fait sous-optimiser les parties. C'est soit ça, soit ça. Donc si nous nous soucions de l'ensemble, des parties vont souffrir. Elles doivent souffrir et elles doivent accepter cette souffrance pour le bien supérieur. Si nous valorisons l'adaptabilité comme objectif d'optimisation organisationnelle, alors peut-être que certaines équipes n'auront pas le flux le plus rapide possible. Parce que de temps en temps, elles devront changer de contexte pour rester pertinentes et apprendre quelque chose avec lequel elles n'avaient jamais travaillé auparavant. Et cela va en fait très à l'encontre de beaucoup de choses que nous entendons à cette conférence et à d'autres conférences, et ce qui est dit dans de nombreux livres de nos jours. Beaucoup d'attention portée aux améliorations au niveau des équipes, pas tant d'attention portée aux choses globales simplement parce qu'il est plus facile d'améliorer au niveau local et de mesurer et d'être heureux etc. Donc, c'est difficile d'optimiser l'ensemble. Pour rendre ça un peu plus concret, n'est-ce pas ? Optimisations locales versus optimisations globales. Comme chaque fois que quelqu'un vous dit, ce n'est pas efficace, vous devriez demander, que voulez-vous dire ? Localement ou globalement ?
[00:27:34] Vous savez, l'efficacité peut être locale ou globale. N'est-ce pas ? Peut-être que ce n'est pas efficace pour cette équipe d'arrêter de travailler sur ce qu'elle fait et d'apprendre, ce n'est pas efficace pour l'équipe, mais c'est plus efficace pour l'organisation globale, pour un système global, pour un département, pour un groupe d'équipes parce que ce système supérieur, ce système plus grand apprend. Est-ce aussi à court terme ou à long terme, n'est-ce pas ? Chaque fois que quelqu'un mentionne le mot efficacité, vous devriez avoir ce son dans votre tête parce que qu'est-ce que vous voulez dire ? Petit, grand, local, global, n'est-ce pas ? Et puis si vous clarifiez ce qu'ils veulent dire, peut-être que vous essayez d'optimiser globalement.
[00:28:14] Et cette personne est vraiment très motivée à continuer d'optimiser les choses localement et c'est pourquoi il y a ce conflit constant dans l'entreprise entre les chefs de produits et les responsables de l'ingénierie. Les parties prenantes, les Scrum Masters, quels qu'ils soient, pensent à l'efficacité différemment. Un autre exemple peut être, oh, c'est une équipe à flux rapide. Fantastique. Super. Mais à quel coût au niveau global ?
[00:28:42] Vous ne pouvez pas être rapide localement sans aucun effet secondaire. N'est-ce pas ? Si je joue dans un groupe et que je suis un très mauvais bassiste, si je joue un peu plus vite que le reste du groupe,
[00:28:56] C'est probablement le dernier concert que je vais faire. On appelle ça du jazz.
[00:28:59] On appelle ça du jazz.
[00:29:00] On appelle ça du jazz, n'est-ce pas ?
[00:29:03] Oui, parfois. Quels effets secondaires indésirables cela créera-t-il dans l'organisation à long terme ? Peut-être positif, fantastique, quelque chose d'inattendu, peut-être pas, mais il est logique d'y réfléchir. Nous entendons ce mot rapide et flux et efficacité, que voulons-nous dire exactement par là et comment le mesurons-nous ? La propriété privée du code réduit la surcharge cognitive. Si je possède une seule ligne de code dans l'entreprise, je suis le développeur le plus rapide de tous les temps. Donc il y a une limite à cela, n'est-ce pas ? Eh bien, vous en savez plus à ce sujet avec la conception axée sur le domaine, bien sûr, ce n'est pas juste une ligne de code, c'est une sorte de contexte. bla bla bla, mais c'est ça la réflexion, n'est-ce pas ? À quel coût ? Et comment cela entravera-t-il l'apprentissage organisationnel à long terme, si nous divisons pour régner, etc, etc, etc ?
[00:29:57] Oui, c'est donc une introduction à l'idée d'essayer de penser de manière plus systémique et plus approfondie, et de ne pas se contenter de la solution facile, car systémique signifie qu'il y a beaucoup de choses impliquées et que c'est complexe, et vous devez faire une réflexion lente pour vraiment comprendre ce qui se passe. Maintenant, nous pensons que c'est le moment de discuter après cela.
[00:30:15] Et nous promettons que c'est la dernière fois que nous vous demandons de faire quelque chose de désagréable lors de notre discours principal.
[00:30:20] Parlez inconfortablement à vos voisins.
[00:30:22] Alors encore une fois, parlez à votre voisin ou parlez à votre ami imaginaire et je vois beaucoup de gens parler à quelqu'un à l'intérieur, c'est bien. Pensez à des exemples de ces optimisations locales que vous observez, avez observées, pourriez observer dans votre organisation. Ce qui signifie ce que nous optimisons localement sans prêter attention aux effets que cela pourrait avoir sur l'image globale. Et par global, ici, nous ne voulons pas vraiment dire monde, écologie, oubliez. Nous voulons dire affaires. Et comme pour l'entreprise et pour les affaires et pour les clients.
[00:31:01] Eh bien, un petit exemple, mon équipe avec laquelle je travaille, je suis chef de produit et j'ai une équipe et je m'assure qu'ils ont beaucoup de travail. Mais c'est l'équipe du mot de passe oublié et en fait, mon équipe est très occupée, donc localement nous sommes très bien optimisés parce que l'optimisation des ressources est à 100%.
[00:31:19] Mais d'un point de vue global, mon équipe ne fournit aucune valeur réelle au client parce qu'ils pensent que les routines de mot de passe oublié fonctionnent bien. D'accord ? C'est un exemple de non, eh bien, c'est optimisé localement mais ne donne aucune valeur globalement. Maintenant, s'il vous plaît, parlez à votre voisin et voyez si vous pouvez identifier.
[00:31:37] Et avant de commencer. Ne blâmez pas les gens. Il n'y a pas de blâme dans la pensée systémique. Si quelqu'un optimise localement, ce n'est pas parce que ces gens sont stupides, malveillants, idiots, ou quoi que ce soit d'autre. Peut-être qu'ils le sont. Mais ce n'est pas parce que c'est à cause de ça qu'ils optimisent localement. Ils optimisent localement parce qu'il y a des motivations dans l'entreprise à penser comme ça. Alors ne blâmez pas les gens, essayez simplement d'observer certains comportements systémiques qui se produisent. quelques minutes, s'il vous plaît, parlez à vos amis.
[00:32:11] D'accord, c'est une super énergie. Merci beaucoup.
[00:32:17] Maintenant, vous savez ce qu'il faut discuter pendant la plus grande pause qui arrive, n'est-ce pas ? Plus d'exemples d'optimisation locale. Quelqu'un ose partager brièvement une chose ?
[00:32:26] Comme une très bonne, une très bonne optimisation locale.
[00:32:29] Quelqu'un ose partager sans le nom de l'entreprise, bien sûr. Non.
[00:32:33] Non. Non.
[00:32:36] Quelqu'un veut en partager un ?
[00:32:37] Je vais en partager un alors. Oui.
[00:32:39] D'accord.
[00:32:40] Que diriez-vous de vous assurer que toutes les chaises longues sont parfaitement organisées sur le Titanic ? Hm.
[00:32:49] Ou quelqu'un dans un restaurant en train de couper des oignons, et il y a beaucoup d'oignons coupés et tout le monde pleure mais vous n'avez pas besoin de tant d'oignons. Ce sont des métaphores pour l'optimisation locale, bien sûr, vous avez trouvé quelque chose de plus spécifique, n'est-ce pas, qui n'a de sens que dans votre contexte. Il est important de ramener ce langage d'optimisation locale versus optimisation globale, à long terme, à court terme, à votre entreprise et de commencer à questionner de manière constructive les intentions des autres.
[00:33:18] N'est-ce pas ? Nous pensons donc qu'il est plus important que jamais de commencer à penser de manière systémique. Euh, nous avons 15 minutes, c'est donc l'heure des questions. Quelqu'un ?
[00:33:30] J'ai une question. Désolé, j'adore poser des questions et maintenant que j'ai l'opportunité d'être sur scène, je pourrais aussi bien en profiter pour poser des questions.
[00:33:39] Allez-y, allez-y le premier. Roland, voici une question. Alors, quelle est la question, monsieur ?
[00:33:43] Je vais m'assurer que c'est une question que tout le monde veut connaître. Euh, donc progresser, vous savez, vers cette dimension produit et faire en sorte que les gens en sachent plus et soient rapides. Est-ce que cela fonctionne vraiment dans de vraies entreprises ou est-ce juste un concept abstrait que vous apportez ici sur scène ? Y a-t-il des exemples de ces entreprises et comment s'y prennent-elles ?
[00:34:05] Eh bien, bonnes questions, Roland.
[00:34:07] Oui, merci. Vous êtes bien préparé, je dois dire.
[00:34:10] Merci.
[00:34:10] Oui.
[00:34:11] Oui. Donc je suppose que beaucoup d'entre vous partagent cela, n'est-ce pas ? Et nous nous posons aussi cette question à nous-mêmes. Nous menons donc une sorte de recherche de toute une vie, essayant de trouver ces organisations, d'entrer et de leur parler. Parler aux managers, aux chefs de produit, aux développeurs exécutifs, aux personnes clés, aux développeurs, et comprendre comment cette entreprise fonctionne.
[00:34:34] Nous vous donnerons plusieurs exemples de telles entreprises. Vous pouvez les trouver sur LinkedIn et les contacter pour leur parler. L'une d'entre elles n'est vraiment pas connue et aucune d'entre elles n'est réellement connue. Aucune d'entre elles n'est comme Apple, Google, etc. Cette entreprise est basée en Ukraine et est le plus grand producteur de logiciels d'automatisation de restaurants B2B. Donc si vous allez au restaurant en Ukraine et que vous avez été servi là-bas et que tout le monde est le bienvenu en Ukraine dans ma ville natale Kiev après la guerre, s'il vous plaît faites cela, visitez-nous. Euh, alors vous serez probablement servi dans un restaurant avec leur logiciel. Donc quelques images ici, quelques instantanés de la conception organisationnelle que dans le langage de l'Orgy, nous appelons des scans de conception organisationnelle, c'est comme si vous voliez autour de l'entreprise et ce que vous voyez. Et cette partie où Roland reste, c'est ce qu'il y avait avant 2022. Ils avaient comme neuf îles.
[00:35:30] Neuf petites îles et par couleurs nous entendons une classification différente basée sur Orgy's. Mais c'étaient des archétypes de bas niveau. Ce qui signifie que chaque entreprise, vous savez, vous voyez ces lignes pointillées autour des équipes, c'est le contexte qu'elles possédaient. Chaque équipe possédait un même petit contexte. Certaines personnes possédaient des composants comme un composant de paiement. Parce que vous faites de l'automatisation de restaurant, il y a différentes imprimantes dans les restaurants pour imprimer les chèques et tout ça. Il y avait une équipe de pilotes d'imprimante dans cette entreprise. N'est-ce pas ? Certaines équipes construisaient des fonctionnalités un peu plus compréhensibles par les clients. Certaines équipes construisaient un constructeur pour que le restaurant puisse construire un site web avec un menu pour lui-même, etc., etc., etc. Mais chaque équipe a sa propre liste. Je n'appellerais même pas ça un backlog, une liste de choses à faire, un propriétaire de liste, un chef de produit et un chef d'équipe. N'est-ce pas ? C'est une configuration très classique que l'on voit dans de nombreuses organisations. Et après environ neuf mois de pensée systémique et de discussion sur les problèmes qu'ils rencontrent et en essayant de comprendre ce qu'ils veulent être quand ils grandiront. Ils ont réalisé, d'accord, nous pouvons en fait essayer d'apprendre à travailler ensemble à nouveau comme nous le faisions quand nous étions petits. Revenons à cette idée que nous sommes une équipe d'équipes, n'est-ce pas ? Et essentiellement, sur cette partie, vous avez neuf équipes, ici vous avez six équipes. Cela ne signifie pas qu'ils ont licencié des gens ou que des gens ont démissionné. Non, ils ont réorganisé les équipes. Ils ont laissé les gens s'auto-organiser en nouvelles équipes et ils se sont assurés que ces nouvelles équipes avaient des connaissances sur différents composants. Comme s'il y avait une équipe qui connaissait bien les imprimantes, ils s'assurent que ces cinq gars vont dans différentes équipes afin que cinq équipes, au moins sur six, puissent faire quelque chose avec les imprimantes. Donc c'était l'idée, comme ouvrir, n'est-ce pas ?
[00:37:24] Certains concepts clés qu'ils ont mis en œuvre. C'était une petite entreprise, 50 personnes en R&D. Ils ont formé un total de six, pas seulement des équipes transfonctionnelles. C'est important. Scrum parle de transfonctionnel, ça vient. Euh, mais ce sont aussi des équipes inter-composants. C'est une très grande différence si vous voulez monter sur l'axe vertical. Et les équipes étaient détachées de l'architecture. Le conseil inverse que nous avons entendu maintes fois lors de cette conférence. Vous détachez les équipes de l'architecture et maintenant toutes ces équipes ensemble co-possèdent cette architecture, ce qui semble être une très mauvaise idée. Mais si vous le faites avec soin, n'est-ce pas ? Si vous le faites de manière réfléchie, si vous mettez de la réflexion, de l'encadrement, des communautés, cela fonctionne plutôt bien. Et quand une équipe a extrait un élément du backlog, elle pourrait extraire un élément qui nécessitait du travail dans un composant sur lequel elle n'avait jamais travaillé auparavant. Ils peuvent le rendre à une autre équipe qui avait plus de connaissances ou ils peuvent dire, d'accord, c'est intéressant. C'est la première fois de notre vie que nous allons ouvrir ce référentiel. Et quand ils ont ouvert le dépôt, ce qui s'est passé au cours du premier semestre dans cette entreprise, les développeurs se sont dit, oh, c'est intéressant.
[00:38:39] Ce référentiel appartenait à cette équipe qui n'existe plus, mais nous voyons que l'équipe a utilisé cette technologie spéciale pour le déploiement ou toute autre migration de script de base de données, mais d'autres référentiels que nous connaissons déjà, ils font quelque chose de différent. Qu'est-ce qu'on fait ?
[00:38:58] Standardisons, simplifions, changeons ce référentiel pour qu'il se comporte comme d'autres référentiels. Donc le niveau de complexité de l'architecture diminue quand vous faites cela. Et quand les choses deviennent plus évidentes, transparentes et visibles, posséder et co-posséder devient encore plus facile et encore mieux. Donc ce mouvement vertical, parfois nous l'appelerons la mise à l'échelle ou la simplification parce que nous essayons de simplifier et de nous débarrasser des choses qui sont vraiment gênantes. D'accord. Euh et il y a des vidéos, bien sûr, vous pouvez trouver en ligne sur cette entreprise. Un autre exemple d'une entreprise légèrement plus grande. Pandadoc.
[00:39:39] Pandadoc. Euh, comme vous pouvez le voir, c'est une organisation plus complexe et c'est le résultat ultime qu'ils ont obtenu. Mais ce qu'ils ont fait en fait, c'est de créer trois grands groupes d'équipes et on pourrait dire que c'est leur contexte délimité dans lequel ils travaillent. Et dans ce contexte, toutes les équipes essaient de partager autant d'informations qu'elles le peuvent, encore une fois, avec les mêmes effets d'architecture émergente, de standards émergents et ainsi de suite. Donc, euh, ils s'enseignent mutuellement au sein de ces équipes sur l'apprentissage de nouvelles choses qu'ils n'ont jamais faites auparavant. Euh, et ce n'est pas comme un voyage qui se fait du jour au lendemain. L'histoire que vous venez de raconter et cette histoire de Pandadoc, il faut des années et des années pour faire cela. Et c'est fait avec de petites expériences qui échouent et que nous réessayons ensuite. Alors, ne pensez pas que la magie opère du jour au lendemain. C'est un voyage. Et un outil comme Ortopologies peut vous aider à parcourir ce voyage de manière sensée et à garder votre cap là où il est.
[00:40:41] Oui, et cette équipe, cette entreprise, ils n'ont pas utilisé Ortopologies. Ils ont en fait utilisé des idées de scrum à grande échelle moins pour arriver à ce design sur cinq ans d'expériences. Un élément particulier de cette liste sur lequel j'aimerais commenter le dernier, composant, mentorat et communautés. Oui. Cette entreprise avait beaucoup de code, beaucoup de composants. C'est comme un système de gestion de documents, des signatures numériques, etc., un domaine complexe. Et bien sûr, au fil des ans, l'entreprise a plus de 10 ans, elle avait beaucoup de code hérité. Comme nous tous. Alors, comment ouvrez-vous ce code maintenant à tout le monde ? Eh bien, vous ne faites pas ça du jour au lendemain, n'est-ce pas ? Ce que vous faites, c'est que vous regardez vos composants, peut-être équivalents à des référentiels, n'est-ce pas ? Et vous essayez de les classer. Ah, d'accord, ce composant est en bon état. Il a une bonne couverture de code, une couverture de test. Il a déjà des pipelines d'automatisation, de déploiement. Ce n'est donc pas un composant critique. Ce n'est pas un composant essentiel. Donc nous pouvons le donner à toutes les équipes. Et si quelqu'un casse quelque chose, eh bien, il y a une CI qui tourne et tout ça, n'est-ce pas ? Et peut-être qu'il y a cinq autres composants comme celui-ci que nous pouvons donner à tout le monde le premier jour. Donc la propriété privée du code et la propriété partagée du code ne sont pas seulement deux options. Il y a de nombreuses étapes intermédiaires, n'est-ce pas ? Certaines choses que vous pouvez ouvrir et donner. Certaines choses que vous vous dites, hmm, non, c'est une partie très essentielle de notre produit. Une seule équipe le connaît. Et maintenant, vous avez une option. Donc nous vous donnons des options, n'est-ce pas ? Une option est de les laisser le posséder pour toujours. Laissez-les les appeler. pipeline de déploiement d'automatisation. Ce n'est donc pas un élément critique. Ce n'est pas un composant essentiel à la mission. Nous pouvons donc le donner à toutes les équipes.
[00:41:45] Et si quelqu'un casse quelque chose, eh bien, il y a une intégration continue en cours et tout, n'est-ce pas ? Et peut-être qu'il y a cinq autres composants comme ça. que nous pouvons donner à tout le monde le premier jour. Ainsi, la propriété de code privée et la propriété de code partagée ne sont pas seulement deux options. Il y a de nombreuses étapes intermédiaires, n'est-ce pas ? Certaines choses que vous pouvez ouvrir et donner. Certaines choses vous font dire, hmm, non, c'est une partie très essentielle de notre produit. Une seule équipe le sait. Et maintenant, vous avez une option. Nous vous donnons donc des options, n'est-ce pas ? Une option est de les laisser en être propriétaires pour toujours. Appelons-les comment on les appelle dans les topologies d'équipe ? Équipe de sous-système complexe. Si vous avez un sous-système complexe, vous avez une équipe de sous-système complexe. Si vous avez une équipe de sous-système complexe, vous avez un sous-système complexe. C'est comme s'ils étaient mariés pour toujours. À moins que la mission de cette équipe ne soit de refactoriser, d'améliorer, d'attester, et à un certain point, de le céder à d'autres équipes. Donc cette communauté de mentorat de composants est l'idée où vous identifiez ces composants difficiles et vous avez une feuille de route pour chaque composant.
[00:42:56] Comme peut-être que vous y attachez une équipe pour travailler dessus, ou peut-être que vous tirez des gens de différentes équipes ou peut-être que des gens se portent volontaires viennent de différentes équipes, ce qui est encore plus cool, et travaillent comme une équipe temporaire pour améliorer le code, puis ils retournent à leurs équipes. Mais maintenant, ces équipes ont des connaissances sur ces composants. Vous pouvez donc le faire progressivement. N'est-ce pas ? Vous n'avez pas besoin de décider de la propriété de code publique ou partagée. Non.
[00:43:18] La transformation dans la réalité est compliquée. Et ça a toujours l'air génial après coup lors de conférences comme celles-ci pour montrer des cartographies et tout était brillant et beau et propre, mais la réalité est, bien sûr, compliquée. Une dernière peut-être.
[00:43:32] Oui, une dernière. Et avant de passer à la dernière, qui est super intéressante, celle-ci. Vous voyez ces trois sortes de cercles égaux aux départements. Eh bien, chez ceux qui étudieront les topologies et la carte, vous verrez deux niveaux supérieurs, le niveau B et le niveau C. C'est donc la différence. Dans une organisation de niveau B, ces murs entre les départements seront fixes. Je suis dans l'équipe X et je suis dans ce département, je travaille sur un B2B2B2C. Vous êtes dans une autre équipe avec d'autres équipes ensemble et vous travaillez sur du B2B2B2C et nous ne changeons jamais. Et vous avez votre manager fixe, etc.
[00:44:13] Ce sera une entreprise de niveau B. L'entreprise de niveau C, qui est une manière plus fluide, et c'est ce que fait Panda Doc. Les équipes restent à moyen terme, à moyen terme, pas pour toujours, à moyen terme. attachées à de grands objectifs commerciaux, ce qui les oblige à travailler sur du B2B2B2C. Mais quand cet objectif est atteint, ou que l'équipe souhaite apprendre autre chose, ou peut-être que cette zone grandit et que cette zone rétrécit à cause du développement commercial comme ceci. Cette équipe ira faire partie de ce département. Donc les départements ne sont pas vraiment des départements, ce sont juste des zones d'accords et ils sont fluides. C'est donc une façon très différente de concevoir votre organisation.
[00:44:56] Et le dernier exemple que nous pouvons discuter est Y soft.
[00:44:59] Oui, Y soft. Très, très intéressante, une entreprise révolutionnaire. Et encore une fois, nous montrons une image, mais il y a eu plusieurs étapes et vous pouvez trouver plus de détails sur notre site web sur la façon dont ils ont progressé. C'est une grande étude de cas. Hum, Ysoft avait 14 équipes, c'est donc un peu plus petit que la précédente. Hum, mais le truc marrant, c'est qu'ils ont ou le bon truc, c'est qu'ils ont réussi à servir toutes les équipes ou à laisser toutes les équipes travailler dans un même contexte délimité. Donc un sprint, si vous voulez, que toutes les équipes partagent. Il y a un espace de collaboration. Et il y a quelques années, je ne sais plus l'année exacte, était-ce 2022 ?
[00:45:35] Peut-être qu'ils sont devenus sans manager. Ils ont donc observé, à des stades antérieurs, que le fait d'avoir un management intermédiaire les empêchait de se développer davantage pour devenir la cellule, le grand organisme cellulaire qu'ils sont maintenant. Et ils ont décidé de redéfinir la gestion. Il y a donc la sécurité de l'emploi mais pas la sécurité des rôles et vous pouvez peut-être faire quelque chose d'autre qui a plus de valeur que de gérer les choses dans notre entreprise. Certaines personnes l'ont fait et d'autres sont parties. Je pense qu'il y a un exemple de quelqu'un qui était content de recommencer à coder, vous savez? Ouais. Tu veux dire quelque chose ?
[00:46:12] Allez.
[00:46:13] Désolé.
[00:46:13] J'ai dit, oui, retour au codage, retour au codage.
[00:46:17] Il y a donc un product owner pour toute l'entreprise, le PDG, d'accord, et il a deux assistants, deux personnes, deux chefs de produit qui font un travail plus quotidien avec les équipes. Le PDG qui définit la stratégie et place les éléments les plus importants sur la feuille de route, ce qu'on appelle un carnet de produit.
[00:46:35] Hum, il y a eu un moment où ils ont fait une fusion, ils ont donc racheté une nouvelle entreprise et les gens de cette nouvelle entreprise ont dû apprendre tous les logiciels que Ysoft fabrique. Et euh, ça a été assez rapide en fait parce qu'il a fallu un mois aux cinq équipes pour se mettre à niveau sur la nouvelle base de code. Partager du code rend les choses plus simples parce que si je sais que vous allez lire mon code, je réfléchirai à deux fois à ce que j'écris, vous savez.
[00:47:01] Oui, donc ce ne sont pas des contes de fées. Ce sont des conférences, des articles, vous pouvez tous les trouver. Nous sommes donc en recherche de plus d'entreprises comme celles-ci. Et si vous rencontrez quelque chose de similaire dans votre entreprise, n'hésitez pas à nous trouver, à nous parler. Nous serions ravis de discuter avec vous et d'apprendre de vous, n'est-ce pas ? Et l'idée de ces entreprises, c'est qu'elles sont beaucoup plus adaptatives et résilientes que n'importe quelle autre entreprise que nous connaissons. L'entreprise en Ukraine, avec laquelle nous avons commencé nos exemples, est toujours là, bousculant le marché même pendant la guerre, même après le COVID. Donc ces entreprises ne sont pas juste funky, ne se contentent pas de partager du code et d'apprendre, ces entreprises ont ces choses que nous avons énumérées. Elles ont des implications commerciales vraiment significatives comme la résilience, par exemple.
[00:47:50] Oui. Parce qu'un exemple de Flotech, s'ils doivent résoudre un nouveau problème, toutes les équipes peuvent travailler sur n'importe quoi. Ils sont habitués à apprendre, c'est donc une question de mettre de nouveaux éléments dans le backlog produit pour qu'ils commencent à travailler dessus. Vous n'avez pas besoin d'une réorganisation si vous voulez vraiment changer de direction en tant qu'entreprise.
[00:48:08] D'accord. Nous n'essayons pas vraiment de réécrire le manifeste Agile. Nous pensons que nous devons juste aider les gens à lire celui-là un peu mieux qu'ils ne le font. Mais nous avons élaboré ces cinq principes que nous avons observés dans les organisations qui créent et suivent une R&D axée sur le commerce. Et j'aimerais vous donner une minute pour prendre des photos et les lire par vous-mêmes.
[00:48:52] Oui, similaire à ce que la conférence a en première page, n'est-ce pas ? Ceci un peu différent. Le juste un commentaire rapide sur l'élément numéro quatre.
[00:49:02] De la réorganisation constante à la conception organisationnelle adaptative. Ce qui est intéressant dans ces entreprises
[00:49:08] est que lorsque quelque chose change sur le marché et qu'ils doivent réajuster la stratégie de l'entreprise, comme l'introduit un nouveau truc fou sur le marché.
[00:49:19] Ces entreprises n'ont pas besoin de se réorganiser, elles n'ont pas besoin de créer de nouvelles équipes et de nouvelles unions commerciales et de nouveaux backlogs et d'embaucher de nouveaux propriétaires de produits et de faire toute cette masse. Ils peuvent simplement réaligner l'ordre de vos éléments sur leur backlog, si vous le souhaitez, ou quelle que soit la technique qu'ils utilisent pour gérer les priorités commerciales.
[00:49:39] Et comme les équipes se sont habituées à apprendre et à travailler sur de nouvelles choses de temps en temps, les équipes vont commencer à apprendre ces nouvelles choses. Nous avons maintenant deux minutes et nous accueillons avec plaisir vos questions si vous en avez pour nous. Merci beaucoup. N'applaudissez pas encore. N'applaudissez pas encore. Si vous applaudissez deux fois, ça devient toujours bizarre, alors attendez pour ça. Nous avons une main au milieu, la dame en bleu.
[00:50:08] Oui, merci. Je pense que nous avons le temps pour une seule question. Et il y a juste une pause-café après. Oui, il y a une pause-café après.
[00:50:15] D'accord. Et où vous discuterez de plus d'optimisations locales, n'est-ce pas ?
[00:50:20] Et pendant que le café créé par l'intelligence artificielle arrive.
[00:50:26] La question.
[00:50:27] Tout d'abord, merci beaucoup. C'était une présentation absolument incroyable. Très pleine d'humour et créative et dynamique. Merci beaucoup.
[00:50:36] Now just a couple of words to Alexey. Я очень рада тебя видеть в Париже. Мы пересекались в Киеве. Очень рада тебя здесь видеть.
[00:50:46] Je suis aussi Ukrainienne.
[00:50:47] Nous parlons russe maintenant. Sous-titres, s'il vous plaît. Sous-titres. Oui.
[00:50:52] Et maintenant, passons directement à la question. Euh, il serait curieux de savoir ce qui vous a servi d'inspiration pour vos topologies d'organisation ? Je suppose que la pensée systémique à coup sûr, et quoi d'autre ?
[00:51:11] C'est difficile de le dire mieux que ce que dit Craig Larman. Et nous essayons de trouver le nôtre. Merci pour la question et heureux de vous voir aussi. Larman dit : « J'essaie de réduire la souffrance dans le développement de produits. » C'est ce qu'il dit. Nous sommes un peu plus optimistes. Nous aimerions améliorer la vie des gens dans les organisations, mais pas seulement en les regardant et en leur donnant une ligne de code, ou en ouvrant ce potentiel humain verrouillé. Il ne s'agit pas seulement de rendre les gens heureux, vous pouvez simplement leur donner des drogues, n'est-ce pas ? Pour l'amour de Dieu. Achetez la drogue. Vous serez heureux pendant quelques minutes.
[00:51:51] C'est bien, mais il ne s'agit pas d'être heureux. Il s'agit de
[00:51:56] réaliser le potentiel inexploité des organisations, ce qui finira par rendre les gens plus épanouis. Donc nous voyons beaucoup d'entreprises et beaucoup d'entreprises sont dysfonctionnelles parce que chaque groupe de personnes est dysfonctionnel. C'est donc normal. Mais certaines entreprises rabaissent vraiment, mettent les gens à terre, vous savez, comme sur notre image, comme en souterrain ou au premier niveau. Et nous croyons que les êtres humains sont des êtres humains et qu'ils peuvent simplement travailler sur des choses sur lesquelles ils aimeraient travailler, ils peuvent être plus créatifs, ils peuvent être ils devraient être libérés de ces limitations de quelqu'un qui croit, la charge cognitive fera exploser ma tête. Je n'ai jamais vu de développeur avec la tête ouverte. Explose-le.
[00:52:37] Ils apprennent, ils souffrent, mais finalement, ils pensent que c'était la bonne chose à faire.
[00:52:45] Alors je dirais le potentiel humain.
[00:52:47] D'accord. Pour être plus concret, je pense, euh, j'ai été vraiment inspiré quand j'ai vu Scrum et que j'ai fait mes premières équipes Scrum, mon Scrum master.
[00:52:58] Scrum.
[00:53:00] Scrum. Et euh, plus tard j'ai découvert le Scrum à grande échelle avec Bas Vaude et Craig Larman. C'était très inspirant pour aller plus loin. Hum, j'ai aussi vu le déclin de l'enthousiasme des gens qui faisaient du Scrum et de l'Agile. Et je suis vraiment, vous savez, ça me fait mal et je veux m'assurer que cela change. Nous voyons tous que nous devons juste l'appliquer différemment.
[00:53:21] Oui.
[00:53:23] C'est ma vocation. Quelqu'un d'autre a une question pour nous ?
[00:53:26] Je suppose que malheureusement, j'ai peur que nous n'ayons pas le temps. Euh,
[00:53:31] D'accord.
[00:53:31] Mais si vous êtes là,
[00:53:33] Maintenant, vous pouvez applaudir si vous voulez. Merci beaucoup.
[00:53:40] Merci beaucoup de nous avoir accueillis.

Transcription (Traduit)