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 :

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 :

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