Les pratiques Lean pour revenir aux sources de l’agilité (1ere 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 de Toyota) 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.

• Première partie : Agilité et amélioration continue : le malentendu
• Deuxième partie : Pratiques Lean pour revenir aux sources de l’agilité (première partie : Préparation du Sprint ; Sprint Planning)
• 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é. ]

Introduction

Aux sources de l’agilité

J’ai découvert l’agilité en rejoignant une start-up à l’été 2004. Je venais du monde des gros systèmes IBM et je trouvais cette approche passionnante : des livraisons mensuelles en production ; des pratiques d’ingénierie logicielle poussées avec des tests automatisés, de l’intégration continue et un focus sur la qualité du code ; une architecture très agile basée sur des web services légers (XML-RPC) permettant de livrer de nouvelles fonctionnalités à nos partenaires en quelques jours.

Je trouvais admirable la vitesse avec laquelle cette équipe livrait de nouveaux services business innovants de qualité dans le monde naissant du mobile. J’avais l’impression qu’ils travaillaient dix fois plus vite que ce que j’avais pu faire jusque là : j’étais fasciné et je décidai de plus jamais travailler autrement.

Il y a sans doute là un regard nostalgique qui romance un peu cette vision mais si on regarde bien, le premier principe de l’agilité c’est bien cela : satisfaire le client avec des livraisons régulières et rapides de logiciel représentant de la valeur. Les histoires fondatrices telles que celle du système Chrysler C3 nous rappellent comment la simplicité de l’agilité et la discipline des pratiques d’ingénierie ont permis de résoudre, en équipe, des problèmes qui semblaient jusque-là insurmontables.

C’est pour cette raison que j’ai toujours privilégié une vision (et une définition) opérationnelle de l’agilité plutôt qu’une vision organisationnelle qui a largement pris le dessus ces dernières années.

L’objectif de cet article est de montrer, en illustrant avec plusieurs exemples terrain, comment la mise en œuvre du Lean (celui de Toyota) 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.

Pour revenir aux sources, nous reviendrons aux définitions de ScrumAlliance [recommandation de professionnel : allez chercher vos sources sur les sites originaux en anglais, et certainement pas sur les sites traduits en raison de la perte en ligne]. Je vois déjà arriver l’objection selon laquelle “Scrum ce n’est pas l’agilité mais une partie seulement”, objection valide que je rejetterais cependant pour le motif que, dans les faits, l’immense majorité des dispositifs agiles que nous voyons chez nos clients sont du Scrum ou un mix Scrum et Kanban qui intègre l’essentiels des pratiques agiles discutées ici (démo, rétro, revue de backlog, rétrospective etc…).

Agilité dans les grandes entreprises : dérive et éloignement de la source

20 ans plus tard, lorsque je retrouve des équipes “agiles” chez nos clients, c’est rarement cette même vision que j’observe en action. Avec l’avènement de la transformation numérique dans la seconde partie des années 2010, l’agilité est devenue le mode d’organisation par défaut des équipes de développement logiciel.

L’agilité a sans conteste permis de créer de meilleures conditions de collaboration et de travail sur l’ensemble de la chaîne de valeur pour les développeurs, les Product Owners (PO), les Ops (opérations), les testeurs etc …, en travaillant sur les soft skills des équipes. On a pu enfin sortir de cette vision, inimaginable chez les géants du numérique, dans laquelle les développeurs sont vus comme des personnes qui “pissent du code”.

Pour autant, les clients qui nous sollicitent nous expliquent bien souvent qu’ils n’ont pas le sentiment que cela a impacté de façon significative l’efficacité des équipes ou la qualité des logiciels livrés. C’est pour cette raison qu’à travers le management Lean et le Kaizen, ils recherchent de nouveaux leviers d’amélioration de l’efficacité et de création de valeur pour leurs clients internes et externes.

Il convient de conserver à l’esprit que nous partons ici non pas de la théorie telle qu’elle est définie mais de ce que nous avons constaté avec les dizaines d’équipes que nous avons accompagnées sur le terrain. Le fait que les clients nous sollicitent pour les aider dans la difficulté peut apporter un biais : celui d’équipes dans lesquelles l’agilité ne fonctionne pas ou plus si bien. Cela ne veut pas dire que c’est le cas de toutes les équipes. Il n’en demeure pas moins que cela reste la réalité opérationnelle dans ces équipes tech vues dans des industries aussi différentes que Energy & Utilities, e-commerce, media, défense, services financiers, luxe, services publics etc …

The Knowing-Doing Gap : penser contre soi

La dérive graduelle des pratiques initiales est très souvent une des explications de ce questionnement. Petit à petit, l’équipe perd le sens des pratiques, s’écarte de la source de ce qui leur a été montré et l’entropie de l’organisation fait son chemin. C’est ainsi que l’on arrête le point quotidien (daily) parce que l’équipe n’y trouve plus de sens ; que les rétrospectives ne sont pas sur des problèmes opérationnels spécifiques ; que l’objectif du sprint n’est plus donné en objectifs SMART ; que l’on pilote le delivery avec des indicateurs abstraits (story points) ; que les US ne sont plus INVEST ; et bien sûr qu’on applique les “principes” tayloristes et contraignant d’une agilité à l’échelle, que dénoncent publiquement les fondateurs initiaux du manifeste, et dans lesquels la ligne managériale retrouve avec plaisir les éléments de pilotages de projet auxquels elle était précédemment habituée.

Pour ce qui est de cet écart endémique entre la théorie et la pratique dans l’entreprise, je ne saurais trop recommander de lire le formidable ouvrage de Bob Sutton et Jeffrey Pfeffer The Knowing-Doing Gap. Dans cet ouvrage les auteurs expliquent qu’une des raisons qui explique le difficile passage du savoir à l’action est que l’on a parfois tendance à survaloriser ce qui est difficile à comprendre et sous-valoriser ce qui est facile à comprendre mais difficile à mettre en œuvre. C’est exactement le cas de nombreux principes agiles ou de principes Lean.

Ainsi, la vaste majorité des Scrum Masters ou des agilistes convaincus vous diront qu’ils connaissent le Plan Do Check Act (PDCA), le moteur de l’amélioration continue. Mais ils seront bien en peine de raconter un exemple précis de PDCA qu’ils ont mené avec les équipes et des apprentissages validés qu’ils en ont tirés. Car sous son apparente évidence, le PDCA requiert une rigueur de réflexion éprouvante à mettre en œuvre. Il s’agit de l’approche scientifique adaptée au monde de l’entreprise. Une approche qui nous impose de penser contre soi comme l’explique Gaston Bachelard ; une approche qui a pour objet d’aller à l’encontre de nos fausses croyances, sujet au cœur des deux premiers chapitres du Workplace Management de Taiichi Ohno.

La rétrospective n’est pas de l’amélioration continue

L’argument que nous entendons le plus souvent est un syllogisme contestable : “nous faisons de l’agilité (et des rétrospectives), donc nous améliorons l'efficacité de l’équipe”. Hors, ce n’est pas parce qu’une équipe se donne les moyens (à travers un événement agile dédié au sujet - la rétrospective) que cette équipe s’améliore. Une équipe s’améliore si elle mesure un résultat positif à la suite de la mise en œuvre de ces nouvelles pratiques.

Cela rejoint une vision un peu démagogique qui présuppose que l’équipe SAIT comment faire (pour livrer de la valeur, pour s’améliorer etc …). On retrouve ici en action le fameux “we hire smart people so they tell us what to do” démagogique de Steve Jobs qui, dans les faits, n’est pas du tout, mais alors pas du tout, appliqué par sa Steveness comme l’explique un de ses collaborateurs dans cet article du Guardian.

C’est cette hypothèse même que le scepticisme empirique du Lean remet en cause, ce qui bouscule un peu la vision bienveillante de l’agilité qui ne sait pas nécessairement mettre l’équipe face à ses manquements opérationnels. L’angle mort étant ici que ce n’est pas parce que l’on rend visible un problème à l’équipe qu’on lui manque de bienveillance. Tant que l’on mobilise toutes les parties prenantes pour travailler ensemble sur la solution au problème (plutôt que leur imposer une solution), nous sommes dans le respect des personnes, cher à Fujio Cho : Go see, ask why, show respect.

L’amélioration a ceci d’inconfortable qu’elle nécessite de la mesure. Cela peut sembler un peu étonnant d’avoir à le rappeler, mais si nous ne nous mesurons pas, nous ne savons pas si nous nous améliorons. Par ailleurs, ce que nous mesurons dans le Lean (la performance) doit faire du sens pour le client : valeur (opérationnelle et business) ; qualité ; coût ; délais. Et ces indicateurs doivent pouvoir être à la main de l’équipe.

Cela ne veut pas dire que la rétrospective est inutile, il me semble plutôt sain que l’équipe ait un espace d’échange ouvert sur sa façon de travailler. Mais l’essentiel des rétrospectives auxquelles j’ai assisté avaient bien peu à voir avec l’amélioration continue, la mesure et la validation de ce qui a été testé. Comme l’explique Leo Tranter sur le blog ExtremeUncertainty, la rétrospective n’est pas de l’amélioration continue. Cela ne veut pas dire que ces échanges ouverts et plutôt bienveillants sont inutiles mais que l’on n’est pas sur le sujet de la performance ou de la satisfaction client.

Performance opérationnelle : l'angle mort de l'agilité

On peut identifier des causes dans le peu de publications scientifiques sur le sujet (recherche google sur "Agility and IT organization operational performance"). Incidemment, la majorité des études sur l'agilité et la performance se retrouvent dans des contextes manufacturiers et parlent de ... Lean.

Un exemple assez révélateur : l'organisme de certification en Project Management (PMI) propose une bibliographie pour la certification Agile (PMI-ACP). L'ouvrage de référence pour la rétrospective est celui de Esther Derby et Diana Larsen : Agile Retrospectives - Making Good Teams Great. Dans l’édition de 2006, à aucun moment n'est évoqué le sujet de la performance opérationnelle de l'équipe.

Les seules références à la performance évoquées sont celles qui critique, à raison, la performance individuelle, héritage encombrant du Management by Objectives de Peter Drucker (évoqué dans son ouvrage The Practice of Management), contre lequel s'est maintes fois élevé Edward Deming, en particulier dans son ouvrage Out of the Crisis.

L'exemple que donne le livre Agile Retrospectives dans l'utilisation des Five Why (fameuse approche Lean de recherche de cause racine) est : "Why did we start our review meeting late on Thursday ?". On voit que nous sommes ici dans une réflexion sur le processus Scrum non pas en tant que producteur de valeur pour le client, mais en tant que conformité à sa vision théorique.

Pour ce qui est des indicateurs à utiliser, les auteures proposent une liste longue comme le bras (20 au total), mélangeant les indicateurs opérationnels et business, laissant aux équipes le choix de choisir les bons. Un peu à la manière de Microsoft qui propose des centaines de fonctionnalités sans concevoir ou proposer les solutions de telles sortes à mettre les plus utiles en avant. Dans le Lean il n’y en a que 4 pour la performance opérationnelle : coûts (ou delivery), qualité, délais, satisfaction client.

Notons enfin que dans cette édition (2006) de l’ouvrage, la satisfaction client n'est pas non plus évoquée.

Si dans la publication de référence sur l'amélioration continue du corpus agile on ne retrouve pas de référence explicite et actionnable à la satisfaction client ou la performance opérationnelle, comment les équipes agiles peuvent-elles intégrer ces notions dans leurs réflexions régulières sur l'amélioration continue ?

Agilité et amélioration continue : le malentendu

Voilà un fréquent sujet de crispation que nous (coachs lean) rencontrons avec les équipes agiles dès lors que nous posons des questions sur la mesure : quels sont les éléments factuels et chiffrés qui vous permettent de déterminer que l’équipe s’améliore ?

Dans le meilleur des cas, l’équipe suit sa vélocité (nombre de story points livrés par itération - voir cet exemple d’un programme de 500 personnes dans le monde du e-commerce : un pure player donc). On retrouve ici cette vision centrée sur l’équipe : on pilote un indicateur qui représente la complexité perçue par l’équipe des cas d’utilisation livrés durant le sprint. Malheureusement, cet indicateur n’a aucun sens depuis la perspective du client car ce qui importe pour ce dernier est la valeur livrée (i.e. le nombre de cas d’utilisation livrés sans défaut). Par ailleurs, cet indicateur peut facilement être “manipulé” sans que personne d’extérieur à l’équipe puisse valider quoi que ce soit (il s’agit d’un indicateur interne). Pour ce qui est de la valeur métier, nous n’accordons aucune valeur à la business value agile - hypothèse de valeur- que je n’ai jamais vue validée a posteriori (voir une discussion approfondie sur ce sujet dans l’article Regard Lean sur la productivité des programmes agiles)

Sur le sujet de la qualité, sur les 120 équipes avec qui j’ai travaillé, celles qui pilotaient leur qualité (i.e. prenait des actions spécifiques pour réduire telle ou telle cause d’incident et en mesurer l’impact) avant la mise en œuvre du Lean peuvent se compter sur les doigts d’une main.

Designer le travail pour le Kaizen

Le Lean promeut le Kaizen pour ce qui est de la stratégie d’amélioration continue. Le Kaizen, tel que défini par Masaaki Imai dans son ouvrage originel Kaizen - The Key to Japan Competitive Success, signifie des petites améliorations, par chacun, chaque jour.

Tout l’objet du management Lean est de proposer un système de management (management de la production et management des compétences) qui rende facile et incontournable ce travail de Kaizen.

L’expert Lean Paul Dunlop parle ainsi volontiers du Lean en tant que design du travail dans le but de :

• Clarifier les conditions de réussite avec les objectifs de production au quotidien ;
• Rendre visibles les gaspillages avec le management visuel et les bons indicateurs de performance opérationnelle (coûts, qualité, délais, satisfaction client) ;
• Mettre chacun en situation de livrer une bonne pièce du premier coup ;
• Que chacun soit habilité à traiter des problèmes sur le champ (avec la démarche structurée PDCA - le diable est dans le détail) et améliorer son cadre de travail.

Le sujet est moins de choisir les outils que l’on va utiliser pour travailler mais d’utiliser les outils du Lean pour mieux choisir les problèmes sur lesquels travailler pour progresser ensemble et mieux satisfaire le client.

Pour accomplir cette vision, le Lean propose un pilotage à haute fréquence de la performance (indicateurs) et de la production (pièces livrées au client sans défaut) : ce rythme quotidien de pilotage crée les conditions du Kaizen. En effet, l’équipe s’engage à atteindre tel objectif ou livrer telle pièce : l’écart entre ce qui était prévu et ce qui a été livré au client représente une opportunité de questionnement et un gisement d’amélioration et de Kaizen. Un pilotage opérationnel à haute fréquence permet de faire apparaître de nombreux petits écarts spécifiques et donc de multiples petites opportunités d’amélioration et d’apprentissage, chaque jour.

Maintenant que nous avons évoqué le problème (l’écart entre les principes originels de l’agilité et leur mise en œuvre effective dans les grandes entreprises), la deuxième partie de cette série va vous proposer de voir dans les faits, cérémonie par cérémonie, comment le Lean et le Kaizen contribuent à la réduction de cet écart et à revenir aux principes de l’agilité pour donner un second souffle à votre transformation agile.