L’agilité à l’échelle est aujourd’hui devenue le sujet de nombreuses DSI. Plusieurs Framework ont donc vu le jour ces dernières années, tentant de résoudre les problèmes les plus courants. Mais en tant que coach Lean, nous restions toujours sur notre faim lorsque nous constations la mise en place de l’un d’entre eux, car de nombreuses questions Lean restaient sans réponse. Nous avons alors proposé FLA@S (le Framework Lean d’Agilité @ Scale), un Framework de passage à l’échelle rapide, léger et efficace (en d’autres termes : Lean) qui intègre le questionnement Lean au quotidien.

Cet article présente une mission d’accompagnement FLA@S menée avec un programme de quatre équipes de production (environ 40 personnes) dans un grand groupe français du secteur du Retail. Il explique comment, avec les mêmes personnes, en clarifiant les conditions de réussite, les équipes sont parvenues à augmenter leur production de manière significative tout en étant très engagées dans la démarche.

Comprendre, voir et agir avec le Lean

Le Lean nous engage chaque jour à 1/ comprendre notre challenge, 2/ voir notre situation et 3/ agir pour aligner la situation avec notre challenge. Et c’est précisément ce geste que nous rendons concret par le déploiement de FLA@S.

Contexte

Les équipes que nous accompagnons ici sont responsables d’un produit très apprécié des utilisateurs. Mais ce produit souffre d’une dette technique importante, et un chantier de refonte a été lancé pour faciliter le scaling et ainsi prendre en compte l'engouement des utilisateurs, toujours de plus en plus nombreux. La refonte est en cours depuis trois mois, et les équipes ont annoncé que le chantier serait rapide (à peine trois cents jours). Mais cette annonce semble avoir été un peu prématurée, et le chantier s’avère un peu plus compliqué que prévu.

1.   Comprendre

Aligner les équipes

Notre première action est de comprendre le challenge. C'est-à-dire 1/ clarifier ce que les équipes ont à réussir, et 2/ comprendre leur perception de ces conditions de réussite.

Les équipes travaillent depuis quelques mois en sprint de 2 semaines. À chaque fin de sprint, comme le veut la coutume Scrum, une rétrospective est organisée pour identifier les problèmes rencontrés et définir des actions d’amélioration. Lors de cette première rétrospective avec eux, les équipiers sont amenés à donner leur avis sur la réussite du sprint. Sur les 15 équipiers qui se sont exprimés, 8 jugent le sprint passé comme étant un succès, 6 le jugent comme “presque réussi” et 1 seul trouve que c’est un échec. Lorsque nous regardons les informations chiffrées, nous constatons que 31 User Stories sont encore au statut “à faire” en fin de sprint sur les 45 prévues initialement (69% ne sont donc pas terminées). L’analyse du niveau de succès n’est donc pas directement liée aux éléments chiffrés, ce qui nous indique un non-alignement de l’équipe vis-à-vis de ses conditions de réussite.

Pour aller plus loin, nous aimerions comprendre comment sont construits les sprints. En d’autres termes, quels éléments tangibles nous permettraient d’affirmer que réussir les user stories du sprint permettra de tenir notre engagement sur le projet ? Là encore peu de réponses, et surtout peu tangibles.

Clarifier le challenge

La seconde action est de clarifier le challenge, c'est-à-dire comprendre le projet et partager ensemble ses conditions de réussite.

Pour cela, nous proposons un premier atelier ayant pour objectif d’identifier l’ensemble des éléments à produire dans ce projet. Puis, nous examinons la charge de travail que cela représente, la répartition de cette charge sur les équipes, et enfin les dépendances entre les équipes.

Tel que le projet nous a été présenté, les équipes devaient être toutes autonomes et indépendantes. L’atelier révèle en fait des dépendances fortes entre 3 des 4 équipes ainsi qu’une répartition inégale de l’effort. En effet, 56% de l’effort global estimé du projet repose sur une seule des équipes, qui se retrouvera donc inévitablement goulot d’étranglement du projet si on ne répartit pas mieux la charge de travail.

Clarifier notre compréhension du projet nous a donc permis de passer d’une vision projet de quatre équipes autonomes et indépendantes, à un projet nécessitant une collaboration forte.

Atelier d'identification des dépendances

Afin de piloter le projet, nous devons identifier les unités d’œuvre à suivre et à mesurer. Les équipes ont déjà défini des EPICs représentant l’ensemble du projet. Chacune d’elles correspond normalement à un parcours utilisateur complet, et sera divisée par les équipes en User Story plus petites au cours du projet. Mais certaines de ces EPICs sont “techniques” et servent à stocker des tickets techniques (concernant les bases de données par exemple) et n'ont donc aucun sens pour le client. Suivre l’avancement du projet avec ce type d’EPIC n’est donc pas cohérent. Pour s’en convaincre, il suffit de regarder l’encours : 14 des 18 EPICs en cours sont techniques et, de par leur nature, ne se termineront pas avant la fin du projet. Nous faisons donc le choix de lister les EPICs représentant les parcours utilisateurs devant être couverts par le projet de refonte. Nous y diluons les EPICs techniques en fonction des dépendances identifiées précédemment, et nous obtenons une liste d’EPICs qui fait sens pour le client et qui nous permettra de piloter notre projet. Mais maintenant, pour que le projet puisse être terminé fin septembre, que devons-nous réussir dans le prochain sprint ? Et dans la journée ?

Pour répondre à ces questions impératives pour réussir un projet de cette envergure, nous avons lissé la production de l’ensemble des EPICs estimées afin de définir un planning de production.

Ce travail partagé, le challenge est clair pour toutes les équipes. Chacun des équipiers est en situation de savoir ce qu’il a à faire dans chaque sprint pour réussir le projet, et ce qu’il a à faire chaque jour pour réussir le sprint, lui donnant ainsi une définition claire de ce qu’est une journée réussie.

“Grâce au Lean, les collaborateurs n’ont pas le devoir de réussir leur journée, mais ils en ont le droit”

Marie-Pia Ignace

2.   Voir

Voir la situation

Clarifier les conditions de réussite sans pouvoir voir et comprendre notre situation actuelle, c’est un peu comme définir des limitations de vitesse sans pouvoir regarder le compteur.

Pour voir leur situation, les équipes utilisent l’outil JIRA. Elles utilisent le board par défaut qui affiche l’ensemble des tickets du sprint en cours. Ce board est régulièrement considéré comme un management visuel par les équipes au début. Mais on constate souvent qu’elles ne le regardent plus au bout de quelques sprints. Nous avons quelques idées sur ce qui pourrait en être la cause.

Pourquoi souhaitons-nous un management visuel ? L’objectif est d’avoir une compréhension claire, rapide et exhaustive de la situation dans laquelle on est, ainsi que des écarts qu’il y a avec nos conditions de réussite. Les boards proposés par JIRA nécessitent de voyager à l’aide d’ascenseurs sur des pages qui semblent parfois interminables. Pour pallier cela, des filtres et des timelines sont mis à disposition pour nous permettre de cacher sans gêne des pans entiers de la situation. De plus, ces boards n’affichent aucun indicateur tangible concernant ce que l’on doit réussir et notre situation. Ces indicateurs existent pourtant bien, mais plusieurs clics sont nécessaires pour les obtenir.

Ces boards peuvent être intéressants pour trier ou rechercher une donnée particulière. Mais lorsqu’il s’agit de voir et comprendre la situation dans laquelle nous sommes afin de prendre les bonnes décisions au bon moment, cela devient plus compliqué. Il suffit de poser les questions suivantes, lors d’un daily par exemple, pour s’en convaincre :

• Combien avez-vous de tickets en cours actuellement ?
• Pourquoi y a-t-il plus de tickets en cours que de personnes dans les équipes ?
• Qu’arrive-t-il aux tickets sur lesquels les équipiers ne travaillent pas aujourd’hui et qui sont pourtant au statut “en cours” ?

Une équipe qui maîtrise sa situation répondra à ces questions basiques instantanément. Ce n’est malheureusement pas le cas dans nos 4 équipes. On voit alors les personnes chercher ces réponses sur le board, scroller, déplier des timelines, activer ou désactiver des filtres pour trouver une réponse qui se révèle parfois être fausse.

Si on clarifie le challenge sans savoir où on est, on se retrouve comme un GPS à qui on a donné une destination, mais qui ne sait pas où il est (i.e. qui n’est pas connecté aux satellites).

Nous allons donc faire en sorte de voir et éclaircir la situation. Il existe plusieurs méthodes pour cela. Les post’its sur un tableau blanc au mur sont bien évidemment la manière la plus simple et rapide de commencer, mais depuis la crise sanitaire, le télétravail a mis à mal cette pratique. Reste alors des outils comme Miro, Klaxoon, Mural ou Draft.io qui permettent de créer et coller des post-it virtuels. C’est la méthode que nous préconisons habituellement. Cependant certaines équipes, très attachées à JIRA, ne souhaitent pas recourir à un outil tiers. C’est le cas de nos équipes. Soyons agiles, nous proposons donc un plugin permettant de répondre en partie à notre problématique : Great Gadgets. Ce plugin permet d’afficher :

1. La situation au travers d’un board condensé des tickets du sprint en cours
2. Des indicateurs chiffrés (nombre d’US en cours, nombre d’US à faire par jour, nombre de bugs dans le sprint nous empêchant de travailler plus sur les US, etc.)
3. Un graphique d’avancement type burndown

Tout cela permet aux équipes d’améliorer leur compréhension de la situation. Le fait d’avoir auparavant clarifié leurs conditions de réussite (grâce notamment au plan de production) leur permet d’appuyer leur organisation quotidienne sur des éléments factuels.

Clarifier la situation

“La vision est rapide et fiable, la mémoire moins, la réflexion est lente et risquée. Un bon management visuel rend les processus intuitifs et révèle les problèmes, créant ainsi les conditions d'une bonne réflexion”

Michael Ballé

Voir les opportunités d’améliorations

Avoir une vision claire de la situation permet également de voir les problèmes qui arrivent dans notre flux de production comme des tickets bloqués, une étape du processus avec un stock important de tickets, une autre entièrement vide, des tickets rouges (sur lesquels on a saisi une anomalie), etc. Ajoutez une définition précise des conditions de succès, et chacun se retrouve alors en capacité d’identifier un écart entre ces conditions et la situation actuelle.

Cet écart mesurable marque le point de départ de l’amélioration continue. Ils représentent tous une opportunité d’apprendre quelque chose sur notre processus de production en se demandant pourquoi on est dans cette situation et en quoi c’est un problème pour l’atteinte de notre objectif. Et c’est ainsi que l’on va pouvoir agir sur notre processus.

3.   Agir

Nous savons maintenant où nous devons aller grâce à la clarification de notre challenge. Nous avons en plus une compréhension claire et rapide de la situation dans laquelle on est grâce au management visuel et à nos indicateurs. On est donc en capacité d’identifier les écarts et agir pour tendre toujours plus vers la réussite de notre challenge.

Nous accompagnons donc les équipes afin de les mettre en situation de pouvoir réagir lorsqu’un tel écart est constaté, et cela le plus rapidement possible, sans avoir à attendre la fin d’un sprint. Pour cela, nous avons un peu bouleversé LE rituel principal de prise de décision : le daily standup. Les équipes avaient pris pour habitude de faire parler les équipiers les uns après les autres, en se posant les questions suivantes :

• Qu’est-ce que j’ai fait hier ?
• Qu’est-ce que je fais aujourd’hui ?
• Ai-je des problèmes ?
• Je passe la parole à … (en dénonçant un collègue qui n’a pas encore parlé).

Ces questions sont régulièrement observées dans les équipes scrum, mais d’un point de vue Lean, elles n’ont qu’un intérêt limité car :

1. Elles ne font pas le lien avec des conditions de succès de l’équipe (j’ai fait, ou je fais quoi pour réussir quoi ?)
2. Elles sont individuelles, ce qui limite la collaboration et la prise de décision collective.

Nous allons donc préférer les questions suivantes, que toute l’équipe se posera ensemble :

• Quelles sont les US que nous devons sortir aujourd’hui pour réussir notre sprint et notre projet ?
• Comment nous organiser pour y arriver ?
• Quels sont les obstacles qui pourraient nous en empêcher, et comment nous en protéger ?

Ces questions, qui seront posées devant le management visuel afin de s’aligner sur la situation, devront trouver des réponses auprès des équipiers de manière collective. Leur avantage est qu’elles font comprendre le lien entre l’activité du jour et la réussite globale du sprint et du projet.

Le lendemain, le daily sera complété par les questions d’amélioration suivantes : “Quelles US devions-nous sortir hier ? Y sommes-nous arrivés ? Pourquoi ?”.

Et maintenant ?

Comprendre, voir et agir sont les trois étapes d’un cycle qui ne s’arrête jamais. Agir nous amène souvent à changer nos standards de production. On change notre processus, on met en place un nouveau rituel ou on en change l’animation, on modifie un geste, on se pose de nouvelles questions. Tout cela, il nous faudra le partager et le comprendre afin de l’expérimenter dans un nouveau cycle. Ce qui nous permettra alors de voir une nouvelle situation issue de notre nouvelle manière de travailler, et d’agir en conséquence pour changer encore et encore nos standards et s’aligner toujours plus avec notre challenge.

Suite aux situations rencontrées, les équipes ont été amenées à réfléchir à l’amélioration de leur collaboration.

Elles décident, au bout d’un sprint, de mettre en place des scrum de scrum leur permettant d’accélérer la chaîne d’aide et d’optimiser la prise de décision collective. Une nouvelle pratique pour améliorer la collaboration rendue nécessaire pour gérer les dépendances qui existent entre les équipes, et faciliter le pilotage des EPICs métier. Ainsi, lors de chaque daily, si un problème ne pouvant pas être traité par l’équipe seule est identifié, il est immédiatement remonté au scrum de scrum. Une décision collective peut immédiatement être prise et redescendre ensuite auprès des équipes. Régulièrement, des obstacles importants touchant plusieurs équipes remontent à 9h30 (heure des dailies), sont discutés à 9h45 avec des représentants de toutes les équipes (lors des scrum de scrum), et sont réglés à 10h par une décision collective ou la création d’une work-room (mob programming sur un sujet précis avec les personnes identifiées lors du scrum de scrum) le cas échéant.

Dans le second sprint, elles décident de mettre en place un “EPIC Refinement”. Une sorte de Backlog Refinement avec les mêmes représentant que pour des scrum de scrum, où il est discuté :

1. Des EPICs à sortir dans le prochain sprint (au regard du plan de production) afin de les rendre “prêtes à développer”, de répartir la charge entre les équipes et de gérer la synchronisation des développements (qui se fera au quotidien lors des scrum de scrum)
2. Des EPICs à sortir dans les sprints suivants afin de préciser le besoin et la compréhension de ces éléments qui arrivent prochainement

Deux sprints plus tard, les équipes identifient un problème de qualité dans la production. Elles lancent alors une démarche d’amélioration de la qualité basée sur l’identification des causes racines. Une fois par semaine, les équipes se retrouvent afin d’échanger sur les tickets de non-qualité qui ont traversé leur flux et pollué leur production. Ils recherchent les causes racines de ces éléments, et agissent en imaginant des contre-mesures qu’ils expérimentent alors immédiatement.

Faire le check

Par cette démarche vertueuse, en clarifiant les critères de réussite et en traitant les obstacles qui les empêchaient d’avancer, les équipes sont passées d’une moyenne de 18,5 US livrées par sprint à 23 en 12 semaines. Elles ont également amélioré leur engagement de 37%, passant d’un taux de réussite de sprint de 38% à 52% (Nombre d’US réalisées sur un sprint vs le nombre d’US prévues).

Mesure avant et après accompagnement

Et tout cela en engageant l’ensemble de l’organisation dans la démarche. Quelques verbatims concernant l’intervention :

“Tout s’est passé très naturellement. Chaque pratique a traité un problème concret que l’on avait.”

Team Leader

“Merci beaucoup pour l’accompagnement et le boulot accompli. Cette approche permet d’avoir un réel focus Delivery.”

DSI Adjoint

“Une approche avec de nombreuses choses simples et pragmatiques.”

DSI

Quant aux équipiers, ils ont noté la démarche 8,42 / 10 (pour un NPS de +42).

Si on en croit l’expérience de Toyota qui apprend chaque jour depuis plus de 70 ans, le chemin est long et l’amélioration semble être infinie. Nos équipes ont donc encore beaucoup à apprendre. Mais nous n'avons aucun doute sur le fait que les réflexes qu’elles ont acquis grâce au Lean les aideront à toujours avancer.