Les pratiques Lean pour revenir aux sources de l’agilité (2è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é 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 partie : 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é. ]

Pratiques Lean pour revenir aux sources de l’agilité

L’objectif de cette seconde partie de l’article est de vous montrer comment hacker vos évènements Agiles existants pour intégrer les principes Lean afin d’améliorer la satisfaction de vos clients, la mobilisation de vos collaborateurs sur des sujets concrets d’amélioration et la performance opérationnelle. En d’autres termes : pour répondre aux enjeux originels de l’agilité.

Nous vous proposons de parcourir ces pratiques selon une vision flux de valeur :

1. Préparation du sprint et analyse du backlog
2. Planification du sprint
3. Animation du sprint
4. Revue de sprint (démo)
5. Rétrospective

Dans chacun des cas nous verrons comment les outils originels de l’agilité sont peu ou mal utilisés sur le terrain (la sédimentation des nombreuses “adaptations” aux contextes de l’équipe) et que dès lors qu’ils sont mis en œuvre convenablement, alors la performance redevient positive.

Nous étendrons les champs de notre réflexion à l’agilité à l’échelle en nous appuyant sur la dimension fractale que nous avons proposée dans un autre article.

Pour chacune de ces pratiques on pourra nous objecter que c’est déjà ce que propose Scrum. Une objection en partie valide à ceci près que, comme nous allons le voir, les termes proposés par Scrum sont plutôt génériques et laissent une grande latitude d’interprétation (et donc d’entropie et de gaspillages).

Et nous verrons que les pratiques Lean vont droit au but sur ce sujet grâce à ce focus évoqué précédemment de design du travail qui rend évidentes les bonnes questions. Si j’osais - car la réalité historique est tout autre - je dirais que le management Lean est une parfaite implémentation des frameworks Scrum ou Scrum à l’échelle et c’est pour cela qu’il permet de revenir aux sources de l’agilité. A ce sujet, Kent Beck a expliqué lors du Lean Digital Summit de 2015 que s’il avait lu Taiichi Ohno, il aurait gagné 10 ans dans sa réflexion sur Extreme Programming.

Enfin nous illustrerons chacune des pratiques par un exemple terrain pour montrer l’apport de cette approche inductive (partir du terrain et tirer des enseignements) plutôt que déductive (partir de la théorie et mettre en œuvre sur le terrain).

Préparation du sprint et analyse du backlog

Objectif et définition

Dans cette phase, l’objectif est de passer en revue l’ensemble des sujets candidats et de circonscrire précisément les sujets sur lesquels l’équipe va travailler sur la prochaine itération (e.g. sprint - de 2 à 4 semaines).

À la lumière de la revue effectuée au terme du sprint précédent, l’équipe va converger vers de nouvelles fonctionnalités à réaliser et livrer. Ceci étant un entrant du sprint suivant, nous proposons de l’évoquer ici en premier.

L’équipe peut travailler sur plusieurs types de sujets : des cas d’utilisation métiers (les User Stories) ; des développements techniques (ou Technical Stories) ; des résolutions d’incidents (Bug Fixes) ; des prototypes ou expérimentations techniques (aka Spike).

Pour ce qui est des User Stories, unité d’oeuvre opérationnelle qui représente de la valeur pour le client, un des principes de l’agilité est que l’on ne fait entrer en phase de réalisation que les sujets qui ont été suffisamment analysés et conçus et qui répondent à la Definition of Ready (DoR) de l’équipe. Cette définition correspond à une checklist définie puis enrichie par l’équipe à mesure qu’elle rencontre et corrige des problèmes. Dans le Lean on parlerait d’un standard. À titre d’exemple :

• Les critères d’acceptation de la réalisation de la User Story ont été définis par le Product Owner (PO) lors de la conception fonctionnelle (ce qui permet de mettre le développeur en autonomie pour valider s’il a produit de la qualité) - on préconise l’utilisation d’une approche Behavioral Driven Design avec des exemples très concrets) ;
• La story répond aux critères INVEST : Indépendante, Négociable, Valorisable, Estimable, Small (petite) et Testable

Pratiques observées

Ce que nous observons dans les équipes que nous accompagnons.

1. La Definition of Ready a été conçue par l’équipe au tout début de son histoire et n’a pas été revue depuis. Taiichi Ohno rappelle dans Workplace Management qu’un standard qui n’est pas mis à jour est une bonne indication que l’équipe ne travaille pas sur de l’amélioration continue (il le voyait rapidement en parcourant l’usine à ce que les feuilles de standard affichées dans l’espace de l’équipe avaient un peu jauni) ;
2. L’équipe n’utilise pas la DoR. Celle-ci a été définie avec les éléments précités mais n’est pas utilisée à chaque sprint. Cela a des conséquences très concrètes : une incompréhension entre le développeur et le PO sur ce qu’il faut développer ; entre le développeur et le testeur sur les cas de tests ; 5 critères d’acceptance ont été définis par le PO mais seuls 3 ont été validés par le développeur, etc …

Pratiques Lean

Comme évoqué précédemment, depuis la perspective Lean, la Definition of Ready est un standard. C’est un outil robuste qui permet à l’équipe de s’accorder sur le niveau de qualité en entrée du sprint et donc sur la capacité des équipes à livrer bon du premier coup et à s’arrêter au défaut (le pilier Jidoka). Travailler avec l’équipe sur ce standard, à la lumière des anomalies rencontrées durant le sprint, est un levier majeur pour améliorer la qualité et donc l’efficacité de l’équipe. Cela a un autre effet : en clarifiant la communication, cela améliore aussi la dimension relationnelle.

Une risque fréquemment remonté par les équipes agiles à ce sujet est que cette approche peut ressembler à un stage-gate process relativement rigide, alors que l’agilité promeut une dimension organique basée autour de la collaboration. Une objection compréhensible mais je dispose littéralement d’une vingtaine d’études de cas dans lesquelles travailler sur ce sujet a permis à l’équipe de livrer entre 30 et 80% de valeur en plus et, surtout, d’améliorer la relation entre les collaborateurs.

Extension à l’agilité à l’échelle

On peut étendre cette vision au niveau des Epics (ensemble de cas d’utilisation - User Stories - représentant une fonctionnalité). Et une Epic ne rentrera en phase de réalisation que si elle répond aux critères de la Definition Of Ready de l’Epic définis par les équipes, là encore une DoR qui est mise à jour régulièrement suite aux problèmes rencontrés dans la réalisation de cette fonctionnalité. Et là encore nous disposons de nombreux retours d’expérience concrets et chiffrés montrant les bénéfices de cette approche.

Retour d’expérience

Une équipe intégration d’un éditeur logiciel proposant des solutions de Digital Asset Management. Le CEO de cette PME Tech est contraint de freiner ses commerciaux car l’équipe n’arrive pas à livrer les projets d’intégration de cette solution pour ses différents clients, qui peuvent être des institutions publiques, des constructeurs automobile ou des grandes enseignes du retail. Le regard Lean permet de poser le problème de façon claire : sur les 12 dernières semaines, en moyenne, l’entreprise a recruté 3 nouveaux clients par semaine mais n’a livré que 2 projets d’intégration par semaine. L’objectif est donc chaque semaine de livrer 4 projets (afin de répondre à la demande client et d’épurer le stock).

Avec une analyse Lean on observe que près d’un tiers des projets prévus d’être livrés et qui ne l’ont pas été sont à plus d’un tiers causés par des demandes de modifications tardives du métier sur des règles de gestion ou la composition des écrans.

L’équipe décide alors de ne faire entrer en réalisation pour la semaine suivante (l’équipe travaille en Kanban et suit semaine par semaine ce qu’elle livre) que les sujets pour lesquels la phase de Discovery (conception fonctionnelle et technique) est terminée. Le mercredi d’avant est la date limite : au-delà de cette date les chefs de projets ne peuvent plus soumettre de sujets en réalisation pour la semaine suivante.

Comme l’équipe est passée en flux tiré (elle définit chaque semaine sur une fenêtre de 4 semaines les sujets à terminer) on peut suivre chaque semaine l’écart entre ce qui était prévu et ce qui est livré : cette cause de problème fonctionnel ne se présente plus et l’équipe peut alors passer au sujet suivant (des problèmes de qualité dans la réalisation voir le Rex complet ici).

Le résultat est que l’équipe est passée de 2 projets livrés par semaine à 2,5 puis 3,5 puis 4,5 avec le même nombre de personnes. Le CEO a pu à nouveau encourager ses commerciaux à démarcher à nouveau. Lorsque vous livrez 2 fois plus de projets avec le même nombre de personnes alors que votre entreprise est juste bénéficiaire, le CA gagné en plus est de la pure marge.

Planification du Sprint (Sprint Planning)

Objectif et définition

Durant cette cérémonie, l’équipe de réalisation définit ce sur quoi elle s’engage pour l’itération qui démarre. Elle établit une adéquation entre sa capacité et la liste de sujets qu’elle va pouvoir traiter sur les 2 ou 3 semaines à venir (User Stories fonctionnelles, correction d’anomalies etc …)

Pratiques observées

Lorsque nous nous immergeons au sein des équipes, une des premières questions que nous posons est liée aux critères de réussite. Comment savez-vous que vous aurez réussi votre itération ? Là encore nous retrouvons fréquemment un anti-pattern dans lequel l’objectif est défini sous forme de phrase - exemple avoir avancé sur la fonctionnalité F-23 ou avoir réduit le stock d’incidents.

Il est possible qu’au début de leur mise en oeuvre de l’agilité, les objectifs étaient définis de façon chiffrée et, comme nous le constatons souvent, les pratiques se sont un peu délitées pour arriver à des objectifs d’itération qui ne sont aujourd’hui plus SMART (Simples, Mesurés, Atteignables, peRtinents, Temporellement définis) en raison de l’entropie des systèmes sociaux-techniques.

Quoi qu’il en soit, lorsque nous posons ces questions à des équipes agiles sur les critères de réussite des itérations, nous constatons que ces objectifs se déclinent en perspectives peu claires au niveau des équipes.

On pourrait présupposer que le contenu du sprint (i.e. le nombre de cas d’utilisation et de corrections d’incident intégrés dans l’itération en cours) est l’objectif implicite que s’est donné l’équipe. Malheureusement ce n’est, bien souvent, pas le cas et ce pour plusieurs raisons :

1. Des équipes “surchargent” le contenu du sprint, avec pour hypothèse qu’ainsi on évite la rupture de charge. Conséquence : cela va inciter les équipes à démarrer des sujets plutôt que finir ceux en cours dès qu’ils sont bloqués : on augment le WiP et on réduit ainsi la valeur opérationnelle livrée ;
2. Des équipes dérogent aux S (Small - i.e petit) du principe INVEST avec des User Stories dont la réalisation est trop lourde pour tenir en un sprint. Conséquence : des US avec effets tunnels avec lesquelles on va réaliser après 30 jours d’effort (au lieu de 5 ou 6) que ce n’est pas la bonne réalisation ;
3. Des équipes font des batchs de plusieurs sprints de réalisation avant de tester afin d’intégrer toutes les fonctionnalités et éviter d’avoir des régressions. Et l’objectif du sprint est alors limité à la phase de réalisation mais pas celle de tests et d’intégration. Conséquence : des régressions en raison de la durée des branches de développement de plusieurs semaines qui vont rendre le report de ces modifications sur le tronc plus long, laborieux et sujet à de multiples erreurs.

Pratiques Lean

Créer les conditions de la réussite est une des clefs du management Lean. Dans le cas des équipes agiles on va donc définir l’objectif de sprint sous forme SMART : réduction de 5% du nombre d’incidents ouverts en stock ; livraison de 12 User Stories terminées ; 12 autres User Stories prêtes pour réalisation selon la DoR pour le sprint suivant.

Cela représente l’avantage d’être clair et compréhensible par tous. Mais surtout cela permet, en le rappelant lors du point matinal (le Daily Scrum, voir section suivante), de mettre l’équipe en situation de prendre des décisions éclairées tout au long de la journée.

Par ailleurs, on ne va pas intégrer de tâches supplémentaires « au cas où » afin d’éviter de créer les conditions d’une augmentation de l’en-cours. Si l’équipe termine tout ce qu’elle a prévu avant la fin de l’itération, elle rajoute alors des sujets et se questionne sur cet écart pour comprendre les causes de sa mauvaise estimation initiale.

Extension à l’agilité à l’échelle

D’une manière analogue à celle évoquée en section précédente, dans le cadre de l’agilité à l’échelle nous recommandons de donner des objectifs de livraisons d’Epic par unité de temps : Incrément Produit (Product Increment - aka PI) dans le cas d’un train ; semaine ou mois dans le cas d’un programme agile. Là encore, cet objectif permet d’alimenter l’autonomie des équipes et de leur permettre de prendre les bonnes décisions pour répondre à cet objectif.

Exemple d’application (ReX)

Une R&D Logiciel d’une centaine de personnes avec 8 domaines et 15 équipes. Cette équipe ne livre pas la valeur attendue : les projets sont en retard, les clients se plaignent de problèmes de qualité.

En regardant de plus près le pilotage de la performance opérationnelle, on se rend rapidement compte que lors des lancements des trimestres, les équipes évoquent les sujets sur lesquels elles vont travailler mais on ne voit pas d’objectif chiffré ni d’engagement chiffré sur les sujets terminés dans la définition de ces objectifs.

La conséquence est que la direction et les équipes constatent en fin de trimestre des sujets qui ne sont pas terminés comme initialement prévu. Lorsque nous avons démarré le projet, la direction a livré sur les deux précédents trimestres 19 et 26 Epics. Les objectifs sont tellement flous qu’il nous est impossible de déterminer quel était l’objectif réel sur chacun de ces deux trimestres en termes d’Epics terminées.

Nous mettons alors en place ce partage de la vision des objectifs sous forme chiffrée et le suivi hebdomadaire avec le directeur et les managers. Sur le trimestre de notre accompagnement, ils ne livrent que 23 Epics sur les 32 prévus mais la pratique est intégrée et le directeur et le manager apprennent à challenger leurs équipes sur ce sujet et le pilotent au quotidien.

Sur le trimestre suivant (après notre départ), l’équipe managériale a poursuivi cet effort et cette même direction livre 36 Epics : la moyenne des 2 trimestres avec le Lean (23 et 36 – soit 29,5) est de 31 % supérieure à la moyenne des deux trimestres avant (22,5). Les Product Managers et Engineering Managers ont intégré cette pratique avec succès. Et l’ensemble de la direction (de 100 personnes) livre 31% de valeur en plus à ses clients soit l’équivalent de 31 ETP.

Dans la troisième partie de cet article nous continuons cette analyse avec les pratiques de l’animation quotidienne du Scrum (ou du Kanban) ; la démo ; et la rétrospective.