samedi, octobre 24, 2020

Conduire sa démarche agile du projet au produit

 

1. Introduction

Le billet de ce jour s’inscrit dans le thème des apports de l’approche lean aux méthodes agiles. Les livres de Mary et Tom Poppendieck ont été une de mes principales sources d’inspiration il y a dix ans, lorsque je me suis penché sur le « Lean Software Development » pour construire l’approche « lean software factory ». Une des idées clés de « Implementing Lean Software Development – From Concept to Cash » est le passage de l’approche projet à l’approche produit. L’approche produit est idéale pour bénéficier des apports du lean : elle permet de se replacer sur le temps long, elle conduit à itérer des releases suivant un processus itératif et répétitif (qui facilite l’apprentissage) et elle remet l’utilisateur (du produit) au centre. Dans l’article « Moving from Project to Product: What Does “Product Thinking” Actually Mean ? » les auteurs soulignent trois ruptures de l’approche produit : passer d’une chronologie fermée (avec un début et une fin) à une chronologie ouverte (sans fin), penser le produit comme un idéal jamais réalisé que l’on approche de façon itérative, et penser de façon systémique (le produit délivre une expérience à un utilisateur).

L’approche produit est plus qu’une idée forte, c’est un savoir-faire différentiant. Il ne s’agit pas simplement de processus et de méthodes, c’est une expertise qui s’apprend par la pratique. C’est pour cela que l’expérience compte, et que les entreprises qui pratiquent le mode produit depuis un certain temps construisent une capacité de différentiation. Tout comme l’excellence opérationnelle, la maîtrise du mode produit ne se copie pas simplement. Il ne suffit pas d’avoir lu l’excellent article de Sriram Narayan, « Products over Projects », il faut mettre en place un nouveau flux de travail et laisser aux équipes autonomes le temps d’apprendre à travailler autrement.

Ce billet est consacré au livre de Mik Kersten, « Project to Product », qui explique que la maîtrise de l’approche produit est essentielle à la compétitivité des entreprises du 21e siècle. C’est une thèse forte, qui résonne avec les conclusions de mon dernier livre. Le logiciel dévore le monde, l’excellence logicielle crée des disruptions, et les entreprises qui dominent la scène digitale ont pris une longueur d’avance dans cette pratique de l’approche produit. Le sous-titre du livre, « How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework », illustre un des points essentiels que développe Mik Kersten : la nature VUCA de l’environnement des entreprises aujourd’hui, et l’importance de la transformation numérique du monde, font qu’il est vital pour la quasi-totalité des entreprises d’apprendre à développer leurs outils logiciels avec la même qualité et efficacité que les « Géants du Web ».    

La suite du billet est donc organisée autour de 7 idées essentielles sur le développement logiciel dans le monde moderne, centrées sur l’approche produit. J’ai beaucoup apprécié l’engagement de Mik Kersten, qui s’appuie sur sa propre expérience et sur les échecs qu’il a constaté en première ligne, pour expliquer le besoin d’enrichir les approches agiles. Certains d’entre vous pourraient me dire qu’une partie de ces idées sont maintenant parfaitement connues et intégrées, comme par exemple dans l’approche SAFe. L’intérêt du livre de Mik Kersten est d’aller au fond des choses et de donner de multiples exemples ; il devrait donc être une contribution éclairante même si le mot « produit » fait maintenant partie de toutes les bonnes méthodologies de développement logiciel. Ce livre peut irriter de temps à autre car l’auteur, CEO d’une entreprise qui vend des outils logiciels pour réussir le pilotage du mode produit, passe de temps en temps en mode « consultant commercial ». Il s’agit cependant d’un livre essentiel pour comprendre l’importance et l’urgence du passage au mode produit, comme le souligne Anthony Crain dans « Projects to Products : What it means, Why it matters ». Le livre contient une analyse comparative avec l’usine ultra-moderne de BMW, qui est passionnante et que je vous recommande de lire. Comme chaque fois dans ce blog, je vais me concentrer sur quelques aspects essentiels du livre, avec un choix éditorial personnel.

 

2.     Du Projet au Produit
 

2.1   La nécessité de changer la façon de développer les systèmes numériques

L’idée que la transformation digitale est difficile, et que de nombreuses entreprises peinent à réaliser leurs ambitions, n’est plus un secret honteux et se retrouve au grand jour dans de nombreux ouvrages. C’est par exemple l’angle d’attaque du livre récent, « The Digital Transformer’s Dilemma », sur lequel je reviendrai dans un autre billet. Mik Kersten partage cette analyse : « However, as we will learn in this chapter, the problem is that those transformations are failing. The main reasons for failure, according to Altimeter’s report “The 2017 State of Digital Transformation,” are a shortage of digital talent and expertise (31.4%), general culture issues (31%), and the treatment of digital transformation as a cost center instead of an investment (31%). None of these are root causes of transformation failure; rather, they are symptoms of a fundamental disconnect between business leaders and technologists that we will review throughout this book ».  Cette citation permet tout de suite de voir le point commun avec la thèse de ce blog : il ne suffit pas de penser sa transformation digitale, il faut avoir les moyens (compétences et technologies) de l’exécuter. L’excellence du développement logiciel (dans un monde où le mot développer signifie intégrer, créer, partager, réutiliser … au sein d’écosystèmes ouverts) est une nécessité pour les entreprises modernes. Bien sûr, cela passe par l’adoption de l’approche agile pour s’adapter à la variabilité du monde digital : « Manufacturing has a fixed, well-defined set of variations for what will emerge from the end of the line, whereas the design of software features is open ended. Manufacturing needs to minimize variability; software development needs to embrace it ». Mais, comme le souligne Mik Kersten, travailler en mode agile ne suffit pas : « I had a chance to witness the pitfalls of this trap firsthand. Working with Nokia, I noticed that management was measuring the success of its digital transformation by how many people were trained on Agile software development methodologies and were onboarded onto Agile tools ».

Nous allons voir progressivement, dans la suite de ce billet, ce qu’il est nécessaire de mettre en place pour développer cette excellence du développement logiciel agile, mais les lecteurs curieux pourront jeter un œil à cet article plus ancien de Mik Kersten, « How to garantee failure in your agile DevOps transformation». Il ne suffit pas d’appliquer les approches modernes de transformation des organisations de développement (digital ou IT), il faut « le faire de façon excellente, avec un profond intérêt pour le produit logiciel et les femmes et les hommes qui le construisent ». Les « anti-patterns » soulignés par Mik Fersten – toute ressemblance avec votre réalité serait fortuite – sont le contraire du respect des personnes (le pilier de l’approche lean) : « Push all tools top-down, limiting choice as much as possible ; Worry about integration later, your internal IT team can handle it ; Optimize your tool chain one silo at a time ; Forget about requirements and quality management ; Ignore Ops and ITIL, they ought to be out of scope; Put someone junior in charge of integrating the value stream; Don’t bother with metrics ».

 

2.2   Pour changer l’horizon du possible, il faut passer de l’approche projet à l’approche produit

Sans surprise, puisque c’est le titre du livre et de ce billet de blog, la plateforme pour construire l’excellence du développement logiciel au 21e siècle est l’approche produit : « Project-oriented management frameworks work well for creating bridges and data centers, but they are woefully inadequate for surviving the Turning Point of the Age of Software ». Il ne faut pas oublier la première partie de la phrase, l’approche produit n’est pas le « silver bullet » qui devrait s’applique pour tous et partout. D’abord parce qu’elle est complexe et longue à mettre en place, mais aussi parce qu’elle correspond à des conditions d’application qui ne se retrouvent pas partout. L’approche produit est en premier lieu une « approche équipe », une philosophie du travail, qui suppose qu’on dispose d’équipes stables (« long lived ») qui vont pouvoir bénéficier de l’autonomie nécessaire pour construire leur apprentissage du mode produit. On retrouve directement l’influence de Daniel Pink sur l’importance de la motivation intrinsèque pour réaliser les apprentissages complexes : « Daniel Pink and others have demonstrated that happy and engaged staff produce better results when creative work is involved. Project-oriented management gets in the way of the autonomy, mastery, and purpose identified by Pink as key to job satisfaction, whereas product-oriented stability of work and teams promotes them ».

Là où l’approche projet crée de façon temporaire des équipes par assemblage de talents qui sont « déplacés » pour aller réaliser le projet (« bringing people to work ») , l’approche produit repose sur une équipe stable : « High-performing software organizations have already learned that “bringing work to people” is more effective. Long-lived teams allow for expertise (both individual and team) and relationships to build over time, improving both velocity and morale ». On retrouve ici les racines profondes du lean : donner aux collaborateurs les conditions de travail qui leur permettent d’apprendre en profondeur le système qu’ils construisent.

Ce qui fait de l’approche produit une plateforme pour l’excellence, c’est la capacité d’améliorer de façon continue et en même temps le produit et le processus qui construit le produit (ce qui est plus difficile en mode projet, car cela demande un « passage à l’abstraction » pour identifier les récurrences et les améliorations). Mik Kersten insiste sur le fait de travailler en premier avec des métriques métiers (associées à la satisfaction des clients et la création de valeur) qui représentent les objectifs, et de considérer les métriques techniques comme des outils qui représentent des moyens : « Quality metrics that are not visible to the customer, like defect aging and change success rate, can provide important leading indicators of quality problems. However, they should remain one level down, as the Flow Framework focuses on customer- and business-visible metrics ».

2.3   Les entreprises qui aspirent à une transformation digitale doivent s’inspirer des géants du Web

Développer ses compétences d’usine logicielle à produit, depuis l’outillage jusqu’aux pratiques en passant par les modèles mentaux, la culture et l’état d’esprit (tout ce que recouvre le mot galvaudé de « mindset ») est long et difficile. Mais c’est juste indispensable ; pour Mik Kersten, la différence de performance ne souffre aucune comparaison : « The result is that the software delivery efficiency of these companies is abysmal when compared to that of digital startups or the tech giants ». Comme le rappelle souvent Eric Chaniot, notre CDO chez Michelin, le changement du « mindset » est le point de départ essentiel. Ce que souligne Mik Kersten : « This mind-set has grave implications. If the current trajectory does not change, the incumbent companies that form the backbone of the world economy are at an inherent and significant disadvantage ».  L’approche qui est proposée dans ce livre ressemble beaucoup à ce qu’on trouve dans le livre de Nicole Forsgren et Jez Humble, « Accelerate », mais  Mik Kersten insiste plus fortement sur l’enjeu stratégique que constitue la réussite de cette transformation : « Organizations can and must change in order to create the software innovation engines that will ensure their competitiveness and survival. To do that, we need to learn from the history of previous technological revolutions instead of assuming that we are in a completely unique moment in time ». Mik Kersten fait ici référence aux travaux de Carlota Perez pour introduire deux âges de la transformation numérique : celui de l’installation (les décennies précédentes) et celui du déploiement dans lequel nous sommes entrés. La période d’installation est marquée par le foisonnement et l’expérimentation, celui du déploiement est marqué par l’efficacité et la rationalisation. Comme pour les révolutions industrielles précédentes, les acteurs dominants s’imposent par la maîtrise des nouveaux processus de production : « Once we reach the Deployment Period, companies that have not adapted to the new means of production will decline in relevance and market share ». Pour la transformation numérique, il s’agit de maîtriser les “nouvelles méthodes” du développement logiciel (de l’agile à DevOps) à l’égal des meilleurs : « Even with the combination of innovation and great products, Jawbone lost out to production-capital companies like Apple. The smartwatch innovator Pebble closed its doors in December 2016 for similar reasons ».  

Ce dont il est question ici n’est simplement la production de logiciel (qui n’est pas un but, mais un moyen), c’est la production d’un flux continu de valeur - qui est appelé « software value stream » dans le livre. Ce flux de valeur est porté partiellement par le développement logiciel, mais il s’agit bien de comprendre et d’optimiser l’expérience du client. Mik Kersten parle beaucoup de « end-to-end », dans un cadre plus vaste que le processus CICD : « In the context of a software value stream, the concept of “end-to-end” includes the entire process of value delivery to the customer. It encompasses functions ranging from business strategy and ideation all the way to instrumentation of usage to determine which values were most adopted by the customer base ».  Je vous renvoie également à l’excellent livre de Nathan Furr et Jeff Dyer, « The Innovator’s Method », qui décrit ce processus dans sa dimension « end-to-end ».

 

2.4   La cause racine de l’amélioration des performances est l’optimisation des flux

Un des principes fondamentaux de l’approche lean est le « streamlining » pour fonctionner en flux continus. Donald Reinersten fait de l’optimisation des flux une pierre angulaire du développement des produits, en constatant que le plus grand gaspillage constaté est le temps que les composants de produits attendent sans recevoir d’attention, entre deux étapes du process de développement. Ces temps d’attente sont les ennemis de l’agilité (ils augmentent la probabilité de rework parce que le monde évolue) et de l’efficacité (ils introduisent des ruptures de charge et de contexte). Ils sont aussi la cause première d’une autre forme de gaspillage : le temps d’attente des membres de l’équipe. Je me souviens encore d’un premier diagnostic lean effectué dans un job précédent il y a plus de 10 ans, qui avait conclu à trois diagnostics : « vous passez votre temps à vous attendre », « vous refaites plusieurs fois la même chose » et « une partie très importante du code produit n’est jamais mis entre les mains des utilisateurs ».

La méthode proposée par Mik Kersten est le « Flow Framework », une approche qui fait du flux de création de valeur le premier sujet d’attention. L’objectif de l’attention portée à ce flux est de s’assurer de la synchronicité entre le flux des demandes (besoins) et le flux de production (éléments logiciel) : « The Flow Framework is a new way of seeing and measuring delivery and aligning all of your IT investments according to value streams that define the set of activities for bringing business value to the market, via software products or software as a service (SaaS) ». Tout comme la réorganisation des usines Toyota par Taiichi Ohno était une rupture il y a 70 ans, repenser l’organisation – des équipes comme du système d’information, liés par la Loi de Conway  – est un changement de paradigme : « In contrast, the disconnect between the business and IT is massive, as are the disconnects within IT organizations. The common approach to enterprise architecture is wrong, as it tends to focus on the needs of the technologists and not on the flow of business value ».

L'attention portée à l’optimisation du flux doit se traduire dans l’automatisation (on retrouve ici DevOps) et les outils mis à disposition des développeurs. Le livre cite de nombreuses études qui montrent que le travail de développement de code n’est pas continu et subit de nombreuses ruptures : « A developer’s primary function and expertise is coding, yet studies summarized in this book have shown that developers spend more than half their time on manual processes due to disconnects in the Value Stream Network ». Qu’il s’agisse des développeurs comme des utilisateurs des systèmes réalisés par ces développeurs, l’expérience apprend que les entreprises accumulent des patchworks d’outils, mal connectés, et qui exigent beaucoup d’actions manuelles pour inter-opérer : « For example, after conducting an internal study on one bank’s software delivery practices, we determined that, on average, every developer and test practitioner was wasting a minimum of twenty minutes per day on duplicate data entry between two different Agile and issue-tracking tools ».

Construire des flux efficaces demande de la régularité (éliminer le mura dans le jargon lean), et cela passe par la création de buffers. Cela demande aussi d’éviter les pics de charge qui déséquilibre le flux : « Excessive flow load can be correlated to inefficiency. For example, Reinertsen states that excess utilization of a value stream dramatically affects velocity due to excess queue times ». Les observations de Reinertsen ne sont que les conséquences de ce que nous apprend la théorie des files d’attentes, et en particulier la formule de Pollaczek-Krinchine, que j’aime citer dans ce blog. Cette formule, qui met en avant à la fois l’importance de mura (régularité) et de muri (taux de charge) dans le temps de service, est un bijou de concision pour ceux qui aime voir le lean à travers un prisme systémique. C’est bien sûr ce qu’on observe dans la pratique : « As DeGrandis summarizes, the result of seeking full utilization is similarly problematic for software delivery as it is for manufacturing, having a negative effect on flow velocity and flow time ».

 

2.5     L’approche produit est une approche systémique tournée vers l’adaptation continue 

Mik Kersten explique fort bien pourquoi l’approche produit est bien adaptée à notre monde VUCA. En premier lieu, l’approche produit est itérative, sur une longue échelle de temps (toute approche agile itère des sprints, mais l’approche produit itère sur un temps ouvert). La démarche proposée dans ce livre permet de construire, de façon itérative, un équilibre entre trois exigences : fournir les fonctionnalités attendues par le client,  rendre le produit résistant et résilients aux risques – comme par exemple le risque de cyberattaque – et maintenir le produit dans un état d’adaptabilité constant, ce qui passe par la suppression continue de la dette technique : « technical debt reduction, which describes the need to perform work on the software and infrastructure codebase that, if not done, will result in the reduced ability to modify or maintain that code in the future ». On retrouve ici une idée que j’ai développée dans mes blogs : la dette technique est l’ennemi de l’agilité, tandis que le mode incrémental de développement produit structurellement de la dette technique. L’approche produit, parce qu’elle se place sur le temps long, est une solution pour résoudre ce paradoxe du développement agile.

En deuxième lieu, ce qui rend l’approche produit adaptative est son ancrage sur le client. C’est trop souvent implicite et cela mérite d’être souligné : on parle de produit parce qu’il y a un client (un utilisateur). C’est ce qui fait la différence entre un composant et un produit dans le système d’information : cette différence tient dans la culture et l’attitude (le « mindset ») bien plus que dans la technologie. C’est pour cela qu’on peut adapter une « approche produit » à des artefacts techniques comme des APIs de fourniture de données. Faire du client l’étoile polaire de l’équipe de développement est la meilleure façon de réaliser que le monde change constamment et que les attentes et usages des utilisateurs évoluent. Mik Kersten, par exemple, met en garde sur l’abus d’utilisation des processus, si l’on perd cette finalité de l’utilisateur : « A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right ».  Faire du client l’étoile polaire de l’approche produit conduit naturellement à faire le lien avec l’approche Lean Startup – ce qui est le socle de mon dernier livre : «  In contrast, Lean Startup and approaches such as minimum viable products (MVPs), are a key part of the product-oriented mind-set. In addition to reducing risk, the incremental product-oriented approach creates option value by allowing the business to pivot at regular checkpoints ».

Pour finir, ce qui augmente l’adaptabilité de l’approche produit est l’apprentissage long et continu de l’équipe (on retrouve l’importance des long-lived teams). C’est une des idées fondamentales du lean : construire des équipes dont chaque membre possède une compréhension correcte de l’ensemble des rôles, parce que cela facilite à la fois l’efficacité (réduction des coûts de transaction dans la collaboration entre membres de l’équipe parce qu’il existe un contexte partagé) et l’adaptabilité (l’équipe est plus « intégrée » et peut réagir plus vite pour changer plus profondément). La combinaison du temps long, des itérations et des équipes stables favorise cet apprentissage. Autrement dit, l’équipe doit développer les fameux « profils en T » (chaque membre a une expertise profonde sur son domaine propre, mais également une compréhension large du domaine collectif).  Mik Kersten cite à ce sujet « Team of Teams: New Rules of Engagement for a Complex World » du General Stanley McChrystal, qui donne plusieurs exemples pour comprendre que la trop grande spécialisation crée des « fault lines » (lignes de faiblesses) entre les différentes équipes.

 

2.6   Le passage à une approche produit est une démarche métier

La démarche produit s’appuie sur des équipes mixtes qui combinent la vision métier et la vision technique pour maximiser le flux de valeur apporté au client. Le flux de valeur que nous avons évoqué plus haut est à prendre dans un sens global : « Value Stream: The end-to-end set of activities performed to deliver value to a customer through a product or service  ».  Puisque la démarche est centrée sur la création de valeur, il faut à la fois un engagement complet du senior management de la « line of business », et la capacité à regrouper dans l’équipe produit l’ensemble des talents qui lui permette de travailler de façon la plus autonome possible, par opposition aux classiques « silos » : « Value streams are composed of all the activities, stakeholders, processes, and tools required to deliver business value to the customer. While this may sound obvious, my second epiphany was all about the fact that instead of creating abstractions around end-to-end value streams, organizations keep creating them within functional silos ». C’est ici le bon moment pour noter que l’insistance sur le value stream (qui est la colonne vertébrale du livre) témoigne de l’expérience B2B de l’auteur et son habitude de travailler sur des flux de demandes clients. Dans le monde B2C des services digitaux, il existe une part plus forte de risque et d’incertitude, qui rendent la démarche de création de valeur plus aléatoire (même avec une approche produit). Certains passages du livre me font penser à l’approche SAFe, en donnant la fausse impression qu’une approche centrée sur la valeur et la satisfaction client ne peut pas échouer.

Une des contributions essentielles de l’approche produit est de trouver de façon dynamique un équilibre entre l’ajout de fonctionnalité, la réduction des risques et la réduction de la dette technique : « Through the lens of the Flow Framework, we know that there is a zero-sum game in the number of features added, defects fixed, and risks mitigated ». Le point clé d’une équipe mixte métier/technique est d’éviter le clivage traditionnel « features pour le métier, réduction de dette pour satisfaire l’équipe technique », un clivage qui ne résiste pas longtemps si l’on prend un point de vue « centré client » qui sert de boussole à l’ensemble de l’équipe produit. Mik Fersten souligne également ce qui devrait être une évidence en 2020, mais qui n’est pas encore compris par tous, les leviers de l’agilité ne s’activent pleinement que si les principes sont compris et partagés par l’ensemble des parties prenantes : « all the specialists in IT are already starting to work in this new way by adopting Agile teams and DevOps automation, but these specialists lack the infrastructure and business buy-in to do so effectively ».

De la même façon, les principes lean tirés de l’optimisation des files d’attentes – la nécessité de piloter la charge, et de conserver des « buffers » pour maximiser la flexibilité – demandent une adhésion des acteurs métiers. L’auteur insiste sur le besoin, pour les responsables métiers d’aujourd’hui, de mieux comprendre les clés de l’efficacité du développement produit : « My key takeaway from that experience was that in the Age of Software, for wealth to be shared across the economy, we need this kind of strategic decision-making framework to be available to all business leaders ». Pour être plus précis il y a bien une double exigence,  celle de comprendre les principes de l’optimisation des flux de valeur et celle de comprendre la nature de l’activité de développement logiciel : « But everyone wanting to make sound decisions around IT and software investment must understand software delivery at the level of business value flow ».

 

2.7   Plus le logiciel dévore le monde, plus il faut des méthodes et des outils 

Dans ce passage à l’âge du déploiement, la recherche de l’automatisation et de l’excellence des pratiques s’impose. C’est précisément ce qui marque l’apparition des entreprises excellentes du domaine : elle profite du « first mover advantage » du monde numérique pour transformer un avantage de position en un avantage d’excellence opérationnelle, qui est plus difficile à rattraper. Un des thèmes du livre est, logiquement si l’on considère l’entreprise dont Mik Fersten est le CEO, l’utilisation de méthodes et d’outils pour éliminer les ruptures dans le flux de valeur : « Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream ». Plus généralement, le livre contient un plaidoyer pour l’automatisation, selon une approche DevOps, de tout ce qui peut l’être dans le processus d’intégration et de déploiement continu (CICD). L’objectif est bien d’automatiser ce qui est simple et répétitif pour se concentrer sur la création de valeur dans la partie créative du développement. L’accent sur l’automatisation ne signifie pas que le développement de produit logiciel est répétitif et industriel. Au contraire, le livre souligne la nature créative du développement logiciel : « Software delivery is, by its nature, creative work. Software specialists are skilled at automating repetitive processes when given the chance, leaving only the complex work and decision making that humans continue to excel at ».

Un des principes lean qui trouve toute sa place dans le développement logiciel est de rendre visible les choses invisibles, tels que les problèmes, le travail en cours, ou les composants qui attendent. Mik Fersten cite plusieurs fois le livre de Dominica DeGrandis, « Making Work Visible: Exposing Time Theft to Optimize Work & Flow », qui souligne, comme conséquence de l’optimisation des flux, l’importance de rendre le « work in progress » (WIP) visible pour mieux le maîtriser : « excess WIP is the enemy of productivity due to the negative effects that overutilization has on output ». La visualisation des flux est d’autant plus importante qu’il ne s’agit pas simplement du code ou des objets logiciels qui participent au produit, il d’agit également de tous les flux d’information qui contribuent à la définition et à la réalisation du produit. Le livre contient de nombreux exemples qui montrent à quel point les développeurs passent du temps à retrouver des informations nécessaires autour d’un contexte donné. Par exemple, il donne l’exemple du Boeing 787 pour lequel la traçabilité des exigences (un classique du développement produit) a joué un rôle important : « The story of the Boeing 787 brake software in Chapter 2 illustrates how critical traceability automation is to evolving and maintaining large-scale software ». Il s’agit donc à la fois d’une opportunité pour réduire des gaspillages (de temps) et d’améliorer le flux (streamlining).

 

3.     Conclusion

Pour conclure, je souhaite souligner que le fonctionnement en « mode produit » est un des principaux apports d’une approche lean aux méthodes agiles, un sujet que je développe dans mon dernier livre. Le livre de Mik Kersten est entièrement construit sur des concepts lean : value stream mapping, flow optimization, élimination des muda, mura et muri.  La rupture que représente le passage du mode projet au mode produit peut se résumer selon les quatre points suivants :

  • Le passage au mode produit change l’horizon de temps. Il nécessite un engagement « long terme » du métier, ce qui permet d’engager la puissance d’une approche lean confiée à une équipe autonome. En particulier cette autonomie se traduit dans un mode de financement (Build & Run) qui permet à l’équipe de piloter le court et le long-terme, et de faire les arbitrages nécessaires à la satisfaction durable du client.
  • L’approche produit est confiée à une équipe transverse, stable dans la durée. Le partage du même contexte et des mêmes objectifs par l’ensemble de l’équipe, technique et métier, est nécessaire pour libérer la capacité d’innovation.
  • L’approche produit est itérative et adaptative (chaque itération influence la suivante). Elle utilise le plus possible l’automatisation du processus CICD pour se concentrer sur la valeur apportée au client. Dans un monde qui change constamment, cette satisfaction n’est jamais acquise et se gagne chaque jour.
  •  L’approche produit permet de corriger de façon continue et adaptative les défauts propres à toute méthode itérative : l’équipe contrôle l’accumulation de la dette technique et ré-évalue régulièrement les risques et les réponses à y apporter.

 

 

1 commentaire: