Black Belt Story

Face à l’insatisfaction chronique des utilisateurs, des coûts démesurés et des délais non tenus, le Lean IT est parti d’un constat simple : pourquoi ne pas appliquer la philosophie et les outils du Lean aux services informatiques d’entreprise ?

En effet, l’IT d’entreprise n’est plus l’un des beaux arts, comme aiment souvent à le penser les développeurs, mais une forme d’industrie, avec des obligations de résultats : des produits à livrer, dans les délais, avec la qualité requise.

Une « agilité » mal comprise

Comme souvent, le Lean IT a donné lieu à l’émergence de concepts, comme le DevOps qui redécouvre l’intérêt de concevoir ensemble (développeurs et exploitation). Ou encore l’Agilité et toutes ses déclinaisons (Scrum en tête), perçue comme un Eldorado qui allait enfin enchanter les clients internes, ravir les financiers, et combler les développeurs.

Mais l’agilité a été pervertie : les clients internes ont vu dans l’agilité un excellent moyen de ne pas réfléchir aux spécifications. Ils s’expriment à présent sous forme d’interviews, sans même prendre la peine de rédiger les « user stories » ou de donner des « business value » motivées et crédibles (voir mon billet sur le Scrum).

D’un autre côté, les développeurs peinent à sortir des versions stables dans les temps. On privilégie la fin du sprint et sa revue, plutôt que la qualité du livrable. Les estimations ne sont pas fiables. Bilan : les sprints se suivent, plombés par des user stories refusées. Les releases se font attendre et les coûts (généralement non mesurés) explosent. Ce n’est pas ce que l’Agile devrait être, mais c’est ce qu’il est souvent devenu.

Les principes du Lean appliqués à l’IT

Le Lean est une philosophie, et donc une attitude, et non une boîte à outils. Cette philosophie met le client au dessus de tout. « Servir le client » est la boussole de l’entreprise, partagée par tous. Au service de cette philosophie, on dispose de méthodes et d’outils, dont la mise en œuvre ne s’improvise pas. Je propose donc ici 10 clefs (il y en a d’autres !) pour mettre en œuvre une véritable approche Lean au service de l’informatique d’entreprise.

1 – Se remettre en cause en permanence

C’est l’un des fondements du Lean. Il faut accepter que ce qui a fait notre succès d’hier ne puisse plus garantir le succès de demain. Les équipes informatiques n’y échappent pas. Il faut lutter contre les habitudes, refuser l’état actuel, rehausser son niveau d’exigence. C’est l’un des buts de la rétrospective Scrum, base de l’amélioration continue, malheureusement banalisée et souvent transformée en constat sans suite.

« J’entends souvent les gens dire qu’ils sont trop occupés pour passer du temps sur l’amélioration.
Je leur réponds qu’ils cesseront d’être occupés lorsque leur entreprise aura fait faillite  » Shigeo Shingo

2 – Ecouter la Voix du Client

Le client est celui qui paie. Dans une informatique d’entreprise, il s’agit donc souvent d’un client interne, mais pas seulement : si on développe un extranet qui sera utilisé par des milliers de clients de l’entreprise, le client est alors bien synonyme de chiffre d’affaires. Et en Lean, ce client externe est bien plus important que le client interne. Car sans service RH ou juridique, l’entreprise peut survivre. Sans client, elle ne le peut pas !

La mission première de l’IT est de délivrer un produit conforme aux attentes. Ni plus, ni moins. encore faut-il avoir collecté correctement ces attentes. Il faut donc briser les frontières, permettre aux développeurs (et pas seulement au chef de projet) de rencontrer le client final et observer son activité (Gemba). Cela rassure le client et valorise le développeur qui donne du sens à son travail.

3 – Traquer les démons

Le Lean chasse 3 démons : le Muda (gaspillages), le Mura (irrégularité), le Muri (surcharge). Retenons que le muda caractérise tout ce qui ne créé pas de valeur pour le client. Le mura représente l’irrégularité dans la charge de travail. On ne peut pas faire travailler les équipes 50 heures par semaine (muri), puis les laisser désoeuvrées pendant 2 mois. Il est de la responsabilité des managers de savoir dire non, et de lisser la production. Les variations sont inévitables, mais elles doivent être maîtrisées. Pour cela, encore faut-il que les équipes tiennent leurs engagements, sinon aucune planification n’est possible.

4 – Observer. Le Gemba.

Une fois les premiers livrables en production, les développeurs devraient observer le produit en fonctionnement réel, chez le client (et non au sein de l’entreprise). Car le feedback client est fondamental . Il est permanent tout au long du cycle de développement et doit être dissocié de la notion de validation. Le client n’est pas incompétent ou stupide s’il ne sait pas se servir du logiciel. Ayons plutôt l’humilité de nous remettre en cause et d’accepter que notre produit ne corresponde pas totalement aux attentes !

Observer consiste donc à regarder, écouter, et demander « pourquoi ? ». Rien de plus. Observer veut aussi dire, pour le manager du SI d’aller là où ça se passe, c’est à dire au coeur des équipes de développement ou d’infrastructures, pour comprendre vraiment.

5 – Arrêt au premier défaut

Personne n’admet d’acheter un produit manufacturé défaillant. Le produit est garanti. Mais tout le monde accepte que les développements soient livrés avec des défauts : ce sont les « inévitables » bugs. L’informatique est la seule industrie dans laquelle les défauts sont « normaux ».

La qualité ne doit pas être le problème de quelqu’un d’autre (souvent ceux qui vont recetter !). En Lean, on ne cherche pas des coupables mais des causes. Le manager doit donc être bienveillant mais exigeant. Chaque problème doit être vu comme une opportunité, donner lieu à une analyse et une résolution rapide. L’un des piliers du Lean est le Jidoka, c’est-à-dire l’arrêt au premier défaut : on ne livre pas si un défaut est constaté et on ne passe pas non plus à l’étape suivante.

Or, les équipes de développement ont tendance à repousser la correction des bugs à plus tard. On se retrouve donc fréquemment avec des produits « presque prêts » mais dont la mise en production est sans cesse repoussée. Les problèmes doivent être résolus immédiatement. Des approches comme le TDD (Tests-driven Developement) peuvent y aider.

6 – Le juste nécessaire

Du reporting, des réunions, des discussions, des feuilles excel, mais aussi les corrections de bugs ne créent strictement aucune valeur. Le seul moment où une équipe de développement créé de la valeur, c’est quand elle conçoit, code ou qu’elle met en production. Le reste est « gaspillage » : il doit donc être réduit ou supprimé.

Le juste nécessaire est un autre socle du Lean : avant d’investir, réfléchir à une approche astucieuse. Avant d’embaucher, prioriser en pilotant par la valeur dégagée. Et puis, limiter les tâches administratives, les contrôles internes, les réunions, les niveaux hiérarchiques, les attentes, les signatures, les formulaires, les validations… Il ne s’agit pas de travailler plus vite, il s’agit de travailler avec moins d’entraves.

En parallèle, résister à la tentation de faire de la sur-qualité (muda). Bâtir une cathédrale alors que le client attend une maisonnette est sans doute valorisant, mais coûte à l’entreprise et ne lui rapporte rien. Penser que le code sera ainsi « réutilisable » et qu’il s’agit d’un investissement est bien souvent une chimère.

7 – L’obsession de la mesure

Aujourd’hui encore, il est bien rare que l’on mesure le temps passé par les équipes informatiques sur les projets. En effet, cette population d’ingénieurs se définit souvent comme créative, et il est bien connu que la créativité ne se mesure pas. Mais comme disait Edward Deming : « On ne peut pas piloter ce qui n’est pas mesuré »

En Lean, il est donc indispensable de tout mesurer et de rendre visible ces mesures. Mais cette mesure n’est pas une surveillance. Seuls les faits sont intéressants. La mesure concerne aussi les performances des logiciels et des infrastructures, vues du client . La métrologie doit être intégrée dans le processus de développement, afin de discuter autour de chiffres, et non d’opinions.

8 – Standardiser

La base du Lean est l’amélioration continue. Mais sans mesures ni standards, il est impossible de progresser. L’Agile Manifesto préconise de privilégier « les interactions entre individus plutôt que les processus et les outils », ce qui m’apparaît contradictoire avec une approche Lean où la standardisation est fondamentale.

Le développement et les infrastructures doivent donc être standardisés. Le standard, à un instant donné, représente la bonne pratique, validée par l’équipe. Les frameworks, qui ont envahi le monde du développement depuis plusieurs années contribuent largement à la standardisation du cycle de vie, mais ne suffisent pas.

« Nous obtenons des résultats excellents en manageant des gens normaux dans des processus excellents. » Shigeo Shingo

Le standard est non négociable. Car il permet de résoudre rapidement les problèmes (Y-a-t’il un standard ? Est-il connu ? Est-il appliqué ?). Mais chacun peut (et doit) faire des propositions d’amélioration. Une fois testée et validée, la proposition est adoptée (ou pas), documentée, et devient alors le nouveau standard. Mais permettre à chacun à développer « comme il veut » est antinomique avec un pilotage sérieux.

9 – Le management visuel

Oubliez les fichiers enfouis dans des arborescences sans fin : Affichez, dessinez, illustrez ! Le management visuel permet de partager les informations pertinentes (et seulement celles-là). Tout le monde peut consulter l’affichage : on y retrouve aussi bien des informations de performances, de qualité, de délais, de coûts… Le scrum, héritier du Lean, a popularisé le management visuel dans l’IT. Mais bien souvent, celui-ci n’est que partiel : on affiche bien les post-it au tableau, mais pas le burndown chart (progression du sprint) par exemple.

10 – L’intelligence collective

Un principe du Lean explique que « celui qui sait est celui qui fait ». Mieux vaut les idées de tous que le savoir d’un seul. Il faut donc encourager les collaborateurs, et surtout leur faire confiance. De même, les fournisseurs doivent être respectés : il détiennent un savoir faire, une expertise ou un produit qui contribue à notre succès.

Encore une fois, le lean ne cherche pas des coupables, mais des causes. Ce n’est que lorsque tous sont convaincus qu’un problème est une opportunité, que l’intelligence collective devient possible, et qu’elle est un vecteur majeur d’amélioration continue.