Samuel Retiere, Bruno Boucard et Philippe Serignac
Transcription
en un jour. Donc on va vous présenter d'abord le contexte qui nous concerne.
Samuel insistera un petit peu plus rapidement sur le modèle qui nous sert à accompagner les équipes, c'est-à-dire comment on accompagne, quels sont les leviers qu'on peut avoir avec eux. Et ensuite, la transformation elle-même, comment on la fait, et là on passera un petit peu plus de temps. Alors notre situation, ça fait plusieurs années qu'on succède des transformations, on est parti sur des fondamentaux lean qui ont permis aux gens de s'approprier un peu plus le respect for people et l'amélioration continue. Une fois qu'on a eu ça, il y a eu des phénomènes agiles qui sont apparus. Des promoteurs à l'intérieur de nos équipes qui ont poussé ces événements-là et ça a transformé ça en projet et ça s'est gangréné de manière positive de telle sorte qu'aujourd'hui on a énormément de gens qui ont fait de l'agile et qui ont voulu aller plus loin et aujourd'hui on est passé dans un mode plus global de délivrer de la valeur à nos clients, parce qu'on ne les oublie pas, via le contenu des livres.
Je passe la main à Samuel pour le modèle.
Donc là, une petite pyramide, c'est le modèle de maturité. En gros, on est où? On a l'investissement de la Société Générale pour faire bouger une structure comme la nôtre. On ne peut pas juste se permettre de dire, ok, on va peut-être par là. Nous, il nous faut un modèle pour dire, voilà ce qu'on va faire, voilà où on va aller. Donc là, il y a une super pyramide. Bon, alors là, le premier niveau, Business Value, c'est en gros, si on reprend le slide qui était avant, c'est la partie agilité. Pour nous, c'est l'agilité, First Star, Agile Basics, on est capable de collaborer avec notre client. On l'a appelé Business Value parce que c'est un peu plus joli que Agile First Star. Deuxième niveau, stable value, il en a un peu parlé Philippe, on ne veut pas faire les cow-boys. Donc avant d'être rapide, on veut être stable. Donc là on va bosser beaucoup sur la stabilité de la connaissance, stabilité du software, stabilité de la preuve. Après le niveau d'après, qu'on a appelé best value, donc le rythme, au début c'était un fast value, mais ce qu'on dit c'est que ce n'est pas nécessaire de livrer vite si on n'en a pas besoin. Donc on va livrer au rythme nécessaire pour notre client. Après le niveau d'appel, le niveau 4, c'est au cas, niveau 3 je suis capable de le faire sur une appli, niveau 4 je le fais sur une chaîne d'application qui s'applique sur un process. Quand on crée un nouveau produit chez nous, il y a à peu près 15 applications à impacter, donc en gros on voudra arriver au niveau 4. Et après le dernier, parce qu'on est mieux les échelles à 5 niveaux, c'est l'entreprise agile. Bon, essayez pas de me demander ce que c'est après, je sais pas bien, mais c'est le niveau rêvé.
Donc là, tous les trois, ce qu'on vient de faire, c'est qu'on vient de faire des transformations au début de l'année, pour faire passer des applications au niveau 3. Donc en gros, on arrive à livrer rapidement. On n'en est pas livré tous les jours, mais on pourrait presque, si on avait envie, les appliquer à livrer plutôt deux fois par semaine. Donc là, c'est le niveau où on est actuellement, et pour passer au niveau 4, qu'est-ce qu'il faut faire? Il faut juste transformer beaucoup d'applications, et après on y arrivera naturellement. Niveau 5, c'est pas pour tout de suite, quand on aura fini cette transformation-là, ce sera un nouvel objectif sûrement.
Donc sur quoi on bosse? Pourquoi on est trois sur scène? Donc là je vais reprendre les impacts attendus par Carl Scotland, on a de la chance qu'il est à la conférence. Value, donc là c'est mettre les bonnes choses dans les tuyaux. Donc ça c'est principalement moi qui bosse sur ces trucs là, on peut aussi l'appeler 12h writing. En gros je mets à l'intérieur de mon système des choses qui servent à quelque chose. Comme je dis souvent, 2 fois 0, ça fait toujours 0. Si je produis 2 fois plus vite, ou des choses qui servent à rien, c'est toujours 0. L'autre axe sur lequel on bosse, donc là je l'appelle Flow, toujours en respect avec Arles-Cotland, donc là c'est faire les bonnes choses. En gros ça nous est arrivé de bosser sur des transformations, côté humain c'était super, tout se passait bien, mais derrière côté technique ça ne suivait pas du tout, il fallait pour tester prendre un dump de prod, le copier, faire tourner pendant 3 jours et attendre de voir ce qui se passe. Donc là, on n'a pas du tout un flux. Donc bosser que sur la partie organisationnelle humaine, ça n'a pas de sens. Il faut aussi bosser sur la partie technique.
Après, dernier axe, value c'est mettre les bonnes choses dans les tuyaux, flow c'est faire les choses bien, et potential, donc c'est human potential, c'est l'amélioration, qui est très ancrée à l'intérieur de Kanban. Donc là on bosse sur ces trois axes-là, et quand on intervient maintenant dans les transformations, on intervient à trois, parce qu'on bosse un peu chacun sur notre domaine.
Et le retour d'expérience qu'on a, c'est que c'est vraiment ça qui a différencié. Actuellement, vraiment, on intervient sur tout, et on arrive à faire bouger les choses. Parce que faire bouger que la technique, on a des limites. Faire bouger que l'organisationnel, on a des limites. Et s'il n'y a pas d'amélioration, on a aussi des limites. Donc là, on l'a vraiment vu dans les transformations qu'on a faites, le fait d'intervenir à trois, c'est vraiment ça le critère différenciant actuellement.
Sur la présentation après, on ne va pas vous présenter ce qu'on a fait dans le passé, parce que si je vous présente ça, c'est déjà quelque chose qui a pu être joué. Du coup on a appris, là on est en train de retransformer des équipes, on a adapté notre pattern de transformation, et là ce qu'on va plutôt vous présenter c'est qu'est-ce qu'on fait actuellement, on reprend une équipe qui est au niveau 0, elle nous a demandé d'amener au niveau 3, voilà sur quel thème on va travailler. Donc voilà, ce qu'on vous présente c'est le pattern actuel, qui dans 6 mois ne sera sûrement pas le pattern qu'on utilisera, c'est ce qu'on fait actuellement, et ça vous donne des possibilités d'amélioration.
Voilà, c'est pour moi le début. Business Dev Collaboration, on va dire que c'est assez proche du manifeste agile. Je veux collaborer avec mon business et je ne veux pas contractualiser. Donc là, c'est quoi? C'est former le métier, leur apprendre ce que c'est l'agilité. J'appelle ça un peu Agile Basics. Donc ça, c'est la collaboration, business, développement et contractualisation. Deuxième max sur lequel je bosse, avant ça c'était plutôt au niveau 2, quand on mettait le slicing. Parce qu'au niveau 1, on se concentrait sur le fait de dire, ok, moi ce que je veux c'est que l'équipe de dev soit concentrée sur, je délivre de la valeur pour mon client, donc je veux voir, dans tout ce que fait l'équipe de dev, je veux voir des choses de métier, des besoins de métier, je ne veux pas voir des tâches de métier. Donc là c'était un peu, je ne veux pas voir un hamburger avec un découpage technique, je veux voir un découpage en tranches par rapport à ce qu'apporte de la valeur. Donc là, à partir du moment où on avait de la valeur, moi ça, entre guillemets, de la valeur, enfin, c'était pas vraiment de la valeur, c'était plutôt justement du comportement, de la fonctionnalité métier, de savoir à quoi ça servait, est-ce que c'était bien orienté dans le process métier, il n'y avait pas. Donc là, Slicing the Business Lead, comment je le fais? On fait des exercices des cathares, on leur donne des caravanes, on leur demande de découper des projets en fonction 1, ce qu'apporte de la valeur, et 2, ensuite, la partie comportementale, comportemental, je parle de l'appli. Et quelle connaissance je veux avoir? Donc là, on va parler de MVP, Minimum Valuable Product. Donc là, maintenant, on insiste énormément sur la partie valeur, et énormément sur un slicing et un rentier process métier. Et pourquoi on fait ça? Si on ne fait pas ça, une fois qu'on va vouloir...
On va parler Bruno après, on ne va pas être capable de le faire. Donc là maintenant, on passe beaucoup plus de temps qu'avant sur la partie slicing, et pour nous c'est la clé de tout. Si c'est bien découpé, et ils sont plus petits, le flux est mieux. Donc ça c'est quelque chose qu'on faisait voir de manière aussi importante, sur lequel on a insisté maintenant.
Donc la première chose qu'on va pouvoir faire aussi, c'est d'essayer de ne pas travailler en mode batch. Pas de l'eau, les lots ça signifie des retards éventuels. Ce qu'on veut, c'est qu'on l'a dit pas mal de fois dans cette conférence, c'est d'être dans un mode flux. Donc des métiers qui durent trop longtemps, des choses qui sont trop gros dans le baglog, tout ça, on essaye de l'éliminer de manière à ce que le développement soit beaucoup plus fluidifié.
Un élément essentiel, et qui me touche personnellement, c'est d'enseigner aux développeurs le design émergent. C'est-à-dire que quand on arrive dans une équipe, bien souvent, les gens n'ont pas cette connaissance de fabriquer du code en mode design émergent, et c'est quelque chose qui... Est essentiel à nos yeux puisque ça leur permet effectivement d'avoir des tests en premier et puis de faire leur code en même temps. Pour arriver à ça, on leur donne des exercices, des katas de création de code qu'on appelle Greenfield. Ils le font pendant plusieurs mois. En général, ça dure trois mois. À partir de là, ils sont...
En parallèle, on leur apprend à refactorer leur code, mais sur le plan du design, des responsabilités. C'est-à-dire que souvent, le code n'a pas un bon découpage, une bonne répartition des responsabilités. On va trouver une classe avec trop de responsabilités et une autre classe avec pas assez. Donc on essaye d'enseigner aux développeurs de bien répartir les responsabilités pour que les classes aient une seule responsabilité en général et que finalement, il soit plus facilement maintenable et qu'il y ait moins de conséquences quand on fait des nouveaux développements.
Alors, une fois qu'on a fait ça, c'est bien, mais il ne faut pas oublier les hommes dans l'histoire. Et on sait que malheureusement, beaucoup de transformations échouent, et quand elles échouent, quand je dis beaucoup, statistiquement c'est autour de 70%, elles échouent majoritairement à cause de l'humain, justement. Soit les managers qui ne sont pas dans le bon comportement, ou qui n'ont pas compris certaines choses, soit même les personnes elles-mêmes, le staff. Donc ce qu'on fait, c'est qu'on va s'attacher à cet aspect humain pour que tout le reste fonctionne. Donc au tout début, on va s'attirer du personal safety. Alors pourquoi on a mis un fouet? C'est parce qu'on s'attache à ce que les managers et même n'importe qui puissent faire du feedback, mais du vrai feedback, pas du recadrage. Donc si quelqu'un a quelque chose à dire, s'il y a quelqu'un d'autre par rapport à n'importe quel événement, il faut qu'il se sente à l'aise pour remonter de l'information qui va permettre d'améliorer la structure. Et une fois que le manager lui-même a cette posture, il va même carrément demander du feedback. Donc on voit des managers qui demandent du feedback à leur N-1 et qui demandent à recevoir du feedback de leur N-1 ou même... jusqu'à certaines couches managériales, N plus 2 et N plus 3. Une fois que ce feedback est en place, que ça devient un peu naturel chez les personnes, on a pas mal entendu parler par Octo par exemple, le personnel safety permet également de recueillir des problèmes. Les personnes sont plus à l'aise pour remonter des problèmes, et les problèmes dans la ligne, c'est la source de l'amélioration continue. Donc les personnes sont à l'aise. pour remonter les problèmes, et on va les aider, nous, via des ateliers, à les traiter. Donc des ateliers, ce qu'on appelle des problem solving sessions, mais il existe beaucoup de types d'ateliers de ce style, sur lesquels nous on les aide à animer, on leur donne des pratiques pour s'améliorer à traiter des problèmes un peu plus complexes. Et l'autre point classique, c'est la rétrospective. Donc ceux qui ne sont pas agiles n'ont pas l'habitude, mais ceux qui sont agiles ont l'habitude, donc vont utiliser les rétrospectives pour aller capter ces problèmes et trouver de l'amélioration.
Enfin, l'autre cas qui est important au niveau des personnes, c'est qu'on a parlé du business tout à l'heure. Des fois, dans notre organisation, ils sont éloignés des développeurs, éloignés du support, tous ces gens-là sont éloignés. Donc finalement, ils ne se connaissent pas si bien que ça. Et donc, notre objectif, c'est de les rassembler. Et quand on sent qu'il y a des tensions entre certaines personnes ou certains métiers, On les rapproche et on utilise un jeu tel que le Given Tech Matrix, où chacun va exprimer ses attentes vis-à-vis des autres, il va également exprimer ce que lui, il estime être son job, et des fois il y a des petites découvertes, des gens qui découvrent vraiment le métier de l'autre, ils n'imaginaient pas ça, et ensemble ils vont fabriquer une équipe, ensemble, une future team, qui va leur permettre de bien se comprendre et de bien fonctionner. Et on n'est pas obligé d'avoir la même organisation à droite et à gauche. Alors une fois qu'on a tout ça, on a fait le flow, on a fait la partie technique, on a fait la partie humaine, on matérialise ça par une petite étoile, une grande étoile, Et cette étoile, on la délivre, on revient à une forme de first star, on remet aux équipes, et ça leur montre qu'ils ont les basiques maintenant, et qu'ils peuvent aller vers l'étape suivante, le niveau 2.
Niveau 2, sur la partie valeur. Niveau 1, au début, on se concentre un peu, c'est ce que je disais, sur le what. C'est en gros, est-ce que l'équipe de développement comprend quel est le comportement attendu de l'applicatif? La question d'après, c'est est-ce qu'ils comprennent ce que l'utilisateur va en faire une fois qu'il est en production? En gros, le why versus le what. Donc là, j'insiste vraiment sur le fait à quoi ça va servir. Typiquement, c'est quand les métiers donnent des solutions, le demander, enfin, donner des besoins. C'est OK, ils donnent une solution, mais à quoi ça va servir? Donc vraiment dire, ok, tu as le droit de challenger le métier, si tu ne comprends pas à quoi ça va servir, ce qui va en faire, fais-le. Donc là, c'est beaucoup de mindset. Je vais en prendre. Après, un truc intéressant, on va parler de la partie produit. Essayer de casser, d'y requérir un project manager qui se concentre sur les indicateurs verts, on time, on budget, et tout le team, ça ne m'intéresse pas. Ce qui m'intéresse, c'est est-ce qu'on délivre de la valeur pour mon client. Essayer de penser produit. Je délivre un produit pour quelqu'un. Donc là, j'utilise deux katas. Dans des exercices basés, le premier sur un bouquin qui s'appelle« Dealing with Daring» qui parle de marketing, de stratégie d'innovation, quelles sont les innovations possibles. Et après, je parle aussi un peu de l'Instartup et du Linkenba. Et là, ce qui est assez sympa, c'est qu'on engage le débat de qu'est-ce que c'est un bon indicateur. Mais je ne l'aborde pas par... la partie performance managérienne, je m'aborde par la partie innovation. Donc là, vous comprendrez un peu pourquoi j'en parle. Mais en gros, là, je parle de la partie innovation, pourquoi vous faites les choses, et dire, ok, pensez à ce que vous faites, essayez de déterminer à l'avance pourquoi vous faites les choses. Dernier point, sur la partie valeur, pourquoi je l'aime au niveau 2, pourquoi je ne l'aime pas au niveau 1? Pour arriver au niveau 2, là j'arrive sur des no estimate, tout ce qui va avec. En gros, c'est de dire, à partir du moment où on s'est découpé de manière fine, que le découpage fonctionnel il est bien, quand j'arrive tout en bas, je me retrouve avec, je prends une équipe qu'on a accompagnée, ils n'ont que des user stories, à la fin, qui font entre 2 et 4 jours. Là, je me pose la question, à quoi ça sert d'estimer? Et à quoi ça sert de s'embêter dans le forecasting, à prendre des poids pour dire j'ai tel user story qui est de poids S, de poids M, de poids L? À la fin, à partir du moment où le découpage est bien fait, là j'arrive juste à cette notion de début, de débit pur et simple, de dire ok, je suis capable de faire 10 demandes par, je sais quoi, par semaine, par deux semaines. Mais en gros, à partir du moment où le slicing est bien fait avant, la partie forecasting devient super simple, et là on peut commencer à faire un peu de stats à la sauce Kanban. Je précise juste un truc parce que quand on le répète au French Cog où on a parlé, Nous, notre focus, il est à fond sur le time to market. ��tre capable de livrer vite. Et il n'est pas nécessairement sur qu'est-ce que je vais livrer dans 6 mois, qu'est-ce que je vais livrer dans 3 mois. Donc là, nous, là-dessus, on insiste un peu moins, c'est pour ça que c'est au niveau 2. Nous, ce qui nous intéresse, c'est je veux livrer en temps le plus vite possible, je veux que mon produit en production évolue le plus vite possible. Il y a un métier qui dit, et j'aime bien ce qu'il dit, c'est... nouvelles fonctionnalités en prod égale nouveaux besoins. Ça ne sert à rien de se projeter à 3 mois, 6 mois, par rapport au retour que je vais avoir sur la production, je vais avoir des nouvelles demandes. Donc ne t'embête pas à me dire tout ce que tu vas faire, dis-moi par contre quelle est ta capacité, quel est ton débit. Donc c'est pour ça que ça arrive au niveau 2.
Super simple. Et là, on peut commencer à faire un peu de stats à la sauce Canban. Je précise juste un truc parce que quand on le répète au French Club, on en a parlé. Nous, notre focus, il est à fond sur le time to market. ��tre capable de livrer vite. Et il n'est pas nécessairement sur qu'est-ce que je vais livrer dans 6 mois, qu'est-ce que je vais livrer dans 3 mois. Donc là, nous, là-dessus, on insiste un peu moins, c'est pour ça que c'est au niveau 2. Nous, ce qui nous intéresse, c'est je veux livrer en prod le plus vite possible, je veux que mon produit en production évolue le plus vite possible. Il y a un métier qui dit, et j'aime bien ce qu'il dit, c'est nouvelle fonctionnalité en prod égale nouveau besoin. Ça ne sert à rien de se projeter à 3 mois, 6 mois, par rapport au retour que je vais avoir sur la production, je vais avoir des nouvelles demandes. Donc ne t'embête pas à me dire tout ce que tu vas faire, dis-moi par contre quelle est ta capacité, quel est ton débit. Donc c'est pour ça que ça arrive au niveau 2.
Donc ensuite, au niveau 2, on s'intéresse à concilier plusieurs acteurs. C'est là qu'intervient la notion de DevOps. On ne va pas forcément mettre en place de l'outillage DevOps. Par contre, on va essayer de constituer une relation entre les gens qui s'occupent de l'infrastructure, les gens qui s'occupent de la partie flow et les gens qui s'occupent de la partie technique, développement. Le but, bien évidemment, c'est de mieux comprendre comment on délivre des back-edges efficients avec moins de couplage, de mieux comprendre l'infrastructure sur laquelle on déploie l'appli, de manière à mieux maîtriser les impacts à chaque fois qu'on réalise.
Un autre élément essentiel, c'est la culture du BDD. On initie les gens au BDD de manière à ce que toutes les nouvelles demandes soient faites avec les billets, les développeurs et les QA s'ils sont présents, de manière à produire des scénarios qui comprennent la pensée de ces trois personnes. Ça, c'est essentiel. Bien évidemment, sur du legacy, on ne va pas forcément jusqu'à de l'automatisation, mais par contre, si c'est du greenfield, on va jusqu'à l'automatisation. Pour ce faire, on a une journée complète de training pour initier les biais et les développeurs à faire du BDD. S'il y a des QA, ils participent aussi. Et ensuite, ils ont des katas pendant plusieurs mois pour être efficients, pour faire du BDD.
On a parlé du factoring dans la première étoile, celui-ci est un factoring plus hardcore, c'est-à-dire celui qui correspond finalement à un logiciel un petit peu ancien, où le test n'est vraiment pas présent, et le taux de couplage entre les entités est très élevé. Ce type de logiciel fait que souvent le développeur abandonne. Il dit non, je ne pourrais pas mettre de test sur ce type de code. Justement, on leur explique avec une série de techniques comment, sur un code intestable, mettre des tests malgré tout. C'est la première pierre avant de reprendre la main en TDD sur ce code-là. Et là aussi, il y a une journée de formation et il y a aussi un training de plusieurs semaines pour que les développeurs soient à l'aise pour faire du refactoring difficile sur du code legacy.
Alors sur la partie potential, on a maintenant des basiques qui sont assez importants au niveau humain sur les personnes. Elles sont prêtes à accepter des problèmes. Là, on parle de performance review maintenant avec les managers, avec les équipes. Performance au sens comment on a performé. Donc, non pas le mauvais terme performance en français qui veut dire un peu marche ou crêle, non. On est vraiment sur comment on a réussi à arriver, qu'est-ce qu'on a eu qui ne se passe pas bien, etc. Et au-delà de ça, aujourd'hui, dans les organisations telles que la nôtre, on a beaucoup d'indicateurs pour savoir où est-ce qu'on en est. Mais des indicateurs où souvent les managers n'aiment pas trop qu'ils soient rouges. Voire ils n'aiment pas du tout. Et donc ça stimule plus les personnes en général à masquer et à essayer de remonter du capillailler vert parce qu'on a un peu peur. Quand on arrive à ce niveau-là avec des équipes qui commencent à être dans la bienveillance, remonter un capillailler rouge, au contraire, c'est une bonne chose parce que ça leur permet justement de corriger le tir. Et donc on fait des ateliers avec les équipes, avec les personnes, avec les managers, pour essayer de définir les meilleurs indicateurs pour eux, qui contribuent bien évidemment aux objectifs de l'entité, à l'organisation, mais qui va leur permettre à eux de corriger le tir le plus vite possible.
Ensuite, évidemment, comme l'objectif c'est de stabiliser tout ce qu'on a appris avant, les personnes, on va les stimuler pour partager leurs connaissances. Partager, l'un des moyens qu'on utilise au niveau des développeurs, au niveau des billets, etc., c'est le pair working. Donc quelqu'un qui arrive... n'a pas forcément tous ses accès, n'a pas forcément tout ce qui va bien pour travailler, mais ce n'est pas grave, on va le faire travailler avec quelqu'un d'autre. Donc à deux, ça va permettre d'emborder la personne. Mais au-delà de ça, même quelqu'un qui est installé depuis longtemps, le fait de travailler avec quelqu'un d'autre va lui permettre d'avoir un œil nouveau et d'aller plus facilement à l'essentiel. Également, sur la partie documentation, du coup, plutôt que de faire des gros pavés, ils vont s'atteler à l'essentiel et vont construire des documentations vivantes. Qui vont être challengés en permanence sur leur utilité présente. Grâce à ça, ils arrivent à mieux travailler sur leur stabilité.
Et enfin, on va parler de fertilisation, parce que là on parle beaucoup des développeurs, des billets, etc. Mais on travaille aussi au niveau managérial. Et les pratiques des managers, souvent, viennent du terrain. Ils ne sont pas forcément des managers dans l'âme au départ. Ils y viennent par leurs compétences. Et pour autant, ils ont envie de savoir bien manager. Ils ont des cas concrets, des problèmes, de la même façon que les développeurs. Donc on les réunit dans ce qu'on appelle des ateliers de co-développement. C'est un terme un peu pompeux peut-être, mais en fait, ils viennent ensemble pour apporter une issue, qu'ils ont un petit problème, et les autres, leurs pairs, vont les aider à travailler dessus. Et donc chacun va repartir avec des options dont il se sert ou pas. Et ça permet justement de faire tiser dans le sens où, dans une grande organisation, on ne connaît pas tout le monde, mais pourtant tout le monde a souvent les mêmes problèmes. Et ce fait de se croiser des gens qu'on connaît moins bien, mais qui sont du même niveau hiérarchique et qui ont les mêmes problèmes, ça permet d'apprendre plus vite. Et en même temps, dans notre organisation, on organise des foires. Ces foires permettent typiquement à des personnes de venir exposer ce qu'ils font et donc du coup aux autres de venir se renseigner et ça permet typiquement à quelqu'un qui n'était pas agile de se dire tiens moi ça m'intéresse et je voudrais y aller.
Donc une fois qu'on a fait tout ça, ces personnes-là sont éligibles et on leur donne le diplôme de la deuxième étoile.
Niveau 3, donc là, juste pour dire les applications qui sont à ce niveau-là, actuellement on en a, je crois que le chiffre non officiel c'est 5. Donc là, ça commence à devenir un peu plus piquant, ça commence à devenir un peu plus compliqué. Donc là tout le monde a reconnu le Black Swan, et ceux qui ont vraiment reconnu ne sont pas là parce qu'ils sont dans la salle de Joshua Arnold en train de faire le cost of the day chez Maersk. Donc là en gros c'est quoi? C'est essayer de bosser un, donc on a essayé une initiative qui s'appelle Agile Portfolio de découper tous les projets, de ne plus avoir de portefeuille de projet, mais portefeuille un peu de produit, et avec des lots maximum 3 ou 4 mois, pour info ça ça a foiré, on va dire ça comme ça, ça c'était une initiative qui venait du management tout en haut. Là maintenant on est plutôt dans des initiatives qui partent du bas, avec l'utilisation du cost of delay par le bas, essayer de bosser donc un peu d'une start-up, d'une calva, tous ces trucs là, mais c'est vraiment, j'arrête de faire des gros projets, je bosse sur des enveloppes budgétaires, je maximise la valeur, et j'essaie de ne plus faire de projet. En gros, on part produit, on part l'enveloppe budgétaire, et après, on se démerde, on maximise la valeur. On essaie quand même d'en monter au niveau métier aussi, au niveau stratégie. Pourquoi vous prenez une décision, pourquoi on fait ça? Et d'essayer de faire que vraiment, côté métier, il y a des meilleures discussions. Donc là, on a beaucoup de discussions côté métier. Voilà, actuellement, je me retrouve à coacher du métier, pour les aider à bosser et essayer de faire les bonnes choses. Après, dans le Dax One, on arrive à faire des choses, mais c'est quand même compliqué, je ne vais pas dire la contraire. La partie d'en bas, par contre, ça marche super bien. Face feedback group. Qu'est-ce que c'est ? On a peut-être entendu parler d'automatisme chic-bat. Maintenant, ce qu'on fait, quand le métier exprime un besoin, il doit exprimer le why, et maintenant, il doit aussi donner quel est l'indicateur métier qui va lui permettre de valider que ce qu'il a demandé, c'est bien ou pas bien. En gros, là, je veux un indicateur, typiquement, si on fait ça, qui va se passer pour toi, pour tes business. Et donc là, qu'est-ce qu'on fait après? Avec un outil de monitoring, on implémente la sonde à l'intérieur de l'applicatif. Et une fois qu'on est en prod, on va voir le métier en disant« Ok, tu pensais gagner, je sais pas, 15% de connexion supplémentaire. T'en es qu'à 10, t'en es qu'à 5, t'en es à 20. » Donc là, on est en train de lui dire« Ok, c'est quoi l'indicateur? » Et qu'est-ce qu'on va calculer un peu derrière, qui commence à venir et qui t'accueille un peu le métier? C'est le pourcentage de demandes métiers qui ont atteint la cible. Ok, tu m'as demandé ça, et tu t'attendais à ça. Ok, donc combien de pourcentages de fois tu touches vraiment la cible? C'est-à-dire, est-ce que tu exprimes des besoins qui servent à quelque chose? Le but, c'est que le produit évolue plus vite. Donc ça, c'est vraiment cette partie-là qui marche le mieux. Ça nous permet de valider que les demandes métiers, elles ont atteint la cible. Donc ça permet aussi au métier d'améliorer ses demandes. Donc ça, c'est une partie qui marche très bien. Outil de monitoring qu'il faut mettre derrière, un petit mode V3, quelque chose comme ça.
Donc au niveau 3, c'est le moment où on va s'intéresser à accélérer le bout en bout, c'est-à-dire qu'on va faire de la phrase code, qui peut être,
on va donc initier dans les équipes cette partie de customisation qui va permettre d'avoir des scripts qui permettent d'automatiser le plus rapidement possible, comme un pouce bouton, et c'est le cas. Donc ça c'est réellement quelque chose qui nous permet d'atteindre effectivement du continuous delivery au niveau d'un projet.
L'infrastructure à ce col, je vais en parler, mais les deux sujets sont liés. C'est-à-dire que là, c'était le déploiement. On peut le faire aussi avec un outil qui s'appelle...
J'ai perdu le nom. Déploy. Mais on pourrait le faire aussi avec un autre outil, bien évidemment.
Le but, c'est d'avoir l'automatisation scriptée et pas une intervention humaine.
La partie infrastructure as code est réellement quelque chose qu'on démarre en ce moment.
Il y a eu aujourd'hui une initiative qui a été portée en termes de stratégie et on va dire qu'il y a quelques projets qui bénéficient finalement de codes complètement automatisés.
Le dernier point est quelque chose qui est à l'étude, qui n'est pas opérationnel. c'est d'offrir aux équipes la capacité d'organiser leurs projets en mode DDD,
C'est quelque chose qui nous paraît complètement éligible pour des gens qui ont déjà une belle organisation, dont le code est relativement bien testé, avec un plutôt bon design. À ce moment-là, effectivement, on envisage de leur donner quelques assets du framework de D.
Alors, sur la partie humaine, finalement, on se retrouve avec très peu de monde, comme l'a dit Samuel et comme l'a dit Bruno également. On est vraiment là aujourd'hui dans l'émergence, on essaye des choses. Et il y a deux thèmes qu'on essaye aujourd'hui, c'est à la fois le decentralized decision et le host leadership. Et là, on travaille au niveau des couches managériales vraiment le plus haut possible. Pourquoi? Parce qu'aujourd'hui, les décisions qui sont prises dans l'entreprise ou dans les organisations, elles sont des fois un peu aberrantes et certains s'en rendent compte. Donc on fait un atelier. Alors là, il est tout simple. En fait, on passe une vidéo sur le Turn the Ship Around. Donc c'est un livre. Il y a eu une petite vidéo ludique de 15 minutes qui explique ce livre. Et à partir de là, on fait discuter les personnes, les managers de tout niveau sur leurs besoins finalement en termes de décision. Est-ce qu'ils pensent que les décisions qui sont prises à leur niveau sont les bonnes? Et les managers également font ce retour par rapport à ça. Il y a une discussion qui s'enclenche et on essaie de les mettre dans le mouvement pour voir qu'est-ce qui pourrait changer dans leur organisation, qu'est-ce qui manquerait. Et donc souvent on voit apparaître des discussions sur la communication finalement, parce que cette décision pour être prise a besoin d'informations, de communication. Et donc ça fait réfléchir tous ces managers sur leur façon de fonctionner en termes de communication dans leur organisation. dans leur propre organisation et avec leur père dans les autres organisations. In fine, on a très peu de gens qui ont avancé sur ce sujet-là, mais on sent qu'il y a de la pétance. Parce qu'à chaque fois qu'on en parle, il y a quelqu'un qui est volontaire pour initier ça dans son board, avec son voisin, etc. Et en même temps, l'os leadership, donc là c'est de la même façon qu'on attend d'un scrum master qui déblaye le terrain pour son équipe de développement et permettre finalement qu'il y ait de la valeur qui soit livrée le plus vite possible à son client. Là on demande au manager d'avoir cette même posture vis-à-vis de l'ensemble de ses staffs. Donc ça peut être assez vaste. Et on a vu quelques managers finalement changer la manière dont ils organisent leur tonneau pour essayer justement d'être un peu plus dans un mode participatif et dire que ce n'est pas mon événement, mais finalement c'est un événement pour le staff. Et donc changer leurs approches et non plus faire simplement un grand discours qui dure une heure et demie, je vous prêche la bonne parole, mais venez également apporter votre pierre à l'édifice. Donc aujourd'hui c'est très peu présent, comme les deux autres thèmes, on est vraiment dans l'émergence, mais on a bon espoir, et on en a quand même quelques-uns qui sont arrivés et qui ont eu droit à une petite remise de troisième étoile. Et on ne désespère pas d'en avoir beaucoup plus d'ici les six prochains mois.
Juste avant de prendre les questions pour info, les slides sont sur Slideshare, il y a le détail. Là, on n'a pas mis le détail derrière chaque item, mais sur les slides que j'ai mis sur Slideshare, il y a le détail. Bon, j'ai regardé mon Mac, je n'ai vu aucune question sur Twitter.