Black Belt Story

En lisant récemment un article sur ZDnet, sobrement intitulé « Votre Direction Informatique est-elle prête pour le Lean IT ? », je découvre au détour de l’article cette affirmation péremptoire :

« Sachant quand même que l’informatique n’a pas attendu le lean pour développer les méthodes agiles qui traduisent d’une certaine façon cette construction continue et économe en ressources ».

Qualité et informatique ?

Je ne sais pas si l’informatique n’a pas attendu le Lean, mais il est clair que si l’on appliquait les méthodes du développement logiciel à la construction aéronautique ou automobile, nous aurions à déplorer une centaine de crashes par jour, et quelques centaines de milliers de morts sur les routes. Soyons très clairs, l’informatique est au même niveau qualitatif que l’industrie des années 50 : de la complication excessive, des défauts nombreux, des délais interminables, des clients insatisfaits.

Tout le monde trouve aujourd’hui « normal » qu’un logiciel comporte des bugs. Mais l’industrie informatique est la seule industrie qui produise des défauts que tout le monde accepte sans broncher. Les défauts sont même spécifiés dans les clauses d’utilisation des produits Microsoft par exemple :

« Le logiciel est concédé en l’état, avec toutes ses imperfections ».

N’est ce pas merveilleux ? Qui accepterait d’un constructeur automobile, ou d’un fabricant d’électro-ménager ou de téléviseurs, que le produit ne soit pas garanti ? Et que dire des « Services Pack ». Ou comment faire croire que l’on délivre un service, alors qu’on corrige des défauts… Je cite Microsoft mais tous les éditeurs logiciels imposent aujourd’hui des clauses identiques, et personne ne s’en émeut.

Scrum et Lean. la poule et l’oeuf.

La méthode Scrum est une méthode itérative de développement de produit, inventée – comme par hasard – par deux japonais  Hirotaka Takeuchi et Ikujiro Nonaka, et détaillée dans un livre intitulé « The New New Product Development Game ». C’était en 1986, donc plus de 20 ans après l’apparition du Lean chez Toyota (à l’époque « Toyota Production System ») !  Donc, il semble que le Scrum vienne du Lean et non l’inverse. Mais l’auteur de l’article évoque peut-être le Lean dans le monde de l’informatique, le fameux Lean IT.

Scrum est inspiré de la progression d’une équipe de rugby et a été au départ imaginé pour la conception de n’importe quel produit, mais il est surtout connu aujourd’hui dans le monde du développement logiciel. Si l’on rapproche la méthode (ou plutôt l’état d’esprit, ou la philosophie) Lean avec la méthode Scrum, les convergences sont multiples :

1. Le propriétaire.
En Scrum, la personne chargée de spécifier les « user stories » ( = cas d’usage) est nommé Product Owner (ou P.O.). Elle « représente » le client de l’application. On retrouve le même concept dans le Lean, qui identifie le « propriétaire du processus ».

2. le pilotage par la valeur
En Scrum, les user stories sont « évaluées » par le Product Owner, par le biais d’une « note » : 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc… Cette évaluation correspond à la « valeur Business » et peut-être discutée par l’équipe toute entière. L’itération du cycle de développement (sprint) comportera en toute logique ce qui a le plus de valeur pour le product owner (et donc pour le client). On retrouve ici un principe fondateur du lean, qui se concentre sur la valeur pour le client (et non nécessairement pour l’entreprise) en éliminant les tâches sans valeur ajoutée.

3. L’équipe Scrum
L’idée est de réunir dans une seule équipe tous ceux qui sont nécessaires à la réalisation du logiciel. Avec le moins d’interactions extérieures possible. Le client est donc présent dans l’équipe par le biais du product owner. C’est l’équivalent de l’Unité Autonome de Production (UAP) qu’on trouve dans le Lean. Avec une orientation processus et non outil. Une équipe Lean ne devrait pas avoir besoin de compétences extérieures pour produire. De même, toute l’équipe Scrum partage les enjeux comme l’équipe Lean partage la vision.

4. L’autonomie
Un développeur d’une équipe Scrum est autonome sur la façon de développer une user story. Il est responsable de son achèvement dans le délai qu’il a lui-même fixé. Il est également responsable de la qualité de ce qu’il produit, et doit faire lui-même au Product Owner la démonstration du résultat. Le Lean met en avant ces mêmes valeurs d’autonomie, de responsabilité et de qualité dont chacun est responsable. En Lean (comme en scrum), le manager est au service de l’opérationnel, et non l’inverse.

5. La transparence
En scrum, l’avancement du sprint (itération) en cours est affiché à disposition de tous. Un tableau montre clairement quelles sont les tâches en cours. On ne cherche en effet pas à montrer du doigt celui qui est en retard, mais à l’aider, afin que les obstacles qu’il rencontre soient levés. La priorité est donnée à l’avancement, et non à la recherche d’un coupable. La transparence absolue est également la règle en Lean où tous les indicateurs sont affichés en permanence, même s’ils sont mauvais.

6. La mesure
La méthode Scrum impose de mesurer en permanence l’avancement, la valeur dégagée, l’effort consommé, et la « vélocité » de l’équipe. Là aussi, cette approche est directement inspirée du Lean, où la mesure est omniprésente et affichée en permanence (Andon) . Et plus encore dans l’approche Lean 6Sigma (cartes de contrôle).

7. Le Management VISUEL
En scrum, tout le suivi du projet se situe à un seul endroit, accessible à tous, et représenté de façon visuelle. Des user stories sont courtes et écrites sur des post-it de couleur différente suivant leur catégorie, les indicateurs d’avancement (downchart, vélocités, burnup, etc) sont mis à jour régulièrement sur un graphique (et non enterré quelque part dans un fichier Excel). La forme visuelle permet une compréhension rapide et synthétique, sans avoir à lire quoi que ce soit…

8. L’adaptabilité
Scrum a été conçu pour permettre au client de changer d’avis en cours de réalisation du logiciel. Scrum permet de modifier, ajouter ou supprimer des user stories à chaque sprint review. C’est là encore une des valeurs du Lean : produire en flux tiré, de petites quantités, être ainsi capable de gérer la variété, et le changement grâce à ces flux optimisés.

Les services informatiques n’ont pas attendu le Lean pour faire de la qualité ? C’est sans doute vrai dans l’informatique embarquée ou temps réel, mais pas dans l’informatique de gestion, souvent empêtrée dans des cycles en V qui ne satisfont personne, prisonnière de concepts franco-français que sont les MOA, AMOA, et MOE, et qui découvre depuis peu, par le biais du Scrum (et des autres méthodes agiles), tous les aspects d’une méthode Lean qui a plus de 40 ans, et qui est adoptée par la majorité des grandes industries.