"Lean Startup" et "Lean Product Development"

Je profite de la période estivale pour vous parler de « The Lean Startup », un livre de Eric Ries qui sortira en Septembre. En attendant d’acheter le livre, vous pouvez voir ses exposés, par exemple sur YouTube, il existe aussi un Wiki dédié à sa méthode.
Le livre d’Eric Ries est avant tout un livre remarquable sur l’innovation. Eric Ries s'appuie sur des grands classiques (G. Moore, etc.), mais il va plus loin et il apporte des histoires illustratives qu'il explique très bien. C’est également le meilleur livre que je connaisse sur les startups et ce qui fait leur succès. J’y ai retrouvé les perles de sagesse que j’avais recueillies auprès de différents VC (venture capital) en Californie. Par exemple, il y a 5 ans, un très grand VC avec 25 ans d’expérience m’a livré la réflexion suivante : pour une start-up qui arrive avec un produit logiciel, il n’y a aucune corrélation entre son succès et la qualité de son premier prototype (ce qui est brutal !), le succès dépend entièrement de deux choses : le fait d’entendre les premiers clients qui sont placés face au produit, et le fait de savoir s’adapter, y compris de façon drastique, ce que Eric Ries appelle un pivot. C’est, pour finir, un très bon livre pour comprendre comment appliquer le lean dans le monde des services et le monde des “knowledge workers”, et ce qui justifie que je vous en parle. On retrouve ici le lean “façon-Toyota”, celui qui s’intéresse à l’individu, à l’apprentissage en équipe, à l’innovation, à l’excellence.

Comme toujours, voici une liste partielle des points saillants, orientée par mes propres questions et réflexions sur l’architecture organisationnelle:

• Le point le plus intéressant est le concept de « validated learning ». La question que se pose Eric Ries, au sujet d’une startup ou d’une « direction innovation » est la suivante : que produit le « processus innovation » et comment le mesurer ?. La réponse d’Eric Ries est que le processus d’innovation produit de la connaissance sur les besoins, attentes et usage du client. Le validated learning représente une idée créatrice de valeur, validée par des clients et donc démontrée par un objet (logiciel dans la plupart des cas). Je parle d’idée pour représenter le concept qui est « appris », mais cette idée est matérialisée par une expérience (cf. le MVP plus loin). L’objectif d’une start-up, ou d’une direction de l’innovation, est d’obtenir une masse critique de “validated learning”. Sa stratégie, du point de vue lean, est de maximiser la création de “validated learning”, et donc d’acquérir le plus vite possible l’expérience de ses clients et le savoir de ce qui leur est réellement utile. Comme dans toute approche lean, ce processus de création d’expérience est optimisé selon un cycle «build-measure-learn », ce que nous allons voir plus loin.
• Minimum Viable Product (MPV): C'est l'enseignement le plus pratique, le plus essentiel ... et le plus difficile pour une grande entreprise :) . Plutôt que de construire des produits riches et complets, qui peuvent - le plus souvent - passer à côté des vrais besoins des clients, il faut travailler avec des livraisons fréquentes de “petits produits”. De la sorte, (1) on évite les erreurs coûteuses et on rectifie le tir plus rapidement, (2) on est exposé beaucoup plus vite au retour des clients, et on peut commencer plus vite à apprendre de ces retours. C’est bien sûr une application du lean, puisqu’il s’agit de supprimer un des gaspillages les plus importants: créer des “features” que personne n’utilisera jamais ! Le minimum viable product apporte une solution au client, ce qui suppose qu’il existe une question (un problème). Ries propose de se poser les 4 questions suivantes :

• Est-ce que les clients sont conscients d’avoir un problème
• Si on leur propose une solution, est-ce qu’ils l’achèteraient ?
• Est-ce qu’ils achèteraient notre solution ?
• Est-ce que nous savons construire une solution ?

Je recommande chaleureusement de lire l’exemple de Dropbox, pour lequel le MVP est une vidéo qui décrit l’expérience client ! Drew Houston a utilisé une vidéo de 3 minutes pour valider (précisément !) une intuition sur ce que les clients attendaient d’une solution de synchronisation.

• Innovation Accounting: C'est la partie du livre qui relève de l’analyse systémique, ou Eric Ries définit le cycle build-measure-learn pour le processus d’acquisition de “validated learning”. Cette partie est difficile à résumer car elle contient un “cours systémique” sur les différents types de business models, et les indicateurs qui sont pertinents en fonction de ces business models. On retrouve ici le message clé du chapitre 2 de “Processus et Entreprise 2.0”: pas d’indicateur sans modèle (une mesure n’apporte rien si on ne peut pas l’interpréter avec un modèle de fonctionnement). Pour citer Eric Ries “When cause and effect is clearly understood, people are better able to learn from their actions”. L’objectif de l’ « innovation accounting” est d’établir la corrélation entre les progrès - vus et mesurés sur le de vue du client - et les changements sur le produit (ce que l’entreprise développe). Un des points clés est que l’approche “validated learning”, qui forme une sorte de roue d’amélioration continue, est une force de progrès : les réactions négatives des clients sont aussi importantes et utiles que les réactions positives. Elles contribuent dans les deux cas à accroître la connaissance acquise. Selon les termes d’Eric Ries, “the solution is a commitment to iteration”.
• Flows: Les flux de clients sont l’ingrédient principal des business models que nous venons d’évoquer. La section (hélas trop courte de mon point de vue) sur l'analyse des flux clients, des cycles de vie, des cohortes, devrait faire partie du kit de survie pour les managers. Il y a ici, rassemblées en quelques pages, des leçons que j’ai mis un certain temps à apprendre et qui sont essentielles. J'utilise ce type de situation lorsque je donne des exemples pratiques de l'intérêt de l'approche systémique (ma question préférée est : si on attend assez longtemps, est-ce que les parts de parc des opérateurs convergent vers les parts de parc ?)
• Small batches : il faut réduire la taille des “unités d’œuvre” (projets, logiciels, expériences, produits) et travailler avec un cycle rapide de petits incréments. Cette section est une application "text-book" du lean, mais elle est remarquablement expliquée et instanciée. Comme c'est un des axes majeurs d'amélioration pour les directions innovation et développement, c'est un apport majeur de mon point de vue (voir par exemple la remarque sur l'émergence du rework dès que les batchs sont trop importants). Les explications sur les "common misconceptions about the strengths of large batches" illustrent ce qui fait la force du livre : Eric Ries a bien compris et analysé nos résistances au changement (de façon de voir le monde) que représente le lean. Le cycle rapide permet de prendre en compte plus vite le retour client (cf. MVP) et de façon plus générale, il est mieux adapté à un environnement incertain puisqu’il permet de “corriger le tir” plus facilement (l’incertitude étant liée aux attentes clients, aux coûts de développement, à ce que font les concurrents, etc.)

• On retrouve au long du livre d’autres principes du TPS qui sont adaptés au monde de la start-up, comme par exemple la mise en œuvre des “5 Whys”.

La référence qu’Eric Ries sur le sujet de « small batches » est « The Principles of Product Development Flow » de Donald Reinertsen. Je me suis donc empressé de l’acheter et de le lire. Même si le style auto-glorifiant peut agacer, c’est un excellent livre, et c’est la meilleure référence que je connaisse sur le lien entre le lean et la théorie des files d’attente. Cette proximité

systémique est évidente (j’y ai fait allusion dans ce blog et dans mon livre), on la trouve mentionné dans les livres de Michael Georges par exemple. Mais le livre de Reinertsen est, de beaucoup, le plus complet sur ce thème. Pour que les choses soient claires, il ne s’agit pas de réduire le « lean » à une optimisation systémique de la tuyauterie ! Mais il y a une dimension systémique qui hérite de nombreuses disciplines de l’ingénierie de systèmes, depuis les files d’attentes aux réseaux de communication en passant par la conception de systèmes d’exploitation. C’est la contribution principale du livre de Reinertsen, avec une belle bibliographie qui démontre la largeur de sa culture en termes d’optimisation de systèmes. Voici une liste des points qui m’ont le plus intéressé, sachant que je n’insiste pas sur ce que je considère acquis (l'apport de la théorie des files d'attente et ses formules):

• Le premier chapitre « What is the problem ? » commence avec une jolie liste de 12 difficultés liées à l’approche classique du développement de produit. Cette liste est fort pertinente, selon mon expérience, et s’applique aussi bien au développement de logiciel qu’au développement de services, deux activités que je pratique depuis fort longtemps. Ce sera le sujet du prochain European Lean IT Forum, que je vous recommande. Un des points clés (cf. Lean Startup) est que le « fast feedback is key to product development ».
• Un des aspects original du livre est d’aller chercher dans l’expérience de la stratégie militaire des leçons d’organisation, en favorisant le “decentralized control & alignment”.
• La dimension cruciale qui justifie l’application des principes lean au développement de produit est le « Cost of Delay », qui est souvent caché, mal compris voire ignoré. Le COD reçoit une attention toute particulière dans ce livre, avec de nombreux exemples. Dans le modèle générique d’entreprise que je développe (BPEM – le sujet d’un prochain billet et d’un article), je fais du COD une des métriques clé de la performance d’entreprise. Reinertsen propose une analyse dont il déduit des « formules sympathiques », comme celle de la page 69 qui donne le débit optimal en fonction du COD et du « Cost of Capacity ».
• Le livre est émaillé d’application aux organisations modernes et de citations réjouissantes (même si elles sont caricaturales) du type « Capacity is restricted because marketing resources tend to be spread across many opportunities with a low duty-cycle on each activity ».
• On trouve page 98 un joli diagramme systémique qui explique les avantages des « small batches » (cf. plus haut). L’application à l’activité de test logiciel (par exemple, p. 129) est très intéressante. Une citation a propos du TPS : « The 100-fold improvement in manufacturing cycle times was not achieved by finding bottlenecks and adding capacity to the bottlenecks. It was achieved by reducing batch size”. Je vous recommande la liste des examples pratiques, page 136, de “batch size” dans le monde du développement de produit ou de logiciel.
• De la même façon, le concept clé du WIP (Work in Process) est très bien expliqué. L’application de la formule de Little qui lie le WIP au cycle time est mentionné, puis de nombreux exemples/applications pratiques sont mentionnés : shedding requirements , purging low-value projects , blocking demands when WIP reached its upper limit, applying extra resources to an emerging queue, etc. Ce dernier point m’a évidemment rappelé les expériences faites il y a 6 ans sur l’optimisation des processus informatiques (OAI). Un des principes essentiel du maintien des SLA (qualité de service) est la bonne gestion des cas d’exception (cf. p. 160). On y trouver également une reconstruction brillante du heijunka de Toyota : le lissage de la charge à travers des mix d’activité. Une citation sur le contrôle de l’injection de nouveaux projets dans le cycle de développement : « By controling density, we control speed and throughput » (analogie avec l’injection de véhicule sur les autoroutes de Los Angeles pour éviter les bouchons).
• Un autre aspect original du livre est de faire le lien entre l’efficacité d’un processus de développement (vu comme un problème de flot) et les techniques employées dans les réseaux de données (ex : réseaux IP) , telles que le throttling. J’ai particulièrement apprécié ce point puisqu’il fait le lien entre mes deux démarches : l’optimisation des systèmes d’information (cf. mon autre blog et le papier précédemment cité) et l’optimisation de la performance d’entreprise. Reinertsen milite pour « The principle of Differential Service : Differentiate quality of service by workstream » (p. 161), qui est précisément que l’objectif de l’optimisation des processus dans un système d’information. Ce n’est donc pas une surprise si l’on retrouve des approches heuristiques semblables (en termes de priorisation par exemple). Je reviendrai sur ce point technique lorsque j’aurai eu l’occasion de faire des simulations computationelles. En passant, tout n’est pas parfait dans ce livre : la vision sur les algorithmes de scheduling est quelque peu naïve … le sujet est plus complexe que ce pense Reinertsen (il fut un temps ou j’étais un spécialiste de ce sujet).
• Pour finir, ce livre couvre en détail les aspects temporels de la gestion de processus : cadence, synchronization, … On trouve (ex : p.177) des explications imagées et pratiques pour saisir le rôle fondamental de la synchronisation dans le travail des « knowledge workers », une idée que j’ai souvent exprimée dans ce blog, mais qui est remarquablement expliquée par Reinertsen. Je cite par exemple : « Many people assume that holding meetings on-demand will provide faster response time than holding them on a regular cadence. This would be true if everyone was just sitting idle, waiting to be called to a meeting. However, most organizations are loaded to high-utilization rates. It takes time to synchronize schedules for a meeting. This adds an inherent delay, or latency, to the timing of an on-demand meeting”. Une autre citation que j’apprécie parce qu’elle recouvre ce que j’ai appris concrètement sur l’urbanisation des SI: “ In asynchronous circuit, we pass the signal to the next gate as soon as it arrives. This reduces delays, but it permits timing errors to accumulate. In general, asynchronous circuits are faster, but synchronous circuits are more stable”. Ce principe est appliqué avec bonheur aux revues de projet, montrant la supériorité d’une approche synchrone et régulière sur une approche asynchrone (telle que produite par l’email).