Yannick Quenec'hdu

Je me présente, je m'appelle Yannick Hennegueddu, comme mon nom l'a dit que je suis breton.
Une petite histoire, en 2011, je commençais un projet à la DCNS, un projet de sous-marin nucléaire. Initialement, mon acolyte a été appelé pour lui demander si on avait une solution sur un projet qui ne fonctionnait pas, qui était en méthode en V. Et on nous a demandé de venir. Je n'avais pas beaucoup d'expérience au Kanban. J'avais un peu lu et je me suis dit que Scrum ne serait pas adapté vu le contexte. Et on a fait notre première expérience sur Kanban. A la suite de ça, j'ai fait une présentation au Scrum Day en 2011. Je suivais un peu ce qui se faisait sur Twitter à ce moment-là. J'avais eu beaucoup de remarques sur des gens qui disaient que... Parce qu'on avait mis en avant ce qu'on appelle la prédictibilité. Et il y a beaucoup de gens qui disaient que c'était un peu idéaliste, c'était même une technique d'apprenti sorcier. Donc depuis 2011, j'essaye de construire une offre autour d'une vague d'accompagnement qui pourrait mettre en place la prédictibilité et montrer que ça fonctionne. Donc depuis deux ans, on travaille essentiellement là-dessus. A la suite de la DCNS, je suis parti à Varsovie travailler pour LVMH, pour mettre ça en place. Et j'ai rejoint il y a un an la société Xebia pour les aider à construire une offre autour de Canban. Et c'est un peu ce que je vais vous présenter à travers ça, c'est comment on a construit en fin de compte ce que nous on appelle une vague, c'est la capacité à monter une équipe pour qu'elle devienne auto-organisée autour des méthodes Kanban. En complément, pour satisfaire en fin de compte les métiers et la direction, nous avons travaillé sur les indicateurs et la prédictibilité. Et c'est un retour d'expérience en fin de compte sur cette vague que je vais vous présenter.
Donc le contexte initialement, c'est une transformation agile avec une orientation Kanban sous une vague d'accompagnement en 8 semaines. On s'est dit, enfin même on arrive maintenant à peu près à la raccourcir, en 6 à 8 semaines on arrive à prendre une équipe, une petite équipe, c'est souvent une dizaine de personnes, et on la passe en Kanban. Dans ce cadre-là, c'est pour vous donner une image à peu près de ce qu'on est en train de faire. On a mis en place un pilote en 2013 avec un très grand client, numéro 1 mondial de l'assurance, et on a commencé sur deux projets. Donc une trentaine de personnes, ça a très bien fonctionné, le pilote a eu un buzz positif à l'intérieur, et à ce moment-là on est parti sur une phase d'initialisation sur laquelle on travaille actuellement avec cinq coachs. Et on transforme en temps réel 10 projets. C'est à peu près une centaine de personnes. Et ensuite, on a pour focus de passer 80 autres projets vers cette méthode, à peu près 400 à 500 personnes. En complément de ça, il y a ce buzz et même sortie de ce client, et il y a plusieurs autres entreprises, dont des noms célèbres de l'Internet, qui sont intéressés, des noms français qui sont très intéressés, et on commence à faire avec eux des pilotes.
Dans le cadre de ce projet, on a mis une limite. pour commencer parce qu'on ne pouvait pas emmener l'ensemble, sachant que notre périmètre à la fin 2014 est de faire ce qu'on appelle le DevOps, c'est-à-dire de partir de l'idée jusqu'à construire l'ensemble du process en méthode Kanban.
On a limité notre approche autour d'une stratégie en trois axes, qui sont 1. Et la première, pourquoi on a été appelé chez ce client, c'est ce qu'on appelle la satisfaction métier. Le métier était un peu mécontent, à la fois des méthodes, on va dire, en V, et des méthodes Scrum qui ont été mises en place, parce qu'il avait du mal à voir où on allait. Il avait du mal à avoir la vision du produit et de respecter les échéances. Donc on a travaillé sur ce sujet. Un autre qui était améliorer la qualité, puisqu'il y a un nombre d'anomalies très importantes et une dette technique importante, qui évidemment impacte sur tenir ses promesses, qui est le dernier point. Tenir ses promesses, en fin de compte, initialement, c'est ce que voulait notre client, c'est comment on peut montrer qu'on peut respecter à peu près nos délais. Bon, vous allez voir, ce n'est pas magique, mais on a réussi à répondre, en tout cas à leurs besoins, grâce à la prédictibilité.
Donc comment on a construit ça? En fin de compte, on a vite compris, et puis tous ceux qui font un peu de l'agilité ont compris que le cœur même central de la pratique est autour de la user story. Si une user story est de qualité, on aura souvent un produit de qualité. Donc la user story, elle part de l'idée jusqu'à la fin quasiment du projet, elle suit tout le cycle de vie. Donc on s'est dit, on va l'améliorer. Ensuite, pour faire de la prédictibilité, il faut maintenir, il faut maîtriser la taille de cette user story, pour éviter qu'il y ait des user stories qui font 10 jours de travail et d'autres 1. Donc on essaye de maintenir à peu près la granularité. Comment on a mis ça en place? Initialement, au niveau de l'idée, on a travaillé avec le métier ou les sponsors sur trois approches différentes. Une qui s'appelle le Lean Startup, que vous connaissez tous je pense, puisqu'il y a eu une présentation hier par deux de mes acolytes. Une autre qui s'appelle la Frigol Innovation, qui est un peu peut-être nouveau pour certains. La Frigol Innovation, c'est quelque chose qui est apparu en Inde et au Brésil, et qui est par exemple le résultat en France de la voiture, la Daxia. C'est comment faire mieux avec moins d'argent, tout simplement. Et une autre technique classique que vous connaissez aussi dans les méthodes Scrum, ce qu'on appelle le Sprint Zero, donc vision produit. En relation avec le type de projet qu'on va accompagner, on va mettre en place trois types d'approches. Cette première approche va nous permettre de sortir les fonctionnalités de base que vous connaissez. On va faire ce qu'on appelle un story mapping. A partir de ce story mapping, on va construire ce qu'on appelle une customer experience mapping, c'est-à-dire une cinématique de l'utilisateur. Cette cinématique va nous permettre de créer ensuite ce qu'on appelle les MMF, Minimum Marketable Future, c'est-à-dire ce qu'a besoin le client dans la première phase pour construire son produit.
Et ça, ça nous permet déjà de fournir ce que nous on appelle notre premier indicateur, c'est le nombre de user stories par MMF. Notre objectif aussi est de le maîtriser. On a actuellement par exemple des MMF qui font 2 user stories et d'autres qui en font 34. Donc on essaye de maîtriser parce que la MMF, en fin de compte pour nous, c'est la démo. A la différence des méthodes Scrum classiques où on s'arrête à la fin d'une itération, dans notre cadre, on est en flottant. On fait des démos flottantes et il faut le métier, surtout chez ce type de grand client, à peu de disponibilité et il faut prévoir, donc être prédictible sur la date. En relation avec un autre indicateur qu'on verra tout à l'heure, qu'on appelle le cycle time, on arrive à donner des mots qui sont à peu près prédictifs à 2 ou 3% près. A partir de ce constat, on va commencer à travailler avec l'équipe du Product Owner. Donc on va prendre une première MMF et on va construire avec lui ce qu'on appelle son backlog de produits. Donc son backlog de produits, initialement, j'ai mis trois phrases parce qu'on a mis en place une technique qui est assez rapide à mettre en œuvre. Donc les coachs arrivent et imposent une pratique. Pourquoi on impose cette pratique? Parce qu'on souhaite que les user stories soient construites d'une façon particulière pour améliorer la granularité et diminuer les anomalies.
Donc on impose des limites, on a pris un simple fait pour les limites, et la même chose pour les règles de passage. Néanmoins, selon l'expérience des équipes, puisque chez ce client on a des gens qui ont déjà une très bonne connaissance des pratiques Scrum, une très bonne connaissance de Kanban, On adapte avec eux. Mais dans l'ensemble, comme vous l'avez vu, on travaille sur un périmètre d'à peu près 400 personnes. Donc on ne peut pas laisser, en tout cas, puisque notre objectif c'est avant tout de rendre... On va dire de... Comment dirais-je... D'industrialiser en fin de compte Kanban chez ce client. Donc tout le monde travaille à peu près de la même façon, tout le monde est le même langage. Donc au départ on est obligé d'imposer une méthode. Et ensuite on fera ce qu'on appelle le PDCA, c'est-à-dire qu'ils vont adapter. Donc maintenant sur les premiers pilotes par exemple, les Kanban ont commencé à être modifiés parce que les gens commençaient à maîtriser leur user story. Donc on a des Kanban beaucoup plus petits.
Donc comment ça fonctionne?
On a mis en place une maîtrise de la qualité des user stories. Donc pour la première chose, on a un product owner qui va travailler sur ce qu'on a orienté nos user stories vers ce qu'on appelle le cas de test en méthode BDD, BA World Wide Web Development, je vous montrerai un exemple tout à l'heure. Donc le travail du Product Owner, c'est d'identifier déjà avec le métier son besoin. À partir du MMF, on le prend, on écrit le scénario orienté comportement. Dès que le premier comportement nominal a été créé, automatiquement, il est adressé à un testeur. Ce testeur qui agira directement avec l'équipe de développement. Ce testeur va rajouter directement les 4 tests dans la User Story en format BDD. Ensuite, une personne de l'équipe technique, une ou plusieurs, c'est selon le choix des équipes, vont interagir directement sur la user. pour ajouter les éléments techniques si nécessaire. Puisqu'on a retiré la notion de user story technique, on essaie de la rendre fonctionnelle pour montrer au métier qu'elle a une vraie valeur. Pour donner un exemple, au début de nos projets, quand on a commencé, on avait beaucoup d'équipes de développement qui disparaissaient pendant deux ou trois semaines dans les premiers sprints pour faire des éléments techniques et personne ne savait où ils étaient réellement par rapport aux attentes du métier. Ils ne produisaient pas de valeur pour le métier. Donc pour éviter justement cette image un peu négative et tout ce retour, on a décidé de les intégrer directement dans la création de la user story. En complément, et de façon transverse si c'est nécessaire, on intègre aussi l'ergonomie directement dans la user story. Donc on essaye de trouver, comme on le fait initialement dans le BDD, d'où il vient, ce qu'il est en train de faire et où il va dans la wireframe qui va être faite. Donc à partir de là, on va avoir un deuxième indicateur qui est ce qu'on appelle le cycle time, donc le temps de cycle pour réaliser une user story au niveau du PO.
Je vous montre un exemple, c'est un peu abscond, d'un exemple de user story qu'on produit. Les user stories ont un format qu'on appelle le A4 et pour gérer la granularité, on limite tout simplement le nombre de scénarios. On a trois types de user stories, on a des user stories S, M et L.
En fin de compte, un scénario, c'est une ES, deux scénarios, c'est une M, et une EL, c'est trois scénarios. Parce qu'il peut y avoir des fois des scénarios différents. Par exemple, pour l'authentification, la première authentification va vous demander votre date de naissance. C'est le cas à la Française des Jeux, par exemple. Et la deuxième authentification, vous n'aurez plus à ressaisir. Donc on limite initialement comme ça, ce qui fait que la première estimation de base est réalisée. Les critères d'acceptation sont orientés un peu plus techniques, c'est-à-dire qu'on va compléter, en fin de compte, sous forme de jeu de données directement pour que les équipes de test puissent générer leur jeu de données directement dans la user story.
Et ensuite, on va rajouter les wireframes. Donc à partir de là, on a construit ce que nous on appelle un backlog de produits. Voici un exemple de backlog de produits qui est généré, donc un camban de backlog de produits qui est généré avec l'équipe de PO. Donc on a un tout doux, c'est-à-dire c'est les éléments qui sont proposés et acceptés ensuite provenant du métier. On spécifie l'user story avec le product owner. On génère les cas de test, on fait les critères d'acceptation et ensuite elles sont estimées. Il y a un dernier travail d'estimation où on va utiliser plutôt la valeur ajoutée d'un développeur au-delà de son estimation à un ou deux jours, c'est de travailler réellement sur la complexité. On a fait un travail où on dit qu'on a SML, ensuite il le regarde et avant tout, ce qui nous intéresse c'est de comprendre si elle est complexe. On l'a déjà rangé dans une des cases, SML quand elle arrive, et ensuite eux vérifient si elle est complexe ou pas et un scénario peut devenir en fin de compte un L, selon sa complexité. Ce qui nous permet à la finalité de générer des sprint planning qui durent à entre... 30 minutes au maximum, entre 15 et 30 minutes. On a permis de réduire par exemple ce genre de cérémonial. Et il y a une grande satisfaction de la part des équipes de développement. Pour vous donner une image, le premier projet qu'on a piloté, il mettait 14 heures pour faire un sprint planning. Il y a deux personnes de cette société qui pourront vous en parler. Donc, une représentation visuelle de ce camban. Voilà, donc par exemple, à quoi ça correspond? Donc là, on a utilisé, on va vous dire tout de suite, on a piqué plein de choses dans les livres de Laurent Morisot. Voilà, donc il y a un exemple, c'est ce qu'on appelle le cockpit. Beaucoup de choses sur les indicateurs. Évidemment, on n'a pas tout créé, on a repris beaucoup de choses qui ont été faites. On les a mis en œuvre et on a essayé de voir comment elles s'adaptaient. Donc une des premières choses, c'est ce qu'on appelle la vision. Donc on essaye de montrer au métier. Alors on pique des salles, on prend des salles, on prend des murs dès qu'on arrive et on s'installe partout. Donc là, par exemple, on a ce qu'on appelle la vision. Donc on va retrouver, en fin de compte, on va demander l'une des premières choses, c'est qu'on va demander à l'ensemble de l'équipe qu'elle se mette d'accord sur la vision du produit. Et on l'écrit. Et ensuite, l'objectif. Quel est l'objectif? Trois points. Quel est l'objectif de notre application? A partir de là, on va sortir ce qu'on appelle aussi les MMF, on va sortir les indicateurs, le débit, par exemple, notre débit c'est deux cadences, enfin on va mettre la cadence, le débit c'est 12 cartes par exemple, et on va mettre le premier lead time. Et ensuite vous allez voir justement ce qu'on appelle un Kanban. Voilà, donc en plus ils sont assez jolis, normalement ils sont en couleur les nôtres, celui-là il est en noir et blanc. Donc là, c'est un premier début. Donc, une fois qu'on a mis ça en place, on commence à... sortir des user stories qui sont de granularité réduite, dont on maîtrise la taille, et dont maintenant les développeurs les trouvent beaucoup plus clairs. C'est le premier retour qu'on a. Donc il y a déjà, on a eu une augmentation de la satisfaction, c'est la première chose, entre les product owners et les équipes de développement. Sachant que dans notre contexte, les équipes de développement ne sont pas sur le même site que les product owners. Donc, il y avait beaucoup, beaucoup de problématiques au niveau de la communication et tendance à rejeter la faute sur l'autre. Sur tous les projets qu'on a coachés, ce point a totalement disparu. Donc maintenant on va travailler ensuite sur ce qu'on appelle l'efficience du système, c'est-à-dire qu'on va essayer de supprimer les premiers gaspillages. Parce qu'en fait, c'est bien de faire des jolies user stories, mais si vous avez tout votre système qui ne fonctionne pas, vous avez trop d'obstacles, trop d'anomalies et d'autres choses, en fait, indépendamment de nos user stories, notre système ne fonctionne pas. Donc comment on travaille sur l'efficience du système? La première chose, c'est de travailler sur les obstacles, tout ce qui perturbe l'efficience du système. Donc les obstacles, c'est assez simple. Dès qu'on en a un, On le note sur une user story. La user story passe dans ce qu'on appelle nous un frigo, parce qu'elle est figée, donc on a fait un petit frigo et on la descend. On génère ce qu'on appelle une petite fiche Kensei. Une fiche Kensei, c'est juste une signalétique pour que tout le monde puisse comprendre. Parce qu'une chose qui m'avait frappé quand j'étais à la DCNS, c'est que tous les acteurs s'intéressent un peu à ce qui se fait. Par exemple, il y a deux jours, je viens d'accompagner une nouvelle équipe qui fait du Kanban. En fait, c'est bien de faire des jolies user stories, mais si vous avez tout votre système qui ne fonctionne pas, c'est-à-dire trop d'obstacles, trop d'anomalies et d'autres choses, en fait, indépendamment de notre user story, notre système ne fonctionne pas. Donc comment on travaille sur l'efficience du système? La première chose, c'est de travailler sur les obstacles, tout ce qui perturbe l'efficience du système. Donc les obstacles, c'est assez simple. Dès qu'on en a un, On le note sur une user story. La user story passe dans ce qu'on appelle nous un frigo, parce qu'elle est figée, donc on a fait un petit frigo et on la descend. On génère ce qu'on appelle une petite fiche Kensei. Une fiche Kensei, c'est juste une signalétique pour que tout le monde puisse comprendre. Parce qu'une chose qui m'avait frappé quand j'étais à la DCNS, c'est que tous les acteurs s'intéressent un peu à ce qui se fait. Par exemple, il y a deux jours, je viens d'accompagner une nouvelle équipe qui fait du Kanban. Et la première chose, c'est que tous les gens qui étaient autour ont commencé à venir voir ce qu'on faisait. Il y a des gens qui prenaient des photos, des gens qui posaient des questions. Donc on essaye d'avoir sur les post-it qu'on pose quelque chose que n'importe qui peut comprendre. Donc la fiche Kensei, c'est la même chose. Souvent, quand je passe dans des cambans où il y a des obstacles, on voit« problème de prod» de tirer GW. Je l'ai vu il n'y a pas très longtemps encore. Donc nous, on a décidé de mettre une fiche Kensei pour que ça soit plus clair. Le titre, la cause, comment on l'a résolu, à quelle date et qui a ouvert. Donc avec un dialogue déjà plus ouvert et que n'importe quelle personne qui passe peut comprendre ce que c'est. Donc cette fiche Kensei, elle est positionnée sur son propre petit camban qui est à côté, qui est aussi dans ce qu'on appelle le cockpit Maurice. Nous, on l'appelle comme ça. Voilà. Suite de ça, on fait ce qu'on appelle un kata. Donc c'est comme une rétrospective si on veut, mais elle est orientée sur une heure de travail où on va travailler à jeter des avions, comme on l'a fait hier pour certains, autour du A3. Et on va générer ce qu'on appelle un A3 à partir des premiers indicateurs qu'on a. Donc on prend nos indicateurs qui seront très factuels, de l'autre côté le ressenti des équipes, et en une heure, on essaye de mettre de façon collégiale tous les acteurs qui sont nécessaires. Donc il nous est arrivé par exemple, avec Ousei qui est ici présent, qui est un des coachs que je vous présenterai tout à l'heure, qui a mis son 1 à 3 avec une équipe, le métier autour de la table, les produits de tonneur et l'équipe de développement. On avait un problème sur la date d'arrivée du projet et on a pris des décisions de façon collégiale. Donc on a travaillé sur la réduction du périmètre, on a rajouté des ressources pour ensuite simuler ce qui allait se passer avec nos indicateurs si on faisait cette technique. Donc c'est un autre indicateur qu'on va avoir ici, c'est le temps de résolution moyen des obstacles et le nombre d'obstacles dans le système. Ce qui va nous permettre aussi d'avoir un nouveau élément factuel pour montrer, par exemple, on l'a fait sur un projet, on a fait exprès, on attend un ergonomes depuis longtemps sur un projet, on a décidé de bloquer le système. On a tout bloqué, les user stories, et ce qui fait que maintenant, il y a un des acteurs importants du projet qui est passé devant et qui a demandé ce qui se passait, pourquoi ça n'avançait plus, et bien on lui a dit, voilà, l'ergonomes n'est pas là. Et il a résolu le problème tout de suite. On en profite pour donner des signaux. Parce que même si on remonte les obstacles,
Les managers ne sont pas encore très agiles pour l'instant.
Second point, réduction des anomalies. Comment réduire les anomalies? C'est une technique qu'on a utilisée là, c'est assez simple. Je vous l'ai dit préalablement, on fait travailler l'équipe de test directement avec l'équipe de Product Owner. Donc ils ont une culture dès le départ de ce que va représenter la User Story. Une fois que la User Story est partie à l'équipe de développement, on a un lead time, c'est-à-dire un temps de traversée moyen entre le moment où elle a été rédigée par l'équipe de test et le moment où elle est passée à l'état test, on a une dizaine de jours en moyenne. Donc ces dizaines de jours vont être utilisés pour créer ce qu'on appelle les jeux de données. Et ensuite, cette personne, donc ce testeur, va accompagner l'équipe pour faire du pair testing. Donc chaque équipe, chaque développeur prend la user story de son voisin et inversement. On les teste à toute vitesse, selon les scénarios qui ont été écrits dans la user story. On note sur un tableau toutes les anomalies qui rentrent dans le système, et ensuite on fait du XP classique, on fait du pair programming. Il y a un senior qui se met à côté d'un junior pour lui expliquer pourquoi il a fait cette anomalie, comment la corriger. Cet exercice se fait à chaque fois au déclenchement d'une limite. Par exemple, dès qu'on a 5 user stories à l'état test, le testeur prévient son équipe que le lendemain, on va faire un pair testing. Et en moyenne, ce pair testing prend une heure. En une heure, on fait les tests qui durent en moyenne entre 20 et 30 minutes. Et ensuite, on résout les anomalies. On peut pousser des fois jusqu'à 1h30 quand on a beaucoup d'anomalies bloquantes. Ce qui fait que le niveau d'anomalies post-done, c'est-à-dire à la sortie du développement, est quasiment inexistant sur les anomalies majeures et bloquantes. Les équipes de recettes, les équipes de QSI, qu'on les appelle, étaient un peu sceptiques sur les méthodes de travail. Ils travaillent à la suite, puisque pour l'instant, on a une grande phase de recette, souvent à la fin du développement. Le premier retour depuis, c'est qu'ils voudraient l'installer partout. Ils ont remarqué que sur l'ensemble des projets qui ont été accompagnés sur cette pratique, il n'y a quasiment plus d'anomalies bloquantes et majeures. Ça veut dire qu'on peut faire une recette de bout en bout, et le taux d'anomalies qui était à peu près de 60% tombe, pour les derniers projets qu'on a, jusqu'à 17%. Après, on trace, nous, le nombre. On va avoir un nouvel indicateur qui est le cycle time des anomalies, le nombre d'anomalies dans le système, et aussi, pour faire de la prédictibilité, la moyenne des anomalies par user story.
A partir de là, On a travaillé à peu près pendant deux ou trois semaines avec l'équipe du Product Owner. On travaille avec l'équipe de développement, l'équipe de réalisation, où là on va avoir des ergonomes, on va avoir de la QSI. On peut avoir aussi des gens qui sont transverses, par exemple il y a des gens qui font des web services. Donc petit à petit, les gens du web service justement ont travaillé pour proposer des mocks, c'est-à-dire qu'on peut faire des boucles locales pour tester. Donc toute la société est en mouvement actuellement pour essayer de diminuer le nombre d'anomalies. Tout le monde a compris que ça coûtait très cher en jours hommes et en coûts sur le projet pour tenir ce délai. Donc le même principe, là on va avoir un product owner qui va maintenant travailler ce qu'on appelle en flux tiré par la demande. Alors ça, c'est le sujet le plus difficile actuellement. c'est d'essayer d'expliquer aux gens qu'il faut arrêter de produire alors que les gens n'ont pas la capacité de le faire de l'autre côté. Donc ce qu'on a fait, pour répondre un peu à ce sujet, c'est qu'on a fait un miroir des cambans. Quand vous êtes sur le site avec des Product Owner, vous voyez ce qui se passe en temps réel à Lille, puisque le site se trouve à Lille, le développeur. Et inversement, tout le monde voit et tout le monde doit voir exactement ce que nous on appellerait plutôt un portfolio projet, c'est-à-dire de l'idée jusqu'à la fin de la réalisation, pour que tout le monde puisse voir la capacité du système et automatiquement s'il y a des goulets d'étranglement. Donc maintenant le Product Owner va travailler par rapport à la capacité. Donc on va lui dire que l'équipe a la capacité de faire 5 User Story. Donc il va essayer de gérer son temps en relation. Et de l'autre côté on va mesurer le débit, c'est-à-dire le nombre de cartes qu'on arrive à sortir. Le nombre de cartes ce sont indépendamment Anomaly, User Story ou... Évolution. Donc là encore, nouvel indicateur, ce qu'on appelle le cycle time pour les user stories et le débit de l'équipe au niveau des cartes. Donc on va rentrer un peu maintenant dans ce qu'on appelle les indicateurs. A partir de là, on a construit notre système, on est arrivé, les indicateurs apparaissent au bout de la quatrième semaine. Donc au bout de quatre semaines, toute l'équipe est en train d'y travailler. L'équipe adopte rapidement, surtout les équipes de développement, comprennent très vite l'avantage de travailler avec un Kanban, parce que ça permet de faire de l'autogestion et surtout d'avoir une meilleure communication et, comme le disait un développeur il n'y a pas longtemps, d'avoir une vision complète de ce qui est en train de se passer sur le projet. Donc nos premiers indicateurs qu'on va sortir, c'est un peu abscond les indicateurs. Ce qu'on va faire nous, c'est ce qu'on appelle des KPI, des indicateurs de projet. Nous, nos indicateurs, souvent, peu de gens les utilisent. On les agrège pour sortir ensuite ce qu'on appelle des KPI selon la stratégie que je vous ai présentée tout à l'heure. La première stratégie, c'est tenir ses promesses. Donc, montrer la prédictibilité, c'est-à-dire la date d'arrivée du projet. Le deuxième, satisfaction métier. Comment on le fait? En montrant la valeur métier produite, tout simplement. Puisque en amont on a fait du Lean Startup et du Frugal Innovation, donc on va pouvoir avoir une idée de la valeur métier qu'on produit. Et le troisième, c'est la gestion des anomalies. On va montrer le coût de la dette technique et s'il y a une réduction dans le temps. Donc tous ces indicateurs, c'est ce que je vous ai présenté tout à l'heure. A chaque phase du Kanban, on sort un certain nombre d'indicateurs, le nombre d'anomalies, le cycle time par anomalie, la même chose pour les user stories. On rajoute encore d'autres indicateurs que je n'ai pas mis là, qui sont associés à la charge de l'équipe, le coût d'une personne pour montrer combien coûte la génération d'une anomalie, parce que pour nous, il est important que les gens comprennent que ça coûte beaucoup d'argent, une anomalie, et que cet argent, il est préférable de le dépenser dans des équipes de test plutôt que dans des anomalies. Donc la première chose qu'on va obtenir, c'est ce qu'on appelle la prédictibilité.
Donc cette prédictibilité, en fin de compte, à partir des différents indicateurs que je vous ai montrés, la date en bleu, c'est la date d'arrivée du projet. Et la date en dessous, la date d'atterrissage, c'est la calcul de la prédictibilité. Et on a un écart. Donc là, cette prédictibilité, elle est gérée par rapport à ce qu'on appelle au cycle time. Et on a un taux d'erreur inférieur à 2%. Et cette fois-ci, par rapport à la DCNS où je n'étais pas prêt en 2011, et en direct je n'ai pas eu de chance, il y avait Laurent Bozovic qui était juste à côté, qui montrait le peu de crédibilité des chiffres qu'on sortait souvent dans l'agilité. Donc c'est vrai que quand j'ai fait ma présentation, j'ai même retiré des chiffres, juste avant de la faire, quand je faisais celle de la DCNS, parce que je n'avais pas assez travaillé, entre guillemets, pour montrer la crédibilité de ces chiffres. Maintenant, ces chiffres sont reproduits à chaque fois à l'intérieur des projets. Donc on a 10, 15, 20, 30, on aura 80 projets qui pourront mesurer réellement si ça fonctionne la prédictibilité. Notre objectif dans le cadre de ce projet, pour nous en tout cas en tant qu'accompagnateur et quand on veut créer cette vague d'accompagnement, parce qu'il y a un objectif quand même, c'est pour nous d'essayer d'initier les gens. À Kanban parce qu'on a un avantage, un petit avantage par rapport à Scrum. c'est que la conduite de changement est beaucoup plus rapide au départ. On a beaucoup moins de rébellion. Les gens l'adoptent très très vite. En fin de compte, c'est impressionnant, mais au bout de 4 semaines, tout le monde est dans le système et tout le monde comprend très bien les avantages du système. Et ce qu'on remarque, moi je le vois auprès de la DCNS parce que le système fonctionne toujours, j'ai toujours accès aux indicateurs, deux ans plus tard il n'y a aucune dilution du système. Donc ça, c'est ce qu'on appelle la prédictibilité par le cycle time. Néanmoins, on a une petite problématique, puisque actuellement on est en phase manuelle dans la saisie des indicateurs, on est en train de passer sur une phase informatisée, c'est-à-dire que les gens bougent tout simplement leur user story dans un outil électronique, tout en gardant le management visuel bien sûr, puisque ça a beaucoup d'impact. On a des fois des gens qui ne respectent pas très bien ce qu'on appelle le cycle time. Donc on a rajouté un nouvel type de prédictibilité, ce qu'on appelle par le débit. On compte tout simplement le nombre de cartes. Donc c'est notre ami Kousei, qu'on appelle chez nous Indicator Man, qui nous fait ça, actuellement, qui maintient. Donc voilà, et on voit qu'il y a un écart. Je me suis amusé à récupérer dernièrement tous les chiffres. On a un écart quand même assez important. Quand on mesure avec le débit, on arrive à entre 10 et 15% de déviation par rapport à la prédictibilité du projet.
Par rapport au cycle time de base.
Cet indicateur, sur le côté, vous avez ensuite ce qu'on appelle des estimations, juste à côté, il y a des estimations 10, 20, 30. Ça va nous permettre... On va donner un outil, tout simplement un fichier Excel, qui va permettre, en même temps qu'on fait le A3, de simuler tous les cas de figure dans le système. Si on rentre tant d'obstacles, si on conserve les obstacles, si on rajoute 10 nouvelles user stories dans le système, donc dans le cas que vous voyez actuellement, il n'y a aucune nouvelle user story qui est rentrée dans le système. On a déjà toutes les user stories. Demain, j'arrive, c'est ce qui nous est arrivé d'ailleurs, le métier est arrivé en disant, il me faut 20 nouvelles user stories. Comme d'habitude, comme c'est le métier, tout le monde a dit oui. Néanmoins, dès qu'on l'a simulé et qu'on a vu la date, tout le monde est revenu en arrière sur la décision. Voilà à quoi ça sert par exemple d'avoir de la prédictabilité. Après, la prédictabilité, ça ne nous permet pas forcément de tenir nos promesses. Ça ne veut pas dire qu'indépendamment, on le sait très bien de l'agilité, on n'arrive pas tout le temps à respecter les dates par rapport à, comme le dit notre client, on veut les dates et le périmètre. C'est très difficile. Mais le fait d'avoir un indicateur de prédictibilité permet de mettre les gens autour de la table et d'avoir des décisions collégiales. Et en fin de compte, depuis qu'on fait ça, les équipes métiers qui étaient mécontentes sur les dates d'atterrissage du projet, Il y a une grande satisfaction de leur part parce qu'ils peuvent le voir en temps réel, puisque les indicateurs sont là en temps réel, et ils peuvent surtout apporter une assistance en demandant par exemple des ressources supplémentaires, en descendant le périmètre pour respecter les échéances. Et depuis, en fin de compte, les métiers, ça a augmenté la satisfaction du métier. Et surtout, on travaille beaucoup avec... à travailler sur ce qu'on appelle le problem solving, la résolution de problèmes, pour améliorer le système en vue d'avoir une meilleure prédictibilité. Donc depuis que le système est de plus en plus efficient, par exemple, il y a les développeurs qui me disaient il n'y a pas très longtemps, enfin je travaille sur pourquoi je suis payé, c'est-à-dire est-ce que j'aime, c'est-à-dire le développement. Il y a de moins en moins de problèmes dans le système parce que tout le monde est conscient que les problèmes engendrent. Un retard sur le projet. Et grâce justement à ces indicateurs de prédictibilité, on peut le voir en temps réel. Je vais vous montrer juste, pour information, quelques graphiques qu'on sort. On en a plein des graphiques parce qu'on construit les graphiques en relation directement avec les patrons des portfolios, c'est-à-dire les gens qui gèrent différents projets. Il y en a des gens qui ont une culture très indicateur et il y en a qui n'en ont pas du tout, qui ont du mal à les lire. Donc on va leur faire ce qu'on appelle des happy boards, deux ou trois chiffres qui leur disent votre projet est là. Il est à 78% de la date d'arrivée et il va y avoir un léger décalage. Il y en a d'autres qui adorent les indicateurs. On a des gens qui sont des patrons des anciens d'Accenture ou autres qui vont nous demander des indicateurs sur la valeur, des indicateurs d'entrée-sortie. Donc le premier indicateur qu'on voit en haut, c'est ce qu'on appelle le cycle time, tout simplement, classique, piqué encore d'un livre bien connu, d'un auteur qui est dans la salle. Voilà, donc c'est un indicateur qu'on a juste et qui montre bien le travail du coaching. Au début, on avait un cycle time très élevé, c'est-à-dire un temps de réalisation des user stories très élevé. Et petit à petit, au bout de 8 semaines, puisque ça c'est le résultat au bout de 6 semaines celui-ci, c'est qu'on a... à diminuer le cycle time. Ce n'est pas de la magie, c'est simplement qu'on a retiré beaucoup d'obstacles, on a travaillé sur des très bonnes user stories, et ce qui a la finalité aussi, c'est qu'on a réduit les anomalies grâce à des user stories de qualité. C'est un des points qui est le plus important qui a été remonté par l'ensemble des acteurs, c'est la qualité des user stories. Un autre indicateur que je vous montre qui est juste à côté, c'est l'entrée-sortie au niveau des user stories. Et on le voit que l'écart, il y a peu d'écart. Dès qu'on rentre quelque chose, il sort toujours à peu près à la même date. et qui montre bien le travail du coaching. Au début, on avait un cycle time très élevé, c'est-à-dire un temps de réalisation des user stories très élevé, et petit à petit, au bout de 8 semaines, puisque ça c'est le résultat au bout de 6 semaines celui-ci, c'est qu'on a réussi à diminuer le cycle time. Ce n'est pas de la magie, c'est simplement qu'on a retiré beaucoup d'obstacles, on a travaillé sur des très bonnes user stories, Et ce qui a la finalité aussi, c'est qu'on a réduit les anomalies grâce à des user stories de qualité. C'est un aussi des points qui est le plus important qui a été remonté par l'ensemble des acteurs, c'est la qualité des user stories.
Un autre indicateur que je vous montre qui est juste à côté, c'est l'entrée-sortie au niveau des user stories. Et on le voit que l'écart, il y a peu d'écart. Dès qu'on rentre quelque chose, il sort toujours à peu près à la même date. Donc on contrôle. L'idée, ce n'est pas de réduire de façon absolue la taille d'une user story, donc le cycle time, ça n'a aucun sens. On en générerait beaucoup trop à la finalité. Mais c'est surtout de maîtriser l'efficience du process. C'est que quand quelque chose sort, rentre dans le système, il sort à peu près à la même date. En dessous, c'est ce qu'on appelle un histogramme des anomalies, le cumulatif flow que vous le voyez. Il y a un des indicateurs qui me tient à cœur, qu'on a rajouté dans le cockpit, qui n'existait pas pour nous. Ça, c'est ce qu'on appelle, en fin de compte, le calendrier. On mesure, on a mis un calendrier dans la salle, sur le cockpit, où tous les acteurs ont écrit lundi, mardi, mercredi, et en face, il y a écrit cérémonial, réunion, absence, atelier. M'absence congé. Et en fait, à chaque fois que quelqu'un part dans un atelier, dans une réunion, dans un cérémonial, et quand il revient, il met simplement le nombre d'heures. Donc, ce n'est pas attitré à une personne, c'est pour le groupe. Et nous, on récupère tous les post-it, tous les heures qui ont été écrites, et on fait un agrégat. Et on obtient cet indicateur par semaine. Donc, par exemple, le bleu, c'est des congés. Là, en fait, ce projet, il arrive en plein milieu de l'été. Donc, il y a beaucoup de congés. Néanmoins, il y a une autre qu'on voit, ce sont les mauves. Les couleurs mauves, ce sont les réunions qui n'ont strictement aucun rapport avec le projet. Où les gens passent leur temps dans des réunions, des tas de trucs qui n'ont rien à faire. Les cérémonials, c'est en rouge. On le voit d'ailleurs, et ça va nous permettre de diminuer le temps moyen d'un cérémonial, c'est-à-dire qu'il soit le plus efficient possible pour produire. On est arrivé, par moment, au début quand on est arrivé, il y avait des rétrospectives qui duraient entre 2 et 3 heures certaines, où on était dans des grandes discussions sur ce qu'on avait vu à la télé. Moi, j'ai assisté pendant une heure à des gens qui comparaient des séries télé. J'avais été très étonné. Mais pourquoi? Parce que simplement, le Scrum Master n'avait jamais été formé à la maîtrise, en fin de compte, d'une simple cérémoniale. Donc par exemple, là, ce qu'on vient de faire, et là, je viens de les commander, c'est qu'on achète tout simplement, par exemple, des sabliers et on les pose dans la salle pour que tout le monde puisse voir. Le temps est mesuré petit à petit avec eux et ils arrivent à être de plus en plus efficients. Et on met quelques messages dans la salle, par exemple, on va leur dire une conversation à la fois, on va leur passer un message pour dire qu'on n'est pas là pour agresser les autres et ainsi de suite. On inculte peut-être. petit à petit l'art de la réunion. Et ce qu'on voit surtout maintenant, c'est qu'en fin de compte, on consomme à peu près 200 heures par mois en réunion pour une équipe. Donc, notre objectif a été de les réduire. Et là aussi, les gens ont pu passer plus de temps à faire ce qu'ils étaient payés, et surtout, pourquoi ils voulaient le faire, c'est-à-dire les développeurs, par exemple, qui m'ont dit que c'était très agréable, qui faisait de moins en moins de réunions, on est arrivé sur des équipes où actuellement le taux de réunion qui est de 50 heures par semaine en moyenne par rapport à l'équipe, on est tombé à 2 à 3 heures.
Pour terminer, je vais vous présenter l'équipe. Voilà, donc une partie de l'équipe. Alors là, vous avez Koussey qui est là, qui est en train de prendre une photo. C'est assez ressemblant. Vous avez Gilles Mantel qui est le responsable de l'offre à Gilles et qui est un vrai scrummer, lui un pur, qui a beaucoup de mal avec moi. Il y a Renaud Chevalier qui a eu l'occasion de mettre ce qu'on appelle les Future Time dans un grand projet autour de la transformation du PMU vers l'iPad et qui nous a rejoints. Et on a l'équipe, ce qu'on appelle la team. Je n'ai pas encore eu le temps de les dessiner, c'est pour ça qu'on ne l'a pas fait. On a Benjamin qui est là, qui est directement de la société, qui ne travaille pas chez Xebia. Qui sera à la demande de son groupe certifié coach, Camban, et qui travaille directement avec moi. Et une autre personne s'appelle Benjamin Marlière, qui est derrière, qui travaille aussi pour ce groupe dans le cadre de ce projet. Ensuite, on a d'autres coachs qui sont sur le terrain, comme Ludovic, Gwenaëlle, Elodie, Marc. Qui sont sur le groupe. Pour vous donner une image, au début 2014, nous serons 10 coachs simultanément sur le projet à gérer des projets. Donc c'est un projet d'industrialisation. Ce projet depuis a fait, il y a beaucoup de monde qui entend parler, on est en train de le monter aussi sur des petites équipes. Donc je suis en train de le faire sur un client entre guillemets très connu sur le boulevard Haussmann, qui a des grands magasins énormes là-bas, et qui est en train de faire ce qu'on appelle une marketplace et qui est en train de passer sur cette pratique. Et là on est sur des petites équipes, des gens où on est plutôt dans le mode start-up, parce qu'on est en train de créer une marketplace, et ils s'adaptent très bien dans ce truc. Alors, on n'a pas retiré du tout Scrum, je rassure. Vous avez toujours les métiers du Product Owner, classiques du Product Owner, et avec les mêmes responsabilités, on essaye de le mettre. Le Scrum Master est toujours là, avec les mêmes responsabilités qu'on attend de lui dans le cadre de Scrum. On a toujours des sprint planning, des démos, des rétrospectives. Simplement, les obstacles sont gérés en kata, les rétros servent à faire de l'introspection, c'est-à-dire de l'amélioration continue sur l'équipe. On oriente plutôt le kata pour gérer les obstacles qui arrivent et le rétro pour travailler sur nous-mêmes. Comment on s'améliore nous-mêmes à l'intérieur de l'équipe.
La différence, simplement, c'est qu'on n'est plus en notion itérative, on est en flux continu, et toutes les instances sont flottantes. Donc, dès qu'on sent qu'on a un obstacle, on fait une cata. Les catas, il peut y en avoir trois dans la semaine. Ça peut arriver, ça arrive souvent en début de projet. Les rétrospectives... Dès qu'on pense, par exemple, il arrive souvent au début de projet, que le Scrum Master et le Product Owner... Il y a un peu de friction, donc on les met dans la salle avec toute l'équipe et on apprend à gérer ces frictions. Donc il va y en avoir au début beaucoup.
Les démos sont associées à ce qu'on appelle les MMF, qu'on a vu tout à l'heure, c'est quand on a un produit marketable, c'est-à-dire quasiment un livrable. Parce qu'on avait un problème, c'est qu'au début des pratiques Scrum, en tout cas avec ce client, les métiers étaient là, les acteurs, les sponsors étaient là, et petit à petit, ils n'étaient plus là. Parce que, comme il disait, moi ça ne m'intéresse pas de voir un formulaire. Donc, on a attendu d'avoir un produit complet, où on peut aller de bout en bout, qui répond à un premier besoin pour les invités. Donc on les invite des fois au bout de 15 jours, des fois une semaine, des fois trois semaines, mais on les invite quand il y a une vraie valeur pour eux. On peut néanmoins faire des petites démos en interne parce qu'on a la chance de travailler sur certains projets qui sont sur de l'iPad. Donc on fait des fichiers IPA et qu'on transmet à tout le monde et que tout le monde peut tester en temps réel. On garde toujours la notion de sprint planning. Donc le sprint planning va être très court parce qu'on a fait un pré-travail déjà avec eux. D'ailleurs, les équipes voient très vite les user stories. On n'en voit plus les user stories par lot. On les a voir par limite à peu près de 5. Donc en une heure, la plupart du temps, ils font déjà ce qu'on appelle une magique estimation, SML. C'est très rapide. Et souvent, il reste quelques user stories, une ou deux, qui paraissent un peu complexes. On les met de côté. Et là, ils peuvent partir dans une discussion autour. On peut rajouter du planning poker au tout, des fois, parce que pour accélérer, on va mettre un petit sablier, et pour qu'on ne reste pas des heures et des heures à parler. Et ce qu'il fait actuellement, donc, Koussaï avait fait une chose au début, on avait fait, c'est qu'on mesurait le cycle time par différents types de user story, selon les tailles, S, M, L. Et on s'est rendu compte que ça ne servait à rien. C'est vrai qu'il y a des L qui sont, des fois, ils sont développés avec un cycle time de S et inversement. Mais ça n'a pas beaucoup d'importance parce que nous, on fait la moyenne. Et on s'est rendu compte... C'est le principe mathématique de ce qu'on appelle la régression par la moyenne. Un exemple tout simple, tous les jours vous partez de chez vous pour aller au travail. Bon, moi je vis à Paris, c'est pas fantastique, donc j'ai le métro, j'ai ainsi de suite, mais je sais qu'en moyenne je vais mettre 20 minutes pour y aller. J'ai pas eu besoin de calculer tous les feux rouges, tous les intersections, et ainsi de suite. Donc il n'y a pas besoin de rentrer dans le détail pour pouvoir estimer. Néanmoins, il y a des jours où je mettrais 30 minutes, parce que le métro va être en retard, d'autres je mettrais un peu plus de temps, parce que tout d'un coup il y a moins de monde, ou c'était un jour férié, ou ainsi de suite, et il m'est arrivé d'aller au travail des jours fériés, j'avais oublié. Et donc je vais un peu plus vite ce jour-là. Et en fait, je m'amuse des fois à le calculer. Je reviens toujours vers la moyenne. Il y a ce qu'on appelle une régression vers la moyenne. Donc on n'a pas réellement besoin d'estimer dès qu'on mesure le temps moyen. Donc on retire un peu, en fait, cette notion d'estimation pour travailler plus sur la complexité et l'apport, la valeur ajoutée directement du développeur dans la user story. Il l'a construit avec les... Ce qui fait qu'actuellement, les équipes, il y a beaucoup plus de satisfaction. J'ai pris quelques phrases à l'intérieur des équipes, il y en a plein, ça sort tous les jours. Pour être transparent, ça fonctionne très très bien, tout le monde adore ce qui se passe, et il y a un grand buzz à l'intérieur et on en profite pour faire fonctionner le système.
Ce qu'il faut faire, c'est faire très attention, c'est que les gens voudraient aller beaucoup plus vite. Les équipes de recettes veulent maintenant être totalement intégrées en Kanban. Les équipes de prod s'intéressent beaucoup au DevOps. Tout le monde veut le faire. Donc on va faire quand même des présentations pour leur dire qu'un jour on va travailler avec eux. Et on leur explique pourquoi on ne va pas trop vite. Pourquoi on travaille sur le Product Owner et le Scrum Master, qui sont des gens avec qui on a plus de facilité à faire de la conduite de changement. Honnêtement, faire de la conduite de changement avec le métier, c'est un travail énorme et très difficile. Ils ne comprennent pas, tant qu'ils n'ont pas vu. Donc par exemple, les anomalies bloquantes, c'est ce que je vous disais, sont quasiment inexistantes. On n'en a plus. Et on descend, en fin de compte, la dette de la société. Je peux enfin me concentrer sur le développement. C'est une personne, un développeur qui nous l'a dit, il le redit par un mail. Le résultat était impressionnant, c'est un des responsables du portfolio.
Les projets qu'il gérait avaient toujours, il me le disait en moyenne, un à deux mois de retard, c'était un minimum. Le projet qu'on a fait actuellement, aux dernières nouvelles, il avait 20 jours, je crois qu'il est redescendu à 1, c'est ça, il a gagné un jour. Pour lui, c'est déjà impressionnant, c'est qu'on livre à temps, avec le même péril.
Et le dernier, c'est je le vois en projet en temps réel, alors ça, ça rassure maintenant, et les indicateurs, ça rassure les gens du métier, sachant qu'il faut être transparent, pour l'instant, ils ne s'impliquent pas beaucoup, ils regardent, mais il y a une nouvelle culture du métier, orientée au niveau du digital dans le groupe, qui fait que de plus en plus, on a des métiers qui comprennent vraiment le web, et qui comprennent ce qui se passe, et qui sont très intéressés, on a des nouveaux acteurs entrant, qui justement... Viennent voir ce qui se passe et travaillent avec les indicateurs avec nous, essayent de créer ce qu'on appelle les MMF ensemble. Qui au lieu de, puisqu'on l'a entendu beaucoup quand on a commencé, je veux les choses à isopérimètre. Donc je vais conclure, je ne sais pas si je suis dans les temps normalement, il me reste 10 minutes, waouh! Ok, on va se faire un planning poker.

Transcription