Notes de lecture sur le livre « Product Development for the Lean Enterprise »

Ce livre de Michael N. Kennedy a été publié en 2003, et a pour sous-titre « Why Toyota’s System is Four Times More Productive and How you Can Implement It ».

Je ne cherche pas à faire une critique du livre. Pour cela les commentaires sur amazon permettent de se faire une bonne idée. Je détaille simplement certains points qui m’ont frappé, par rapport à mon but de mieux comprendre les implications (notamment organisationnelles) d’une mise en place de Scrum.

Note : ce livre est écrit comme une nouvelle. Mais ne vous attendez pas à une intrigue romantique. C’est plutôt dans le style The Five Dysfunctions of a Team: A Leadership Fable, de Patrick Lencioni, à savoir une description assez vivante des réunions et discussions entre les membres d’une équipe de management. J’aime bien ce style qui permet de rentrer plus facilement dans un nouveau sujet, mais cela peut rendre l’assimilation des idées un peu plus difficile, et peut demander ensuite de compléter avec d’autres livres écrits de manière plus traditionnelle.

Les énormes marges de progression

Quand je demande à des ingénieurs et managers américains travaillant pour Toyota combien de leur temps ils passent à « créer de la valeur » ou à « créer de la connaissance » ou « faire de l’ingénierie », les réponses sont en moyenne autour de 80%. Quand je pose la même question à des ingénieurs et des managers américains travaillant pour de grandes entreprises US, les réponses sont en moyenne moins de 20%. Des entreprises scandinaves de taille moyenne sont en moyenne autour de 40%, presque à mi-chemin entre les deux. Dr Allen Ward dans la préface du livre.

J’essaie souvent de poser et de me poser ce genre de questions. Avant notre passage à Scrum, j’avais essayé (avec Homo Agilis notamment) d’évaluer combien de temps nous passions à ajouter de la valeur sur un logiciel existant, par rapport au temps passé à corriger des problèmes. Nous étions arrivés à 25% du temps passé à de nouvelles fonctionnalités contre 75% du temps à corriger des problèmes. Cela m’avait paru à l’époque (2005) assez affolant, et m’avait fortement motivé pour travailler sur la mise en place de Scrum, mais les chiffres de Allen Ward ci-dessus permettent maintenant de relativiser. Nous n’étions pas un cas particulier.

Après plus de trois ans de pratique de Scrum, je suis toujours curieux de savoir où nous en sommes, et je demande dans les rétrospectives d’évaluer le temps perdu dans des gaspillages (au sens du Lean Software Development). Les réponses des développeurs sont typiquement entre 30 à 50% de leur temps encore gaspillé ! D’autre part quand je pose la même question au public plus restreint des managers et scrummasters, il y a unanimité pour penser que nous sommes encore au-dessus des 50%. Je suppose que les managers/scrummasters ont une évaluation plus pessimiste que les développeurs car ils voient mieux certains gaspillages, comme le ré-apprentissage entre projets.

Ces chiffres indiquent des possibilités de d’amélioration vraiment importantes. Pour se faire une idée plus précise, si l’on fait l’hypothèse que ces pourcentages s’appliquent directement à l’utilisation de la masse salariale, on peut considérer qu’éviter 10% de temps « gaspillé » correspondrait aux salaires de X personnes supplémentaires (exercice pour le lecteur : calculez votre X)…  Mais ce serait encore plus intéressant que d’avoir X personnes de plus, car ajouter des gens est coûteux en temps de formation, de management et de communication. Donc trouver le moyen de gagner 10% permet d’avoir très rapidement l’équivalent de plus de X personnes formées, expérimentées, opérationnelles immédiatement… Voilà qui mérite réflexion.

Toutefois la difficulté n’est pas dans le constat, mais dans la découverte d’une solution adaptée à chaque contexte. Le livre pose peut-être plus que questions qu’il n’apporte de réponses.

Les limites des démarches d’amélioration

L’entreprise fictive du livre n’a bien sûr pas attendu 2003 pour essayer de s’améliorer, et a déjà dépensé beaucoup d’argent sur plusieurs initiatives pour s’améliorer. Toutefois, même si elle a pu développer certains points forts (par exemple la qualité de sa fabrication) elle est en perte de vitesse, notamment car elle ne parvient pas à développer de nouveaux produits suffisamment rapidement, ni des produits suffisamment en phase avec les attentes de ses clients, lesquels se tournent maintenant vers ses concurrents.

Dans le livre les sources de problèmes sont identifiées assez rapidement par le petit groupe qui doit en toute urgence présenter un plan d’action – à noter qu’à part certains managers de haut niveau qui ne voient que certains symptômes des problèmes, il y a vite un accord général sur les causes. La table ci-dessous présente en ligne les causes de problèmes, puis en colonne les impacts potentiels des initiatives d’amélioration déjà en cours.

 

Il n’est pas possible de généraliser les causes de problèmes ci-dessus, chacun doit faire le travail d’analyse dans son propre contexte. En tout cas la démarche recommandée est de chercher des problèmes systémiques dans l’entreprise, c’est-à-dire ceux qui touchent l’entreprise dans sa globalité.

Dans notre cas je pense qu’avant Scrum nous avions comme problème systémique un trop grand nombre de problèmes découverts chez nos clients en production, problèmes qui pouvaient venir

• soit d’une mauvaise compréhension des besoins clients (pour être concret, nous avons parfois sous-estimé l’importance que l’impression de rapports papier avait pour nos clients, ou plus généralement souvent considéré comme secondaires certaines fonctionnalités qui étaient en fait primordiales pour de nombreux clients) 
• soit d’une mauvaise méthode de travail (par exemple, des tests effectués beaucoup trop tardivement dans le cycle de développement, et peu d’attention portée à l’automatisation des tests).

Après la mise en place de Scrum nous avons beaucoup progressé sur la prise en compte des besoins clients, sur les tests et autres bonnes pratiques, mais il nous reste des problèmes systémiques :

• comme dans le tableau ci-dessus, il y a peu d’apprentissage d’un projet à l’autre. Par exemple certains projets/équipes maîtrisent parfaitement le développement sans fuites de mémoire, et toutefois nous peinons à généraliser ce point pourtant vital dans certaines de nos applications. Plus généralement, des projets largement déployés dans le monde ont permis d’établir un catalogue d’erreurs classiques, mais nous ne disséminons qu’imparfaitement cette connaissance, et nous faisons régulièrement des erreurs déjà connues.
• nous avons également du mal à permettre des progressions de carrière technique, afin d’éviter que des gens très compétents techniquement ne perdent du temps sur des tâches à faible valeur ajoutée.
• nous avons des difficultés à décider des bonnes actions d’amélioration. Les idées ne manquent pas mais nous ne savons pas bien les choisir ni les évaluer.
• il reste difficile de réduire le temps de développement des logiciels, en partie parce que les Product Owners veulent avoir le maximum de fonctionnalités avant de sortir un produit. Il faudra certainement arriver à appréhender les besoins client d’une autre manière, notamment en résolvant leurs besoins incrémentalement. Il reste à savoir si cela est réellement impossible dans notre domaine, ou si c’est un problème de culture des Product Owners.

Malheureusement la leçon du livre est que les problèmes systémiques ne peuvent pas se résoudre simplement par des améliorations de processus, et c’est ce que nous avons essayé de faire pour l’instant. Je pense que cela ne remet pas en cause nos efforts de mise en place de pratiques Lean comme la recherche de gaspillages, mais par contre cela indique que les succès seront très faibles tant qu’une attitude Lean ne sera pas parfaitement comprise et adoptée par tout le monde.

Structure contre connaissance

C’est probablement le point clé du livre, et le plus difficile à maîtriser (pour moi lecteur, mais aussi pour les personnages du livre). L’auteur considère d’abord que l’on peut classer les entreprises (plus précisément leurs environnements de développement de nouveaux produits) sur un axe qui s’étend de « Orienté-Structure » à « Orienté-Connaissance ».

Le côté « Orienté-Structure » est facile à comprendre, ce sont les environnements focalisés sur les procédures, le contrôle, le respect de standards. A cet égard, il faut souligner que l’une de nos motivations pour implémenter Scrum était d’introduire plus de structure dans un environnement qui semblait trop chaotique (le chaos venant probablement de notre époque « startup », pas si lointaine). Nous avons bien réussi, et Scrum nous a d’ailleurs permis en un an d’obtenir une certification ISO9001 version 2000. Toutefois cette motivation n’était peut-être pas si louable si l’on considère que se positionner sur l’autre extrémité de l’axe est l’objectif à atteindre !

Cette autre extrémité est « Orienté-Connaissance ». La base de tels environnements est la connaissance des travailleurs individuels : compréhension des besoins, accès à l’information dont ils ont besoin, responsabilité et interactions en équipe. Ce concept n’est pas nouveau, Peter Drucker, le gourou humaniste du management, a commencé à travailler sur le concept du travailleur intellectuel (knowledge worker) vers 1959. Mais il semble que peu d’entreprises aient réellement compris comment mettre en oeuvre ce concept. Dans le secteur informatique il est possible que les méthodes agiles soient la première tentative d’aller de manière systématique en direction de l’organisation « Orientée-Connaissance ». Je suppose que nous pourrions être plus efficaces si nous comprenions où nous allons ! Pour moi la direction paraît relativement claire, mais la destination ne l’est pas suffisamment !

Clé numéro 1 : la conception concurrente

Le livre fournit justement quelques éclairages sur cette destination, au moins dans le cas de Toyota. L’une des clés de l’explication semble être le concept du « set-based design », que l’on peut traduire par « conception concurrente », ou « conception avec options ». Cela consiste à reporter les décisions de conception le plus tard possible, pour cela on travaille en parallèle sur plusieurs alternatives viables, jusqu’au moment où l’on a suffisamment d’informations et de connaissances pour prendre une décision. C’est une notion que l’on rencontre de toute manière dans le Lean en général, dans le Lean Software Development en particulier (voir Implementing Lean Software Development: From Concept to Cash des Poppendieck). Mais le mérite du livre est pour moi d’expliquer comment cette approche génère de la connaissance. En effet la connaissance se matérialise en conservant les informations relatives aux prises de décisions (les compromis que l’on a fait entre les solutions alternatives, ce qui a marché et pas marché, etc.), et se réutilise de projets en projets, étant donné que certaines conceptions alternatives écartées pour un projet seront utiles pour d’autres projets dans le futur.

Ce concept a déjà été partiellement exploré en informatique. L’article Set-Based Concurrent Engineering donne des exemples concrets (choix entre algorithmes, entre mécanismes de persistance, utilisation systématique de la modularité, d’abstractions, d’interfaces).

Donc le concept est relativement facile à appliquer en informatique. Cela pourrait prendre différentes formes dans un cadre Scrum :

• plusieurs équipes travaillent en parallèle pendant un sprint sur des implémentations différentes d’une même user story,
• ou si l’on n’a pas assez d’équipes, une même équipe réalise plusieurs implémentations différentes sprint après sprint,
• à l’intérieur d’une équipe et d’un sprint, plusieurs sous-groupes réalisent en parallèle des implémentations différentes d’une user story.

Evidemment on voit bien apparaître la question du coût potentiellement exagéré de telles démarches ! La question du coût est abordée dans le livre, avec l’argument que s’engager très tôt dans un certain choix de conception a d’importants coûts cachés : on va bâtir des plans toujours trop optimistes qui ne permettront pas facilement les nécessaires retours en arrière en cas de problèmes inévitables, et le coût de ces retards est énorme. De plus on se prive de la connaissance apportée par la compréhension des alternatives, ce qui a également un coût. Je suis assez convaincu par ces questions de coût, il y a des décisions de conception très difficiles à prendre, et l’on passe parfois plus de temps à des débats théoriques que cela ne prendrait de coder les alternatives pour prendre des décisions rapides et factuelles ! Mais je caricature un peu… Un autre argument dans le livre est la maitrise du risque : le risque d’échec d’un projet est bien plus élevé quand le choix d’une conception est fait tôt, tandis qu’il devient quasi-nul si l’on poursuit plusieurs alternatives (le livre présente un peu de statistiques sur la question, avec un exemple de conception de vélo).

Pour adapter ces idées à notre contexte, il faut

• bien identifier ce qui constitue le « coeur » de la connaissance dans notre métier (et ce pourra être différent dans le contexte particulier de chaque lecteur je suppose). Dans le cas de Toyota, ce sont les « tradeoff curves » (courbes de compromis ?).
• trouver comment capturer et utiliser cette connaissance sur plusieurs projets.  J’ai des difficultés à voir comment on capitalise cette connaissance. Est-ce qu’elle reste simplement dans la tête des individus concernés ? Comment la fait-on partager ? On rédige des documents ? On fait des exposés ? On alimente un wiki ?

En tout cas cela ouvre des pistes pour les rétrospectives Scrum, qui devraient peut-être être beaucoup plus « orientées-connaissance ». Les rétrospectives pourraient, me semble-t-il, devenir le support de la capitalisation de connaissances. On devrait donc regarder beaucoup plus sérieusement quelles étaient les options techniques considérées, les raisons de choix, ce qui a marché, ce qui n’a pas marché. Ensuite on devrait se poser la question de savoir comment conserver ces informations finalement très précieuses, et probablement comment les communiquer au reste de l’entreprise.

C’est la première idée concrète qui me vient pour commencer à appliquer ces concepts dans un cadre Scrum. Il y a certainement mieux à faire.

Les trois autres clés

La logique est simple. La conception concurrente est le processus qui permet de chercher et converger vers une solution. Cela fonctionnera seulement si les ingénieurs ont l’expertise pour travailler dans un environnement de conception concurrente, si le leadership de projet maîtrise suffisamment le contexte technique pour prendre des décisions, et le projet est planifié et contrôlé grâce à des responsabilités distribuées.

L’idée est donc que le processus (la recherche de solutions par conception concurrente), les gens, les leaders et le système de contrôle doivent tous être alignés vers ce paradigme « orienté-connaissance ». C’est là que les impacts organisationnels commencent surtout à apparaître :

• l’ingénieur est responsable, et est récompensé pour sa performance (en termes de ce qu’il fait pour le client, et de sa capacité à ajouter de la connaissance). Attention, l’idée est ici d’éviter de le récompenser en le promouvant vers un poste de management. L’idée est que les ingénieurs continuent à faire de l’ingénierie !
• les managers fonctionnels sont des enseignants (ou encore formateurs, mentors). Chez Toyota les managers sont les ingénieurs les plus compétents techniquement et ceux qui ont le plus d’expérience. Ils sont également responsables de la complétude et du contrôle des courbes de compromis : pour eux, ces données (ces connaissances) sont l’équivalent des procédures qualités et documentations des entreprises « orientées-structure ». Cet impact tombe bien, l’une des conséquences identifiées de Scrum est la perte de sens pour les chefs de projets de l’avant Scrum, qui ont du mal à trouver leur place dans un nouvel environnement avec beaucoup d’auto-organisation ! Ici nous voyons que le rôle de mentor est une évolution possible pour ces chefs de projets, et qu’il a beaucoup de valeur dans une organisation « orientée-connaissance ».
• le leadership de projet est responsable de la gestion du processus de conception concurrente, et de la convergence vers une solution. C’est un travail difficile car il y a beaucoup de possibilités et pas de spécifications (je cite le livre). C’est le « Chief Engineer », le champion qui a déjà conçu plusieurs voitures. Il travaille avec les clients, trouver les ressources, combine et raffine les décisions. Les gens ne sont pas sous ses ordres (à part une petite équipe d’intégration). Il doit négocier avec les managers fonctionnels au sujet des ressources et de la qualité de conception. Cela ressemble à un Product Owner Scrum de haut niveau, impliqué dans le technique ?

La fin du livre est consacrée à la gestion du changement pour mettre en place une organisation « orientée-connaissance », mais c’est celle que j’ai le moins comprise pour l’instant – j’y reviendrai peut-être plus tard.

Conclusion

Voilà quelques réflexions inspirées par la lecture d’un premier ouvrage sur la conception (et non pas la fabrication) de produits Lean. Il me semble que l’analyse faite par cet auteur (et d’autres) devrait pouvoir nous aider à trouver des solutions pour progresser dans la maîtrise de Scrum, qui est un excellent révélateur de problèmes, mais qui ne fournit pas de solution prête à l’emploi pour les résoudre. Qu’en pensez-vous ?