Les pratiques Lean pour revenir aux sources de l’agilité (3ème partie)

L’objectif de cette série d’articles est de montrer, en illustrant avec plusieurs exemples terrain, comment la mise en œuvre du Lean (celui du Toyota Production System) dans des équipes agiles permet à celles-ci de mieux revenir aux principes originels pour améliorer la satisfaction client, l’engagement des collaborateurs et l’amélioration de la performance.

1. Première partie : Agilité et amélioration continue : le malentendu
2. Deuxième partie : Pratiques Lean pour revenir aux sources de l’agilité (première partie : Préparation du Sprint ; Sprint Planning)
3. Troisième partie : Pratiques Lean pour revenir aux sources de l’agilité (deuxième volet : animation du daily Scrum ; démo de sprint ; rétrospective ; conclusion)

[ Mille mercis à Jean-Michel L. pour m’avoir donné l’idée de cet article ainsi qu’à Olivier Bras et Samuel Ahnine pour leurs relectures minutieuses et leurs commentaires de qualité. ]

Animation quotidienne (Daily Scrum)

Objectif et définition

Il s’agit probablement de l’évènement à la fois le plus important et le plus négligé au sein des équipes que nous accompagnons. Avant toute chose, voyons ce que ScrumAlliance nous dit de ce point d’animation quotidien :

> « In this meeting, team members coordinate and synchronize their activities as related to the sprint goal. They also identify impediments to progress. (…) The meeting is timeboxed to a maximum of 15 minutes**. »

Pour ce qui est de l’animation, voici ce que dit le Scrum Guide (version 2020)

« The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. »

Pratiques observées

Nous ne comptons plus le nombre d’équipes qui ont des points matinaux de 30 minutes ou plus. Ce premier anti-pattern est critique parce qu’il démobilise. Comme « c’est l’équipe qui décide de son mode de travail », il n’est pas rare que cette pratique soit abandonnée (ou aménagée avec une fréquence beaucoup plus réduite – e.g. hebdomadaire - et perdre ainsi son intérêt) parce que « ça ne marchait pas pour nous ».

Le second anti-pattern est la structure de l’intervention de chacun : « Ce que j’ai fait la veille, ce que je vais faire aujourd’hui et mes points de blocage [souvent oubliés] » avec l’équipe en cercle, sans support visuel, ce qui a tendance à désespérer tout le monde. Nous constatons que, bien souvent, certaines personnes monopolisent la parole au grand désespoir de collègues qui ont milles chose à faire et qui lèvent les yeux au ciel de dépit. Je me rappelle de cette équipe de 20 personnes qui travaillait en Kanban avec un coéquipier sympathique mais qui parlait longuement au point matinal qui durait 40 minutes avec le reste de l’équipe les yeux au plafond.

Mais le point le plus important est que comme l’objectif du sprint est défini sous forme littérale, il est à la libre interprétation de chacun, qui peut expliquer comment sa contribution participe à sa lecture de l’objectif. « J’en ai profité pour refactorer la classe ClassePasTrèsBienConçue parce qu’on en aura besoin pour la fonctionnalité F-253 qu’on a prévu dans 6 mois. J’en ai encore pour deux jours, ça va aller vite ». Là encore les équipes agiles vous rappellent que c’est l’équipe qui décide et que, si on n’arrive pas à l’objectif, eh bien « c’est la vraie vie ».

Pratiques Lean

Le sujet a déjà été évoqué dans Culture Kaizen ou dans cet article de Nicolas Ploquin. Dans le Lean nous souhaitons une chose : réussir notre journée. Et si l’équipe a défini pour un sprint de deux semaines (10 jours) de livrer 10 User Stories, alors chaque jour, on s’organisera pour livrer une User Story par jour : la suprême élégance du flux tiré.

Plutôt que l’assommant « Ce que j’ai fait hier, ce que je fais aujourd’hui, et ce qui me bloque aujourd’hui » l’animateur du point quotidien ainsi posera 3 questions :

• Quelle User Story terminons nous aujourd’hui ? Qu’est-ce qui pourrait nous en empêcher ?
• A-t-on bien terminé hier la User Story qu’on avait prévu de terminer ? Si ce n’est pas le cas, que s’est-il passé ?
• Comment nous organisons-nous pour atteindre notre objectif de la journée ?

Ce questionnement a mille vertus. Nous allons en décrire trois. En premier lieu, la question porte sur le « nous » et pas sur le « je ». Ce qui ferme la porte aux débordements personnels souvent superfétatoires. Pour illustrer ce questionnement, l’équipe va utiliser son support visuel (tableau représentant le flux de valeur depuis le backlog jusqu’à la livraison), cela peut être un tableau JIRA ou (mieux) un tableau physique dans l’espace de l’équipe, en démarrant par la colonne la plus à droite, c’est à dire la plus proche de la fin du flux et donc la plus proche de la livraison au client).

Ensuite, l’ensemble de l’équipe est réaligné sur l’objectif du sprint. Le développeur qui avancerait alors qu’il a pris la décision de refactoriser une classe pour une fonction prévue dans 6 mois et une surcharge de 3 jours sera repris par l’équipe. Par ailleurs, le verbe « terminer » est bien plus fécond que le verbe « faire » pour engager les équipes dans des actions concrètes qui apportent de la valeur directement.

Enfin, nous créons ici avec la dernière question (comment nous organisons-nous ?) les conditions pour l’auto-organisation de l’équipe. Il s’agit d’une des promesses de l’agilité qui me semble un peu démagogique et qui peut aboutir à des décisions contre-productives comme vu précédemment. En revanche, créer les conditions de l’auto-organisation avec cette question me semble bien plus concret et vertueux.

Autre point essentiel sur la pratique Lean : au lieu de se retrouver en cercle pour dire ce qu’on a fait, on se retrouve devant le management visuel avec le suivi d’indicateurs. Ce support visuel permet lui aussi un meilleur alignement des équipes et un support de la conversation qui ancre sur des objectifs concrets.

Une des objections avancées contre cette approche du pilotage au quotidien est que les personnes qui ne travaillent pas sur quelque chose qui doit être livré aujourd’hui peuvent ne pas prendre la parole. Notre réponse est que cela contribue justement à inciter chacun à livrer régulièrement des petites pièces de valeur.

Extension à l’agilité à l’échelle

Dans le cadre de l’agilité à l’échelle avec des programmes agiles qui doivent livrer des Epics (fonctionnalité, agrégat de User Stories) nous nous poserons la même question lors du point de synchronisation hebdomadaire (ou mieux encore lors du Scrum de Scrum quotidien – le passage à l’échelle du Daily des équipes) : quelles Epics allons-nous terminer cette semaine ? Qu’est-ce qui pourrait nous en empêcher ? Il s’agit d’un questionnement puissant en particulier pour mieux synchroniser, en temps réel, les efforts de différentes équipes impliquées sur une même fonctionnalité et faire surnager les problèmes qui pourraient nous en empêcher.

Exemple d’application (REX)

Une équipe produit de 40 personnes, constituée de 5 squads. Dans cette équipe, 3 squads travaillent en Scrum (itération de 3 semaines) et 2 autres en Kanban. Avant la mise en oeuvre du Lean, l’équipe produit dans son ensemble a livré 3,8 US par semaine sur les 8 semaines précédentes (les méthodes étant mixtes - Scrum et Kanban, le suivi à la semaine est le plus pertinent).

Nous mettons en place un suivi hebdomadaire avec le manager produit et chaque squad leader pour suivre avec eux (planifier, mesurer) les US terminées chaque semaine. Le fait d’avoir ce suivi leur permet de mieux anticiper les obstacles qui pourraient survenir et d’éviter la dispersion (bloqué sur un sujet, les personnes sont tentées d’en terminer un autre).

Avec l’accompagnement lean, la moyenne des US livrées sur les 8 semaines suivantes est de 7 par semaine au lieu des 3,8 initiales, soit un gain de 81% (nous n’avons pas comptées là toutes les US qui étaient effectivement terminées mais non identifiées comme telles dans l’outil de suivi). Le Lead Time des US (temps de bout en bout) a réduit de 23% de 37,2J à 27,8J.

Pour ce qui est des Epics, nous sommes passés de 2,2 par mois (les 4 mois précédents l’accompagnement) à 4 par mois (une augmentation de 78%) avec un Lead Time qui a réduit de 43% et qui est passé de 112J en moyenne à 64J.

Et je vous renvoie encore une fois à un premier ReX avec l’article de Nicolas Ploquin pour avoir un ReX sur l’impact de ce changement de pratique sur le delivery mais surtout sur l’engagement des collaborateurs.

La démo de sprint (Sprint Demo)

Définition et objectifs

Celle-ci est intégrée dans le corpus de connaissance Scrum dans la Sprint Review mais comme dans cette session on traite à la fois la fin du processus (discussion autour du logiciel qui a été livré) et le début (préparation du sprint suivant), nous vous proposons de séparer les deux sections.

Voici la définition que donne Scrum Alliance de la démo :

> The demo is a meeting with the developers and stakeholders where the team demos what they accomplished during the sprint on the current product iteration, application, etc. The demo could include bug fixes, new features, or completed code and is an opportunity to demonstrate working user stories and get immediate feedback from stakeholders.

Pratiques observées

Il s’agit là probablement de la session qui prête le moins à commentaires ou remarques même si on observe des dérives bureaucratiques qui font que l’on voit présentées dans cet événement des slides, ce qui n’est pas vraiment recommandé.

Dans la plupart des cas que nous avons vus, les équipes présentent effectivement du logiciel et l’esprit de l’événement est plutôt bien respecté. Il arrive parfois que celui-ci soit buggé (on ne peut pas tester ce chemin métier car on a un bug) ou sans intégration (on présente avec des données factices, sans intégration aux API). On peut aussi constater des commentaires de parties prenantes qui ne sont pas particulièrement bienveillantes, et le rôle du management est clé pour s’assurer que les feedbacks des parties prenantes faits à l’équipe, en public, restent bienveillants (le fameux “praise in public, criticize in private”).

Pratiques Lean : la micro-démo

Un problème que nous observons toutefois est que se passe-t-il si le PO fait un feedback négatif sur une US qui a coûté plusieurs jours de réalisation (développement, test et intégration) ? Et bien nous avons là du gaspillage : du temps passé inutilement pour quelque chose qui était en écart avec l’attente du PO.

Extension à l’agilité à l’échelle

Une extension envisageable ici serait que le PO partage les feedbacks obtenus lors de la démo au client, une démo qui serait faite en flux pour chaque Epic plutôt qu’attendre la phase de recette métier. Ce genre de pratiques peut être compliqué à envisager en fonction de la nature de l’organisation mais nous observons, de plus en plus, dans les grandes DSI avec qui nous travaillons, cette intégration de représentants du métier au plus près des équipes, ce qui facilité ce genre d’initiatives.

Exemple d’application (REX)

Une superbe contre-mesure que nous avions mis en œuvre lors de ma première expérience de passage à l’échelle de l’agile, était la suivante : plutôt qu’attendre que les testeurs aient fait TOUS les tests en fin de sprint et valider en batch toutes les US en démo, dès que le développeur a validé le cas nominal, il propose une micro-démo de 10 mns aux parties prenantes (PO, testeur, UX si nécessaire) sur son poste pour valider que c’est bien ce qui est attendu. Si cette micro-démo est KO, il peut apporter les modifications et on a économisé le temps nécessaire à l’exécution de l’ensemble des tests. Si elle est OK, le testeur peut valider complètement l’US en sachant que le risque qu’elle soit rejetée par le PO (et/ou l’UX) est beaucoup plus faible : ce ne sera pas du temps perdu.

La rétrospective

Définition et objectifs

La définition de Scrum Alliance :

> The scrum event in which the team reflects on the past sprint. Areas for improvement are identified, and action items are carried forward into the next sprint.

Dans ce cas-ci, une définition qui n’est pas particulièrement spécifique, et qui laisse libre champs aux interprétations en particulier sur ce qu’est une amélioration ou comment on pilote les actions d’amélioration.

Pratiques observées

La pratique la plus courante est le tableau KISS : Keep (ce que l’on garde) ; Improve (ce qu’on améliore) ; Start (ce qu’on commence à faire) et Stop (ce qu’on arrête de faire). Durant cette session, ce que nous observons est que le Scrum Master et/ou le Coach Agile créent bien les conditions de la communication ouverte et de l’échange. Nous sommes moins impressionnés par les résultats (outcomes) de ces sessions en termes d'amélioration de la performance opérationnelle.

En effet, nous observons que l’objectif est moins de s’améliorer sur de nouveaux sujets (qualité, satisfaction client, delivery, etc …) que de tester de nouvelles manières d’animer cet atelier (dont une approche psychédélique). En ce qui me concerne je n’aurais aucun problème avec ces démarches si cela apportait effectivement des résultats concrets, ce qui n’est pas ce que j’ai observé.

Pratiques Lean

Dans le cadre du Lean, une rétrospective utilise les mêmes modalités d’animation : partir des résultats chiffrés du sprint et analyser les pièces en écart pour en comprendre les causes factuelles.

Ainsi le point de départ doit-être l’écart entre l’objectif de sprint, en nombre de “choses” terminées (US livrées, US prêtes pour le prochain sprint, Epic livrées, Epic, prêtes pour la prochaine échéance, spikes, incidents résolus, etc.). Et pour chacun des écarts on regarde chaque ticket pour comprendre ce qui s’est passé. Un exemple ici ou un autre ci-dessous :

• On avait prévu de livrer l’US 243-12 - et elle est au statut Intégration, qu’est-ce qui nous a empêché de la terminer ?
• En fait, lorsqu’on a intégré avec l’équipe Panther, on s’est rendu compte qu’on avait un problème ?
• Ah mince, que s’est-il passé ?
• En fait on pensait que le DataObject qu’on leur passait devait contenir que le sous-ensemble habituel que l’on retourne pour cet objet (qui est très gros). Pour nous c’était implicite, d’habitude il nous demandent juste le sous-ensemble, cela permet d’être plus performant et de limiter la bande passante utilisée. Mais pour une fois, ils avaient vraiment besoin d’avoir l’objet en entier.
• Du coup on leur livre quand la bonne version ?
• J’ai commité le code juste avant ce point, en sortant je regarde si le build est OK et je leur expose demain matin.
• Top! Bon et pourquoi on ne l’a pas vu avec nos tests automatisés ?
• Parce que dans les objets utilisés on n’a que ces données là, du sous-ensemble.
• Ok. On peut regarder leur Epic qui est liée à notre US ?
• Ah je ne sais pas où elle est
• Ben écoute je te propose qu’on remonte à partir de notre US dans l’outil
• Ah ouais, pourquoi pas. Maintenant ?
• Ben oui, viens on regarde
• Ah voilà Epic 243
• Que dit-elle de la nature de la donnée affichée ?
• Attends, je regarde : ah voilà ! Ah oui tiens, il faut l’ensemble de l’objet, c’est écrit ici.
• Ah intéressant ! Du coup qu’est-ce que cela dit sur la DoR des API qu’on expose ?
• Attends je regarde - ah oui il n’est pas précisé de distinction sur les DataObject transmis. En même temps on doit avoir que 2 ou 3 objets concernés sur les centaines de type qu’on retourne.
• OK aussi c’est plutôt “normal” qu’on ait eu ce problème. Comment peut-on faire pour corriger cela ?
• Bon ben on va juste demander au client s’il a besoin du DataObject réduit ou de l’objet complet lorsqu’on retourne ce type d’infos.
• *OK parfait, je te laisse mettre la DoR à jour tout de suite ? *

Le point clé ici est que l’on prend un sujet spécifique (une US qui livre un service métier et qui n’a pas pu être intégré) pour identifier une contre-mesure actionnable rapidement (mise à jour de la DoR des US API). C’est ainsi que graduellement, sprint après sprint, problème après problème, on rend les standards de l’équipe plus robustes et son savoir-faire explicite.

Bien sûr, théoriquement, on pourrait aussi parvenir à ce résultat avec une rétrospective standard. De fait j’ai assisté à des rétrospectives de dizaines et dizaines d’équipes et je n’en ai vu qu’une poignée qui arrivaient à des choses concrètes et actionnables telles que celle-ci en séance.

On procède de la même manière pour analyser en binôme ou trinôme une à une des anomalies remontées par le testeur ou le PO pour en comprendre la cause, et voir ensemble ce qu’il faut modifier sur notre processus interne. Dans ce cas, sur notre façon d’animer les ateliers Tres Amigos de Georges Dinwiddie, une excellente pratique pour aligner les visions de ces trois rôles. L’objectif est moins de traiter tous les sujets qu’en traiter quelques-uns de façon complète.

Extension à l’agilité à l’échelle

De manière symétrique, on peut étendre cette rétrospective agile à une rétrospective de programme agile (avec les rôles cadres - Scrum Master, Product Owner, testeurs, UX, architectes, Lead Tech) et analyser les causes des Epic (ensemble de cas d’utilisation - User Stories) qui étaient prévues sur le sprint et qui ne sont pas sorties.

On peut rendre alors visibles des problèmes d’intégration et améliorer les standards de réalisation d’Epic :

1. la Definition Of Ready qui liste l’ensemble des validations à effectuer pour ce qui de l’analyse fonctionnelle et de la conception technique à mener avant la phase de réalisation ;
2. La Defintion of Done : qui liste l’ensemble des validations à effectuer pour s’assurer que la fonctionnalité entière est prête à être livrée aux clients : tests d’intégration techniques et métier mais aussi de performance (volumétrie, charge etc …)

On peut aussi profiter de ces sessions pour faire une passe sur les Epic livrées lors des sprints précédents et valider les hypothèses de valeur business émises dans l’Epic Canvas : observe-t-on une réduction du taux d’attrition ? Une augmentation du nombre de nouveaux clients ? Une amélioration de la note dans les dernières évaluations sur l’AppStore ? Cette validation des hypothèses métiers est un moment privilégié pour rapprocher les équipes techniques et métiers et faire le lien avec les OKRs du produit.

Exemple d’application et ReX

Une équipe agile de 8 personnes qui livrent des fonctionnalités pour une application mobile d’agents terrain dans le monde de l’Energy & Utilities.

Sur les 8 sprints avant l’accompagnement, l’équipe n’a sorti en moyenne que 14,1 US par sprint alors qu’elle en prévoyait en moyenne 24 : le taux d’engagement (ratio livré / prévu) est à 56%.

Jusqu’alors, l’équipe a des rétrospectives « standards ». Elle décide d’essayer les rétrospectives Lean et de regarder, US par US les causes de non succès dans le sprint.

Elle se rend compte que différentes causes émergent :

· Une US est KO car la règle métier n’est pas rappelée dans sa description. Cette règle est implicite dans l’esprit de la PO mais pas du tout dans celle du développeur qui a rejoint l’équipe récemment ;

· Une US n’a pas de critère d’acceptance car la PO n’a pas jugé cela nécessaire en raison de sa simplicité ;

· Deux US sont parties en réalisation alors qu’elles n’étaient pas conformes à la DoR ;

· Une US avait des hypothèses implicites : une fonctionnalité est ainsi prise en compte pour tous les opérateurs de recherche lorsqu’un seul était requis ;

· Etc …

En travaillant avec l’équipe sur chacun de ces sujets spécifiques sprint après sprint, , l’équipe a rendu plus explicites les définitions de ses US, développé les compétences plus profondes de chacun sur son poste de travail, et a amélioré son delivery.

Sur les 10 sprints suivants, le delivery de l’équipe est ainsi passé en moyenne à 18.3 US/sprint (au lieu de 14,1) avec un taux d’engagement qui est passé à 92% (au lieu de 56%), ce qui représente une amélioration du valeur opérationnelle livrée de 29%. Mais là encore, au-delà du chiffre, la résolution de ces problèmes a aussi apporté une bien meilleure et fructueuse relation entre les membres de l’équipe.

Un second souffle

Nous observons aujourd’hui chez de nombreux clients, indépendamment de leur maturité en agilité, que ceux-ci bénéficient d’un second souffle dans leur organisation agile grâce à la mise en œuvre de pratiques Lean.

Si la transformation agile a permis de travailler sur la lisibilité de l’organisation, une meilleure collaboration des équipes et une prise de conscience de l’importance des soft skills, les pratiques Lean permettent d’aller plus loin, et de façon complémentaire, en se concentrant sur les dimensions opérationnelles et les hard skills des collaborateurs.

Qu’attendriez-vous d’un nouveau souffle pour votre transformation agile ?

Mille mercis à Jean-Michel L. pour m’avoir donné l’idée de cet article ainsi qu’à Olivier Bras et Samuel Ahnine pour leurs relectures minutieuses et leurs commentaires de qualité.