Sander Hoogendoorn

[00:00:04] Merci.
[00:00:07] Ça c'est le seul mot que je peux prononcer en français, c'est merci.
[00:00:13] Alors, j'allais dire, bon. Donc, le reste sera en anglais, n'est-ce pas ? J'ai en fait une diapositive en français, alors euh, j'espère que ça va fonctionner. Donc, euh, euh, en fait, le titre du programme est différent du titre que j'utilise aujourd'hui. Euh, et, et c'est fondamentalement parce que chaque fois que je parle aux gens, euh, mes idées changent. N'est-ce pas ? C'est assez courant. Et, euh, euh, donc le titre a également changé, et le contenu aussi. Euh, et je ne suis pas tout à fait sûr de pouvoir le faire en une heure parce que j'ai ajouté beaucoup de choses basées sur des conversations très agréables que j'ai eues hier pendant le dîner, mais aussi plus tard au bar avec Demetri. Je n'avais pas réalisé que c'était ton anniversaire. Nous sommes restés jusqu'après minuit, n'est-ce pas ? Donc tu avais déjà eu ton anniversaire. Donc oui, le titre est maintenant 'Se débloquer'. Et, et la raison pour laquelle ça s'appelle ainsi est que, euh, euh, je travaille pour, euh, de plus petites entreprises. J'ai travaillé pour de grandes entreprises, j'ai arrêté. Euh, c'est quelque chose que je peux absolument recommander si vous retenez quelque chose de cette conférence, c'est que les petites entreprises sont en fait beaucoup plus amusantes, je pense. Mais bon, c'est une opinion personnelle. Donc, euh, euh, et, et beaucoup de ces entreprises sont restées bloquées au fil des années. Et, euh, euh, certains d'entre eux m'ont engagé pour les aider à se débloquer. Euh, nous avons échoué dans certaines de ces tentatives, euh, nous avons réussi dans certaines autres tentatives. Alors je vais vous en parler un peu. C'est un peu comme une histoire personnelle des choses que j'ai vécues au cours des, disons, dix dernières années. Donc, la première question serait : pourquoi les organisations restent-elles bloquées ? Comment font-elles ça ? Euh, c'est en fait très difficile de ne pas rester bloqué, mais, euh, voyons ce qui se passe. Donc, euh, ça commence un peu avec la qualité, n'est-ce pas ? Et la qualité est une chose très difficile, surtout dans les logiciels. Cependant, dans la plupart des autres industries, ce n'est pas aussi difficile, parce que, euh, attendez, laissez-moi agrandir un peu ça. Pour que je puisse réellement voir ma propre diapositive. Par exemple, si vous allez au supermarché et que vous achetez du café. N'est-ce pas, la plupart d'entre nous le font. Euh, euh, j'ai eu une discussion intéressante sur le café avec Luka ce matin. Euh, euh, euh, il est italien, n'est-ce pas ? Donc, ils boivent leur café différemment. Ils ont un meilleur café, je pense. Et, euh, donc si je vais au supermarché, euh, si j'achète, si je veux un meilleur café, un café de meilleure qualité, j'achète un café plus cher, n'est-ce pas ? Si je m'en fiche, euh, d'habitude, euh, chez moi, ma fille boit la majeure partie du café, et elle en boit tellement que je ne me soucie pas de la qualité. Elle le boira de toute façon, n'est-ce pas ? Alors, j'achèterai la marque la moins chère, qui est généralement sur les étagères les plus basses, euh, mais, mais si je suis à la maison, j'achèterai un café plus cher parce qu'il a meilleur goût, n'est-ce pas ? Donc, c'est, c'est une compréhension très linéaire, euh, de la qualité. Donc, c'est comme si vous achetiez une voiture, n'est-ce pas ? Si vous achetez une voiture, plus vous voulez de fonctionnalités, plus elle est chère. Et nous nous attendons tous à ce que ce modèle fonctionne, et nous appliquons également cela aux logiciels. Le problème avec les logiciels, c'est un modèle très différent. Donc, normalement, nous faisons cela, n'est-ce pas ? Si nous allons acheter quelque chose, nous essayons de trouver l'optimum entre le montant que nous sommes prêts à dépenser et la qualité que nous en attendons. Et il y a toujours un certain optimum, n'est-ce pas ? Si je ne me soucie pas de la qualité, j'achète le café bon marché, si je m'en soucie, j'achète la marque de voiture la plus chère ou n'importe quoi, n'est-ce pas ? Cependant, avec les logiciels, c'est assez différent. Dans le logiciel, eh bien, vous diriez que la qualité est beaucoup plus intangible car de nombreuses choses contribuent à la qualité des logiciels. Il en va de même pour tous les autres produits, sauf que ceux-ci sont beaucoup, beaucoup plus compliqués, je dirais, pas complexes, mais compliqués. Et, euh, toutes ces choses, il y a, comme, euh, l'interopérabilité, la maturité, la disponibilité, la responsabilité, il y a beaucoup de choses de ce genre. Tout cela compte quand on parle de la qualité des logiciels. Maintenant, ça rend les choses vraiment difficiles, ça les rend en quelque sorte, quoi, intangibles. J'utilise beaucoup de mes propres photos dans ma présentation. C'est mon, mon équipe dans une sorte de Je ne sais pas ce qu'ils font, mais ils écrivent probablement du code. Donc, le problème avec tous ces aspects de la qualité dans les logiciels est qu'il faut trouver le bon équilibre pour votre logiciel, n'est-ce pas ? Et trouver le bon équilibre est toujours difficile. Au fait, j'utilise aussi des photos de mes voyages, donc, euh, c'est une photo de voyage. Euh, et, euh, trouver cet équilibre est particulièrement difficile. Alors, ce qui se passe, c'est que beaucoup, surtout les startups, elles sont là, n'est-ce pas ? Donc, nous voulons fabriquer notre produit, nous voulons le sortir le plus vite possible, donc nous ne nous soucions pas de la qualité du code. Et vous pourriez dire, oh, ce n'est pas juste. Mais c'est juste pour eux, n'est-ce pas ? C'est juste parce qu'ils peuvent sortir leur produit très, très vite.
[00:04:37] Si vous êtes sur un marché, disons que vous allez comparer des billets d'avion, n'est-ce pas ? Euh, vous construisez une application pour ça et elle doit concurrencer beaucoup d'autres applications, donc vous voulez la sortir très, très vite.
[00:04:50] À un moment donné, je travaillais pour l'entreprise qui a inventé le thermostat intelligent. Il y a longtemps, c'était tout nouveau à l'époque. C'était vraiment important, au fait, euh, et il n'avait pas l'interopérabilité qu'il a eue plus tard. Mais ils l'ont inventé. Et ça a bien marché. Et ils ont commencé à y ajouter des fonctionnalités. Vraiment cool. Mais, vous savez ce qui s'est passé, les grandes entreprises de ce monde, donc, euh, les Google, les Tado, les Amazon, elles se sont toutes lancées dans ce domaine, n'est-ce pas ? Et puis, en tant que petite entreprise, avoir des produits rapides et bâclés devient moins, eh bien, moins utile, pour ainsi dire. Donc, vous devez vous soucier de ce qui se passe à long terme. Si votre logiciel doit fonctionner pendant, disons, une décennie ou deux décennies. Avez-vous un logiciel qui tourne déjà depuis deux décennies ? 20 ans ?
[00:05:35] Si vous travaillez pour une banque, vous le faites probablement, n'est-ce pas ? Si vous travaillez pour une compagnie d'assurance, oui, sans aucun doute. C'est écrit en Cobol ? Oui, probablement. Est-ce que ça compte ? Non. Eh bien, à moins que vous ne deviez trouver des développeurs, c'est généralement un problème. Mais, et le fait est, que se passe-t-il si vous continuez à ajouter des choses à votre logiciel, euh, vous pourriez vous retrouver avec de la dette technique. Vous avez entendu ce mot, n'est-ce pas ? Dette technique. Vous en avez ? Personne ne dit non, tout le monde en a, n'est-ce pas ?
[00:06:04] Je, je dis habituellement, non, je n'ai pas de dette technique, il y a juste des choses que nous n'avons pas encore faites. Mais c'est à peu près la même chose, je dirais, n'est-ce pas ? Alors, qu'en est-il de la dette technique ? Alors, prenons la définition originale de Ward Cunningham. Il a en quelque sorte inventé le mot. Et il a dit, eh bien, livrer du code pour la première fois, c'est comme s'endetter. Euh, une petite dette accélère le développement, tant qu'elle est remboursée rapidement par refactoring. Alors il dit, c'est bien de juste livrer les choses, mais tu dois te promettre de, de les améliorer tout le temps, n'est-ce pas ? C'est là que la règle des boy-scouts, qui n'est pas très inclusive, mais oui, c'est comme ça qu'elle s'appelle je crois, est que vous laissez le terrain de camping un peu mieux que vous ne l'avez trouvé. Et si vous faites cela tout le temps, votre dette technique est un petit peu moindre. Mais ça pourrait empirer, n'est-ce pas ? Et, euh, euh, Ward dit alors, il dit, eh bien, en gros, le danger survient lorsque la dette n'est pas remboursée. C'est le cas avec la dette tout le temps, n'est-ce pas ?
[00:06:55] Euh, et chaque minute passée sur du code qui n'est pas tout à fait adapté à la tâche de programmation du moment, compte comme des intérêts sur la dette. Donc, chaque refactoring que vous ne faites pas, vous devez payer des intérêts supplémentaires. Des organisations d'ingénierie entières peuvent alors être paralysées, dit-il, sous le poids de la dette d'une implémentation non suivie, orientée objet ou autre. Donc le paradigme n'a pas vraiment d'importance, ce qui est vrai. Je l'ai vu dans tous les paradigmes. Et, euh, euh, si vous ne faites pas cela, vous pourriez arriver à un arrêt. C'est ça le problème avec la dette technique. Je vais vous donner quelques exemples. Certains de ma propre, euh, euh, expérience. Donc, euh, fin 2013, j'ai été embauché par cette compagnie d'assurance. C'est leur immeuble de bureaux en fait. Euh, et, euh, ils voulaient se débarrasser de leurs systèmes actuels. Maintenant, ils avaient de très grandes bases de code fonctionnant sur un mainframe qui était au sous-sol. Je ne plaisante pas, n'est-ce pas ? C'était littéralement au sous-sol. Consommant toute l'énergie du bâtiment. Euh, euh, et ils avaient 18 millions de lignes de Cobol, donc 18 millions, 18 lignes de millions de lignes de Cobol, et 12 millions de lignes de Java. Vous pouvez débattre, bien sûr, de ce qui est pire, mais, euh, n'allons pas dans cette direction. Et, et le problème était avec, surtout avec les systèmes Cobol, je vais vous montrer un peu de code. C'est en fait une partie du code.
[00:08:13] Maintenant, comme nous sommes à Paris, vous ne pourrez probablement pas le lire car c'est en néerlandais.
[00:08:18] Cela signifie que beaucoup de gens dans l'industrie ne peuvent pas lire ce code parce qu'il est en néerlandais. C'est aussi plein d'abréviations, comme des acronymes de trois lettres, tous là-dedans. Personne ne sait plus ce que c'est, n'est-ce pas ? C'est aussi dans un dialecte bizarre de Cobol, donc il n'y avait pas beaucoup de développeurs qui pouvaient réellement le lire. Et le problème avec les développeurs de l'entreprise était qu'ils vieillissaient, bien sûr. Et ils voulaient prendre leur retraite. En fait, certains d'entre eux ont pris leur retraite et ont ensuite été réembauchés pour beaucoup d'argent, en fait, pour faire le même travail. C'était un modèle plutôt cool en fait. Donc, c'était, c'est un problème, n'est-ce pas ? Et puis ils sont restés bloqués car ils ne pouvaient plus innover. Deuxième exemple. C'est mon client actuel. Ce n'est pas une compagnie d'électricité, mais j'utilise les fils comme exemple que c'est comme, c'est comme des spaghettis, n'est-ce pas ? En gros. Donc, c'est une entreprise de commerce électronique, qui a commencé il y a 20 ans avec une seule offre sur une page web. Et c'était sympa. Et ils pouvaient mettre ça dans un tableau Excel et, bien sûr, les tableaux Excel ont tout le pouvoir du monde, n'est-ce pas ? Et, euh, et, et puis ça a grandi. Et ils ont commencé à ajouter des systèmes à leur environnement. Donc ils ont tout un tas de, euh, disons, de choses orientées client, des applications web, des applications mobiles, etc., etc. Et puis ils ont tout un tas de systèmes qu'ils ont trouvés quelque part et implémentés et y ont mis des données. Et, et chaque fois qu'ils avaient besoin d'une solution pour un problème, ils la mettaient simplement dans le système qu'ils maintenaient à ce moment-là, n'est-ce pas ? Donc, tous les comptes utilisateurs étaient dans le système CMS. Ce n'est pas à cela que sert un système CMS. Mais c'était pratique et les gens savaient faire du PHP, donc c'était bien. Donc, et puis ils ont commencé à faire des trucs de microservices. Euh, et bien sûr, ils ont comme, euh, toutes les plateformes que vous pouvez trouver, ils ont comme, ils avaient à la fois Azure et Google Cloud, et ils avaient un CDN qui tournait quelque part. Tournant ailleurs. Ils devaient s'intégrer avec tout un tas de parties.
[00:10:03] Euh, et, euh, avec le temps, toutes les données qu'ils avaient se sont en quelque sorte répandues dans tous ces systèmes. Et puis ils ont dû les maintenir synchronisés. Ce qui était encore pire. Ils ont donc créé toutes sortes de connexions entre ces systèmes. Ce n'est qu'un modèle, n'est-ce pas ? Ce n'est pas la représentation réelle. En réalité, c'est pire. Bien sûr.
[00:10:22] Donc, ils s'envoient en fait des CSV ou des feuilles de calcul Excel par mail, ils, euh, exportent des choses et importent des choses dans la base de données. Dans le code, hors du code, euh, d'un système à l'autre. Puis ils construisent un ESB pour s'assurer que cela se produit, euh, euh, et ils mettent en place un système de file d'attente stylé. Et personne ne savait comment les données passaient d'un système à l'autre. Et puis, euh, euh, ils sont restés bloqués. En gros, ils avaient donc une application mobile qu'ils n'avaient pas publiée depuis deux ans et demi. N'est-ce pas, c'est du commerce électronique, n'est-ce pas ? Il faut que votre application mobile soit lancée. Et ils sont tombés dans ce que j'appelle la mort technique. C'est le point, qui est essentiellement la dernière colonne de la diapositive, où tout le temps dont vous disposez est consacré à la maintenance de votre environnement actuel. Si vous en arrivez là, vous avez atteint ce que j'appelle la mort technique, pas la dette technique, mais la mort technique. Vous êtes condamné, en gros. C'est là que les entreprises cessent d'exister. Et c'est la façon la plus amicale de le dire. Alors, et la question est, la dette technique est-elle réellement le vrai problème ? Et j'ai compris, et beaucoup d'autres personnes l'ont aussi compris, que généralement, la dette technique est essentiellement une conséquence d'une certaine manière d'agir. Donc le vrai problème est toujours l'organisation et sa culture. C'est un endroit où les propriétaires de produits, les chefs de produit, les managers, euh, euh, les directeurs de département, tout ce que vous avez, sont tous des parties prenantes du logiciel. Et tous ont des voix plus fortes que les personnes qui maintiennent le logiciel. Ce n'est pas nécessairement une mauvaise chose. Ce n'est juste pas très constructif, parce que ce qui se passe, c'est que tout le refactoring que nous voulons faire en tant que développeurs, nous ne pouvons pas le faire parce que nous sommes accélérés par l'organisation pour ajouter autant de fonctionnalités que possible. C'est une situation que je rencontre assez souvent en fait. Et, et, et ce n'est pas une bonne chose. Cela mène à un autre problème, et ensuite je vais arrêter de m'enfoncer dans les problèmes. Donc, l'autre problème que nous avons est, euh, ce qu'on appelle le dilemme de l'innovateur, et c'est en fait une conséquence de ce qui s'est passé avant cela. Maintenant, le dilemme de l'innovateur est très bien, c'est en gros un graphique. C'est ce graphique. Alors, ce qui se passe, c'est que vous introduisez un produit sur le marché, n'est-ce pas ? Vous, vous le lancez, c'est fait, euh, et, et ça commence à devenir populaire. Euh, j', j'utilise toujours le thermostat intelligent comme exemple. C'était un appareil vraiment intéressant. C'était trop grand pour l'actuel, donc actuellement ils sont de cette taille et celui-là était de cette taille, il y avait comme un grand écran dedans. Donc, ils l'ont inventé. Ils l'ont mis en ligne, ils l'ont mis sur le marché, les gens voulaient économiser de l'énergie. Je parle d'il y a 15 ans, n'est-ce pas ? Euh, et puis ils, ils l'ont utilisé et ça allait de mieux en mieux. Et de plus en plus de gens l'ont acheté. Et ils ont commencé à y ajouter des fonctionnalités parce qu'ils pensaient que si nous ajoutions plus de fonctionnalités, plus de gens l'achèteraient. Donc, ils ajoutent des informations météorologiques sur cet appareil qui était sur votre mur dans votre maison, ce qui est plutôt sympa, sauf que tout le monde l'a sur son téléphone de nos jours, n'est-ce pas ? Donc ils ont été dépassés.
[00:13:19] Euh, et puis ils se sont dit : qu'est-ce qu'on peut faire d'autre ? Alors ils ont commencé à afficher des informations sur le trafic. Euh, mais les informations sur le trafic et la météo devaient transiter par Internet. En conséquence, ils ont construit un VPN avec deux millions d'appareils dedans. C'est le plus grand VPN d'Europe. C'était très, très coûteux à maintenir. C'était plus cher que l'argent qu'ils gagnaient. Donc, en conséquence, ils ont été rachetés. Donc, ils ont été rachetés par une compagnie d'énergie qui a dit, donc, si vous prenez un abonnement chez nous, vous obtenez l'un de ces appareils. Et c'était vraiment cool. Nous n'avons toujours pas gagné d'argent. Ils ne gagnaient toujours pas d'argent. Je n'étais pas encore là à ce moment-là. Et à ce moment-là, ils auraient dû prendre une direction différente. Ce qu'ils ont continué à faire, c'est ajouter plus de fonctionnalités à l'appareil, comme des fonctionnalités intelligentes. Comme, oh, nous pouvons dire quand votre machine à laver est en marche. Ils pouvaient le voir grâce aux schémas de consommation d'énergie. Donc, ils ont beaucoup investi dans, euh, les données et, euh, l'analyse et toutes sortes de choses. Mais personne n'achetait plus l'appareil car il était saturé, en gros. Et d'autres entreprises sont entrées sur le marché avec des produits qui étaient gratuits. Sans abonnement de la part de la compagnie d'énergie, mieux comme le Google, euh, euh, le Google Nest, les trucs Tado. J'ai un Tado à la maison, c'est, c'est bien. Ça marche, n'est-ce pas ?
[00:14:34] Euh, et ils ont été dépassés. Et ils sont tombés dans le dilemme de l'innovateur. Ils auraient dû se réinventer à ce moment-là. Ils ne l'ont pas fait.
[00:14:42] Et puis ils ont fait faillite. N'est-ce pas ? Et, euh, nous sommes partis, nous avons tous quitté l'entreprise. C'était une, c'était une triste réunion. C'était pendant le COVID et nous avons eu cette conférence téléphonique avec 120 personnes et le PDG a dû annoncer que l'entreprise avait cessé d'exister.
[00:14:57] Et, euh, et, et un certain silence est tombé dans l', dans l'appel. C'était un appel vraiment silencieux. C'était vraiment désagréable en fait. Donc, euh, et puis nous sommes passés à une autre entreprise. Mais, mais c'est un problème pour beaucoup d'entreprises, n'est-ce pas ? Et ils n'ont aucune idée de comment s'en sortir. Et la question est, que faites-vous ? Eh bien, alors vous m'appelez, n'est-ce pas ? Donc, non, c'est une blague. Euh, euh, donc, mais c'est le bon moment pour me présenter, n'est-ce pas ? C'est moi, euh, je suis Sander.
[00:15:20] Euh, euh, en néerlandais on dit Hogendoorn. Vous ne faites pas ça en français, je sais, mais n'hésitez pas à le prononcer comme vous voulez. Donc, euh, je suis, je suis en gros le père de mes trois enfants adultes. Euh, euh, un et demi vivent encore chez moi. Euh, je parle un peu, j'écris un peu, je voyage beaucoup, j'aime beaucoup voyager. Et, euh, je suis fondamentalement un programmeur de longue date. J'écris du code depuis 1978. D'accord, 1978. Si je fais ça à une conférence JavaScript, les gens dans la salle diront : quoi ? Mes parents n'étaient même pas nés à l'époque.
[00:15:50] Euh, Je suis actuellement le CTO de cette entreprise d'e-commerce appelée Ibo. Nous avons récemment ouvert en France en fait, c'est plutôt sympa. Euh, et j'étais auparavant le Global Agile Thought Leader de Cap Gemini, pour ce que ça vaut, n'est-ce pas ? C'est un beau titre. Donc, euh, euh, en fait pour, euh, Oh oui, c'est Ibo. Nous avons remporté le prix du site web de l'année aux Pays-Bas, ce qui était bien parce que je n'y travaillais que depuis deux ans.
[00:16:10] Euh, oui, je suis très surpris sur scène là, quelque part. Alors, pour vous prouver que je suis programmeur, voici mon nom. Euh, je suis en fait doublement orienté objet. Il n'y a pas moyen d'y échapper, bien que j'aime beaucoup plus la programmation fonctionnelle. Euh, c'est devenu pire, parce que j'habite dans la rue Java à Amsterdam.
[00:16:27] C'est, euh, eh bien, le mieux que vous puissiez faire en tant que développeur, n'est-ce pas ? Et, euh, oh, je contribue aussi à l'open source. C'est notre framework open source, c'est en TypeScript, c'est bien. Euh, donc j'écris beaucoup de code, c'est ce que j'aime faire. Alors, la question est, comment se débloquer si l'on est coincé dans la mort technique ou dans le dilemme de l'innovateur ? Et en gros, euh, euh, eh bien, ce que beaucoup de gens font, c'est qu'ils se lancent dans des transformations Agile, n'est-ce pas ? C'est ce que vous faites. Vous, vous achetez un livre sûr. Je ne suis pas sûr qu'il existe réellement un livre sûr sur le marché, probablement oui, n'est-ce pas ? Parce qu'il y a de l'argent à gagner. Donc, vous implémentez en toute sécurité, et puis vous vous retrouvez encore plus bloqué, n'est-ce pas ? C'est ça, c'est tout le problème parce que ça va dans la mauvaise direction. Vous devez aller dans l'autre direction. Euh, donc je vais vous montrer un peu comment aller dans l'autre direction. Euh, et je dois dire ceci d'abord parce que euh, c'est le principe du simple partage. Cela signifie que ce que je raconte, ça fonctionne en quelque sorte pour nous, pas toujours, mais ça fonctionne généralement pour nous. Cela ne signifie pas que ça fonctionne aussi pour vous, n'est-ce pas ? Alors, choisissez-en ce que vous voulez. Si vous n'aimez rien de tout cela, venez juste me critiquer après et ça ira. Alors, euh, qu'allons-nous faire ? Le plus intéressant, c'est que si vous êtes dans une entreprise qui essaie de gagner de l'argent, euh, il n'y a jamais un moment où vous pouvez dire, euh, ce que vous aimeriez dire si vous, si vous arrivez en tant que nouveau CTO dans une entreprise, ce que vous faites habituellement est de dire, il faut recommencer. C'est ce que font les CTO, n'est-ce pas ? Vous êtes embauché et la première chose que vous dites, oh, c'est de la merde, il faut s'en débarrasser. On recommence, à zéro.
[00:17:43] Et le problème est que vous ne pouvez pas. Parce que le magasin doit toujours rester ouvert, n'est-ce pas ? Donc, en conséquence, euh, euh, vous, vous arrivez à quelque chose que j'appelle la rénovation continue. Vous devez trouver et maintenir l'équilibre entre faire les nouvelles choses que vous voulez faire, mais aussi maintenir les anciennes choses et les faire fonctionner. Et comment faire cela n'est pas aussi facile qu'il y paraît. Parce que, eh bien, en gros, le magasin doit toujours rester ouvert, n'est-ce pas ? Alors, alors que faites-vous ? Eh bien, il n'y a qu'une seule chose à faire. Et c'est, vous devez compter sur la prise de petites mesures. Le problème avec la prise de petites mesures est qu'il y a toujours beaucoup de gens dans les entreprises qui sont toujours pressés. Généralement les managers, PDG, directeurs des opérations, des gens comme ça. Ils disent, oui, oui, mais quand est-ce qu'on obtient quelque chose, n'est-ce pas ? Et ils savent, vous savez, nous allons faire de petits pas. Cela signifie que la première étape que nous allons faire n'est probablement pas quelque chose qui livre tout de suite, bien que ce devrait être le cas, mais ça ne peut jamais l'être. Euh, donc il faut être patient. Et ce n'est pas leur plus grand vice normalement, n'est-ce pas ? Ce ne sont pas des gens très patients. Euh, et, euh, Je, je vais y glisser quelques citations aussi, n'est-ce pas ? Donc, c'est la loi de Gall, et, euh, John Gall dit, un système complexe conçu à partir de zéro ne fonctionne jamais et ne peut être rafistolé pour le faire fonctionner. J'ai vu ça, n'est-ce pas ? J'ai travaillé pour des banques. Donc, euh, et, euh, ça signifie qu'il faut commencer très, très simplement, commencer très, très, très petit.
[00:19:06] Et c'est ça le grand truc. Euh, et puis je vais ajouter Caan. Je n'étais pas sûr parce que j'étais probablement quelque part dans la pièce. Cela signifie que, euh, j'ai, vous avez déjà vu Caan, n'est-ce pas ? Donc je n'ai pas à l'expliquer en détail, mais Je vais, je vais le faire brièvement avec mes propres mots. Je vais probablement l'interpréter totalement de travers. Euh, c'est donc un framework qui est essentiellement écrit par un gars appelé Dave Snowden. Euh, et ça m'explique en quelque sorte où vous vous situez dans différentes situations. Donc, mon explication simple est toujours : si vous êtes dans la zone claire, autrefois zone simple, ou contexte, euh, s'il y a un problème qui se situe dans cet espace,
[00:19:41] c'est facile à reconnaître car il existe une meilleure pratique. Elle existe bien. Cela signifie que vous pouvez simplement l'appliquer. Exemple simple, s'il y a de la vaisselle dans l'évier chez moi, euh, pour une raison quelconque, les enfants ne savent jamais ce qu'est une machine à laver, n'est-ce pas ? Ils, ils, ils ne la trouvent pas. C'est sous la vaisselle, mais ils ne le savent pas en fait, alors, la seule solution à cela, je mets la vaisselle dans l'évier et j'allume la machine à laver. Ensuite, ils ne savent pas comment le nettoyer, mais bon, c'est un autre problème. Donc, il y a une meilleure pratique pour ça. Vous pouvez juste l'appliquer, c'est fait, n'est-ce pas ? C'est très linéaire. Si vous êtes dans l'espace compliqué, cela signifie une série de solutions parmi lesquelles vous pouvez choisir. D'accord, euh, si vous faites, euh, la gestion des identités et des accès, vous pouvez choisir, oh, je vais l'exécuter dans le Google Cloud, dans AWS, je vais l'exécuter dans Azure, je vais faire Okta, ou je peux, je peux même l'implémenter moi-même. Ne jamais, ne jamais faire ça, au fait. C'est une mauvaise pratique. J'ai essayé, ça échoue, n'est-ce pas ? Vous, vous vous faites pirater immédiatement. C'est le point. Donc, mais il y a un tas de solutions parmi lesquelles vous pouvez choisir. Cela signifie que vous pouvez faire une analyse, puis commencer à implémenter ces choses. Ce n'est pas très complexe, c'est compliqué, en fait. Si vous êtes dans la zone complexe ou dans la zone chaotique, cela signifie qu'il n'y a pas de bonnes ou de meilleures pratiques. Là, au mieux, des pratiques émergent. Quelqu'un l'a fait quelque part avant. Peut-être, n'est-ce pas ? Et la différence dans mon interprétation du modèle est que, euh, la différence entre chaotique et complexe est principalement : savez-vous où vous allez ? Je suis en AWS, je vais l'exécuter dans Azure, je vais faire Octa ou je peux même l'implémenter moi-même. Ne faites jamais ça d'ailleurs. C'est une mauvaise pratique. J'ai essayé, ça échoue, n'est-ce pas ? Vous vous faites pirater immédiatement. C'est le but. Donc, il y a un tas de solutions parmi lesquelles vous pouvez choisir. Cela signifie que vous pouvez faire une analyse et ensuite commencer à implémenter ces choses. Ce n'est pas très complexe, c'est compliqué en fait. Si vous êtes dans la zone complexe ou dans la zone chaotique, cela signifie qu'il n'y a pas de bonnes pratiques ou de meilleures pratiques. Au mieux, il y a des pratiques émergentes. Quelqu'un l'a déjà fait quelque part, peut-être, n'est-ce pas ? Et la différence dans mon interprétation du modèle est que la différence entre chaotique et complexe est principalement, savez-vous où vous allez ? Savez-vous où vous allez, cette chanson nulle ? Bref, donc. Donc, si vous savez où vous allez, vous avez un certain sens de l'orientation. Ce qui facilite le fait d'avancer, d'aller de l'avant. Si vous ne savez pas où vous êtes, vous ne savez pas où vous voulez aller, vous ne pouvez qu'espérer faire les choses dans la bonne direction. Et la seule chose que vous pouvez faire, d'ailleurs, normalement dans la technologie, parce que la technologie change aussi beaucoup, nous sommes généralement sur le côté gauche de ce diagramme. Cela signifie qu'il n'y a pas de solution facile aux problèmes que nous avons. Elles n'existent pas en fait. Si elles existaient, l'informatique ne serait pas une si grande industrie. Simple, n'est-ce pas ? Alors, que faites-vous ? Eh bien, Liz a formulé quelques déclarations à ce sujet. Elle dit, eh bien, vous pouvez en quelque sorte le diviser en ceci. Si nous savons tous comment faire cela, c'est simple, c'est clair, au mieux compliqué. Quelqu'un dans l'équipe est dans l'équipe et l'a déjà fait. Vous êtes bon aussi, n'est-ce pas ? Si j'ai de l'expérience dans mon équipe pour configurer Google Cloud, eh bien, nous pouvons nous lancer, n'est-ce pas ? Nous pouvons commencer. Les ennuis commencent si vous êtes en quatre ou cinq. Cela signifie que quelqu'un a fait cela mais pas dans ce contexte, c'est-à-dire probablement pas dans cette entreprise, ou pas dans le cloud dans lequel nous vivons, ou pas dans un environnement de commerce électronique, ou pas dans un environnement de deal quotidien, ou quel que soit l'environnement, n'est-ce pas ? Ou pire encore, personne n'a fait ça avant. C'est là que vous avez des problèmes. C'est là que vous êtes dans les zones compliquées, complexes ou chaotiques, et vous devez trouver votre chemin pour en sortir. Maintenant, Dave Snowden, qui est l'auteur du modèle, est un gars extrêmement intelligent. Il dit, eh bien, chercher les bonnes réponses est inutile dans un contexte chaotique, n'est-ce pas ? Parce que, eh bien, il n'y a tout simplement pas de modèle linéaire entre eux. Donc, ce que vous faites, c'est que dans ce domaine, vous devez innover. Il n'y a pas d'issue. Et la seule façon d'innover, d'ailleurs, est de mener des expériences. Et ce gentil monsieur rieur est Jeff Bezos, n'est-ce pas ? Et j'ai trouvé cette citation hier et il dit, eh bien, pour innover, il faut expérimenter. Si vous savez que ça va marcher, ce n'est pas une expérience. Parce que, eh bien, vous êtes probablement dans les zones compliquées ou claires, n'est-ce pas ? Cependant, il dit que la plupart des grandes organisations adoptent l'idée d'invention ou d'innovation. Elles veulent, mais elles ne sont pas non plus prêtes à en subir les conséquences, ce qui signifie que vous devez expérimenter.
[00:23:38] Si vous n'autorisez pas les choses, si vous n'autorisez pas les gens à expérimenter, si vous n'autorisez pas les choses à échouer, vous ne sortirez jamais des zones complexes et chaotiques. Et c'est un problème, n'est-ce pas ? Donc, la seule chose que vous pouvez faire est d'expérimenter. Et il y a une définition très claire sur Wikipédia qui dit, une expérience est un test effectué afin d'apprendre quelque chose ou de découvrir que quelque chose fonctionne ou est vrai. Ou faux selon la façon dont vous formulez votre hypothèse, n'est-ce pas ? Mais c'est tout. Vous devez vous permettre d'expérimenter. Et permettre aux gens d'expérimenter dans une organisation qui essaie de survivre, où la plupart des efforts sont consacrés à maintenir ce que nous avons, est vraiment difficile. Parce qu'il faut trouver le temps de le faire. Et une autre chose intéressante est que si vous ne faites aucun choix, le temps passe. Le temps passe si vous êtes déjà dans la zone du dilemme des innovateurs, c'est vraiment difficile parce que c'est le moment où vous êtes dépassé par d'autres entreprises et vous faites faillite. C'est donc toujours difficile, n'est-ce pas ? Alors, que faites-vous ? Eh bien, vous faites de petits pas. Ce que j'ai compris avec le temps, c'est que nous faisons de petits pas dans quatre domaines, en gros. Donc, nous voulons livrer des fonctionnalités plus petites au lieu de faire des produits ou même des projets. Et nous faisons ça en cycles plus courts. Vous pensez, oui, oui, nous faisons déjà du Scrum. Quelqu'un d'entre vous fait-il du Scrum ? Oh, personne n'ose l'admettre, n'est-ce pas ? C'est comme, vous pouvez aller à une conférence Kanban et admettre que vous faites du Scrum, n'est-ce pas ? C'est comme, oh, on va parler un peu de Scrum, n'est-ce pas ? Donc, vous devez entrer dans des cycles encore plus courts que ce que vous faites déjà. Avec différents types d'équipes, c'est du moins ce que nous faisons. Cela ne fonctionne pas nécessairement pour vous, mais et puis il y a aussi que vous le faites en composants beaucoup plus petits afin de pouvoir livrer beaucoup plus rapidement. Mais je ne vais pas aborder ce point car je peux parler de micro-architectures pendant des jours, ce que je ne ferai pas maintenant. Mais je vais parler de l'obtention de... oh, c'est encore... euh... parler de l'intégration de fonctionnalités plus petites. Alors, quelle est la première étape que vous pouvez faire ? La première étape est de déterminer où vous vous trouvez dans une zone chaotique ou complexe. Et ce que je fais habituellement, c'est que j'ai demandé aux managers, c'est le COO et le PDG de l'entreprise pour laquelle je travaille. Et je lui ai demandé, alors, quel est votre point à l'horizon ? Où voulez-vous que cette entreprise soit dans cinq ans ? La première réponse que j'ai eue dans cette entreprise est vraiment intéressante. C'est le PDG qui a dit, vous savez ce que je veux vraiment ? Je veux un chiffre d'affaires plus important avec des marges plus élevées. C'est ce que font les gens d'affaires, n'est-ce pas ? Alors, oui, d'accord, et quel logiciel voulez-vous que je construise pour ça, n'est-ce pas ? C'est mon outil, je peux développer des logiciels, je peux développer des logiciels avec une équipe, nous pouvons le faire assez bien. Mais qu'est-ce que vous voulez que nous construisions ? Qu'est-ce que cela signifie d'obtenir des marges plus élevées et un chiffre d'affaires plus important ? Ils ont donc dû aller chercher ce que devrait être l'horizon pointillé réel. Nous avons donc participé à toutes sortes d'ateliers, nous avons compris ces choses, nous avons assemblé des mots, nous les avons fait passer par notre IA à nos équipes marketing et c'est un peu ce que nous avons produit avec des phrases comme celle-ci, n'est-ce pas ? Et vous pourriez vous dire, oui, c'est vraiment abstrait, n'est-ce pas ? Oui. Cependant, ils donnent beaucoup de direction sur où vous voulez aller. Par exemple, si vous dites que vous voulez être le principal site de deals en Europe, vous n'êtes pas le principal site de deals en Europe si vous n'opérez que dans cinq pays. Cela met donc beaucoup l'accent sur l'internationalisation. Nous avons dû ajouter le français, en fait. Nous étions actifs en Belgique, mais seulement dans la partie néerlandophone de la Belgique, ce qui représente environ la moitié. Nous avons donc ajouté le français comme langue. Nous n'avions pas de personnes parlant français. Donc, nous avons cherché l'IA, nous avons fait beaucoup d'expériences pour voir si ça marchait, ça a marché en quelque sorte, et ensuite nous avons quand même embauché des personnes parlant français. Et ensuite, la prochaine étape était d'aller en France, ce que nous avons fait en quelque sorte, je crois que la semaine dernière, nous avons vendu 90 articles en France. C'est un pas en avant, n'est-ce pas ? Donc, nous devons probablement faire du marketing ici. Mais cela donne beaucoup d'orientation. Cela nous aide donc à savoir où nous allons. Et si vous savez où vous allez, vous êtes déjà dans un bien meilleur état. Et puis l'étape suivante est, il y a toujours trop de travail à faire pour que ce soit fait, n'est-ce pas ? Nous sommes une équipe de 30 personnes dans notre entreprise de technologie, et il y a toujours plus de souhaits, de bugs à résoudre, de grandes équipes, de grandes idées qui passent et que nous ne pouvons pas réaliser, n'est-ce pas ? Donc la conséquence de cela, et cela vaut pour la plupart des entreprises, est que vous devez en fait choisir. Alors comment choisissez-vous ? Parce que vous devez maintenir, vous devez garder la boutique ouverte et vous devez innover. Nous avons donc fixé des pourcentages. Nous avons dit, eh bien, nous allons consacrer 70% de notre temps à atteindre le point à l'horizon, nous allons faire 20% sur les petites fonctionnalités que les gens veulent ajouter aux systèmes existants et nous allons juste faire 10% sur tous les bugs qui passent, peuvent-ils toujours les avoir, n'est-ce pas ? Donc, en gros, si vous deviez cartographier cela, c'est comme 70% d'innovation, 20% de rénovation et 10% juste pour maintenir les lumières allumées. Et c'est en gros ce que nous avons commencé à faire. Et cela signifie que les personnes en charge, que nous appelons le Conseil Technique, nous avons mis en place un groupe de personnes pour en quelque sorte orienter et alimenter notre direction à suivre. Et nous pouvons dire, et ils viennent nous voir et disent, vous n'avez pas dépensé 20% pour la rénovation ce mois-ci. Vous n'avez pas traité suffisamment de tickets de ce tableau particulier. Nous avons des tickets, n'est-ce pas ? C'est Jira, je n'aime pas le mot, je n'aime pas le mot Jira non plus, mais c'est ce que c'est. Alors nous avons ce groupe de personnes qui sont en fait les parties prenantes de l'entreprise. Donc toutes les idées suffisamment importantes qui arrivent, euh, elles vont au conseil technique. Et ce groupe de personnes en discute. Quelqu'un propose une nouvelle idée et nous nous posons une série de questions. Donc, dans ce groupe, il y a le PDG, j'y suis, une des personnes de mon équipe y est, et ensuite en quelque sorte les leaders de chaque département de l'entreprise. Et nous discutons de la valeur de ces éléments. Et il est très difficile de décider de la valeur commerciale réelle. Il est également très difficile d'estimer quelle sera la taille de la chose. Nous nous posons donc ces questions. Cela nous aide-t-il à atteindre le point à l'horizon ? Sinon, nous le jetterons simplement ici. Nous n'y consacrons absolument aucun temps.
[00:29:42] Et la question suivante est, la question suivante est en fait, est-ce trop grand ?
[00:29:47] Si c'est trop gros, nous ne pouvons pas l'utiliser, nous ne pouvons pas le faire car cela prendrait tout notre temps et nous ne pouvons pas consacrer ce temps à d'autres choses. Il faut donc le décomposer. Alors nous le rendons aux gens et disons, s'il vous plaît, décomposez-le. Si vous voulez faire, euh, ce que nous faisons maintenant, du bétail, ce que vous voudriez en tant qu'entreprise de commerce électronique. Prenons ça, faisons le premier pas en premier. Et ensuite, si ça réussit, nous pouvons choisir ce que nous faisons ensuite avec notre temps, n'est-ce pas ? Et ensuite, nous disons, est-ce réalisable ? Pouvons-nous vraiment faire ça ? Avons-nous les personnes nécessaires pour faire cela ? Avons-nous la technologie nécessaire pour faire cela ? Savons-nous comment le faire ou est-ce fondamentalement complexe ? Et puis la question suivante est, parce qu'il y a toujours des choses qui passent par ces trois premières questions, est-ce que nous en avons besoin maintenant ? Avons-nous vraiment besoin de ça maintenant ? Est-ce le plus urgent que nous puissions traiter ? Si oui, c'est celui que nous choisissons. Sinon, nous le mettrons probablement dans la colonne un jour peut-être. Ce qui signifie que nous le faisons littéralement glisser dans une colonne qui se trouve à l'autre bout de nos tableaux et nous le réexaminons tous les trois mois environ. Et nous examinons ça. Ce qui est bien, c'est que la plupart des choses qui vont dans la colonne 'un jour peut-être', nous ne les faisons jamais. Parce que nous n'avons jamais le temps, c'est une raison, mais aussi parce qu'après environ un an, elles ne sont plus valides. Nous n'avons plus à les faire parce que le temps passe. Et c'est bien, n'est-ce pas ? Alors voici les tableaux, les tableaux physiques que nous avons, je voulais en fait vous les montrer parce que je les ai ouverts sur mon ordinateur portable, mais c'est en gros les choses les plus importantes, n'est-ce pas ? Nous avons dû faire, nous voulions faire du libre-service pour nos clients, n'est-ce pas ? Donc, nous voulons pouvoir déplacer l'enregistrement vers la nouvelle plateforme qui s'appelle Libags, reconstruire notre page de chasse, qui est une chose de vente spéciale. Ce sont donc tous les sujets plus importants. Les sujets plus petits vont sur un autre tableau. Que nous appelons le conseil général. Je ne sais pas qui est le conseil général, mais il est assez important dans notre entreprise. Et puis nous avons un canal de sélection pour les petites choses, n'est-ce pas ? Si vous avez une question, un bug ou autre, mettez-le simplement sur le canal de sélection, nous le prendrons en charge si nous avons le temps, si quelqu'un veut le prendre en charge en fait. C'est ainsi que nous divisons le travail, en gros, dans notre entreprise. Et ça fonctionne en quelque sorte parce que ça nous aide à démarrer. Et cela nous aide à nous concentrer sur les choses que nous devons vraiment faire pour nous éloigner de tout cet héritage que nous avons. Maintenant, la prochaine étape est d'entrer dans les cycles. Examinez les cycles.
[00:31:59] Alors, ce que je vois beaucoup de gens faire, c'est qu'ils implémentent Scrum et ensuite ils ont fini, n'est-ce pas ? C'est tout, nous faisons du Scrum. Et le problème avec ça, je vous le montrerai dans une seconde, c'est que, mais il y a une sorte d'évolution, n'est-ce pas ? Et c'est comme quand je suis entré dans cette industrie, nous faisions du waterfall.
[00:32:17] J'ai donc commencé à gagner de l'argent dans le développement de logiciels en 1987. Et les gens faisaient du waterfall. C'était tout, en gros. Il n'y avait pas d'autre moyen. Nous n'en connaissions pas d'autre. C'était tout. Et puis des choses comme le Processus Unifié Rationnel sont apparues, ce qui est fondamentalement sûr, mais il y a 20 ans. Écrit par les mêmes personnes et tout, mais c'est, oui. Peu importe, donc si vous ne savez pas ce qu'est le Processus Unifié Rationnel, pensez sécurité. Nous en sommes revenus à cela, n'est-ce pas ? Et puis nous sommes passés à des cycles plus courts. J'ai commencé à faire du DSDM au milieu des années 90, c'est-à-dire que nous avions des cycles de quatre à six semaines, ce qui était très court à l'époque. Parce que nous n'avions pas tous les outils disponibles que nous avons maintenant, n'est-ce pas ? Et puis nous sommes passés à Scrum et XP et le monde s'est amélioré. Et nous sommes passés à la livraison continue et au déploiement continu. Nous livrons maintenant en production, probablement avec notre petite équipe, environ, je dirais 20 à 40 fois par jour. Cela varie un peu selon le jour et ce sur quoi nous travaillons, mais c'est un peu ça. Nous sommes donc passés à des itérations de plus en plus courtes. Et le fait est, à chaque étape de ces mouvements, vous voyez beaucoup de gens qui sont à l'étape précédente. Alors, quand nous sommes passés à des cycles plus courts, les gens ont dit, non, nous devons faire le Processus Unifié Rationnel. Nous sommes standardisés sur le Processus Unifié Rationnel. Je travaillais pour ce grand cabinet de conseil à l'époque et ils ont dit, non, non, nous faisons le Processus Unifié Rationnel partout. Je me dis, non, non, je vais vous apprendre à faire de l'Agile. Donc, c'est 2000, n'est-ce pas ? 2003, 2004, et ils n'y croyaient tout simplement pas. Et maintenant ils sont tous en train de faire de l'Agile, et puis après un certain temps, ils ont commencé à faire du safe, et maintenant ils sont de nouveau de vrais consultants, ce qui est bien. Mais beaucoup de gens restent aussi bloqués sur Scrum, n'est-ce pas ? Maintenant, le truc avec Scrum, c'est que c'est devenu, c'est une religion, en fait, n'est-ce pas ? Donc vous avez des grands prêtres et vous avez des praticiens et bien, des églises où les gens vont et s'assoient en petits cercles et tout. Et la question que vous obtenez toujours si vous essayez de changer quelque chose dans la façon dont l'approche fonctionne, ils vous brûleront par le feu. Vous devenez un hérétique de l'église, n'est-ce pas ? Vous ne pouvez pas supprimer les rétrospectives de Scrum parce que vous ne faites plus de Scrum. Je me dis, oui, alors. Et puis tous ces gens du Scrum se disent, non, non, il faut faire le Scrum correctement. Comme vous voyez toutes ces citations partout, Internet en est plein en fait, n'est-ce pas ? Eh bien, vous faites du Scrum de la mauvaise manière. Voici comment le faire correctement. Bien sûr, il y a toujours quelqu'un qui sait exactement comment c'est, sauf qu'ils ne sont pas vraiment d'accord là-dessus. Et puis il y a d'autres personnes, faites-vous vraiment du Scrum ? Suivez ces directives pour en être sûr. Oh, ce sont des directives, c'est moins strict que des règles, n'est-ce pas ? Et est-ce que c'est bien de sauter des événements Scrum, n'est-ce pas ? Non, faux. Vous ne pouvez pas sauter les événements Scrum, quels qu'ils soient. Ou, quand une équipe implémente Scrum correctement, le framework apporte des bénéfices de valeur. Scrum prouve une fondation empirique pour les équipes, bla bla bla, l'équipe peut récolter les bénéfices de Scrum, quels qu'ils soient, n'est-ce pas ? Le Scrum Master est un leader, un coach, un mentor et tout. C'est le travail ultime, n'est-ce pas ? C'est comme le couteau suisse de l'informatique. Et ça empire, n'est-ce pas ? Ça dit, le Guide Scrum contient la définition de Scrum. D'accord. C'est 14 pages. Je peux lire cette définition. Chaque élément du cadre sert un objectif spécifique. Et puis ça empire. Il dit que si vous changez les idées de conception de base de Scrum, en laissant de côté des éléments ou en ne suivant pas les règles de Scrum, attention, les règles de Scrum, masque les problèmes et limite les avantages de Scrum. Cela signifie en fait que si vous ne faites pas Scrum à 100% correctement, vous ne pouvez pas blâmer Scrum si les choses tournent mal. Et c'est leur intention, n'est-ce pas ? Parce que sinon toutes ces certifications n'auraient aucun sens.
[00:35:45] Le problème est que personne ne sait comment faire cela correctement, n'est-ce pas ? Alors, ceci provient d'un projet que j'ai suivi à Bruxelles. Et ils construisaient des logiciels, ils avaient des sprints mensuels, donc c'est 2013, n'est-ce pas ? Il y a des lustres. Alors ce que vous faites au début du sprint, vous estimez le travail, quelle que soit la chose que vous faites pour l'estimation. Et puis vous essayez de faire le travail dans le cadre de... donc vous essayez de suivre la ligne idéale et à la fin du sprint, vous ne devriez plus avoir de travail. Il leur restait du travail, n'est-ce pas ? C'était le premier sprint. Puis un deuxième sprint est arrivé. Oh, il leur restait aussi du travail et puis un troisième sprint est arrivé et puis le chef de projet, oui, il y avait un chef de projet. Il a commencé à devenir en quelque sorte nerveux parce qu'ils n'ont pas réussi le sprint. Ils disent, vous êtes stupides. Vous, développeurs stupides, vous ne pouvez pas estimer le travail. Et oui, les développeurs se disaient, c'est vrai.
[00:36:31] Alors, euh, puis il, euh, eh bien, ça a empiré. Et ils ont réévalué. Il a donc embauché beaucoup de monde en Inde. Il n'y a rien de mal avec les gens d'Inde. C'est juste qu'il a embauché, je crois que c'était environ 80 personnes dans une équipe qui en comptait 40. Donc, c'est en quelque sorte, eh bien, ça a en quelque sorte réduit la productivité totale, n'est-ce pas ? Donc le projet était voué à l'échec, le chef de projet a été viré. Et tout a échoué. Mais, oui, ils n'ont pas fait de Scrum correctement, donc Scrum n'était pas à blâmer, n'est-ce pas ? Et le problème est que c'est en fait très difficile d'adapter un sprint. Parce que vous devez avoir cet objectif de sprint, bien qu'il y ait aussi un débat à ce sujet, n'est-ce pas ? Mais et puis vous dites, oui, oui, mais vous savez quoi, nous pouvons faire, nous pouvons finir trop tôt. Que faites-vous avec le temps ? Eh bien, vous ne pouvez pas étendre les choses qui vont dans un sprint, n'est-ce pas ? Parce que, eh bien, sinon vous ne suivez pas les règles. Alors, que faites-vous ? Eh bien, sortez, prenez des vacances. Ou bien, vous, les gens, l'acceptez vraiment très tard, ce qui est aussi mauvais. Oh, vous allez plus lentement que d'habitude, car nous, les développeurs, estimons de toute façon trop optimiste. Ou vous obtenez un dérapage du périmètre, des choses y sont ajoutées de toute façon, même si vous ne voulez pas le faire. Mais il y a de nombreuses façons dont cela peut mal tourner. Et ça empire parce que le fait est que le progrès n'est pas vraiment linéaire, n'est-ce pas ? Il ne va pas dans ce sens. Il y a des jours où les choses fonctionnent tout simplement, où elles sortent des machines, et il y a des jours où ça ne marche tout simplement pas, n'est-ce pas ? Hier, j'ai eu une journée, je suis allé à Paris, tout a cassé. Ce n'est pas parce que je suis à Paris, c'est parce qu'ils ont renvoyé un undefined au lieu d'un null. Et puis notre service de profil a planté et les gens ne pouvaient plus commander. C'est ce qui se passe, n'est-ce pas, en réalité. Et ça craint. Et ça signifie que toute notre productivité, notre vélocité a chuté parce que nous n'avons rien fait d'autre que de trouver ce bug particulier. Bien sûr, nous aurions dû écrire un test d'API, ce que nous n'avions pas fait pour ce cas particulier, donc c'était le problème. Donc ce n'est pas linéaire. Et la question est, qu'est-ce que l'Agile signifie réellement alors ? Maintenant, mon bon ami Allan dit ceci, et c'est la citation la plus juste sur l'Agile, je pense. L'Agile n'est pas un processus. L'Agile est la capacité à créer le vôtre. Et c'est là que vous devez aller, n'est-ce pas ? Vous devez définir le vôtre. Donc la question ne devrait pas être, euh, nous ne faisons pas Scrum correctement, elle devrait être, nous ne faisons pas Scrum, n'est-ce pas ?
[00:38:42] Ce qui est assez différent, je pense. Alors que devriez-vous faire ? Eh bien, je pense que vous devriez passer à des cycles encore plus courts. Livrer de manière encore plus continue. Cela signifie en fait, mettre des choses en ligne aussi vite que possible. Parce que comme le dit Jeff Humble, si ça fait mal, faites-le plus fréquemment et avancez la douleur. Il parle de la publication de logiciels, d'ailleurs. Euh oui, n'essayez pas ça dans d'autres trucs, mais Et c'est plutôt cool, n'est-ce pas ? Parce que c'est un peu contre-intuitif si vous commencez à faire ça pour la première fois. Mais vous dites, quoi, si je livre plus vite, c'est plus facile ? Oui, en fait. Parce que le fait est, et je l'ai vu, je travaillais pour cette entreprise qui circule avec des trains aux Pays-Bas. Je ne vais pas la nommer, mais vous pouvez probablement deviner, n'est-ce pas ? Et ils avaient un très grand paysage monolithique et ils sortaient une version tous les trois mois. C'était le mieux qu'ils pouvaient faire. Et puis ils ont livré un tas de changements en même temps, ce qui signifiait qu'une grande partie du temps qu'ils passaient à le publier, environ six semaines, ils devaient tester tout le paysage. Je vous montrerai le paysage dans un instant. Cela signifie qu'ils ne pouvaient pas publier plus rapidement. Ils n'avaient de toute façon aucune intention de sortir plus vite. En fait, ils sont allés dans le sens de dire, eh bien, c'est vraiment difficile à faire, n'est-ce pas ? Peut-être devrions-nous passer à des versions de six mois.
[00:39:55] Et si vous faites ça, vous passez à des releases d'un an. Je travaille pour une entreprise qui a fait ça. Et à la fin, ils n'ont plus rien sorti du tout, n'est-ce pas ? Ils étaient totalement bloqués. C'est aussi de la dette technique. Donc le fait est, Oh, voici leur paysage d'ailleurs, si vous pensez que chaque rectangle ici est une classe, non, ce n'est pas ça, c'est un système. Et chacune de ces lignes représente des dépendances entre les systèmes dans le paysage. Au fait, ce n'est que leur service client.
[00:40:22] Donc c'est juste se connecter, vérifier votre bilan comme ça. Et il y a de jolis systèmes là-dedans. Cette petite chose ici s'appelle, où est ma chose ? n'avait de toute façon aucune intention de publier plus rapidement. En fait, ils sont allés dans la direction qui disait, eh bien, c'est vraiment difficile de faire ça, n'est-ce pas ? Peut-être devrions-nous passer à des publications tous les six mois. Et si vous faites cela, vous passez à des versions d'un an. J'ai travaillé pour une entreprise qui a fait cela, et finalement, ils n'ont plus rien publié du tout, n'est-ce pas ? Ils étaient complètement bloqués. C'est aussi de la dette technique. Donc le truc, c'est que c'est leur paysage, soit dit en passant. Si vous pensez que chaque rectangle ici est une classe, non, ce n'est pas ça, c'est un système. Et chacune de ces lignes représente des dépendances entre les systèmes du paysage. Au fait, il s'agit uniquement de leur service client. Donc c'est juste se connecter, vérifier votre bilan comme ça et euh il y a de jolis systèmes là-dedans. Ce petit truc ici s'appelle où est ma chose, oh là, n'est-ce pas ? Où est-ce que je fais ? Ah oui, je ne devrais pas trop l'utiliser. On dirait que je suis ivre. Donc euh, euh, comme SAP CRM.
[00:40:36] Nous avons une fois compté les tables dans ce système SAP CRM. Il avait, je ne vais pas vous faire deviner parce que vous ne devinerez jamais. Il y a 142 000 tables là-dedans. N'est-ce pas ? Et ce n'est qu'un des rectangles de ce paysage. C'est aussi pourquoi les consultants SAP sont si incroyablement chers. Euh et le truc, c'est que si vous passez à de très petites versions, vous savez, chaque petite partie du système. C'est aussi pourquoi vous devez en quelque sorte transformer votre système en des parties beaucoup plus petites en utilisant toutes les techniques, comme euh nous utilisons beaucoup de DDD là-dedans, euh pour rendre les domaines vraiment, vraiment petits, et vous pouvez publier chaque partie séparément, n'est-ce pas ? Et si vous pouvez faire ça, cela signifie que vous êtes dans un bien meilleur espace car l'écart entre deux versions d'une même chose est beaucoup plus petit. Et si c'est beaucoup plus petit, c'est plus facile à tester, plus facile à déployer, plus facile à publier. Et c'est là que vous pouvez aller, n'est-ce pas ? Donc, euh, une jolie citation à ce sujet, au fait, et c'est probablement ce qui, si cela vous semble contre-intuitif, la prochaine citation y parviendra en fait. Voici Jason et Jason dit : Rater le bus n'est pas grave si vous savez qu'il y en aura un autre dans cinq minutes, n'est-ce pas ? Et c'est la citation que j'utilise en fait avec les managers. C'est comme, écoutez, nous allons publier. Oui, mais si ça casse quand tu publies ? Ça pourrait casser. Oui, ça pourrait. Ça va casser en fait. Ça arrive tout le temps, mais on peut le réparer en cinq minutes. Et c'est ça le grand avantage, n'est-ce pas ? Si quelque chose ne va pas, si quelque chose ne nous plaît pas vraiment, on peut juste appuyer à nouveau, n'est-ce pas ? Nous faisons un petit changement, nous changeons l'indéfini en nul, ce que nous avons fait hier après-midi, et ensuite nous le publions à nouveau et tout va bien. Si vous ne pouvez publier qu'une fois tous les trois mois, vous ne pouvez pas faire ça. Ce qui signifie qu'il n'y a pas de bus à venir. Si vous avez manqué le bus, euh, eh bien, vous savez qu'il n'y aura pas d'autre bus avant les trois prochains mois. Alors tu dois être dessus. Cela signifie que tout doit être là. Cela signifie que les gens poussent en fait vers mettre tout dans la prochaine version tout le temps, ce qui met beaucoup de stress inutile dessus. Et ce que vous devez faire pour cela, c'est automatiser tout. Euh nous faisons cela euh et ce n'est pas que nous soyons parfaits, mais nous avons parcouru un long chemin avec ça. Et euh Edward Deming a une belle citation et il dit, eh bien, vous devez éliminer le besoin d'une inspection massive en intégrant la qualité au produit dès le départ. Donc, tester après coup est coûteux. Les révisions par les pairs sont coûteuses. Les demandes de tirage (pull requests) sont coûteuses car toutes sont effectuées après le travail réel. N'est-ce pas ? Donc, il faut l'intégrer. Cela signifie qu'il faut euh, l'automatiser. Et une autre citation de Jason encore, parce que j'aime beaucoup Jason en fait, il a de belles citations. Il dit : J'ai passé quelques bonnes années à chercher et à comprendre ce dont les utilisateurs avaient besoin, euh, à traîner avant de réaliser que l'information se trouve de l'autre côté d'une publication. C'est plutôt sympa, n'est-ce pas ? C'est vrai, n'est-ce pas ? On ne peut pas, généralement, quand on expérimente, on arrive au point où oui, je veux publier quelque chose pour que vous puissiez le voir, travailler avec, le vivre et voir ce qui se passe. Et c'est ce que nous avons commencé à faire. Nous avons commencé à prendre de l'avance sur notre équipe marketing. Ce qui est généralement très difficile car ils vont partout, comme il n'y a juste pas euh, eh bien, on ne peut pas les retenir, n'est-ce pas ? Ils sont partis en une minute. Ils ont un nouvel outil là-bas, une nouvelle chose là-bas, une nouvelle chose là-bas. Et nous avons commencé à leur fournir des choses que nous pensions utiles. Nous l'avons juste construit, nous le leur avons donné et avons dit, regardez, nous pouvons maintenant faire ça. Et ils sont là, ah, cool. Et puis nous espérions que ça prendrait feu et que nous aurions de nouvelles idées à partir de là, et ça commence à arriver doucement maintenant. Ils reviennent doucement vers moi en disant, écoutez, nous pouvons maintenant envoyer notre préférence de marque, mais pourriez-vous aussi les envoyer à Insider parce que nous voulons envoyer des e-mails de là et tout ce qu'ils veulent faire. Donc ça commence à fonctionner, n'est-ce pas ? Et c'est en fait quelque chose qui fonctionne. Si vous faites cela, vous devez investir dans l'implémentation de pipelines complets. Je voulais en fait vous montrer le mien, mais j'ai peur parce que c'est ma nouvelle machine. C'est la première fois que je l'utilise sur scène. Si je vais dans mon navigateur, je ne pourrai pas revenir à la bonne diapositive de ma présentation, alors je vous la montrerai depuis la présentation. Ceci est l'un de nos pipelines réels. C'est ce qui se passe si nos services passent par le pipeline. Ils sont construits, formatés, nous faisons du linting, nous exécutons les tests unitaires, nous lançons Sonar pour voir si l'outil d'analyse de code statique, n'est-ce pas ? Euh ensuite, nous le publions. Ensuite, nous le déployons dans un conteneur Docker, nous exécutons le test API dessus sur l'environnement de développement, puis nous le déployons en acceptation, nous exécutons des tests de charge et ensuite nous le mettons en production. Et nous faisons beaucoup d'autres choses de bootstrapping là-bas aussi. C'est un pipeline beaucoup plus long, soit dit en passant, mais cela explique en quelque sorte le processus. Et c'est entièrement automatisé. À chaque changement que je fais dans le code, c'est ce qui se passe. Et il va en production automatiquement sans même que j'aie à le regarder. Je pourrais littéralement l'essayer, mais les pipelines tourneraient pendant environ 15 minutes de nos jours. Euh, euh donc ça prend beaucoup de temps de faire ça, alors je ne vais pas le faire maintenant. Donc, euh et puis aussi votre infrastructure doit devenir du code. Parce que vous ne pouvez pas avoir vos environnements configurés manuellement si vous déployez automatiquement tout le temps. Parce que si l'un des environnements tombe en panne, il doit se relancer automatiquement. Parce que sinon, vous devez le surveiller, cela prend du temps, vous devez le réparer manuellement. Il y a des gens qui font des choses manuelles et les choses manuelles mènent toujours à des exceptions et à des pannes. Il faut donc l'automatiser. Donc toute l'infrastructure est aussi du code. Et si vous faites cela, vous atteignez une certaine sérénité qui vous permet de simplement publier du code, parce que, eh bien, tout ce qui se trouve en dessous est automatisé. Et c'est agréable. Donc, euh, je vais sauter les tests un instant et passer à, attendez, laissez-moi sauter un peu les tests. Euh, et le truc, c'est que, euh, euh si vous faites
[00:45:56] les tests, les tests se déroulent également dans le pipeline. Donc, le même pipeline que j'avais plus tôt, nous faisons des tests unitaires, de la validation de syntaxe, de l'analyse de code, des tests d'API, des tests web, des scénarios de bout en bout, etc., etc., tout au long du pipeline. Ce qui signifie qu'au final, tout est testé automatiquement. Il n'y a pas de test manuel, sauf lorsque nous construisons des choses. C'est tout. Quand nous le publions, il est là. Et c'est automatisé. Et ça veut dire qu'on peut, on peut sortir une version toutes les cinq minutes ou toutes les cinq secondes ou peu importe. Et ce qu'il y a de bien avec ça, c'est que nous pouvons en fait commencer à coder en toute confiance. Nous n'avons pas besoin de prier comme ce monsieur ici, euh, pour travailler en fait. Je sais pourquoi il prie, n'est-ce pas ? Parce que, eh bien, il a son identifiant en mode clair. On ne fait pas ça. C'est dans les règles de Scrum, n'est-ce pas ? Vous ne pouvez pas mettre vos identifiants en mode clair. Donc la dernière partie de celui-ci. C'est un peu sur les équipes. Alors qu'en est-il des équipes ? Eh bien, les équipes sont intéressantes. La belle citation d'Esker Dijstra est qu'il dit, eh bien, le programmeur doit être capable de penser en hiérarchies qui sont beaucoup plus profondes que ce qu'un seul esprit n'a jamais eu à affronter auparavant. Il dit en fait que le développement logiciel est la chose la plus complexe que vous puissiez faire. Probablement chaotique aussi. Mais euh, euh et cela signifie que c'est devenu trop grand, n'est-ce pas ? Quand j'ai commencé à écrire du code dans les années 70 et 80, c'était assez simple. J'avais cet écran noir avec des caractères verts dessus. Je pouvais dire 'run' et ça lançait le programme sur ma machine. C'était tout, en gros. Et si je voulais le lancer sur la machine de quelqu'un d'autre, je le mettais sur une disquette. Et je donnais la disquette à quelqu'un d'autre et ils l'installaient et ils lançaient le programme. C'était tout en gros. Mais c'est devenu beaucoup, beaucoup, beaucoup plus complexe. J'ai fait une requête, la société qui a fait faillite, euh j'ai demandé aux développeurs, alors qu'est-ce qu'on utilise ? Et ils ont dressé cette liste. Et ce sont 30 développeurs qui maintiennent un VPN pour 2 millions d'appareils et tout le logiciel qui y tourne dans toutes les langues qu'ils utilisaient pour les systèmes embarqués, le web et les applications, et c'est énorme, n'est-ce pas ? Si vous devez maintenir cela, eh bien, vous êtes foutu en gros. Ils l'étaient, d'ailleurs. Donc c'est quelque chose que vous ne devriez pas faire. Ce que j'ai le plus réalisé de cette mission particulière, c'est qu'il y a tellement de choses dont je n'ai vraiment aucune idée, n'est-ce pas ? Euh, je suis dans cette industrie depuis longtemps. Je sais comment écrire du code, mais il y a tellement de choses sur lesquelles je n'ai aucune connaissance. Et je ne veux pas avoir de connaissances sur toutes ces choses, car sinon je ne pourrais pas faire le travail que je fais. Donc, on réalise que l'on ne peut plus construire de logiciels tout seul. Et ça fait longtemps que c'est comme ça et ça ne va pas s'améliorer. Sauf si vous le construisez avec l'IA. Parce que quand vous faites de l'IA, selon une citation de Jeff Sutherland il y a deux jours sur LinkedIn, il a dit, avec l'IA, vous pouvez générer 80% de votre code, ce qui signifie que nous pouvons être cinq fois plus productifs. Et je me dis, attendez, c'est vrai si on tapait toute la journée. Mais nous ne le faisons pas, n'est-ce pas ? Alors d'où viennent ces chiffres ? Il n'a pas encore répondu, mais j'espère qu'il le fera. Donc la réalisation est venue que la plus petite unité de propriété dans le développement logiciel est l'équipe. Il n'y a pas d'autre moyen. C'est ça. C'est l'équipe. Nous devons faire la chose. Une autre prise de conscience est venue il y a longtemps, à savoir que la dynamique d'équipe avec les équipes avec lesquelles je travaille était en fait assez différente de celles auxquelles j'étais habitué lorsque nous avons commencé à faire de l'Agile. Et euh j'ai commencé à regarder euh euh comment ça marche en musique. Donc j'ai trois enfants très musiciens. Un de mes enfants est un batteur professionnel, ce qui est vraiment sympa si vous vivez dans une petite maison. C'est euh sauf les voisins qui se plaignent tout le temps, mais euh et puis ils ont dit, eh bien, il va devenir pro. Et puis ils ont dit, oh, cool. Et puis il n'y a plus eu de problème. Alors oui, si on regarde le jazz, n'est-ce pas ? Je suis ici à un concert de jazz à Amsterdam. Mais euh la belle prise de conscience est venue en fait de ce concert. C'est un grand orchestre néerlandais appelé The New Cool Collective. Il y a environ 20, 30 personnes dans l'équipe, en gros, et ils produisent de la musique. Ils peuvent le faire avec tout un groupe, mais ce qui arrive généralement, c'est que de plus petits groupes de ce big band se réunissent et jouent différents types de musique. Comme s'ils veulent jouer une ballade, il y a le pianiste et quelqu'un qui chante et peut-être une trompette et des choses comme ça. Donc cela diffère de ce qu'ils font, de la configuration de ce, eh bien, du sous-ensemble de ce groupe qui fait le travail réel sur une chose particulière. Et nous avons commencé à imiter cela. Donc nous avons dit que, en gros, si nous voulons faire avancer tous les logiciels, si nous voulons pouvoir les publier, alors euh nous devrions avoir toutes ces compétences dans l'équipe, n'est-ce pas ? C'est donc essentiellement un ensemble de compétences, comme tout ce dont vous pourriez avoir besoin pour produire des logiciels. Et si vous faites cela, euh, euh, ce qui est intéressant, c'est que vous pouvez travailler avec tout ce groupe. Si vous devez faire des trucs de design et ça et et ça diffère. J'ai vu des groupes de ce genre travailler dans des entreprises où j'ai travaillé, jusqu'à 40, 45 personnes, et ça marche toujours, les mêmes principes que je vais vous dire maintenant. Euh donc vous pouvez voir le collectif en action. C'est là que nous faisons une session de conception. Ça a l'air un peu chaotique, ça l'était probablement. Euh en voici une autre, mais il n'y a que six personnes sur la photo. Il y a en fait 40 personnes dans cette équipe. Euh les autres sont euh, eh bien, ils sont arrivés en retard. J'ai pris cette photo très tôt le matin, personne ne se présente très tôt le matin, n'est-ce pas ? Donc c'était avant le COVID apparemment parce que nous sommes assez proches les uns des autres. Et c'est l'ensemble des compétences dont vous avez besoin pour faire avancer vos affaires. Et c'est beaucoup plus grand si l'on prend en compte toutes les choses supplémentaires qui se passent là-bas. Les choses que vous faites occasionnellement, comme l'UX. Bien que j'aie récemment rencontré un projet où j'avais cinq personnes UX dans l'équipe. Je n'avais jamais vu ça auparavant. Cinq UX, oui, des gens de l'UI, je connais, des développeurs front-end, oui, mais des gens de l'UX, cinq. C'était comme sur les 100 personnes qu'ils avaient dans l'équipe. C'était vraiment, vraiment, vraiment beaucoup. Mais bref. Donc, euh et le truc, c'est que ces groupes de personnes travaillent le mieux ensemble si vous pouvez leur donner l'autonomie dont ils ont besoin. Maintenant, j'ai essayé de promouvoir l'autonomie et l'auto-organisation pendant très longtemps. Comme probablement 20, 25 ans, bien que cela soit devenu très évident dans les années 2010 et des choses comme ça. Mais le problème avec l'autonomie, c'est que c'est vraiment difficile. Il est difficile de donner de l'autonomie si vous êtes un manager, car la plupart des managers ont de réels problèmes avec cela. Il est aussi difficile d'avoir l'autonomie en tant qu'équipe ou en tant que membre d'équipe, car pour beaucoup de gens, le problème avec ça, c'est que ça se situe en dehors de leur zone de confort. L'un des développeurs de mon équipe actuelle, quand j'ai commencé à rejoindre l'équipe, j'ai dit, eh bien, c'est à vous de décider sur quoi vous travaillez, n'est-ce pas ? Il y a beaucoup de choses que nous pouvons faire. C'est ce qui a déjà été priorisé, nous pouvons le choisir si nous le voulons. Vous choisissez. Et il a dit, eh bien, voulez-vous que je travaille sur le système EAP ou sur les nouvelles choses TypeScript ? J'ai dit, c'est à vous. C'est votre responsabilité. Oui, oui, oui, mais qu'est-ce que vous voulez que je fasse ? Et c'est la question que vous entendez souvent, n'est-ce pas ? Si vous dites, c'est à vous. Et la première question que les gens vous posent est : oui, mais qu'est-ce que vous voulez que je fasse ? Et je me dis, qu'est-ce que tu penses devoir faire, n'est-ce pas ? C'est toujours renvoyer la question, n'est-ce pas ? C'est la stratégie. Et euh mais c'est très compliqué. C'est aussi très difficile à expliquer. Je pense que c'est comme, euh si je demande aux gens de dessiner une chouette, je peux dire, oui, vous savez, vous commencez par deux cercles. Oh, et puis vous dessinez la chouette. C'est comme ça, n'est-ce pas ? C'est comme euh c'est vraiment compliqué de faire comprendre ça. Et et le truc qui est venu à l'esprit à un certain moment, et c'est bien formulé par un gars appelé euh D. Hock, qui était le PDG de Visa. Et il a dit, eh bien, un objectif et des principes simples et clairs donnent naissance à un comportement complexe et intelligent. C'est cool, non ? Si vous gardez les règles simples, les gens commencent à réfléchir. Si vous leur donnez beaucoup de règles, comme des règles et des réglementations complexes, cela donne naissance à des comportements simples et stupides. Vous avez vu ça, n'est-ce pas ? Des gens qui suivent des règles, ils suivent juste des règles.
[00:53:36] D'accord, tu veux que je fasse ça ? D'accord, je vais le faire. C'est ainsi que beaucoup d'équipes sont gérées. Et il dit, eh bien, le contrôle obsessionnel n'est pas toujours la réponse au chaos. Probablement jamais. Simplifier pour amplifier. J'aime cette expression. C'est vraiment cool, n'est-ce pas ?
[00:53:50] Alors, euh que faites-vous ? Eh bien, J'ai compris que je donnais moins de règles aux gens.
[00:53:56] Et moins je leur donnais de règles, et c'est une chose intéressante, c'est un carrefour près de chez moi à Amsterdam. Et ils ont fait une expérience avec ça. C'était un carrefour assez populaire. Il n'y a plus personne ici parce que, eh bien, nous n'avons pratiquement plus de voitures à Amsterdam, ou pratiquement plus de voitures. C'est vraiment cool. C'est en fait le début d'une autoroute cyclable qui traverse le centre de la ville à Amsterdam. Il n'y a plus de voitures là-bas. Donc, ils ont enlevé tous les panneaux. Il y avait des feux stop ici et euh des feux de circulation et tout, ils ont tout enlevé pour voir ce qui allait se passer. Et euh ce qui s'est passé, c'est que si vous arrivez à ce carrefour et que vous savez que ça va arriver, vous observez les autres usagers de la route, n'est-ce pas ? Vous surveillez ce qu'ils font, vous estimez leur vitesse. Vous regardez s'ils conduisent une BMW, auquel cas vous devez faire attention, ou s'il y a un tram, ils sont beaucoup plus gros que vous, donc prenez en compte toutes ces situations et les gens commencent à communiquer entre eux. Et c'est ce qui se passe quand on donne moins de règles aux gens. Euh donc si vous regardez mon équipe actuelle, c'est mon équipe actuelle. Ce sont mes amis, n'est-ce pas ? C'est pourquoi ils sourient tous. Non, j'ai dit 'souris', et puis ils ont souri. Et nous sommes passés d'une équipe très réglementée à une équipe qui n'a pratiquement aucune règle. Et donc c'est mon français. Je vais essayer en français. C'est bon ? Donc la perfection. Alors, c'est Antoine de Saint-Exupéry, n'est-ce pas ? Et il a dit, la perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. Et euh c'est ça le truc, n'est-ce pas ? Merci. J'étais un peu nerveux à propos de cette diapositive, mais c'est ça le truc, n'est-ce pas ? Si vous atteignez la perfection quand il n'y a plus rien à retirer. Et c'est ce que nous faisons, n'est-ce pas ? Donc, nous nous retrouvons en fait à travailler d'une manière totalement différente de n'importe quelle autre équipe avec laquelle j'ai travaillé, et c'est comme ça que ça devrait être. Ce n'est pas que chaque équipe devrait travailler de cette façon, chaque équipe devrait travailler de la manière qu'elle juge appropriée. Et c'est en fait ce que nous faisons. Nous n'avons pas de Scrum, pas de Kanban non plus, pas de sprints. Donc nous avons supprimé les sprints. Nous n'avons plus de Scrum Masters, nous n'avons plus de rétrospectives non plus. Parce que nous travaillons ensemble toute la journée. Qu'y a-t-il à rétrospecter ? Eh bien, rien en fait. Nous n'estimons pas. Sauf des chiffres approximatifs dans le conseil technologique comme, oui, cela nous prendra probablement deux à quatre mois. Euh, nous n'avons pas de product owner, pas d'histoires, euh pas de backlog à euh, aucune idée. C'est fondamentalement ça. Et vous savez quoi, les gens sont toujours heureux. Alors ce qui s'est passé, c'est ça. Donc nous faisons beaucoup de ma programmation, par exemple, n'est-ce pas ? C'est ce que nous faisons toute la journée, nous nous asseyons dans différentes constellations à travailler ensemble. Mais ce qui se passe réellement, c'est ceci. C'est que nous avons commencé à nous concentrer sur la résolution de petits problèmes chaque jour. Et plus ils sont petits, c'est ce que le reste des diapositives aurait dû vous apprendre. Plus ils sont petits, mieux vous pouvez les résoudre. C'est donc là que les choses, le travail sort, n'est-ce pas ? Et le truc, c'est que aucun des deux éléments sur lesquels nous pouvons travailler ne nécessite exactement le même ensemble de compétences de la part de ce collectif plus large. Cela nécessite un sous-ensemble, n'est-ce pas ? Parfois, vous avez besoin d'un architecte, d'un développeur back-end et d'un QA, parfois vous avez besoin ce que j'ai mis ici, un développeur et architecte DevOps. En fait, il sourit parce qu'il n'est pas DevOps en fait, mais euh Non, c'est un développeur Java, n'est-ce pas ? Donc euh, ce n'est pas que vous puissiez le reconnaître parce qu'il n'a pas de barbe, n'est-ce pas ? Euh mais euh bref. Oui, et euh euh voilà le truc. Alors nous commençons à travailler un peu comme cette recette et ce n'est pas quelque chose que nous faisons consciemment, ça arrive juste, n'est-ce pas ? Euh quelqu'un a fini ce qu'il faisait avant. Oh, ils choisissent un nouvel article. Vous savez, je vais travailler sur ceci et cela. Et quelqu'un d'autre a dit, vous savez quoi, je vais vous accompagner là-dessus parce que je veux en savoir plus sur cette chose ou en savoir plus sur cette chose. Euh, nous nous asseoirons ensemble, ferons du travail. Et nous pouvons nous asseoir ensemble à tout moment, à tout endroit où nous voulons, n'est-ce pas ? Parce que ça n'a pas d'importance parce que ce ne sont que deux ou trois personnes. Donc, qu'ils soient dans un bar, dans un pub, au bureau, à la maison, le soir, le matin, le week-end, je m'en fiche. Quoi que tu fasses, n'est-ce pas ? Ce qui te motive. Ils font le travail. Ils disent, bon, on a fini, on va faire autre chose. Ils se séparent à nouveau et ça fonctionne différemment. Je vais vous en montrer quelques exemples. Et c'est vraiment sympa. C'est un gars DevOps et un développeur Java. Euh oui. Bon point. Euh ici vous voyez ce sont trois des développeurs de mon équipe. Non, ils ne font pas de Java, bien qu'ils aient des barbes. Euh ils utilisent TypeScript. Euh et Francisco et ils font probablement du back-end, parce que Francisco a l'air vraiment brumeux, comme, qu'est-ce qu'ils font, n'est-ce pas ? Maintenant, il connaît aussi le back-end. En gros, tout le monde connaît un petit peu tout des autres aspects également. Voici deux développeurs et un testeur. Bien sûr, le testeur doit se tenir debout, n'est-ce pas ? C'est à ça que sert le testeur. Euh et euh euh plus. Ah oui, c'est un architecte et un développeur. sur un projet différent. Euh bien sûr, le développeur sait que ça ne va pas marcher. L'architecte prie toujours. Euh, oui. C'est des choses qui arrivent, n'est-ce pas ? Donc, euh et c'est ça le truc. Et c'est en fait un principe sympa. Ce n'est pas très conscient. Si j'allais dans mon équipe et que je disais, travaillez-vous en micro-équipes ? Ils diraient, oui, je crois. Je ne suis pas sûr. Parce que ça n'a pas vraiment d'importance ce qu'ils font, n'est-ce pas ? C'est ce qu'ils font. Euh et c'est très contextuel parce qu'ils prennent leurs propres décisions. C'est une grande autonomie, n'est-ce pas ? Ils peuvent prendre leurs décisions sur tout ce qu'ils veulent. Euh Eugene de mon équipe a déployé une nouvelle version de nos pipelines hier juste parce qu'il le pouvait. Il pensait que c'était mieux. Et puis il a dit, oh, cool, super, merci de faire ça, n'est-ce pas ? Donc c'est très euh très haute autonomie. Et c'est cool. Et puis euh les gens me demandent, oui, mais est-ce que ça scale ? Pour être honnête, je m'en fiche. Je ne me soucie plus des grandes entreprises. J'ai perdu ça il y a longtemps. Ce qui est bien, c'est qu'ING, euh la grande banque, n'est-ce pas ? Euh si vous les connaissez, c'est euh bon, ils ont ce logo orange. Bon, je sais pas, peu importe. Et ils l'ont en fait essayé et ils ont dit, eh bien, ça marche plutôt bien aussi en dans les organisations en scaling. Remarquez, ils faisaient du Safe combiné avec le modèle Spotify avant, n'est-ce pas ? Donc euh c'est un grand changement, je suppose. Donc euh oui, c'est une technique sympa. Donc ça fait partie de ce que je fais. Donc, en rétrospective, il me reste deux minutes. Je vais en fait être pile à l'heure. Hmm ? Pardon ?
[00:59:49] Deux grandes minutes. Qu'est-ce que ça veut dire ? Ils ont genre 60 grandes secondes, je suppose, non ? Donc. Donc, en rétrospective, c'est juste un bref récapitulatif, n'est-ce pas ? Donc encore une fois, je vais reporter, parce que beaucoup de gens ne réalisent probablement pas qu'ils se trouvent dans des zones complexes et chaotiques. Et si vous l'êtes ou si vous vous considérez comme étant ici, cela signifie que vous devez agir différemment, n'est-ce pas ? Il n'y a plus de planification ou de travail linéaire, ni même de cycles comme dans les cycles de Scrum. Je ne ferais pas ça si j'étais dans cette situation. Donc, vous devez comprendre où vous vous situez étant donné le contexte dans lequel vous vous trouvez. Et cela signifie différents types de comportement. Dans la plupart des cas, cela signifie une rénovation continue, n'est-ce pas ? Cela signifie que vous devez maintenir la boutique ouverte. Vous devez continuer à dépenser de l'énergie dans les systèmes existants et aussi pour les personnes qui les utilisent, car elles nécessitent également de l'attention, en plus de l'innovation. Que vous ne pouvez pas simplement innover et que vous ne pouvez pas simplement maintenir. Dans les deux situations, vous êtes condamné. Donc vous devez mélanger et assortir, n'est-ce pas ? Et puis vous pouvez commencer à dire, vous savez quoi, nous allons construire des choses plus petites, n'est-ce pas ? Arrêtez de faire des projets, même de construire des produits, ne sortez pas un seul produit chaque année, sortez-en de petites étapes. Bien sûr, il y a un truc initial comme un MVP, n'est-ce pas ? Mais c'est euh de plus petites fonctionnalités. Passez à des cycles encore plus courts, supprimez les cycles. Eh bien, en gros, supprimer les cycles reste un cycle, n'est-ce pas ? Parce que, eh bien, si vous livrez 40 fois par jour en production, c'est toujours un cycle. C'est juste court, c'est comme cinq minutes. Ou si vous croyez Jeff Sutherland qui dit que 80% de votre code peut être généré, alors c'est même une minute. Pas sûr qu'il faille le croire, n'est-ce pas ? Donc bref. Et vous pouvez faire cela avec différentes configurations d'équipe. Trouvez la configuration d'équipe qui vous convient. Alors laissez-le simplement évoluer vers quelque chose qui fonctionne vraiment. N'essayez pas de forcer les gens à faire ce que vous voulez en disant : « Non, il faut faire ça. Il doit y avoir une rétrospective. » Et si je ne me présente pas à la rétrospective ? Nous expérimentons actuellement de ne pas faire de stand-ups. Nous les retirons du jour où nous sommes au bureau, qui est le jeudi. Nous ne faisons plus de stand-ups lorsque nous sommes au bureau car nous nous parlons toute la journée de toute façon. Et nous allons probablement les supprimer pour les autres jours aussi. On verra si ça passe, mais c'est une expérience, n'est-ce pas ? Et les expériences, eh bien, on ne sait jamais si elles fonctionnent. Et la dernière chose, c'est que vous le faites en plus petits composants. Donc, si vous faites tout ça, il n'y a qu'une seule conclusion. Moins, c'est plus. C'est vraiment, vraiment le cas. Et je ne dis pas moins le cadre agile évolutif, n'est-ce pas ? Donc. Euh nous avons commencé à résoudre un problème par jour. Euh aussi, la prochaine chose dans cette industrie, parce que ça change tout le temps, c'est que vous ne pouvez jamais, jamais arrêter d'apprendre des choses. Et euh probablement le meilleur de tous, eh bien, nous sommes dans la meilleure industrie. J'adore cette industrie. Mon fils m'a demandé un jour : et si tu n'étais pas développeur de logiciels, que ferais-tu ? Et j'ai dit, eh bien, j'apprendrais à programmer tout de suite. Et c'est en gros ça. Alors merci de m'avoir invité. J'espère que ce furent les deux grandes minutes. Et euh j'espère que vous apprécierez la journée. Je serai là pour des discussions et euh n'hésitez pas à me critiquer si vous n'aimez pas ce que je dis. Et parce que j'aime la critique. Euh euh non.
[01:02:50] Merci.

Transcription (Traduit)