dimanche, janvier 31, 2021

Les défis de la transformation digitale

 

1. Introduction


L’année 2020 a été marquée, en ce qui me concerne, par la transformation digitale. C’est évident de façon globale, à cause de l’accélération produite par la pandémie. C’est également vrai à titre personnel puisque 2020 est l’année de sortie de mon livre « l’approche lean de la transformation digitale ». Le court billet de ce jour va compléter la bibliographie que j’ai commenté dans de multiples billets de ce blog avec un nouveau livre sur la transformation digitale, sorti en Février 2020.

Avant de butiner quelques idées remarquables, il me semble utile de souligner les quatre points qui sont essentiels pour comprendre la transformation digitale. Ces quatre idées forment la colonne vertébrale de mon propre livre; je ne fais que les évoquer, ces points sont connus et traités dans d’autre billets du blog.

  1. « Markets are conversations ». La numérisation du monde, la mondialisation et la société d’abondance a changé la nature de la relation entre l’entreprise et son client. Il faut passer du « push » au « pull », et articuler une stratégie de contenu pour initier les conversations. Pour reprendre la formule géniale de Doc Searls, on passe de « transaction > relation > conversation » (les transactions avec des clients construisent une relation qui permet de développer une conversation) à la forme inverse « conversation > relation  > transaction » (le développement de conversations permet de développer une relation (intimacy) qui ensuite offre la possibilité de transactions).
  2. « Customers are the architects of their experiences ». Passer du produit à l’expérience est la marque de la véritable « customer-centricity ». L’expérience est globale, elle est centrée sur le client, elle s’appuie sur un écosystème dont l’entreprise n’est qu’un des participants.
  3.  « Empowerment is the consequence of rising complexity». Cette idée géniale et profonde a été exprimée en premier lieu (pour moi) dans « The World is Flat » de Thomas Friedman. Même dans le monde du big data et de synthèse des « insights », la numérisation des produits permet une véritable personnalisation. On ne peut pas vraiment comprendre la puissance de l’approche API (un des traits de la transformation digitale) sans saisir l’importance de ce  « shift-right » : laisser une part plus importante des décisions entre les mains de l’utilisateur. C’est aussi vrai dans le B2B que cela l’est dans le B2C.
  4. « Think Platform because there are more smart people outside than inside your company ». La numérisation du monde permet d’accélérer la collaboration et la co-construction. La transformation digitale de l’entreprise implique de savoir attirer les talents et les contributions externes en se pensant comme une plateforme.

Pour les lecteurs férus de systémique, on peut remarquer que ce besoin de « shift-right » (laisser l’utilisateur en charge d’une partie de la complexité) est la conséquence de la Loi de la variété requise d’Ashby et de ce que Nassim Taleb explique sur la nécessaire simplicité des règles pour garder la résilience face à l’incertitude. L’art de l’exposition de service est de déterminer quel part de la complexité doit être absorbée par l’entreprise pour décharger ses clients, sans prendre en charge ce qui doit être laissé à l’appréciation en situation, par le client, dans son contexte (ce que représente l’expression « architect of his experience »).

Ce cout billet est simplement organisé autour de « Deliberately Digital – Rewriting Enterprise DNA for Enduring Success », un livre écrit par une équipe Européenne d’ATOS : Hubert Tardieu , David Daly, José Estaban-Lauzan, John Hall et Georges Miller. Il s’agit d’un livre intéressant qui arrive à être original, sur un sujet très encombré, par sa perspective Européenne et systémique. Il est articulé autour de deux axes : l’orientation client (customer-centricity) et la capacité élastique à déployer à grande échelle (to scale). Ce livre est « Européen » à la fois dans les exemples mais également dans l’approche conceptuelle et systémique de la transformation digitale. Il s’appuie sur une approche « bimodale » : d’un côté, améliorer son efficacité sur son modèle d’affaire, ses produits et ses services existants part la numérisation de son activité, et de l’autre côté, développer des nouveaux modèles d’affaire, produits et services qui tirent partie de la digitalisation de son environnement. On retrouve ici précisément l’approche de « Designed for Digital » que j’ai abordée dans un billet précédent. Cette vision systémique, qui fait la part belle à la notion de capacité, permet de comprendre que la transformation digitale est difficile – je reviendrai sur ce thème avec la revue du livre « The Digital Transformer’s Dilemma » dans un prochain billet – elle demande de la patience et une approche de temps long, focalisée sur le management de l’émergence. Ceci exige une implication personnelle des dirigeants, de la persévérance et l’abandon de l’  « illusion du contrôle » chère à Frédéric Laloux.


2. « Deliberately Digital »

Je ne vais pas proposer un résumé du livre mais me concentrer sur quelques points clés. Le livre contient un développement classique sur le rôle de l’organisation afin de favoriser la transformation, l’importance des équipes (« Create (virtual) multi-functional teams to avoid wasteful handovers between siloed divisions ») et des méthodes de développements (Agile, Lean, DevOps). Sur ces trois thèmes, je vous laisse lire le livre vous-même et retrouver des idées que j’ai déjà eu l’occasion de partager dans ce blog. Je vais me concentrer sur six idées clés du livre qui me semblent être des contributions plus originales ou plus saillantes, à l’analyse de la transformation digitale.

Le livre utilise astucieusement le «  CYNEFIN framework » (qui distingue les domaines complexes, compliqués, simples et chaotiques) pour segmenter différentes composantes d’une transformation digitale. Il termine par une superbe citation de l’antropologue Pascal Picq qui caractérise l’importance de l’émergence et de l’appropriation par les acteurs dans une transformation complexe telle que la transformation digitale : « It is appropriation ; it cannot be anticipated. Some things are emerging without prior need. They may not be selected because there is no need. But if they are selected, they can change the world as they serve as basis for an invention to become an innovation. Innovation can change practice and society. … . Inventions emerge without answering an absolute need in our society. We are in a world where solutions are waiting for problems. We are in a completely Darwinian world ». 

 

2.1   Le succès de la transformation digitale s’exprime selon deux axes : la connaissance intime de ses clients et la capacité de démultiplication (to scale) des opérations.

 

Ces deux axes forment la structure du livre : comment développer les capacités sur ces deux dimensions, qui permettent d’assurer l’impact de la transformation digitale ? Cet impact passe par le changement induit sur les clients de l’entreprise : « We believe that a successful digital transformation will be measured by its societal adoption, no matter how well defined its “hard” business KPI may be ».  Le chapitre 7 insiste sur l’importance d’une stratégie de transformation digitale, qui soit connue et communiquée, et qui se place résolument sur le long-terme (« short-termism is one of the sight of our time ») et conçue comme une réponse à un environnement en perpétuel changement. La transformation digitale va émerger de façon distribuée, comme un système complexe, mais sa finalité est unique, partagée et comprise par tous.

 


Comme cela a été dit en introduction, la stratégie proposée par les auteurs repose sur une approche bimodale qui rappelle celle des livres « Designed for Digital » ou encore « The digital Transformer’s Dilemma » ( l’approche des deux « courbes en S ») : « A digital transformation can be approached from two different perspectives : (1) Optimization ans transformation of existing busines process with little or no change to the core business model (2) Fundamental transformation of the business model to deliver new services and products in  new and disruptive ways. … . It is important to understand that for most businesses, this does not represent an either/or choice ».  La première dimension de la transformation digitale est une optimisation :  « Achieve the optimization of existing business processes by working on the five categories : asset utilization and performance, employee productivity, cost reduction by process automation, new revenue opportunities and source of data-driven value, and customer experience and engagement ». Je recommande au lecteur de lire avec attention les recommandations de la section 7.6. On y retrouve par exemple une référence au « Innovator’s dilemma » : « Keep the innovator’s dilemma in mind. Incumbents may fail by seemingly doing the right thing every step of the way ». Il s’agit bien d’une approche “Et” (en même temps) : exécuter les deux dimensions de la transformation digitale en même temps car la seconde a besoin de la première.


2.2   Malgré une volonté affirmée, de nombreuses entreprises rencontrent des difficultés à réaliser cette transformation digitale

Cette difficulté, qui est également évoquée dans les deux autres livres que j’ai cités, est inhérente à une ambition de transformation profonde et obtenue par émergence, alors que beaucoup d’entreprises attendent des résultats rapides et contrôlés : « The pressure (both internal and external) to deliver short-term, demonstrable results from digital transformations can be significant. This often leads to somewhat parochial and limited scope activities that deliver “skin deep” results. They give an illusion of something different and new buy, in reality, the underlying core business process are still reliant on legacy, old-world processes, and technology ». Les auteurs donnent différents exemples de cette schizophrénie dans la conduite de la transformation, mais je ne résiste pas au plaisir de citer le symptôme bien connu du  « water-scrum-fall », l’application des  « méthodes agiles » à l’intérieur d’une gouvernance classique (« waterfall ») de projet : « Another fort of applying digital varnish comes from overpromising on the expectations of digital. Failure to realize the promised benefits will inevitably lead to disappointment … An example might be that of using waterfall project management approaches for overseeing agile development programs. Almost inevitably this leads to sub-optimal outcomes at best ».

Comme indiqué en introduction, les auteurs insistent sur la nécessité du support complet de l’équipe de direction pour la transformation digitale: « a CDO cannot be successful in any of these missions, without the support, buy-in, and commitment from the rest of the Executive Committee ».  Par exemple, le premier axe de la transformation, la connaissance intime des clients, repose sur une « orientation client » qui doit être une responsabilité et un objectif de l’ensemble de l’entreprise. Les auteurs remarquent que la difficulté de vivre cet engagement d’orientation client est souvent un frein à la transformation digitale : « “Customer-first” is treated as an essential part of many businesses’value statements. Despite this, we continue to observe that there is a massive gap between those organizations which authentically practice “customer-first” and those that are just paying lip-service to it »

2.3   Le cœur de la transformation digitale est l’orientation client.

Le terme anglais est « customer centricity », je pourrais traduire dans ce contexte par « l’obsession du client ».  Il s’agit bien du point de départ de la transformation digitale : « For many organizations, customer engagement and experience are where digital transformation begin  ».  La définition que les auteurs proposent pour cette approche « customer-first » est fondée sur le fait se de placer à la place du client et de considérer son expérience complète. C’est ce qui tire les approches de design d’expérience utilisateur et l’utilisation de méthodes telles que le Design Thinking : « Listen with purpose: Design Thinking is proving a powerful means to create innovative new concepts. … an excellent way to map customer journeys, understand customer needs and wants, identify the “pains” and “gains” associated with these, and define new concepts for further development and evaluation ». Il convient de se rappeler ici que le monde numérique est un monde d’abondance qui entraine un renversement du rapport de force entre le producteur et le consommateur. En conséquence, il faut également se souvenir que le premier moteur du Design (Thinking) est l’observation.

 

L’approche systémique que je mentionnais en introduction se retrouve dans la place que le livre laisse à l’apprentissage et aux boucles de rétroaction (feedback) : « You will notice that this customer-first belief system has strong, positively reinforcing feedback loops embedded withing it. These feedback loops can enable to create powerful momentum which can drive out the competition». C’est évidemment une conviction que je partage, puisque j’ai fait du « Customer Feedback Learning Loop » (CFLL) un des pivots de mon propre livre. Le livre « Deliberately Digital » fait plusieurs références à l’approche Lean Startup (qui est un parfait exemple de l’utilisation des boucles de rétroaction) pour apprendre à innover à partir des besoins de ses clients :  « Innovating against customer needs : … This capability is especially powerful in today’s digital world given the pace at which competition can create a “fast follower” response». Pour les auteurs, réussir sa transformation digitale exige de passer d’un modèle linéaire d’organisation (organisé selon un pattern “AIDA”: Awareness, Interest, Decision, Action) à une approche systémique construite sur des boucles : « organizations have found that custoomer journeys are better representeed by a more interactive set of feedback loops with multi-way interactions ». C’est très précisément ce que représente le mot “conversation” dans “Markets are conversations”. Ces conversations sont essentielles dans la réussite de la stratégie digitale : « Having great products is one thing, having people buy them is another … digital leaders need to generate customer interest and excitement in their brands and in their latest offers ». Les conversations forment les fondations de l’engagement des clients.



2.4   Face au défi de la transformation digitale, il faut savoir utiliser les écosystèmes et devenir une plateforme

Le livre attache beaucoup d’intérêt aux plateformes, surtout aux plateformes bifaces à cause de l’effet de levier (network effect) qu’elles permettent d’obtenir, selon les principes théorisés par Jean Tirole. Les auteurs proposent cette belle citation extraite d’un article de Jean Charles Rochet et Jean Tirole : « Platforms devote much attention to their business model, that is, how the court each side while making money overall. This paper builds a model of platform competition with two-sided markets It unveils the determinants of price allocation and end-user surplus for different governance structures (profit-maximizing platforms and non-for-profit joint undertakings) ». Je vous renvoie à mon billet précédent sur les différents modèles de plateforme pour resituer le modèle biface (ou multiples côtés) par rapport aux plateformes d’innovation. Un des enjeux de la transformation des modèles d’affaire est de passer d’un modèle linéaire/indépendant (de type « pipeline ») à un modèle boucle/écosystème (via une plateforme) : « It is important to realize that there is no obvious continuum between a sophisticated pipeline business model that only recognizes one side in the market, and a platform business model that relies on network effects between two sides of a market to build a critical mass (although data platforms can and do support pipelines model) ». Le livre contient plusieurs exemples classiques mais intéressants, tels que la data platform de HERE (issu de la division cartographie de Nokia) dans la section 17.5 ou encore l’exemple de la plateforme biface Skywise de Airbus, avec des rôles différents en amont (fournisseurs) et en aval (compagnies aériennes).

Cette notion d’écosystème – le réseau des clients, fournisseurs et partenaires ainsi que les types d’interaction – se retrouve à la fois dans la fourniture des services mais également pour obtenir et partager les données qui sont nécessaires à ces services numériques : « Understand what data (that you do not already have access to) your business could benefit from. Is this data already being collected by someone else (a partner, supplier, or client perhaps) ? ». L’approche systémique des auteurs se retrouve également dans leur analyse des cycles de vie des données. On retrouve par exemple dans les illustrations de la section 8.2 le cercle vertueux de l’enrichissement des données : plus de données donnent des meilleurs insights, plus d’insights améliorent la pertinence donc l’usage, plus d’usage produit plus de données ou des données de meilleure qualité.  L’approche « plateforme et écosystèmes de données » est donc un accélérateur de création de valeur : « Platforms will be the enabler for unlocking all manner of data-centric insights and hence service innovation opportunities ».

Je ne vais pas rentrer dans le détail du sujet essentiel du respect de la “data privacy” mais je vous engage à lire les discussions intéressantes sur GDPR. Les auteurs insistent sur le respect de la compliance, mais également sur la prise en compte du point de vue des utilisateurs, puisque la confiance est le premier capital indispensable pour une approche plateforme : « It is essential to implement data sovereignty principles as an extension to GDPR in such a way that data privacy is not limited to data access but fully includes data usage control, otherwise there is a risk that individual perceived risks can prevent the realization of benefits from industry data platforms ».

2.5   Le pilotage traditionnel sur ROI (retour sur investissement) de l’innovation doit changer dans un monde VUCA.

Je vous recommande la section sur « The elusive Return on Innovation Investment ». Même si ce sujet est maintenant bien balisé (le passage d’un modèle de « retour sur investissement » à une approche de « perte acceptable »), les auteurs proposent une analyse détaillée et intéressante. Le point de départ, sans surprise, est la valeur diminuée de la prévision dans un monde VUCA : « Some argue that the very concept of ROII makes no sense. In general, it is based on so many wild estimations that its validity is nearly null, and this is truer the more disruptive the investment is. Kromer proposes discarding the ROII and understanding innovation as a financial option ». Passer à une approche “analyse d’option” conduit à comparer le “cost of doing” vs “cost of delay”. On notera tout de suite que la nature VUCA de l’environnement bruite les deux évaluations, mais il est en effet judicieux de toujours considérer le second terme : « Cost of Delay, which was first described by Donald Reinertsen, is the opportunity cost associated with not doing something  ».  Cette approche est liée à l’utilisation de l’heuristique Weighted Shorted Job First préconisée dans la méthode SAFe.  Néanmoins, j’attire l’attention du lecteur sur le risque associé à l’estimation du « cost of delay ». C’est à la fois une excellente façon de poser le problème (penser en termes d’option) et un risque, celui d’oublier que le monde est toujours incertain.  La relation entre les résultats (“outcome”) et les actions reste complexe et difficile à prévoir. Cela ne conduit pas à abandonner les mesures, le pilotage ou l’analyse, mais il faut garder sa lucidité. Comme l’écrivent les auteurs à propos des KPI: « Measures are not “Key”. They don’t address the heart of what end-users are really looking for. Business should ask themselves how many KPI are appropriate ... Measures are not really linked to designed outcomes. Thy are somewhat arbitrary measures of loosely related activity ».


2.6   La transformation digitale s’appuie sur des capacités, comme celles des systèmes d’information et des processus opérationnels métiers.

L’approche bimodale structure le plan d’action proposé dans le livre, où cohabitent les « foundations workstreams » pour inventer les nouvelles expériences disruptives et les nouveaux modèles d’affaire et les « enabling workstreams » pour améliorer de façon continue le cœur de l’entreprise : « these are the workstreams that will tend to optimize your business operations. They may diver efficiency and scale, but they will not (by themselves) impact the fundamental nature of your business ».  On retrouve ici très précisément l’approche de “Designed for Digital ».  L’art de la transformation digitale est de donner à chaque partie de cette approche bimodale suffisamment d’indépendance (pour que l’innovation de rupture puisse avoir lieu) sans ignorer la dépendance (l’entreprise a besoin de l’ensemble de ses capacités et la digitalisation des processus et systèmes de la partie « traditionnelle » nourrit le potentiel de la partie « nouveaux modèles d’affaire »).

Cette dépendance s’illustre en termes de systèmes d’information et plateformes de services numériques. Une partie importante de la transformation digitale repose sur les capacités du système d’information. Ce système doit se transformer pour servir les « enabling workstreams » (permettre l’optimisation) et pour exposer les services nécessaires aux « foundations workstreams ». Pour les auteurs, cela conduit à penser l’organisation des systèmes d’information en termes d’augmentation, plutôt qu’en termes de séparation : « If the digital transformation is properly designed and planned, it should normally be handled by an augmented IT department  ».


3. Conclusion

Je pourrais conclure ce billet en revenant, une fois de plus, sur le management de l’émergence et sur l’importance du livre de François Jullien pour comprendre le concept de potentiel de situation et l’opposition entre le temps long, celui de la transformation et de la construction du potentiel, et le temps court, celui de la saisie de l’opportunité. Je vous renvoie plutôt à mon dernier livre « l’approche lean de la transformation digitale ».

Je vais plutôt conclure de façon systémique en soulignant quatre tensions qui sont créatrices de valeur et d’énergie, pour la transformation digitale de l’entreprise :

  • Il faut combiner une approche de conception, qui cherche à construire un « backbone » de capacités, et une approche réactive de co-construction avec son environnement.
  • Il faut faire coexister une stratégie digitale claire (la finalité) avec une approche d’écoute des clients et d’apprentissage antifragile (l’homéostasie digitale).
  • Il faut combiner de façon bimodale la transformation continue de l’existant (en particulier du système d’information) et l’ajout constant de nouvelles capacités, selon un modèle d’organisation exponentielle.
  • Il faut savoir combiner ses propres atouts avec ceux de son écosystème en utilisant une approche plateforme.


 

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.