Samuel Retiere

Tout d'abord, je me présente, Samuel Rottier. Là, ce n'est pas écrit après, je le dis juste en intro. Je suis coach agile, ancien manager. Vous verrez après pourquoi ça compte.
Ce dont je vais vous parler, c'est côté banque d'investissement de la Société Générale. Pour juste parler un peu de la taille, on est à peu près, je ne sais plus exactement combien, mais sur Paris, on est entre 3 et 5 000 côté informatique. Donc là, Canman for Manager, pourquoi je parle de ça?
Ici, je pense que personne ne m'a vu au Scrum Day. Globalement, ce qui se passe côté Société Générale, on parle souvent de scaling agile, surtout côté banque d'investissement. Donc nous, on a fait vraiment du déploiement de masse. Donc dans le déploiement de masse, après, il y a vraiment un jeu déploie. Et pour réussir à faire ça, souvent, on parle de quoi? On parle du manager agile. Alors le manager agile... J'aime beaucoup quand je vais dans des conférences agiles, on en parle beaucoup. C'est celui qui aide ses équipes, qui est tout le temps là pour eux, servant leadership et des choses comme ça.
Je me permets juste. Donc, servant leadership, dans la pratique, je n'en ai pas vu beaucoup des servants leaders et des managers agiles qui sont arrivés comme ça. Donc, on va dire quoi? On va dire que dans la pratique, on a quand même souvent à faire du travail pour réussir à avoir des managers avec un mindset un peu plus agile. Donc pour y arriver, ce qu'on fait, ce en quoi je crois principalement, c'est de réussir à faire que les managers pensent agile en vraiment en pratiquant agile. Donc on a fait la même chose un peu avec le métier, faire travailler le métier sur des projets agiles sans IT, pour qu'eux, ils sachent comment ça marche de leur côté. Donc là, côté manager, c'est faire qu'eux, ils pratiquent l'agilité sans qu'il y ait nécessairement des équipes qui développent du logiciel en dessous. Donc le but, c'est un peu de faire ça.
Je vais faire la présentation en trois parties. Dire comment c'est arrivé le Kanban pour Manager. Donc là je dis un peu comment c'est arrivé. En fait on l'a découvert par hasard. Ce n'était pas quelque chose qui a été réfléchi. Une fois qu'on a vu apparaître ça, il y en a plusieurs qui sont apparus chez nous. On a vraiment... créer, on va dire, mise en place un modèle de maturité. Et donc c'est comme ça que je vais vous expliquer en gros ce que c'est pour nous, Kanban pour Manager. Pas juste dire, ok, Kanban pour Manager c'est ça, mais où est-ce que nous on le place dans les pratiques managériales. Et après, je vais vous dire en gros comment va la suite chez nous.
Bon là c'est un petit slide, il est super joli. Pour vous parler en gros de la banque d'investissement de la Société Générale, il faut que je fasse un peu d'histoire. Donc il y a deux ans, notre chef vénéré à tous, notre DSI, en gros nous a dit que dans deux ans, 40% des projets seront en agile. Donc ça c'était il y a deux ans, ça c'était la cible. En gros il y a deux ans, on ne peut pas dire qu'on n'avait rien, on avait quelques équipes agiles, pas tant que ça. Mais en gros il a donné un objectif très très clair et il fallait aller vers là. Donc quelques mois plus tard, le centre agile s'est créé. Au moment où le centre agile s'est créé, au début, on ne faisait que du Scrum. C'était vraiment Scrum only. Donc là, on le voit, c'est ici.
Après, on a déployé du Scrum au début. C'est là où on voit que ça s'est pas mal déployé. Après, les barres grises, qu'est-ce que c'est? Forcément, dans le banque d'investissement, on est quand même assez drivé par les indicateurs de performance et choses qui vont bien. Donc en gros, ce qui se passe en février-mars chez nous, c'est les objectifs annuels. Je sais, c'est un peu bizarre que ce soit en février-mars, mais c'est en février-mars. Donc là, il y a plein de projets et d'équipes qui sont autodéclarés agiles. Donc ça, c'est toute la barre grise. Après, on s'est rendu compte que Scrum c'était bien, mais que dans certaines équipes on avait eu pas mal de soucis et que ça passait pas bien. Donc là, c'est le livre de Michael Saota sur la culture qui nous a fait un peu changer de manière de voir. De dire arrêtons de prendre Scrum et de le déployer tel quel. Ils ont une approche peut-être un peu plus itérative et incrémentale. Et c'est là où on a commencé en plus d'utiliser Scrum à utiliser en plus Kanban. Donc ça c'était on va dire l'été dernier.
Donc on a continué à déployer. Donc là, vous voyez, à partir de ce moment-là, Scrum, finalement, ça se tasse. On a quasiment fait que du Kanban ces derniers temps. Donc vraiment, on a déployé du Kanban en plus. Et après, événement qui compte, c'est cet été, il y a un des coachs qui est chez nous, qui s'appelle Jerry Derbier, pour le pas de nommer, qui a commencé à avoir une approche crystal clear. Donc il y a une autre approche, je ne sais pas si tout le monde connaît, je ne suis pas sûr, donc je vais expliquer un peu en gros, c'est de dire que les pratiques ne sont pas importantes, ce qui compte c'est le résultat attendu, c'est les propriétés d'une équipe agile. Donc il l'a fait sur une équipe, ce n'est pas tant intéressant qu'il l'ait fait sur une équipe agile, surtout que ça a changé notre manière de voir sur les outils, les frameworks. En gros, on a commencé à dire que ce qui compte, c'est le résultat. On veut des propriétés d'une équipe agile. On veut du feedback client sur un working software. On veut que l'équipe soit auto-organisée, des choses comme ça. Et après, on a commencé à laisser libre les équipes. Vous faites du Scrum, vous faites du Kanban, en gros vous faites ce que vous voulez, pour nous c'est pas très grave. Donc on a arrêté d'avoir une différence Scrum-Kanban, parce qu'en plus on avait les Scrum-Ban, qui pour moi ne veut pas dire grand chose, et on s'est mis à dire on a des équipes agiles, qui ont des propriétés agiles, après vous prenez les pratiques que vous voulez, sachant que nous quand même, coach agile, on est là pour les conseiller, mais vous êtes libre.
Donc après, il y a quand même un petit truc, c'est qu'on devait faire 40% dans deux ans, puis on s'est retrouvé à faire 40% bien plus tôt que ce qui était prévu. Là, on a même dépassé 50%. Et là, notre DSI, il a un peu demandé, mais au fait, c'est quoi l'agilité chez nous? Est-ce qu'on est vraiment sûr que les équipes sont vraiment agiles? Donc là, en gros, il nous a demandé, donc là j'ai mis« Keep calm because I am the law», c'est nous, centre agile, d'aller regarder ce qui se passe, on va dire, sur le terrain, et de voir un peu quel est le niveau de maturité des équipes agiles chez nous. Donc là, on est allé voir par rapport à des propriétés. Il faut savoir qu'au niveau du coaching, nous on avait vu qu'à peu près 10% des équipes, tout le reste, c'était parti soit du coaching, ils l'ont fait en direct, soit ils sont auto-formés, des choses comme ça. Et donc là, on a dû vraiment aller voir ce qui se passait. Donc là d'ailleurs, en allant voir ce qui se passait, on voit que la courbe est descendante, parce qu'on a vu des comportements que nous on considère comme plus agiles. Par exemple, je prends l'exemple d'un projet où ils ont figé la roadmap sur toute l'année. Donc ils ont tellement verrouillé le scope que sur toutes les itérations de l'année, on connaît le scope. Donc forcément, ça a eu beaucoup d'effets pervers. L'équipe est plus responsabilisée, ils ne sont plus committés sur des itérations, donc on sait à l'avance quelles sont leurs itérations. Donc là, par exemple, comment ils ont fait pour réussir à tenir les délèves? Ils ont tapé sur la qualité. Ils ont tapé sur la qualité ou sinon ils ont tapé sur les heures sup. Donc en gros là on est passé dans un mode où on va voir, sachant qu'on essaye de ne pas être les flics, mais on essaye plutôt de dire ok, c'est vraiment trop flagrant qu'ils sont là. écartés, on les disqualifie. Et là on s'est rendu compte quand même d'une chose, c'est que j'appellerais ça la nature profonde de la banque d'investissement de la Société Générale au niveau management, donc la strade qui est au-dessus, c'est plutôt quand même de dire par défaut on fait du waterfall. Toutes les équipes en dessous, donc en gros
40% des équipes en dessous bossent en agile, mais la façon dont les managers du dessus pensent, elle n'est pas vraiment agile. Ils ont tendance finalement à mettre un cadre qui a tendance à faire que les équipes retournent vers du waterfall. Donc là, avec le turnover qu'on a chez nous, on va dire, au fait que les gens doivent bouger tous les trois ans, soit les internes, soit les prestataires. Donc en gros... Chaque année où on perd 30% des équipes. Donc ce turnover-là a fait que sur certaines équipes, on s'est rendu compte qu'elles étaient agiles à un moment et c'est retombé. Donc un de nos gros défis, il est quand même sur la partie strat-managériale au-dessus des équipes, qui vraiment fait que naturellement, ils ont tendance à revenir en arrière. Typiquement, ils en posent souvent des roadmaps, le staffing connu sur toute l'année, des choses comme ça. Donc après, il y a eu trois petits événements qui nous ont permis d'avancer sur cette partie-là, Agile pour le management. Le premier amendement, c'était en septembre de l'année dernière. On a chez nous ce qu'on appelle les Agile Fairs. C'est tous les trois mois, on fait des sessions, en général il y a une dizaine de stands où on présente des nouveautés. C'est des stands d'un quart d'heure qui se répètent, on fait de la awareness. Donc c'est présenter vraiment les nouveautés. Donc à cette occasion-là, en septembre, J'avais présenté Kanban, on commençait à travailler sur Kanban.
Et là, finalement, pas longtemps après, Je reçois un mail d'un des managers qui me fait « We need your help ». Donc c'est exactement ce mail-là qui m'a fait. Et donc là après, moi j'y suis allé pour essayer de les aider. Et en fait j'ai vu apparaître quoi? J'ai vu apparaître des managers. Donc au niveau de ce qu'on appelle chez nous un responsibility center, c'est en gros des managers qui ont 150 personnes en dessous d'eux à peu près. J'ai vu apparaître un board qui ressemblait très fortement quand même à un Kanban. Donc eux, ils sont partis tout seuls et c'est les premiers qui l'ont fait. Donc ça, c'est côté équipe de dev. Après, en février de cette année, on s'est rendu compte qu'on était, donc 40%, je crois même qu'on était à 42%, on va dire, agile. Ce qu'on considère nous comme agile côté dev, mais côté ops, donc tout ce qui est production, le support, intégration. Toutes ces activités-là, eux, ils étaient agiles à 2%. Donc en gros, il y avait un gros gap entre du business jusqu'au dev, on est agile, mais dès qu'on veut faire dev jusqu'à prod, c'est un peu la galère. Donc là, on a remonté ça à leur top manager, donc le responsable de tous ces gens-là, il dirige à peu près 1200 personnes sous lui. Donc quand il s'est rendu compte de l'écart entre ce qui avait été fait côté dev et ce qui avait été fait ailleurs, sachant que lui aussi, il a quand même cet objectif à lui d'essayer d'être un peu agile, il a dit« Ok, nous, le board de management va commencer à appliquer à nous-mêmes. Donc là, ils m'ont demandé de les aider pour mettre en place, on va dire à la base, du visual management pour aller vers du Kanban.
Et au bout de deux mois, ils m'ont posé la question, mais au fait, c'est quoi notre niveau d'agilité? Alors un niveau d'agilité sur un board de manager, j'étais un peu embêté. Donc là, c'est à ce moment-là que je me suis dit, oula, J'ai un peu besoin d'un modèle de maturité parce qu'ils voulaient savoir jusqu'où ils pouvaient aller, à quel niveau ils étaient. En gros, ils voulaient que je leur donne un peu une progression possible. Donc c'est à ce moment-là que j'ai commencé à créer le modèle de maturité.
Et après, en avril, on commençait pas mal l'initiative DevOps, donc essayer d'être agile, on va dire, du bout en bout sur la chaîne. Pas juste s'arrêter à la fin du dev, mais d'être agile, on va dire, et être capable de livrer en prod assez facilement. Donc là, il y a une initiative agile sur la partie Ops. Donc là, moi j'y suis allé pour regarder ce qu'on pouvait faire avec les équipes d'Ops. Et là, ils m'ont dit, à un moment, j'ai rencontré les Ops, ils m'ont dit, mais allez voir l'équipe de Dev. Donc là, je suis allé voir l'équipe de Dev pour voir comment ils bossaient, parce que je ne les connaissais pas tant que ça. Et là, j'ai découvert quoi? Qu'ils avaient un daily meeting avec tous les managers devant un tableau. Donc là, j'y suis allé pour voir à quoi ça ressemblait. Et je me suis rendu compte qu'il y avait quand même de l'échange, mais que ça ne ressemblait pas au précédent board Kanban que j'avais vu l'été d'avant. Donc là, en gros, that's more complicated. C'est moi qui me suis dit, en voyant ça, le modèle de maturité est un peu plus compliqué que ce que je pensais. Et donc c'est ça qui m'a fait encore faire évoluer le modèle de maturité. Que je vais présenter juste après.
Bon, un manager, là j'ai repris la définition de Wikipédia. C'est juste pour dire, voilà, c'est quelqu'un qui fait beaucoup de choses, qui essaie de coordonner des gens.
Mais la question que je pose derrière, c'est est-ce qu'il y a vraiment un seul type de management? Est-ce qu'il y a un seul type de manager?
Dans certaines boîtes, oui. Dans une boîte de la taille de la Banque d'investissement, La Société Générale, c'est quand même pas tout à fait vrai.
Donc pour moi, il y a quand même plus les managers opérationnels. Donc c'est ceux-là où on a pas mal bossé avec eux sur la partie agile. Donc pour moi, c'est ceux qui sont vraiment...
C'est le manager juste au-dessus, des gens qui sont tout en bas. Donc lui, c'est vraiment un peu le pompier, il est au feu, il est à la mine, c'est lui qui fait avancer les choses. Après, on a le top manager, qui est quand même quelques échelons au-dessus. C'est lui qui définit la vision, vers où on veut aller. Donc c'est eux en général qui font les plans. Ah dans 5 ans on sera là? C'est toujours les plans qui m'amusent beaucoup. Oui?
De couches? Pas tant que ça. Entre notre DSI et les gens qui sont en bas, il y a 5 couches à peu près. Pour une boîte de notre taille, c'est pas tant que ça finalement. Ils ont vraiment décidé d'avoir pas trop de couches.
De quoi ?
En largeur, on est à Paris, on doit être à 3000, un truc comme ça. Entre 3 et 5000, je ne connais pas les chiffres exactement. Pour la petite histoire, il y avait le nombre d'équipes avant. On ne connaît pas le nombre d'équipes qu'on a chez nous. C'est un niveau qu'on n'a pas. Au niveau organisationnel, on a ce qu'on appelle le Responsibility Center. On sait qu'il y a à peu près 150 personnes en dessous, mais on ne sait absolument pas comment elles sont organisées. Il n'y a aucun organigramme qui permet de savoir le nombre d'équipes chez nous. Donc là, les équipes agiles, c'est parce que moi, je suis allé voir tous les boards et tout, puis après, j'ai reconstitué le fichier, mais à la base, on ne l'avait pas. On sait le nombre de personnes qu'on a, mais on ne sait pas comment ils sont organisés.
En fait, il est calculé par rapport au budget consommé en euros. D'ailleurs, c'est en euros. Au budget consommé en euros sur les projets. L'indicateur, il a été fait comme ça à la base. Il est fait sur les projets, il n'est pas fait sur les équipes. Après, le middle management, c'est toutes les couches intermédiaires. Et globalement, là où je disais qu'on a pas mal de difficultés, c'est vraiment sur cette couche-là, qui est vraiment une couche où ils sont censés avoir la direction stratégique qui vient d'en haut, puis ils sont censés passer au niveau tactique. Dans la pratique, ce qu'on voit, c'est qu'on a vraiment, en fonction des middle managers, on le voit par exemple sur la partie agile, on a des endroits où c'est très agile, d'autres endroits où ça l'est beaucoup moins. C'est un peu en fonction de ce qu'il a envie de faire. Et ce qui se passe souvent, c'est que ces gens-là, middle management, ils ont beaucoup de demandes, beaucoup de stratégies, mais ils en ont tellement que finalement ça dépasse ce qu'ils peuvent faire, et chacun choisit un peu ce qu'il a envie de faire. Et c'est souvent sur cette couche-là qu'on voit un peu, ok, j'ai un nouvel objectif, en dessous vous allez bouger, mais moi par contre je continue à bosser comme avant. Et c'est souvent ce qui se passe. Et donc on revoit, ok, j'ai des équipes agiles, mais vous me faites une roadmap, puis vous me dites dans trois ans où j'en suis. Donc ça c'est quelque chose qu'on voit relativement souvent.
Bon alors, il fait quoi le middle manager? En gros, il a les directives qui arrivent d'en haut, il supervise les managers qui sont en bas, donc ça, ça descend d'un côté, puis ça remonte de l'autre. Qu'est-ce qui remonte? En général, chez nous, c'est du KPI et du reporting. Ok, comment vous êtes? Puis là, j'ai... J'ai mis un petit dessin avec AAA. On a chez nous ce qu'on appelle souvent sur les projets les indicateurs pastèque. C'est-à-dire qu'ils sont tous verts. Si on regarde les indicateurs projet, c'est simple, ils sont tous verts. Pourquoi pastèque? Parce que si on regarde un peu à l'intérieur, il y en a quand même un bon paquet qui sont rouges. Mais par défaut, ils sont tous verts. Pour moi, les indicateurs qu'on a actuellement, ils ne servent pas à grand-chose.
Bon, là finalement j'ai présenté un modèle, qui est vraiment le modèle un peu comme on a de contrôle, ça descend, ça remonte. Donc moi c'est ce que j'appelle« I work for my boss». Et après je vous ai fait des petits schémas comme ça. Donc en gros l'OBA c'est un peu pour moi là où ça se passe. Si vous voulez savoir ce qui se passe dans une organisation comme ça, Vous avez intérêt d'aller au café, parce qu'en général, c'est là que vous apprenez les choses. C'est dans les couloirs, mais c'est très siloté. Et c'est vraiment les objectifs individuels. Si vous regardez ce qu'il y a dedans, vous allez retrouver du reporting et du contrôle. Moi, quand j'étais à un moment middle manager, j'étais épaté. J'avais zéro objectif sur mon équipe. Aucun. J'en avais, je ne sais plus, 23. Ils étaient tous vers le haut. Je devais faire de la com, des choses comme ça. Je devais reporter. Je ne devais pas dépasser mon budget. J'avais zéro objectif sur comment je me débrouillais en tant que manager vis-à-vis de mon équipe. Je n'en avais pas. J'avais que des objectifs sur remonter dans la formation.
De quoi? Moi c'est ce que j'appelle « I work for my boss ». Et après je vous ai fait des petits schémas comme ça. Donc en gros l'OBA c'est un peu pour moi là où ça se passe. Si vous voulez savoir ce qui se passe dans une organisation comme ça, vous avez intérêt d'aller au café, parce qu'en général c'est là que vous apprenez les choses. C'est dans les couloirs, mais c'est très siloté. Et c'est vraiment les objectifs individuels, si vous regardez ce qu'il y a dedans, vous allez retrouver du reporting et du contrôle. Moi, quand j'étais à un moment middle manager, j'étais épaté. J'avais zéro objectif sur mon équipe. Aucun. J'en avais, je ne sais plus, 23. Ils étaient tous vers le haut. Je devais faire de la com, des choses comme ça. Je devais reporter. Je ne devais pas dépasser mon budget. Mais j'avais zéro objectif sur comment je me débrouillais en tant que manager vis-à-vis de mon équipe. Je n'en avais pas. J'avais que des objectifs sur remonter dans la formation.
De quoi?
Ouais, non, c'était même pas le débat. J'avais même proposé d'en rajouter, mais on m'avait dit non, c'est pas très important. Donc je n'en avais pas eu finalement.
Bon, est-ce qu'on peut faire autrement? C'est quoi les problèmes? Ouais, on peut faire quand même autrement, on a quand même réussi à bouger à certains endroits. Donc le problème, c'est le manque de culture commune, et puis au niveau partage de connaissances en général, si vous demandez à quelqu'un qu'est-ce qu'il fait le voisin, qu'est-ce que le middle manager d'à côté y fait, ils ne sont même pas capables de répondre. Moi ça m'avait un peu marqué quand je suis arrivé dans la banque d'investissement, j'étais arrivé sur une table dans un open space et j'avais demandé ils font quoi les gens à côté là, ils étaient à 3 mètres, ben ils savaient pas. C'était quand même assez étonnant. Donc en gros un modèle c'est one project one team, donc qu'est-ce qu'ils ont fait sur les projets Waterfall, c'est quand même essayer de créer des équipes projet. Au lieu d'avoir tout saucissonné, un projet c'est dans plein d'équipes, on crée une équipe projet. Donc c'est un modèle plus comme ça. Tu as une question?
Excuse-moi, c'est juste par rapport aux 3 mètres et aux équipes un peu distantes. Est-ce que tu sentais que c'était voulu ou que finalement il y avait un manque, que les gens auraient aimé savoir ce que faisaient les gens en face ou ils s'en foutaient complètement?
Non, ils s'en foutaient, ce n'est pas un problème. Je ne vois pas l'intérêt en fait.
C'est vraiment un peu chacun dans son silo, mais c'est pas qu'ils les aimaient pas, c'est juste qu'ils voyaient pas trop l'intérêt de discuter avec leurs voisins. Bon, là après je vais parler d'outils un peu. Pour moi, le Kaman pour manager, je le présenterai un peu. Pour moi, c'est un outil. Donc en gros, la partie visual management. Donc là, visual management, vous connaissez le visual management pour, on va dire, souvent pour... Des équipes en bas, mais on a vraiment mis en place du visual management pour des managers, pour que les managers discutent entre eux. Donc des managers de managers qui discutent entre eux. Une des équipes de dev que j'avais vu, justement, c'est ça. Ils avaient mis en place un board pour discuter de tous les projets qu'il y avait au sein de leur équipe. Donc ça, c'est des managers en tout. Il y a 60 personnes en dessous. Tous les jours, à 18h, ils ont un daily meeting pour savoir ce qui se passe au niveau de... En fait, c'est une application qui est en dessous. Donc là, en gros, c'est quoi? C'est transparent, c'est problème, ça regoutte. C'est au moins de savoir ce qui se passe. Donc là souvent c'est un des trucs qui n'est pas si facile que ça. Ça sert à quoi le vis-à-vis de management pour nous? Donc donner l'état du process, diriger le manager vers là où il a besoin d'aider, et après indiquer les actions à prendre, les actions correctives qui sont en cours, et surtout montrer ce qui est normal et ce qui n'est pas normal. Et souvent, ça, c'est un des trucs qui est super dur. Parce qu'au niveau manager, si on prend des managers de managers, Par exemple, si vous consolidez tous les projets pour les mettre au niveau épique, Donc ils ont un truc super beau, ils ont un bon tableau de suivi, mais eux, ils n'ont aucune action. Donc ça ne leur sert à rien. Et en plus, si on voit le tableau, on ne sait jamais ce qui marche bien et ce qui ne marche pas bien. Donc cette notion de dire, ok, on part des équipes et puis on essaie de consolider les informations pour en faire quelque chose pour eux, ça c'est quelque chose qu'on a abandonné parce que finalement pour eux, en termes d'action, ça ne leur sert strictement à rien. Ils ne voient pas à quel endroit il faut qu'ils bougent et à quel endroit il ne faut pas qu'ils bougent. Donc là, juste pour info, le tableau que j'ai mis en photo, c'est issu d'une transformation Lean Management qui a eu lieu avant. J'en parle un peu parce que c'est une des contraintes. qu'on a chez nous, elle est jour de la semaine, personne par personne. Donc là, nous, on a dû partir de ça. Donc la notion, je veux voir ce que fait chaque personne et être sûr que tout le monde est occupé à 100%, c'est là un peu d'où on part. Ça a touché, je ne sais plus, je crois, 70% du périmètre. Donc dans le mindset, nous, on a ça à prendre en compte.
Bon, là ce que je dis, quand il s'arrive à ce niveau-là, déjà ce qui est pas mal, c'est qu'ils partagent. Au moins on demande à un manager qu'est-ce que fait le manager à côté, il est capable de le dire parce que sur un tableau il y a tout, et chacun en parle et il voit ce que font les autres. Donc en gros moi j'appelle ça« je sais ce que mes collègues font».
En modèle, donc là j'ai parlé d'Obeya, donc là il y a des équipes qui ont des choses comme ça, donc avec qu'est-ce qu'on doit faire, où est-ce qu'on en est, qu'est-ce qu'on a expérimenté, qu'est-ce qu'on a décidé de propager à l'extérieur. Donc là on voit arriver quoi? On voit quand même que les objectifs individuels ils changent, on voit apparaître donc des KPI qui sont moins au niveau des équipes ou des budgets, des choses comme ça, mais plus au niveau du projet, faire que le projet réussisse un peu, et on voit vraiment souvent des objectifs apparaître de partage de connaissances. Bon, celui-là, il est toujours un peu casse-gueule, l'objectif par tête de connaissance, parce que qu'est-ce que ça veut dire un objectif réussi, qu'est-ce que c'est un objectif pas réussi, c'est pas toujours très facile. Donc l'analogie que je fais, moi c'est one project, one team. Au niveau du modèle, on voit qu'il y a un manager qui est au centre et qui discute avec les autres, mais on voit que j'ai mis des pointillés qui commencent à discuter sur le côté. Alors que l'ancien modèle, c'est vraiment, je ne discute pas à côté parce que finalement ça ne sert pas à grand chose.
Donc là, les équipes qui passent à ça au niveau management, moi je trouve que c'est déjà un bon début. Au moins, ils commencent à discuter entre eux, ils commencent à partager. Après, est-ce qu'on peut aller plus loin? Ouais. Pourquoi? Globalement, qu'est-ce qu'on voit sur par exemple l'équipe de dev 860? C'est les managers qui arrivent et ils prennent un post-it, puis ils le foutent en plein milieu du tableau. Au fait, il y a ça. Et donc au niveau anticipation, priorisation, il n'y a rien. C'est vraiment, on découvre ce que font les autres. Il n'y a absolument aucune gestion de qu'est-ce qu'on doit faire de manière globale. Et il n'y a pas non plus d'entraide. C'est vraiment chaque personne arrive, il n'y a pas d'assigne. On découvre. Et ça reste souvent une vue organisée projet. Ils ont tendance à faire ça au niveau des lignes. Il n'y a plus des personnes, il y a des projets. Et ça reste quand même pour moi des vues de silo. Bon, c'est déjà pas mal, ils commencent à partager. Mais on se rend compte souvent qu'il y en a un qui est débordé, l'autre ça va. Et vraiment les trucs, ils arrivent en plein milieu. Ce qui fait qu'il y a des initiatives qui avancent et d'autres qui n'avancent pas. Et ce n'est pas nécessairement l'initiative la plus importante au niveau des managers qui avance.
Donc là, voilà.
Au bout de quelques temps, je suis arrivé au sujet principal. Mais pour moi, il fallait montrer comment on y était arrivé. Parce que je ne pense pas qu'on puisse passer directement du stade 1 au stade 3. Et puis, je vais encore parler d'un stade 4. À mon avis, c'est un peu plus progressif que ça. Donc Kanban pour manager c'est quoi? C'est vraiment, là ils ont commencé à se dire ok il faudrait peut-être quand même qu'on pilote ce qu'on met dedans. Donc on a commencé à voir apparaître sur la gauche des produits backlog. C'est ça qui a vachement changé les choses. Donc c'est vraiment qu'est-ce que nous l'équipe de manager on veut faire, c'est quoi notre objectif. Donc là on voit vraiment arriver sur les objectifs de l'équipe. Par contre, moi je parle d'objectifs et d'initiatives, je ne parle pas de projets. Parce que les projets finalement ce n'est pas si important que ça. Ce qui est important c'est qu'est-ce que eux les managers vont devoir faire. Il y a à peu près 75% de leur activité qui n'est pas du projet.
Il y a un nouveau plan RH, il y a des choses comme ça. Et là c'est vraiment commencer à se répartir de manière globale tout ce que l'équipe doit faire. Essayer de limiter le multitasking. Donc là j'ai mis un petit chiffre sur une progress. Et vraiment faire une répartition au niveau de tout le monde. Et après, Matrix. Donc le CFD, j'ai vu personne finalement l'utiliser pour l'instant. Le Control Chart, par contre, il l'utilise vraiment. Au niveau des... Je crois que je vais en parler juste un peu après. Au niveau du workflow, là j'ai mis In Progress. Il y en a qui ont mis des choses plus compliquées. Il faut savoir que ce qu'ils ont, ce n'est pas un process de dev. Donc le process, il est en général beaucoup plus basique parce qu'il est très très hétérogène.
Donc là, on a vraiment quoi? On a vraiment les managers qui sont responsabilisés sur les objectifs de l'équipe. On a vraiment plus un system thinking, justement, pas des trucs qui avancent et d'autres moins vite, on ne sait pas trop bien pourquoi. Et vraiment, on commence à avoir une création d'esprit d'équipe. Vraiment, les managers, ils sont entre eux, c'est une équipe. Ce n'est pas chaque manager est dans son coin, il veut essayer de prendre la place du manager d'à côté en étant meilleur de son côté. C'est aussi ça qu'on cherche.
Bon, là j'essaye de faire juste un petit zoom pour dire pourquoi j'appelle ça du Kanban et pourquoi je n'appelle pas ça du Visible Management. Uh, On a vraiment une notion de backlog, gestion de la demande, priorisation. Donc ça, c'est clairement pour moi la grosse différence entre le stade d'avant et ce stade-là, c'est le fait qu'on priorise. C'est qu'il faut avoir des backlogs qui arrivent sur le côté, un tableau, et pas les trucs qui arrivent n'importe comment.
Après, je dis quoi? Full down colonne. Alors ça, c'est assez marrant parce que finalement, sur les Kanban classiques côté dev, la colonne down, elle se vide toute seule. Dès que ça part en prod, la colonne down, elle se vide. Mais sur les managers, ils n'ont pas de relise. Et là, j'ai vu plein de tableaux où tu arrives, la colonne donne, elle est complètement pleine. Donc là, souvent, ce que ça donne comme indice, c'est que deux, il n'y a pas de cadence. Donc il n'y a pas de cadence. Souvent, on voit qu'il y a du mal à avoir une cadence d'entrée, mais aussi une cadence de sortie. Et là, c'est aussi un indice sur le fait qu'il n'y a pas beaucoup d'améliorations continues chez eux. Parce que souvent la colonne donne, on la vide quand? On la vide quand on fait de l'amélioration continue, quand on regarde ce qui s'est passé depuis la dernière fois. Quand la colonne est pleine, il y a de grandes chances pour que les séances d'amélioration continue, elles sont...
Cost of delay, donc la soft service, en général, on n'en voit pas trop. On en voit trois. expédite, donc tout ce qui est urgence. Donc là souvent on voit quasiment tout le temps une ligne en haut pour gérer les urgences. Et après ils ont pas mal tâtonné mais quasiment tous ils arrivent à la même conclusion, c'est qu'ils ont les actions à faire eux, c'est-à-dire moi manager j'ai quelque chose à faire parce qu'on me le demande, puis j'ai les actions de suivi, donc suivi des autres qui sont en dessous. Et finalement on se rend compte que les délais et les demandes c'est pas du du tout la même fréquence. Donc souvent, dans les tableaux, il y a trois swim lanes. Expedite pour les urgences, standard, et après follow, donc c'est eux qui suivent les équipes en dessous.
Oui, ça c'est clair. Au début, urgence, tout est urgent.
Ce qui est super marrant, c'est que, surtout sur la première, qui est pour moi d'ailleurs une des plus matures, Donc ils ont mis en place l'urgence et puis ils se sont donné un peu des délais, de dire une sorte de petit SLA qu'ils se sont donné entre eux. Ok, une urgence, ça ne doit pas rester plus de deux jours, et une standard, ça ne doit pas rester plus de cinq jours. Eux, c'est une équipe qui vraiment, tous les deux semaines, ils font bien de l'amélioration continue pour savoir ce qui s'est passé. Ils se sont rendus compte qu'il y avait des trucs dans l'urgence qui étaient là, je ne sais pas, il y en avait un qui avait mis deux semaines, je crois, un truc comme ça.
C'est vraiment une urgence ce truc-là. Et donc eux, ils se sont mis à faire ce qu'on appelle la varicelle. Tous les jours, ils mettent un point sur chaque post-it. Ils se sont rendus compte qu'il y avait des trucs qui traînaient en urgence, qu'on n'était pas. Donc dès qu'il y avait trop de points, finalement, ils disaient s'il y avait urgence ou pas, ils ont commencé à redescendre. C'est le fait de mettre les points qui les a pas mal aidés là-dessus. Ils ont aussi fait la technique de mettre des points de couleurs différents en fonction de la colonne. Et ils ont pu voir dans quelle colonne ils passaient du temps. Je crois que je l'ai mis juste après le leur.
Work in progress.
Donc, se focusser sur le flow plutôt que sur la partie...
occupation des gens, ça a super bien marché côté dev, parce que ça pour un fond on l'a fait côté dev et côté ops, vraiment les devs ils se sont mis dans la tête non faut essayer de pas avoir trop de choses pour être performant,
donc ça ça a plutôt bien passé, par contre côté tout ce qui est prod, pour eux c'est un peu plus je commence plus je finis, donc là il y a vraiment une notion de j'arrête d'accumuler qui est super dur, et là clairement on galère un peu à leur faire comprendre que le multitasking ça a quand même des effets pervers. Donc ça, on essaye. Ça marche très bien côté dev, ça marche moins bien côté ops. Continuous Improvement, c'est un peu pareil. Ça marche très bien côté dev, ça marche pas trop côté ops. Côté ops, ils n'ont pas la culture de dire« Ok, j'essaie de m'améliorer tous les mois, tous les 2-3 semaines. » Et sur aucune équipe, j'ai pu avoir de la disponibilité pour qu'on ait le temps de les former un peu, leur expliquer un peu les concepts, leur montrer, ou je ne sais pas, faire des jeux.
Pas au niveau manager quand même.
Non.
Bon après, juste pour info côté Ops, au début quand je suis arrivé, les seuls indicateurs qui se faisaient c'était in, out et stock. Et jamais le temps de réponse. Je les avais quand même un peu charriés là-dessus en disant c'est marrant vous êtes des Ops mais vous n'avez aucune idée du temps de réponse que vous avez. Et donc eux c'était plus leurs indicateurs sur les équipes en bas, c'est uniquement sur le stock. In, out et stock. Pas sur le temps de réponse.
Oui, quasiment tous, c'est des managers ici du terrain.
Oui, c'est clair, ils ont la culture Ops.
C'est côté Ops, par contre, que ça s'est le plus déployé, Canman pour Manager, de notre côté.
Donc après, par contre, sur les cinq que j'ai un peu suivi et aidé, je n'ai jamais réussi à avoir une heure pour les former, leur expliquer quelques concepts. On a juste pu améliorer à chaque fois en allant avec eux, en assistant à leurs meetings, en essayant de les faire évoluer au fur et à mesure. Donc ça évolue lentement, moi, je trouve, en partie parce qu'ils ne se donnent pas les moyens d'aller plus vite. Donc les workflows, comme je disais, ils sont basiques. J'en ai vu qu'on fait, c'est quasiment que les ops qui font ça. Eux, ils ont une progress de 0 à 100%. Et en gros, ils ont fait une colonne assez large et ils font bouger l'action à l'intérieur de ça. Bon, c'est un peu basique, mais... Ça leur allait. Moi là-dessus, je leur dis c'est un peu leur process, faites ce que vous voulez. Pareil hier, chacun s'attribue son tableau, c'est responsabilisé.
Moi ça je les laisse. Alors après ce qui était assez marrant, c'est arrivé aussi côté OPS, c'est le DON. Que faire du DON? À un moment ils ont dit ok le DON, ce qu'il faudra quand même qu'on sache c'est qu'est-ce qu'il y a des success pour être capable de les marketer et qu'est-ce qu'il y a des achievements. Donc ils ont commencé à faire ce split sur la colonne DON entre success et achievement. Bon ça, pour moi c'est un peu la culture manager, c'est qu'est-ce qu'on va être capable de marketer. Donc ça leur a servi à ça, essayer de voir de manière globale au niveau de leur équipe qu'est-ce qu'ils allaient pouvoir marketer vers le haut. Oui, c'est leur culture. Mais voilà, c'est assez marrant.
Et par contre, ce qu'on a vu, et moi qui m'a fait super plaisir, c'est qu'on a commencé à faire sauter la vision swimline, c'est les personnes. Et certains ont fait des swimlines, pas tant que ça en fonction des classes de service, mais en fonction des objectifs de leur équipe.
Ce n'est même pas de leur équipe, c'est côté OPS. Ils ont des objectifs globaux sur toute l'année, qualité de service, des choses comme ça. Et en fait, leur colonne, c'est ça. Et ça leur permet de voir par rapport aux objectifs qui leur ont été donnés sur toute l'année, est-ce qu'ils avancent sur tous les thèmes.
Et la partie mesure, le cycle time, ça parle super bien aux ops. Donc c'est eux qui ont tiré ça. Même si à la base, ils ne l'utilisaient pas. Par contre, quand je leur ai demandé pourquoi vous ne l'utilisez pas, ça me paraît un peu débile. Ça leur a vraiment bien parlé. Pour info, pourquoi ils ne s'en occupaient pas, c'est parce que les quelques années d'avant, on a eu beaucoup de problèmes de prod. Alors ils m'ont un peu dit, notre priorité, c'était les incidents majeurs. Et on va dire le flux, c'était moins la priorité.
Bon, succès, sort, faille, alors par contre là-dessus j'ai aussi essayé de leur ajouter quelque chose, donc du Lean Startup, pour leur dire au fait, vos initiatives, à chaque fois vous voulez qu'elles finissent, mais c'est normal qu'il y en ait qui s'arrêtent. Donc essayer en plus en même temps de parler d'initiatives et de dire que des initiatives c'est normal que ça s'arrête. Donc là j'ai commencé aussi en plus à essayer de, on va dire... Impulser quelques petits messages subliminaux. Vous pouvez changer, vous aussi. Pour l'instant, ça commence à venir. Le fait de parler d'initiatives, on commence à pouvoir discuter de ça. Parce qu'avant, ce n'était même pas possible.
Moi, j'appelle ça niveau 3,« We think together». Donc en gros, on pense ensemble. Mais je suis passé trop vite.
Le modèle, c'est un peu ça. Le tableau que j'ai mis, là, on a du mal à voir. Mais celui-là, par exemple, ils l'ont fait un peu plus détaillé que juste« To do in progress zone». Eux, ils avaient, par exemple,« Analyse»,« Mise en place» et« Review», je crois, un truc comme ça. Et en gros, pourquoi ils ont fait ça? Parce qu'à l'analyse, souvent, ils avaient un post-it. Et c'était un moment où ils font l'analyse et qu'ils ont découpé les post-its en plusieurs morceaux. On ne le voit pas bien ici, mais... Si vous regardez les slides que j'ai mis en ligne, on le voit mieux. Eux, ils ont carrément des limites par colonne. Et ils ont l'expédite en haut, ça c'est ce qu'ils suivent au milieu, et ce qui est en bas, c'est ce qu'eux suivent.
Certains utilisent des avatars, mais tout le monde ne le fait pas, pour savoir qui bosse sur quoi. Donc là, les objectifs individuels, finalement, on ne retrouve pas trop d'objectifs individuels. On retrouve plus des objectifs d'équipe dans les objectifs. Ce qu'on dit, c'est qu'on remonte d'un cran les objectifs. Au lieu de donner des objectifs par personne, on ne donne vraiment que les objectifs de l'équipe. Et ça tire quand même aussi le continuous improvement. Vous êtes capable de dire dans les objectifs, vous devez vous améliorer. Donc ça c'est assez sympa et vraiment on voit que les gens commencent à bosser avec les autres. Pour le premier, pour info, quand je suis allé les voir, j'ai assisté à un daily meeting, ils étaient cinq. Je ne connaissais que deux personnes dans l'équipe. Et à la fin du meeting, je ne savais même pas qui était le chef. Et je l'ai appris après lequel des cinq était le responsable au-dessus de tout le monde. Il y en avait un, il y en avait quatre autres en dessous. Et c'est qu'après qu'on m'a dit au fait c'est lui le responsable. La façon dont c'était animé et que ça tournait, je ne me suis même pas rendu compte du responsable. C'est pour ça que je fais une analogie avec les équipes agiles. C'est vraiment, on a vu apparaître des auto-organisés, responsabilisés, ils sont comités sur les objectifs de l'équipe.
Bon là, je ne vais pas passer longtemps sur ce slide, juste pour dire qu'on est pas mal influencés, c'est une pub, par tout ce qui est tribal leadership. Essayer de faire que les gens collaborent ensemble, ils arrêtent de faire de la concurrence, ils essaient d'être performants. C'est vraiment, on est sur tout ça, sur Canman pour Manager, on est beaucoup influencés par tribal leadership. Essayer de faire des triades, de faire se rencontrer.
C'est un des bouquins qui nous a super inspiré pour ça. Bon, est-ce qu'on peut faire mieux? Ouais, pour moi on peut encore, parce que c'est pas parce qu'on bosse avec quelqu'un d'autre qu'on bosse vraiment ensemble. Ils se sont rendus compte sur la première équipe qu'à un moment il y en avait un des leurs qui a eu beaucoup de problèmes, c'était surtout sur ses équipes en dessous, Les autres, ils savaient qu'il avait un problème et finalement, il ne s'est rien passé. Parce que c'était son équipe un peu, puis il n'y avait pas d'initiative sur cette partie-là. Et après, ça leur a fait quand même tilter en disant, OK, on bosse avec les autres, on attribue de manière globale tout ce qu'on doit faire, mais est-ce qu'on bosse vraiment ensemble? Donc là, ils se sont rendus compte que ce n'était pas si vrai que ça. Donc là, pair work. Donc en gros, ils se sont mis à dire, ok, on pourrait faire comme le pair programming, et on va essayer de bosser ensemble. Donc en gros, ils se sont mis à se dire, ok, sur certaines initiatives, on va vraiment bosser à deux. C'est pas une personne qui va prendre l'initiative, qui va la faire, qui va reporter, puis on a ce signe de manière globale, c'est vraiment, on va bosser ensemble. Donc là, on a vu apparaître, donc il n'y en a qu'une pour moi qui est vraiment à ce niveau-là, sur les équipes de managers. Il y a une équipe qui commence vraiment à faire du pair work entre managers. Ce qu'ils font souvent, c'est sur une initiative, ils se mettent vraiment à bosser à deux. Et pas, il serait parti s'il y en a une qui le prend. Et après, surtout sur ce périmètre-là, où ils vont le plus loin, ils ont aussi commencé à faire, sur ce périmètre-là, des communautés, des dryades. Tous ceux qui connaissent Spotify connaissent ce schéma. Donc en gros, on essaye, mais pour l'instant, c'est super dur. C'est super dur. Pourquoi? En partie, on a des discussions là-dessus. C'est que la culture du don, elle n'est pas ancrée chez nous. C'est parce que quand même, quand on est dans des communautés, on fait un don aux autres. Est-ce qu'on a un retour direct? Pas trop.
Donc des communautés, on en a lancé. Des communautés qui marchent, qui sont gérées. Pour l'instant, ça, c'est un peu... Casser la gueule. Je pense que tant qu'on ne changera pas le fait qu'il faut être capable de donner aux autres, qu'au niveau des objectifs des gens, on est beaucoup plus objectif d'équipe, je pense qu'on ne s'en sortira pas tout de suite. Donc là, pour nous, on sait qu'on a ça dans la boîte à outils, les communautés, pour essayer de développer les gens encore. Mais pour l'instant, ça ne prend pas trop. Pour ne pas dire, ça ne prend pas.
Bon, alors moi j'appelle ça« you work together».
Et donc dans le modèle, l'Obeya pour moi, c'est vraiment la chaise double. Bon, il n'y en a pas des chaises comme ça, j'en ai pas trouvé sur le marché.
Après, au niveau des objectifs, moi j'avoue que de plus en plus, je suis contre les objectifs SMART. Est-ce que vous savez ce que c'est SMART?
Donc spécifique, la dernière fois je ne me souvenais même plus de toutes les lettres, spécifique, mesurable, dans le temps et atteignable. Moi plus ça va, plus je suis contre les objectifs SMART, parce que finalement on a tendance à avoir un objectif, il est SMART, super précis, et qu'est-ce qu'ils vont faire les gens? On va essayer d'avoir l'indicateur. On va voir le comportement qu'on mesure. Et de plus en plus, je trouve que ça influe tellement les comportements, l'objectif, que je suis pour arrêter de mettre des objectifs smart. Et après, on va arriver à des objectifs vraiment d'équipe et les 360 degrés. Quand on évalue le manager, on fait un 360 degrés. Ça, pour l'instant, ça commence à pointer le nez, mais on n'y est quand même pas encore. Après voilà, on a ça en tête. Pourquoi j'ai fait un modèle? C'est aussi un peu pour leur donner. Ils me demandaient vers où on peut aller, qu'est-ce qu'on peut faire. C'est pour essayer de leur présenter ça, de dire, ben voilà, vous pouvez aller jusque-là. Souvent, j'appelle ça, moi, ouvrir les chakras. Alors montrer ce qui est possible, puis après, à eux de voir.
Bon alors, et après la suite?
C'est bon, j'aurai le temps pour prendre trois questions. Waouh, ça c'est super joli! Ça c'est notre modèle actuel, c'est encore un autre modèle. Pourquoi on a fait ce modèle-là? 40% d'agile dans deux ans, pour nous, on appelle ça la first star. En gros, le minimum vital sur l'agilité. Là, je l'appelle ça 12 le sing right. En gros, qu'est-ce qu'on met derrière? On met être capable de livrer la feature, être capable de collaborer avec son client et être capable de faire du people empowerment. Donc ça, c'est le niveau 1. Pour nous, on est arrivé là.
Pourquoi on a fait ça, au fait, pour info? C'est parce qu'en gros, les managers en haut, dont je parlais un peu avant, ils se sont rendus compte qu'ils avaient leur 40%, donc en gros, l'agilité, ils ont fait« Ok, c'est derrière! » Donc en gros, la pression a complètement arrêté. L'objectif était atteint, pas de problème. Donc ça, c'est le prochain objectif. Et donc notre nouvel objectif pour dans deux ans, c'est ça, continuer de délivrer of value.
Sachant que c'était quand même un peu un slogan marketing. Et après, il a fallu qu'on définisse ce qu'on mettait derrière. Donc ce qu'on met derrière, voilà, do the thing right, client collaboration, deliver feature, people empowerment, do the right thing, qui est le niveau d'après, nous on l'a mis après, après voilà, c'est en fonction des entreprises, vous faites ce que vous voulez, do the right thing, on met quoi? Value, je dis de la valeur, et pas juste de la feature, et après stability, donc stability c'est, il y a pas mal de pratiques de dev sur du code, automatisation des tests fonctionnels, des choses comme ça, et on met aussi de la stabilité sur la connaissance, knowledge sharing, toutes les choses comme ça, être capable de gérer correctement le turnover.
Et... Donc ça, c'est notre niveau 2. Ça ne va pas être facile parce qu'au niveau valeur, côté métier, on a quand même un peu de mal. C'est pour ça que j'étais au super workshop avec Don Reinerson ces derniers jours. Après, do it fast. Alors, do it fast. Et après, en gros, ici, c'est j'accélère. Donc, toutes les pratiques DevOps, je collabore avec les Ops. Et il va y avoir un phrase code du cloud. Beaucoup de pratiques de Dev à ce niveau-là. Et on commence aussi à faire du scaled. Parce que le niveau d'après, continue to deliver value, c'est vraiment du scaled. C'est-à-dire en étant, et on dit qu'on délivre vraiment de la valeur, qu'on délivre de la valeur sur la chaîne. Donc là, on attaque aussi tout ce qui est Agile Portfolio, qu'on attaque déjà à Do It Fast. Qu'est-ce qu'on met derrière? C'est être capable de faire le bon projet, même si de plus en plus, moi je pense qu'un projet, ça n'a pas de sens, et qu'il faudrait regarder des minimums. Marketable release. à l'intérieur d'un projet, regarder lesquels ont du sens et pas au niveau projet global parce que ça se trouve il n'y a que 50% du projet qui sert à faire 90% de valeur et le reste on ne devrait pas le faire. Donc on commence à aborder ça et on veut faire à terme aussi du dynamic staffing. Alors ça, ça va être vachement plus compliqué, c'est-à-dire qu'il n'y aura plus de projet sur trois ans. Tous les projets seront saucissonnés en petits blocs de trois, quatre mois. Et tous les trois, quatre mois, on se reposera la question, est-ce qu'il reste assez de valeur, est-ce que c'est intéressant, est-ce que je ne vais pas sur un autre? Pour l'instant, ce qu'on y est un peu, c'est qu'on va découper tous les projets en trois mois, on ne va pas donner tout le budget d'un coup. On se reposera la question assez souvent des priorités, mais par contre, réallouer le staff, dynamiquement d'un projet à l'autre, ça c'est au niveau 4. Donc ça c'est ce qu'on doit faire pendant deux ans. Donc c'est un gros chantier. Pour l'instant, pour moi, on a 90% des équipes qui sont au niveau 1. Des équipes qui sont au niveau 2, il y en a quelques-unes, et il y en a même au niveau 3. Il y en a une ou deux qui traînent. Mais en gros, voilà. Et là-dessus, pour moi, on n'y arrivera pas si les managers, on va dire, ils ne changent pas un peu de... De façon de voir sur certaines choses. Donc c'est ce qu'on va proposer pour aider à aller au niveau 4. Maintenant, on n'est plus dans le stade, on a découvert une pratique, un outil, un man pour manager. Là maintenant, on va essayer de le proposer dans certains cas quand on pense que c'est intéressant.
Mon niveau 5, j'en parle pas trop pour l'instant, on sait même pas ce que c'est. On l'a mis parce qu'il fallait un peu un niveau 5. Mais si vous me demandez ce qu'il y a derrière, actuellement, il n'y a un peu rien. Il y a juste le titre. Donc voilà, ça c'est l'avenir pour nous. Dans deux ans, on veut être, pas toutes les équipes, mais une bonne partie des équipes au niveau 4. Juste pour info, tout ce qui est de la compta, des choses comme ça, avoir toute l'infrastructure nécessaire pour délivrer en prod feature par feature, on trouve que ça n'a pas de sens, ça n'apporte pas de valeur. Donc on ira vers ça que pour les applis où ça a du sens, celles qui sont très proches du front finalement, et celles qui sont bien organisées pour être capables de le faire. On ne veut pas livrer en... C'est vraiment qu'on continue de délivrer of value et pas qu'on continue de délivrer tout court. On met pas mal d'importance là-dessus pour dire, ok, c'est pas juste je vais en prod et je délivre n'importe quoi, c'est de la valeur.
Donc voilà.

Transcription