Agile et Lean – la complémentarité d’un vrai binôme

Agile et Lean – la complémentarité d’un vrai binôme

En 2007, alors qu’Operae sponsorisait la 1ère conférence “Agile France”, les développeurs de cette époque lointaine se demandaient si l’agile n’était, au fond, pas autre chose que du lean management appliqué au monde du logiciel.

Ne créons pas de suspens : la réponse est définitivement non et beaucoup d’entreprises peuvent en témoigner.

Cet article vise à expliquer comment les deux démarches agile et lean se ressemblent mais surtout en quoi la seconde sécurise la réussite de la première.

Agilité – une transformation radicale

Le consensus n’est pas total en ce qui concerne la définition du “développement agile de logiciel”, les entreprises ont des pratiques variées, les posts publiés sur Linkedin permettent de lister des approches différentes. J’en appelle à l’indulgence du lecteur si sa définition est différente de la mienne.

Pour ma part, je retiens celle d’Yves Caseau, DSI du groupe Michelin au Lean Digital Summit :

« L’agile, en synthèse :
De petits lots itératifs (time-boxed sprints)
Une attention concentrée sur la livraison de valeur et la mesure de la satisfaction des clients
Des équipes autonomes, auto-organisées, “cross fonctionnelles” qui vont développer ensemble le design, le code et l’architecture du logiciel
Du travail d’équipe synchronisé avec une préférence pour la communication en face à face.”

L’installation de ces 4 pratiques représente un effort considérable pour les DSI des entreprises, les R&D des éditeurs et les responsables de prestation chez les ESN. Toute l’industrie du logiciel doit revoir ses méthodes de travail, ses outils, ses interactions, la structure de ses locaux, les modes de contractualisation, les rôles de chacun, les relations entre les individus, etc… L’accompagnement des collaborateurs vers une organisation agile représente un investissement massif pour qu’ils retrouvent leurs marques dans un environnement de travail différent : communication, formation, coaching, les moyens mis en œuvre sont toujours importants.

Cette période de transition prend fin, à un moment ou à un autre. Et là, force est de constater que la fin du cycle en V ne tient pas toujours ses promesses. Ce qui est parfaitement normal :

1. Les difficultés rencontrées avant le déploiement de l’agilité persistent après :

Exemple : Une entreprise du web propose de mettre en relation des personnes du grand public avec des experts pour répondre à des demandes techniques. Le site est évalué comme offrant une vraie valeur à ses clients (les réponses sont très adaptées) mais insupportable en matière de temps de réponse. Un gemba[1] avec les développeurs dans le code met en évidence que l’algorithme de mise en relation « client – expert » effondre les performances du site. En creusant le sujet, le coach lean découvre que les développeurs n’ont aucune culture du « design pattern » (recours à des bibliothèques de bonnes pratiques) qui leur aurait permis d’éviter cette erreur de code, et bien d’autres.

Voilà un exemple de sujet sur lesquels l’équipe aurait tout intérêt à s’améliorer, qu’elle travaille en cycle en V ou en mode agile.

2. La conduite agile de développement logiciel nécessite l’acquisition de nouvelles compétences.

Or bien maitriser une nouvelle compétence demande 10 000 heures de pratique (soit 1 400 jours ou 7 années de travail).

Exemple : comprendre finement le client et la valeur attendue, la répartir à l’intérieur de Minimum Viable Products de plus en plus riches, la traduire en un ensemble de user stories acceptables pour les développeurs sont autant de compétences que se doit de maitriser un Product Owner et qu’il découvre lorsqu’on lui confie le rôle.

Lean – Le chemin de la réussite

C’est ici que le lean management apporte sa pierre à l’édifice en proposant une approche rapide et concrète pour répondre à la question suivante : comment obtenir le plus rapidement possible les promesses de l’agilité ?

une livraison régulière et rapide de logiciels qui fonctionnent,
qui rendent le service attendu,
construits par des collaborateurs autonomes, créatifs et travaillant sereinement

En effet, l’ADN du lean est un système de réflexion pragmatique et efficace ayant pour domaine d’application la réduction rapide des écarts :

  • entre des situations connues et la situation actuelle (“d’habitude, le temps de réponse est de 15 ms et aujourd’hui, il est de 100”),
  • entre une bonne performance répétable et une pratique variable (“une fois sur trois, nous arrivons à livrer toutes les user stories dans le sprint ; les autres fois, c’est plus long”),
  • entre une situation cible et la situation réelle (“les corrections sont traditionnellement livrées en 3 mois ; comment descendre à 2 semaines ?”).

Dès lors qu’une personne ou qu’une équipe va se poser la question de réduire un écart, et qu’elle va le faire sérieusement, jusqu’à identifier une action concrète avec un résultat précis, cette personne ou cette équipe se sera appropriée une compétence nouvelle.

Une histoire parmi d’autres

Voici un exemple d’équipe agile s’appropriant le lean management :

L’équipe d’Olivier développe les logiciels d’une nouvelle borne interactive.

Ces bornes sont positionnées au niveau des points de vente et permettent aux clients ayant des achats simples d’éviter les files d’attente. L’équipe informatique travaille en sprints de 2 semaines et a déjà réalisé 23 sprints avec tous les points de passage prévus par scrum : création du backlog, mêlée quotidienne, démonstration, rétrospective, etc…

Et pourtant !

3 sites pilotes ont reçu les nouvelles bornes. Les personnels de caisse, qui étaient favorables à l’installation des bornes, menacent de les débrancher. En effet, les clients ne parviennent que très rarement à terminer une transaction tout seuls. Il faut donc abandonner son guichet, venir en aide au client démuni, faire face à son agacement éventuel, revenir en caisse et faire face à l’agacement des clients qui attendent. Les journées de travail deviennent déplaisantes.

Il y a plusieurs centaines de points de vente à déployer et la direction de l’entreprise craint que le programme ne soit stoppé. Elle décide de mettre Raphaël, coach lean et agile, à disposition de l’équipe.

Olivier est anxieux à double titre. Il sent bien que les bornes livrées ne fonctionnent pas comme prévu mais les sites pilotes sont loin et il ne comprend pas vraiment quelles sont les difficultés. La venue de Raphaël ne le rassure pas non plus ; il a le sentiment que l’équipe est “sous l’eau” : Raphaël va-t-il leur faire perdre du temps ?

Raphaël leur propose le planning suivant :

  • 3 semaines d’immersion pour lui, pour que son coaching soit spécifique à l’équipe d’Olivier,
  • 3 jours ensemble, avec l’équipe, pour diagnostiquer le processus, trouver ses faiblesses, analyser les causes et proposer des actions correctrices,
  • 8 semaines – 4 sprints – pour redresser la situation.

Agilité et lean – éléments de méthode

La démarche lean conduite dans l’équipe d’Olivier, en charge des bornes interactives, a duré 12 semaines. Le fil directeur de Raphaël, le coach lean et agile, est celui recommandé par Steven Spear[2], l’un des grands penseurs du lean :

1. Construire un management visuel qui révèle de façon dynamique les problèmes opérationnels

comprendre voir agir
Dessins de Jean-Philippe Douet

2.Résoudre ces problèmes un par un, immédiatement, jusqu’à obtenir le niveau de performance attendu avec la méthode du PDCA

PDCA

En procédant ainsi, Raphaël incite les membres de l’équipe d’Olivier à explorer les aspects de l’agilité et de création de logiciel qu’ils maitrisent moins bien. La maitrise des principes du management visuel et de la résolution de problèmes donne une grande autonomie à l’équipe de développement pour progresser, ce que ses membres apprécient vraiment.

Les 4 aspects de l’agilité cités en synthèse par Yves Caseau vont clairement faciliter l’accompagnement proposé par Raphaël :

  1. De petits lots itératifs (time-boxed sprints) :
    Le cycle d’amélioration PDCA demande que les idées testées fassent l’objet d’une validation de leur efficacité (le C pour Check du PDCA). Les sprints courts rendent très faciles ces validations, bien plus complexes dans les projets en cycle en V ! L’amélioration est donc plus rapide.
  2. Une attention concentrée sur la livraison de valeur et la mesure de la satisfaction des clients :
    La 1ère ambition du lean est de “satisfaire complètement le client”. L’agilité, en mettant la création de valeur au centre de l’attention, évite de longues négociations avec les parties prenantes sur la légitimité de choisir des sujets d’amélioration concernant ce qui peut décevoir clients et utilisateurs.
  3. Des équipes autonomes, auto-organisées, “cross fonctionnelles” qui vont développer ensemble le design, le code et l’architecture du logiciel :
    Le lean préconise aussi le travail en équipe en lieu et place de la recherche des “héros”, le développement de la confiance dans le collectif plus tôt que la validation hiérarchique et l’amélioration de la chaine de valeur au lieu de l’amélioration d’un silo isolé.
  4. Du travail d’équipe synchronisé avec une préférence pour la communication en face à face :
    Le management visuel va devenir l’artefact du travail synchronisé et va favoriser non pas la communication en face à face, mais la communication en côte à côte, encore plus favorable à l’installation d’un esprit de collaboration.

En synthèse

La complémentarité des démarches agiles et lean peut s’exprimer ainsi :

Le lean permet aux organisations agiles de tenir plus rapidement les promesses faites à l’entreprise d’une informatique qui apporte plus rapidement plus de valeur à ses utilisateurs.

L’agilité révèle les difficultés inhérentes à la création de produits, cachées auparavant dans les processus, les infrastructures et la distance avec le client et donne la liberté de progresser.

Cette synthèse apaisée ne doit pas masquer les mille difficultés que vont rencontrer les équipes et leurs coachs dont les plus fréquents sont de moins de point de vue :

  • des débats stériles de méthode. J’ai assisté à tellement de prises de becs ennuyeuses et sans intérêt depuis 2007 !
  • une réticence à s’engager dans l’amélioration car l’un ou l’autre va craindre d’être mis en cause alors que bien au contraire le lean ne s’intéresse qu’aux faiblesses des processus et des organisations pour que tous réussissent dans leur mission.
  • une inquiétude à consacrer du temps au bénéfice de l’amélioration, alors que l’activité est sous tension. Il est d’autant plus important que l’équipe définisse ses indicateurs de performance et vérifie, dans les chiffres, que l’amélioration est bien réelle.

Enfin, de mon point de vue et de celui de mes interlocuteurs, les bénéfices à attendre des démarches agiles et lean conjointes justifient les efforts qu’on leur consacre : fierté d’avoir des retours explicites et positifs des utilisateurs, satisfaction personnelle à acquérir des expertises de plus en plus fines, plaisir à travailler ensemble.

Conclusion

« Software is eating the world » est une idée forte de Marc Andreessen qui reconnait la puissance des entreprises du numérique, à commencer par les GAFA. L’une des conditions nécessaires serait quand même de construire du bon software : générant de la valeur pour ses utilisateurs, rapide car nous sommes tous impatients, robuste pour être disponible en permanence, capable d’évoluer car le monde change, etc… Avec ces critères d’évaluation, tous les logiciels ne se valent pas. Certaines entreprises vont être laissées de côté.

S’il s’agit d’éditeurs de logiciel, on peut se désoler avec eux de leurs difficultés mais on peut aussi être surpris de voir des entrepreneurs se lancer dans un métier dont ils connaissent mal les fondamentaux.

S’il s’agit de DSI, le lien entre la difficulté des métiers et la qualité ou l’absence de qualité des systèmes d’information ne saute pas toujours aux yeux des développeurs. Je pense à ce distributeur qui n’arrivait pas à livrer une version bien plus moderne de sa carte de fidélité :

  • les développeurs ne voyaient pas en quoi cela pouvait poser problème à qui,
  • à la proposition : « allez en boutique et demandez au responsable ce qu’il en pense », haussement d’épaules : « je ne vois pas ce que j’irai faire là-bas ! »

Quelle indifférence ! Quel manque de sens du collectif, non pas entre collègues du même plateau, mais entre toutes les personnes qui se donnent du mal pour que l’entreprise soit rentable, et verse leurs salaires. Ce constat ne rend pas justice à l’énergie des équipes informatiques et ne reconnait pas les difficultés qu’elles affrontent tous les jours. Mais il reflète bien la réalité : l’entre-soi de l’informatique pénalise bien trop souvent la capacité des entreprises à se battre dans la compétition numérique.

Le déploiement de l’agilité et du lean est une opportunité de changer de posture. La montée en expertise des équipes informatiques qui est proposée est à considérer par les ingénieurs, les manageurs et les dirigeants comme une chance de mieux soutenir leurs entreprises respectives. Réussir ses sprints ou sinon conduire des améliorations pour les réussir, satisfaire ses clients ou sinon conduire des améliorations pour y parvenir, livrer sans bug ou sinon relire son code jusqu’à avoir compris où l’on a fait une erreur devraient faire partie des engagements collectifs et personnels.

Il n’y a aucune raison à installer de façon déplaisante cette culture de la responsabilité et de l’expertise : la brutalité démotive une partie d’entre nous et ne rend pas plus efficace ceux qui l’accepte. Bien au contraire, apprendre fait sourire[3] et l’agilité comme le lean embarquent une bonne dose d’esprit d’équipe et de bienveillance. Profitons-en.

Merci à Jean-Philippe Douet pour ses dessins 😉


[1] Le gemba consiste à aller sur le terrain pour observer les demandes des clients et le fonctionnement du processus. Ce qu’on l’on voit alimente la recherche de causes et d’actions d’amélioration.

[2] Son livre « the high velocity edge » est une référence dans le domaine

[3] S. Dehaene, chercheur en neuroscience, professeur au Collège de France

5 réflexions sur “Agile et Lean – la complémentarité d’un vrai binôme

  1. Merci Marie-Pia pour cet article fort utile.

    Je partage le même constat que Agile et Lean font clairement bon ménage. Ce qui s’explique sans doute par le fait que le Toyota Production System (ou Lean ?) a largement inspiré les créateurs des méthodes agiles. C’est notamment le cas du cadre de travail le plus connu parmi elles et évoqué dans cet article : Scrum. Il faut rendre à César ce qui appartient à César 🙂

    Et si on dit que le Lean a inspiré les méthodes agiles, on pourrait penser qu’on considère le Lean comme un ancêtre vieillissant ? De mon point de vue, il n’en est rien et il demeure d’une incroyable modernité malgré son âge.

    Comme évoqué dans l’article, les facteurs d’échec de transformation agile sont nombreux. En tant que coach agile, je fais face quasi-quotidiennement aux idées reçues à propos de l’agilité (du genre : « en agile on ne fait pas de doc ni de test, on improvise sans arrêt sans plan pour se retrouver à faire et défaire », « en mode agile c’est l’anarchie, il n’y a même pas de chef », « l’agilité c’est pour les petits projets avec moins de 10 personnes », et j’en passe…). Mais ce n’est pas le plus gros problème. Celui qui me chagrine le plus, ce sont les entreprises/équipes/managers qui sous-estiment l’ampleur du changement. Qui perçoivent l’agilité comme un simple changement de méthode et non pas comme un changement de paradigme et de façon de penser. Résultat, la conduite du changement est négligée. Pas de sponsor haut placé pour soutenir véritablement la démarche, absence de réflexion ni communication sur le « pourquoi » adopter l’agilité (« on fait de l’agilité parce que les autres le font ou pour « réduire les coûts » »), application de l’agilité (souvent « bricolée ») directement sur des projets à forts enjeux sans se faire la main au préalable sur un projet pilote avec à minima l’accompagnement (sur 2 à 3 mois minimum) par une personne qui a déjà mis en place avec succès l’agilité et un noyau dur de volontaires dans l’équipe.

    Je vois encore un autre problème, propre à Scrum à cette fois. Scrum n’est pas une méthode, c’est un cadre de travail. C’est à la fois sa force (capacité d’adaptation à des tas de contextes et secteurs différents, légèreté, inclusif des outils et techniques propres au contexte de l’équipe dont la créativité est ainsi libérée, etc) et sa faiblesse. Sa faiblesse car on oublie du coup trop souvent les pratiques et outils complémentaires indispensables à la réussite du défi proposé par l’agilité. A savoir : convertir des besoins en un incrément utilisable et potentiellement livrable (donc de qualité) en seulement 2 semaines (pour prendre la moyenne de durée des sprints à ce jour sur les projets de développement logiciel). Intégration Continue, Test Driven Development, Pair Programming, Clean Coding / Software Craftsmanship, etc, ou équivalents, doivent venir compléter Scrum. Autre défi amené par Scrum : faire face à toutes ses imperfections révélées par la transparence de Scrum. Scrum est souvent comparé à (la caricature de) votre belle mère qui considère que vous ne serez jamais assez bien pour son fils ou sa fille, ce n’est pas pour rien 🙂

    Maintenant, ça n’enlève rien à la valeur que le Lean peut apporter aux équipes agiles. Les principes fondamentaux sont les même, dont celui consistant à remettre l’humain au coeur du réacteur tout en faisant preuve d’une grande rigueur et discipline. Avec tant de bénéfices à la clé, à la fois en termes de performance et de motivation durables.

    Encore merci pour cet article.

    Amicalement,
    Florent LOTHON

    J'aime

  2. on est d’accord à propos de SCRUM. C’est un ‘cadre de gestion de projet’ , avec des rituels, des cérémonies et des sprints qui sont des cycles en V toutes les 2 semaines au lieu de tous les 6, 9, 12, 18 mois !
    D’où un impact énorme sur les méthodes et outils de conception logicielle, de test, de déploiement dans les environnements, ….
    Il faut effectivement « comme avant » des personnes qui maîtrisent le métier d’architecte, de développeur, de testeur, pour faire de l’architecture, de la conception logicielle, … mais en plus pointus car il faut délivrer au moins toutes les 2 semaines !
    Et des coach agiles qui comprennent cela et comprennent ce qu’il se passe techniquement dans l’équipe….

    J'aime

  3. Pour le cycle en V dans le Sprint, c’est amusant car c’est le premier travers dans lequel je suis tombé sur mon tout premier projet Scrum pour la SNCF en 2008 🙂

    Mon chef de l’époque avait insisté (pour se rassurer) pour que nos sprints (de 3 semaines à l’époque) commencent par une phase de conception, puis réalisation, puis test. Mais ce n’est pas de l’agilité et ça comporte trop de risques (délai, effet tunnel, démotivation, etc) même si ces risques sont heureusement réduits par la durée des sprints ainsi que les précieuses revues et rétrospectives de sprint. Une fois mon chef rassuré, j’ai vite mis fin à ça.

    Au sein d’un sprint, on ne pilote pas les travaux par des phases comme en cycle en V (conception/réalisarion/test), on pilote par les fonctionnalités/exigences (Feature Driven Development). Autrement dit, une fonctionnalité peut être terminée (conçue/développée/testée) et revue par le Product Owner dès la première semaine d’un sprint de 3 semaines par exemple. J’espère être clair car c’est l’un des aspects que j’ai le plus de mal à expliquer sans schéma 🙂

    J'aime

  4. Merci pour ton feedback 🙂

    Je ne parlais pas de pilotage par le cycle en V, je parlais que les activités sont toujours celles d’un cycle en V (typiquement : capture des besoins, écriture des « spécifications »/US, architecture/conception technique, Coding, tests unitaires, tests d’intégration / de non régression sur l’ensemble du produit, déploiement ) mais appliquées sur des « petits lots »(les features qu’il faut livrer dans un sprint) , voire sur une seule pièce. La pièce étant la feature.

    D’ailleurs un cycle en V n’est en général pas sur un seul sprint : la capture des besoins et la conception technique pourraient se faire dans le sprint n-1, les activités suivantes (Coding, …) étant réalisées dans le sprint n.
    (C’est ce que fait Theodo qui utilisent des sprints d’une semaine).

    Ce n’est pas évident de discuter par écrit (sans schémas) de choses plutôt précises et complexes… 🙂

    J'aime

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s