Stéphane Lichtenberger& Samuel Chapal - LeSS chez Esker

[00:00:06] Bon, et ben, bonjour à tous. Euh, on va se tenir bien chaud pendant cette conférence.
[00:00:12] Euh, donc nous on va vous présenter un retour d'expérience de Less chez Esker. Donc Less c'est quoi ? C'est Large Scale Scrum.
[00:00:23] Euh, et Esker, c'est le nom de de l'entreprise dans l'on dans laquelle on travaille, Samuel et moi.
[00:00:31] Et merci d'être venu nombreux.
[00:00:34] et nombreuse. On se présente ?
[00:00:35] Oui.
[00:00:36] Allez. Euh, donc, comme, comme vous l'a dit Stéphane, moi je on travaille chez Esker, je suis Samuel Chappal. Je suis Scrum Master dans une dans l'équipe SRE d'Esker.
[00:00:48] Et euh, et pour ma part, je suis chez Esker depuis 2 ans et demi à peu près.
[00:00:52] Voilà, et moi je suis Stéphane Lichtenberger. Euh, je travaille chez Esker depuis plus de 20 ans. Donc quand je suis arrivé chez Esker, on était euh c'est assez inhabituel, on était 30 et maintenant on est 1000. C'est pour vous donner une idée aussi du scaling chez Esker.
[00:01:10] Bah, si vous avez des questions sur l'historique, ce sera pour pour Stéphane.
[00:01:13] Voilà. Alors qu'est-ce qu'on fait chez Esker ? Euh, on fait une solution qui automatise euh les tâches répétitives ou à faible valeur ajoutée de la finance, euh des achats et du service client. Donc c'est tout ça c'est fait sur une plateforme SAS. Euh, et donc ce que vous voyez sur le schéma, alors c'est le slide marketing. Vous voyez deux cycles, euh du côté gauche, le cycle source to pay, c'est-à-dire depuis c'est le cycle fournisseur, depuis euh la recherche des fournisseurs, la gestion des contrats avec les fournisseurs, les achats, la comptabilité fournisseur, les frais. Et côté gauche, le cycle order to cash, euh donc plutôt le cycle client, depuis la réception d'une commande, la gestion des demandes client, la facturation, les réclamations et la réconciliation, les paiements et la réconciliation des paiements.
[00:02:07] J'ai rien compris, c'est beaucoup trop compliqué, tu vas devoir l'expliquer de façon plus basique.
[00:02:09] Alors j'ai fait un slide pour les stagiaires de troisième qui viennent faire des stages chez nous.
[00:02:16] C'est moi.
[00:02:22] Alors voilà, nous on travaille dans le monde du B2B, donc c'est les entreprises qui font du business avec des entreprises. Évidemment, c'est un peu différent du B2C où bah vous allez dans un magasin, vous achetez un produit, vous le payez et vous repartez avec. Les entreprises ont trouvé un moyen beaucoup plus sophistiqué de faire du business ensemble avec un flux de documents euh très compliqué. Donc qui peut démarrer par une RFQ Request for quotation, c'est-à-dire une demande de devis. Euh, le fournisseur va répondre par un devis, ensuite le client va envoyer une commande. Euh, qui va être confirmée par une confirmation de commande, un avis de livraison. Puis ensuite, euh on va envoyer une facture, potentiellement le client peut faire une réclamation. Et ensuite, on va recevoir un avis de paiement et une notification de paiement de la banque. Donc notre produit, il fait euh il traite tout ce ce flux de documents, donc il y a beaucoup de dématérialisation. Et aussi les processus qui sont associés à chacun de ces documents, euh soit du côté gauche, soit du côté droit. Donc par exemple pour une commande, et ben il va y avoir tout un processus d'achat côté client. Et côté fournisseur, pour une commande, et ben on va vérifier euh les stocks, la disponibilité des produits, les prix et cetera quoi.
[00:03:44] Bref, c'est simple.
[00:03:45] Ouais. C'est beaucoup plus simple.
[00:03:50] OK. Euh, et donc pour faire tout ça et gérer ces processus relativement complexes, vous avez compris, on peut vous donner quelques quelques chiffres pour pour ça vous vous situer d'où on parle. Donc euh, en particulier donc, on on fait partie de la R&D chez Esker.
[00:04:05] Euh, donc Esker c'est vaste, on ne parle que pour la partie recherche et développement. Euh, c'est à peu près 2 c'est plus de 200 personnes à la R&D qui sont essentiellement toutes situées en France à Lyon. Euh, on a aussi quelques membres de la R&D qui sont euh aux US et en Asie, mais pour l'essentiel, on est en France. Euh, et on est constitué en équipe Scrum et on a environ 30 équipes Scrum. On vous on vous évitera les les détails de de toute la décomposition de toutes les équipes. Euh, mais c'est pour vous donner une ordre d'idée de taille, c'est euh voilà, c'est 30 équipes Scrum la R&D Esker environ actuellement. Et ça fait quelques temps que ça dure euh cette affaire. Donc comme je vous ai dit, moi je suis plus récent dans dans l'histoire, mais euh on en est à euh plus de 325 sprints, c'est-à-dire que ça fait euh
[00:04:54] ça fait depuis 2012 qu'on itère et qu'on fait des sprints avec ces équipes Scrum. Alors évidemment, le nombre actuel d'équipes Scrum, il était plus petit il y a 12 ans.
[00:05:04] Oui, alors il y a 12 ans, on a commencé avec quatre équipes Scrum. Et on a eu une formatrice euh à qui on a dit "Mais Scrum c'est fait pour une équipe de 5 à 9 et nous on est déjà à quatre équipes à travailler sur le même logiciel, comment on fait ?" Et elle nous a dit "Ça n'a pas d'importance, Scrum, ça suffit." Et euh avec le recul, c'était pas un si mauvais conseil. Euh c'est-à-dire qu'on a essayé de s'en tenir à ça et après le scaling, ça a été des pratiques émergentes des équipes Scrum. Et petit à petit, on s'est reconnu dans le framework Less, mais sans forcément euh partir en Less dès le départ. Au départ, on a simplement essayé d'appliquer Scrum euh by the book.
[00:05:50] Euh alors on fait environ 100 fonctionnalités par sprint qui sont mises en production, donc toutes les deux semaines. Nos clients peuvent hériter d'une centaine de fonctionnalités qui peuvent être activées ou pas. Elles sont pas forcément toutes activées à un instant T. On a 3000 clients, 1,25 millions d'utilisateurs et 95 millions de transactions.
[00:06:09] Donc quand on parle de transactions, bah ça peut être des factures, des commandes, des avis de livraisons, des avis de paiement. Euh, c'est des documents, ça peut être des PDF, des documents Word.
[00:06:19] Toutes toutes les flèches du schéma pour le stagiaire de troisième, il faut que tu leur expliques le schéma juste avant.
[00:06:25] Voilà.
[00:06:28] Alors nous on s'est présenté, mais euh on a besoin de savoir un peu aussi quel est votre votre positionnement. Euh, alors qui dans la salle pratique ou a pratiqué Scrum déjà ? Si vous si vous êtes, vous vous reconnaissez là-dedans, levez la main s'il vous plaît. Waouh, c'est l'unanimité. C'est super, parce qu'on s'est dit "Il faut qu'on parte sur le principe que les gens connaissent Scrum parce que sinon on va pas ré-expliquer Scrum." Merci. Si jamais vous êtes perdu dans euh vous pouvez demander à votre voisin, forcément, votre voisin ou votre voisine a fait du Scrum apparemment.
[00:07:00] Voilà, ici connaît Less ou a déjà pratiqué Less ?
[00:07:05] OK, donc c'est moi. Joli. Et un autre framework, est-ce qu'il y a des personnes qui auraient pratiqué un autre framework d'agilité à l'échelle ?
[00:07:15] OK, donc il y a il y a des récidivistes des multi-framework.
[00:07:21] OK, super. Alors ce qu'on a décidé pour cette présentation, c'est euh donc on vous dit c'est un retour d'expérience. Euh, pour ça on va suivre euh comme ligne de guide les principes Less. Donc Less définit un certain nombre de principes euh qui nous encourage à utiliser. Et euh on s'est dit que c'était une bonne occasion en fait de vous concrétiser certains de ces principes en vous illustrant comment nous on les vit chez Esker. Et donc on va suivre ce cet élément-là comme comme fil rouge. Alors si tu fais un petit clic, voilà, hop. Euh ceci dit, on va pas vous présenter, on va pas rentrer dans le détail sur tous les principes de Less parce que sinon, bah, on en aurait pour toute l'après-midi, euh, voire plus. Euh, on a décidé de zoomer sur certains. Donc en particulier, on va parler de de un principe qui est, donc Less, Large Scale Scrum is Scrum. Et euh, et donc on reviendra un peu sur euh en quoi ça ça ressemble beaucoup à Scrum. Euh, ce qui fait que vous retrouvez aussi d'autres principes comme la transparence, le contrôle empirique de process qui sont très très liés à Scrum, enfin je veux dire ils font intégralement partie de euh de de ce qu'est Scrum.
[00:08:31] Donc on se concentrera sur celui-ci, mais vous pouvez si enfin vu que vous connaissez presque tous Scrum, vous pouvez euh euh imaginer de quoi on parle quand on parle de transparence de dans de process empiriques. On parlera de More with Less, de focus sur l'intégralité du produit. Euh, et il y a certains parties sur lesquelles on passera, euh être centré client, c'est un principe de Less. Euh, l'amélioration continue jusqu'à la perfection qui concerne à la fois l'organisation et le produit. Euh, bon, on fera pas un focus sur l'amélioration continue aujourd'hui, ce sera ce sera peut-être pour l'année prochaine, on verra. Euh, on va pas vous parler de Lean thinking, mais on est à Flowcon, donc c'est possible que vous ayez quelques idées de ce que c'est que le le Lean thinking. Évidemment, il faudrait une conférence entière rien que là-dessus, et il y en aura sur les deux jours.
[00:09:23] Dans Less, on retrouve aussi le principe de euh de la pensée systémique. Euh, de réfléchir euh les problématiques sous leur aspect systémique, on a vu une conférence par exemple ce matin qui qui traitait de ça dans le domaine de du SRE. Euh, et cetera. Euh, et donc on se concentrera pour cette présentation sur Large Scale Scrum is Scrum, Whole Product Focus, More with Less et euh Queuing Theory parce qu'on s'est dit qu'il fallait qu'on parle un petit peu quand même de file d'attente à Flowcon.
[00:09:56] Et donc pour commencer, on va vous parler de bah Large Scale Scrum, c'est Scrum. Alors c'est Scrum, mais c'est c'est Scrum un peu différent puisque c'est une approche de Scrum à l'échelle.
[00:10:07] Et euh tel que ce principe est décrit dans la documentation Less, euh la phrase qu'on a retenu pour le définir, c'est Less c'est euh c'est du Scrum à plusieurs équipes.
[00:10:20] C'est pas une collection de plusieurs équipes Scrum. Euh, que veut dire ce principe par là, c'est que vraiment le principe ça n'est de de Less, ça n'est pas de créer un framework qui serait construit autour d'équipes Scrum.
[00:10:35] Et qui rajouterait un ensemble de principes et de pratiques autour du fait qu'il y a des équipes Scrum. Je sais pas si vous connaissez des frameworks de ce style. Ça peut exister, euh imaginez voilà de d'avoir plus j'ai des équipes Scrum et en plus je rajoute des rôles, des pratiques et cetera qui font que je passe à l'échelle.
[00:10:54] Il y a il y a des propositions comme ça qui existent. Voilà, mais donc ce qu'on le vraiment ce que veut Less, c'est dire on garde les principes et pratiques de Scrum et on est capable de les appliquer à l'échelle, presque en ajoutant rien. Alors, on va peut-être concrétiser ça un peu mieux.
[00:11:13] Euh, et donc là, c'est vraiment le le schéma Less qui vous résume le fonctionnement de Less dans lequel effectivement, assez facilement, vous allez vous retrouver vos billes par rapport aux pratiques et aux rôles que vous avez dans Scrum.
[00:11:28] Alors si j'essaie de vous le résumer et en particulier de faire le focus sur ce qui peut être enfin sur ce qui est différenciant avec Less, bah la base déjà évidemment, c'est que Less ça se pratique à plusieurs équipes Scrum. Donc là on retrouve chaque ligne quelque part est une équipe Scrum différente, OK ? Et euh et donc ce qui nous permet de passer à l'échelle, c'est qu'on a plusieurs équipes qui travaillent ensemble et qui travaillent ensemble sur le même produit. On y reviendra un peu plus tard.
[00:11:56] Euh, et en terme de donc en terme de rôle, on retrouve exactement les mêmes rôles que dans Scrum et pas de rôle en plus. C'est-à-dire qu'on a euh des membres d'équipe euh de Dev, euh des Scrum Master et un Product Owner. Et quelque part, il y a un principe de base dans Less qui est que donc ces plusieurs équipes vont être il n'y aura qu'un seul Product Owner qui va euh être rattaché à ces différentes équipes. En terme de taille euh pour Less, euh une organisation Less, c'est entre 3 et 8 équipes maximum Scrum, OK ? Qui vont avoir donc les tailles d'équipe sont celles définies par Scrum et euh qui vont avoir un ou plusieurs Scrum Master, ça c'est on a un peu la latitude de déterminer le nombre de Scrum Master qu'on dont on estime avoir besoin euh pour bien faire tourner les équipes. Par contre, effectivement, elles partageront le même backlog et le même Product Owner et elles travaillent sur le même produit. OK ?
[00:12:58] En terme de déroulement, bah vous vous retrouvez au début de au début du sprint euh vraiment les mêmes choses qu'en qu'en Scrum. Donc on fonctionne par sprint, chez nous les sprints sont d'une durée de 2 semaines. Euh, qui est la même pour toutes les équipes. Et euh et on démarre un sprint par un sprint planning. Et ce sprint planning est fait en deux parties. La première partie, sprint planning partie 1. C'est plutôt un une étape où le Product Owner va présenter les objectifs du sprint et où les différentes équipes vont se répartir ce qu'il y a à faire, vont se répartir les éléments du backlog entre elles. Bon, on a pris l'habitude de dire les stories et de d'utiliser cet abru de langage chez nous. Donc le Product Owner arrive avec une série de stories et euh et elle se dispatche entre les équipes et c'est le résultat d'une discussion. Et dans la partie sprint planning 2. Là, c'est chaque équipe qui fait cette partie-là euh à part et qui va travailler sur les éléments qu'elle a sélectionné. Donc vous vous voyez dans ce schéma que le planning 1 est commun à toutes les équipes et le planning 2, en fait, est un rendez-vous de chaque équipe séparée. Et avec ça, on démarre notre sprint.
[00:14:07] Voilà, donc à peu près au milieu, il y a un événement qui s'appelle le Product Backlog Refinement, le PBR, qui est plus important en Less euh qu'en Scrum. On y passe, alors en théorie, c'est une journée pour un sprint de 2 semaines, euh dans mon équipe, par exemple, on y passe une demi-journée. Euh, c'est un événement important inter-équipes. Alors vous voyez là les événements inter-équipes, il y a le sprint planning euh part 1, mais le part 2 est par équipe. Et après à la fin, on a une rétrospective de sprint qui est commune aux trois équipes, c'est pour ça qu'il n'y a pas de petite barre noire sur la couche sprint review. Après, il y a une rétrospective par équipe, donc chaque équipe fait sa rétro comme dans Scrum. Et il y a un seul événement ajouté dans le framework Less par rapport à Scrum, c'est l'overall rétrospective. C'est la seule réunion supplémentaire qui est faite par rapport à Scrum, et elle dure une heure chez nous. Et alors ce qui est important, c'est qu'à la fin, il y a qu'un seul cadeau, il y a un potentially shippable increment, donc toutes les équipes travaillent sur le même cadeau qui est livré en production toutes les deux semaines.
[00:15:19] Voilà, donc ça scale alors en théorie jusqu'à 8. Dans mon dans mon équipe, moi je suis Product Owner d'une organisation Less de trois équipes. Euh, mais comme on vous l'a dit au départ, on est 30 équipes euh chez Esker.
[00:15:36] Alors nous, ce que ça nous a apporté, bah, c'est que c'est les mêmes rôles. On n'a pas ajouté de rôle. C'est-à-dire que chez nous, il y a pas euh de d'architecte, de lead développeur, de UX designer. Il y a qu'un seul rôle, c'est team member euh pour les équipes, PO et des Scrum Master. On a rien rien ajouté.
[00:15:55] Et puis ça nous a permis de conserver notre cadence de livraison. Donc on livre vraiment toutes les deux semaines en production sans ajouter de de complexité.
[00:16:07] Et ensuite pour passer à 30 équipes, il y a une deuxième version de Less qui s'appelle Less Huge. Alors, retenez bien le schéma, il y aura des questions à la fin. Non, alors c'est assez simple, en fait, là ce qu'on voit sur le schéma, c'est trois organisations Less accolées euh avec de multiples équipes. Et euh ça s'appelle Less Huge, ça permet de scaler jusqu'à, je sais plus combien, très beaucoup, en théorie beaucoup. En tout cas, nous ça monte jusqu'à 30 équipes. Et alors dans ce cas-là, il y a des Product Owners par organisation Less, qui s'appelle Area Product Owner, c'est ce que vous voyez sur la gauche, APO, c'est Area Product Owner. Euh, en théorie, il y a un super PO euh qui connaît tout et qui est capable de tout prioriser, le monde entier.
[00:17:00] Et à la fin, alors la différence aussi, c'est qu'on voit il y a pas de synchronisation entre les organisations Less, il y a des synchros entre les équipes au sein d'une organisation Less, mais pas entre les organisations. La synchro, elle est faite par une vue sur le backlog des Area Product Owner. Donc chaque Area Product Owner priorise et discute avec son équipe. Et puis à la fin, la différence c'est qu'il y a quand même toujours un seul cadeau pour 30 équipes, il y a un seul incrément, tout est mis en production en même temps.
[00:17:36] OK. Alors donc, voilà, euh merci d'être resté avec nous pour suite à ce court théorique sur Less. Euh, évidemment, on vous a promis un retour d'expérience, donc euh la question un peu qui se pose, c'est enfin qu'on qu'on vous a qu'on va un peu creuser ensemble, c'est concrètement qu'est-ce qu'on fait chez nous. C'est-à-dire que là on vous a présenté la théorie Less, on vous a dit on applique Less, ben vous allez voir qu'il y a des petites nuances dans ce qu'on fait. Euh, et si on prend un pas de recul, en fait, la question qui se pose quand on euh quand on veut euh passer à l'échelle en Scrum, c'est que pour moi, il y a vraiment plusieurs alternatives possibles.
[00:18:12] Il y a une alternative qui ressemble à ce qu'on vient de vous présenter avec Less Huge, c'est de dire j'ai mon produit qui est énorme, mon produit il grossit. parce que il grossit, il j'ai plus d'utilisateurs, j'ai plus de fonctionnalités, euh malheureusement j'ai énormément de succès, je fais rentrer euh des sous et euh il y a toujours des demandes et de l'attente. Et donc mon produit est appelé à grossir, et donc je suis euh enfin je je suis naturellement amené à juste ajouter le nombre d'équipes qui travaillent sur mon produit. Donc c'est une stratégie de scaling, c'est-à-dire plus gros produit, je dois être capable de faire travailler plus d'équipes sur un seul produit.
[00:18:43] On est tout là-bas.
[00:18:46] Et puis il y aurait une autre utopie agile qui serait de dire bah en fait ce qui est super dans Scrum, c'est l'autonomie des équipes, donc il faut vraiment qu'on leur garde de l'autonomie. Donc on va plutôt avoir des petits produits. Donc au lieu de de viser un très gros produit euh qui ne fait que grossir, bah je le découpe en plus petits produits et je suis capable à chaque fois d'avoir une équipe Scrum pour chaque produit et de répartir en fait la charge de travail de cette façon, c'est-à-dire plus je scale, plus je je fais popper de nouveaux produits et des équipes dédiées à ça. Et donc avec un système très réparti.
[00:19:19] Et alors euh l'énigme pour cette présentation, c'est que nous on est quelque part entre les deux et euh vous allez devoir deviner où est-ce qu'on est. Et si vous avez faux, bah vous aurez pas la fin de la présentation.
[00:19:30] Il y aura la réponse quand même.
[00:19:31] Non, il y aura la réponse.
[00:19:35] Et donc avant que vous ayez la réponse, on va parler un peu de euh d'un deuxième principe qui est Whole Product Focus.
[00:19:00] qui ne fait que grossir, ben je le découpe en plus petits produits, et je suis capable à chaque fois d'avoir une équipe Scrum pour chaque produit et de répartir en fait la charge de travail de cette façon, c'est-à-dire, plus je scale, plus je je fais popper de nouveaux produits et des équipes dédiées à ça. Et donc avec un système très réparti.
[00:19:18] Et alors l'énigme pour cette présentation, c'est que nous on est quelque part entre les deux et euh vous allez devoir deviner où est-ce qu'on est et si vous avez faux, bah vous aurez pas la fin de la présentation. Voilà.
[00:19:30] Il y aura la réponse quand même.
[00:19:31] Non, il y aura la réponse.
[00:19:35] Et donc avant que vous ayez la réponse, on va parler un peu de euh d'un deuxième principe qui est 'Hall Product Focus'.
[00:19:46] Alors voilà, quand on scale, euh ce qu'on essaie de faire, c'est de quand on scale avec le Less, c'est de garder euh le focus sur l'ensemble du produit et pas sur un composant ou une sous-partie. Mais la définition, en fait, de produit, elle peut aussi varier dans le temps.
[00:20:01] Donc euh si je prends mon smartphone par exemple, peut-être que il y a une dizaine d'années ou plus, il y avait une compétition au nombre de de pixels par photo, et c'était de plus en plus gros et cetera. Euh c'était assez indépendant de la résolution des écrans. Euh si on veut une bonne expérience utilisateur, sachant qu'aujourd'hui la plupart des photos, 99% sont regardées sur le smartphone qui les a prises, euh il faut que les deux soient alignés. Donc ça peut être défini comme des produits différents parce que c'est tellement compliqué qu'il faut découper, mais on pourrait aussi considérer que c'est qu'un seul produit et c'est c'est ce que le client achète finalement qui compte. Donc c'est là-dessus finalement qu'on va se focaliser.
[00:20:47] Alors c'est quoi le produit chez Sker?
[00:20:49] Ouais. Parce que là c'était c'était la partie compliquée.
[00:20:54] Euh donc j'en ai un peu parlé au début. En résumé, on a deux suites de solutions, une suite pour le cycle Source to Pay, le cycle pour la gestion des fournisseurs, et une suite de solutions Order to Cash pour la gestion du cycle client.
[00:21:13] Donc ça aurait pu euh ça aurait pu être un découpage produit.
[00:21:17] En fait, ça fait euh... ça c'est notre gros produit S4 on demand avec deux parties et donc finalement il suffit de il suffit qu'on mette plein d'équipes sur ce produit là et on scale. C'est c'est ça qu'on a fait en fait.
[00:21:31] Alors oui, ça aurait pu être une possibilité mais c'est pas ce qu'on a fait.
[00:21:34] Euh parce que nos clients, alors ils achètent rarement l'ensemble de la suite, c'est-à-dire à la fois Source to Pay et Order to Cash, et même ils achètent pas souvent l'ensemble de Source to Pay, l'ensemble de Order to Cash, mais au fur et à mesure qu'on scale chez Sker, on vend à des comptes de plus en plus gros euh qui pourraient acheter l'ensemble de la suite, mais on n'a pas pas décidé d'être 30 équipes sur l'ensemble de la suite parce que c'est quand même assez compliqué si vous voyez le slide suivant, en fait, il y a 13 applications dans ces suites de produits. Donc les applications, c'est ce que vous voyez là, on appelle ça une fleur chez nous, et chaque pétale, c'est une application. Et c'est ça que les clients achètent. Donc par exemple, ils peuvent acheter euh la gestion des commandes clients. C'est le module qui s'appelle Order Management. Et d'ailleurs, quand on a commencé avec quatre équipes, euh on vendait quatre de de ces pétales.
[00:22:29] Okay. Et ben donc c'est c'est ce que je disais là de on est peut-être plutôt de ce côté, c'est-à-dire que on a réussi à découper notre produit en petit pétale et cetera. Et puis on a distribué des pétales à nos équipes et euh et on a grossi comme ça. En fait, c'est euh c'est élégant, je trouve, comme comme façon de faire.
[00:22:44] Pas tout à fait, Samuel.
[00:22:47] OK.
[00:22:47] Nos clients effectivement, ils achètent quand ils achètent la gestion des commandes clients, euh c'est les services clients qui achètent ce module, mais ils peuvent en acheter plusieurs. Et alors souvent ce qui se passe, c'est que les services clients, ils achètent les trois modules du service client. Donc là ici, on a la gestion des demandes clients, c'est-à-dire la gestion de la mailbox du service client, la gestion des commandes clients et la gestion des réclamations, c'est des modules qui vont ensemble. Mais ils peuvent aussi acheter quatre autres pétales euh qui serait le cycle Invoice to Cash. C'est-à-dire depuis la facturation jusqu'à la jusqu'au paiement.
[00:23:21] Euh ça c'est des modules qui vont être plutôt traités par la comptabilité euh par la comptabilité fournisseur, euh par la comptabilité client, pardon. Et ils peuvent acheter en fait n'importe quel de ces modules pas forcément toute la suite euh indépendamment.
[00:23:41] Et donc c'est pourquoi finalement euh on a fini par découper le monde en trois, un petit peu par persona ou par euh département chez nos clients. Euh pour refléter finalement les acheteurs chez nos clients et les utilisateurs chez nos clients. Donc le cycle Source to Pay, c'est la gestion des achats, Customer Service, le service client et Accounts Receivable depuis la facturation jusqu'au paiement. Et finalement, ça fait des suites de solutions qui sont un peu intermédiaires entre on vend tout et on vend que une solution parmi les 13.
[00:24:20] Et alors vous voyez bien qu'en plus c'est assez compliqué d'être expert dans toutes les solutions, parce qu'il y a 13 applications.
[00:24:29] Et donc la réponse à la question était à peu près par là, voilà, c'est à peu près par là qu'on se situe. C'est-à-dire que c'est vrai qu'on est euh on est organisé d'une façon qui est euh on a plutôt en fait un ensemble de gros produits avec une série d'équipes euh qui travaillent dessus. On n'est pas dans le modèle que des petites équipes autonomes, mais en même temps, on n'a pas non plus choisi un modèle où absolument tout le monde à la R&D peut travailler sur absolument n'importe quel des 13 pétales qu'on vous a présenté du produit parce que ça nécessite en fait des connaissances, ne serait-ce que des connaissances métier et de contexte lié à ça. Et donc on a euh on a cherché en fait un compromis. Euh et donc ce compromis, on va vous le montrer tout de suite.
[00:25:17] Donc voilà, la R&D SKR, ça ressemble à ça. Chacune des grandes briques que vous voyez là, en fait, c'est une organisation Less, donc c'est un ensemble d'équipes qui fonctionne sur le mode Less. mais avec des scopes différents et on n'est pas non plus complètement organisé dans un mode Less Huge, c'est-à-dire dans lequel toutes ces équipes interagiraient à chaque sprint, même si forcément, il y a du il y a du travail ensemble. Mais on a plutôt un découpage autour des grandes suites, donc euh qu'on vous a dit Source to Pay euh Accounts Receivable, Customer Service. Et on a aussi des équipes qui sont plus sur la partie plateforme euh que vous voyez en bas et qui vont avoir un rôle plus transverse euh sur tout ce qui est euh la partie traitement de données qui est une qui est un élément très important chez nous et qui est utilisé en fait par toutes les couches qui sont au-dessus. sur la partie euh tout ce qui est framework web, sécurité et cetera où là aussi on a des équipes euh qui s'occupent de cette partie-là et qui à la fois développent des fonctionnalités et assure un suivi de du framework qui est utilisé par les autres équipes. Et puis mes petits chouchous parce que bah c'est c'est mon équipe en fait, il y a une équipe SRE qui assure les opérations et donc le suivi de la plateforme et de l'infrastructure. Euh donc c'est ce découpage là que vous retrouvez où vous voyez aussi que selon les euh périmètres, on peut retrouver entre à aujourd'hui, parce que ça bouge tout le temps, mais entre deux et cinq équipes pour chacun des groupes Less d'équipes.
[00:26:51] Et pour complexifier un peu le travail de Samuel ou des équipes framework, on a aussi des équipes Bizdev qui font des solutions dont j'ai absolument pas parlé sur ce sur ce framework ou des partenaires qui développent des solutions sur ce framework. Qui ne sont pas dans les pétales qu'on vous a Qui ne sont pas dans les pétales qu'on a montré.
[00:27:12] Donc juste en synthèse sur cette partie-là, si vous voulez, de façon assez euh organique et empirique, on a petit à petit fait un découpage qui est celui-là aujourd'hui, qui peut évoluer dans le temps dans le futur, et qui n'est pas tout à fait celui de Less Huge, même si en fait on en reprend quand même des principes. Et ce qui est important aussi, c'est que les équipes métier, donc par exemple moi mon équipe, c'est Customer Service, euh peut intervenir partout dans le framework, c'est-à-dire qu'on peut enrichir le framework, ça servira à d'autres équipes. Il n'y a pas de limite entre les équipes métier et framework.
[00:27:47] OK.
[00:27:50] Alors, on va poursuivre sur euh un un autre principe qui fait on va faire plus un zoom sur du coup quel est le fonctionnement de chacun de ces groupes Less indépendamment. Et on va parler de théorie des files d'attente et euh donc je pars du principe que on est à Flocon, vous devez savoir de quoi on parle, euh avec vraiment le principe que une file d'attente, il faut à la fois euh l'optimiser, faire en sorte que notre délai de réponse à euh aux attentes soit le plus rapide possible. Et aussi qu'on va essayer d'éviter de créer des files d'attente inutiles. Euh or si on veut optimiser une file d'attente et avoir un délai de réponse rapide, ce qu'il faut qu'on fasse, c'est d'éliminer les les goulots d'étranglement. Alors, on a une difficulté par rapport à ça, c'est que dans le Less, il y a un goulot d'étranglement qui est hardcodé dans le framework, et le goulot d'étranglement, euh c'est c'est toi, Stéphane. C'est moi.
[00:28:47] Donc oui, comme vous avez vu dans l'organisation Less, quand on rajoute une équipe, on rajoute pas un PO. Euh et moi j'étais déjà bien occupé avec une équipe. Euh j'avais du travail pour tous les jours quoi. Euh donc prioriser des stories pour deux équipes, c'est plus de stories et cetera. Donc comment on fait euh pour scaler le PO? Alors maintenant, il y a l'intelligence artificielle. Mais euh à l'époque il y avait pas, donc il y avait une solution, c'est le burnout. Mais j'ai préféré passer cette option.
[00:29:18] Et sinon il y a le Product Backlog Refinement qui est un événement très important dans le Less. Euh parce que c'est le moment où on va raffiner les stories, les répartir entre équipes, euh les découper. Et en fait, la solution c'est que les équipes deviennent plus plus autonomes sur le fonctionnel. C'est pour ça que dans nos découpages produits, on a vraiment fait un découpage fonctionnel. Donc mon équipe, il travaille au jour le jour, enfin l'organisation Less travaille pour le service client euh donc ils connaissent très bien le fonctionnel des équipes clients. L'équipe qui travaille sur Invoice to Cash, va connaître très bien le fonctionnel de la comptabilité ou de la finance. Euh et ça leur permet en fait de raffiner les stories, de les découper, de proposer des stories. Euh on discute de tout ça pendant le product backlog refinement. Donc les équipes peuvent créer des stories.
[00:30:09] Simplement, on les revoit ensemble au PBR. Euh c'est ce qui permet finalement de scaler le PO. C'est de déléguer de plus en plus de tâches. Euh la définition des stories, l'UX, les aspects sécurité, tout ça, c'est des critères qui sont écrits par les équipes.
[00:30:24] Comment ça se passe chez vous un PBR, peut-être tu peux?
[00:30:26] Oui, alors j'ai pris en en photo, c'est notre notre tableau blanc. Donc on se regroupe, c'est en présentiel, une fois toutes les deux semaines, c'est le jeudi avant le démarrage du prochain sprint. Donc on a mis ça c'est trois jours à l'avant la fin du sprint parce que comme ça ça reste dans les mémoires pour le planning suivant. Et on se réunit en présentiel, donc c'est des délégués de chaque équipe qui viennent au bureau. Alors c'est chez nous c'est en présentiel, mais c'est pas le cas dans toutes les équipes. Mais on a essayé d'appliquer le Less vraiment by the book. Et euh, ça se passe comme ça, vous avez le timing, il y a 30 minutes où je vais présenter les stories qui peuvent être grosses ou petites. Euh je vais parler du du but du du sprint suivant. Ensuite, il y a 45 minutes où les équipes vont se décomposer en binôme ou en trinôme sur plein de tableaux. Donc on a un mur qui est probablement même plus grand que ça avec des tableaux.
[00:31:25] On fait des équipes mixtes, c'est ce que vous voyez en bas, c'est-à-dire que les les trois équipes Scrum essaient de se mélanger pour la définition des stories. On parle du fonctionnel dans le dans le backlog refinement et ils essaient de raffiner les stories. Euh dans cet événement, on essaie d'identifier les dépendances inter-équipes ou les compétences qui seraient éventuellement dans une des autres équipes Less ou même ailleurs chez SRE ou dans des équipes framework.
[00:31:54] Et le but de tout ça, c'est aussi de ressortir avec une une estimation un peu gut feeling. La story elle est S, M ou L, c'est des tailles de t-shirt. On va pas trop rediscuter si elle est S, M ou L. Euh par contre, si elle est XL, ça veut dire elle tient pas dans le sprint. Et dans ce cas-là, ce qu'on essaie de faire, c'est simplement c'est quoi le le first step? C'est quoi le premier pas qu'on peut faire pour attaquer cette story qui est trop grosse et donc personne sait quoi faire parce que elle est trop grosse en fait. Donc au lieu de se dire on va étudier la story et faire un grand story mapping de tout ce qu'il y a à faire, on va juste identifier un premier pas. Et on essaie de faire ce premier pas. Et on verra au sprint suivant.
[00:32:38] Et donc pour l'anecdote, ben dans mon équipe qui a des contraintes assez différentes, SRE, on a une partie de l'équipe qui est aux États-Unis, et ben on le fait sur plusieurs jours, en asynchrone, en distantiel. Voilà, c'est deux façons différentes de faire le le PBR. Et on a on a vraiment cette latitude que chaque équipe organise ses rendez-vous comme elle le comme elle le souhaite. Oui, il y a d'autres équipes qui font par exemple la première partie euh au cours d'une journée, le PO présente les stories. Après il y a une journée où les devs travaillent de leur côté, et le lendemain, ils se réunissent pour euh pour la deuxième partie. Enfin, il y a plusieurs, il faut s'adapter quoi. Il n'y a pas de recette.
[00:33:15] Et puis oui, on a on a des scripts qui prennent des notes de tout ce qui a été dit euh dans le PBR, euh pour ceux qui étaient pas là.
[00:33:27] Alors dans cet objectif de d'affinage par équipe et plus globalement dans le travail en Less, il y a toujours un un challenge qu'on a euh avec les les membres des équipes. Vous savez que Scrum c'est les équipes polyvalentes, j'ai toutes les compétences qu'il faut pour euh euh pour réaliser toutes les les stories, tous les éléments du backlog euh au sein d'une seule équipe. Alors ça c'est un idéal. Quand on passe à l'échelle, comme vous voyez, le périmètre de des équipes ne fait que augmenter, le périmètre fonctionnel, le périmètre technique, et euh et donc ce challenge d'être polyvalent et de savoir tout couvrir, il est d'autant plus difficile à relever. Et donc c'est vraiment cette ce dilemme entre polyvalence et spécialisation qu'on avec lequel on a toujours à négocier. C'est-à-dire que notre but, c'est qu'il y ait de la polyvalence qui permette pratiquement que chaque équipe qui quelque part n'importe quelle équipe qui est disponible puisse prendre un élément du backlog et dire je vais travailler dessus et on va sortir de la valeur et en même temps, on sait bien qu'il y a des des éléments sur lesquels on va avoir besoin d'expertise et on va avoir oui des files d'attente, des goulots d'étranglement. Parce que dans telle équipe, il y a l'expertise pointue sur ce sujet-là dont on ne peut pas se passer pour. Donc notre but, c'est toujours de d'améliorer le transfert de connaissance au sein de l'équipe et de prendre le temps de d'aider les gens à monter en compétence. Mais en même temps, il n'y a pas de formule magique quoi, c'est c'est c'est pas miraculeux, on ne peut pas avoir tout le temps les compétences nécessaires pour n'importe quelle nouvelle chose qu'on a à traiter dans le backlog et on compose avec quoi.
[00:35:04] Il se passe pas une semaine dans mon équipe sans qu'on me parle de spécialisation.
[00:35:11] Et le dernier, je pensais le dernier, ouais, le dernier principe dont on va vous parler, c'est euh More With Less. Alors, qu'est-ce que c'est More With Less? Et ben c'est probablement que euh je te donne moins de moyens, mais je te demande d'en faire plus. Non, c'est pas ça. Euh, donc, on vous a parlé vraiment de la manière dont euh le Less permet de partir de quelques équipes Scrum et scaler et accompagner cette cette croissance. Euh, il y a aussi vraiment ce principe de dire, on n'a pas besoin de beaucoup plus de rôles et de process pour euh traiter tous les problèmes auxquels on fait face. Et donc vraiment l'approche de Less c'est dire ne rajoutez pas de complexité à votre organisation pour résoudre les problèmes, basez-vous plutôt sur la délégation, l'autonomie en fait dans les équipes et vous allez voir que ça va se résoudre tout seul un peu comme tu disais tout à l'heure, en fait juste du Scrum et vous allez voir ça ira ça ira bien.
[00:36:05] Faut avoir la foi quand même on essaie de l'avoir.
[00:36:11] Un et donc ça on peut le le voir par exemple au niveau des rôles, ouais, qu'on qu'on a chez nous.
[00:36:17] Oui, donc les rôles chez nous euh bah c'est ceux qui sont affichés, les trois du bas, vous les connaissez, les product owner, les Scrum Master et les équipes. Euh associé au rôle de Product Owner, on a un product manager qui est plutôt côté marketing. Donc moi j'ai un collègue product manager qui travaille sur le marketing, les ventes, les price list, euh tout ce qui est commercial. Et on travaille beaucoup en binôme, moi je suis plutôt côté de la R&D. Euh quand il y a des événements clients, on y va ensemble. C'est-à-dire que on on essaie de parler au client, la théorie de Scrum c'était 50% du temps, le PO doit parler au client et 50% il doit s'occuper de l'équipe. Euh on essaie de faire ça.
[00:37:01] Et puis on a un VP of R&D qui joue un peu le rôle de Super PO. Alors non, il priorise pas son story comme le dit la théorie de de Less Huge. Euh c'est vraiment les PO qui priorisent les stories. De temps en temps, il va faire de gros arbitrages sur sur des modules par exemple s'il y a un produit dont le backlog est plein et un autre produit où ça va, les clients sont servis, le flux est est continue, il va peut-être arbitrer sur des grosses fonctionnalités. Parce qu'il y a des fonctionnalités qui sont communes à tous tous nos produits, euh bah par exemple la gestion des utilisateurs. Euh que n'importe quelle équipe peut faire et qui des fois sont tellement grosses que ça noierait le backlog d'un produit et qui serait pas possible à faire. Donc la plupart du temps, ça va dans des équipes plateformes, mais les équipes plateformes aussi peuvent être surchargées, donc ça peut être une feature team qui prend le sujet. Alors ça arrive pas souvent, mais de temps en temps ça arrive et en général, c'est quand même en lien avec le le produit. C'est-à-dire que c'est pas une feature euh une fonctionnalité, pardon, euh qui est complètement alienne au produit sur lequel on travaille. Par exemple en customer service, on va pas travailler sur des fonctionnalités qui sont vraiment comptabilité ou finances.
[00:38:20] Donc il va il va être là simplement pour faire des des gros arbitrages.
[00:37:41] que n'importe quelle équipe peut faire, et qui des fois sont tellement grosses que ça noierait le backlog d'un produit et qui serait pas possible à faire. Donc la plupart du temps, ça va dans des équipes plateformes, mais les équipes plateformes aussi peuvent être surchargées, donc ça peut être une feature team qui prend le sujet. Alors ça arrive pas souvent, mais de temps en temps ça arrive et en général, c'est quand même en lien avec le le produit, c'est-à-dire que c'est pas une feature une fonctionnalité pardon, euh qui est complètement alien au produit sur lequel on travaille. Par exemple, en customer service, on va pas travailler sur des fonctionnalités qui sont vraiment en comptabilité ou finance.
[00:38:21] Donc il va il va être là simplement pour faire des des gros arbitrages.
[00:38:27] OK, et donc comme je vous disais, pour arriver à en faire plus avec moins de process, moins de rôle ou en tout cas pas trop en plus. Euh ce sur quoi on se repose, c'est vraiment l'auto-organisation. Alors l'auto-organisation euh ou les équipes euh auto managées, c'est quelque chose que vous retrouvez dans Scrum et c'est euh c'est de garder ce principe là euh
[00:38:47] tout en passant à l'échelle, c'est-à-dire encore une fois oui de pas rajouter de complexité à notre organisation malgré le fait qu'on est deux ans maintenant. Alors je peux donner quelques exemples. Hop, si tu reviens.
[00:38:59] Vous vous êtes fait spoiler la suite. Euh, seuh, seuh. Donc des exemples assez simples hein. Euh donc moi je vous disais ça fait que des équipes avec quand même pas mal d'autonomie, j'ai pu en voir dans mon parcours euh euh à plusieurs endroits. Je pense qu'à je pense j'ai jamais rencontré des équipes qui avaient le niveau d'autonomie euh des équipes d'Esker en particulier sur des entreprises de cette taille-là. Euh un exemple, c'est la le recrutement dans dans mon équipe, quand on recrute une nouvelle personne, en fait notre process, c'est on va avoir un certain nombre de personnes de l'équipe, de membres de l'équipe qui vont être volontaire pour euh euh faire les entretiens, on va avoir euh deux entretiens avec ces membres de l'équipe après après que les RH nous aient passé le le profil.
[00:39:43] Euh, si ces entretiens se passent bien, que les euh 5, 6 personnes concernées par les entretiens se réunissent et disent oui, on y va, ou non, on n'y va pas, et ben on embauche la personne. C'est-à-dire que il y a pas un on fait pas une contre-validation par un manager, euh on on l'équipe a l'autonomie de décider euh de de décider de de qui elle recrute. Un autre exemple, c'est les outils, il y a beaucoup de liberté de choix des outils euh chez Sker.
[00:40:12] Dans mon équipe, par exemple, on a décidé d'utiliser Notion, c'est peut-être un outil que vous connaissez, et donc on fonctionne comme ça, on est la seule équipe de la R&D à utiliser Notion. Mais c'est un super outil, ceci dit. Euh et puis d'autres équipes ont choisi d'autres outils qui correspondent à leurs usages. Euh et il y a cette liberté là en fait, il y a pas de volonté d'uniformiser, de déterminer un seul meilleur outil et une seule meilleure pratique pour l'ensemble de la R&D. Si euh une équipe sait dire pourquoi elle a elle a fait la demande de euh d'utiliser un outil particulier ou autre, et ben c'est c'est c'est OK, ça peut se faire. Un autre exemple euh qui est récent et qui euh et qui euh qui me semble important, tiens, vas-y, si tu veux, c'est la constitution des équipes.
[00:40:56] Alors ne cherchez pas à lire ce qui est écrit, de toute façon, vous comprendrez rien. Mais ce qui vous est illustré là, c'est un atelier qu'on a fait euh euh au mois de novembre dans mon équipe, où en fait, on a euh fusionné deux équipes et donc mon équipe a euh grossi de façon radicale, on est passé de 16 ingénieurs à 24 du jour au lendemain. Et il fallait qu'on gère ça et évidemment, il y avait la question de ben, donc vous avez vu tout le diagramme de tout à l'heure, comment on constitue les nouvelles équipes maintenant qu'on qu'on a fait + 50%? Et euh bah la réponse c'était ben, vous allez le faire, c'est-à-dire vous les membres d'équipe, c'est vous qui allez décider de comment vous allez constituer les les les nouvelles équipes. Donc c'est ce qu'on retrouve dans ce tableau, je vais pas vous décrire tout, mais c'est un atelier d'une journée qu'on a animé.
[00:41:43] Euh, dans lequel, en fait, on a challengé, on a constitué des petits groupes de trois personnes et chaque groupe avait la responsabilité ce que vous retrouvez là dans les dans chacune des feuilles avec moult post-it. Euh chaque groupe a constitué une proposition de constitution d'équipe, c'est-à-dire qu'ils étaient à trois et devaient dire, OK, demain, si on démarre avec des nouvelles équipes, c'est quoi pour toi la meilleure, pour vous la meilleure composition?
[00:42:03] Faites la meilleure proposition possible à trois. Et on va en avoir donc là on en a sept du coup, et derrière, on a organisé euh un vote, une discussion et cetera pour composer ça, sachant que on s'était mis d'accord sur les critères qui composasaient une bonne équipe.
[00:42:18] Et c'est ce qu'on retrouve au-dessus, c'est-à-dire de l'autonomie, de la polyvalence, euh un équilibrage des séniorités, ce genre de chose. Donc c'est c'était euh déterminer les critères importants pour l'équipe, laisser l'équipe constituer des propositions et voter pour celle qu'elle préfère en fait. Et donc ben le choix de découpage de ces équipes qui sont donc quatre équipes en France, bah il a été fait par les par les membres d'équipe eux-mêmes et pas par un manager. Sachannt que c'était amusant parce que tout en étant un un une équipe habituelle autonomie, bah il y a eu un peu un moment où certains membres de l'équipe pouvaient dire et si le chef il décidait et il nous proposait les équipes, ça nous ça nous éviterait un un casse-tête très difficile. Et puis bah au final, vous voyez, c'est bien passé.
[00:43:05] Euh, dernier élément d'autonomie, je pense qu'il y a intéressant à à à aborder en fait, c'est toute la question de la gestion des dépendances. parce que on vous l'a dit, il y a à la fois euh dans chaque groupe laisse plusieurs équipes. Et euh et par ailleurs, ben du coup, des des silos, il faut le dire, chacun de ses groupes laisse, là qui a l'habitude de bien fonctionner ensemble. Ils sont ils sont à l'aise dans leur laisse et puis euh des fois, il faut qu'ils aillent parler aux autres. On va avoir des dépendances pour débloquer des stories, pour pour pour avancer, pour euh euh pour se donner les moyens les uns les autres. Par exemple, il y a plein d'équipes qui peuvent dépendre de la mienne. Alors comment on résout ces ces dépendances là? Bah c'est un peu pareil quoi. C'est euh si possible, on va on va pas passer par les chefs, on va pas passer par les Scrum Master ou autre, mais on va définir des patterns qui permettent de faire en sorte de gérer ça. Donc il y en a un qui est très simple qui est décrit dans les c'est le pattern du des voyageurs. C'est-à-dire de dire une équipe a besoin d'une expertise qu'elle n'a pas euh pour faire une story. Je vous disais tout à l'heure, euh ben on fait la polyvalence autant qu'on peut sauf quand on peut pas. Bah si on peut pas et il nous manque une compétence, on va chercher une bonne personne, on lui dit si tu es avec nous pour le prochain sprint, et cette personne elle voyage, elle va dire à son équipe si c'est OK pour vous le prochain sprint, je le passe là-bas.
[00:44:17] Et puis je les aide à faire ce truc là, ça a de la valeur et on y va. Et en fait ça se négocie à ce niveau-là, il suffit que tout le monde soit bien informé et il y a pas de, j'allais dire des mots que je déteste, mais il y a pas de répartition des ressources entre chef de projet.
[00:44:30] Euh, donc ça se gère vraiment au niveau des équipes.
[00:44:34] Euh, un autre exemple, c'est les communautés de pratique, où là, on peut avoir des tout un tas de problématiques de d'enjeux techniques ou fonctionnels qui dépassent une seule équipe et qui sont communs à plusieurs groupes, bah dans ce cas-là, en fait, on met en place des communautés de pratique qui vont discuter de cette technologie là, de ces enjeux.
[00:44:51] et de comment la faire vivre au sein de la R&D. Et euh ces communautés de pratique, elles vont être euh potentiellement aussi euh demandeuses et émetteuses de story, et elles vont alimenter les backlogs de choses qui vont permettre de évoluer, utiliser de nouveaux outils, euh
[00:45:06] euh euh supprimer de la dette technique. Et puis vraiment quand on y arrive pas et que on se rend compte que on a un challenge qu'on avait euh qu'on avait jamais vu mais qui dure un certain temps et qui nécessite vraiment une composition particulière d'équipe qu'on a pas, et ben on crée une task force et on lui donne un objectif et ils travaillent ensemble pour le temps qu'il faut et puis après ils rejoignent leurs équipes respectives et puis ça peut fonctionner aussi quoi.
[00:45:32] Voilà des exemples de d'initiatives transverse aussi euh multi-équipe. Très régulièrement, à peu près tous les deux mois, on organise un Tech day euh qui est un dont le but principal est de partager les bonnes pratiques entre les les différentes équipes. et de justement de faire sortir du giron des équipes, les bonnes pratiques qu'elles soient techniques, surtout techniques ou organisationnelles et qui sont intéressantes à connaître par les autres et que ça ça ça essme dans les autres équipes.
[00:46:05] Voilà, et pour conclure, parce que tout le monde a chaud maintenant, je pense.
[00:46:07] Ouais, il fait chaud depuis longtemps, je pense.
[00:46:09] Ouais. Euh, donc nous euh le scaling finalement de de l'agilité chez Sker, euh une des valeurs fondamentales de Les, c'est c'est de garder en fait l'agilité chez Sker. Donc Les, c'est vraiment du Scrum à plusieurs équipes.
[00:46:26] Ça changeait pas fondamentalement ce qu'on faisait. C'est juste qu'on s'est mis à le faire à grande échelle, quoi.
[00:46:32] Et en même temps, on n'a pas non plus euh on n'est pas non plus euh comment dire, des euh des intégristes du framework, je pense que on on y prend plein de bonnes idées de principes et pour l'essentiel, on y colle, mais euh si si on trouve utile de déroger, et ben on déroge si on sait l'expliquer, je pense que c'est OK.
[00:46:48] Donc euh savoir adapter les framework aussi, c'est pas parce que c'est écrit dans le framework qu'il faut faire comme ça.
[00:46:55] Voilà, le 4ème principe, queuing theory, ben c'est de déléguer aux équipes. Donc tous les aspects euh cybersécurité, il y a une COP, community of practice cybersécurité qui nous soumet des stories au PO. Euh, il y a une COP UX, il y a il y a des communautés de pratique inter équipes et donc nous on délègue beaucoup les PO parce que sinon on arriverait pas à prioriser toutes ces stories.
[00:47:16] Et puis garder ce principe de rester simple, chercher à faire simple, que ce soit dans la manière dont on a organisé, que ce soit dans la manière dont on résout nos problèmes, que ce soit dans la conception technique de nos produits, viser la simplicité, c'est ce qu'on essaie de faire.
[00:47:34] Et merci à tous.
[00:47:36] Merci à tous.
[00:47:44] On est à l'heure.
[00:47:46] Y a-t-il des questions ?
[00:47:51] Bonjour. Merci.
[00:47:55] Euh, moi je vais mettre le pied dans le plat puisque vous parliez euh d'équipe autonome, je me pose la question euh, quel est le rôle du Scrum Master dans ce cas-là? Enfin, quelle est l'apport ? Pour moi.
[00:48:13] Euh, bah c'est une excellente question. Tu mets les pieds dans le plat quoi. Euh.
[00:48:20] Euh, bah, je pense que enfin l'autonomie, enfin, déjà pour une équipe Scrum, en fait, le rôle du Scrum Master, c'est de de l'aider à faciliter son autonomie, en fait. Et euh, typiquement, moi, en fait, quand j'ai été plongé dans cet environnement où en fait, je passe de euh accompagner un groupe de 6, 7 personnes à en accompagner 15, 16, 20, euh les challenges sont assez différents du coup et euh il faut déterminer ou répartir ses efforts. Donc en fait, quelque part, ça il y a d'autant plus besoin d'autonomie dans les équipes, parce que le Scrum Master, il va pas pouvoir avoir le même niveau d'accompagnement auprès de chacun et de chaque équipe euh qu'il peut avoir ou que moi j'ai pu avoir, par exemple. euh, auparavant, quand j'avais forcément des plus petites équipes, en fait, c'est un c'est un peu comme le rôle du PO, mais on a on est un un poil moins challengé, donc il se transforme. Après, si je je rentre, enfin, je ne pourrai pas rentrer dans les détails parce que un moment, je me disais, on pourrait faire une conf là-dessus, mais euh.
[00:49:20] Mais c'est sûr qu'il y a plus de challenges sur les les euh l'interaction entre les équipes, euh sur ou sur des changements un peu plus euh radicaux quoi, des améliorations euh euh qu'on peut aller chercher qui qui aillent chercher plus loin et qui en particulier vont aller impliquer plusieurs équipes et donc il va falloir les aligner entre elles. Et aligner cinq personnes, c'est pas simple. Euh, en aligner 15 entre elles, voire euh 25 à travers deux continents, c'est un c'est un tout autre challenge et euh et euh et c'est c'est c'est assez amusant.
[00:49:52] Voilà, j'espère que je réponds à ta question.
[00:49:58] En tout cas, moi je peux témoigner que ils sont très très occupés les Scrum Master, ils s'ennuient pas.
[00:50:04] Euh et les équipes savent enfin s'appuient beaucoup sur eux justement pour trouver les moyens de s'auto-organiser.
[00:50:11] Alors, je vais enchaîner avec une question un peu qui qui fait la suite de ce que vous disiez.
[00:50:17] Euh, moi pour avoir bossé dans une organisation LESS, un des gros challenges qu'on a eu justement, c'était à éviter que les équipes se spécialisent. Euh, et en fait, on a vu que elles avaient tendance malgré un peu les les les les choses qu'on préconisait à euh à vouloir anticiper par exemple, à se dire bah est-ce que je je vais aller bosser sur ce sujet-là qui est dans le baclog ou pas? Et à ce moment-là, on voyait des phénomènes du genre ne participe au PBR que les gens qui pressentent que ils vont vraiment bosser sur la story et et à force, ça faisait que les équipes se spécialisaient. Comment vous avez fait pour lutter contre ça?
[00:51:00] Alors c'est c'est pour ça que j'ai mis un slide dessus, c'est parce que euh c'est un point d'attention euh permanent en fait. Donc en particulier, par exemple, quand on a composé je vous ai montré l'atelier où on a recomposé nos équipes, il y a un principe de base qui a été reposé, c'est de viser la polyvalence technique. Euh, dans mon équipe, c'est un challenge particulièrement important euh parce que je dis pas que dans les équipes de dev c'est facile hein. Euh mais au niveau SRE sur l'infra, on a une quantité de technologie à maîtriser qui est juste incroyable.
[00:51:32] Et euh et c'est vrai que c'est enfin je dirais que la première chose c'est que c'est pas facile tous les jours pour les membres de l'équipe, c'est-à-dire que des fois ils peuvent se sentir un peu débordé de de niveau de scope qu'ils ont à avoir dans la tête pour arriver à à travailler sur le euh sur ce qu'on fait. Donc euh ouais, c'est un c'est un vrai challenge et en même temps, on y voit le bénéfice aussi, enfin je veux dire, le but c'est pas de de d'être dans la religion de la polyvalence, mais c'est de se rendre compte que bah dans l'année en fait, nos les attentes, les choses sur lesquelles on doit travailler, c'est très cyclique. Ça ça euh ça varie, d'un coup, on va on peut avoir un gros challenge qui émerge et qui nécessite certaines compétences, on s'en fait 6 mois qu'on touche très peu. Euh et donc il faut pouvoir s'adapter à ça et ce qui nous permet de nous adapter à ça, c'est la polyvalence. Donc donc, on pose la polyvalence comme un principe, quand les membres de l'équipe disent ouais non mais c'est trop dur là, il faudrait qu'on soit tous réunis tous tous les experts machins, on va dire plutôt ben il y a déjà les PBR pour pour faire ce genre de choses. Faites des rendez-vous dédiés pour ça et cetera. Euh et puis euh et puis c'est un élément de responsabilisation et de délégation quoi, c'est de dire euh ben ouais, le meilleur expert de notre techno de cette techno là, il est pas euh tu vois, il est pas dans ton équipe, mais je suis sûr que tu peux y arriver quand même quoi. Je sais pas si ça répond à ta question, mais ouais, merci pour ta question parce que oui, c'est effectivement c'est un vrai gros challenge.
[00:52:51] Et je me posais une autre question euh soulevée par euh le point sur les les la gestion des dépendances et le fait que il y a des personnes qui euh vont passer d'une équipe à une autre, pardon. Euh, et donc je me posais la question autour des objectifs. Comment euh comment, est-ce qu'il y a des process de gestion d'objectifs, à quel niveau et comment ça s'ajuste, ça s'adapte?
[00:53:14] Le scaddles.
[00:53:18] Alors moi, en fait, je gère pas trop ça. C'est-à-dire je gère mes priorités.
[00:53:24] Et euh et quelque part, j'ai une attente que les équipes s'organisent autour de mes priorités. Donc ça répond aussi un petit peu à votre question. C'est-à-dire que si j'ai j'ai trois équipes, euh s'il y a trois stories qui sont attendues par les clients à la fin du sprint, euh je vais essayer de les mettre en prioritaire et je vais proposer qu'elles soient réparties sur les trois équipes. Après, ils vont communiquer entre eux pour se transférer les compétences qu'ils ont pas. Parce que oui, ils se sinon, ils vont dire bah cette story euh elle va plutôt là parce qu'ils ont les compétences, et puis celle-là, ah bah tiens, celle-là aussi, et puis celle-là aussi, et puis à la fin, il y a tout un sprint qui va sur une équipe et les deux autres font rien. Euh et c'est pas ce qui se passe en fait, c'est que les équipes essaient de bien respecter les priorités et de prendre un petit peu des stories de chaque.
[00:54:11] C'était pas la question.
[00:54:12] Je vais essayer.
[00:54:15] Sur les objectifs, pour nous, pour un objectif donné, est-ce qu'il y a une évaluation a posteriori avec les objectifs qui sont en place?
[00:54:24] Non.
[00:54:26] Ah. Donc ça c'était la version courte. C'est clair que dans un compte, mais je pense que c'est pas propre à l'est ou quoi, c'est que dans un contexte agile, c'est vrai que ce qu'on ce qu'on va attendre des membres d'équipe en fait, c'est vraiment l'adaptabilité, d'être capable de euh de bah de d'être présent quand il y a de nouveaux quand on découvre des nouvelles choses et qu'il faut qu'il faut s'adapter. Donc quelque part, fixer à l'avance des objectifs longtemps à l'avance sur lesquels les personnes va être va être évaluée de façon très rigide en disant, il faut que tu aies fait ça, alors qu'en fait, on sait que les priorités du baclog vont changer, c'est contradictoire. Donc un un un management par objectif euh euh très carré, je pense que ça ça c'est c'est c'est difficilement euh mixable avec l'agilité. Ceci dit, on peut insister plus sur des des comportements attendus, ce genre de chose, euh sur euh sur être capable de monter en compétence sur telle technologie, par exemple, donc d'avoir des objectifs un peu plus euh génériques et qui soient réalistes, mais forcément si euh si j'ai quelqu'un dans mon équipe qui va dire euh euh tiens, cette année, je monteraais bien euh à fond en compétence sur l'administration et la l'architecture Open search.
[00:55:36] Et que il se trouve que dans l'année en fait, on a des énormes projets sur du poseux, et ben il va se trouver qu'il va plutôt faire du poseux et qu'à la fin de l'année on dira bah bravo, tu es monté en compétence sur cette techno et c'est super en fait. Voilà.
[00:55:49] Et la la question c'est.
[00:55:54] Je dirais je dirais pour faire rapide, la question c'est est-ce qu'il y a des objectifs collectifs ou individuels et je dirais pour faire rapide, il y a des objectifs individuels mais qu'on essaie de faire de la nature que je te décrivais. Et euh, excusez-les objectifs collectifs. Non.
[00:56:11] Moi je dirais oui.
[00:56:14] Moi je dirais oui, les principaux objectifs, c'est jouer le jeu des équipes Scrum agiles. Donc ce qu'on retrouve dans les fiches de poste de team member, c'est ça en fait les objectifs qu'on va évaluer chaque année. C'est-à-dire le teamplay, la collaboration, l'amélioration continue. Il y a déjà en fait tout ce qu'il faut dans Scrum pour faire une fiche de poste quoi. Et donc c'est ça qu'on évalue, après, on croise ça avec l'expérience. C'est-à-dire en fonction de la montée en compétence des gens, on attend d'eux plus de système, c'est-à-dire d'action impactante au niveau R&D. Donc investissement dans les community of practice, dans les tech day, euh dans des conférences, des choses comme ça.
[00:56:55] Alors, moi j'ai deux questions, la première, c'est, est-ce que vous utilisez votre propre solution en interne ?
[00:57:00] Alors ça, c'est une super question. Oui, on utilise nos propres solutions en interne. Euh, pas toutes, encore. Euh, pas tout et je réfléchis.
[00:57:15] Non mais c'est déjà bien que vous l'utilisiez, c'est déjà une bonne nouvelle. Et la réponse courte c'est oui. Et une question beaucoup plus complexe, comment est-ce que vous faites pour garantir une cohérence architecturale tant sur la partie business que sur la partie tech ?
[00:57:28] Alors sur la partie business, on a des réunions euh entre product owner euh qui sont assez fréquentes. Donc moi, par exemple, j'ai une réunion spécifique pour le prochain sprint avec le VPR&D et les product owner de cycle Order to cash, parce qu'il y a quand même beaucoup d'interaction en Order to cash entre customer service et Invoice to cash. Et je vais aussi à l'autre réunion côté purchasing parce que le purchasing, c'est le pendant de, enfin les achats, c'est le pendant de le traitement des commandes chez les fournisseurs. Euh, on a toutes les semaines des PO meeting euh côté fonctionnel. Et côté tech, je te laisse répondre.
[00:58:11] Je peux essayer rapidement. Côté tech, ben entre autres, il y a les communautés de pratique, ce qu'on vous montrait dans le schéma d'organisationnel, c'est qu'il y a vraiment tout ce socle technologique commun, vraiment le framework interne qui fait que les différentes équipes s'appuient surtout sur des briques communes. Voilà. Et euh l'autre chose que je peux dire aussi, c'est comment on garantit la cohérence, bah des fois il y a divergence euh et des fois même il y a des équipes qui divergent et il y en a certaines qui trouvent des meilleures façons de faire. Et donc je pense que ça va aussi avec l'agilité, c'est d'accepter que des fois on explore plusieurs pistes et puis on en trouve certains de meilleurs, certains pas et que c'est c'est ça qui permet d'avancer quoi. Donc voilà, on a pas une cohérence 100 % et c'est peut-être pas forcément l'objectif. Et je crois qu'on est au bout du temps, c'est ça?
[00:58:50] Non, non, non.
[00:58:51] Allez.
[00:58:51] OK, j'ai j'ai le micro, j'en profite.
[00:58:54] J'avais une question sur l'autonomie des équipes, tu as pris l'exemple de du recrutement délégué aux équipes, comment est-ce que j'aime savoir c'est la le revers de cette médaille là, comment vous décidez de sortir quelqu'un de l'équipe, est-ce que ça se décide par l'équipe ou pas?
[00:59:13] Ouf.
[00:59:15] Alors.
[00:59:15] Wah. J'ai dit qu'il avait chaud et qu'il faisait chaud. Euh, alors attends. Oui, donc en particulier, donc donc il y a le process de recrutement, il y a aussi le process d'accompagnement sur la période d'essai. Ça aussi, c'est c'est cadré en fait au sein de l'équipe, on a des on a des rendez-vous au milieu de la période d'essai où en fait l'équipe va faire des feedbacks au nouvel arrivant et en particulier, on va se dire est-ce qu'il y a des choses qui sont potentiellement euh à risque pour tu restes ou pas et qu'est-ce qu'on espère qu'il enfin, qu'est-ce qu'on attend qui changerait, qui ferait que si ça change, bah c'est OK et on et on se tapera tous dans la main à la fin de ta période d'essai, et si c'est pas le cas, ben au moins on aura été transparent sur le fait que ça marche pas, et ça ça remonte de l'équipe.
[01:00:01] Et euh, pour les cas plus compliqués euh si vous avez une recette magique à ça, je veux bien, mais euh je je dirais que ça là pour le coup, c'est quand même pas mal les Scrum Master et les managers qui prennent leur rôle de une fois qu'il y a un certain nombre de remontées du terrain, des gens dans les équipes qui disent là il y a vraiment un problème et souvent enfin et c'est de là que ça vient, bah à un moment, il faut prendre son cour à demain et puis en plus en France, c'est des processus très longs et compliqués et euh et voilà, c'est ce que je dirais là. Et euh je propose qu'on fasse une dernière question parce que nous restons pas sur euh une dernière rapide. Ce truc là, s'il vous plaît.
[01:00:40] Merci hein, pour cette présentation inspirante. Euh, ça a l'air tellement simple quand même quand vous le décrivez comme ça. Euh moi j'ai j'ai deux questions. La première, c'est comment, c'est quoi les premiers pas justement pour aller vers une organisation LESS ? Et euh, deuxième question, quel est le rôle des managers ?
[01:01:04] On on finit simple. Je je veux que j'y aille, tu veux que je? Alors. Le premier pas pour faire du LESS, c'est d'être de savoir faire du Scrum. Et c'est même valable pour d'autres frameworks qui se baseraient sur Scrum, imaginons qu'il en est d'autres. Voilà. Et or, je pense qu'on saute souvent ce premier pas. Euh, voilà. Et je pense que quand même, si on a un Scrum qui fonctionne plutôt bien, c'est-à-dire que vraiment on livre de façon régulière et c'est voilà, ce challenge est passé et il y a vraiment de l'autonomie de l'équipe et cetera, euh finalement, le commencer à le faire à plusieurs équipes, ça je dis pas que c'est simple, mais je pense que ça se fait de façon organique, voilà.
[01:01:45] Ouais. Oui.
[01:01:49] La deuxième partie, c'était sur les managers ? Alors notre formateur LESS, il nous a dit, si vous avez des managers, voilà ce que vous pouvez faire. Parce que c'est pas un rôle dans dans les S, mais la loi française oblige qu'il y a un manager qui s'occupe au moins, qui fasse au moins un entretien de carrière une fois par an. Donc ça, ça fait partie des duties du manager. Après le le quoi faire, bah c'est le product owner, il a il a son backlog. Donc la partie quoi, c'est gérée par le backlog. La partie comment, c'est plutôt de l'auto-organisation. Et donc le rôle du manager, il est réduit à peu de choses.
[01:02:24] Le coaching, de la gestion de carrière et puis bah parfois du du offboarding. De l'équipe, ça peut être aller dans une autre équipe.
[01:02:37] Mais justement, c'est très peu.
[01:02:42] Merci beaucoup.

Transcription